BMI0160/260 conflicts

BMI0160/260 conflicts

[Derek John Clark]

Greetings,

I have identified a trend where handheld PC manufacturers, primarily
from China, are not properly identifying the IMU's in their device
DSDT's. I was hoping to start a dialogue on possible remediation at
the kernel level as I only imagine this issue compounding further. I
have an idea of the solution, but considering the amount of work for
it I at least wanted to see what the general thoughts of the
maintainers were first.  My apologies for the length here, I have done
quite a bit of investigation before reaching out as I wanted to have
all my ducks in a row.

Background:
The first instance was AYANEO with their founders edition & 2021
models using 10EC5280 instead of BMI0160. A kernel patch was submitted
a while back that ultimately stalled for this being considered
incorrect. For context:
https://lore.kernel.org/all/Yfqv8V6fZBnG5J5H@smile.fi.intel.com/

Unfortunately the issue has only compounded with time. GPD has been
shipping their WinMax2 with 10EC5280 in the DSDT, and the early GPD
Win4 prototypes sent out are using the same despite it actually having
a BMI0260, which isn't currently supported in the kernel.

Three other manufacturers are using BMI0160 in their DSDT when they
have a BMI0260. Specifically, the Aya Neo AIR Pro (5825u model), OXP
Mini Pro, and AOKZOE A1 are all guilty of this. Unfortunately this IMU
isn't a complete drop in replacement. While it uses some of the same
registers, many are different. I won't go too into the weeds, but for
this discussion the most important is that the CHIP_ID uses the same
registers but is reported 0x27 on the BMI0260's while the BMI0160's
are 0x1d. Based on all these findings I don't believe it is possible
to have a separate bmi260 driver.

Remediation:
I have reached out to the aforementioned companies about releasing
updated BIOS for each of the respective models to correct the DSDT
ID's. AYANEO and GPD seem receptive as they have each provided beta
BIOS for testing. There are still plenty of devices in the wild
however that will likely not be fixed, and there's no telling what
will be created in the future considering the rapid growth in this
market. OneNet forwarded the concern to the OXP/AOK engineering team
but have not provided comment at this time.

I think the only reliable way to resolve this effectively would be to
utilize the IMU reported chip ID to actually identify which device is
present, using the ACPI ID as an entry point for the driver. This
would likely require some redesign of the driver, wherein all common
functionality between chips would exist in the existing bmi160_core to
ensure backwards compatibility. This would essentially become the
entry point where all three ACPI IDs trigger a read of the CHIP_ID
before splitting off to load IMU specific registers and functions.

This is similar to how ChromiumOS manages these two IMU's, which
incidentally I'm using that driver as the primary source of
information about the 260 since Bosch haven't released a comprehensive
datasheet on it.

Link for the curious, see accelgyro_bmi_x files for reference:
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/driver

Thank you for your time, I await your feedback.

Re: BMI0160/260 conflicts

[Jonathan Cameron]

On Sat, 7 Jan 2023 19:51:59 -0800
Derek John Clark <derekjohn.clark@gmail.com> wrote:

> Greetings,
> 
> I have identified a trend where handheld PC manufacturers, primarily
> from China, are not properly identifying the IMU's in their device
> DSDT's. I was hoping to start a dialogue on possible remediation at
> the kernel level as I only imagine this issue compounding further. I
> have an idea of the solution, but considering the amount of work for
> it I at least wanted to see what the general thoughts of the
> maintainers were first.  My apologies for the length here, I have done
> quite a bit of investigation before reaching out as I wanted to have
> all my ducks in a row.
> 
> Background:
> The first instance was AYANEO with their founders edition & 2021
> models using 10EC5280 instead of BMI0160. A kernel patch was submitted
> a while back that ultimately stalled for this being considered
> incorrect. For context:
> https://lore.kernel.org/all/Yfqv8V6fZBnG5J5H@smile.fi.intel.com/
> 
> Unfortunately the issue has only compounded with time. GPD has been
> shipping their WinMax2 with 10EC5280 in the DSDT, and the early GPD
> Win4 prototypes sent out are using the same despite it actually having
> a BMI0260, which isn't currently supported in the kernel.
> 
> Three other manufacturers are using BMI0160 in their DSDT when they
> have a BMI0260. Specifically, the Aya Neo AIR Pro (5825u model), OXP
> Mini Pro, and AOKZOE A1 are all guilty of this. Unfortunately this IMU
> isn't a complete drop in replacement. While it uses some of the same
> registers, many are different. I won't go too into the weeds, but for
> this discussion the most important is that the CHIP_ID uses the same
> registers but is reported 0x27 on the BMI0260's while the BMI0160's
> are 0x1d. Based on all these findings I don't believe it is possible
> to have a separate bmi260 driver.
> 
> Remediation:
> I have reached out to the aforementioned companies about releasing
> updated BIOS for each of the respective models to correct the DSDT
> ID's. AYANEO and GPD seem receptive as they have each provided beta
> BIOS for testing. 

