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

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]

Message-ID: <20241013161457.506c2296@jic23-huawei>
Date: Sun, 13 Oct 2024 16:14:57 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Justin Weiss <justin@...tinweiss.com>
Cc: Alex Lanzano <lanzano.alex@...il.com>, Lars-Peter Clausen
 <lars@...afoo.de>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 "Derek J . Clark" <derekjohn.clark@...il.com>, Philip Müller <philm@...jaro.org>
Subject: Re: [PATCH 1/3] iio: imu: Add i2c driver for bmi260 imu


> >> +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@mail.gmail.com/
> 
> 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