Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)

From: Hans de Goede
Date: Wed Feb 01 2023 - 10:47:33 EST

Next message: Konrad Dybcio: "Re: [PATCH 2/3] arm64: dts: qcom: sm8350-hdk: correct LT9611 pin function"
Previous message: Konrad Dybcio: "Re: [PATCH 1/3] arm64: dts: qcom: sm8350-hdk: align pin config node names with bindings"
In reply to: Darrell Kavanagh: "Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)"
Next in thread: Bastien Nocera: "Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

On 2/1/23 16:03, Darrell Kavanagh wrote:
> Thanks for the info, Hans. I was hoping there'd be something like
> that. Compiling the whole kernel on this little machine will be
> interesting, though...

I usually build on a big machine and then also run "sudo make modules_install"
on the big machine (which normally will not conflict with distor kernels
since they have extra info in their version number) and then I do e.g.:

# on big machine:
make -j15 bzImage && make -j15 modules && sudo make modules_install

# on target, as root:
mkdir /lib/modules/6.2.0-rc6+

# on big machine
cd /lib/modules/6.2.0-rc6+/
scp -pr kernel modules.* root@192.168.1.97:/lib/modules/6.2.0-rc6+/
cd ~/projects/linux
cp arch/x86/boot/bzImage root@192.168.1.97:/boot/vmlinuz-6.2.0-rc6+

# on target, as root:
kernel-install add 6.2.0-rc6+ /boot/vmlinuz-6.2.0-rc6+

I believe you can also pass an alternate install location for the
modules, then you also don't need the sudo for the make modules_install,
but I tend to dogfood my own kernel tree on my $big-desktop-machine,
so I actually want the modules in /lib/modules/$version/ ...

Regards,

Hans

