| 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: <20241012120830.338aca19@jic23-huawei>
Date: Sat, 12 Oct 2024 12:08:30 +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
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
> 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
> 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.
> + 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.
> + { "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.
> +};
> +
> 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.
> { }
> };
>
> 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?
> { }
> };
>
Powered by blists - more mailing lists