Great.  Hopefully that means that the scope of problem devices from
these manufacturers is not going to grow too much going forwards!

> There are still plenty of devices in the wild
> however that will likely not be fixed, and there's no telling what
> will be created in the future considering the rapid growth in this
> market. OneNet forwarded the concern to the OXP/AOK engineering team
> but have not provided comment at this time.
> 
> I think the only reliable way to resolve this effectively would be to
> utilize the IMU reported chip ID to actually identify which device is
> present, using the ACPI ID as an entry point for the driver. This
> would likely require some redesign of the driver, wherein all common
> functionality between chips would exist in the existing bmi160_core to
> ensure backwards compatibility. This would essentially become the
> entry point where all three ACPI IDs trigger a read of the CHIP_ID
> before splitting off to load IMU specific registers and functions.

Whilst it's previously been more common to see a mess on this front for
DT, we do have drivers that use the 'compatible' as more of a hint than
anything else.  The approach being.

1) Check for the chip ID matching the expected.  All good use that.
2) Check for a match against other known IDs.  Print a warning message
   but use the values for the right device.
3) If no match, use the values for the compatible originally given.
   The reasoning behind this is that new devices might come along that
   are truely backwards compatible, but include extra features.
   We want them to work with the supported features out of the box
   so the dts includes a fallback compatible to the simpler old device.

I have no problem with doing similar for ACPI.  IIRC it even has the
equivalent of fallback compatibles to cover that 3rd case.
For the ACPI case we might have to deny certain fallbacks if we know
they are shipping in devices and are broken (sigh).  Or we only use
the fallback route if the _CID is provided - which is the right way
to do compatible handling in ACPI anyway.

The bigger issue here was that the manufacturers were using the
ID space of a realtech pci device.  I'm not so worried if they just
break things in their own ID spaces but potentially breaking
things for someone else is a big problem.

*Sigh*. Doing this stuff right in the first place is so easy and
the specs are free to anyone etc...

Thanks for your hard work tracking down people who can hopefully
improve what they do next time around.

Jonathan


> 
> This is similar to how ChromiumOS manages these two IMU's, which
> incidentally I'm using that driver as the primary source of
> information about the 260 since Bosch haven't released a comprehensive
> datasheet on it.
> 
> Link for the curious, see accelgyro_bmi_x files for reference:
> https://chromium.googlesource.com/chromiumos/platform/ec/+/master/driver
> 
> Thank you for your time, I await your feedback.

Re: BMI0160/260 conflicts

[Andy Shevchenko]

On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> On Sat, 7 Jan 2023 19:51:59 -0800
> Derek John Clark <derekjohn.clark@gmail.com> wrote:

...

> > Remediation:
> > I have reached out to the aforementioned companies about releasing
> > updated BIOS for each of the respective models to correct the DSDT
> > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > BIOS for testing. 
> 
> Great.  Hopefully that means that the scope of problem devices from
> these manufacturers is not going to grow too much going forwards!

Wow, you have Ayaneo response?! Unbelievable!
If they answering to you, can you ping them on [1] please?

