On Fri, Jan 7, 2022 at 6:14 AM Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> wrote: > On Thu, Jan 6, 2022 at 10:33 PM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > On Thu, Jan 6, 2022 at 6:13 AM Kai-Heng Feng > > <kai.heng.feng@xxxxxxxxxxxxx> wrote: ... > > > - Change the ID to follow ACPI Spec > > > > Is there any evidence Texas Instrument allocated this ID, or you just > > created it yourself? > > Please, add an excerpt from email from them to confirm this. > > Sure, let me ask our customer to provide the excerpt. Thanks! This is basically the most important point of review. ... > > > + .acpi_match_table = ACPI_PTR(hdc100x_acpi_match), > > > > It's the wrong usage of ACPI_PTR(). > > Can you please explain a bit more? > > ACPI_PTR() turns the value to NULL when ACPI is not enabled, seems to > be correct? > Not to mention most other drivers also use ACPI_PTR() for acpi_match_table. ACPI_PTR() needs to be used along with the ugly ifdeffery (#ifdef CONFIG_ACPI). Rather not doing both simplifies the code and avoids unneeded macros or attributes (as you suggested below). > > > }, > > > > All the comments are applicable to all your patches. Some of them I > > already commented on and even kbuild bot has sent you a complaint. > > That one should be solved by adding __maybe_unused to acpi_device_id array. This is illogical to add an ID table that we will know may be unused, don't you think? Better to always provide it. Yes, the downside is few dozens of bytes in the module even if it doesn't support, but OTOH this information still may be useful for users to know what devices the certain module might support. -- With Best Regards, Andy Shevchenko
