#
7cf15f42 |
|
15-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iio: Switch i2c drivers back to use .probe() After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230515205048.19561-1-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
122b0c0b |
|
18-Nov-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iio: light: si1133: Convert to i2c's .probe_new() .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221118224540.619276-138-uwe@kleine-koenig.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
d4f2a1c6 |
|
03-Jun-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: light: si1133: Drop remaining uses of %hhx format string. Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. As there are not that many in IIO, this is part of an effort to clear them out so we don't have any instances that might get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-3-jic23@kernel.org
|
#
770494a7 |
|
03-Jun-2021 |
Arnd Bergmann <arnd@arndb.de> |
iio: si1133: fix format string warnings clang complains about multiple instances of printing an integer using the %hhx format string: drivers/iio/light/si1133.c:982:4: error: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Werror,-Wformat] part_id, rev_id, mfr_id); ^~~~~~~ Print them as a normal integer instead, leaving the "#02" length modifier. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-2-jic23@kernel.org
|
#
d3be8324 |
|
22-May-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: remove explicit IIO device parent assignment This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
76170adb |
|
20-Apr-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
iio: light: si1133: Use get_unaligned_be24() This makes the driver code slightly easier to read. Cc: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
328b50e9 |
|
18-Feb-2020 |
Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> |
iio: si1133: read 24-bit signed integer for measurement The chip is configured in 24 bit mode. The values read from it must always be treated as is. This fixes the issue by replacing the previous 16 bits value by a 24 bits buffer. This changes affects the value output by previous version of the driver, since the least significant byte was missing. The upper half of 16 bit values previously output are now the upper half of a 24 bit value. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Reported-by: Simon Goyette <simon.goyette@gmail.com> Co-authored-by: Guillaume Champagne <champagne.guillaume.c@gmail.com> Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
496fb59e |
|
31-Jul-2018 |
Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> |
iio: light: si1133: fix uninitialized resp variable Read response register to detect any error. Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
1e96e93a |
|
30-Jul-2018 |
Colin Ian King <colin.king@canonical.com> |
iio: light: si1133 fix test for val being not zero or not one. The current check on val always results in true and so the call to sii1133_update_adcsens never gets called. Fix this check so it returns with -EINVAL only when val is not zero and not one. Detected by CoverityScan, CID#1472099 ("Logically dead code") Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
e01e7eaf |
|
19-Jul-2018 |
Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> |
iio: light: introduce si1133 e-mail received from Silicon Lab to confirm that the licensing isn't a problem. " Dear Maxime Roussin-Belanger, The LUX calculation code only works with Si1133. As long as the software is used with Silicon Lab's sensor product, I don't see any problem. Regards, Tony " Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Reviewed-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|