Message ID | 20210811095759.1281480-1-geert@linux-m68k.org |
---|---|
Headers | show |
Series | auxdisplay: ht16k33: Add character display support | expand |
Hi Marek, On Wed, Aug 11, 2021 at 12:48 PM Marek Behún <kabel@kernel.org> wrote: > On Wed, 11 Aug 2021 11:57:59 +0200 > Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > Instantiate a single LED based on the "led" subnode in DT. > > This allows the user to control display brightness and blinking (backed > > by hardware support) through the LED class API and triggers, and exposes > > the display color. The LED will be named > > "auxdisplay:<color>:<function>". > > > > When running in dot-matrix mode and if no "led" subnode is found, the > > driver falls back to the traditional backlight mode, to preserve > > backwards compatibility. > > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > Reviewed-by: Marek Behún <kabel@kernel.org> Thanks! > BTW, this driver does not need to depend on OF, methinks. > The few instances of properties reading can be > easily rewritten to device_* functions (from include/linux/property.h). > The of_get_child_by_name() can become device_get_named_child_node(). > > Geert, what do you think? Sure, that can be done later, when an ACPI user appears? The dependency on OF was pre-existing, and this series is already at v5. Gr{oetje,eeting}s, Geert
Hi Andy, On Thu, Aug 12, 2021 at 2:33 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Wednesday, August 11, 2021, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> On Wed, Aug 11, 2021 at 12:48 PM Marek Behún <kabel@kernel.org> wrote: >> > On Wed, 11 Aug 2021 11:57:59 +0200 >> > Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> > > Instantiate a single LED based on the "led" subnode in DT. >> > > This allows the user to control display brightness and blinking (backed >> > > by hardware support) through the LED class API and triggers, and exposes >> > > the display color. The LED will be named >> > > "auxdisplay:<color>:<function>". >> > > >> > > When running in dot-matrix mode and if no "led" subnode is found, the >> > > driver falls back to the traditional backlight mode, to preserve >> > > backwards compatibility. >> > > >> > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> >> > >> > Reviewed-by: Marek Behún <kabel@kernel.org> >> >> Thanks! >> >> > BTW, this driver does not need to depend on OF, methinks. >> > The few instances of properties reading can be >> > easily rewritten to device_* functions (from include/linux/property.h). >> > The of_get_child_by_name() can become device_get_named_child_node(). >> > >> > Geert, what do you think? >> >> Sure, that can be done later, when an ACPI user appears? > > Actually with PRP0001 approach any of compatible driver may be used onACPI platform. So, what you are saying can be interpreted the way “we don’t care about users on ACPI based platforms”. If it is the case, then it should be told explicitly. I think you're interpreting too much ;-) My point is simply: >> The dependency on OF was pre-existing, and this series is already >> at v5. If any OF compatible driver can now be used on ACPI platforms, perhaps this should be handled at the API level? I.e. the distinction between OF and device properties should be dropped completely, and all drivers be converted mechanically in one shot, instead of a gradual ad-hoc conversion being sneaked in through other series like this one? Gr{oetje,eeting}s, Geert
On Fri, Aug 13, 2021 at 3:53 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Aug 12, 2021 at 2:33 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Wednesday, August 11, 2021, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >> On Wed, Aug 11, 2021 at 12:48 PM Marek Behún <kabel@kernel.org> wrote: > >> > On Wed, 11 Aug 2021 11:57:59 +0200 ... > >> Sure, that can be done later, when an ACPI user appears? > > > > Actually with PRP0001 approach any of compatible driver may be used onACPI platform. So, what you are saying can be interpreted the way “we don’t care about users on ACPI based platforms”. If it is the case, then it should be told explicitly. > > I think you're interpreting too much ;-) > My point is simply: > > >> The dependency on OF was pre-existing, and this series is already > >> at v5. Okay, but we can get rid of it. Why not make it more generic at the same time? Does it make sense? (I believe this is what Marek is asking initially) > If any OF compatible driver can now be used on ACPI platforms, perhaps > this should be handled at the API level? I.e. the distinction between > OF and device properties should be dropped completely, And this is done by device_*() / fwnode_*() APIs. And that's what can be easily done here. > and all drivers > be converted mechanically in one shot, instead of a gradual ad-hoc > conversion being sneaked in through other series like this one? Do you realize that you are asking for something impossible? Moreover, an ad-hoc approach is what we do for plenty of things in the kernel (WRT new APIs, that don't replace old ones immediately).