| Message ID | 20220106041257.927664-1-kai.heng.feng@canonical.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] iio: humidity: hdc100x: Add ACPI HID table | expand |
On Thu, Jan 6, 2022 at 6:13 AM Kai-Heng Feng <kai.heng.feng@canonical.com> wrote: > > x86 boards may use ACPI HID "TXN1010" to for hdc100x device. to for --> for the > So add an ACPI match table for that accordingly. ... > - 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. ... > +static const struct acpi_device_id __maybe_unused hdc100x_acpi_match[] = { > + { "TXN1010" }, > + { }, No comma is needed. > +}; > + No blank line is needed. > +MODULE_DEVICE_TABLE(acpi, hdc100x_acpi_match); ... > + .acpi_match_table = ACPI_PTR(hdc100x_acpi_match), It's the wrong usage of ACPI_PTR(). > }, 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.
On Thu, Jan 6, 2022 at 10:33 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Jan 6, 2022 at 6:13 AM Kai-Heng Feng > <kai.heng.feng@canonical.com> wrote: > > > > x86 boards may use ACPI HID "TXN1010" to for hdc100x device. > > to for --> for the Will correct it. > > > So add an ACPI match table for that accordingly. > > ... > > > - 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. > > ... > > > +static const struct acpi_device_id __maybe_unused hdc100x_acpi_match[] = { > > + { "TXN1010" }, > > > + { }, > > No comma is needed. Got it. > > > +}; > > > + > > No blank line is needed. Will update. > > > +MODULE_DEVICE_TABLE(acpi, hdc100x_acpi_match); > > ... > > > + .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. > > > }, > > 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. Kai-Heng > > -- > With Best Regards, > Andy Shevchenko
On Fri, Jan 7, 2022 at 6:14 AM Kai-Heng Feng <kai.heng.feng@canonical.com> wrote: > On Thu, Jan 6, 2022 at 10:33 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Jan 6, 2022 at 6:13 AM Kai-Heng Feng > > <kai.heng.feng@canonical.com> 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.
diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c index 9e0fce917ce4c..c6c71ca1d2017 100644 --- a/drivers/iio/humidity/hdc100x.c +++ b/drivers/iio/humidity/hdc100x.c @@ -417,10 +417,18 @@ static const struct of_device_id hdc100x_dt_ids[] = { }; MODULE_DEVICE_TABLE(of, hdc100x_dt_ids); +static const struct acpi_device_id __maybe_unused hdc100x_acpi_match[] = { + { "TXN1010" }, + { }, +}; + +MODULE_DEVICE_TABLE(acpi, hdc100x_acpi_match); + static struct i2c_driver hdc100x_driver = { .driver = { .name = "hdc100x", .of_match_table = hdc100x_dt_ids, + .acpi_match_table = ACPI_PTR(hdc100x_acpi_match), }, .probe = hdc100x_probe, .id_table = hdc100x_id,
x86 boards may use ACPI HID "TXN1010" to for hdc100x device. So add an ACPI match table for that accordingly. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> --- v2: - Change the ID to follow ACPI Spec - Add __maybe_unused to avoid compiler warning drivers/iio/humidity/hdc100x.c | 8 ++++++++ 1 file changed, 8 insertions(+)