On Thu, Sep 22, 2022 at 08:22:54PM +0000, Sakari Ailus wrote: > On Thu, Sep 22, 2022 at 04:54:10PM +0300, Andy Shevchenko wrote: > > Add const qualifier to the device_get_match_data() parameter. > > Some of the future users may utilize this function without > > forcing the type. > > From const to non-const? This is what this patch does, right? Right. > > All the same, dev_fwnode() may be used with a const qualifier. > > > > Reported-by: kernel test robot <lkp@xxxxxxxxx> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > -struct fwnode_handle *dev_fwnode(struct device *dev) > > +struct fwnode_handle *dev_fwnode(const struct device *dev) > > If you have const struct device pointer, then the embedded fwnode handle in > that object sure is const, too. Isn't it? > > If you really have const struct device pointer (where do you?), then I'd device_get_match_data() expects the const parameter, but due to dev_fwnode() it can't be satisfied. This has been reported by LKP when I tried to submit a wrapper: https://lore.kernel.org/linux-spi/20220921204520.23984-1-andriy.shevchenko@xxxxxxxxxxxxxxx/ Yes, I probably can drop const there, but it will be again awkward to see almost all APIs beneath using const and upper one without it for unclear (to the reader) reasons. > suggest to add another function, dev_fwnode_const() that is otherwise the > same except the argument as well as the return value are const. Perhaps this is the case, but does it mean we need to duplicate APIs when we know we don't modify data? Seems road to bloating the code for peanuts. > Or alternatively define it as a macro and use _Generic()? Yeah, I have the mixed feelings about _Generic for generic APIs because it requires to convert some stuff to macros when type checking of the parameters can be missed (if a target takes two or more of them). It might work here (we have a single parameter), but in general... -- With Best Regards, Andy Shevchenko
