| Message ID | 20240609233826.330516-1-vassilisamir@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: chemical: bme680: Driver cleanup | expand |
On Mon, Jun 10, 2024 at 01:38:11AM +0200, Vasileios Amoiridis wrote: > Based on fixes-togreg as the 4 first commits are already applied > > Patch 1/15: Added comment for explanation of what mutex is used for > > Patch 2/15: Removed fixes tag > > Patch 3-15/15: Reworded the commit messages to come close to convention > of 75 chars per line. > > v2: https://lore.kernel.org/linux-iio/20240606212313.207550-1-vassilisamir@gmail.com/ > > Patch 4/19: > - Combined the bme680_conversion_time_us() and bme680_wait_for_eoc() > into one function. > - Added better comment for the calculation. > - Added checks in the bme680_wait_for_eoc() function. > > Patch 5/19: > - Fixed typo in commit message. > > Patch 6/19: > - Added a fixes tag since without the mutexes, read operations can be > broken. > > Patch 10/19: > - Converted shifting operation to FIELD_GET() > > Patch 11/19: > - Changed convention from &data->bufer[0] to data->buffer. > - Removed IIO_DMA_MINALIGN as it is not needed anymore. > > Patch 13/19: > - Removed IIO_DMA_MINALIGN > > Patch 14/19: > - Splitted from Patch v1 14/19 > > Patch 15/19: > - Splitted from Patch v1 14/19 > > Patch 16/19: **NEW** > - Use dev_err_probe() where applicable. > > v1: https://lore.kernel.org/linux-iio/20240527183805.311501-1-vassilisamir@gmail.com/ > > This started as a series to add support for buffers and the new > BME688 but it ended up being just a cleaning series. These might > be quite some patches for such a thing but I feel that they are > are well split, in order to allow for better review. > > The patches are mostly small changes but essential for the correct use > of the driver. The first patches looked like fixes that should be > marked for the stable. Patches [11,17/17] might be a bit bigger but 11/17 > is quite straightforward and 17/17 is basically a duplication of a > very similar commit coming from the BMP280 driver [1]. > > In general, the datasheet [2] of the driver is not very descriptive, > and it redirects the user to the BME68x Sensor API [3]. All the things > that were identified from the BME68x Sensor API have been marked with > links to the original locations of the GitHub code. If this is too much > and we don't want this type of information on the commit message, please > let me know and I will fix it. > > [1]: https://lore.kernel.org/linux-iio/20240512230524.53990-1-vassilisamir@gmail.com/T/#mc6f814e9a4f8c2b39015909d174c7013b3648b9b > [2]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf > [3]: https://github.com/boschsensortec/BME68x_SensorAPI/tree/master > > > Vasileios Amoiridis (15): > iio: chemical: bme680: Fix read/write ops to device by adding mutexes > iio: chemical: bme680: Fix typo in define > iio: chemical: bme680: Drop unnecessary casts and correct adc data > types > iio: chemical: bme680: Remove remaining ACPI-only stuff > iio: chemical: bme680: Sort headers alphabetically > iio: chemical: bme680: Remove duplicate register read > iio: chemical: bme680: Use bulk reads for calibration data > iio: chemical: bme680: Allocate IIO device before chip initialization > iio: chemical: bme680: Add read buffers in read/write buffer union > iio: chemical: bme680: Make error checks consistent > iio: chemical: bme680: Modify startup procedure > iio: chemical: bme680: Move probe errors to dev_err_probe() > iio: chemical: bme680: Remove redundant gas configuration > iio: chemical: bme680: Move forced mode setup in ->read_raw() > iio: chemical: bme680: Refactorize reading functions > > drivers/iio/chemical/bme680.h | 41 +- > drivers/iio/chemical/bme680_core.c | 631 +++++++++++++---------------- > 2 files changed, 291 insertions(+), 381 deletions(-) > > > base-commit: 4241665e6ea063a9c1d734de790121a71db763fc > -- > 2.25.1 > Hi Jonathan, It's been three weeks so I am just checking-in here, to be sure that this series was not lost in the countless e-mails that you receive. Totally understand the summer time on top, so no hurry at all, just checking in that it is not lost! :) Thanks for the amazing job with the reviews though anyways! :) Cheers, Vasilis
On Sun, 30 Jun 2024 22:26:40 +0200 Vasileios Amoiridis <vassilisamir@gmail.com> wrote: > On Mon, Jun 10, 2024 at 01:38:11AM +0200, Vasileios Amoiridis wrote: > > Based on fixes-togreg as the 4 first commits are already applied > > > > Patch 1/15: Added comment for explanation of what mutex is used for > > > > Patch 2/15: Removed fixes tag > > > > Patch 3-15/15: Reworded the commit messages to come close to convention > > of 75 chars per line. > > > > v2: https://lore.kernel.org/linux-iio/20240606212313.207550-1-vassilisamir@gmail.com/ > > > > Patch 4/19: > > - Combined the bme680_conversion_time_us() and bme680_wait_for_eoc() > > into one function. > > - Added better comment for the calculation. > > - Added checks in the bme680_wait_for_eoc() function. > > > > Patch 5/19: > > - Fixed typo in commit message. > > > > Patch 6/19: > > - Added a fixes tag since without the mutexes, read operations can be > > broken. > > > > Patch 10/19: > > - Converted shifting operation to FIELD_GET() > > > > Patch 11/19: > > - Changed convention from &data->bufer[0] to data->buffer. > > - Removed IIO_DMA_MINALIGN as it is not needed anymore. > > > > Patch 13/19: > > - Removed IIO_DMA_MINALIGN > > > > Patch 14/19: > > - Splitted from Patch v1 14/19 > > > > Patch 15/19: > > - Splitted from Patch v1 14/19 > > > > Patch 16/19: **NEW** > > - Use dev_err_probe() where applicable. > > > > v1: https://lore.kernel.org/linux-iio/20240527183805.311501-1-vassilisamir@gmail.com/ > > > > This started as a series to add support for buffers and the new > > BME688 but it ended up being just a cleaning series. These might > > be quite some patches for such a thing but I feel that they are > > are well split, in order to allow for better review. > > > > The patches are mostly small changes but essential for the correct use > > of the driver. The first patches looked like fixes that should be > > marked for the stable. Patches [11,17/17] might be a bit bigger but 11/17 > > is quite straightforward and 17/17 is basically a duplication of a > > very similar commit coming from the BMP280 driver [1]. > > > > In general, the datasheet [2] of the driver is not very descriptive, > > and it redirects the user to the BME68x Sensor API [3]. All the things > > that were identified from the BME68x Sensor API have been marked with > > links to the original locations of the GitHub code. If this is too much > > and we don't want this type of information on the commit message, please > > let me know and I will fix it. > > > > [1]: https://lore.kernel.org/linux-iio/20240512230524.53990-1-vassilisamir@gmail.com/T/#mc6f814e9a4f8c2b39015909d174c7013b3648b9b > > [2]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf > > [3]: https://github.com/boschsensortec/BME68x_SensorAPI/tree/master > > > > > > Vasileios Amoiridis (15): > > iio: chemical: bme680: Fix read/write ops to device by adding mutexes > > iio: chemical: bme680: Fix typo in define > > iio: chemical: bme680: Drop unnecessary casts and correct adc data > > types > > iio: chemical: bme680: Remove remaining ACPI-only stuff > > iio: chemical: bme680: Sort headers alphabetically > > iio: chemical: bme680: Remove duplicate register read > > iio: chemical: bme680: Use bulk reads for calibration data > > iio: chemical: bme680: Allocate IIO device before chip initialization > > iio: chemical: bme680: Add read buffers in read/write buffer union > > iio: chemical: bme680: Make error checks consistent > > iio: chemical: bme680: Modify startup procedure > > iio: chemical: bme680: Move probe errors to dev_err_probe() > > iio: chemical: bme680: Remove redundant gas configuration > > iio: chemical: bme680: Move forced mode setup in ->read_raw() > > iio: chemical: bme680: Refactorize reading functions > > > > drivers/iio/chemical/bme680.h | 41 +- > > drivers/iio/chemical/bme680_core.c | 631 +++++++++++++---------------- > > 2 files changed, 291 insertions(+), 381 deletions(-) > > > > > > base-commit: 4241665e6ea063a9c1d734de790121a71db763fc > > -- > > 2.25.1 > > > > Hi Jonathan, > > It's been three weeks so I am just checking-in here, to be sure that this > series was not lost in the countless e-mails that you receive. Totally > understand the summer time on top, so no hurry at all, just checking in > that it is not lost! :) Thanks for the amazing job with the reviews > though anyways! :) Hi, It's stalled because of a tree management issue - that is the first few patches were going through fixes-togreg and I'd like to keep the merge fun simple which means they have to end up upstream and back in char-misc/char-misc-next which I then rebase on after an IIO pull request. They are in char-misc-next as of about 45 mins ago. It'll be a bit tight for this cycle but my plan is 2 more pull requests with the last one at risk because of timing. This stuff can only be in that final pull request. Once it's all in place I will take a final look for but not anticipating needing any changes. Jonathan > > Cheers, > Vasilis >
On Mon, Jul 01, 2024 at 01:44:52PM +0100, Jonathan Cameron wrote: > On Sun, 30 Jun 2024 22:26:40 +0200 > Vasileios Amoiridis <vassilisamir@gmail.com> wrote: > > > On Mon, Jun 10, 2024 at 01:38:11AM +0200, Vasileios Amoiridis wrote: > > > Based on fixes-togreg as the 4 first commits are already applied > > > > > > Patch 1/15: Added comment for explanation of what mutex is used for > > > > > > Patch 2/15: Removed fixes tag > > > > > > Patch 3-15/15: Reworded the commit messages to come close to convention > > > of 75 chars per line. > > > > > > v2: https://lore.kernel.org/linux-iio/20240606212313.207550-1-vassilisamir@gmail.com/ > > > > > > Patch 4/19: > > > - Combined the bme680_conversion_time_us() and bme680_wait_for_eoc() > > > into one function. > > > - Added better comment for the calculation. > > > - Added checks in the bme680_wait_for_eoc() function. > > > > > > Patch 5/19: > > > - Fixed typo in commit message. > > > > > > Patch 6/19: > > > - Added a fixes tag since without the mutexes, read operations can be > > > broken. > > > > > > Patch 10/19: > > > - Converted shifting operation to FIELD_GET() > > > > > > Patch 11/19: > > > - Changed convention from &data->bufer[0] to data->buffer. > > > - Removed IIO_DMA_MINALIGN as it is not needed anymore. > > > > > > Patch 13/19: > > > - Removed IIO_DMA_MINALIGN > > > > > > Patch 14/19: > > > - Splitted from Patch v1 14/19 > > > > > > Patch 15/19: > > > - Splitted from Patch v1 14/19 > > > > > > Patch 16/19: **NEW** > > > - Use dev_err_probe() where applicable. > > > > > > v1: https://lore.kernel.org/linux-iio/20240527183805.311501-1-vassilisamir@gmail.com/ > > > > > > This started as a series to add support for buffers and the new > > > BME688 but it ended up being just a cleaning series. These might > > > be quite some patches for such a thing but I feel that they are > > > are well split, in order to allow for better review. > > > > > > The patches are mostly small changes but essential for the correct use > > > of the driver. The first patches looked like fixes that should be > > > marked for the stable. Patches [11,17/17] might be a bit bigger but 11/17 > > > is quite straightforward and 17/17 is basically a duplication of a > > > very similar commit coming from the BMP280 driver [1]. > > > > > > In general, the datasheet [2] of the driver is not very descriptive, > > > and it redirects the user to the BME68x Sensor API [3]. All the things > > > that were identified from the BME68x Sensor API have been marked with > > > links to the original locations of the GitHub code. If this is too much > > > and we don't want this type of information on the commit message, please > > > let me know and I will fix it. > > > > > > [1]: https://lore.kernel.org/linux-iio/20240512230524.53990-1-vassilisamir@gmail.com/T/#mc6f814e9a4f8c2b39015909d174c7013b3648b9b > > > [2]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf > > > [3]: https://github.com/boschsensortec/BME68x_SensorAPI/tree/master > > > > > > > > > Vasileios Amoiridis (15): > > > iio: chemical: bme680: Fix read/write ops to device by adding mutexes > > > iio: chemical: bme680: Fix typo in define > > > iio: chemical: bme680: Drop unnecessary casts and correct adc data > > > types > > > iio: chemical: bme680: Remove remaining ACPI-only stuff > > > iio: chemical: bme680: Sort headers alphabetically > > > iio: chemical: bme680: Remove duplicate register read > > > iio: chemical: bme680: Use bulk reads for calibration data > > > iio: chemical: bme680: Allocate IIO device before chip initialization > > > iio: chemical: bme680: Add read buffers in read/write buffer union > > > iio: chemical: bme680: Make error checks consistent > > > iio: chemical: bme680: Modify startup procedure > > > iio: chemical: bme680: Move probe errors to dev_err_probe() > > > iio: chemical: bme680: Remove redundant gas configuration > > > iio: chemical: bme680: Move forced mode setup in ->read_raw() > > > iio: chemical: bme680: Refactorize reading functions > > > > > > drivers/iio/chemical/bme680.h | 41 +- > > > drivers/iio/chemical/bme680_core.c | 631 +++++++++++++---------------- > > > 2 files changed, 291 insertions(+), 381 deletions(-) > > > > > > > > > base-commit: 4241665e6ea063a9c1d734de790121a71db763fc > > > -- > > > 2.25.1 > > > > > > > Hi Jonathan, > > > > It's been three weeks so I am just checking-in here, to be sure that this > > series was not lost in the countless e-mails that you receive. Totally > > understand the summer time on top, so no hurry at all, just checking in > > that it is not lost! :) Thanks for the amazing job with the reviews > > though anyways! :) > > Hi, > > It's stalled because of a tree management issue - that is the first > few patches were going through fixes-togreg and I'd like to keep > the merge fun simple which means they have to end up upstream and > back in char-misc/char-misc-next which I then rebase on after > an IIO pull request. > > They are in char-misc-next as of about 45 mins ago. > > It'll be a bit tight for this cycle but my plan is 2 more pull requests > with the last one at risk because of timing. This stuff can only be > in that final pull request. > > Once it's all in place I will take a final look for but not anticipating > needing any changes. > > Jonathan > Hi Jonathan, Ok, since it is not lost perfect! No need to hurry or anything. Thanks! Cheers, Vasilis > > > > > > Cheers, > > Vasilis > > >
On Mon, 1 Jul 2024 19:00:49 +0200 Vasileios Amoiridis <vassilisamir@gmail.com> wrote: > On Mon, Jul 01, 2024 at 01:44:52PM +0100, Jonathan Cameron wrote: > > On Sun, 30 Jun 2024 22:26:40 +0200 > > Vasileios Amoiridis <vassilisamir@gmail.com> wrote: > > > > > On Mon, Jun 10, 2024 at 01:38:11AM +0200, Vasileios Amoiridis wrote: > > > > Based on fixes-togreg as the 4 first commits are already applied > > > > > > > > Patch 1/15: Added comment for explanation of what mutex is used for > > > > > > > > Patch 2/15: Removed fixes tag > > > > > > > > Patch 3-15/15: Reworded the commit messages to come close to convention > > > > of 75 chars per line. > > > > > > > > v2: https://lore.kernel.org/linux-iio/20240606212313.207550-1-vassilisamir@gmail.com/ > > > > > > > > Patch 4/19: > > > > - Combined the bme680_conversion_time_us() and bme680_wait_for_eoc() > > > > into one function. > > > > - Added better comment for the calculation. > > > > - Added checks in the bme680_wait_for_eoc() function. > > > > > > > > Patch 5/19: > > > > - Fixed typo in commit message. > > > > > > > > Patch 6/19: > > > > - Added a fixes tag since without the mutexes, read operations can be > > > > broken. > > > > > > > > Patch 10/19: > > > > - Converted shifting operation to FIELD_GET() > > > > > > > > Patch 11/19: > > > > - Changed convention from &data->bufer[0] to data->buffer. > > > > - Removed IIO_DMA_MINALIGN as it is not needed anymore. > > > > > > > > Patch 13/19: > > > > - Removed IIO_DMA_MINALIGN > > > > > > > > Patch 14/19: > > > > - Splitted from Patch v1 14/19 > > > > > > > > Patch 15/19: > > > > - Splitted from Patch v1 14/19 > > > > > > > > Patch 16/19: **NEW** > > > > - Use dev_err_probe() where applicable. > > > > > > > > v1: https://lore.kernel.org/linux-iio/20240527183805.311501-1-vassilisamir@gmail.com/ > > > > > > > > This started as a series to add support for buffers and the new > > > > BME688 but it ended up being just a cleaning series. These might > > > > be quite some patches for such a thing but I feel that they are > > > > are well split, in order to allow for better review. > > > > > > > > The patches are mostly small changes but essential for the correct use > > > > of the driver. The first patches looked like fixes that should be > > > > marked for the stable. Patches [11,17/17] might be a bit bigger but 11/17 > > > > is quite straightforward and 17/17 is basically a duplication of a > > > > very similar commit coming from the BMP280 driver [1]. > > > > > > > > In general, the datasheet [2] of the driver is not very descriptive, > > > > and it redirects the user to the BME68x Sensor API [3]. All the things > > > > that were identified from the BME68x Sensor API have been marked with > > > > links to the original locations of the GitHub code. If this is too much > > > > and we don't want this type of information on the commit message, please > > > > let me know and I will fix it. > > > > > > > > [1]: https://lore.kernel.org/linux-iio/20240512230524.53990-1-vassilisamir@gmail.com/T/#mc6f814e9a4f8c2b39015909d174c7013b3648b9b > > > > [2]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf > > > > [3]: https://github.com/boschsensortec/BME68x_SensorAPI/tree/master > > > > > > > > > > > > Vasileios Amoiridis (15): > > > > iio: chemical: bme680: Fix read/write ops to device by adding mutexes > > > > iio: chemical: bme680: Fix typo in define > > > > iio: chemical: bme680: Drop unnecessary casts and correct adc data > > > > types > > > > iio: chemical: bme680: Remove remaining ACPI-only stuff > > > > iio: chemical: bme680: Sort headers alphabetically > > > > iio: chemical: bme680: Remove duplicate register read > > > > iio: chemical: bme680: Use bulk reads for calibration data > > > > iio: chemical: bme680: Allocate IIO device before chip initialization > > > > iio: chemical: bme680: Add read buffers in read/write buffer union > > > > iio: chemical: bme680: Make error checks consistent > > > > iio: chemical: bme680: Modify startup procedure > > > > iio: chemical: bme680: Move probe errors to dev_err_probe() > > > > iio: chemical: bme680: Remove redundant gas configuration > > > > iio: chemical: bme680: Move forced mode setup in ->read_raw() > > > > iio: chemical: bme680: Refactorize reading functions > > > > > > > > drivers/iio/chemical/bme680.h | 41 +- > > > > drivers/iio/chemical/bme680_core.c | 631 +++++++++++++---------------- > > > > 2 files changed, 291 insertions(+), 381 deletions(-) > > > > > > > > > > > > base-commit: 4241665e6ea063a9c1d734de790121a71db763fc > > > > -- > > > > 2.25.1 > > > > > > > > > > Hi Jonathan, > > > > > > It's been three weeks so I am just checking-in here, to be sure that this > > > series was not lost in the countless e-mails that you receive. Totally > > > understand the summer time on top, so no hurry at all, just checking in > > > that it is not lost! :) Thanks for the amazing job with the reviews > > > though anyways! :) > > > > Hi, > > > > It's stalled because of a tree management issue - that is the first > > few patches were going through fixes-togreg and I'd like to keep > > the merge fun simple which means they have to end up upstream and > > back in char-misc/char-misc-next which I then rebase on after > > an IIO pull request. > > > > They are in char-misc-next as of about 45 mins ago. > > > > It'll be a bit tight for this cycle but my plan is 2 more pull requests > > with the last one at risk because of timing. This stuff can only be > > in that final pull request. > > > > Once it's all in place I will take a final look for but not anticipating > > needing any changes. > > > > Jonathan > > > > Hi Jonathan, > > Ok, since it is not lost perfect! No need to hurry or anything. Thanks! Applied to the testing branch of iio.git. Unfortunately the tree juggling meant this hit what is probably a few days too late to get another pull request out for 6.11. Hence I'm now treating this as 6.12 material. The tree will be rebased on 6.11-rc1 once available and pushed out then as togreg with linux-next picking that up. Thanks, Jonathan > > Cheers, > Vasilis > > > > > > > > > > > Cheers, > > > Vasilis > > > > >
Based on fixes-togreg as the 4 first commits are already applied Patch 1/15: Added comment for explanation of what mutex is used for Patch 2/15: Removed fixes tag Patch 3-15/15: Reworded the commit messages to come close to convention of 75 chars per line. v2: https://lore.kernel.org/linux-iio/20240606212313.207550-1-vassilisamir@gmail.com/ Patch 4/19: - Combined the bme680_conversion_time_us() and bme680_wait_for_eoc() into one function. - Added better comment for the calculation. - Added checks in the bme680_wait_for_eoc() function. Patch 5/19: - Fixed typo in commit message. Patch 6/19: - Added a fixes tag since without the mutexes, read operations can be broken. Patch 10/19: - Converted shifting operation to FIELD_GET() Patch 11/19: - Changed convention from &data->bufer[0] to data->buffer. - Removed IIO_DMA_MINALIGN as it is not needed anymore. Patch 13/19: - Removed IIO_DMA_MINALIGN Patch 14/19: - Splitted from Patch v1 14/19 Patch 15/19: - Splitted from Patch v1 14/19 Patch 16/19: **NEW** - Use dev_err_probe() where applicable. v1: https://lore.kernel.org/linux-iio/20240527183805.311501-1-vassilisamir@gmail.com/ This started as a series to add support for buffers and the new BME688 but it ended up being just a cleaning series. These might be quite some patches for such a thing but I feel that they are are well split, in order to allow for better review. The patches are mostly small changes but essential for the correct use of the driver. The first patches looked like fixes that should be marked for the stable. Patches [11,17/17] might be a bit bigger but 11/17 is quite straightforward and 17/17 is basically a duplication of a very similar commit coming from the BMP280 driver [1]. In general, the datasheet [2] of the driver is not very descriptive, and it redirects the user to the BME68x Sensor API [3]. All the things that were identified from the BME68x Sensor API have been marked with links to the original locations of the GitHub code. If this is too much and we don't want this type of information on the commit message, please let me know and I will fix it. [1]: https://lore.kernel.org/linux-iio/20240512230524.53990-1-vassilisamir@gmail.com/T/#mc6f814e9a4f8c2b39015909d174c7013b3648b9b [2]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf [3]: https://github.com/boschsensortec/BME68x_SensorAPI/tree/master Vasileios Amoiridis (15): iio: chemical: bme680: Fix read/write ops to device by adding mutexes iio: chemical: bme680: Fix typo in define iio: chemical: bme680: Drop unnecessary casts and correct adc data types iio: chemical: bme680: Remove remaining ACPI-only stuff iio: chemical: bme680: Sort headers alphabetically iio: chemical: bme680: Remove duplicate register read iio: chemical: bme680: Use bulk reads for calibration data iio: chemical: bme680: Allocate IIO device before chip initialization iio: chemical: bme680: Add read buffers in read/write buffer union iio: chemical: bme680: Make error checks consistent iio: chemical: bme680: Modify startup procedure iio: chemical: bme680: Move probe errors to dev_err_probe() iio: chemical: bme680: Remove redundant gas configuration iio: chemical: bme680: Move forced mode setup in ->read_raw() iio: chemical: bme680: Refactorize reading functions drivers/iio/chemical/bme680.h | 41 +- drivers/iio/chemical/bme680_core.c | 631 +++++++++++++---------------- 2 files changed, 291 insertions(+), 381 deletions(-) base-commit: 4241665e6ea063a9c1d734de790121a71db763fc