linux-kernel - Re: [PATCH] mmc: dw_mmc: rockchip: Keep controller working for card detect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFoU=AoQqXov_-qFo8xjEbiDAk9mtTtCR9HAYz_gg-bnzQ@mail.gmail.com>
Date: Mon, 7 Oct 2024 11:49:17 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Robin Murphy <robin.murphy@....com>
Cc: Kever Yang <kever.yang@...k-chips.com>, Heiko Stübner <heiko@...ech.de>, 
	linux-rockchip@...ts.infradead.org, Jaehoon Chung <jh80.chung@...sung.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc: dw_mmc: rockchip: Keep controller working for card detect

On Fri, 4 Oct 2024 at 19:34, Robin Murphy <robin.murphy@....com> wrote:
>
> On 02/10/2024 10:55 pm, Ulf Hansson wrote:
> > On Sat, 14 Sept 2024 at 13:52, Heiko Stübner <heiko@...ech.de> wrote:
> >>
> >> Am Donnerstag, 12. September 2024, 09:26:14 CEST schrieb Kever Yang:
> >>> In order to make the SD card hotplug working we need the card detect
> >>> function logic inside the controller always working. The runtime PM will
> >>> gate the clock and the power domain, which stops controller working when
> >>> no data transfer happen.
> >>>
> >>> So lets skip enable runtime PM when the card needs to detected by the
> >>> controller and the card is removable.
> >>>
> >>> Signed-off-by: Kever Yang <kever.yang@...k-chips.com>
> >>
> >> So for the change itself this looks good, i.e. it fixes an issue for baords relying
> >> on the on-chip-card-detect.
> >>
> >>
> >> But for boards doing that, the controller will be running _all the time_
> >> even if there is never any card inserted.
> >>
> >> So relying on the on-soc card-detect will effectively increase the power-
> >> consumption of the board - even it it'll never use any sd-card?
> >
> > Good point! A better option is to use a polling based mechanism - and
> > we have MMC_CAP_NEEDS_POLL for exactly that.
> >
> > Moreover, on DT based platforms one can even use the "broken-cd"
> > property to indicate this.
>
> Except that goes further than is needed here, since it would fall back
> entirely to software-based polling for card presence. In this case the
> CD function is not broken in terms of actually detecting a card, it just
> doesn't work to wake the controller up from suspend because it can't
> fire its own interrupt while powered off. In principle all we should
> require here is to periodically resume/suspend the device, to provide a
> window for the interrupt to work and normal operation to take over if
> appropriate.

Well, I would not object if "broken-cd" would be used for this case
too. I believe it already is.

Another option would be to look at a compatible string and set
MMC_CAP_NEEDS_POLL based on that.

>
> Of course the really clever way would be for suspend to switch the pin
> into GPIO mode, and set the GPIO interrupt as a wakeup to trigger resume
> and switch it back again, but perhaps that's a bit tricky without
> explicit pinctrl states in the DT :/

Right. A dedicated GPIO pin for the card detect is certainly the
preferred method, if you care about not wasting power.

Kind regards
Uffe