linux-kernel - Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

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, 15 Oct 2014 10:08:12 +0300
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	linus.walleij@...aro.org, gnurou@...il.com,
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from
 pinctrl to gpio directory

On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote:
> Hi Mathias,
> 
> On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> > On 13.10.2014 22:17, David Cohen wrote:
> > > Even though GPIO module on Intel Bay Trail is able to control pin
> > > functionality, it's unlikely Linux kernel driver will ever support it
> > > since BIOS should handle all pin muxing itself.
> > > 
> > > Currently this driver does not register any pinctrl interface and
> > > doesn't call any pinctrl interface. It just uses on internal functions
> > > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > > under gpio directory.
> > > 
> > 
> > This discussion was held when gpio-baytrail was first submitted.
> > These threads explain the gpio/pinctrl-baytrail history:
> > 
> > http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> > http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> > http://marc.info/?l=linux-kernel&m=137155497023054&w=2
> 
> Thanks for pointing that out.
> 
> > 
> > A proper pinctrl driver for baytrail is still not yet ruled out
> 
> Having it inside pinctrl directory is creating some confusion because
> ppl expect it to implement the actual pinctrl interface.

A typical pinctrl driver can implement both a pinctrl interface and a
GPIO interface. So it is not uncommon to look the GPIO drivers under
drivers/pinctrl/*.

Furthermore the driver announces that it is a GPIO driver in its Kconfig
entry:

config PINCTRL_BAYTRAIL
        bool "Intel Baytrail GPIO pin control"

so I don't quite get why this would confuse people.

We are also planning to add more Intel pinctrl (real) drivers in the
future. drivers/pinctrl/intel/* should be the place where people find
the pinctrl/GPIO drivers for newer Intel hardware.

> Anyway, the threads above are over 1 year old. Perhaps it was making
> sense during that time, but unless somebody is working on pinctrl
> interface now, IMHO we're misplacing the driver for too long. It'd
> better to move this driver to gpio directory and when/if pinctrl
> interface is implemented, we move it back to current place.

I disagree.

What happens when people and distros have CONFIG_PINCTRL_BAYTRAIL=y and
now the symbol is changed to something else? For one, it will break the
existing working configs.
--
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/