| 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
| ||
|
Message-ID: <874j5grafd.fsf@justinweiss.com>
Date: Sat, 12 Oct 2024 19:41:58 -0700
From: Justin Weiss <justin@...tinweiss.com>
To: Jonathan Cameron <jic23@...nel.org>
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
Jonathan Cameron <jic23@...nel.org> writes:
> On Fri, 11 Oct 2024 08:37:47 -0700
> Justin Weiss <justin@...tinweiss.com> wrote:
>
> Title needs an edit to reflect the description that follows.
>
> iio: imu: bmi270: Add i2c support for bmi260
Thanks, I'll fix this in v2.
>> Adds i2c support for the Bosch BMI260 6-axis IMU to the Bosch BMI270
>> driver. Setup and operation is nearly identical to the Bosch BMI270,
>> but has a different chip ID and requires different firmware.
>>
>> Firmware is requested and loaded from userspace.
>>
>> Signed-off-by: Justin Weiss <justin@...tinweiss.com>
>> ---
>> drivers/iio/imu/bmi270/bmi270.h | 16 ++++++++++++++-
>> drivers/iio/imu/bmi270/bmi270_core.c | 29 +++++++++++++++++++++++-----
>> drivers/iio/imu/bmi270/bmi270_i2c.c | 22 ++++++++++++++++++---
>> drivers/iio/imu/bmi270/bmi270_spi.c | 11 ++++++++---
>> 4 files changed, 66 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/imu/bmi270/bmi270.h b/drivers/iio/imu/bmi270/bmi270.h
>> index 8ac20ad7ee94..51e374fd4290 100644
>> --- a/drivers/iio/imu/bmi270/bmi270.h
>> +++ b/drivers/iio/imu/bmi270/bmi270.h
>> @@ -10,10 +10,24 @@ struct device;
>> struct bmi270_data {
>> struct device *dev;
>> struct regmap *regmap;
>> + const struct bmi270_chip_info *chip_info;
>> +};
>> +
>> +enum bmi270_device_type {
>> + BMI260,
>> + BMI270,
>> +};
> It is obviously fairly trivial in this case, but the 'ideal' form for
> a patch series adding this flexibility is:
> Patch 1) Add a noop refactor to include the configuration structures etc.
> Patch 2) Add the support for the new device.
>
> First patch can then be reviewed on basis it's not destructive and second one just for
> the chip specific data added
Makes sense, I'll split these up for v2.
>> diff --git a/drivers/iio/imu/bmi270/bmi270_core.c b/drivers/iio/imu/bmi270/bmi270_core.c
>> index aeda7c4228df..e5ee80c12166 100644
>> --- a/drivers/iio/imu/bmi270/bmi270_core.c
>> +++ b/drivers/iio/imu/bmi270/bmi270_core.c
>> @@ -11,6 +11,7 @@
>
>> static int bmi270_get_data(struct bmi270_data *bmi270_device,
>> int chan_type, int axis, int *val)
>> {
>> @@ -154,8 +170,8 @@ static int bmi270_validate_chip_id(struct bmi270_data *bmi270_device)
>> if (ret)
>> return dev_err_probe(dev, ret, "Failed to read chip id");
>>
>> - if (chip_id != BMI270_CHIP_ID_VAL)
>> - dev_info(dev, "Unknown chip id 0x%x", chip_id);
>> + if (chip_id != bmi270_device->chip_info->chip_id)
> If we have multiple known IDs it can be slightly more friendly to check them all
> and if another one matches, just moan about broken firmware before carrying on
> using the correct data.
Sounds good. I'll dev_info a message if it doesn't match what the
chip_info expects, and then switch to the chip_info corresponding to the
chip ID returned by the device.
>
>> + return dev_err_probe(dev, -ENODEV, "Unknown chip id 0x%x", chip_id);
>>
>> return 0;
>> }
>> @@ -187,7 +203,8 @@ static int bmi270_write_calibration_data(struct bmi270_data *bmi270_device)
>> return dev_err_probe(dev, ret,
>> "Failed to prepare device to load init data");
>>
>> - ret = request_firmware(&init_data, BMI270_INIT_DATA_FILE, dev);
>> + ret = request_firmware(&init_data,
>> + bmi270_device->chip_info->fw_name, dev);
>> if (ret)
>> return dev_err_probe(dev, ret, "Failed to load init data file");
>>
>> @@ -274,7 +291,8 @@ static int bmi270_chip_init(struct bmi270_data *bmi270_device)
>> return bmi270_configure_imu(bmi270_device);
>> }
>
>> diff --git a/drivers/iio/imu/bmi270/bmi270_i2c.c b/drivers/iio/imu/bmi270/bmi270_i2c.c
>> index e9025d22d5cc..c8c90666c76b 100644
>> --- a/drivers/iio/imu/bmi270/bmi270_i2c.c
>> +++ b/drivers/iio/imu/bmi270/bmi270_i2c.c
>> @@ -18,28 +18,44 @@ static int bmi270_i2c_probe(struct i2c_client *client)
>> {
>> struct regmap *regmap;
>> struct device *dev = &client->dev;
>> + const struct bmi270_chip_info *chip_info;
>> +
>> + chip_info = i2c_get_match_data(client);
>> + if (!chip_info)
>> + return -ENODEV;
>>
>> regmap = devm_regmap_init_i2c(client, &bmi270_i2c_regmap_config);
>> if (IS_ERR(regmap))
>> return dev_err_probe(dev, PTR_ERR(regmap),
>> "Failed to init i2c regmap");
>>
>> - return bmi270_core_probe(dev, regmap);
>> + return bmi270_core_probe(dev, regmap, chip_info);
>> }
>>
>> static const struct i2c_device_id bmi270_i2c_id[] = {
>> - { "bmi270", 0 },
>> + { "bmi260", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
>> + { "bmi270", (kernel_ulong_t)&bmi270_chip_info[BMI270] },
>> { }
>> };
>>
>> +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.
>> + { "10EC5280", (kernel_ulong_t)&bmi270_chip_info[BMI260] },
>
> What's this one? There is no such vendor ID.
>
>> + { },
> No trailing comma on null terminators like this.
Thanks, will fix in v2.
>> +};
>> +
>> static const struct of_device_id bmi270_of_match[] = {
>> - { .compatible = "bosch,bmi270" },
>> + { .compatible = "bosch,bmi270", .data = &bmi270_chip_info[BMI270] },
>
> Add the 260 here as well + add to the dt docs.
Will fix in v2.
>> { }
>> };
>>
>> static struct i2c_driver bmi270_i2c_driver = {
>> .driver = {
>> .name = "bmi270_i2c",
>> + .acpi_match_table = bmi270_acpi_match,
>> .of_match_table = bmi270_of_match,
>> },
>> .probe = bmi270_i2c_probe,
>> diff --git a/drivers/iio/imu/bmi270/bmi270_spi.c b/drivers/iio/imu/bmi270/bmi270_spi.c
>> index 34d5ba6273bb..3d240f9651bc 100644
>> --- a/drivers/iio/imu/bmi270/bmi270_spi.c
>> +++ b/drivers/iio/imu/bmi270/bmi270_spi.c
>> @@ -50,6 +50,11 @@ static int bmi270_spi_probe(struct spi_device *spi)
>> {
>> struct regmap *regmap;
>> struct device *dev = &spi->dev;
>> + const struct bmi270_chip_info *chip_info;
>> +
>> + chip_info = spi_get_device_match_data(spi);
>> + if (!chip_info)
>> + return -ENODEV;
>>
>> regmap = devm_regmap_init(dev, &bmi270_regmap_bus, dev,
>> &bmi270_spi_regmap_config);
>> @@ -57,16 +62,16 @@ static int bmi270_spi_probe(struct spi_device *spi)
>> return dev_err_probe(dev, PTR_ERR(regmap),
>> "Failed to init i2c regmap");
>>
>> - return bmi270_core_probe(dev, regmap);
>> + return bmi270_core_probe(dev, regmap, chip_info);
>> }
>>
>> static const struct spi_device_id bmi270_spi_id[] = {
>> - { "bmi270" },
>> + { "bmi270", (kernel_ulong_t)&bmi270_chip_info[BMI270] },
>> { }
>> };
>>
>> 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.
>> { }
>> };
>>
Thanks again,
Justin
Powered by blists - more mailing lists