[PATCH] pinctrl: mcp23s08: reject devices without match data

[PATCH] pinctrl: mcp23s08: reject devices without match data

[Jiale Yao]

A device bound through driver_override need not match an entry in the
driver tables. In that case spi_get_device_match_data() returns NULL,
but mcp23s08_probe() later passes the result to the regmap setup and
dereferences it while setting up each device.

Reject devices without match data before reading device properties.

Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify probe()/mcp23s08_spi_regmap_init()")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
index bacebcff67ef..926034fcd512 100644
--- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
+++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
@@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
 	u8 v;
 
 	info = spi_get_device_match_data(spi);
+	if (!info)
+		return -ENODATA;
 
 	ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
 	if (ret) {
-- 
2.34.1

RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Biju Das]

Hi,

> -----Original Message-----
> From: Jiale Yao <yaojiale02@163.com>
> Sent: 25 September 2026 14:38
> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match data
> 
> A device bound through driver_override need not match an entry in the driver tables. In that case
> spi_get_device_match_data() returns NULL, but mcp23s08_probe() later passes the result to the regmap
> setup and dereferences it while setting up each device.

I believe this is an invalid use case as the user trying driver_override
and the probe returns error. Am I missing anything here?

Can you please prepare a patch that makes the driver probe success by using driver_override
Feature? Also please share some logs to see how it works in real device

Cheers,
Biju

> 
> Reject devices without match data before reading device properties.
> 
> Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify probe()/mcp23s08_spi_regmap_init()")
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
>  drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> index bacebcff67ef..926034fcd512 100644
> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> @@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
>  	u8 v;
> 
>  	info = spi_get_device_match_data(spi);
> +	if (!info)
> +		return -ENODATA;
> 
>  	ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
>  	if (ret) {
> --
> 2.34.1

Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[jiale yao]

Hi Biju,

At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>Hi,
>
>> -----Original Message-----
>> From: Jiale Yao <yaojiale02@163.com>
>> Sent: 25 September 2026 14:38
>> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match data
>> 
>> A device bound through driver_override need not match an entry in the driver tables. In that case
>> spi_get_device_match_data() returns NULL, but mcp23s08_probe() later passes the result to the regmap
>> setup and dereferences it while setting up each device.
>
>I believe this is an invalid use case as the user trying driver_override
>and the probe returns error. Am I missing anything here?

Yes, my commit message was not clear enough. This patch is intended to fix
a regression introduced by commit 2e44555b05c0, rather than to make an
unmatched device probe successfully through driver_override.

Before that commit, missing match data effectively resulted in type 0,
which fell through to the default switch case and returned -EINVAL.
Commit 2e44555b05c0 replaced the type value with an info pointer, but the
SPI path missed the corresponding NULL check before dereferencing
info->type. The I2C path preserved the previous error handling with an
explicit NULL check after the same conversion.

Consequently, an unmatched device bound through driver_override used to
fail cleanly. It can now cause a NULL pointer dereference when a valid
spi-present-mask property is present. This patch restores the previous
failure behavior.

>
>Can you please prepare a patch that makes the driver probe success by using driver_override
>Feature? Also please share some logs to see how it works in real device
>
>Cheers,
>Biju
>
>> 
>> Reject devices without match data before reading device properties.
>> 
>> Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify probe()/mcp23s08_spi_regmap_init()")
>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> ---
>>  drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> index bacebcff67ef..926034fcd512 100644
>> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> @@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
>>  	u8 v;
>> 
>>  	info = spi_get_device_match_data(spi);
>> +	if (!info)
>> +		return -ENODATA;
>> 
>>  	ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
>>  	if (ret) {
>> --
>> 2.34.1

Cheers,
Jiale

Re:Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[jiale yao]

At 2026-09-26 18:23:42, "jiale yao" <19888972804@163.com> wrote:
>Hi Biju,
>
>At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>>Hi,
>>
>>> -----Original Message-----
>>> From: Jiale Yao <yaojiale02@163.com>
>>> Sent: 25 September 2026 14:38
>>> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match data
>>> 
>>> A device bound through driver_override need not match an entry in the driver tables. In that case
>>> spi_get_device_match_data() returns NULL, but mcp23s08_probe() later passes the result to the regmap
>>> setup and dereferences it while setting up each device.
>>
>>I believe this is an invalid use case as the user trying driver_override
>>and the probe returns error. Am I missing anything here?
>
>Yes, my commit message was not clear enough. This patch is intended to fix
>a regression introduced by commit 2e44555b05c0, rather than to make an
>unmatched device probe successfully through driver_override.
>
>Before that commit, missing match data effectively resulted in type 0,
>which fell through to the default switch case and returned -EINVAL.
>Commit 2e44555b05c0 replaced the type value with an info pointer, but the
>SPI path missed the corresponding NULL check before dereferencing
>info->type. The I2C path preserved the previous error handling with an
>explicit NULL check after the same conversion.

Just like.
---
+       info = i2c_get_match_data(client);
+       if (!info)
+               return dev_err_probe(dev, -EINVAL, "invalid device type\n");
---
The return value of spi_get_device_match_data should be check also.

>
>Consequently, an unmatched device bound through driver_override used to
>fail cleanly. It can now cause a NULL pointer dereference when a valid
>spi-present-mask property is present. This patch restores the previous
>failure behavior.
>
>>
>>Can you please prepare a patch that makes the driver probe success by using driver_override
>>Feature? Also please share some logs to see how it works in real device
>>
>>Cheers,
>>Biju
>>
>>> 
>>> Reject devices without match data before reading device properties.
>>> 
>>> Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify probe()/mcp23s08_spi_regmap_init()")
>>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>>> ---
>>>  drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>>> index bacebcff67ef..926034fcd512 100644
>>> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>>> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>>> @@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
>>>  	u8 v;
>>> 
>>>  	info = spi_get_device_match_data(spi);
>>> +	if (!info)
>>> +		return -ENODATA;
>>> 
>>>  	ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
>>>  	if (ret) {
>>> --
>>> 2.34.1
>
>Cheers,
>Jiale
>

RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Biju Das]

Hi jiale yao,

> -----Original Message-----
> From: jiale yao <19888972804@163.com>
> Sent: 26 September 2026 11:24
> Subject: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data
> 
> [You don't often get email from 19888972804@163.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Biju,
> 
> At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >Hi,
> >
> >> -----Original Message-----
> >> From: Jiale Yao <yaojiale02@163.com>
> >> Sent: 25 September 2026 14:38
> >> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match data
> >>
> >> A device bound through driver_override need not match an entry in the
> >> driver tables. In that case
> >> spi_get_device_match_data() returns NULL, but mcp23s08_probe() later
> >> passes the result to the regmap setup and dereferences it while setting up each device.
> >
> >I believe this is an invalid use case as the user trying
> >driver_override and the probe returns error. Am I missing anything here?
> 
> Yes, my commit message was not clear enough. This patch is intended to fix a regression introduced by
> commit 2e44555b05c0, rather than to make an unmatched device probe successfully through driver_override.
> 
> Before that commit, missing match data effectively resulted in type 0, which fell through to the default
> switch case and returned -EINVAL.
> Commit 2e44555b05c0 replaced the type value with an info pointer, but the SPI path missed the
> corresponding NULL check before dereferencing
> info->type. The I2C path preserved the previous error handling with an
> explicit NULL check after the same conversion.

you are testing the driver with driver_override and your patch makes driver
Probe failure. I do not understand the test case you are trying to
achieve with driver_override.

Can you please share some logs with driver_override that you planned to test?

Cheers,
Biju 

> 
> Consequently, an unmatched device bound through driver_override used to fail cleanly. It can now cause a
> NULL pointer dereference when a valid spi-present-mask property is present. This patch restores the
> previous failure behavior.
> 
> >
> >Can you please prepare a patch that makes the driver probe success by
> >using driver_override Feature? Also please share some logs to see how
> >it works in real device
> >
> >Cheers,
> >Biju
> >
> >>
> >> Reject devices without match data before reading device properties.
> >>
> >> Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify
> >> probe()/mcp23s08_spi_regmap_init()")
> >> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> >> ---
> >>  drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> >> b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> >> index bacebcff67ef..926034fcd512 100644
> >> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> >> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> >> @@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
> >>      u8 v;
> >>
> >>      info = spi_get_device_match_data(spi);
> >> +    if (!info)
> >> +            return -ENODATA;
> >>
> >>      ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
> >>      if (ret) {
> >> --
> >> 2.34.1
> 
> Cheers,
> Jiale

Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[jiale yao]

At 2026-09-28 14:03:46, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>Hi jiale yao,
>
>> -----Original Message-----
>> From: jiale yao <19888972804@163.com>
>> Sent: 26 September 2026 11:24
>> Subject: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data
>> 
>> [You don't often get email from 19888972804@163.com. Learn why this is important at
>> https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> Hi Biju,
>> 
>> At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>> >Hi,
>> >
>> >> -----Original Message-----
>> >> From: Jiale Yao <yaojiale02@163.com>
>> >> Sent: 25 September 2026 14:38
>> >> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match data
>> >>
>> >> A device bound through driver_override need not match an entry in the
>> >> driver tables. In that case
>> >> spi_get_device_match_data() returns NULL, but mcp23s08_probe() later
>> >> passes the result to the regmap setup and dereferences it while setting up each device.
>> >
>> >I believe this is an invalid use case as the user trying
>> >driver_override and the probe returns error. Am I missing anything here?
>> 
>> Yes, my commit message was not clear enough. This patch is intended to fix a regression introduced by
>> commit 2e44555b05c0, rather than to make an unmatched device probe successfully through driver_override.
>> 
>> Before that commit, missing match data effectively resulted in type 0, which fell through to the default
>> switch case and returned -EINVAL.
>> Commit 2e44555b05c0 replaced the type value with an info pointer, but the SPI path missed the
>> corresponding NULL check before dereferencing
>> info->type. The I2C path preserved the previous error handling with an
>> explicit NULL check after the same conversion.
>
>you are testing the driver with driver_override and your patch makes driver
>Probe failure. I do not understand the test case you are trying to
>achieve with driver_override.
>
>Can you please share some logs with driver_override that you planned to test?
>
>Cheers,
>Biju 
>
>> 
>> Consequently, an unmatched device bound through driver_override used to fail cleanly. It can now cause a
>> NULL pointer dereference when a valid spi-present-mask property is present. This patch restores the
>> previous failure behavior.
>> 
>> >
>> >Can you please prepare a patch that makes the driver probe success by
>> >using driver_override Feature? Also please share some logs to see how
>> >it works in real device
>> >
>> >Cheers,
>> >Biju


The test is NOT intended to make an unmatched device probe successfully.
driver_override permits an explicit probe attempt; it does not guarantee that probe must succeed.
The driver must still reject unsupported devices safely. The bug is that it currently crashes instead of returning an error.

I reproduced this deterministically with KASAN on arm64 QEMU.
The SPI device has an unmatched compatible and a valid microchip,spi-present-mask property, and is then bound with:

echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind

KASAN reports:

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
pc : mcp23s08_probe+0x2f8/0x944
lr : mcp23s08_probe+0x190/0x944
Call trace:
 mcp23s08_probe+0x2f8/0x944 (P)
 spi_probe+0x1c0/0x2d8
 really_probe+0x17c/0x5b8
 __driver_probe_device+0x28c/0x350
 device_driver_attach+0xa0/0x18c
 bind_store+0xc4/0x13c
 drv_attr_store+0x60/0x9c
 sysfs_kf_write+0x170/0x1e8
 kernfs_fop_write_iter+0x298/0x404
 vfs_write+0x648/0x8cc
 ksys_write+0xf0/0x1e0
 __arm64_sys_write+0x70/0xa0
 invoke_syscall+0x70/0x24c


spi_get_device_match_data() returns NULL, and mcp23s08_spi_regmap_init() later dereferences info->type at offset 16.

The patch only guarantees safety; it does not attempt to support unmatched hardware through driver_override.

Cheers,
Jiale

>> >
>> >>
>> >> Reject devices without match data before reading device properties.
>> >>
>> >> Fixes: 2e44555b05c0 ("pinctrl: mcp23s08: Simplify
>> >> probe()/mcp23s08_spi_regmap_init()")
>> >> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> >> ---
>> >>  drivers/pinctrl/pinctrl-mcp23s08_spi.c | 2 ++
>> >>  1 file changed, 2 insertions(+)
>> >>
>> >> diff --git a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> >> b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> >> index bacebcff67ef..926034fcd512 100644
>> >> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> >> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
>> >> @@ -146,6 +146,8 @@ static int mcp23s08_probe(struct spi_device *spi)
>> >>      u8 v;
>> >>
>> >>      info = spi_get_device_match_data(spi);
>> >> +    if (!info)
>> >> +            return -ENODATA;
>> >>
>> >>      ret = device_property_read_u8(dev, "microchip,spi-present-mask", &v);
>> >>      if (ret) {
>> >> --
>> >> 2.34.1
>> 
>> Cheers,
>> Jiale

RE: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Biju Das]

> -----Original Message-----
> From: jiale yao <19888972804@163.com>
> Sent: 28 September 2026 08:25
> To: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Linus Walleij <linusw@kernel.org>; Andy Shevchenko <andriy.shevchenko@linux.intel.com>; linux-
> gpio@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data
> 
> [You don't often get email from 19888972804@163.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> At 2026-09-28 14:03:46, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >Hi jiale yao,
> >
> >> -----Original Message-----
> >> From: jiale yao <19888972804@163.com>
> >> Sent: 26 September 2026 11:24
> >> Subject: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without
> >> match data
> >>
> >> [You don't often get email from 19888972804@163.com. Learn why this
> >> is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Hi Biju,
> >>
> >> At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >> >Hi,
> >> >
> >> >> -----Original Message-----
> >> >> From: Jiale Yao <yaojiale02@163.com>
> >> >> Sent: 25 September 2026 14:38
> >> >> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match
> >> >> data
> >> >>
> >> >> A device bound through driver_override need not match an entry in
> >> >> the driver tables. In that case
> >> >> spi_get_device_match_data() returns NULL, but mcp23s08_probe()
> >> >> later passes the result to the regmap setup and dereferences it while setting up each device.
> >> >
> >> >I believe this is an invalid use case as the user trying
> >> >driver_override and the probe returns error. Am I missing anything here?
> >>
> >> Yes, my commit message was not clear enough. This patch is intended
> >> to fix a regression introduced by commit 2e44555b05c0, rather than to make an unmatched device probe
> successfully through driver_override.
> >>
> >> Before that commit, missing match data effectively resulted in type
> >> 0, which fell through to the default switch case and returned -EINVAL.
> >> Commit 2e44555b05c0 replaced the type value with an info pointer, but
> >> the SPI path missed the corresponding NULL check before dereferencing
> >> info->type. The I2C path preserved the previous error handling with
> >> info->an
> >> explicit NULL check after the same conversion.
> >
> >you are testing the driver with driver_override and your patch makes
> >driver Probe failure. I do not understand the test case you are trying
> >to achieve with driver_override.
> >
> >Can you please share some logs with driver_override that you planned to test?
> >
> >Cheers,
> >Biju
> >
> >>
> >> Consequently, an unmatched device bound through driver_override used
> >> to fail cleanly. It can now cause a NULL pointer dereference when a
> >> valid spi-present-mask property is present. This patch restores the previous failure behavior.
> >>
> >> >
> >> >Can you please prepare a patch that makes the driver probe success
> >> >by using driver_override Feature? Also please share some logs to see
> >> >how it works in real device
> >> >
> >> >Cheers,
> >> >Biju
> 
> 
> The test is NOT intended to make an unmatched device probe successfully.
> driver_override permits an explicit probe attempt; it does not guarantee that probe must succeed.
> The driver must still reject unsupported devices safely. The bug is that it currently crashes instead of
> returning an error.
> 
> I reproduced this deterministically with KASAN on arm64 QEMU.
> The SPI device has an unmatched compatible and a valid microchip,spi-present-mask property, and is then
> bound with:
> 
> echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
> echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind
> 
> KASAN reports:

This is original issue.
You want to now add driver_override feature.

What is the log you get with your patch, probe failure?

Can't you make a patch for making probe working with driver_override feature
that makes the device functional with driver_override?

> 
> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
> pc : mcp23s08_probe+0x2f8/0x944
> lr : mcp23s08_probe+0x190/0x944
> Call trace:
>  mcp23s08_probe+0x2f8/0x944 (P)
>  spi_probe+0x1c0/0x2d8
>  really_probe+0x17c/0x5b8
>  __driver_probe_device+0x28c/0x350
>  device_driver_attach+0xa0/0x18c
>  bind_store+0xc4/0x13c
>  drv_attr_store+0x60/0x9c
>  sysfs_kf_write+0x170/0x1e8
>  kernfs_fop_write_iter+0x298/0x404
>  vfs_write+0x648/0x8cc
>  ksys_write+0xf0/0x1e0
>  __arm64_sys_write+0x70/0xa0
>  invoke_syscall+0x70/0x24c
> 
> 
> spi_get_device_match_data() returns NULL, and mcp23s08_spi_regmap_init() later dereferences info->type at
> offset 16.
> 
> The patch only guarantees safety; it does not attempt to support unmatched hardware through
> driver_override.

If you don't want driver_override non functional
What is the point of this patch, simply want to add some
Code space in linux kernel?

Cheers,
Biju

Re:RE: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[jiale yao]

At 2026-09-28 15:32:52, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>
>
>> -----Original Message-----
>> From: jiale yao <19888972804@163.com>
>> Sent: 28 September 2026 08:25
>> To: Biju Das <biju.das.jz@bp.renesas.com>
>> Cc: Linus Walleij <linusw@kernel.org>; Andy Shevchenko <andriy.shevchenko@linux.intel.com>; linux-
>> gpio@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data
>> 
>> [You don't often get email from 19888972804@163.com. Learn why this is important at
>> https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> At 2026-09-28 14:03:46, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>> >Hi jiale yao,
>> >
>> >> -----Original Message-----
>> >> From: jiale yao <19888972804@163.com>
>> >> Sent: 26 September 2026 11:24
>> >> Subject: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without
>> >> match data
>> >>
>> >> [You don't often get email from 19888972804@163.com. Learn why this
>> >> is important at https://aka.ms/LearnAboutSenderIdentification ]
>> >>
>> >> Hi Biju,
>> >>
>> >> At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
>> >> >Hi,
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jiale Yao <yaojiale02@163.com>
>> >> >> Sent: 25 September 2026 14:38
>> >> >> Subject: [PATCH] pinctrl: mcp23s08: reject devices without match
>> >> >> data
>> >> >>
>> >> >> A device bound through driver_override need not match an entry in
>> >> >> the driver tables. In that case
>> >> >> spi_get_device_match_data() returns NULL, but mcp23s08_probe()
>> >> >> later passes the result to the regmap setup and dereferences it while setting up each device.
>> >> >
>> >> >I believe this is an invalid use case as the user trying
>> >> >driver_override and the probe returns error. Am I missing anything here?
>> >>
>> >> Yes, my commit message was not clear enough. This patch is intended
>> >> to fix a regression introduced by commit 2e44555b05c0, rather than to make an unmatched device probe
>> successfully through driver_override.
>> >>
>> >> Before that commit, missing match data effectively resulted in type
>> >> 0, which fell through to the default switch case and returned -EINVAL.
>> >> Commit 2e44555b05c0 replaced the type value with an info pointer, but
>> >> the SPI path missed the corresponding NULL check before dereferencing
>> >> info->type. The I2C path preserved the previous error handling with
>> >> info->an
>> >> explicit NULL check after the same conversion.
>> >
>> >you are testing the driver with driver_override and your patch makes
>> >driver Probe failure. I do not understand the test case you are trying
>> >to achieve with driver_override.
>> >
>> >Can you please share some logs with driver_override that you planned to test?
>> >
>> >Cheers,
>> >Biju
>> >
>> >>
>> >> Consequently, an unmatched device bound through driver_override used
>> >> to fail cleanly. It can now cause a NULL pointer dereference when a
>> >> valid spi-present-mask property is present. This patch restores the previous failure behavior.
>> >>
>> >> >
>> >> >Can you please prepare a patch that makes the driver probe success
>> >> >by using driver_override Feature? Also please share some logs to see
>> >> >how it works in real device
>> >> >
>> >> >Cheers,
>> >> >Biju
>> 
>> 
>> The test is NOT intended to make an unmatched device probe successfully.
>> driver_override permits an explicit probe attempt; it does not guarantee that probe must succeed.
>> The driver must still reject unsupported devices safely. The bug is that it currently crashes instead of
>> returning an error.
>> 
>> I reproduced this deterministically with KASAN on arm64 QEMU.
>> The SPI device has an unmatched compatible and a valid microchip,spi-present-mask property, and is then
>> bound with:
>> 
>> echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
>> echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind
>> 
>> KASAN reports:
>
>This is original issue.
>You want to now add driver_override feature.
>
>What is the log you get with your patch, probe failure?
>
>Can't you make a patch for making probe working with driver_override feature
>that makes the device functional with driver_override?

I think we are discussing two different expectations:

- driver_override only gives the named driver an opportunity to bind, as
    documented in Documentation/ABI/testing/sysfs-bus-platform. It does
    not guarantee that probe succeeds.
- Without match data, this driver cannot determine whether the device is
    an MCP23S08, MCP23S17 or MCP23S18. Probe must therefore fail.
- Before commit 2e44555b05c0, this path failed cleanly with -EINVAL.
    After that commit, it dereferences NULL.
- This patch only restores the safe failure behavior.

With the patch applied, the result is:

    [    2.319112] mcp23s08 spi0.0: probe with driver mcp23s08 failed with error -61

This is the expected result. As far as I understand, an unsuccessful probe should
return an error, not cause a kernel memory access fault.

I am a little confused by this point. Are you suggesting that, if driver_override is
used for an unsupported device, the kernel should crash rather than have the
driver's probe fail cleanly?

>
>> 
>> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
>> pc : mcp23s08_probe+0x2f8/0x944
>> lr : mcp23s08_probe+0x190/0x944
>> Call trace:
>>  mcp23s08_probe+0x2f8/0x944 (P)
>>  spi_probe+0x1c0/0x2d8
>>  really_probe+0x17c/0x5b8
>>  __driver_probe_device+0x28c/0x350
>>  device_driver_attach+0xa0/0x18c
>>  bind_store+0xc4/0x13c
>>  drv_attr_store+0x60/0x9c
>>  sysfs_kf_write+0x170/0x1e8
>>  kernfs_fop_write_iter+0x298/0x404
>>  vfs_write+0x648/0x8cc
>>  ksys_write+0xf0/0x1e0
>>  __arm64_sys_write+0x70/0xa0
>>  invoke_syscall+0x70/0x24c
>> 
>> 
>> spi_get_device_match_data() returns NULL, and mcp23s08_spi_regmap_init() later dereferences info->type at
>> offset 16.
>> 
>> The patch only guarantees safety; it does not attempt to support unmatched hardware through
>> driver_override.
>
>If you don't want driver_override non functional
>What is the point of this patch, simply want to add some
>Code space in linux kernel?
>
>Cheers,
>Biju

RE: Re:RE: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Biju Das]

> -----Original Message-----
> From: jiale yao <19888972804@163.com>
> Sent: 28 September 2026 08:55
> To: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Linus Walleij <linusw@kernel.org>; Andy Shevchenko <andriy.shevchenko@linux.intel.com>; linux-
> gpio@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re:RE: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data
> 
> At 2026-09-28 15:32:52, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: jiale yao <19888972804@163.com>
> >> Sent: 28 September 2026 08:25
> >> To: Biju Das <biju.das.jz@bp.renesas.com>
> >> Cc: Linus Walleij <linusw@kernel.org>; Andy Shevchenko
> >> <andriy.shevchenko@linux.intel.com>; linux- gpio@vger.kernel.org;
> >> linux-kernel@vger.kernel.org
> >> Subject: Re:RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices
> >> without match data
> >>
> >> [You don't often get email from 19888972804@163.com. Learn why this
> >> is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> At 2026-09-28 14:03:46, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >> >Hi jiale yao,
> >> >
> >> >> -----Original Message-----
> >> >> From: jiale yao <19888972804@163.com>
> >> >> Sent: 26 September 2026 11:24
> >> >> Subject: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without
> >> >> match data
> >> >>
> >> >> [You don't often get email from 19888972804@163.com. Learn why
> >> >> this is important at https://aka.ms/LearnAboutSenderIdentification
> >> >> ]
> >> >>
> >> >> Hi Biju,
> >> >>
> >> >> At 2026-09-26 18:07:14, "Biju Das" <biju.das.jz@bp.renesas.com> wrote:
> >> >> >Hi,
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Jiale Yao <yaojiale02@163.com>
> >> >> >> Sent: 25 September 2026 14:38
> >> >> >> Subject: [PATCH] pinctrl: mcp23s08: reject devices without
> >> >> >> match data
> >> >> >>
> >> >> >> A device bound through driver_override need not match an entry
> >> >> >> in the driver tables. In that case
> >> >> >> spi_get_device_match_data() returns NULL, but mcp23s08_probe()
> >> >> >> later passes the result to the regmap setup and dereferences it while setting up each device.
> >> >> >
> >> >> >I believe this is an invalid use case as the user trying
> >> >> >driver_override and the probe returns error. Am I missing anything here?
> >> >>
> >> >> Yes, my commit message was not clear enough. This patch is
> >> >> intended to fix a regression introduced by commit 2e44555b05c0,
> >> >> rather than to make an unmatched device probe
> >> successfully through driver_override.
> >> >>
> >> >> Before that commit, missing match data effectively resulted in
> >> >> type 0, which fell through to the default switch case and returned -EINVAL.
> >> >> Commit 2e44555b05c0 replaced the type value with an info pointer,
> >> >> but the SPI path missed the corresponding NULL check before
> >> >> dereferencing
> >> >> info->type. The I2C path preserved the previous error handling
> >> >> info->with an
> >> >> explicit NULL check after the same conversion.
> >> >
> >> >you are testing the driver with driver_override and your patch makes
> >> >driver Probe failure. I do not understand the test case you are
> >> >trying to achieve with driver_override.
> >> >
> >> >Can you please share some logs with driver_override that you planned to test?
> >> >
> >> >Cheers,
> >> >Biju
> >> >
> >> >>
> >> >> Consequently, an unmatched device bound through driver_override
> >> >> used to fail cleanly. It can now cause a NULL pointer dereference
> >> >> when a valid spi-present-mask property is present. This patch restores the previous failure
> behavior.
> >> >>
> >> >> >
> >> >> >Can you please prepare a patch that makes the driver probe
> >> >> >success by using driver_override Feature? Also please share some
> >> >> >logs to see how it works in real device
> >> >> >
> >> >> >Cheers,
> >> >> >Biju
> >>
> >>
> >> The test is NOT intended to make an unmatched device probe successfully.
> >> driver_override permits an explicit probe attempt; it does not guarantee that probe must succeed.
> >> The driver must still reject unsupported devices safely. The bug is
> >> that it currently crashes instead of returning an error.
> >>
> >> I reproduced this deterministically with KASAN on arm64 QEMU.
> >> The SPI device has an unmatched compatible and a valid
> >> microchip,spi-present-mask property, and is then bound with:
> >>
> >> echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
> >> echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind
> >>
> >> KASAN reports:
> >
> >This is original issue.
> >You want to now add driver_override feature.
> >
> >What is the log you get with your patch, probe failure?
> >
> >Can't you make a patch for making probe working with driver_override
> >feature that makes the device functional with driver_override?
> 
> I think we are discussing two different expectations:
> 
> - driver_override only gives the named driver an opportunity to bind, as
>     documented in Documentation/ABI/testing/sysfs-bus-platform. It does
>     not guarantee that probe succeeds.
> - Without match data, this driver cannot determine whether the device is
>     an MCP23S08, MCP23S17 or MCP23S18. Probe must therefore fail.
> - Before commit 2e44555b05c0, this path failed cleanly with -EINVAL.
>     After that commit, it dereferences NULL.
> - This patch only restores the safe failure behavior.
> 
> With the patch applied, the result is:
> 
>     [    2.319112] mcp23s08 spi0.0: probe with driver mcp23s08 failed with error -61
> 
> This is the expected result. As far as I understand, an unsuccessful probe should return an error, not
> cause a kernel memory access fault.
> 
> I am a little confused by this point. Are you suggesting that, if driver_override is used for an
> unsupported device, the kernel should crash rather than have the driver's probe fail cleanly?

If you want to support driver_override, you need to make it functional for this device.
But you are making probe failure for driver_override which is of no Value to Linux

Cheers,
Bij

> 
> >
> >>
> >> KASAN: null-ptr-deref in range
> >> [0x0000000000000010-0x0000000000000017]
> >> pc : mcp23s08_probe+0x2f8/0x944
> >> lr : mcp23s08_probe+0x190/0x944
> >> Call trace:
> >>  mcp23s08_probe+0x2f8/0x944 (P)
> >>  spi_probe+0x1c0/0x2d8
> >>  really_probe+0x17c/0x5b8
> >>  __driver_probe_device+0x28c/0x350
> >>  device_driver_attach+0xa0/0x18c
> >>  bind_store+0xc4/0x13c
> >>  drv_attr_store+0x60/0x9c
> >>  sysfs_kf_write+0x170/0x1e8
> >>  kernfs_fop_write_iter+0x298/0x404
> >>  vfs_write+0x648/0x8cc
> >>  ksys_write+0xf0/0x1e0
> >>  __arm64_sys_write+0x70/0xa0
> >>  invoke_syscall+0x70/0x24c
> >>
> >>
> >> spi_get_device_match_data() returns NULL, and
> >> mcp23s08_spi_regmap_init() later dereferences info->type at offset 16.
> >>
> >> The patch only guarantees safety; it does not attempt to support
> >> unmatched hardware through driver_override.
> >
> >If you don't want driver_override non functional What is the point of
> >this patch, simply want to add some Code space in linux kernel?
> >
> >Cheers,
> >Biju

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Linus Walleij]

On Mon, Sep 28, 2026 at 9:25 AM jiale yao <19888972804@163.com> wrote:

> I reproduced this deterministically with KASAN on arm64 QEMU.
> The SPI device has an unmatched compatible and a valid microchip,spi-present-mask property, and is then bound with:
>
> echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
> echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind

[KASAN splat from spi_get_device_match_data() returning NULL]

But hey look in the driver:

static const struct spi_device_id mcp23s08_ids[] = {
        { "mcp23s08", (kernel_ulong_t)&mcp23s08_spi },
        { "mcp23s17", (kernel_ulong_t)&mcp23s17_spi },
        { "mcp23s18", (kernel_ulong_t)&mcp23s18_spi },
        { }
};
MODULE_DEVICE_TABLE(spi, mcp23s08_ids);

Why doesn't the override find the right data from the match table?

This looks more like a bug in the SPI bus implementation,
surely the bus should match a driver_overrid and return a
valid match data from spi_get_device_match_data()?

I think this is just papering over the real issue, you need
to dig into the SPI bus implementation and see why this isn't
working.

Yours,
Linus Walleij

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Andy Shevchenko]

On Thu, Oct 01, 2026 at 10:07:29PM +0200, Linus Walleij wrote:
> On Mon, Sep 28, 2026 at 9:25 AM jiale yao <19888972804@163.com> wrote:
> 
> > I reproduced this deterministically with KASAN on arm64 QEMU.
> > The SPI device has an unmatched compatible and a valid microchip,spi-present-mask property, and is then bound with:
> >
> > echo mcp23s08 > /sys/bus/spi/devices/spi0.0/driver_override
> > echo spi0.0 > /sys/bus/spi/drivers/mcp23s08/bind
> 
> [KASAN splat from spi_get_device_match_data() returning NULL]
> 
> But hey look in the driver:
> 
> static const struct spi_device_id mcp23s08_ids[] = {
>         { "mcp23s08", (kernel_ulong_t)&mcp23s08_spi },
>         { "mcp23s17", (kernel_ulong_t)&mcp23s17_spi },
>         { "mcp23s18", (kernel_ulong_t)&mcp23s18_spi },
>         { }
> };
> MODULE_DEVICE_TABLE(spi, mcp23s08_ids);
> 
> Why doesn't the override find the right data from the match table?
> 
> This looks more like a bug in the SPI bus implementation,
> surely the bus should match a driver_overrid and return a
> valid match data from spi_get_device_match_data()?
> 
> I think this is just papering over the real issue, you need
> to dig into the SPI bus implementation and see why this isn't
> working.

I believe this is the whole design of driver_override like this...
There is an attempt to allow drivers to forbid that feature.

-- 
With Best Regards,
Andy Shevchenko

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Linus Walleij]

On Fri, Oct 2, 2026 at 8:59 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> I believe this is the whole design of driver_override like this...
> There is an attempt to allow drivers to forbid that feature.

I guess I don't have the right background to understand
the driver_override feature, it feels someone should explain
its virtues to me because I feel I am getting really angry
at it and it may not deserve that.

The entire name of the thing feels like debugfs-footgun
territory for example.

Yours,
Linus Walleij

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Andy Shevchenko]

On Fri, Oct 02, 2026 at 11:52:41AM +0200, Linus Walleij wrote:
> On Fri, Oct 2, 2026 at 8:59 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > I believe this is the whole design of driver_override like this...
> > There is an attempt to allow drivers to forbid that feature.
> 
> I guess I don't have the right background to understand
> the driver_override feature, it feels someone should explain
> its virtues to me because I feel I am getting really angry
> at it and it may not deserve that.
> 
> The entire name of the thing feels like debugfs-footgun
> territory for example.

Yeah, I can't find neither a thing on LWN.net nor in the in-tree documentation.
The only useful piece of information is (in kernel-doc of struct bus_type):

  driver_override
    Set to true if this bus supports the driver_override mechanism, which
    allows userspace to force a specific driver to bind to a device via a sysfs
    attribute.

-- 
With Best Regards,
Andy Shevchenko

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Linus Walleij]

On Fri, Oct 2, 2026 at 12:19 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, Oct 02, 2026 at 11:52:41AM +0200, Linus Walleij wrote:
> > On Fri, Oct 2, 2026 at 8:59 AM Andy Shevchenko

> > The entire name of the thing feels like debugfs-footgun
> > territory for example.
>
> Yeah, I can't find neither a thing on LWN.net nor in the in-tree documentation.
> The only useful piece of information is (in kernel-doc of struct bus_type):
>
>   driver_override
>     Set to true if this bus supports the driver_override mechanism, which
>     allows userspace to force a specific driver to bind to a device via a sysfs
>     attribute.

This whole thing is weird, but OK.

Since we have a ton of drivers depending on match data we either
have to patch them all to bail out if match data is NULL (like this
patch does) or, which is equivalent, opt out of driver_override
that much is certain.

What I don't get is what this is intended for. What is the use case?
The commit says this is for VFIO. Shouldn't it be opt-in and turned
on only for VFIO then?

Kim Phillips is listed as contract for the platform bus driver_override
so let's ask! Kim: what is this for?

All of the device tree drivers use the platform bus, what's yhe
Unique Selling Point of this for our devices?

Yours,
Linus Walleij

Re: RE: Re:RE: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Andy Shevchenko]

+Cc: Danilo
(as you were involved in cleaning this up in the past and being co-maintainer
 of driver core)

On Sun, Oct 04, 2026 at 01:06:07AM +0200, Linus Walleij wrote:
> On Fri, Oct 2, 2026 at 12:19 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Oct 02, 2026 at 11:52:41AM +0200, Linus Walleij wrote:
> > > On Fri, Oct 2, 2026 at 8:59 AM Andy Shevchenko

...

> > > The entire name of the thing feels like debugfs-footgun
> > > territory for example.
> >
> > Yeah, I can't find neither a thing on LWN.net nor in the in-tree documentation.
> > The only useful piece of information is (in kernel-doc of struct bus_type):
> >
> >   driver_override
> >     Set to true if this bus supports the driver_override mechanism, which
> >     allows userspace to force a specific driver to bind to a device via a sysfs
> >     attribute.
> 
> This whole thing is weird, but OK.
> 
> Since we have a ton of drivers depending on match data we either
> have to patch them all to bail out if match data is NULL (like this
> patch does) or, which is equivalent, opt out of driver_override
> that much is certain.
> 
> What I don't get is what this is intended for. What is the use case?
> The commit says this is for VFIO. Shouldn't it be opt-in and turned
> on only for VFIO then?
> 
> Kim Phillips is listed as contract for the platform bus driver_override
> so let's ask! Kim: what is this for?
> 
> All of the device tree drivers use the platform bus, what's yhe
> Unique Selling Point of this for our devices?

-- 
With Best Regards,
Andy Shevchenko