linux-kernel - [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed

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-next>] [day] [month] [year] [list]

Message-ID: <CAMdYzYrx8pgeyK7u=kcopZ+Wae+fQdr_uM4AuVjqWKfZYikgcA@mail.gmail.com>
Date:   Wed, 4 Aug 2021 10:32:52 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Jaehoon Chung <jh80.chung@...sung.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>
Cc:     linux-mmc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        devicetree@...r.kernel.org
Subject: [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed

Good Morning,

I've encountered a fun issue with the dw-mmc driver while working on
enabling support for the Quartz-64 Model A.
The regulator-fixed driver supports enabling via a gpio, but does not
have the ops to set voltage as it is fixed.
The dw-mmc calls mmc_regulator_set_ocr for vmmc, which attempts to set
the voltage first but fails due to the lack of the voltage ops. It
then bails returning -EINVAL.
This leads to the following message :
dwmmc_rockchip fe2b0000.mmc: could not set regulator OCR (-22)

This can be fixed by switching to regulator-gpio for the vmmc supply
to the sdmmc controller, however the sdio controller vmmc is provided
by a fixed regulator that is always on. Obviously the regulator-gpio
isn't an option, as it has no gpio to enable.

Removing the vmmc phandle from the sdio node is an option, but then it
doesn't fully describe the hardware (it's also a non-standard 4.4v).
I had considered changing the check in dw-mmc.c [1] to continue in the
case of -EINVAL, but there are other places in the regulator framework
that can also return that and it doesn't address the underlying issue.

As such I'm reaching out to the experts to see what the best course of
action is here.
Please weigh in with what you think.

Very Respectfully,
Peter Geis