[PATCH 0/5] iio: proximity: hx9023s: firmware property, safety fixes, and ACPI support

[PATCH 0/5] iio: proximity: hx9023s: firmware property, safety fixes, and ACPI support

[Yasin Lee]

Hi,

This series contains a set of small fixes and improvements for the hx9023s
proximity sensor driver.

The changes include:

 - Fixing a potential out-of-bounds access when copying firmware data.
 - Avoiding a division-by-zero case when the sampling frequency is unspecified.
 - Allowing the firmware file name to be specified via firmware-name property,
   along with the corresponding DT binding update.
 - Adding ACPI device ID support to enable hx9023s on ACPI-based platforms.

All changes are independent but related to robustness and platform support,
and are grouped together for easier review.

Tested on a DT-based platform with firmware loading enabled.

Thanks for your time and review.

Best regards,
Yasin Lee

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
Yasin Lee (5):
      iio: proximity: hx9023s: fix out-of-bounds access when copying firmware
      iio: proximity: hx9023s: Protect against division by zero in set_samp_freq
      iio: proximity: hx9023s: support firmware-name property
      dt-bindings: iio: proximity: hx9023s: support firmware-name property
      iio: proximity: hx9023s: add ACPI support

 .../bindings/iio/proximity/tyhx,hx9023s.yaml       |  7 ++++++
 drivers/iio/proximity/hx9023s.c                    | 26 +++++++++++++++++-----
 2 files changed, 28 insertions(+), 5 deletions(-)
---
base-commit: c8bfb63c902678228a0a265e22a5f55404988a43
change-id: 20260209-upstream-20260219-a7af6d9a85ad

Best regards,
-- 
Yasin Lee <yasin.lee.x@gmail.com>

[PATCH 1/5] iio: proximity: hx9023s: fix out-of-bounds access when copying firmware

[Yasin Lee]

Initialize fw_size before copying firmware data into the flexible
array member to match the __counted_by() annotation. This fixes a
potential out-of-bounds access that could lead to a kernel crash.

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
 drivers/iio/proximity/hx9023s.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
index 2918dfc0df54..ad839db6b326 100644
--- a/drivers/iio/proximity/hx9023s.c
+++ b/drivers/iio/proximity/hx9023s.c
@@ -1034,9 +1034,8 @@ static int hx9023s_send_cfg(const struct firmware *fw, struct hx9023s_data *data
 	if (!bin)
 		return -ENOMEM;
 
-	memcpy(bin->data, fw->data, fw->size);
-
 	bin->fw_size = fw->size;
+	memcpy(bin->data, fw->data, bin->fw_size);
 	bin->fw_ver = bin->data[FW_VER_OFFSET];
 	bin->reg_count = get_unaligned_le16(bin->data + FW_REG_CNT_OFFSET);
 

-- 
2.43.0

Re: [PATCH 1/5] iio: proximity: hx9023s: fix out-of-bounds access when copying firmware

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 11:37:02AM +0800, Yasin Lee wrote:
> Initialize fw_size before copying firmware data into the flexible
> array member to match the __counted_by() annotation. This fixes a
> potential out-of-bounds access that could lead to a kernel crash.

Fixes tag?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/5] iio: proximity: hx9023s: fix out-of-bounds access when copying firmware

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:45 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:02AM +0800, Yasin Lee wrote:
> > Initialize fw_size before copying firmware data into the flexible
> > array member to match the __counted_by() annotation. This fixes a
> > potential out-of-bounds access that could lead to a kernel crash.
>
> Fixes tag?
>

This is a proactive fix for an original implementation issue I found
as maintainer.

> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH 1/5] iio: proximity: hx9023s: fix out-of-bounds access when copying firmware

[Jonathan Cameron]

On Wed, 11 Feb 2026 00:35:19 +0800
Yasin Lee <yasin.lee.x@gmail.com> wrote:

> On Mon, Feb 9, 2026 at 4:45 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Mon, Feb 09, 2026 at 11:37:02AM +0800, Yasin Lee wrote:  
> > > Initialize fw_size before copying firmware data into the flexible
> > > array member to match the __counted_by() annotation. This fixes a
> > > potential out-of-bounds access that could lead to a kernel crash.  
> >
> > Fixes tag?
> >  
> 
> This is a proactive fix for an original implementation issue I found
> as maintainer.
Hi Yasin,

I think there is a misunderstanding here.

The fixes tag requested reflects which patch originally introduced
the code with the bug. Its separate from Closes tag for which your
reply makes more sense.

The aim of a fixes tag is is to allow stable and individual vendors
who might be carrying your driver to figure out how far back
to backport a fix.

Jonathan

> 
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >  

[PATCH 2/5] iio: proximity: hx9023s: Protect against division by zero in set_samp_freq

[Yasin Lee]

Avoid division by zero when sampling frequency is unspecified by
falling back to a default 100ms sampling period.

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
 drivers/iio/proximity/hx9023s.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
index ad839db6b326..eb4902d18d74 100644
--- a/drivers/iio/proximity/hx9023s.c
+++ b/drivers/iio/proximity/hx9023s.c
@@ -719,7 +719,11 @@ static int hx9023s_set_samp_freq(struct hx9023s_data *data, int val, int val2)
 	struct device *dev = regmap_get_device(data->regmap);
 	unsigned int i, period_ms;
 
-	period_ms = div_u64(NANO, (val * MEGA + val2));
+	if (!val && !val2)
+		/* Fallback to a safe default sampling period */
+		period_ms = 100;
+	else
+		period_ms = div_u64(NANO, (val * MEGA + val2));
 
 	for (i = 0; i < ARRAY_SIZE(hx9023s_samp_freq_table); i++) {
 		if (period_ms == hx9023s_samp_freq_table[i])

-- 
2.43.0

Re: [PATCH 2/5] iio: proximity: hx9023s: Protect against division by zero in set_samp_freq

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 11:37:03AM +0800, Yasin Lee wrote:
> Avoid division by zero when sampling frequency is unspecified by
> falling back to a default 100ms sampling period.

Fixes tag?

...

> +	if (!val && !val2)

What's wrong with the positive conditional?

	if (val || val2)
		...
	else
		...

> +		/* Fallback to a safe default sampling period */
> +		period_ms = 100;
> +	else
> +		period_ms = div_u64(NANO, (val * MEGA + val2));

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/5] iio: proximity: hx9023s: Protect against division by zero in set_samp_freq

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:46 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:03AM +0800, Yasin Lee wrote:
> > Avoid division by zero when sampling frequency is unspecified by
> > falling back to a default 100ms sampling period.
>
> Fixes tag?
>
 This is a proactive fix for an original implementation issue I found
as maintainer.

> ...
>
> > +     if (!val && !val2)
>
> What's wrong with the positive conditional?
>
Agreed. Positive conditional will be present in v2.

>         if (val || val2)
>                 ...
>         else
>                 ...
>
> > +             /* Fallback to a safe default sampling period */
> > +             period_ms = 100;
> > +     else
> > +             period_ms = div_u64(NANO, (val * MEGA + val2));
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH 2/5] iio: proximity: hx9023s: Protect against division by zero in set_samp_freq

[Andy Shevchenko]

On Wed, Feb 11, 2026 at 12:29:15AM +0800, Yasin Lee wrote:
> On Mon, Feb 9, 2026 at 4:46 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Mon, Feb 09, 2026 at 11:37:03AM +0800, Yasin Lee wrote:
> > > Avoid division by zero when sampling frequency is unspecified by
> > > falling back to a default 100ms sampling period.
> >
> > Fixes tag?

>  This is a proactive fix for an original implementation issue I found as
>  maintainer.

Cool, any objections to use Fixes tag?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/5] iio: proximity: hx9023s: Protect against division by zero in set_samp_freq

[Yasin Lee]

On Wed, Feb 11, 2026 at 1:34 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Wed, Feb 11, 2026 at 12:29:15AM +0800, Yasin Lee wrote:
> > On Mon, Feb 9, 2026 at 4:46 PM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > >
> > > On Mon, Feb 09, 2026 at 11:37:03AM +0800, Yasin Lee wrote:
> > > > Avoid division by zero when sampling frequency is unspecified by
> > > > falling back to a default 100ms sampling period.
> > >
> > > Fixes tag?
>
> >  This is a proactive fix for an original implementation issue I found as
> >  maintainer.
>
> Cool, any objections to use Fixes tag?
>

Hi Andy,

You're absolutely right. I understand now - adding a Fixes tag is the proper way
to document bug origins, even for proactively discovered issues.
I will add the Fixes tag in v2. Thanks for the correction!

> --
> With Best Regards,
> Andy Shevchenko
>
>

[PATCH 3/5] iio: proximity: hx9023s: support firmware-name property

[Yasin Lee]

Add an optional firmware-name property to specify the firmware file.
If not provided, the driver falls back to the default firmware name.

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
 drivers/iio/proximity/hx9023s.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
index eb4902d18d74..b680b89956bd 100644
--- a/drivers/iio/proximity/hx9023s.c
+++ b/drivers/iio/proximity/hx9023s.c
@@ -1089,6 +1089,7 @@ static int hx9023s_probe(struct i2c_client *client)
 	struct device *dev = &client->dev;
 	struct iio_dev *indio_dev;
 	struct hx9023s_data *data;
+	const char *fw_name = "hx9023s.bin";
 	int ret;
 
 	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
@@ -1111,6 +1112,10 @@ static int hx9023s_probe(struct i2c_client *client)
 	if (ret)
 		return dev_err_probe(dev, ret, "regulator get failed\n");
 
+	ret = device_property_read_string(dev, "firmware-name", &fw_name);
+	if (ret && ret != -EINVAL)
+		return dev_err_probe(dev, ret, "failed to read firmware-name\n");
+
 	ret = hx9023s_id_check(indio_dev);
 	if (ret)
 		return dev_err_probe(dev, ret, "id check failed\n");
@@ -1126,7 +1131,7 @@ static int hx9023s_probe(struct i2c_client *client)
 	if (ret)
 		return dev_err_probe(dev, ret, "channel config failed\n");
 
