From: Arnd Bergmann <arnd@arndb.de>
To: Tony Lindgren <tony@atomide.com>
Cc: Andreas Fenkart <afenkart@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH v3 1/1] mmc: omap_hsmmc: devm_pinctrl_get returns ERR_PTR upon error
Date: Thu, 21 Apr 2016 00:28:05 +0200 [thread overview]
Message-ID: <4155990.SfY6i69ddf@wuerfel> (raw)
In-Reply-To: <20160420151337.GK5973@atomide.com>
On Wednesday 20 April 2016 08:13:37 Tony Lindgren wrote:
> * Andreas Fenkart <afenkart@gmail.com> [160420 04:39]:
> > 2016-04-20 10:11 GMT+02:00 Dan Carpenter <dan.carpenter@oracle.com>:
> > > On Tue, Apr 19, 2016 at 03:12:27PM -0700, Arnd Bergmann wrote:
> > >> On Tuesday 19 April 2016 23:04:13 Andreas Fenkart wrote:
> > >> > Only the dummy implementation of devm_pinctrl_get returns NULL.
> > >> > The real implementation returns ERR_PTR. By enforcing pinselect
> > >> > in Kconfig we can simplify the test to check only for ERR_PTR.
> > >> > detected/triggered by static code checker.
> > >>
> > >> This is not how the interface is meant to work:
> > >>
> > >> The dummy devm_pinctrl_get() intentionally returns NULL because IS_ERR()
> > >> treats that as valid. All other pinctrl functions subsequently ignore
> > >> that NULL pointer, so the second half of the patch is ok without the
> > >> first half.
> > >>
> > >
> > > We had that discussion. The static checker warning triggered the
> > > discussion but the real reason for this patch is that the
> > > hardware will not work without PINCTRL. So instead of compiling an
> > > unusable kernel we added the select.
Ok, but if that is the case, that the changelog text above should be
rewritten to explain it (but as Tony explains it was probably a
misinterpretation).
> > beaglebone needs the workaround, most chips don't. The code discussed,
> > only gives some feedback to users about an incorrect configuration.
> > I can drop that part or replace it with a dev_info line, pointing to
> > "Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt"
>
> Yes pinctrl is optional for sure. And leaving pinctrl out does not
> produce an unusable kernel for some boards that do all the pin muxing
> in the bootloader. Like Andreas says, only some boards need dynamic
> pin muxing for the wake-up events.
>
> The dev_info change sounds like papering over the issue.. I'm fine
> with that, but isn't the real problem devm_pinctrl_get prototype?
>
>
I don't see anything wrong with the devm_pinctrl_get prototype other
than how it frequently confuses driver writers.
Arnd
next prev parent reply other threads:[~2016-04-20 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 21:04 [PATCH v3 0/1] mmc: omap_hsmmc: devm_pinctrl_get returns ERR_PTR Andreas Fenkart
2016-04-19 21:04 ` [PATCH v3 1/1] mmc: omap_hsmmc: devm_pinctrl_get returns ERR_PTR upon error Andreas Fenkart
2016-04-19 22:03 ` kbuild test robot
2016-04-19 22:12 ` Arnd Bergmann
2016-04-20 8:11 ` Dan Carpenter
2016-04-20 11:38 ` Andreas Fenkart
2016-04-20 15:13 ` Tony Lindgren
2016-04-20 22:28 ` Arnd Bergmann [this message]
2016-04-21 4:32 ` Dan Carpenter
2016-04-19 22:15 ` kbuild test robot
2016-04-19 22:19 ` kbuild test robot
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=4155990.SfY6i69ddf@wuerfel \
--to=arnd@arndb.de \
--cc=afenkart@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox