drivers/iio/accel/bmc150-accel-core.c | 3 +++ 1 file changed, 3 insertions(+)
The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
which leads to bmc150_accel_core_probe() being called with irq=0, which
leads to bmc150_accel_interrupts_setup() never being called, which leads
to struct bmc150_accel_data *data ->interrupts[i].info being left unset
to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
which depends on struct bmc150_accel_data *data ->interrupts[i].info being
non-NULL, and which triggers NULL pointer dereference. This is triggered
e.g. from iio-sensor-proxy.
Fix this by skipping the IRQ register configuration in case there is no
IRQ connected in hardware, in a manner similar to what the driver did in
the very first commit which added the driver.
ACPI table dump:
"
$ acpidump > acpi.dat && acpixtract -sDSDT acpi.dat && iasl -d dsdt.dat
$ grep -A 30 -B 3 BOSC0200 dsdt.dsl
Device (BMA2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BOSC0200") // _HID: Hardware ID
Name (_CID, "BOSC0200") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
}
Method (ROTM, 0, NotSerialized)
{
Name (SBUF, Package (0x03)
{
"0 1 0",
"1 0 0 ",
"0 0 1"
})
Return (SBUF) /* \_SB_.PCI0.I2C0.BMA2.ROTM.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
"
Splat, collected from debian unstable, probably not very useful:
"
BUG: kernel NULL pointer dereference, address: 0000000000000001
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 3 UID: 0 PID: 960 Comm: iio-sensor-prox Not tainted 6.12.22-amd64 #1 Debian 6.12.22-1
Hardware name: Default string Default string/Default string, BIOS 5.12 03/04/2019
RIP: 0010:bmc150_accel_set_interrupt+0x68/0x120 [bmc150_accel_core]
Code: 84 86 00 00 00 ba 01 00 00 00 f0 0f c1 10 83 c2 01 83 fa 01 7f 64 49 8b 3c 24 be 01 00 00 00 e8 5e fc ff ff 89 c3 85 c0 75 52 <41> 0f b6 55 01 41 0f b6 75 00 45 31 c9 45 31 c0 49 8b 3c 24 6a 00
RSP: 0018:ffff9aba00f4bb40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff01
RDX: ffffffff9b526790 RSI: 0000000000000202 RDI: ffff8aff20a97504
RBP: ffff8aff20a97420 R08: ffff8aff02a753e8 R09: 0000000000000000
R10: ffff9aba00f4bb58 R11: 0000000000000009 R12: ffff8aff02a75550
R13: 0000000000000000 R14: 0000000000000001 R15: ffff8aff02a75330
FS: 00007fc47005c940(0000) GS:ffff8b0066d80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 0000000109218001 CR4: 00000000003726f0
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? page_fault_oops+0x15c/0x2e0
? exc_page_fault+0x7e/0x180
? asm_exc_page_fault+0x26/0x30
? rpm_resume+0x310/0x700
? bmc150_accel_set_interrupt+0x68/0x120 [bmc150_accel_core]
bmc150_accel_buffer_postenable+0x5d/0x90 [bmc150_accel_core]
__iio_update_buffers+0x731/0xb20 [industrialio]
enable_store+0x84/0xe0 [industrialio]
kernfs_fop_write_iter+0x13b/0x1f0
vfs_write+0x28d/0x450
ksys_write+0x6d/0xf0
do_syscall_64+0x82/0x190
? xas_load+0xd/0xd0
? xa_load+0x7b/0xb0
? __memcg_slab_free_hook+0xf7/0x140
? __x64_sys_close+0x3c/0x80
? kmem_cache_free+0x3ee/0x440
? syscall_exit_to_user_mode+0x4d/0x210
? do_syscall_64+0x8e/0x190
? syscall_exit_to_user_mode+0x4d/0x210
? do_syscall_64+0x8e/0x190
? do_syscall_64+0x8e/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fc4704629ee
Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
RSP: 002b:00007ffd598afd18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fc47005c940 RCX: 00007fc4704629ee
RDX: 0000000000000001 RSI: 00007ffd598afec0 RDI: 0000000000000009
RBP: 00007ffd598afec0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 000055680df28490 R14: 00007fc4705ade80 R15: 0000000000000001
</TASK>
Modules linked in: rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_sof_pci_intel_skl snd_sof_intel_hda_generic soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink snd_sof_intel_hda binfmt_misc snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi soundwire_bus nls_ascii intel_uncore_frequency intel_uncore_frequency_common iwlmvm snd_soc_avs nls_cp437 vfat fat snd_hda_codec_hdmi snd_soc_hda_codec snd_hda_ext_core x86_pkg_temp_thermal snd_hda_codec_realtek snd_soc_core intel_powerclamp mac80211 snd_hda_codec_generic snd_compress snd_hda_scodec_component snd_pcm_dmaengine coretemp ext4 snd_hda_intel kvm_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec btusb libarc4 mei_hdcp mei_pxp iwlwifi btrtl mbcache snd_hda_core jbd2 kvm intel_rapl_msr btintel btbcm joydev btmtk snd_hwdep rapl cfg80211 snd_pcm snd_timer bluetooth intel_cstate snd processor_thermal_device_pci_legacy intel_uncore
processor_thermal_device processor_thermal_wt_hint pcspkr mei_me processor_thermal_rfim processor_thermal_rapl intel_rapl_common rfkill intel_wmi_thunderbolt soundcore mei crc16 bmc150_accel_i2c processor_thermal_wt_req bmc150_accel_core intel_pch_thermal processor_thermal_power_floor processor_thermal_mbox intel_soc_dts_iosf intel_xhci_usb_role_switch goodix_ts industrialio_triggered_buffer roles kfifo_buf industrialio int3403_thermal intel_pmc_core int340x_thermal_zone soc_button_array ac intel_vsec int3400_thermal pmt_telemetry acpi_pad acpi_thermal_rel pmt_class evdev msr efi_pstore configfs nfnetlink efivarfs ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic dm_crypt dm_mod hid_generic usbhid hid i915 drm_buddy i2c_algo_bit drm_display_helper cec rc_core crct10dif_pclmul ttm crc32_pclmul crc32c_intel ghash_clmulni_intel drm_kms_helper sha512_ssse3 nvme sha256_ssse3 sha1_ssse3 nvme_core xhci_pci sdhci_pci drm xhci_hcd cqhci iTCO_wdt sdhci intel_pmc_bxt
iTCO_vendor_support aesni_intel watchdog gf128mul crypto_simd usbcore cryptd nvme_auth serio_raw mmc_core i2c_i801 intel_lpss_pci i2c_smbus intel_lpss usb_common idma64 video battery wmi button
CR2: 0000000000000001
---[ end trace 0000000000000000 ]---
RIP: 0010:bmc150_accel_set_interrupt+0x68/0x120 [bmc150_accel_core]
Code: 84 86 00 00 00 ba 01 00 00 00 f0 0f c1 10 83 c2 01 83 fa 01 7f 64 49 8b 3c 24 be 01 00 00 00 e8 5e fc ff ff 89 c3 85 c0 75 52 <41> 0f b6 55 01 41 0f b6 75 00 45 31 c9 45 31 c0 49 8b 3c 24 6a 00
RSP: 0018:ffff9aba00f4bb40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff01
RDX: ffffffff9b526790 RSI: 0000000000000202 RDI: ffff8aff20a97504
RBP: ffff8aff20a97420 R08: ffff8aff02a753e8 R09: 0000000000000000
R10: ffff9aba00f4bb58 R11: 0000000000000009 R12: ffff8aff02a75550
R13: 0000000000000000 R14: 0000000000000001 R15: ffff8aff02a75330
FS: 00007fc47005c940(0000) GS:ffff8b0066d80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 0000000109218001 CR4: 00000000003726f0
note: iio-sensor-prox[960] exited with irqs disabled
"
Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
---
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Julien Stephan <jstephan@baylibre.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Salvatore Bonaccorso <carnil@debian.org>
Cc: linux-iio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/iio/accel/bmc150-accel-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
index 744a034bb8b5..1c3583ade2b4 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
if (ret < 0)
return ret;
+ if (!info)
+ return 0;
+
/* map the interrupt to the appropriate pins */
ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
(state ? info->map_bitmask : 0));
--
2.47.2Hi,
On 13-Jun-25 14:45, Marek Vasut wrote:
> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> which leads to bmc150_accel_core_probe() being called with irq=0, which
> leads to bmc150_accel_interrupts_setup() never being called, which leads
> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> non-NULL, and which triggers NULL pointer dereference. This is triggered
> e.g. from iio-sensor-proxy.
>
> Fix this by skipping the IRQ register configuration in case there is no
> IRQ connected in hardware, in a manner similar to what the driver did in
> the very first commit which added the driver.
...
> Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
> Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
> ---
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Julien Stephan <jstephan@baylibre.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Salvatore Bonaccorso <carnil@debian.org>
> Cc: linux-iio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/iio/accel/bmc150-accel-core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> index 744a034bb8b5..1c3583ade2b4 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
> if (ret < 0)
> return ret;
>
> + if (!info)
> + return 0;
> +
> /* map the interrupt to the appropriate pins */
> ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
> (state ? info->map_bitmask : 0));
AFAIK the proper fix would be to not register any IIO-triggers. This fix will
avoid the problem, but userspace might still try to use non-working triggers
which will now silently fail.
I'm not an IIO expert, but IIRC other drivers simply skip registering their triggers
when there is no interrupt support.
Regards,
Hans
On Mon, 16 Jun 2025 14:42:54 +0200
Hans de Goede <hansg@kernel.org> wrote:
> Hi,
>
> On 13-Jun-25 14:45, Marek Vasut wrote:
> > The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> > which leads to bmc150_accel_core_probe() being called with irq=0, which
> > leads to bmc150_accel_interrupts_setup() never being called, which leads
> > to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> > to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> > which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> > non-NULL, and which triggers NULL pointer dereference. This is triggered
> > e.g. from iio-sensor-proxy.
> >
> > Fix this by skipping the IRQ register configuration in case there is no
> > IRQ connected in hardware, in a manner similar to what the driver did in
> > the very first commit which added the driver.
>
> ...
>
> > Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
> > Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
> > ---
> > Cc: "Nuno Sá" <nuno.sa@analog.com>
> > Cc: Andy Shevchenko <andy@kernel.org>
> > Cc: David Lechner <dlechner@baylibre.com>
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Cc: Julien Stephan <jstephan@baylibre.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Salvatore Bonaccorso <carnil@debian.org>
> > Cc: linux-iio@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > drivers/iio/accel/bmc150-accel-core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> > index 744a034bb8b5..1c3583ade2b4 100644
> > --- a/drivers/iio/accel/bmc150-accel-core.c
> > +++ b/drivers/iio/accel/bmc150-accel-core.c
> > @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
> > if (ret < 0)
> > return ret;
> >
> > + if (!info)
> > + return 0;
> > +
> > /* map the interrupt to the appropriate pins */
> > ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
> > (state ? info->map_bitmask : 0));
>
> AFAIK the proper fix would be to not register any IIO-triggers. This fix will
> avoid the problem, but userspace might still try to use non-working triggers
> which will now silently fail.
>
> I'm not an IIO expert, but IIRC other drivers simply skip registering their triggers
> when there is no interrupt support.
Absolutely. It is annoyingly common for devices to have some or none of the interrupt
lines actually wired so drivers should not present the interfaces if they aren't.
It is acceptable for a new driver to just fail to probe if handling the device with no
interrupts is particularly complex but in general at least some functionality tends
to be easy to implement so we prefer that.
Thanks,
Jonathan
>
> Regards,
>
> Hans
>
>
On 6/21/25 7:17 PM, Jonathan Cameron wrote:
> On Mon, 16 Jun 2025 14:42:54 +0200
> Hans de Goede <hansg@kernel.org> wrote:
>
>> Hi,
>>
>> On 13-Jun-25 14:45, Marek Vasut wrote:
>>> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
>>> which leads to bmc150_accel_core_probe() being called with irq=0, which
>>> leads to bmc150_accel_interrupts_setup() never being called, which leads
>>> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
>>> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
>>> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
>>> non-NULL, and which triggers NULL pointer dereference. This is triggered
>>> e.g. from iio-sensor-proxy.
>>>
>>> Fix this by skipping the IRQ register configuration in case there is no
>>> IRQ connected in hardware, in a manner similar to what the driver did in
>>> the very first commit which added the driver.
>>
>> ...
>>
>>> Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
>>> Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
>>> ---
>>> Cc: "Nuno Sá" <nuno.sa@analog.com>
>>> Cc: Andy Shevchenko <andy@kernel.org>
>>> Cc: David Lechner <dlechner@baylibre.com>
>>> Cc: Jonathan Cameron <jic23@kernel.org>
>>> Cc: Julien Stephan <jstephan@baylibre.com>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Salvatore Bonaccorso <carnil@debian.org>
>>> Cc: linux-iio@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> ---
>>> drivers/iio/accel/bmc150-accel-core.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
>>> index 744a034bb8b5..1c3583ade2b4 100644
>>> --- a/drivers/iio/accel/bmc150-accel-core.c
>>> +++ b/drivers/iio/accel/bmc150-accel-core.c
>>> @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
>>> if (ret < 0)
>>> return ret;
>>>
>>> + if (!info)
>>> + return 0;
>>> +
>>> /* map the interrupt to the appropriate pins */
>>> ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
>>> (state ? info->map_bitmask : 0));
>>
>> AFAIK the proper fix would be to not register any IIO-triggers. This fix will
>> avoid the problem, but userspace might still try to use non-working triggers
>> which will now silently fail.
>>
>> I'm not an IIO expert, but IIRC other drivers simply skip registering their triggers
>> when there is no interrupt support.
>
> Absolutely. It is annoyingly common for devices to have some or none of the interrupt
> lines actually wired so drivers should not present the interfaces if they aren't.
> It is acceptable for a new driver to just fail to probe if handling the device with no
> interrupts is particularly complex but in general at least some functionality tends
> to be easy to implement so we prefer that.
I haven't gotten to this again ... yet ... I can try and add some sort
of polling fallback maybe ?
Hi Marek,
On 21-Jun-25 7:24 PM, Marek Vasut wrote:
> On 6/21/25 7:17 PM, Jonathan Cameron wrote:
>> On Mon, 16 Jun 2025 14:42:54 +0200
>> Hans de Goede <hansg@kernel.org> wrote:
>>
>>> Hi,
>>>
>>> On 13-Jun-25 14:45, Marek Vasut wrote:
>>>> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
>>>> which leads to bmc150_accel_core_probe() being called with irq=0, which
>>>> leads to bmc150_accel_interrupts_setup() never being called, which leads
>>>> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
>>>> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
>>>> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
>>>> non-NULL, and which triggers NULL pointer dereference. This is triggered
>>>> e.g. from iio-sensor-proxy.
>>>>
>>>> Fix this by skipping the IRQ register configuration in case there is no
>>>> IRQ connected in hardware, in a manner similar to what the driver did in
>>>> the very first commit which added the driver.
>>>
>>> ...
>>>
>>>> Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
>>>> Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
>>>> ---
>>>> Cc: "Nuno Sá" <nuno.sa@analog.com>
>>>> Cc: Andy Shevchenko <andy@kernel.org>
>>>> Cc: David Lechner <dlechner@baylibre.com>
>>>> Cc: Jonathan Cameron <jic23@kernel.org>
>>>> Cc: Julien Stephan <jstephan@baylibre.com>
>>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>>> Cc: Salvatore Bonaccorso <carnil@debian.org>
>>>> Cc: linux-iio@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> ---
>>>> drivers/iio/accel/bmc150-accel-core.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
>>>> index 744a034bb8b5..1c3583ade2b4 100644
>>>> --- a/drivers/iio/accel/bmc150-accel-core.c
>>>> +++ b/drivers/iio/accel/bmc150-accel-core.c
>>>> @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
>>>> if (ret < 0)
>>>> return ret;
>>>> + if (!info)
>>>> + return 0;
>>>> +
>>>> /* map the interrupt to the appropriate pins */
>>>> ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
>>>> (state ? info->map_bitmask : 0));
>>>
>>> AFAIK the proper fix would be to not register any IIO-triggers. This fix will
>>> avoid the problem, but userspace might still try to use non-working triggers
>>> which will now silently fail.
>>>
>>> I'm not an IIO expert, but IIRC other drivers simply skip registering their triggers
>>> when there is no interrupt support.
>>
>> Absolutely. It is annoyingly common for devices to have some or none of the interrupt
>> lines actually wired so drivers should not present the interfaces if they aren't.
>> It is acceptable for a new driver to just fail to probe if handling the device with no
>> interrupts is particularly complex but in general at least some functionality tends
>> to be easy to implement so we prefer that.
> I haven't gotten to this again ... yet ... I can try and add some sort of polling fallback maybe ?
IIO has separate interfaces for exporting channels which can be polled by
userspace and for triggers which is a more event driven interface.
It should be possible to modify the driver to skip the trigger registration,
while keeping the channels. E.g. iio-sensor-proxy will then automaticallt
switch to polling in userspace.
Regards,
Hans
On 6/21/25 10:14 PM, Hans de Goede wrote:
Hello Hans,
> IIO has separate interfaces for exporting channels which can be polled by
> userspace and for triggers which is a more event driven interface.
>
> It should be possible to modify the driver to skip the trigger registration,
> while keeping the channels. E.g. iio-sensor-proxy will then automaticallt
> switch to polling in userspace.
I wonder if this got fixed by this commit in the meantime:
3aa385a9c75c ("iio: accel: bmc150: Fix irq assumption regression")
On Thu, Jan 8, 2026 at 10:55 PM Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/21/25 10:14 PM, Hans de Goede wrote:
>
> Hello Hans,
>
> > IIO has separate interfaces for exporting channels which can be polled by
> > userspace and for triggers which is a more event driven interface.
> >
> > It should be possible to modify the driver to skip the trigger registration,
> > while keeping the channels. E.g. iio-sensor-proxy will then automaticallt
> > switch to polling in userspace.
> I wonder if this got fixed by this commit in the meantime:
>
> 3aa385a9c75c ("iio: accel: bmc150: Fix irq assumption regression")
I think so.
It was causing a NULL dereference for me, so I had to fix it.
Yours,
Linus Walleij
On 1/9/26 10:24 AM, Linus Walleij wrote:
> On Thu, Jan 8, 2026 at 10:55 PM Marek Vasut <marek.vasut@mailbox.org> wrote:
>
>> On 6/21/25 10:14 PM, Hans de Goede wrote:
>>
>> Hello Hans,
>>
>>> IIO has separate interfaces for exporting channels which can be polled by
>>> userspace and for triggers which is a more event driven interface.
>>>
>>> It should be possible to modify the driver to skip the trigger registration,
>>> while keeping the channels. E.g. iio-sensor-proxy will then automaticallt
>>> switch to polling in userspace.
>> I wonder if this got fixed by this commit in the meantime:
>>
>> 3aa385a9c75c ("iio: accel: bmc150: Fix irq assumption regression")
>
> I think so.
>
> It was causing a NULL dereference for me, so I had to fix it.
Thank you !
Strange I don't see Hans in the Cc list, so added.
Thanks for the report and patch, my comments below.
On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> which leads to bmc150_accel_core_probe() being called with irq=0, which
> leads to bmc150_accel_interrupts_setup() never being called, which leads
> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> non-NULL, and which triggers NULL pointer dereference. This is triggered
> e.g. from iio-sensor-proxy.
>
> Fix this by skipping the IRQ register configuration in case there is no
> IRQ connected in hardware, in a manner similar to what the driver did in
> the very first commit which added the driver.
>
> ACPI table dump:
> Device (BMA2)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "BOSC0200") // _HID: Hardware ID
> Name (_CID, "BOSC0200") // _CID: Compatible ID
> Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
> Name (_UID, One) // _UID: Unique ID
> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> {
> Name (RBUF, ResourceTemplate ()
> {
> I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\_SB.PCI0.I2C0",
> 0x00, ResourceConsumer, , Exclusive,
> )
> })
> Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
> }
These lines...
> Method (ROTM, 0, NotSerialized)
> {
> Name (SBUF, Package (0x03)
> {
> "0 1 0",
> "1 0 0 ",
> "0 0 1"
> })
> Return (SBUF) /* \_SB_.PCI0.I2C0.BMA2.ROTM.SBUF */
> }
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
> Return (0x0F)
> }
...are irrelevant.
> }
> "
>
> Splat, collected from debian unstable, probably not very useful:
Oh my gosh, please leave only ~3-5 *important* lines out of this, or move it
completely to the comment block (after '---' cutter line).
This is requirement written in Submitting Patches.
...
As for the solution, are you sure the line is not wired at all?
IIRC Hans had a broken tales where it was simply forgotten, meaning
the Android / Windows driver simply hardcoded needed info.
If it's the case, it should be solved differently around PDx86 special quirk
driver for the cases like this.
--
With Best Regards,
Andy Shevchenko
On 6/13/25 5:09 PM, Andy Shevchenko wrote:
> Strange I don't see Hans in the Cc list, so added.
> Thanks for the report and patch, my comments below.
>
> On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
>> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
>> which leads to bmc150_accel_core_probe() being called with irq=0, which
>> leads to bmc150_accel_interrupts_setup() never being called, which leads
>> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
>> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
>> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
>> non-NULL, and which triggers NULL pointer dereference. This is triggered
>> e.g. from iio-sensor-proxy.
>>
>> Fix this by skipping the IRQ register configuration in case there is no
>> IRQ connected in hardware, in a manner similar to what the driver did in
>> the very first commit which added the driver.
>>
>> ACPI table dump:
>
>> Device (BMA2)
>> {
>> Name (_ADR, Zero) // _ADR: Address
>> Name (_HID, "BOSC0200") // _HID: Hardware ID
>> Name (_CID, "BOSC0200") // _CID: Compatible ID
>> Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
>> Name (_UID, One) // _UID: Unique ID
>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
>> {
>> Name (RBUF, ResourceTemplate ()
>> {
>> I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
>> AddressingMode7Bit, "\\_SB.PCI0.I2C0",
>> 0x00, ResourceConsumer, , Exclusive,
>> )
>> })
>> Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
>> }
>
> These lines...
>
>> Method (ROTM, 0, NotSerialized)
>> {
>> Name (SBUF, Package (0x03)
>> {
>> "0 1 0",
>> "1 0 0 ",
>> "0 0 1"
>> })
>> Return (SBUF) /* \_SB_.PCI0.I2C0.BMA2.ROTM.SBUF */
>> }
>>
>> Method (_STA, 0, NotSerialized) // _STA: Status
>> {
>> Return (0x0F)
>> }
>
> ...are irrelevant.
>
>> }
>> "
>>
>> Splat, collected from debian unstable, probably not very useful:
>
> Oh my gosh, please leave only ~3-5 *important* lines out of this, or move it
> completely to the comment block (after '---' cutter line).
>
> This is requirement written in Submitting Patches.
>
> ...
>
> As for the solution, are you sure the line is not wired at all?
No . It is some cheap mini-laptop , I have no schematics or any other
info really .
Note that I am not really familiar with x86 and ACPI, so there is that.
> IIRC Hans had a broken tales where it was simply forgotten, meaning
> the Android / Windows driver simply hardcoded needed info.
>
> If it's the case, it should be solved differently around PDx86 special quirk
> driver for the cases like this.
There are likely two issues.
First, this driver needs to handle i2c_client->irq == 0 correctly if it
should work without IRQ line, which the driver seems to indicate that it
does. The current crashing the kernel is not the correct way of handling
that. That's this patch, in some form.
Second, if this laptop has some IRQ line for this chip hidden somewhere,
then it might need a quirk of sorts, sure. Is there some way to find
out, without taking the thing apart and poking around with a scope ?
On Fri, Jun 13, 2025 at 07:02:28PM +0200, Marek Vasut wrote:
> On 6/13/25 5:09 PM, Andy Shevchenko wrote:
> > On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
> > > The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> > > which leads to bmc150_accel_core_probe() being called with irq=0, which
> > > leads to bmc150_accel_interrupts_setup() never being called, which leads
> > > to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> > > to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> > > which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> > > non-NULL, and which triggers NULL pointer dereference. This is triggered
> > > e.g. from iio-sensor-proxy.
> > >
> > > Fix this by skipping the IRQ register configuration in case there is no
> > > IRQ connected in hardware, in a manner similar to what the driver did in
> > > the very first commit which added the driver.
> > >
> > > ACPI table dump:
> >
> > > Device (BMA2)
> > > {
> > > Name (_ADR, Zero) // _ADR: Address
> > > Name (_HID, "BOSC0200") // _HID: Hardware ID
> > > Name (_CID, "BOSC0200") // _CID: Compatible ID
> > > Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
> > > Name (_UID, One) // _UID: Unique ID
> > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> > > {
> > > Name (RBUF, ResourceTemplate ()
> > > {
> > > I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
> > > AddressingMode7Bit, "\\_SB.PCI0.I2C0",
> > > 0x00, ResourceConsumer, , Exclusive,
> > > )
> > > })
> > > Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
> > > }
> > > }
...
> > As for the solution, are you sure the line is not wired at all?
>
> No . It is some cheap mini-laptop , I have no schematics or any other info
> really .
> Note that I am not really familiar with x86 and ACPI, so there is that.
Yes, I understand that.
You can try to monitor the /sys/kernel/debug/pinctrl/*/pins files for any
changes that might happen on the sensor events. It might (help to) reveal
the IRQ line.
> > IIRC Hans had a broken tales where it was simply forgotten, meaning
> > the Android / Windows driver simply hardcoded needed info.
> >
> > If it's the case, it should be solved differently around PDx86 special quirk
> > driver for the cases like this.
> There are likely two issues.
>
> First, this driver needs to handle i2c_client->irq == 0 correctly if it
> should work without IRQ line, which the driver seems to indicate that it
> does. The current crashing the kernel is not the correct way of handling
> that. That's this patch, in some form.
>
> Second, if this laptop has some IRQ line for this chip hidden somewhere,
> then it might need a quirk of sorts, sure. Is there some way to find out,
> without taking the thing apart and poking around with a scope ?
--
With Best Regards,
Andy Shevchenko
On 6/16/25 10:47 AM, Andy Shevchenko wrote:
> On Fri, Jun 13, 2025 at 07:02:28PM +0200, Marek Vasut wrote:
>> On 6/13/25 5:09 PM, Andy Shevchenko wrote:
>>> On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
>
>>>> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
>>>> which leads to bmc150_accel_core_probe() being called with irq=0, which
>>>> leads to bmc150_accel_interrupts_setup() never being called, which leads
>>>> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
>>>> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
>>>> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
>>>> non-NULL, and which triggers NULL pointer dereference. This is triggered
>>>> e.g. from iio-sensor-proxy.
>>>>
>>>> Fix this by skipping the IRQ register configuration in case there is no
>>>> IRQ connected in hardware, in a manner similar to what the driver did in
>>>> the very first commit which added the driver.
>>>>
>>>> ACPI table dump:
>>>
>>>> Device (BMA2)
>>>> {
>>>> Name (_ADR, Zero) // _ADR: Address
>>>> Name (_HID, "BOSC0200") // _HID: Hardware ID
>>>> Name (_CID, "BOSC0200") // _CID: Compatible ID
>>>> Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
>>>> Name (_UID, One) // _UID: Unique ID
>>>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
>>>> {
>>>> Name (RBUF, ResourceTemplate ()
>>>> {
>>>> I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
>>>> AddressingMode7Bit, "\\_SB.PCI0.I2C0",
>>>> 0x00, ResourceConsumer, , Exclusive,
>>>> )
>>>> })
>>>> Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
>>>> }
>
>>>> }
>
> ...
>
>>> As for the solution, are you sure the line is not wired at all?
>>
>> No . It is some cheap mini-laptop , I have no schematics or any other info
>> really .
>
>> Note that I am not really familiar with x86 and ACPI, so there is that.
>
> Yes, I understand that.
>
> You can try to monitor the /sys/kernel/debug/pinctrl/*/pins files for any
> changes that might happen on the sensor events. It might (help to) reveal
> the IRQ line.
Sooo ... if the IRQ line is not described in ACPI, it could still be
connected ? Hum, I'll try to shake the laptop next time I power it up.
On Mon, Jun 16, 2025 at 2:03 PM Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/16/25 10:47 AM, Andy Shevchenko wrote:
> > On Fri, Jun 13, 2025 at 07:02:28PM +0200, Marek Vasut wrote:
> >> On 6/13/25 5:09 PM, Andy Shevchenko wrote:
> >>> On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
...
> >>>> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> >>>> which leads to bmc150_accel_core_probe() being called with irq=0, which
> >>>> leads to bmc150_accel_interrupts_setup() never being called, which leads
> >>>> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> >>>> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> >>>> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> >>>> non-NULL, and which triggers NULL pointer dereference. This is triggered
> >>>> e.g. from iio-sensor-proxy.
> >>>>
> >>>> Fix this by skipping the IRQ register configuration in case there is no
> >>>> IRQ connected in hardware, in a manner similar to what the driver did in
> >>>> the very first commit which added the driver.
> >>>>
> >>>> ACPI table dump:
> >>>
> >>>> Device (BMA2)
> >>>> {
> >>>> Name (_ADR, Zero) // _ADR: Address
> >>>> Name (_HID, "BOSC0200") // _HID: Hardware ID
> >>>> Name (_CID, "BOSC0200") // _CID: Compatible ID
> >>>> Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
> >>>> Name (_UID, One) // _UID: Unique ID
> >>>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> >>>> {
> >>>> Name (RBUF, ResourceTemplate ()
> >>>> {
> >>>> I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
> >>>> AddressingMode7Bit, "\\_SB.PCI0.I2C0",
> >>>> 0x00, ResourceConsumer, , Exclusive,
> >>>> )
> >>>> })
> >>>> Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
> >>>> }
> >
> >>>> }
...
> >>> As for the solution, are you sure the line is not wired at all?
> >>
> >> No . It is some cheap mini-laptop , I have no schematics or any other info
> >> really .
> >
> >> Note that I am not really familiar with x86 and ACPI, so there is that.
> >
> > Yes, I understand that.
> >
> > You can try to monitor the /sys/kernel/debug/pinctrl/*/pins files for any
> > changes that might happen on the sensor events. It might (help to) reveal
> > the IRQ line.
> Sooo ... if the IRQ line is not described in ACPI, it could still be
> connected ? Hum, I'll try to shake the laptop next time I power it up.
Yes, it's possible, unfortunately due to the closed / per-product
nature of the Windows drivers.
--
With Best Regards,
Andy Shevchenko
On 6/16/25 1:09 PM, Andy Shevchenko wrote: Hi, >>> You can try to monitor the /sys/kernel/debug/pinctrl/*/pins files for any >>> changes that might happen on the sensor events. It might (help to) reveal >>> the IRQ line. >> Sooo ... if the IRQ line is not described in ACPI, it could still be >> connected ? Hum, I'll try to shake the laptop next time I power it up. > > Yes, it's possible, unfortunately due to the closed / per-product > nature of the Windows drivers. This is the only pins I got out of this, and there doesn't seem to be anything changing if I shake the machine: # cat /sys/kernel/debug/pinctrl/INT344B\:00/pins registered pins: 152 pin 0 (RCINB) 0:INT344B:00 GPIO 0x04000102 0x00001018 pin 1 (LAD_0) 1:INT344B:00 mode 1 0x44000702 0x00003c19 [ACPI] pin 2 (LAD_1) 2:INT344B:00 mode 1 0x44000702 0x00003c1a [ACPI] pin 3 (LAD_2) 3:INT344B:00 mode 1 0x44000702 0x00003c1b [ACPI] pin 4 (LAD_3) 4:INT344B:00 mode 1 0x44000702 0x00003c1c [ACPI] pin 5 (LFRAMEB) 5:INT344B:00 mode 1 0x44000700 0x0000001d [ACPI] pin 6 (SERIQ) 6:INT344B:00 mode 1 0x44000702 0x0000001e [ACPI] pin 7 (PIRQAB) 7:INT344B:00 GPIO 0x44000100 0x0000101f pin 8 (CLKRUNB) 8:INT344B:00 mode 1 0x44000702 0x00000020 pin 9 (CLKOUT_LPC_0) 9:INT344B:00 mode 1 0x44000700 0x00001021 [ACPI] pin 10 (CLKOUT_LPC_1) 10:INT344B:00 mode 1 0x44000700 0x00001022 pin 11 (PMEB) 11:INT344B:00 GPIO 0x44000102 0x00001023 pin 12 (BM_BUSYB) 12:INT344B:00 GPIO 0x44000100 0x00001024 [LOCKED] pin 13 (SUSWARNB_SUS_PWRDNACK) 13:INT344B:00 mode 1 0x44000700 0x00000025 pin 14 (SUS_STATB) 14:INT344B:00 mode 1 0x44000700 0x00000026 [ACPI] pin 15 (SUSACKB) 15:INT344B:00 mode 1 0x44000702 0x00003027 [ACPI] pin 16 (SD_1P8_SEL) 16:INT344B:00 mode 1 0x44000500 0x00000028 pin 17 (SD_PWR_EN_B) 17:INT344B:00 mode 1 0x44000700 0x00000029 pin 18 (ISH_GP_0) 18:INT344B:00 GPIO 0x40800102 0x0000002a pin 19 (ISH_GP_1) 19:INT344B:00 GPIO 0x40000100 0x0000102b pin 20 (ISH_GP_2) 20:INT344B:00 GPIO 0x42000102 0x0000002c pin 21 (ISH_GP_3) 21:INT344B:00 GPIO 0x44000201 0x0000002d pin 22 (ISH_GP_4) 22:INT344B:00 GPIO 0x44000100 0x0000102e pin 23 (ISH_GP_5) 23:INT344B:00 GPIO 0x44000100 0x0000102f pin 24 (CORE_VID_0) 24:INT344B:00 GPIO 0x44000100 0x00001030 pin 25 (CORE_VID_1) 25:INT344B:00 GPIO 0x44000100 0x00001031 pin 26 (VRALERTB) 26:INT344B:00 GPIO 0x44000201 0x00000032 pin 27 (CPU_GP_2) 27:INT344B:00 GPIO 0x44000100 0x00001033 pin 28 (CPU_GP_3) 28:INT344B:00 GPIO 0x44000201 0x00000034 pin 29 (SRCCLKREQB_0) 29:INT344B:00 GPIO 0x44000100 0x00001035 pin 30 (SRCCLKREQB_1) 30:INT344B:00 GPIO 0x44000102 0x00003036 pin 31 (SRCCLKREQB_2) 31:INT344B:00 GPIO 0x44000102 0x00003037 pin 32 (SRCCLKREQB_3) 32:INT344B:00 mode 1 0x44000702 0x00003038 pin 33 (SRCCLKREQB_4) 33:INT344B:00 mode 1 0x44000702 0x00000039 pin 34 (SRCCLKREQB_5) 34:INT344B:00 mode 1 0x44000702 0x0000003a pin 35 (EXT_PWR_GATEB) 35:INT344B:00 mode 1 0x44000700 0x0000003b [ACPI] pin 36 (SLP_S0B) 36:INT344B:00 mode 1 0x44000700 0x0000003c pin 37 (PLTRSTB) 37:INT344B:00 mode 1 0x44000700 0x0000003d pin 38 (SPKR) 38:INT344B:00 GPIO 0x44000100 0x0000003e pin 39 (GSPI0_CSB) 39:INT344B:00 GPIO 0x44000102 0x0000303f pin 40 (GSPI0_CLK) 40:INT344B:00 GPIO 0x44000100 0x00001040 pin 41 (GSPI0_MISO) 41:INT344B:00 GPIO 0x46000102 0x00000041 pin 42 (GSPI0_MOSI) 42:INT344B:00 GPIO 0x44000100 0x00001042 pin 43 (GSPI1_CSB) 43:INT344B:00 GPIO 0x44000100 0x00001043 pin 44 (GSPI1_CLK) 44:INT344B:00 GPIO 0x44000100 0x00001044 pin 45 (GSPI1_MISO) 45:INT344B:00 GPIO 0x44000100 0x00001045 pin 46 (GSPI1_MOSI) 46:INT344B:00 GPIO 0x44000100 0x00001046 pin 47 (SML1ALERTB) 47:INT344B:00 GPIO 0x44000100 0x00001047 pin 48 (SMBCLK) 48:INT344B:00 mode 1 0x44000702 0x00002848 pin 49 (SMBDATA) 49:INT344B:00 mode 1 0x44000702 0x00002849 pin 50 (SMBALERTB) 50:INT344B:00 GPIO 0x44000100 0x0000104a pin 51 (SML0CLK) 51:INT344B:00 GPIO 0x44000100 0x0000104b pin 52 (SML0DATA) 52:INT344B:00 GPIO 0x44000100 0x0000104c pin 53 (SML0ALERTB) 53:INT344B:00 GPIO 0x44000100 0x0000104d pin 54 (SML1CLK) 54:INT344B:00 GPIO 0x44000100 0x0000104e pin 55 (SML1DATA) 55:INT344B:00 GPIO 0x44000100 0x0000104f pin 56 (UART0_RXD) 56:INT344B:00 GPIO 0x44000102 0x00000050 [ACPI] pin 57 (UART0_TXD) 57:INT344B:00 GPIO 0x86080102 0x00000051 [ACPI] pin 58 (UART0_RTSB) 58:INT344B:00 GPIO 0x44000201 0x00000052 pin 59 (UART0_CTSB) 59:INT344B:00 GPIO 0x44000102 0x00003053 pin 60 (UART1_RXD) 60:INT344B:00 GPIO 0x44000200 0x00002454 pin 61 (UART1_TXD) 61:INT344B:00 GPIO 0x44000100 0x00001055 pin 62 (UART1_RTSB) 62:INT344B:00 GPIO 0x44000100 0x00001056 pin 63 (UART1_CTSB) 63:INT344B:00 GPIO 0x44000100 0x00001057 pin 64 (I2C0_SDA) 64:INT344B:00 mode 1 0x44000702 0x00000058 pin 65 (I2C0_SCL) 65:INT344B:00 mode 1 0x44000702 0x00000059 pin 66 (I2C1_SDA) 66:INT344B:00 mode 1 0x44000702 0x0000005a pin 67 (I2C1_SCL) 67:INT344B:00 mode 1 0x44000702 0x0000005b pin 68 (UART2_RXD) 68:INT344B:00 mode 1 0x44000702 0x0000005c pin 69 (UART2_TXD) 69:INT344B:00 mode 1 0x44000700 0x0000005d pin 70 (UART2_RTSB) 70:INT344B:00 GPIO 0x44000200 0x0000245e pin 71 (UART2_CTSB) 71:INT344B:00 GPIO 0x44000100 0x0000105f pin 72 (SPI1_CSB) 72:INT344B:00 GPIO 0x44000100 0x00001060 pin 73 (SPI1_CLK) 73:INT344B:00 GPIO 0x44000100 0x00001061 pin 74 (SPI1_MISO_IO_1) 74:INT344B:00 GPIO 0x44000100 0x00001062 pin 75 (SPI1_MOSI_IO_0) 75:INT344B:00 GPIO 0x44000100 0x00001063 pin 76 (FLASHTRIG) 76:INT344B:00 GPIO 0x44000100 0x00001064 pin 77 (ISH_I2C0_SDA) 77:INT344B:00 GPIO 0x44000102 0x00000065 pin 78 (ISH_I2C0_SCL) 78:INT344B:00 GPIO 0x44000102 0x00000066 pin 79 (ISH_I2C1_SDA) 79:INT344B:00 GPIO 0x44000102 0x00000067 pin 80 (ISH_I2C1_SCL) 80:INT344B:00 GPIO 0x44000102 0x00000068 pin 81 (ISH_SPI_CSB) 81:INT344B:00 GPIO 0x44000100 0x00001069 pin 82 (ISH_SPI_CLK) 82:INT344B:00 GPIO 0x44000100 0x0000106a pin 83 (ISH_SPI_MISO) 83:INT344B:00 GPIO 0x40000102 0x0000006b pin 84 (ISH_SPI_MOSI) 84:INT344B:00 GPIO 0x40000102 0x0000006c pin 85 (ISH_UART0_RXD) 85:INT344B:00 GPIO 0x44000100 0x0000106d pin 86 (ISH_UART0_TXD) 86:INT344B:00 GPIO 0x44000100 0x0000106e pin 87 (ISH_UART0_RTSB) 87:INT344B:00 GPIO 0x44000100 0x0000106f pin 88 (ISH_UART0_CTSB) 88:INT344B:00 GPIO 0x44000100 0x00001070 pin 89 (DMIC_CLK_1) 89:INT344B:00 GPIO 0x44000200 0x00001071 pin 90 (DMIC_DATA_1) 90:INT344B:00 GPIO 0x44000100 0x00001072 pin 91 (DMIC_CLK_0) 91:INT344B:00 GPIO 0x44000201 0x00003073 pin 92 (DMIC_DATA_0) 92:INT344B:00 GPIO 0x04000201 0x00003074 pin 93 (SPI1_IO_2) 93:INT344B:00 GPIO 0x44000100 0x00001075 pin 94 (SPI1_IO_3) 94:INT344B:00 GPIO 0x44000100 0x00001076 pin 95 (SSP_MCLK) 95:INT344B:00 GPIO 0x44000100 0x00001077 pin 96 (SATAXPCIE_0) 96:INT344B:00 GPIO 0x44000100 0x00001018 pin 97 (SATAXPCIE_1) 97:INT344B:00 mode 1 0x44000700 0x00001019 pin 98 (SATAXPCIE_2) 98:INT344B:00 GPIO 0x44000100 0x0000101a pin 99 (CPU_GP_0) 99:INT344B:00 GPIO 0x44000100 0x0000101b pin 100 (SATA_DEVSLP_0) 100:INT344B:00 GPIO 0x44000100 0x0000101c pin 101 (SATA_DEVSLP_1) 101:INT344B:00 mode 1 0x04000700 0x0000001d pin 102 (SATA_DEVSLP_2) 102:INT344B:00 GPIO 0x44000100 0x0000101e pin 103 (CPU_GP_1) 103:INT344B:00 GPIO 0x84000100 0x0000001f pin 104 (SATA_LEDB) 104:INT344B:00 GPIO 0x44000100 0x00001020 pin 105 (USB2_OCB_0) 105:INT344B:00 mode 1 0x44000702 0x00000021 pin 106 (USB2_OCB_1) 106:INT344B:00 mode 1 0x44000702 0x00000022 pin 107 (USB2_OCB_2) 107:INT344B:00 GPIO 0x44000301 0x00000023 pin 108 (USB2_OCB_3) 108:INT344B:00 GPIO 0x44000100 0x00001024 pin 109 (DDSP_HPD_0) 109:INT344B:00 mode 1 0x44000700 0x00000025 pin 110 (DDSP_HPD_1) 110:INT344B:00 mode 1 0x44000700 0x00000026 pin 111 (DDSP_HPD_2) 111:INT344B:00 mode 1 0x44000702 0x00000027 pin 112 (DDSP_HPD_3) 112:INT344B:00 GPIO 0x80880102 0x00003028 [ACPI] pin 113 (EDP_HPD) 113:INT344B:00 mode 1 0x44000702 0x00000029 pin 114 (DDPB_CTRLCLK) 114:INT344B:00 mode 1 0x44000702 0x0000002a pin 115 (DDPB_CTRLDATA) 115:INT344B:00 mode 1 0x44000702 0x0000102b pin 116 (DDPC_CTRLCLK) 116:INT344B:00 GPIO 0x44000100 0x0000102c pin 117 (DDPC_CTRLDATA) 117:INT344B:00 GPIO 0x44000102 0x0000102d pin 118 (DDPD_CTRLCLK) 118:INT344B:00 GPIO 0x44000100 0x0000102e pin 119 (DDPD_CTRLDATA) 119:INT344B:00 GPIO 0x44000100 0x0000102f pin 120 (SSP2_SCLK) 120:INT344B:00 GPIO 0x44000200 0x00001030 pin 121 (SSP2_SFRM) 121:INT344B:00 GPIO 0x44000200 0x00001031 pin 122 (SSP2_TXD) 122:INT344B:00 GPIO 0x44000200 0x00001032 pin 123 (SSP2_RXD) 123:INT344B:00 GPIO 0x44000200 0x00001033 pin 124 (I2C2_SDA) 124:INT344B:00 mode 1 0x44000702 0x02000034 pin 125 (I2C2_SCL) 125:INT344B:00 mode 1 0x44000702 0x02000035 pin 126 (I2C3_SDA) 126:INT344B:00 GPIO 0x44000201 0x00001036 pin 127 (I2C3_SCL) 127:INT344B:00 GPIO 0x82800102 0x00003037 pin 128 (I2C4_SDA) 128:INT344B:00 GPIO 0x40080100 0x00000038 pin 129 (I2C4_SCL) 129:INT344B:00 GPIO 0x44000201 0x00003039 pin 130 (I2C5_SDA) 130:INT344B:00 GPIO 0x44000200 0x0000103a pin 131 (I2C5_SCL) 131:INT344B:00 GPIO 0x44000201 0x0000003b pin 132 (EMMC_CMD) 132:INT344B:00 mode 1 0x44000700 0x0000003c pin 133 (EMMC_DATA_0) 133:INT344B:00 mode 1 0x44000700 0x0000003d pin 134 (EMMC_DATA_1) 134:INT344B:00 mode 1 0x44000700 0x0000003e pin 135 (EMMC_DATA_2) 135:INT344B:00 mode 1 0x44000700 0x0000003f pin 136 (EMMC_DATA_3) 136:INT344B:00 mode 1 0x44000700 0x00000040 pin 137 (EMMC_DATA_4) 137:INT344B:00 mode 1 0x44000700 0x00000041 pin 138 (EMMC_DATA_5) 138:INT344B:00 mode 1 0x44000700 0x00000042 pin 139 (EMMC_DATA_6) 139:INT344B:00 mode 1 0x44000700 0x00000043 pin 140 (EMMC_DATA_7) 140:INT344B:00 mode 1 0x44000700 0x00000044 pin 141 (EMMC_RCLK) 141:INT344B:00 mode 1 0x44000700 0x00000045 pin 142 (EMMC_CLK) 142:INT344B:00 mode 1 0x44000700 0x00000046 pin 143 (GPP_F_23) 143:INT344B:00 GPIO 0x44000200 0x00001047 pin 144 (SD_CMD) 144:INT344B:00 mode 1 0x44000700 0x00000048 pin 145 (SD_DATA_0) 145:INT344B:00 mode 1 0x44000700 0x00000049 pin 146 (SD_DATA_1) 146:INT344B:00 mode 1 0x44000700 0x0000004a pin 147 (SD_DATA_2) 147:INT344B:00 mode 1 0x44000700 0x0000004b pin 148 (SD_DATA_3) 148:INT344B:00 mode 1 0x44000700 0x0000004c pin 149 (SD_CDB) 149:INT344B:00 mode 1 0x44000702 0x0000304d pin 150 (SD_CLK) 150:INT344B:00 mode 1 0x44000700 0x0000004e pin 151 (SD_WP) 151:INT344B:00 mode 1 0x44000700 0x0000004f -- Best regards, Marek Vasut
On Sat, Jun 21, 2025 at 07:33:41PM +0200, Marek Vasut wrote: > On 6/16/25 1:09 PM, Andy Shevchenko wrote: > > > > You can try to monitor the /sys/kernel/debug/pinctrl/*/pins files for any > > > > changes that might happen on the sensor events. It might (help to) reveal > > > > the IRQ line. > > > Sooo ... if the IRQ line is not described in ACPI, it could still be > > > connected ? Hum, I'll try to shake the laptop next time I power it up. > > > > Yes, it's possible, unfortunately due to the closed / per-product > > nature of the Windows drivers. > > This is the only pins I got out of this, and there doesn't seem to be > anything changing if I shake the machine: Yeah, it's kinda hard to catch in case it's an edge triggered interrupt. But for level shouldn't be that hard and it seems there is no luck so far. :-( That said, the best workaround now is what Hans suggested. -- With Best Regards, Andy Shevchenko
On Fri, 13 Jun 2025 19:02:28 +0200
Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/13/25 5:09 PM, Andy Shevchenko wrote:
> > Strange I don't see Hans in the Cc list, so added.
> > Thanks for the report and patch, my comments below.
> >
> > On Fri, Jun 13, 2025 at 02:45:22PM +0200, Marek Vasut wrote:
> >> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> >> which leads to bmc150_accel_core_probe() being called with irq=0, which
> >> leads to bmc150_accel_interrupts_setup() never being called, which leads
> >> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> >> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> >> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> >> non-NULL, and which triggers NULL pointer dereference. This is triggered
> >> e.g. from iio-sensor-proxy.
> >>
> >> Fix this by skipping the IRQ register configuration in case there is no
> >> IRQ connected in hardware, in a manner similar to what the driver did in
> >> the very first commit which added the driver.
> >>
> >> ACPI table dump:
> >
> >> Device (BMA2)
> >> {
> >> Name (_ADR, Zero) // _ADR: Address
> >> Name (_HID, "BOSC0200") // _HID: Hardware ID
> >> Name (_CID, "BOSC0200") // _CID: Compatible ID
> >> Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
> >> Name (_UID, One) // _UID: Unique ID
> >> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> >> {
> >> Name (RBUF, ResourceTemplate ()
> >> {
> >> I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
> >> AddressingMode7Bit, "\\_SB.PCI0.I2C0",
> >> 0x00, ResourceConsumer, , Exclusive,
> >> )
> >> })
> >> Return (RBUF) /* \_SB_.PCI0.I2C0.BMA2._CRS.RBUF */
> >> }
> >
> > These lines...
> >
> >> Method (ROTM, 0, NotSerialized)
> >> {
> >> Name (SBUF, Package (0x03)
> >> {
> >> "0 1 0",
> >> "1 0 0 ",
> >> "0 0 1"
> >> })
> >> Return (SBUF) /* \_SB_.PCI0.I2C0.BMA2.ROTM.SBUF */
> >> }
> >>
> >> Method (_STA, 0, NotSerialized) // _STA: Status
> >> {
> >> Return (0x0F)
> >> }
> >
> > ...are irrelevant.
> >
> >> }
> >> "
> >>
> >> Splat, collected from debian unstable, probably not very useful:
> >
> > Oh my gosh, please leave only ~3-5 *important* lines out of this, or move it
> > completely to the comment block (after '---' cutter line).
> >
> > This is requirement written in Submitting Patches.
> >
> > ...
> >
> > As for the solution, are you sure the line is not wired at all?
>
> No . It is some cheap mini-laptop , I have no schematics or any other
> info really .
>
> Note that I am not really familiar with x86 and ACPI, so there is that.
>
> > IIRC Hans had a broken tales where it was simply forgotten, meaning
> > the Android / Windows driver simply hardcoded needed info.
> >
> > If it's the case, it should be solved differently around PDx86 special quirk
> > driver for the cases like this.
> There are likely two issues.
>
> First, this driver needs to handle i2c_client->irq == 0 correctly if it
> should work without IRQ line, which the driver seems to indicate that it
> does. The current crashing the kernel is not the correct way of handling
> that. That's this patch, in some form.
Hi Marek,
For this, the driver shouldn't be giving the impression it can do either
events or fifo based capture if it doesn't have an irq.
(the fifo case could be made to work but that's a complex job).
Right now the driver only correctly doesn't initialize a trigger
for data ready use when the interrupt isn't there - it does all the
rest unconditionally :(
Usual way to do that is to have two iio_info structures and chan spec
arrays and pick between them. That should remove any chance of getting
to the code that messes with the interrupts. It seems to be using
the watermark setting to mess with the fifo interrupt so hiding that
as well in the info structure should block that one and anything that
indicates there might be a fifo.
What you have here stops it crashing and is sensible defence in depth
but cutting off the pointless paths at the top is also needed
to avoid giving userspace the wrong impression.
Jonathan
>
> Second, if this laptop has some IRQ line for this chip hidden somewhere,
> then it might need a quirk of sorts, sure. Is there some way to find
> out, without taking the thing apart and poking around with a scope ?
On 6/13/25 7:45 AM, Marek Vasut wrote: > The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables, > which leads to bmc150_accel_core_probe() being called with irq=0, which > leads to bmc150_accel_interrupts_setup() never being called, which leads > to struct bmc150_accel_data *data ->interrupts[i].info being left unset > to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt() > which depends on struct bmc150_accel_data *data ->interrupts[i].info being > non-NULL, and which triggers NULL pointer dereference. This is triggered > e.g. from iio-sensor-proxy. Is the interrupt not wired up or is it just missing from the table? > > Fix this by skipping the IRQ register configuration in case there is no > IRQ connected in hardware, in a manner similar to what the driver did in > the very first commit which added the driver. > ... > diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c > index 744a034bb8b5..1c3583ade2b4 100644 > --- a/drivers/iio/accel/bmc150-accel-core.c > +++ b/drivers/iio/accel/bmc150-accel-core.c > @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i, > if (ret < 0) > return ret; > A comment here explaining why this is needed and what the consequences are would be helpful. The obvious one to me is that we won't get events even when events are enabled. It isn't so clear to me though what happens if the watermark interrupt isn't enabled during buffered reads. > + if (!info) > + return 0; > + > /* map the interrupt to the appropriate pins */ > ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask, > (state ? info->map_bitmask : 0));
+Hans here as well. On Fri, Jun 13, 2025 at 10:03:34AM -0500, David Lechner wrote: > On 6/13/25 7:45 AM, Marek Vasut wrote: > > The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables, > > which leads to bmc150_accel_core_probe() being called with irq=0, which > > leads to bmc150_accel_interrupts_setup() never being called, which leads > > to struct bmc150_accel_data *data ->interrupts[i].info being left unset > > to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt() > > which depends on struct bmc150_accel_data *data ->interrupts[i].info being > > non-NULL, and which triggers NULL pointer dereference. This is triggered > > e.g. from iio-sensor-proxy. > > Is the interrupt not wired up or is it just missing from the table? Same Q I just asked :-) -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.