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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Aug 2021 15:54:11 +0200 From: Linus Walleij <linus.walleij@...aro.org> To: Andrew Jeffery <andrew@...id.au> Cc: Linux LED Subsystem <linux-leds@...r.kernel.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, Cédric Le Goater <clg@...d.org>, Rob Herring <robh+dt@...nel.org>, Joel Stanley <joel@....id.au>, Pavel Machek <pavel@....cz>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-aspeed <linux-aspeed@...ts.ozlabs.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 4/6] leds: pca955x: Use pinctrl to map GPIOs to pins On Fri, Jul 23, 2021 at 9:59 AM Andrew Jeffery <andrew@...id.au> wrote: > The leds-pca955x driver currently assumes that the GPIO numberspace and > the pin numberspace are the same. This quickly falls apart with a > devicetree binding such as the following: (...) Honestly I do not understand this patch. It seems to implement a pin controller and using it in nonstandard ways. If something implements the pin controller driver API it should be used as such IMO, externally. This seems to be using it do relay calls to itself which seems complicated, just invent something locally in the driver in that case? No need to use pin control? Can you explain why this LED driver needs to implement a pin controller? Yours, Linus Walleij
Powered by blists - more mailing lists