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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> > > > Acked-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > > > 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, Guenter
