lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 30 Sep 2023 17:17:58 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Jagath Jog J <jagathjog1996@...il.com>
Cc:     Denis Benato <benato.denis96@...il.com>,
        andriy.shevchenko@...ux.intel.com, lars@...afoo.de,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
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@...il.com> wrote:

> Hi Denis,
> 
> On Thu, Sep 28, 2023 at 2:55 AM Denis Benato <benato.denis96@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