[1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/

-- 
With Best Regards,
Andy Shevchenko

Re: BMI0160/260 conflicts

[Andy Shevchenko]

On Mon, Jan 09, 2023 at 01:38:48PM +0200, Andy Shevchenko wrote:
> On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > On Sat, 7 Jan 2023 19:51:59 -0800
> > Derek John Clark <derekjohn.clark@gmail.com> wrote:

...

> > > Remediation:
> > > I have reached out to the aforementioned companies about releasing
> > > updated BIOS for each of the respective models to correct the DSDT
> > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > BIOS for testing. 
> > 
> > Great.  Hopefully that means that the scope of problem devices from
> > these manufacturers is not going to grow too much going forwards!
> 
> Wow, you have Ayaneo response?! Unbelievable!
> If they answering to you, can you ping them on [1] please?

TL;DR: They are using Realtek's ACPI HID for the Bosch sensor device.

> [1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/

-- 
With Best Regards,
Andy Shevchenko

Re: BMI0160/260 conflicts

[Derek John Clark]

On Mon, Jan 9, 2023 at 3:38 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > On Sat, 7 Jan 2023 19:51:59 -0800
> > Derek John Clark <derekjohn.clark@gmail.com> wrote:
>
> ...
>
> > > Remediation:
> > > I have reached out to the aforementioned companies about releasing
> > > updated BIOS for each of the respective models to correct the DSDT
> > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > BIOS for testing.
> >
> > Great.  Hopefully that means that the scope of problem devices from
> > these manufacturers is not going to grow too much going forwards!
>
> Wow, you have Ayaneo response?! Unbelievable!
> If they answering to you, can you ping them on [1] please?
>
> [1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/
>
> --
> With Best Regards,
> Andy Shevchenko

I've been knocking on this door for a few months now. They recently
sent me a test BIOS with the alleged fix for testing. Hopefully they
do a wide release once it is fully validated.

Re: BMI0160/260 conflicts

[Andy Shevchenko]

On Mon, Jan 09, 2023 at 07:42:01AM -0800, Derek John Clark wrote:
> On Mon, Jan 9, 2023 at 3:38 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > > On Sat, 7 Jan 2023 19:51:59 -0800
> > > Derek John Clark <derekjohn.clark@gmail.com> wrote:

...

> > > > Remediation:
> > > > I have reached out to the aforementioned companies about releasing
> > > > updated BIOS for each of the respective models to correct the DSDT
> > > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > > BIOS for testing.
> > >
> > > Great.  Hopefully that means that the scope of problem devices from
> > > these manufacturers is not going to grow too much going forwards!
> >
> > Wow, you have Ayaneo response?! Unbelievable!
> > If they answering to you, can you ping them on [1] please?
> >
> > [1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/

> I've been knocking on this door for a few months now. They recently
> sent me a test BIOS with the alleged fix for testing. Hopefully they
> do a wide release once it is fully validated.

At least they reacted to your knock, that's why I'm asking you to ping them so
they would know that they have an issue with the ACPI ID for the accelerometer
device.

-- 
With Best Regards,
Andy Shevchenko

Re: BMI0160/260 conflicts

[Derek John Clark]

They typically communicate through discord or whatsapp. I've sent them
the link for the thread a few times and I've asked for an email
address I can CC on the LKML so we'll see if they provide one. I don't
think this will be an issue, from them at least, in the future. For a
bit of history, the original tablet was designed by a different team
which they were obligated to finish through an IndieGoGo campaign
after the company was bought out halfway through production. All
subsequent releases from AyaNeo (7 models by my count) have all used
the BMI0160 ACPI ID. I'm personally more concerned personally with GPD
having released new products over a year later using the same Realtek
ACPI ID, and currently sending out engineering sample units of a
second model. I've included my GPD contact in this thread for their
awareness.

On Mon, Jan 9, 2023 at 9:29 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Jan 09, 2023 at 07:42:01AM -0800, Derek John Clark wrote:
> > On Mon, Jan 9, 2023 at 3:38 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > > > On Sat, 7 Jan 2023 19:51:59 -0800
> > > > Derek John Clark <derekjohn.clark@gmail.com> wrote:
>
> ...
>
> > > > > Remediation:
> > > > > I have reached out to the aforementioned companies about releasing
> > > > > updated BIOS for each of the respective models to correct the DSDT
> > > > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > > > BIOS for testing.
> > > >
> > > > Great.  Hopefully that means that the scope of problem devices from
> > > > these manufacturers is not going to grow too much going forwards!
> > >
> > > Wow, you have Ayaneo response?! Unbelievable!
> > > If they answering to you, can you ping them on [1] please?
> > >
> > > [1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/
>
> > I've been knocking on this door for a few months now. They recently
> > sent me a test BIOS with the alleged fix for testing. Hopefully they
> > do a wide release once it is fully validated.
>
> At least they reacted to your knock, that's why I'm asking you to ping them so
> they would know that they have an issue with the ACPI ID for the accelerometer
> device.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: BMI0160/260 conflicts

[Andy Shevchenko]

On Mon, Jan 09, 2023 at 11:04:38AM -0800, Derek John Clark wrote:
> They typically communicate through discord or whatsapp. I've sent them
> the link for the thread a few times and I've asked for an email
> address I can CC on the LKML so we'll see if they provide one. I don't
> think this will be an issue, from them at least, in the future. For a
> bit of history, the original tablet was designed by a different team
> which they were obligated to finish through an IndieGoGo campaign
> after the company was bought out halfway through production. All
> subsequent releases from AyaNeo (7 models by my count) have all used
> the BMI0160 ACPI ID. I'm personally more concerned personally with GPD
> having released new products over a year later using the same Realtek
> ACPI ID, and currently sending out engineering sample units of a
> second model. I've included my GPD contact in this thread for their
> awareness.

Thank you very much for this effort!

Btw, feel free to tell them if they need any assistance in ACPI understanding
they may publicly or privately ask me and other Linux kernel developers from
Intel related to ACPI (see MAINTAINERS for that list).

> On Mon, Jan 9, 2023 at 9:29 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Jan 09, 2023 at 07:42:01AM -0800, Derek John Clark wrote:
> > > On Mon, Jan 9, 2023 at 3:38 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > > > > On Sat, 7 Jan 2023 19:51:59 -0800
> > > > > Derek John Clark <derekjohn.clark@gmail.com> wrote:

...

> > > > > > Remediation:
> > > > > > I have reached out to the aforementioned companies about releasing
> > > > > > updated BIOS for each of the respective models to correct the DSDT
> > > > > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > > > > BIOS for testing.
> > > > >
> > > > > Great.  Hopefully that means that the scope of problem devices from
> > > > > these manufacturers is not going to grow too much going forwards!
> > > >
> > > > Wow, you have Ayaneo response?! Unbelievable!
> > > > If they answering to you, can you ping them on [1] please?
> > > >
> > > > [1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/
> >
> > > I've been knocking on this door for a few months now. They recently
> > > sent me a test BIOS with the alleged fix for testing. Hopefully they
> > > do a wide release once it is fully validated.
> >
> > At least they reacted to your knock, that's why I'm asking you to ping them so
> > they would know that they have an issue with the ACPI ID for the accelerometer
> > device.

-- 
With Best Regards,
Andy Shevchenko

Re: Re: BMI0160/260 conflicts

[Andy Shevchenko]

On Wed, Jan 11, 2023 at 09:31:27AM +0800, liudk@softwincn.com wrote:
> HI：
>     We have been verifying the BMI0160 ACPI ID on WIN4. If there is no problem with the verification, it will be updated to WinMax2 synchronously. At present, the feedback is that the chip of BMI 260 under Linux does not seem to be able to use the driver of BMI 160, and we are still trying the latest Linux driver

Thank you for confirming the ID. The devices discussed in the thread [1] below
have the Realtek ID (in accordance with PCI and ACPI specifications). I hope
that that is fixed now.

> 中软赢科技术有限公司
> 软件部     刘德康
> 电话： 18674743475
> 地址： 深圳市南山区软件产业基地4D栋1006
>  
> From: Andy Shevchenko
> Date: 2023-01-10 04:49
> To: Derek John Clark
> CC: Jonathan Cameron; linux-iio; Joaquín Ignacio Aramendía; Hans de Goede; liudk
> Subject: Re: BMI0160/260 conflicts
> On Mon, Jan 09, 2023 at 11:04:38AM -0800, Derek John Clark wrote:
> > They typically communicate through discord or whatsapp. I've sent them
> > the link for the thread a few times and I've asked for an email
> > address I can CC on the LKML so we'll see if they provide one. I don't
> > think this will be an issue, from them at least, in the future. For a
> > bit of history, the original tablet was designed by a different team
> > which they were obligated to finish through an IndieGoGo campaign
> > after the company was bought out halfway through production. All
> > subsequent releases from AyaNeo (7 models by my count) have all used
> > the BMI0160 ACPI ID. I'm personally more concerned personally with GPD
> > having released new products over a year later using the same Realtek
> > ACPI ID, and currently sending out engineering sample units of a
> > second model. I've included my GPD contact in this thread for their
> > awareness.
>  
> Thank you very much for this effort!
>  
> Btw, feel free to tell them if they need any assistance in ACPI understanding
> they may publicly or privately ask me and other Linux kernel developers from
> Intel related to ACPI (see MAINTAINERS for that list).
>  
> > On Mon, Jan 9, 2023 at 9:29 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Jan 09, 2023 at 07:42:01AM -0800, Derek John Clark wrote:
> > > > On Mon, Jan 9, 2023 at 3:38 AM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > >
> > > > > On Sun, Jan 08, 2023 at 11:53:41AM +0000, Jonathan Cameron wrote:
> > > > > > On Sat, 7 Jan 2023 19:51:59 -0800
> > > > > > Derek John Clark <derekjohn.clark@gmail.com> wrote:

...

> > > > > > > Remediation:
> > > > > > > I have reached out to the aforementioned companies about releasing
> > > > > > > updated BIOS for each of the respective models to correct the DSDT
> > > > > > > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > > > > > > BIOS for testing.
> > > > > >
> > > > > > Great.  Hopefully that means that the scope of problem devices from
> > > > > > these manufacturers is not going to grow too much going forwards!
> > > > >
> > > > > Wow, you have Ayaneo response?! Unbelievable!
> > > > > If they answering to you, can you ping them on [1] please?

[1]: https://lore.kernel.org/lkml/CACAwPwYQHRcrabw9=0tvenPzAcwwW1pTaR6a+AEWBF9Hqf_wXQ@mail.gmail.com/

> > > > I've been knocking on this door for a few months now. They recently
> > > > sent me a test BIOS with the alleged fix for testing. Hopefully they
> > > > do a wide release once it is fully validated.
> > >
> > > At least they reacted to your knock, that's why I'm asking you to ping them so
> > > they would know that they have an issue with the ACPI ID for the accelerometer
> > > device.

-- 
With Best Regards,
Andy Shevchenko

Re: BMI0160/260 conflicts

[Derek John Clark]

On Sun, Jan 8, 2023 at 3:40 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sat, 7 Jan 2023 19:51:59 -0800
> Derek John Clark <derekjohn.clark@gmail.com> wrote:
>
> > Greetings,
> >
> > I have identified a trend where handheld PC manufacturers, primarily
> > from China, are not properly identifying the IMU's in their device
> > DSDT's. I was hoping to start a dialogue on possible remediation at
> > the kernel level as I only imagine this issue compounding further. I
> > have an idea of the solution, but considering the amount of work for
> > it I at least wanted to see what the general thoughts of the
> > maintainers were first.  My apologies for the length here, I have done
> > quite a bit of investigation before reaching out as I wanted to have
> > all my ducks in a row.
> >
> > Background:
> > The first instance was AYANEO with their founders edition & 2021
> > models using 10EC5280 instead of BMI0160. A kernel patch was submitted
> > a while back that ultimately stalled for this being considered
> > incorrect. For context:
> > https://lore.kernel.org/all/Yfqv8V6fZBnG5J5H@smile.fi.intel.com/
> >
> > Unfortunately the issue has only compounded with time. GPD has been
> > shipping their WinMax2 with 10EC5280 in the DSDT, and the early GPD
> > Win4 prototypes sent out are using the same despite it actually having
> > a BMI0260, which isn't currently supported in the kernel.
> >
> > Three other manufacturers are using BMI0160 in their DSDT when they
> > have a BMI0260. Specifically, the Aya Neo AIR Pro (5825u model), OXP
> > Mini Pro, and AOKZOE A1 are all guilty of this. Unfortunately this IMU
> > isn't a complete drop in replacement. While it uses some of the same
> > registers, many are different. I won't go too into the weeds, but for
> > this discussion the most important is that the CHIP_ID uses the same
> > registers but is reported 0x27 on the BMI0260's while the BMI0160's
> > are 0x1d. Based on all these findings I don't believe it is possible
> > to have a separate bmi260 driver.
> >
> > Remediation:
> > I have reached out to the aforementioned companies about releasing
> > updated BIOS for each of the respective models to correct the DSDT
> > ID's. AYANEO and GPD seem receptive as they have each provided beta
> > BIOS for testing.
>
> Great.  Hopefully that means that the scope of problem devices from
> these manufacturers is not going to grow too much going forwards!
>
> > There are still plenty of devices in the wild
> > however that will likely not be fixed, and there's no telling what
> > will be created in the future considering the rapid growth in this
> > market. OneNet forwarded the concern to the OXP/AOK engineering team
> > but have not provided comment at this time.
> >
> > I think the only reliable way to resolve this effectively would be to
> > utilize the IMU reported chip ID to actually identify which device is
> > present, using the ACPI ID as an entry point for the driver. This
> > would likely require some redesign of the driver, wherein all common
> > functionality between chips would exist in the existing bmi160_core to
> > ensure backwards compatibility. This would essentially become the
> > entry point where all three ACPI IDs trigger a read of the CHIP_ID
> > before splitting off to load IMU specific registers and functions.
>
> Whilst it's previously been more common to see a mess on this front for
> DT, we do have drivers that use the 'compatible' as more of a hint than
> anything else.  The approach being.
>
> 1) Check for the chip ID matching the expected.  All good use that.
> 2) Check for a match against other known IDs.  Print a warning message
>    but use the values for the right device.
> 3) If no match, use the values for the compatible originally given.
>    The reasoning behind this is that new devices might come along that
>    are truely backwards compatible, but include extra features.
>    We want them to work with the supported features out of the box
>    so the dts includes a fallback compatible to the simpler old device.
>
> I have no problem with doing similar for ACPI.  IIRC it even has the
> equivalent of fallback compatibles to cover that 3rd case.
> For the ACPI case we might have to deny certain fallbacks if we know
> they are shipping in devices and are broken (sigh).  Or we only use
> the fallback route if the _CID is provided - which is the right way
> to do compatible handling in ACPI anyway.

Sounds good. I don't have a timeline right now but I'll start working
on this. Thank you for the feedback.

> The bigger issue here was that the manufacturers were using the
> ID space of a realtech pci device.  I'm not so worried if they just
> break things in their own ID spaces but potentially breaking
> things for someone else is a big problem.
>
> *Sigh*. Doing this stuff right in the first place is so easy and
> the specs are free to anyone etc...

From my experience, these manufacturers don't care about doing things
the right way that much. I've only been able to pressure them into
making changes because their pet projects are Linux based (AyaNeoOS
and a GPD Manjaro fork). Telling them they need to make these changes
to support their own initiatives has been more effective than trying
to explain why they shouldn't break convention. It is interesting
though that two separate companies are using the same incorrect ID. It
would seem they are either stealing from each other, or they used the
same supplier with bad data.

> Thanks for your hard work tracking down people who can hopefully
> improve what they do next time around.
>
> Jonathan




> > This is similar to how ChromiumOS manages these two IMU's, which
> > incidentally I'm using that driver as the primary source of
> > information about the 260 since Bosch haven't released a comprehensive
> > datasheet on it.
> >
> > Link for the curious, see accelgyro_bmi_x files for reference:
> > https://chromium.googlesource.com/chromiumos/platform/ec/+/master/driver
> >
> > Thank you for your time, I await your feedback.
>