From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 B398F3E9C37 for ; Wed, 13 May 2026 11:40:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778672420; cv=none; b=cRFXs0N4cJHR3JNChEUo+yjQKNb0EWeo6MSOwz3jJ+/0qHMy/KPKxrwrjMxcpKcMqrYCFEl2SWmCtA8IK4Frd/jGlE/bDVdn0C+Zvrp2LiYQt0l/1XLTLSslskoYRkd4kOMRtygXHGlviTRasLsZxinutiW4D1rmqsETh/hE5l4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778672420; c=relaxed/simple; bh=Zo1bKwZlEZaICjjvIUgDqifzJHuTu0prbFdXHcd3FNQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=divSYZeMfg67iTktRFBZDYkI6qYcpAeVk6MF+DcRMmYdx0D74yppd/qFHpMP+Pz3lGueR+1X0d0QczR7SzG+Q/n8frYZmuPHhIaEk26xg05DtCCqXLi8UEukV1P23axbtMedlCqtnv1/P62S7sK+WFwjNTMnGmTu9At2EkIWmro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=starlabs.systems; spf=pass smtp.mailfrom=starlabs.systems; dkim=pass (2048-bit key) header.d=starlabs-systems.20251104.gappssmtp.com header.i=@starlabs-systems.20251104.gappssmtp.com header.b=rqAJu54F; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=starlabs.systems Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=starlabs.systems Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=starlabs-systems.20251104.gappssmtp.com header.i=@starlabs-systems.20251104.gappssmtp.com header.b="rqAJu54F" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-48e8132c6d0so29056055e9.1 for ; Wed, 13 May 2026 04:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=starlabs-systems.20251104.gappssmtp.com; s=20251104; t=1778672417; x=1779277217; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/fRyxJU14pJX/5AtyEOHNqc7Zwu4u8GCE+MLyPL2ieU=; b=rqAJu54FRTrpmGuLruV+gTNJJ5gAYFTpJWaWxHvKBjOC5UeJ+1srIe3wxOt676ty7Q zj4h4eZD9OytcJiO/+RNriMqRkfNSXoCva/2trzDr/a7g7N+rRcSfaYd35W7ltzVS6z8 Pm+DVFULxI6dsWkSBLxewAiL4QqQYH1T1OnQncakKIS9IDjl8WeHSfNsMyOXWX3gYrKw gkm6c4J3DjbtfTV3m4axBeoIdZe0EDcF0Ce/FBZQIvY+NUSQSLJrxofNKrq/c5I7IsmC N9YaFZYjuSvom1dfCJlQiO0RCPV4sfROgNFQjXGWMWw7BPle1BPc1PrdbOSp6qB3lhAL 2S1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778672417; x=1779277217; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/fRyxJU14pJX/5AtyEOHNqc7Zwu4u8GCE+MLyPL2ieU=; b=RqiKKgZp/ZLEAhbZ1sZTXa9DxErUKUKI/HPvaX1h6zJw9PKvieA8Nix6lt8Ohux8ez B60CjJsF9pLbXWdyFmXERk/m3abe+rraH0cTcZjCAvr9ekpqMkVDCGDXXrRvJzyF+L4p UIaaAG+5T130Kp+qeX/gQd742r61hmy9oSCBr3zjszTHsYyi/3rm0NjFier6K6tJGGdk w/40oBuLwDpu5Ce3kBlNq9sxY7gQtD4Gmw5YDHQ5HJPl9TtbkJUA19MpCuLxjnqmtQud UjN/k+tWEccNzsYaSpAjjFKPLUJhACmCYSYqYAEIpFUm5DMk1nxs0zGsVWIDZuhnm+K9 HBlQ== X-Forwarded-Encrypted: i=1; AFNElJ9JH41XNf/eTCERRXXcVQzI29uWHiaBJv5cet0eiRNlawNAhe12/tMS0y/9C0rMggmqxde4RJ2+O7RXgnE=@vger.kernel.org X-Gm-Message-State: AOJu0YzG8/GUVrl/yFjDXAK+d6Ek2zt3UeBBc0jvHKYRbSPgezUjxacX tJHF3XrGsxmjJuL9YIjn6CK+VHOm4POM0XGuthPWkpAXp6ljy9hCBLI8E1kVY3hf+hY508WoYhP ZcyuuCqJA X-Gm-Gg: Acq92OHfVDhKxyMNLKP25IhR68ytQs3h/nYdehK82YjsQJMHN4rHdvVrJmT7EyYT4JD Dr/o7Dskq1fZllqKUe7/wZhWroNAOfncvIbo1sPxB5grCd4tACj6QrPexxfgIIG21tU8b1myTL+ pg7s4xsXnD2nub27R6AR/BOpmmqWj+w/DzJZ7u25030M0Gb2PHn4xSDPPXsonw97hNva9E0MssL lem79D56eCphpFJWuliqyhgIlQGt0BEShsCGBEfHJ8qkRg7gDcaMF69nMoD7hDECX0XWXL9HJFY oyigWf+CJ2IlBDn2YLqZA3hoRmcCUo5rXqObePGydyId1Yc68mtthOaBXaLinJuLaLGFjMuQVcU n6ciJQ3LCB8v1BH6YwxEQgSEZpbDj+QZY5/tturMYkAbhkuY+B0sR8Q/xS7+Ncxf6tfMaOmt9GN b4TEEg6xxouUZdjiRxzCTwWfMVTMyymNWYCXRRU7OmWPVZriqPrl3SyGTVOjvejifsb1E5 X-Received: by 2002:a05:600c:1547:b0:48e:8499:4bd7 with SMTP id 5b1f17b1804b1-48fce9eb099mr33828485e9.17.1778672416784; Wed, 13 May 2026 04:40:16 -0700 (PDT) Received: from horizon.localdomain ([212.105.128.254]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fcdf64013sm53508475e9.2.2026.05.13.04.40.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 04:40:16 -0700 (PDT) From: Sean Rhodes To: Ulf Hansson Cc: Ricky Wu , Avri Altman , Sean Rhodes , Jisheng Zhang , Nathan Chancellor , Dan Carpenter , Binbin Zhou , linux-mmc@vger.kernel.org, Huacai Chen , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, gregkh@linuxfoundation.org, arnd@arndb.de, ulf.hansson@linaro.org, adrian.hunter@intel.com, rogerable@realtek.com, matthew.schwartz@linux.dev Subject: [RFC PATCH 0/2] mmc: rtsx_usb_sdmmc: qualify card-detect on tray readers Date: Wed, 13 May 2026 12:40:11 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Uffe, USB/cardreader folks, Uffe suggested sending this as an RFC and adding the USB/cardreader side, because this may need input on where the media qualification should live. I previously sent an RFC for the USB/cardreader runtime-PM side of this problem. That did not get USB/cardreader-side guidance on the detect layering question; the only substantive feedback was that the MMC child should already own runtime PM for a real inserted card. I have since retested that, and it is correct: with real media inserted, rtsx_usb_sdmmc holds runtime_usage=1 and the USB parent remains active through runtime_active_kids=1. The remaining failure is narrower: empty tray only. Raw SD_CD remains asserted, the MMC core repeatedly probes non-existent media, and the runtime-PM hierarchy does not settle. This is an RFC for the Realtek RTS5129 tray-reader false-detect issue. Short version: on these machines, raw SD_CD is not a reliable "card is present" signal. It is asserted when the tray is inserted, even if the tray contains no SD card. That means the current driver reports card-present to the MMC core for an empty tray. The MMC core then does what it should do: it tries to initialize a card. The commands time out, no mmcblk device is created, but because SD_CD remains asserted the detect path is entered again. In practice this keeps rtsx_usb_sdmmc runtime-active and prevents the USB parent from autosuspending. I retested this on an RTS5129 reader: - tray removed: no mmcblk device, rtsx_usb_sdmmc suspends, USB parent suspends - empty tray inserted: no mmcblk device, repeated CMD0/CMD8/CMD55/CMD1 probe loop, rtsx_usb_sdmmc remains active, USB parent remains active - tray + SD card: mmcblk0 appears and reads correctly; the MMC child holds runtime PM as expected The old Realtek rts5139 staging driver did not treat raw tray/CD state as sufficient. It qualified insertion by checking whether media actually responded before reporting a card present. That approach works on this hardware, and avoids papering over the issue in runtime PM. I know the previous version put the validation directly in ->get_cd(), and the objection was that MMC command probing does not belong there. I'm not trying to ignore that feedback. The question for this RFC is the layering: - if the only exposed hardware bit is "tray inserted", not "card present", where should the Realtek-specific media qualification live? - is an rts5139-style qualification acceptable in rtsx_usb_sdmmc if it is kept out of the generic MMC core? - or should the USB/cardreader parent expose a qualified media-present state to the SD/MMC child? This is intentionally copied to linux-usb and the char/misc/cardreader maintainers, not just linux-mmc, because one possible answer is that the USB/cardreader parent should expose a qualified media-present state rather than having rtsx_usb_sdmmc compensate for raw SD_CD. Patch 2 keeps the validation path in a known initial electrical state by starting SD power-up at 3.3V, matching the old Realtek rts5139 driver. It is included because the validation sequence must not inherit a previous 1.8V state. I have deliberately left the SDR/UHS rate patches out of this RFC. They are separate capability work and just make this harder to review. This series is only about making tray card-detect correct and stopping the empty-tray detect loop. Thanks, Sean Sean Rhodes (2): mmc: rtsx_usb_sdmmc: avoid false card-detect on tray readers mmc: rtsx_usb_sdmmc: start card power-up at 3.3V drivers/mmc/host/rtsx_usb_sdmmc.c | 161 ++++++++++++++++++++++++++++-- 1 file changed, 153 insertions(+), 8 deletions(-)