-	ret = request_firmware_nowait(THIS_MODULE, true, "hx9023s.bin", dev,
+	ret = request_firmware_nowait(THIS_MODULE, true, fw_name, dev,
 				      GFP_KERNEL, data, hx9023s_cfg_update);
 	if (ret)
 		return dev_err_probe(dev, ret, "reg config failed\n");

-- 
2.43.0

Re: [PATCH 3/5] iio: proximity: hx9023s: support firmware-name property

[Krzysztof Kozlowski]

On Mon, Feb 09, 2026 at 11:37:04AM +0800, Yasin Lee wrote:
> Add an optional firmware-name property to specify the firmware file.
> If not provided, the driver falls back to the default firmware name.
> 
> Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
> ---
>  drivers/iio/proximity/hx9023s.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
> index eb4902d18d74..b680b89956bd 100644
> --- a/drivers/iio/proximity/hx9023s.c
> +++ b/drivers/iio/proximity/hx9023s.c
> @@ -1089,6 +1089,7 @@ static int hx9023s_probe(struct i2c_client *client)
>  	struct device *dev = &client->dev;
>  	struct iio_dev *indio_dev;
>  	struct hx9023s_data *data;
> +	const char *fw_name = "hx9023s.bin";
>  	int ret;
>  
>  	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> @@ -1111,6 +1112,10 @@ static int hx9023s_probe(struct i2c_client *client)
>  	if (ret)
>  		return dev_err_probe(dev, ret, "regulator get failed\n");
>  
> +	ret = device_property_read_string(dev, "firmware-name", &fw_name);

Incorrect order of patches, see submitting patches in DT dir about the
order - documentation always comes first. This is here an undocumented ABI.

Best regards,
Krzysztof

Re: [PATCH 3/5] iio: proximity: hx9023s: support firmware-name property

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:02 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:04AM +0800, Yasin Lee wrote:
> > Add an optional firmware-name property to specify the firmware file.
> > If not provided, the driver falls back to the default firmware name.
> >
> > Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
> > ---
> >  drivers/iio/proximity/hx9023s.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
> > index eb4902d18d74..b680b89956bd 100644
> > --- a/drivers/iio/proximity/hx9023s.c
> > +++ b/drivers/iio/proximity/hx9023s.c
> > @@ -1089,6 +1089,7 @@ static int hx9023s_probe(struct i2c_client *client)
> >       struct device *dev = &client->dev;
> >       struct iio_dev *indio_dev;
> >       struct hx9023s_data *data;
> > +     const char *fw_name = "hx9023s.bin";
> >       int ret;
> >
> >       indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> > @@ -1111,6 +1112,10 @@ static int hx9023s_probe(struct i2c_client *client)
> >       if (ret)
> >               return dev_err_probe(dev, ret, "regulator get failed\n");
> >
> > +     ret = device_property_read_string(dev, "firmware-name", &fw_name);
>
> Incorrect order of patches, see submitting patches in DT dir about the
> order - documentation always comes first. This is here an undocumented ABI.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
You're absolutely right, my apologies. I'll resend the series with the
correct order.

Best regards,
Yasin

Re: [PATCH 3/5] iio: proximity: hx9023s: support firmware-name property

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 11:37:04AM +0800, Yasin Lee wrote:
> Add an optional firmware-name property to specify the firmware file.
> If not provided, the driver falls back to the default firmware name.

...

>  	struct device *dev = &client->dev;
>  	struct iio_dev *indio_dev;
>  	struct hx9023s_data *data;

> +	const char *fw_name = "hx9023s.bin";

Preserve reversed xmas tree order.
And looking at the usage, please split the definition and assignment.

>  	int ret;

...

> +	ret = device_property_read_string(dev, "firmware-name", &fw_name);
> +	if (ret && ret != -EINVAL)

Why is this special error code check?

> +		return dev_err_probe(dev, ret, "failed to read firmware-name\n");

	fw_name = "...";
	device_property_read_string(dev, "firmware-name", &fw_name);

I believe if wondering one can get a debug information from
request_firmware_nowait() on what firmware file has been actually used.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/5] iio: proximity: hx9023s: support firmware-name property

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:50 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:04AM +0800, Yasin Lee wrote:
> > Add an optional firmware-name property to specify the firmware file.
> > If not provided, the driver falls back to the default firmware name.
>
> ...
>
> >       struct device *dev = &client->dev;
> >       struct iio_dev *indio_dev;
> >       struct hx9023s_data *data;
>
> > +     const char *fw_name = "hx9023s.bin";
>
> Preserve reversed xmas tree order.
> And looking at the usage, please split the definition and assignment.
>
Ack. Will fix this in v2.

> >       int ret;
>
> ...
>
> > +     ret = device_property_read_string(dev, "firmware-name", &fw_name);
> > +     if (ret && ret != -EINVAL)
>
> Why is this special error code check?
>
Good point. I will simplify the logic as you suggested and remove the
redundant check.

> > +             return dev_err_probe(dev, ret, "failed to read firmware-name\n");
>
>         fw_name = "...";
>         device_property_read_string(dev, "firmware-name", &fw_name);
>
> I believe if wondering one can get a debug information from
> request_firmware_nowait() on what firmware file has been actually used.
>
Agreed. Thanks.

> --
> With Best Regards,
> Andy Shevchenko
>
>

[PATCH 4/5] dt-bindings: iio: proximity: hx9023s: support firmware-name property

[Yasin Lee]

Allow specifying the firmware file name via device tree.

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
 Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
index 64ce8bc8bd36..7e516fc011c6 100644
--- a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
@@ -28,6 +28,12 @@ properties:
 
   vdd-supply: true
 
+  firmware-name:
+    description:
+      Name of the firmware file to be requested by the driver using
+      the firmware loader interface.
+    maxItems: 1
+
   "#address-cells":
     const: 1
 
