From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) (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 2DD5D3B0AC4 for ; Mon, 5 Oct 2026 08:30:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791189023; cv=none; b=EDBooeL/N1gabBK43HGM/y6uAe5e5FBbJkm9Hv9zdT2YurSfVJEOzq0WDmGla6N9CCWvGOCUdWV2hwVS+1RSNLH8I8bTOTC/sQ9wI8ESld0QYjOSurcKRq5xXFlFQm4O0KWs3keKYuDVCzOVioAGcjWJHUeOaIpUhoTQhd+xIRY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791189023; c=relaxed/simple; bh=vyTwTI8VlQ0pCbmAtLYSj9W7L6C9GYAol3GzhJTQf1g=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MS37T53yC+R6Zyljga77FmDVb42HAYYUh5AkkCcPFL/Qsdokdihar9UV1Uadur0eum39sj4cHkP5XrIHvUY6kHWhuSuxKDrjYT9tiv8Ewu72FA3ayq5jCt97IX6QDW+UwJFvPoWje3pd0kflQkdDo22oIjmdjM41DoX3RVs18nM= 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=c/EUI7So; arc=none smtp.client-ip=74.125.225.140 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="c/EUI7So" Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a1722c37c9so4856825e9.3 for ; Mon, 05 Oct 2026 01:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791189016; x=1791793816; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=sd1BmBIq6PAEb87txh8tHMQ7YpHFp1uklRh5l7OqDQs=; b=c/EUI7SoBfNBQAAdVHR7FXUjXzbc859r/vcm9DEFj2V3V+ztdzanJyKA16TllyawQP kEWRD1WC9U/anctRdZfCaupCHlSCySWN7lX4pi1zeV3YzoMGIhGXA6DrYaTZ/Mj8vGxS O8mkGDyF6/9t6GwrYSI6IVNxFZFlPA5qf95wzN2WrvfL8NzgR/7PZH7bLx6hYps01bkd dW5ICTMKKPfEVzjyTXKrgX820y5vccZaq0BkiyTghs5wZ6hFfqm4M7OVDCOBWZWB0Njg yI7xDLtFgQsnReo1W6g2ofBbFmG2PHxDrM2flnf7zWFsSScYNs/MZUxPv30b9NUxbq2p Ca1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791189016; x=1791793816; h=content-transfer-encoding:content-type: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 :content-type; bh=sd1BmBIq6PAEb87txh8tHMQ7YpHFp1uklRh5l7OqDQs=; b=gt5S/uf6GUgEt6W38PG37l5wwW75qqBzstoyKsFKzUp01wxXDmmbJlb9YWdkIozGuO dtNoLwoDm/rSRVx2NfDMhrM8xM3scCEQXNvKv9gPko1lY4KVk7Y4APsKMMxC2tYbwezG iHPMELjIJ4wYbF+4IlHGTNdqq2FnzqpUgju3+LbLQR2Ld5a3UbsN1D2XEwDaefd3/Flj 0gGDm0HEd+GeBV3mbBjk/M5s4OEnsqhkIho+Rv0Q6/oQcRpQChFfqlEEGsyb6AMMEmhs 3UG1VkJ34QPE7QeCNp8kdyV7j2OfOLQFcItKBEF9Gjm8PAQNZ+jFhqan6oXepRvAtljA FWGw== X-Forwarded-Encrypted: i=1; AKwUvBxGphb12geJpS5yiOOGERJAuhW+jfYtLIHj2tG3zQas35hyUWeGxo8wzZYrGN1ObEKoELVESm7PyChIf6c=@vger.kernel.org X-Gm-Message-State: AFuF++n5sZ15LBN4uQiwWdWt8TYQYzi7U9p+WDGdxX+yuZ8+lA3wFAcT if4DtDZKsOFkATRN9a7M/4NuSFIeHpkVy6VdkNeRcM5zK00Z7+xSqlcW X-Gm-Gg: AYBFou1LUJokX4lzE8XZ8KwHR4fQQ1qQgLHtre5AC6Vq+kom0rdsV3770sy8AdkxfaI qgYD/+HZy4LCNg7+Ykwy1A3gDZWYGdkdlgwneJAT7ZJHz2YwO54ouVsv9u25Aqg5FZol2h+ly/O r/0DGB+uUm0ntxLqNTmMj6rhbT5u/CiAtNMIjsJE/Ks3e6FEO9nxi0ay3+NSwhN05Sot/lrsWgi L8sgC4ZUWzyNmQXyOCsdX9G7pDtPPP0qrDSm0CMLflM4JbhMMnE49xoNrDN+nVeRRqgDNN6EGa2 mYQ9ZVdC0l7qG8liinvXbf/yIlIq/BNiQeLrACho2zRCoDLynLC/iPuJdc9I0bWcsbCI7tOw0pW 8mq+VtJSu49wINsgo5oLtYzRemuU3ymVaVSdkSA05lJulgs8s62eCQ/5lnjx/MUF9p/nTYBjpHw mZkLy+o+RGrV26y1DRWOFbMJZDHioysOFDV9s+LJyrz40+phs2glPNTIm01/rtHEIedR/eUpZau Hld9zO3Bw== X-Received: by 2002:a05:600c:4592:b0:4a0:bc9:28c6 with SMTP id 5b1f17b1804b1-4a0276b6860mr152436465e9.34.1791189014935; Mon, 05 Oct 2026 01:30:14 -0700 (PDT) Received: from foxbook (bfj133.neoplus.adsl.tpnet.pl. [83.28.47.133]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c63904832sm1548590f8f.14.2026.10.05.01.30.13 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 05 Oct 2026 01:30:14 -0700 (PDT) Date: Mon, 5 Oct 2026 10:30:11 +0200 From: Michal Pecio To: Sean Rhodes Cc: Ulf Hansson , Arnd Bergmann , Greg Kroah-Hartman , Ricky Wu , Lee Jones , Roger Tseng , Dan Carpenter , Jisheng Zhang , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] misc: rtsx_usb: avoid USB I/O in runtime autosuspend Message-ID: <20261005103011.03175826.michal.pecio@gmail.com> In-Reply-To: <7acac70a471452a6ccf23b7ccc557f3c3861e0ad.1783352430.git.sean@starlabs.systems> References: <7acac70a471452a6ccf23b7ccc557f3c3861e0ad.1783352430.git.sean@starlabs.systems> 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 Mon, 6 Jul 2026 16:40:43 +0100, Sean Rhodes wrote: > The runtime autosuspend callback currently queries card status and > clears OCP by issuing USB register accesses. This can run from the > USB runtime-PM path itself, which is the wrong place to start more > device I/O. > > Keep a cached copy of the card-status bits from normal status reads > instead. During runtime autosuspend, use that cached value only to > preserve the existing Memory Stick autosuspend deferral. How is the driver supposed to detect card insertion after the last poll but before the reader goes to suspend and can issue remote wakeup? This is exactly what happens now: if I insert a new card within two seconds of the "card removed" message showing up (which itself happens up to a second after removal) the insertion is never detected and the reader enters suspend with the card in. It seems that not only was "starting more I/O in the runtime-PM path" actually a good idea, but polling should only stop when the parent USB device suspends, not the child MMC host, because there is a two second delay between them. And even with this patch reverted, insertion never works if USB autosuspend is simply disabled altogether. Also, does anyone know if there is any way to utilize the interrupt endpoint instead of polling? I tried submitting a URB to it and got regular responses, but only zeros. Can this be changed? > Do not treat raw SD_CD as an autosuspend blocker, because tray-based > SD readers can assert SD_CD with an empty tray. A real SD card is > protected by the SD/MMC child runtime-PM usage once powered. Sounds like the proper condition is to ignore the card if and only if it failed to initialize and has not been swapped for a new one. Hence the question about interrupts: this would vastly reduce the risk that a swap for an actual working card remains undetected. Regards, Michal