On Mon, 22 Apr 2024 15:28:48 +0300
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> 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 ?
>
Good