@@ -65,6 +71,7 @@ examples:
         interrupt-parent = <&pio>;
         interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
         vdd-supply = <&pp1800_prox>;
+        firmware-name = "hx9023s.bin";
 
         #address-cells = <1>;
         #size-cells = <0>;

-- 
2.43.0

Re: [PATCH 4/5] dt-bindings: iio: proximity: hx9023s: support firmware-name property

[Krzysztof Kozlowski]

On Mon, Feb 09, 2026 at 11:37:05AM +0800, Yasin Lee wrote:
> Allow specifying the firmware file name via device tree.

For what purpose? What's in the firmware?

> 
> Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
> ---
>  Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> index 64ce8bc8bd36..7e516fc011c6 100644
> --- a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> +++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> @@ -28,6 +28,12 @@ properties:
>  
>    vdd-supply: true
>  
> +  firmware-name:
> +    description:
> +      Name of the firmware file to be requested by the driver using
> +      the firmware loader interface.

Drop description, obvious. It cannot be anything else.

Best regards,
Krzysztof

Re: [PATCH 4/5] dt-bindings: iio: proximity: hx9023s: support firmware-name property

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:01 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:05AM +0800, Yasin Lee wrote:
> > Allow specifying the firmware file name via device tree.
>
> For what purpose? What's in the firmware?
>

Hi Krzysztof,

Thanks for the review.

The firmware contains device-specific configuration data required to
properly initialize the internal sensing engine of the hx9023s.

Although the silicon is identical, different board designs use different
electrode layouts and mechanical structures, which require different
calibration and register configuration tables for correct operation.
Without the appropriate configuration data, the sensor does not function
as intended on a given hardware design.

The default firmware name remains unchanged for existing platforms.
The firmware-name property is intended only to allow selecting the
correct hardware-specific configuration when the physical design differs.

Best regards,
Yasin Lee

> >
> > Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> > index 64ce8bc8bd36..7e516fc011c6 100644
> > --- a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> > +++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
> > @@ -28,6 +28,12 @@ properties:
> >
> >    vdd-supply: true
> >
> > +  firmware-name:
> > +    description:
> > +      Name of the firmware file to be requested by the driver using
> > +      the firmware loader interface.
>
> Drop description, obvious. It cannot be anything else.
>

Agreed. Thanks.

> Best regards,
> Krzysztof
>

[PATCH 5/5] iio: proximity: hx9023s: add ACPI support

[Yasin Lee]

Extend the hx9023s driver to support ACPI matching by adding TYHX9023
to the ACPI device ID table.

Signed-off-by: Yasin Lee <yasin.lee.x@gmail.com>
---
 drivers/iio/proximity/hx9023s.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
index b680b89956bd..6bf5a02c3615 100644
--- a/drivers/iio/proximity/hx9023s.c
+++ b/drivers/iio/proximity/hx9023s.c
@@ -8,6 +8,7 @@
  * http://www.tianyihexin.com/ueditor/php/upload/file/20240614/1718336303992081.pdf
  */
 
+#include <linux/acpi.h>
 #include <linux/array_size.h>
 #include <linux/bitfield.h>
 #include <linux/bitops.h>
@@ -1106,7 +1107,7 @@ static int hx9023s_probe(struct i2c_client *client)
 
 	ret = hx9023s_property_get(data);
 	if (ret)
-		return dev_err_probe(dev, ret, "dts phase failed\n");
+		return dev_err_probe(dev, ret, "failed to get device properties\n");
 
 	ret = devm_regulator_get_enable(dev, "vdd");
 	if (ret)
@@ -1195,6 +1196,12 @@ static int hx9023s_resume(struct device *dev)
 static DEFINE_SIMPLE_DEV_PM_OPS(hx9023s_pm_ops, hx9023s_suspend,
 				hx9023s_resume);
 
