lkml.org 
[lkml]   [2022]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v1 1/3] hwmon: (pwm-fan) Make use of device properties
On Fri, Aug 19, 2022 at 4:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Fri, Aug 19, 2022 at 12:56:42PM +0300, Andy Shevchenko wrote:
> > On Fri, Aug 19, 2022 at 2:41 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > > On Sat, Aug 06, 2022 at 06:25:15PM +0300, Andy Shevchenko wrote:
> > > > Convert the module to be property provider agnostic and allow
> > > > it to be used on non-OF platforms.
> > > >
> > > > Add mod_devicetable.h include.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > >
> > > I had another look at this patch. A substantial part of the changes
> > > is because device properties don't support of_property_read_u32_index(),
> > > reworking the code to use device_property_read_u32_array() instead.
> > > Sorry, I don't like it, it results in a substantial number of unnecessary
> > > changes. Device properties should support the equivalent of
> > > of_property_read_u32_index() instead to simplify conversions.
> >
> > Not all (device property) providers can have such API available. Are
> > you suggesting to
> > a) alloc memory for entire array;
> > b) cache one for a given index;
> > c) free a memory;
> > d) loop as many times as index op is called.
> >
> > Sorry, this is way too far and non-optimal in comparison to the
> > substantial number of unnecessary changes (two or three small
> > refactorings?).
> >
> > Another way is to provide a pwm-fan-acpi, which will be the copy of
> > the driver after this patch is applied. I don't think it's a very
> > bright idea either.
> >
> An alternative might be to split the patch in two parts, one replacing
> of_property_read_u32_index() with of_property_read_u32_array() as
> preparation, with the above rationale and a note that this is to
> prepare for the switch to device properties, and then the actual device
> property switch. Some context showing how other conversions handled this
> problem would also be nice, though not necessary.

Thanks for the idea, I like it and it would indeed simplify the
understanding of the changes made.

--
With Best Regards,
Andy Shevchenko

\
 
 \ /
  Last update: 2022-08-20 01:35    [W:0.056 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site