From: Mark Brown <broonie@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Jaehoon Chung <jh80.chung@samsung.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
linux-mmc@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
devicetree@vger.kernel.org
Subject: Re: [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed
Date: Wed, 4 Aug 2021 17:15:01 +0100 [thread overview]
Message-ID: <20210804161501.GB26252@sirena.org.uk> (raw)
In-Reply-To: <CAMdYzYrx8pgeyK7u=kcopZ+Wae+fQdr_uM4AuVjqWKfZYikgcA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
On Wed, Aug 04, 2021 at 10:32:52AM -0400, Peter Geis wrote:
> 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.
What is the underlying issue that you don't see as being fixed if the
MMC code is able to cope with not being able to read the voltage? If we
don't know what voltage the regulator has then no amount of wishful
thinking is going to give us that knowledge, if we want to proceed with
controlling the device then the MMC code is going to need to make some
decisions about what it's safe to do given the limited information it
has available to it. Otherwise there's no option other than providing
the information about the voltage.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Jaehoon Chung <jh80.chung@samsung.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
linux-mmc@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
devicetree@vger.kernel.org
Subject: Re: [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed
Date: Wed, 4 Aug 2021 17:15:01 +0100 [thread overview]
Message-ID: <20210804161501.GB26252@sirena.org.uk> (raw)
In-Reply-To: <CAMdYzYrx8pgeyK7u=kcopZ+Wae+fQdr_uM4AuVjqWKfZYikgcA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 955 bytes --]
On Wed, Aug 04, 2021 at 10:32:52AM -0400, Peter Geis wrote:
> 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.
What is the underlying issue that you don't see as being fixed if the
MMC code is able to cope with not being able to read the voltage? If we
don't know what voltage the regulator has then no amount of wishful
thinking is going to give us that knowledge, if we want to proceed with
controlling the device then the MMC code is going to need to make some
decisions about what it's safe to do given the limited information it
has available to it. Otherwise there's no option other than providing
the information about the voltage.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2021-08-04 16:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210804143357epcas1p1c67eca591d8bb557c11b8175baaa8550@epcas1p1.samsung.com>
2021-08-04 14:32 ` [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed Peter Geis
2021-08-04 14:32 ` Peter Geis
2021-08-04 16:15 ` Mark Brown [this message]
2021-08-04 16:15 ` Mark Brown
2021-08-05 10:00 ` Jaehoon Chung
2021-08-05 10:00 ` Jaehoon Chung
2021-08-05 11:38 ` Peter Geis
2021-08-05 11:38 ` Peter Geis
2021-08-05 12:46 ` Mark Brown
2021-08-05 12:46 ` Mark Brown
2021-08-05 12:58 ` Peter Geis
2021-08-05 12:58 ` Peter Geis
2021-08-05 13:08 ` Mark Brown
2021-08-05 13:08 ` Mark Brown
2021-08-06 8:14 ` Ravikumar Kattekola
2021-08-06 8:14 ` Ravikumar Kattekola
2021-08-06 10:59 ` Mark Brown
2021-08-06 10:59 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210804161501.GB26252@sirena.org.uk \
--to=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jh80.chung@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pgwipeout@gmail.com \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.