LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2021-08-04 16:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210804143357epcas1p1c67eca591d8bb557c11b8175baaa8550@epcas1p1.samsung.com>
2021-08-04 14:32 ` Peter Geis
2021-08-04 16:15   ` Mark Brown [this message]
2021-08-05 10:00   ` Jaehoon Chung
2021-08-05 11:38     ` Peter Geis
2021-08-05 12:46       ` Mark Brown
2021-08-05 12:58         ` Peter Geis
2021-08-05 13:08           ` Mark Brown
2021-08-06  8:14             ` Ravikumar Kattekola
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 \
    --subject='Re: [BUG] mmc_regulator_set_ocr can'\''t cope with regulator-fixed' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).