[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZm9C23aHTWs8DNX1RChSB4A-X0PoyW5wnH2XyQQeviag@mail.gmail.com>
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