On Mon, Apr 22, 2024 at 2:45 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> On 4/22/24 1:33 PM, Andy Shevchenko wrote:
> > On Mon, Apr 22, 2024 at 11:24 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> >> On 4/22/24 9:55 AM, Andy Shevchenko wrote:
> >>> Wed, Apr 17, 2024 at 06:46:12PM +0200, Hans de Goede kirjoitti:
...
> >>> I have briefly looked into this and I like this, except the part of the big
> >>> function being in the header. Why? Why can't it be in a C-file?
> >>>
> >>> Note, 3 users justify very well to me that shared code, should be shared in
> >>> binary as well. (I.o.w. you may argue that IRL there will be no more than
> >>> one of such device connected, but in case of DIY and prototyping it might
> >>> still be the use case.)
> >>
> >> It is only 1 function and it is not that big. IMHO the static inline
> >> in a header solution here is much better then making this a separate .ko
> >> file with all the associated overhead.
> >
> > Look how the i8042 RTC header became a disaster. :-)
> > Nevertheless, this can be part of the IIO core for the ACPI enabled
> > kernels. Which eliminates a need for a separate module.
>
> Putting this in the IIO core, with an iio-prefix, so say something like:
>
> #ifdef CONFIG_ACPI
> bool iio_read_acpi_mount_matrix(struct device *dev, struct iio_mount_matrix *matrix, const char *method_name);
> #else
> static inline bool
> iio_read_acpi_mount_matrix(struct device *dev, struct iio_mount_matrix *matrix, const char *method_name)
> {
> return false;
> }
>
> in include/linux/iio/iio.h ?
Yes, like SPI, I²C, etc. do in similar cases.
> works for me and that also avoids Jonathan's worry about using an acpi_
> prefix in iio code.
>
> Jonathan how does that sound to you ?
--
With Best Regards,
Andy Shevchenko
