On Sun, 13 Oct 2024 13:36:51 -0700
Justin Weiss <justin@xxxxxxxxxxxxxxx> wrote:
> Jonathan Cameron <jic23@xxxxxxxxxx> writes:
>
> >> >> +static const struct acpi_device_id bmi270_acpi_match[] = {
> >> >> + { "BOSC0260", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
> >> >> + { "BMI0260", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
> >> >> + { "BOSC0160", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
> >> >> + { "BMI0160", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
> >> >
> >> > Sigh. That's not a valid ACPI ID or PNP ID.
> >> > (Well technically it is, but it belongs to the Benson Instrument Company
> >> > not Bosch)
> >> >
> >> > Which of these have been seen in the wild?
> >> > For any that are not of the BOSC0160 type form add a comment giving
> >> > a device on which they are in use.
> >>
> >> I know of the BMI0160 (this seems to be the most common way the BMI260
> >> is identified on handheld PCs), and the 10EC5280 has been seen in the
> >> wild, as described here:
> >> https://lore.kernel.org/all/CAFqHKTm2WRNkcSoBEE=oNbfu_9d9RagQHLydmv6q1=snO_MXyA@xxxxxxxxxxxxxx/
> >>
> >> I have not personally seen any devices using BMI0260, but I'll add
> >> comments to the BMI0160 and 10EC5280 entries with some examples of
> >> devices that use those IDs.
> >
> > Drop any we don't have evidence are out there.
> >
> > Do we have any confirmation from Bosch (or products in the wild) for
> > the structurally correct BOSC0160 etc? Those would normally have
> > to be tracked by Bosch as allocated for this purpose.
> >
>
> I haven't seen any reported, but the Windows driver INF has all five of
> these entries listed. I don't see any evidence of the BOSC0160 or
> BOSC0260 being used other than that Windows driver file.
Ok. Lets leave the extras out for now and see if anyone screams.
>
> BMI0160 seems by far the most common, with some appearances of 10EC5280
> (some AYANEO devices, possibly some GPD Win Max 2 devices) and BMI0260
> (OrangePi NEO).
>
> >>
> >> >> + { "10EC5280", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
> >> >
> >> > What's this one? There is no such vendor ID.
> >> >
> >>
> > ...
> >
> >> >>
> >> >> static const struct of_device_id bmi270_of_match[] = {
> >> >> - { .compatible = "bosch,bmi270" },
> >> >> + { .compatible = "bosch,bmi270", .data = &bmi270_chip_info[BMI270] },
> >> >
> >> > If the bmi260 supports SPI, should be added here as well. (I've no idea if it does!)
> >> >
> >> > Or is this because you can't test it?
> >>
> >> Yeah, it was because I can't test it, the BMI260 does support SPI. I can
> >> add entries here, though.
> >>
> >> Should the ACPI match entries from I2C also go here? All of the devices
> >> with mismatched IDs seem to use I2C so there might not be as much of a
> >> problem here.
> > We want the incorrect formatted ones to be as hard to use as possible to discourage
> > them going into new products. Can't do anything to solve the i2c cases
> > but definitely don't want to allow them for SPI as well if no evidence
> > of products where it yet matters.
> >
> > If we have confirmation from Bosch of the BOSC forms, then those I would like
> > in the SPI drivers as well (to point to the correct option for anyone using
> > this in future!)
> >
> > Jonathan
> >
>
> Agreed. Since we don't have confirmation of the correct values here or
> any that are in use, I would be OK either adding the single BOSC0260
> entry (as a guess, which may or may not be used) or leaving it out
> entirely until an entry is needed.
>
Add that one as it might encourage anyone who happens to consider Linux
support to do this right...
If anyone has contacts at Bosch to moan at about their garbage use
of ACPI IDs in windows drivers, please do.
Jonathan
> Justin
>
> >>
> >> >> { }
> >> >> };
> >> >>
> >>
> >> Thanks again,
> >> Justin
