linux-kernel - Re: [PATCH 1/3 v3] pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x.

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:	Thu, 29 Aug 2013 17:36:32 +0800
From:	Sonic Zhang <sonic.adi@...il.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Grant Likely <grant.likely@...aro.org>,
	Steven Miao <realmz6@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	adi-buildroot-devel@...ts.sourceforge.net,
	Sonic Zhang <sonic.zhang@...log.com>
Subject: Re: [PATCH 1/3 v3] pinctrl: ADI PIN control driver for the GPIO
 controller on bf54x and bf60x.

Hi Linus,

On Thu, Aug 29, 2013 at 4:19 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Aug 22, 2013 at 10:48 PM, Stephen Warren <swarren@...dotorg.org> wrote:
>> On 08/22/2013 01:07 AM, Sonic Zhang wrote:
>>>
>>> There are 6 to 9 GPIO HW blocks in one Blackfin SoC. Function
>>> pinmux_enable_setting() in current pinctrl framework assumes the
>>> function mux setting of one peripheral pin group is configured in one
>>> pinctrl device. But, the function mux setting of one blackfin
>>> peripheral may be done among different GPIO HW blocks. So, I have to
>>> separate the pinctrl driver from the GPIO block driver add the ranges
>>> of all GPIO blocks into one pinctrl device for Blackfin.
>>
>> I don't think you need separate device; the pin control mapping table
>> entries for a particular state simply needs to include entries for
>> multiple pin controllers.
>
> So splitting each block into a separate pin control device is definately
> one way to skin the cat.
>
> The ux500 would then have 9 pin controller instances (after a
> big fat refactoring, but whatever) instead of 9 GPIO instances
> and one pinctrl instance referencing them. Also this solves
> the problem of registering GPIO ranges from the wrong end
> of the pin controller.
>
> Hm, I should try this and see where it goes... What do you
> think about this Sonic?

As I discussed with Stephen:

To separate the pinctrl_settings of one peripheral to multiple pinctrl
devices, multiple pinctrl group arrays and function arrays should be
defined in the soc data file. This change increases the code size of
the soc data file a lot without get any real benefits.

The pin controller device can be defined as a logic device to cover
many gpio devices, which are mapped into the same pin id space without
collision. All overhead in the soc data file can be removed in this
way. GPIO devices with pin id region collision should be put into
different pin controller devices.

So, I think it is fine to either binding pinctrl device to gpio device
or leave it as a logic device.

Regards,

Sonic
--
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/