linux-kernel - Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

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]

Date:	Wed, 24 Oct 2012 09:18:01 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Benoit Cousson <b-cousson@...com>,
	Sourav Poddar <sourav.poddar@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-input@...r.kernel.org,
	Felipe Balbi <balbi@...com>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> 
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same patches for the rest of input drivers shortly.
> > This suggests that the operation is done at the wrong level. Do the
> > pin configuration as you parse DT data, the same way you set up i2c
> > devices registers in of_i2c.c, and leave the individual drivers that do
> > not care about specifics alone.
> 
> Exactly this can be done with pinctrl hogs.
> 
> The problem with that is that it removes the cross-reference
> between the device and it's pinctrl handle (also from the device
> tree). Instead the pinctrl handle gets referenced to the pin controller
> itself. So from a modelling perpective this looks a bit ugly.
> 
> So we have two kinds of ugly:
> 
> - Sprinke devm_pinctrl_get_select_default() over all drivers
>   which makes pinctrl handles properly reference their devices
> 
> - Use hogs and loose coupling between pinctrl handles and their
>   devices
> 
> A third alternative as outlined is to use notifiers and some
> resource core in drivers/base/*

OK, so with drivers/base/, have you considered doing default pinctrl
selection in bus's probe() methods? Yo would select the default
configuration before starting probing the device and maybe select idle
when probe fails or device is unbound? That would still keep the link
between device object and pinctrl and there less busses than device
drivers out there.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/