> On Wed, 1 Feb 2023 at 11:01, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>> Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote:
>>>
>>>> Hello, all.
>>>>
>>>> I've finally reached a conclusion on this, after testing all the
>>>> combinations of the patches (with and without reading the acpi
>>>> mounting matrix), window managers (wayland, xorg) and the presence or
>>>> not of my custom kernel parms.
>>>>
>>>> What works well is the full set of patches with the custom kernel
>>>> parms and a new hwdb entry for the sensor:
>>>>
>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>> ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>
>>>> The autorotate then works correctly in wayland and xorg, but for xorg,
>>>> the settings say the screen is "portrait left" when in actual fact it
>>>> is in standard laptop landscape orientation. Wayland does not have
>>>> this problem (I guess because wayland's view of the screen is straight
>>>> from the kernel).
>>>>
>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>> using the acpi matrix and 180 degrees out when using it. I could have
>>>> gone either way here with appropriate hwdb entries, but my view is
>>>> that we *should* be using the matrix.
>>>
>>> Added Hans de Goede as he has probably run into more of this mess
>>> than anyone else. Hans, any thoughts on if we are doing something
>>> wrong on kernel side? Or is the matrix just wrong *sigh*
>>
>> I see below that this laptop has a panel which is mounted 90 degrees
>> rotated, that likely explains why the ACPI matrix does not work.
>> So the best thing to do here is to just override it with a hwdb entries.
>>
>> IIRC there are already 1 or 2 other hwdb entries which actually
>> override the ACPI provided matrix because of similar issues.
>>
>> Linux userspace expects the matrix in this case to be set so that
>> it causes e.g. gnome's auto-rotation to put the image upright
>> even with older gnome versions / mate / xfce which don't know about
>> the panel being mounted 90 degrees.
>>
>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>> while the device is actually in normal clamshell mode with the
>> display up-right.
>>
>> This reporting of left-side-up or right-side-up is actually "correct"
>> looking from the native LCD panel orientation and as mentioned is
>> done for backward compatibility. This is documented here:
>>
>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>
>> The way we are handling this is likely incompatible with how Windows
>> handles this special case of 90° rotated screen + ROTM. Or the
>> matrix in the ACPI tables could be just wrong...
>>
>>> I think 'ROTM' is defined by MS.
>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>
>> Right and as such it would be good if we can still add support to
>> it to the sensor driver in question. Because the ROTM info usually
>> is correct and avoids the need for adding more and more hwdb entries.
>>
>> Note there already is existing support in some other sensor drivers.
>>
>> So we probably need to factor out some helper code for this and share
>> that between sensor drivers.
>>
>>
>>>> The only thing that concerns me is the need for custom kernel parms.
>>>> It would be better if there was a way to avoid this, so that the user
>>>> didn't have to mess around with their grub config. Though having said
>>>> that, the sensors fix as we have it doesn't make things worse - under
>>>> currently released kernels the screen always starts up sideways unless
>>>> custom parms are added in grub.
>>
>> We actually have a quirk mechanism in the kernel for specifying
>> the need for: video=DSI-1:panel_orientation=right_side_up and this
>> will also automatically fix the fbcon orientation, see:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>
>> If you submit a patch for this upstream please Cc me.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>
>>
>>>>> On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>>>>>>
>>>>>> On Mon, 30 Jan 2023 20:02:31 +0000
>>>>>> Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Thanks. To be clear, before I changed the grub command line, the
>>>>>>> system always booted up "sideways", even when the sensor was not being
>>>>>>> detected. This was true for everything, not just Gnome, except grub
>>>>>>> itself.
>>>>>>>
>>>>>>> I added:
>>>>>>>
>>>>>>> GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
>>>>>>> video=DSI-1:panel_orientation=right_side_up quiet splash"
>>>>>>>
>>>>>>> This fixed the orientation for pre-splash boot messages, the splash
>>>>>>> screen and the desktop environment. But not, for example (as I saw
>>>>>>> after adding my own module signing key for testing your fixes), the
>>>>>>> MOK validation screens.
>>>>>>>
>>>>>>> Does this make sense?
>>>>>>>
>>>>>>> Does what you are proposing act at a lower level than changing the
>>>>>>> systemd hwdb orientation matrix?
>>>>>>
>>>>>> I'm not sure on the userspace side of things, but intent is that
>>>>>> it will provide the orientation data to any users - though only after
>>>>>> the kernel boots and software needs to be aware of it. Give it a go,
>>>>>> and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
>>>>>>
>>>>>> For Bastien - patches for kernel side are:
>>>>>> https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@xxxxxxxxxx/T/#t
>>>>>>
>>>>>> Darrell is going to test them after back porting to 6.1.
>>>>>> With the first patch he gets the right result in gnome but we weren't
>>>>>> picking up the rotation matrix at that point (ROTM in ACPI).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Darrell
>>>>>>>
>>>>>>> On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> On Mon, 30 Jan 2023 18:32:02 +0000
>>>>>>>> Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
>>>>>>>>> <Jonathan.Cameron@xxxxxxxxxx> wrote:
>>>>>>>>>
>>>>>>>>>> That certainly looks like suitable matrix.
>>>>>>>>>>
>>>>>>>>>> If we are lucky it matches the handling in bmc150-accel-core.c for an identically
>>>>>>>>>> named method. That is going to swap the x and y axis which is I'd have thought would
>>>>>>>>>> be rather bad if what you have is currently working well.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually, that would be good, because at present I have to rotate 90
>>>>>>>>> degrees in my grub command line.
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I'll see if I can roll a suitable patch.
>>>>>>>>
>>>>>>>> Jonathan
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Darrell
>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Method (PRIM, 0, NotSerialized)
>>>>>>>>>>> {
>>>>>>>>>>> Name (RBUF, Buffer (One)
>>>>>>>>>>> {
>>>>>>>>>>> 0x01 // .
>>>>>>>>>>> })
>>>>>>>>>>> Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Method (_STA, 0, NotSerialized) // _STA: Status
>>>>>>>>>>> {
>>>>>>>>>>> If ((GAVT == 0x6A))
>>>>>>>>>>> {
>>>>>>>>>>> Return (0x0F)
>>>>>>>>>>> }
>>>>>>>>>>> Else
>>>>>>>>>>> {
>>>>>>>>>>> Return (Zero)
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Method (CALS, 1, NotSerialized)
>>>>>>>>>>> {
>>>>>>>>>>> Local0 = Arg0
>>>>>>>>>>> If (((Local0 == Zero) || (Local0 == Ones)))
>>>>>>>>>>> {
>>>>>>>>>>> Local0 = BAC1 /* \BAC1 */
>>>>>>>>>>> Return (Local0)
>>>>>>>>>>> }
>>>>>>>>>>> Else
>>>>>>>>>>> {
>>>>>>>>>>> BAC1 = Local0
>>>>>>>>>>> BACS = Local0
>>>>>>>>>>> BSCA (0xB0)
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Darrell
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
>>>>>>>>>>> <Jonathan.Cameron@xxxxxxxxxx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 30 Jan 2023 03:37:23 +0000
>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Forwarding because original html messages were rejected by the server...
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>> From: Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx>
>>>>>>>>>>>>> Date: Mon, 30 Jan 2023 at 02:52
>>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST
>>>>>>>>>>>>> Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>>>> To: Jonathan Cameron <jic23@xxxxxxxxxx>
>>>>>>>>>>>>> Cc: <lorenzo@xxxxxxxxxx>, <lars@xxxxxxxxxx>,
>>>>>>>>>>>>> <linux-iio@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>,
>>>>>>>>>>>>> <carnil@xxxxxxxxxx>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
>>>>>>>>>>>>> that 6.2 includes some i2c enhancements), but I adapted your changes
>>>>>>>>>>>>> to fit my Debian 6.1 kernel and it works. Two IIO devices are created
>>>>>>>>>>>>> in sysfs, iio-sensor-proxy.service starts up and automatic screen
>>>>>>>>>>>>> rotation in Gnome just works.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To get the modules to load on boot, I made a small change to your code
>>>>>>>>>>>>> in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
>>>>>>>>>>>>>
>>>>>>>>>>>>> adding a null element to st_lsm6dsx_i2c_acpi_match:
>>>>>>>>>>>>> static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>>> { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>>> { },
>>>>>>>>>>>>> };
>>>>>>>>>>>>> then:
>>>>>>>>>>>>> MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
>>>>>>>>>>>>
>>>>>>>>>>>> doh! That was indeed sloppy of me to miss even for an untested hack.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> dmesg shows:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
>>>>>>>>>>>>> using dummy regulator
>>>>>>>>>>>>> [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
>>>>>>>>>>>>> using dummy regulator
>>>>>>>>>>>>> [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
>>>>>>>>>>>>> found: using identity...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is this a problem?
>>>>>>>>>>>>
>>>>>>>>>>>> Those are all fine. For regulators that's expected on ACPI and should
>>>>>>>>>>>> be harmless as it's up to the firmware to manage power (in DT it may
>>>>>>>>>>>> be up to the kernel).
>>>>>>>>>>>> For the mounting matrix, there is often something in ACPI DSDT
>>>>>>>>>>>> (non standard though). Could you
>>>>>>>>>>>> cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
>>>>>>>>>>>> then run through iasl from acpitools
>>>>>>>>>>>> iasl -d ~/dsdt
>>>>>>>>>>>> and find the bit related to this device.
>>>>>>>>>>>>
>>>>>>>>>>>> If you can then share that there may be a _DSM or similar in there that
>>>>>>>>>>>> is effectively the mounting matrix. If we are lucky it will look like
>>>>>>>>>>>> some existing versions we have code to handle and can add that support
>>>>>>>>>>>> as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Either way - I'll spin a formal patch with your fixes above and we can
>>>>>>>>>>>> get this upstream for future kernels. Mounting matrix can follow
>>>>>>>>>>>> later if needed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Darrell
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, 29 Jan 2023 17:03:51 +0000
>>>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I raised this bug in Debian, and have been asked to raise it upstream and
>>>>>>>>>>>>>>> was given your addresses to do so. Will this email be OK, or should I raise
>>>>>>>>>>>>>>> it in a bug tracking system somewhere?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Email is the right option.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>> Darrell
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>>>> From: Salvatore Bonaccorso <carnil@xxxxxxxxxx>
>>>>>>>>>>>>>>> Date: Sat, 28 Jan 2023 at 20:33
>>>>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
>>>>>>>>>>>>>>> LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>>>>>> To: Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx>, <1029850@xxxxxxxxxxxxxxx>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Darrell,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
>>>>>>>>>>>>>>>> Package: src:linux
>>>>>>>>>>>>>>>> Version: 6.1.4-1
>>>>>>>>>>>>>>>> Severity: normal
>>>>>>>>>>>>>>>> File: linux
>>>>>>>>>>>>>>>> X-Debbugs-Cc: darrell.kavanagh@xxxxxxxxx
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dear Maintainer,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is a convertable touchscreen tablet/laptop. The rotation sensor
>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>> ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>> sysfs trees are created at
>>>>>>>>>>>>>>> devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
>>>>>>>>>>>>>>>> and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
>>>>>>>>>>>>>>>> symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> no driver is loaded.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At least this is using the ST PNP ID which is better than average
>>>>>>>>>>>>>> (long story!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> does not currently have an ACPI support. It should be straight forwards
>>>>>>>>>>>>>> to add though the driver first needs converting to use
>>>>>>>>>>>>>> device_get_match_data() with appropriate fallback so that it will match on
>>>>>>>>>>>>>> ACPI, OF or original spi_device_id tables
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Completely untested but something like the following
>>>>>>>>>>>>>> (the offset in the enum is needed to allow us to tell if we got a result when
>>>>>>>>>>>>>> calling device_get_match_data() as it returns NULL on failure IIRC)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure how sucessful the driver will be at finding any interrupts etc, but
>>>>>>>>>>>>>> it may get you basic functionality.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Good luck and others more familiar with the driver may well tell me what I forgot
>>>>>>>>>>>>>> when hacking the below ;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> index 499fcf8875b4..2617ce236ddc 100644
>>>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> @@ -39,7 +39,7 @@
>>>>>>>>>>>>>> #define ST_ISM330IS_DEV_NAME "ism330is"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> enum st_lsm6dsx_hw_id {
>>>>>>>>>>>>>> - ST_LSM6DS3_ID,
>>>>>>>>>>>>>> + ST_LSM6DS3_ID = 1,
>>>>>>>>>>>>>> ST_LSM6DS3H_ID,
>>>>>>>>>>>>>> ST_LSM6DSL_ID,
>>>>>>>>>>>>>> ST_LSM6DSM_ID,
>>>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> index df5f60925260..ecfceb2fb3db 100644
>>>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> - const struct i2c_device_id *id = i2c_client_get_device_id(client);
>>>>>>>>>>>>>> - int hw_id = id->driver_data;
>>>>>>>>>>>>>> + int hw_id;
>>>>>>>>>>>>>> struct regmap *regmap;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> + hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
>>>>>>>>>>>>>> + if (!hw_id)
>>>>>>>>>>>>>> + hw_id = i2c_client_get_device_id(client)->driver_data;
>>>>>>>>>>>>>> + if (!hw_id)
>>>>>>>>>>>>>> + return -EINVAL;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
>>>>>>>>>>>>>> if (IS_ERR(regmap)) {
>>>>>>>>>>>>>> dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
>>>>>>>>>>>>>> @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>>>> + { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
>>>>>>>>>>>>>> { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
>>>>>>>>>>>>>> { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
>>>>>>>>>>>>>> @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
>>>>>>>>>>>>>> .name = "st_lsm6dsx_i2c",
>>>>>>>>>>>>>> .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
>>>>>>>>>>>>>> .of_match_table = st_lsm6dsx_i2c_of_match,
>>>>>>>>>>>>>> + .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
>>>>>>>>>>>>>> },
>>>>>>>>>>>>>> .probe_new = st_lsm6dsx_i2c_probe,
>>>>>>>>>>>>>> .id_table = st_lsm6dsx_i2c_id_table,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The device is identifying itself to the kernel with PNP id SMO8B30:
>>>>>>>>>>>>>>>> physical_node:
>>>>>>>>>>>>>>>> modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>> name=SMO8B30:00
>>>>>>>>>>>>>>>> uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>> waiting_for_supplier=0
>>>>>>>>>>>>>>>> firmware_node:
>>>>>>>>>>>>>>>> hid=SMO8B30
>>>>>>>>>>>>>>>> modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>> path=\_SB_.PCI0.I2C5.DEV_
>>>>>>>>>>>>>>>> status=15
>>>>>>>>>>>>>>>> uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>> uid=0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
>>>>>>>>>>>>>>> loaded on boot.
>>>>>>>>>>>>>>>> Modprobing it does not associate it with the device, as I would expect as
>>>>>>>>>>>>>>>> the module does not provide an alias for the above acpi/pnp id.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you report this issue upstream? Gues to reach out are according to
>>>>>>>>>>>>>>> get_maintainers.pl script:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lorenzo Bianconi <lorenzo@xxxxxxxxxx> (maintainer:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>>>> Jonathan Cameron <jic23@xxxxxxxxxx> (maintainer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>>>> Lars-Peter Clausen <lars@xxxxxxxxxx> (reviewer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>>>> linux-iio@xxxxxxxxxxxxxxx (open list:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>>>> linux-kernel@xxxxxxxxxxxxxxx (open list)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please keep us in the loop.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Salvatore
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
>

Next message: Konrad Dybcio: "Re: [PATCH 2/3] arm64: dts: qcom: sm8350-hdk: correct LT9611 pin function"
Previous message: Konrad Dybcio: "Re: [PATCH 1/3] arm64: dts: qcom: sm8350-hdk: align pin config node names with bindings"
In reply to: Darrell Kavanagh: "Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)"
Next in thread: Bastien Nocera: "Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]