+static const struct acpi_device_id hx9023s_acpi_match[] = {
+	{ "TYHX9023", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, hx9023s_acpi_match);
+
 static const struct of_device_id hx9023s_of_match[] = {
 	{ .compatible = "tyhx,hx9023s" },
 	{ }
@@ -1210,6 +1217,7 @@ MODULE_DEVICE_TABLE(i2c, hx9023s_id);
 static struct i2c_driver hx9023s_driver = {
 	.driver = {
 		.name = "hx9023s",
+		.acpi_match_table = hx9023s_acpi_match,
 		.of_match_table = hx9023s_of_match,
 		.pm = &hx9023s_pm_ops,
 

-- 
2.43.0

Re: [PATCH 5/5] iio: proximity: hx9023s: add ACPI support

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 11:37:06AM +0800, Yasin Lee wrote:
> Extend the hx9023s driver to support ACPI matching by adding TYHX9023
> to the ACPI device ID table.

...

> +#include <linux/acpi.h>

Why?

...

> +static const struct acpi_device_id hx9023s_acpi_match[] = {
> +	{ "TYHX9023", 0 },

No ', 0' part, please.

> +	{ }
> +};

...

And since you added a new ID, please add to the commit message if this is
in a wild (and hence the vendor and model of the device that it has) and
also an excerpt from DSDT to the comment block (after '---' line).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 5/5] iio: proximity: hx9023s: add ACPI support

[Yasin Lee]

On Mon, Feb 9, 2026 at 4:44 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Feb 09, 2026 at 11:37:06AM +0800, Yasin Lee wrote:
> > Extend the hx9023s driver to support ACPI matching by adding TYHX9023
> > to the ACPI device ID table.
>
> ...
>
> > +#include <linux/acpi.h>
>
> Why?
>

Ack. I Will remove this.

> ...
>
> > +static const struct acpi_device_id hx9023s_acpi_match[] = {
> > +     { "TYHX9023", 0 },
>
> No ', 0' part, please.
>

Agreed. Thanks.

> > +     { }
> > +};
>
> ...
>
> And since you added a new ID, please add to the commit message if this is
> in a wild (and hence the vendor and model of the device that it has) and
> also an excerpt from DSDT to the comment block (after '---' line).
>

Hi Andy,

Thanks for your comments.
Regarding the ACPI ID "TYHX9023", it is for a product currently in the
late stages of development. We are in the process of formally
registering the "TYHX" Vendor ID with the UEFI Forum.
To ensure everything is compliant, I will withdraw this ACPI support
patch (5/5) for now. I will resubmit it as a standalone patch once the
ID registration is officially confirmed and I can provide the verified
DSDT evidence.
I will send v2 for the rest of the series (1-4) with your other
suggestions addressed.

Best Regards,
Yasin

> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH 5/5] iio: proximity: hx9023s: add ACPI support

[Andy Shevchenko]

On Wed, Feb 11, 2026 at 11:54:11AM +0800, Yasin Lee wrote:
> On Mon, Feb 9, 2026 at 4:44 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Mon, Feb 09, 2026 at 11:37:06AM +0800, Yasin Lee wrote:

...

> > > +#include <linux/acpi.h>
> >
> > Why?
> 
> Ack. I Will remove this.

Hmm... Don't you need to add mod_devicetable.h?

...

> > And since you added a new ID, please add to the commit message if this is
> > in a wild (and hence the vendor and model of the device that it has) and
> > also an excerpt from DSDT to the comment block (after '---' line).

> Thanks for your comments.
> Regarding the ACPI ID "TYHX9023", it is for a product currently in the
> late stages of development. We are in the process of formally
> registering the "TYHX" Vendor ID with the UEFI Forum.
> To ensure everything is compliant, I will withdraw this ACPI support
> patch (5/5) for now. I will resubmit it as a standalone patch once the
> ID registration is officially confirmed and I can provide the verified
> DSDT evidence.

Thanks! That is the best approach, glad you followed the process!

> I will send v2 for the rest of the series (1-4) with your other
> suggestions addressed.

Sounds good.

-- 
With Best Regards,
Andy Shevchenko