Messages in this thread | | | Date | Sat, 30 Sep 2023 17:17:58 +0100 | From | Jonathan Cameron <> | Subject | Re: [RFC 2/2] iio: imu: Add driver for BMI323 IMU |
| |
On Fri, 29 Sep 2023 13:29:13 +0530 Jagath Jog J <jagathjog1996@gmail.com> wrote:
> Hi Denis, > > On Thu, Sep 28, 2023 at 2:55 AM Denis Benato <benato.denis96@gmail.com> wrote: > > > > Hello, > > > > Some devices (as my asus rog ally) have an ACPI node describing a BOSC0200 sensor. The IC being used in those devices is a bmi323 but as a result of how the ACPI table reports that device, it is detected by the existing kernel module and we have no way of differentiating until after the chip ID probe. > > > > The module loaded is bmc150-accel-i2c.c which currently doesn't support the bmi323 and the loading of the module just fails at chip check. > > bmc150 driver supports multiple accelerometer sensors such as > bma222, bma280, bmi055 and all of them are having similar > register map, but the bmi323 register map is completely different > from bmc150.
Horrible bios hacks that depend on a particular driver stack are always a pain.
Hmm. Andy (handy ACPI expert), any suggestion?
We could maybe do a wrapper driver that does appropriate checks and wraps the probe + remove from the two drivers? Whilst we can obviously have a single driver that deals with radically different devices I'm not particularly keen on that as it tends to make things less maintainable.
Jonathan
> > > > > > I have solved the problem by expanding the current bmc150-accel-i2c.c and bmc150-accel-core.c files to handle that IC in almost every part: gyroscope, accelerometer and temperature sensor. > > > > What is the best way of organizing code to have this module mainlined? Is it correct leaving files called bmc150-accel-* even if it is managing another IC and and not just the accelerometer part anymore? > > > > TIA for your time. > > > > Best regards, > > Denis Benato > > Regards > > Jagath
| |