From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C8DE19F40A for ; Fri, 14 Nov 2025 12:32:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763123558; cv=none; b=bopKvoEheOXw7iiADrz9hGzAWQzLdBKK/wicxsBAKiKxZH2gFkdqDIYHMpA4KM8iQwDQIVTp4Sq3gzqtH6opvTGkoWZ9VmKmpiS1TaPmzbqeXu0O6ftJJQ5fC0uNBLOIaruxfUem2zUSd44LBjGc2LgOPfZwu10mazFtGgdYalQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763123558; c=relaxed/simple; bh=DIJjYjFtI2spgDs2sVP6KIq23gVo71gRQCz0nIFteQE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EgTZuW4qbMSg8mhJWmSET0QoDGfFQmVvJTFcLRxmoG/9eVvdBZVkyo6Jz2NIpF+EPQH0GqcRvanNtS+3CKPlQNrqKyIgzneRK6mLPsZtl2DQ/3jip6uScOQWbwBOGXWiemgvvFFq/8kaBQV0ifu7EMhlPz+xj0jXZqCDskCPyyk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eqw/Z2RG; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eqw/Z2RG" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-b70bee93dc4so263137166b.3 for ; Fri, 14 Nov 2025 04:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763123555; x=1763728355; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=QeHeMacQ98VS8jGbNZN3tzdZLAogm9JqSfkYxWWrnr8=; b=eqw/Z2RGVfZjKvYnY2MpWn2I/Up6uU1aa9KgKB49H/aVwDSHH1laa/yfvNGBSfZcMm X/LIhSQxpZzUhN/oudPw+qTFpTo9mmNBNKpWGAM+f5OKALtaOTuz6MEfG6BZIzoU7BlW AEfmbIw8rPuP4+sWpSCJ6rISPlQofq/fYMwc0BXEYctYTMyqfrqd7AJpQbgmOZBIz4fj Lfg/jrXM+r2Ndt+DQirjU0CPPXEHlhKy4H1JZRVz62khqdWMKFKL8otN7W69wTVLimES N1NZlTzK2lGcdR9thfJH6hglw6VGVmEqYKies8p755OZTfzmKb9PJWPASSMKHuYpuEg8 Yxxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763123555; x=1763728355; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QeHeMacQ98VS8jGbNZN3tzdZLAogm9JqSfkYxWWrnr8=; b=KD/yx9+313qC5hjHd6j7SMnPFkZf04gif9Fu5dk5gXc6oInRwRx4OVPRkfCdmr/doE 6CIu/Vd0W6+BUcZeCItCL8wBsi3AlrY0haVDEyY72Bn8YX/AC+hPKiPDrv1Dx80GscJy 3eBM5Y9s4K0OGvwFBbDvq6EcOyPr8AqN2ryoWSHx22MbUOpR3Vwu38TY96yWfpuWyi4e POKMk8QciSkoTllQ7M0bZdJFAphC5z44vjmr6JfDrzodbqMwYXdUdMduSpMf0KBuVJEa TvsERtz3ndbYR2+u6bkTfZj2QviT7jmNyf3eXqapbmwwqK8qKlOWs+mUpVeEUwy/vZ+F JGOg== X-Forwarded-Encrypted: i=1; AJvYcCUcdEvNKkXBdx3Yn9gOUkrS/nIUaCM4eQwdTEcTRlZ894cd0lX9rAmS4R3Ejm+keYpzQQ4KseTfMcG2560=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5f7IEE7Bep+/RxuLebGMaIrQmfJoVz4/dfxIP7njDCRd++3pX EO4qn1sdO+wCO3tFXCf0QPvo8sKoNDPMXkr004m3pTGREbZPAWotmrQB X-Gm-Gg: ASbGncsr/oFcUAiqhneAGdUMvIyYivBPgnloqpyXNiF2/ywcRcR55VaTEismuRrtSZL /2aQ8KgHlW3WQzxGMdi2UhM/UWLzYWl4il8fUKDLR/LZ6/Sbgh0LwfdPd0QMZdNO4isAtTG8ub7 TybxylKpvn1+ygctoT+S659gh0BzYuxM7acCetFqxPmXUuiKlMHIDQv42wgibZmKPe9+JmkGO0w vqf1qJqhQbA3BwenfxJ1du+VEIxJKSilJuV2xcF9D+7gKmFDHkeB05pVgQKFVDHVP1mp7BM3eGF IFJiWEDOpXCb+6BsExrG0fLzkyQtL6D93eAhXOcn5eHJKe0ZqNGogvERPpvL72IhbpNvwF/AEbE nLx0XbcIH8qMHhauaurPPTUmaaArUYRQ3KGMJEVSN7krR9baHOKYMe5k0/lUp5YtBe6RU526EsR kd2C5K2ooCkg== X-Google-Smtp-Source: AGHT+IHCOXnWh0xyAvkPtNe79UUfkP7BpqznH6RoChqC1GNR7ult8e2DIaStzBV+HDUl/Ydg/BSxWA== X-Received: by 2002:a17:906:f59c:b0:b73:6534:5984 with SMTP id a640c23a62f3a-b736780bcc3mr269364766b.16.1763123555293; Fri, 14 Nov 2025 04:32:35 -0800 (PST) Received: from foxbook (bfd52.neoplus.adsl.tpnet.pl. [83.28.41.52]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b734fad3edasm376754766b.17.2025.11.14.04.32.34 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 14 Nov 2025 04:32:35 -0800 (PST) Date: Fri, 14 Nov 2025 13:32:31 +0100 From: Michal Pecio To: Mathias Nyman Cc: Mathias Nyman , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: xhci: Assume that endpoints halt as specified Message-ID: <20251114133231.3f187b94.michal.pecio@gmail.com> In-Reply-To: References: <20251107111317.69be45a5.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 11 Nov 2025 14:13:05 +0200, Mathias Nyman wrote: > Makes sense, I guess we can only trust hardware to update the state in > the endpoint context on specific command completions, not transfer events. Technically, 4.8.3 requires HW to update to Running before writing any transfer event to the event ring. It says nothing about Halted, though 4.10.2.1 appears to imply similar ordering in case of Stall Error. But then 4.8.3 explicitly says The update of EP State may also be delayed relative to a Doorbell ring or error condition (e.g. TRB Error, STALL, or USB Transaction Error) that causes an EP State change not generated by a command. so the spec is a self-contradictory mess as usual. My hope with this patch is that maybe other SW vendors follow 4.8.3 recommendation and HW gets tested to work under such conditions. The Promontory problem is not even a delay, it's a complete failure. I added a loop which waits for GET_EP_CTX_STATE(READ_ONCE(ep_ctx)) to become HALTED and it was still RUNNING after 1.5 second. I guess it's some stinking internal race condition again, maybe it halts too quickly after restart and then a delayed update to Running overwrites the Halted state update. Or something that only happens if we restart too quickly after previous error. IIRC, it was never happening the first time the endpoint halts after loss of connection, only randomly later after some resets. Regards, Michal