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]
Message-ID: <576B9B3A.2070808@baylibre.com>
Date:	Thu, 23 Jun 2016 10:18:02 +0200
From:	Neil Armstrong <narmstrong@...libre.com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Rob Herring <robh@...nel.org>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: sx150x: Update OF configuration

On 06/23/2016 10:08 AM, Linus Walleij wrote:
> On Mon, Jun 20, 2016 at 5:57 PM, Rob Herring <robh@...nel.org> wrote:
>> On Fri, Jun 17, 2016 at 11:51:03AM +0200, Neil Armstrong wrote:
> 
>>> +Optional Properties:
>>> +- oscio-is-gpo: Boolean, Indicated the oscio pin can be used as additional
>>> +             output gpo port.
>>> +
>>
>>> +- pull-up-ports: Array of port numbers which must have pull-up enabled.
>>> +- pull-down-ports: Array of port numbers which must have pull-down enabled.
>>> +- open-drain-ports: Array of port numbers which must be configured as open-drain,
>>> +                     Push-Pull mode is default.
>>> +- polarity-invert-ports: Array of port numbers whih port polarity must be inverted.
>>
>> Seems like these should be done in a common way.
>>
>> If not, they all need a vendor prefix.
> 
> Actually on second look, this takes the sx150 to pin control territory.
> 
> I am starting to feel like a move to drivers/pinctrl/* might be warranted.
> 
> Neil you worked on other pin controllers IIRC, do you think it would
> be much work to make a combined GPIO+pinctrl driver and move
> this over to drivers/pinctrl?
> 
> I know refactoring across subsystems can be a pain, but at least
> I'm maintaining both and happy to help out.
> 
> Yours,
> Linus Walleij
> 

Hi Linus,

Yes, it would be good to have it as a gpio+pinctrl with only pinconf, but it would show
the way on how to support external GPIO expanders using the pinctrl framework.

But it is quite challenging and needs quite some work, and actually the current state of the driver is that the OF is broken.

Would you agree to :
 - Push the minimal code to make OF work again, at least for 4.7 ?
 - Engage complete refactoring to transform it in a real gpio+pinctrl driver ?

For the dt-bindings properties, I can add the vendor prefixes ASAP.

Thanks,
Neil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