On Thu, May 15, 2025 at 11:58:33AM +0300, Andy Shevchenko wrote: > On Thu, May 15, 2025 at 11:47:27AM +0300, Mika Westerberg wrote: > > On Thu, May 15, 2025 at 11:41:59AM +0300, Andy Shevchenko wrote: > > > On Thu, May 15, 2025 at 11:34:51AM +0300, Mika Westerberg wrote: > > > > On Thu, May 15, 2025 at 11:04:22AM +0300, Andy Shevchenko wrote: > > > > > On Wed, May 14, 2025 at 06:59:55PM +0300, Mika Westerberg wrote: > > ... > > > > > > That's might be the next step to have for all of them, but these are ACPI > > > > > specific. In any case they can't be put to gpiolib-quirks.c due to module > > > > > parameters. If we do that we will need a dirty hack to support old module > > > > > parameters (see 8250 how it's done there, and even author of that didn't like > > > > > the approach). > > > > > > > > Hmm, how does it affect module paremeters? I thought they are > > > > gpiolib.something as all these object files are linked to it? > > > > > > gpiolib_acpi.FOO because the object file is gpiolib-acpi.o. > > > > Ah okay. > > > > > > At least can we drop the gpiolib-acpi-core.c rename? > > > > > > Unfortunately no due to the above. > > > > This does not work? > > > > gpiolib-acpi-y := gpiolib-acpi.o gpiolib-acpi-quirks.o > > No. You can't use the same name on left and right parts. I see :( Okay then I guess there are no other options than name it like this. [ Ideally we would drop the while gpiolib- prefix from all these so you have acpi.c, sysfs.c and so on without the redundancy but that's outside of scope of this work anyways ;-) ] Acked-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
