Re: [PATCH 1/3] iio: imu: Add i2c driver for bmi260 imu

[Jonathan Cameron]

> >> +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.

> 
> >> +	{ "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
 
> 
> >>  	{ }
> >>  };
> >>    
> 
> Thanks again,
> Justin