- Linux-stable-mirror - lists.linaro.org

patch "iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From e5b1032a656e9aa4c7a4df77cb9156a2a651a5f9 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 10 Nov 2020 14:38:35 +0100 Subject: iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting tablet-mode Some 360 degree hinges (yoga) style 2-in-1 devices use 2 KXCJ91008-s to allow the OS to determine the angle between the display and the base of the device, so that the OS can determine if the 2-in-1 is in laptop or in tablet-mode. On Windows both accelerometers are read by a special HingeAngleService process; and this process calls a DSM (Device Specific Method) on the ACPI KIOX010A device node for the sensor in the display, to let the embedded-controller (EC) know about the mode so that it can disable the kbd and touchpad to avoid spurious input while folded into tablet-mode. This notifying of the EC is problematic because sometimes the EC comes up thinking that device is in tablet-mode and the kbd and touchpad do not work. This happens for example on Irbis NB111 devices after a suspend / resume cycle (after a complete battery drain / hard reset without having booted Windows at least once). Other 2-in-1s which are likely affected too are e.g. the Teclast F5 and F6 series. The kxcjk-1013 driver may seem like a strange place to deal with this, but since it is *the* driver for the ACPI KIOX010A device, it is also the driver which has access to the ACPI handle needed by the DSM. Add support for calling the DSM and on probe unconditionally tell the EC that the device is laptop mode, fixing the kbd and touchpad sometimes not working. Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID") Reported-and-tested-by: russianneuromancer <russianneuromancer(a)ya.ru> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201110133835.129080-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/kxcjk-1013.c | 36 ++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c index abeb0d254046..560a3373ff20 100644 --- a/drivers/iio/accel/kxcjk-1013.c +++ b/drivers/iio/accel/kxcjk-1013.c @@ -129,6 +129,7 @@ enum kx_chipset { enum kx_acpi_type { ACPI_GENERIC, ACPI_SMO8500, + ACPI_KIOX010A, }; struct kxcjk1013_data { @@ -275,6 +276,32 @@ static const struct { {19163, 1, 0}, {38326, 0, 1} }; +#ifdef CONFIG_ACPI +enum kiox010a_fn_index { + KIOX010A_SET_LAPTOP_MODE = 1, + KIOX010A_SET_TABLET_MODE = 2, +}; + +static int kiox010a_dsm(struct device *dev, int fn_index) +{ + acpi_handle handle = ACPI_HANDLE(dev); + guid_t kiox010a_dsm_guid; + union acpi_object *obj; + + if (!handle) + return -ENODEV; + + guid_parse("1f339696-d475-4e26-8cad-2e9f8e6d7a91", &kiox010a_dsm_guid); + + obj = acpi_evaluate_dsm(handle, &kiox010a_dsm_guid, 1, fn_index, NULL); + if (!obj) + return -EIO; + + ACPI_FREE(obj); + return 0; +} +#endif + static int kxcjk1013_set_mode(struct kxcjk1013_data *data, enum kxcjk1013_mode mode) { @@ -352,6 +379,13 @@ static int kxcjk1013_chip_init(struct kxcjk1013_data *data) { int ret; +#ifdef CONFIG_ACPI + if (data->acpi_type == ACPI_KIOX010A) { + /* Make sure the kbd and touchpad on 2-in-1s using 2 KXCJ91008-s work */ + kiox010a_dsm(&data->client->dev, KIOX010A_SET_LAPTOP_MODE); + } +#endif + ret = i2c_smbus_read_byte_data(data->client, KXCJK1013_REG_WHO_AM_I); if (ret < 0) { dev_err(&data->client->dev, "Error reading who_am_i\n"); @@ -1262,6 +1296,8 @@ static const char *kxcjk1013_match_acpi_device(struct device *dev, if (strcmp(id->id, "SMO8500") == 0) *acpi_type = ACPI_SMO8500; + else if (strcmp(id->id, "KIOX010A") == 0) + *acpi_type = ACPI_KIOX010A; *chipset = (enum kx_chipset)id->driver_data; -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 11e94f28c3de35d5ad1ac6a242a5b30f4378991a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 10 Nov 2020 14:38:34 +0100 Subject: iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type enum Replace the boolean is_smo8500_device variable with an acpi_type enum. For now this can be either ACPI_GENERIC or ACPI_SMO8500, this is a preparation patch for adding special handling for the KIOX010A ACPI HID, which will add a ACPI_KIOX010A acpi_type to the introduced enum. For stable as needed as precursor for next patch. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID") Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201110133835.129080-2-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/kxcjk-1013.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c index beb38d9d607d..abeb0d254046 100644 --- a/drivers/iio/accel/kxcjk-1013.c +++ b/drivers/iio/accel/kxcjk-1013.c @@ -126,6 +126,11 @@ enum kx_chipset { KX_MAX_CHIPS /* this must be last */ }; +enum kx_acpi_type { + ACPI_GENERIC, + ACPI_SMO8500, +}; + struct kxcjk1013_data { struct i2c_client *client; struct iio_trigger *dready_trig; @@ -143,7 +148,7 @@ struct kxcjk1013_data { bool motion_trigger_on; int64_t timestamp; enum kx_chipset chipset; - bool is_smo8500_device; + enum kx_acpi_type acpi_type; }; enum kxcjk1013_axis { @@ -1247,7 +1252,7 @@ static irqreturn_t kxcjk1013_data_rdy_trig_poll(int irq, void *private) static const char *kxcjk1013_match_acpi_device(struct device *dev, enum kx_chipset *chipset, - bool *is_smo8500_device) + enum kx_acpi_type *acpi_type) { const struct acpi_device_id *id; @@ -1256,7 +1261,7 @@ static const char *kxcjk1013_match_acpi_device(struct device *dev, return NULL; if (strcmp(id->id, "SMO8500") == 0) - *is_smo8500_device = true; + *acpi_type = ACPI_SMO8500; *chipset = (enum kx_chipset)id->driver_data; @@ -1299,7 +1304,7 @@ static int kxcjk1013_probe(struct i2c_client *client, } else if (ACPI_HANDLE(&client->dev)) { name = kxcjk1013_match_acpi_device(&client->dev, &data->chipset, - &data->is_smo8500_device); + &data->acpi_type); } else return -ENODEV; @@ -1316,7 +1321,7 @@ static int kxcjk1013_probe(struct i2c_client *client, indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->info = &kxcjk1013_info; - if (client->irq > 0 && !data->is_smo8500_device) { + if (client->irq > 0 && data->acpi_type != ACPI_SMO8500) { ret = devm_request_threaded_irq(&client->dev, client->irq, kxcjk1013_data_rdy_trig_poll, kxcjk1013_event_handler, -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: light: fix kconfig dependency bug for VCNL4035" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: light: fix kconfig dependency bug for VCNL4035 to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 44a146a44f656fc03d368c1b9248d29a128cd053 Mon Sep 17 00:00:00 2001 From: Necip Fazil Yildiran <fazilyildiran(a)gmail.com> Date: Tue, 3 Nov 2020 01:35:24 +0300 Subject: iio: light: fix kconfig dependency bug for VCNL4035 When VCNL4035 is enabled and IIO_BUFFER is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for IIO_TRIGGERED_BUFFER Depends on [n]: IIO [=y] && IIO_BUFFER [=n] Selected by [y]: - VCNL4035 [=y] && IIO [=y] && I2C [=y] The reason is that VCNL4035 selects IIO_TRIGGERED_BUFFER without depending on or selecting IIO_BUFFER while IIO_TRIGGERED_BUFFER depends on IIO_BUFFER. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035") Signed-off-by: Necip Fazil Yildiran <fazilyildiran(a)gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209883 Link: https://lore.kernel.org/r/20201102223523.572461-1-fazilyildiran@gmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index cade6dc0305b..33ad4dd0b5c7 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -544,6 +544,7 @@ config VCNL4000 config VCNL4035 tristate "VCNL4035 combined ALS and proximity sensor" + select IIO_BUFFER select IIO_TRIGGERED_BUFFER select REGMAP_I2C depends on I2C -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 6d6aa2907d59ddd3c0ebb2b93e1ddc84e474485b Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Tue, 3 Nov 2020 20:12:38 +0000 Subject: iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used When the command feature of the ADC is used, it is possible to program the ADC, and specify at each step what input should be processed, and in comparison to what reference. This broke the AUX and battery readings when the touchscreen was enabled, most likely because the CMD feature would change the VREF all the time. Now, when AUX or battery are read, we temporarily disable the CMD feature, which means that we won't get touchscreen readings in that time frame. But it now gives correct values for AUX / battery, and the touchscreen isn't disabled for long enough to be an actual issue. Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.") Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Acked-by: Artur Rojek <contact(a)artur-rojek.eu> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201103201238.161083-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ingenic-adc.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c index 973e84deebea..1aafbe2cfe67 100644 --- a/drivers/iio/adc/ingenic-adc.c +++ b/drivers/iio/adc/ingenic-adc.c @@ -177,13 +177,12 @@ static void ingenic_adc_set_config(struct ingenic_adc *adc, mutex_unlock(&adc->lock); } -static void ingenic_adc_enable(struct ingenic_adc *adc, - int engine, - bool enabled) +static void ingenic_adc_enable_unlocked(struct ingenic_adc *adc, + int engine, + bool enabled) { u8 val; - mutex_lock(&adc->lock); val = readb(adc->base + JZ_ADC_REG_ENABLE); if (enabled) @@ -192,20 +191,41 @@ static void ingenic_adc_enable(struct ingenic_adc *adc, val &= ~BIT(engine); writeb(val, adc->base + JZ_ADC_REG_ENABLE); +} + +static void ingenic_adc_enable(struct ingenic_adc *adc, + int engine, + bool enabled) +{ + mutex_lock(&adc->lock); + ingenic_adc_enable_unlocked(adc, engine, enabled); mutex_unlock(&adc->lock); } static int ingenic_adc_capture(struct ingenic_adc *adc, int engine) { + u32 cfg; u8 val; int ret; - ingenic_adc_enable(adc, engine, true); + /* + * Disable CMD_SEL temporarily, because it causes wrong VBAT readings, + * probably due to the switch of VREF. We must keep the lock here to + * avoid races with the buffer enable/disable functions. + */ + mutex_lock(&adc->lock); + cfg = readl(adc->base + JZ_ADC_REG_CFG); + writel(cfg & ~JZ_ADC_REG_CFG_CMD_SEL, adc->base + JZ_ADC_REG_CFG); + + ingenic_adc_enable_unlocked(adc, engine, true); ret = readb_poll_timeout(adc->base + JZ_ADC_REG_ENABLE, val, !(val & BIT(engine)), 250, 1000); if (ret) - ingenic_adc_enable(adc, engine, false); + ingenic_adc_enable_unlocked(adc, engine, false); + + writel(cfg, adc->base + JZ_ADC_REG_CFG); + mutex_unlock(&adc->lock); return ret; } -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio/adc: ingenic: Fix battery VREF for JZ4770 SoC" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio/adc: ingenic: Fix battery VREF for JZ4770 SoC to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c91ebcc578e09783cfa4d85c1b437790f140f29a Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Wed, 4 Nov 2020 19:28:43 +0000 Subject: iio/adc: ingenic: Fix battery VREF for JZ4770 SoC The reference voltage for the battery is clearly marked as 1.2V in the programming manual. With this fixed, the battery channel now returns correct values. Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.") Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Acked-by: Artur Rojek <contact(a)artur-rojek.eu> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201104192843.67187-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ingenic-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c index 92b25083e23f..973e84deebea 100644 --- a/drivers/iio/adc/ingenic-adc.c +++ b/drivers/iio/adc/ingenic-adc.c @@ -71,7 +71,7 @@ #define JZ4725B_ADC_BATTERY_HIGH_VREF_BITS 10 #define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986) #define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12 -#define JZ4770_ADC_BATTERY_VREF 6600 +#define JZ4770_ADC_BATTERY_VREF 1200 #define JZ4770_ADC_BATTERY_VREF_BITS 12 #define JZ_ADC_IRQ_AUX BIT(0) -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From fe0b980ffd1dd8b10c09f82385514819ba2a661d Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi <lorenzo(a)kernel.org> Date: Sun, 1 Nov 2020 17:21:18 +0100 Subject: iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout Set 10ms as minimum i2c slave configuration timeout since st_lsm6dsx relies on accel ODR for i2c master clock and at high sample rates (e.g. 833Hz or 416Hz) the slave sensor occasionally may need more cycles than i2c master timeout (2s/833Hz + 1 ~ 3ms) to apply the configuration resulting in an uncomplete slave configuration and a constant reading from the i2c slave connected to st_lsm6dsx i2c master. Fixes: 8f9a5249e3d9 ("iio: imu: st_lsm6dsx: enable 833Hz sample frequency for tagged sensors") Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support") Signed-off-by: Lorenzo Bianconi <lorenzo(a)kernel.org> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/a69c8236bf16a1569966815ed71710af2722ed7d.16042472… Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c index 8c8d8870ca07..99562ba85ee4 100644 --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c @@ -156,11 +156,13 @@ static const struct st_lsm6dsx_ext_dev_settings st_lsm6dsx_ext_dev_table[] = { static void st_lsm6dsx_shub_wait_complete(struct st_lsm6dsx_hw *hw) { struct st_lsm6dsx_sensor *sensor; - u32 odr; + u32 odr, timeout; sensor = iio_priv(hw->iio_devs[ST_LSM6DSX_ID_ACC]); odr = (hw->enable_mask & BIT(ST_LSM6DSX_ID_ACC)) ? sensor->odr : 12500; - msleep((2000000U / odr) + 1); + /* set 10ms as minimum timeout for i2c slave configuration */ + timeout = max_t(u32, 2000000U / odr + 1, 10); + msleep(timeout); } /* -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: adc: stm32-adc: fix a regression when using dma and irq" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32-adc: fix a regression when using dma and irq to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 695e2f5c289bb7f8b85351dcfa35fa236e0200a4 Mon Sep 17 00:00:00 2001 From: Olivier Moysan <olivier.moysan(a)st.com> Date: Wed, 21 Oct 2020 10:53:13 +0200 Subject: iio: adc: stm32-adc: fix a regression when using dma and irq Since overrun interrupt support has been added, there's a regression when two ADCs are used at the same time, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). This is a regression as similar issue had been fixed earlier by commit dcb10920179a ("iio: adc: stm32-adc: fix a race when using several adcs with dma and irq"). Issue is that stm32_adc_eoc_enabled() returns non-zero value (always) since OVR bit has been added and enabled for both DMA and IRQ case. Remove OVR mask in IER register, and rely only on CSR status for overrun. To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has to be cleared. CSR OVR bit cannot be cleared directly by software. To do this ADC must be stopped first, and OVR bit in ADC ISR has to be cleared. Also add a check in ADC IRQ handler to report spurious IRQs. Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt") Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/stm32-adc-core.c | 41 +++++++++++--------------- drivers/iio/adc/stm32-adc.c | 50 ++++++++++++++++++++++++++++++-- 2 files changed, 65 insertions(+), 26 deletions(-) diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c index cd870c089182..a83199b212a4 100644 --- a/drivers/iio/adc/stm32-adc-core.c +++ b/drivers/iio/adc/stm32-adc-core.c @@ -41,18 +41,16 @@ * struct stm32_adc_common_regs - stm32 common registers * @csr: common status register offset * @ccr: common control register offset - * @eoc1_msk: adc1 end of conversion flag in @csr - * @eoc2_msk: adc2 end of conversion flag in @csr - * @eoc3_msk: adc3 end of conversion flag in @csr + * @eoc_msk: array of eoc (end of conversion flag) masks in csr for adc1..n + * @ovr_msk: array of ovr (overrun flag) masks in csr for adc1..n * @ier: interrupt enable register offset for each adc * @eocie_msk: end of conversion interrupt enable mask in @ier */ struct stm32_adc_common_regs { u32 csr; u32 ccr; - u32 eoc1_msk; - u32 eoc2_msk; - u32 eoc3_msk; + u32 eoc_msk[STM32_ADC_MAX_ADCS]; + u32 ovr_msk[STM32_ADC_MAX_ADCS]; u32 ier; u32 eocie_msk; }; @@ -282,21 +280,20 @@ static int stm32h7_adc_clk_sel(struct platform_device *pdev, static const struct stm32_adc_common_regs stm32f4_adc_common_regs = { .csr = STM32F4_ADC_CSR, .ccr = STM32F4_ADC_CCR, - .eoc1_msk = STM32F4_EOC1 | STM32F4_OVR1, - .eoc2_msk = STM32F4_EOC2 | STM32F4_OVR2, - .eoc3_msk = STM32F4_EOC3 | STM32F4_OVR3, + .eoc_msk = { STM32F4_EOC1, STM32F4_EOC2, STM32F4_EOC3}, + .ovr_msk = { STM32F4_OVR1, STM32F4_OVR2, STM32F4_OVR3}, .ier = STM32F4_ADC_CR1, - .eocie_msk = STM32F4_EOCIE | STM32F4_OVRIE, + .eocie_msk = STM32F4_EOCIE, }; /* STM32H7 common registers definitions */ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = { .csr = STM32H7_ADC_CSR, .ccr = STM32H7_ADC_CCR, - .eoc1_msk = STM32H7_EOC_MST | STM32H7_OVR_MST, - .eoc2_msk = STM32H7_EOC_SLV | STM32H7_OVR_SLV, + .eoc_msk = { STM32H7_EOC_MST, STM32H7_EOC_SLV}, + .ovr_msk = { STM32H7_OVR_MST, STM32H7_OVR_SLV}, .ier = STM32H7_ADC_IER, - .eocie_msk = STM32H7_EOCIE | STM32H7_OVRIE, + .eocie_msk = STM32H7_EOCIE, }; static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = { @@ -318,6 +315,7 @@ static void stm32_adc_irq_handler(struct irq_desc *desc) { struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc); struct irq_chip *chip = irq_desc_get_chip(desc); + int i; u32 status; chained_irq_enter(chip, desc); @@ -335,17 +333,12 @@ static void stm32_adc_irq_handler(struct irq_desc *desc) * before invoking the interrupt handler (e.g. call ISR only for * IRQ-enabled ADCs). */ - if (status & priv->cfg->regs->eoc1_msk && - stm32_adc_eoc_enabled(priv, 0)) - generic_handle_irq(irq_find_mapping(priv->domain, 0)); - - if (status & priv->cfg->regs->eoc2_msk && - stm32_adc_eoc_enabled(priv, 1)) - generic_handle_irq(irq_find_mapping(priv->domain, 1)); - - if (status & priv->cfg->regs->eoc3_msk && - stm32_adc_eoc_enabled(priv, 2)) - generic_handle_irq(irq_find_mapping(priv->domain, 2)); + for (i = 0; i < priv->cfg->num_irqs; i++) { + if ((status & priv->cfg->regs->eoc_msk[i] && + stm32_adc_eoc_enabled(priv, i)) || + (status & priv->cfg->regs->ovr_msk[i])) + generic_handle_irq(irq_find_mapping(priv->domain, i)); + } chained_irq_exit(chip, desc); }; diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index b3f31f147347..16c02c30dec7 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -154,6 +154,7 @@ struct stm32_adc; * @start_conv: routine to start conversions * @stop_conv: routine to stop conversions * @unprepare: optional unprepare routine (disable, power-down) + * @irq_clear: routine to clear irqs * @smp_cycles: programmable sampling time (ADC clock cycles) */ struct stm32_adc_cfg { @@ -166,6 +167,7 @@ struct stm32_adc_cfg { void (*start_conv)(struct iio_dev *, bool dma); void (*stop_conv)(struct iio_dev *); void (*unprepare)(struct iio_dev *); + void (*irq_clear)(struct iio_dev *indio_dev, u32 msk); const unsigned int *smp_cycles; }; @@ -621,6 +623,13 @@ static void stm32f4_adc_stop_conv(struct iio_dev *indio_dev) STM32F4_ADON | STM32F4_DMA | STM32F4_DDS); } +static void stm32f4_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + + stm32_adc_clr_bits(adc, adc->cfg->regs->isr_eoc.reg, msk); +} + static void stm32h7_adc_start_conv(struct iio_dev *indio_dev, bool dma) { struct stm32_adc *adc = iio_priv(indio_dev); @@ -659,6 +668,13 @@ static void stm32h7_adc_stop_conv(struct iio_dev *indio_dev) stm32_adc_clr_bits(adc, STM32H7_ADC_CFGR, STM32H7_DMNGT_MASK); } +static void stm32h7_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + /* On STM32H7 IRQs are cleared by writing 1 into ISR register */ + stm32_adc_set_bits(adc, adc->cfg->regs->isr_eoc.reg, msk); +} + static int stm32h7_adc_exit_pwr_down(struct iio_dev *indio_dev) { struct stm32_adc *adc = iio_priv(indio_dev); @@ -1235,17 +1251,40 @@ static int stm32_adc_read_raw(struct iio_dev *indio_dev, } } +static void stm32_adc_irq_clear(struct iio_dev *indio_dev, u32 msk) +{ + struct stm32_adc *adc = iio_priv(indio_dev); + + adc->cfg->irq_clear(indio_dev, msk); +} + static irqreturn_t stm32_adc_threaded_isr(int irq, void *data) { struct iio_dev *indio_dev = data; struct stm32_adc *adc = iio_priv(indio_dev); const struct stm32_adc_regspec *regs = adc->cfg->regs; u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg); + u32 mask = stm32_adc_readl(adc, regs->ier_eoc.reg); - if (status & regs->isr_ovr.mask) + /* Check ovr status right now, as ovr mask should be already disabled */ + if (status & regs->isr_ovr.mask) { + /* + * Clear ovr bit to avoid subsequent calls to IRQ handler. + * This requires to stop ADC first. OVR bit state in ISR, + * is propaged to CSR register by hardware. + */ + adc->cfg->stop_conv(indio_dev); + stm32_adc_irq_clear(indio_dev, regs->isr_ovr.mask); dev_err(&indio_dev->dev, "Overrun, stopping: restart needed\n"); + return IRQ_HANDLED; + } - return IRQ_HANDLED; + if (!(status & mask)) + dev_err_ratelimited(&indio_dev->dev, + "Unexpected IRQ: IER=0x%08x, ISR=0x%08x\n", + mask, status); + + return IRQ_NONE; } static irqreturn_t stm32_adc_isr(int irq, void *data) @@ -1254,6 +1293,10 @@ static irqreturn_t stm32_adc_isr(int irq, void *data) struct stm32_adc *adc = iio_priv(indio_dev); const struct stm32_adc_regspec *regs = adc->cfg->regs; u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg); + u32 mask = stm32_adc_readl(adc, regs->ier_eoc.reg); + + if (!(status & mask)) + return IRQ_WAKE_THREAD; if (status & regs->isr_ovr.mask) { /* @@ -2046,6 +2089,7 @@ static const struct stm32_adc_cfg stm32f4_adc_cfg = { .start_conv = stm32f4_adc_start_conv, .stop_conv = stm32f4_adc_stop_conv, .smp_cycles = stm32f4_adc_smp_cycles, + .irq_clear = stm32f4_adc_irq_clear, }; static const struct stm32_adc_cfg stm32h7_adc_cfg = { @@ -2057,6 +2101,7 @@ static const struct stm32_adc_cfg stm32h7_adc_cfg = { .prepare = stm32h7_adc_prepare, .unprepare = stm32h7_adc_unprepare, .smp_cycles = stm32h7_adc_smp_cycles, + .irq_clear = stm32h7_adc_irq_clear, }; static const struct stm32_adc_cfg stm32mp1_adc_cfg = { @@ -2069,6 +2114,7 @@ static const struct stm32_adc_cfg stm32mp1_adc_cfg = { .prepare = stm32h7_adc_prepare, .unprepare = stm32h7_adc_unprepare, .smp_cycles = stm32h7_adc_smp_cycles, + .irq_clear = stm32h7_adc_irq_clear, }; static const struct of_device_id stm32_adc_of_match[] = { -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: adc: mediatek: fix unset field" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: mediatek: fix unset field to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 15207a92e019803d62687455d8aa2ff9eb3dc82c Mon Sep 17 00:00:00 2001 From: Fabien Parent <fparent(a)baylibre.com> Date: Sun, 18 Oct 2020 21:46:44 +0200 Subject: iio: adc: mediatek: fix unset field dev_comp field is used in a couple of places but it is never set. This results in kernel oops when dereferencing a NULL pointer. Set the `dev_comp` field correctly in the probe function. Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support") Signed-off-by: Fabien Parent <fparent(a)baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/mt6577_auxadc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c index ac415cb089cd..79c1dd68b909 100644 --- a/drivers/iio/adc/mt6577_auxadc.c +++ b/drivers/iio/adc/mt6577_auxadc.c @@ -9,9 +9,9 @@ #include <linux/err.h> #include <linux/kernel.h> #include <linux/module.h> -#include <linux/of.h> -#include <linux/of_device.h> +#include <linux/mod_devicetable.h> #include <linux/platform_device.h> +#include <linux/property.h> #include <linux/iopoll.h> #include <linux/io.h> #include <linux/iio/iio.h> @@ -276,6 +276,8 @@ static int mt6577_auxadc_probe(struct platform_device *pdev) goto err_disable_clk; } + adc_dev->dev_comp = device_get_match_data(&pdev->dev); + mutex_init(&adc_dev->lock); mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC, -- 2.29.2

4 years, 11 months

1
0
0 0

patch "iio: cros_ec: Use default frequencies when EC returns invalid" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: cros_ec: Use default frequencies when EC returns invalid to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 56e4f2dda23c6d39d327944faa89efaa4eb290d1 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou <gwendal(a)chromium.org> Date: Tue, 30 Jun 2020 08:37:30 -0700 Subject: iio: cros_ec: Use default frequencies when EC returns invalid information Minimal and maximal frequencies supported by a sensor is queried. On some older machines, these frequencies are not returned properly and the EC returns 0 instead. When returned maximal frequency is 0, ignore the information and use default frequencies instead. Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Link: https://lore.kernel.org/r/20200630153730.3302889-1-gwendal@chromium.org CC: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- .../cros_ec_sensors/cros_ec_sensors_core.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index c62cacc04672..e3f507771f17 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -256,7 +256,7 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent); struct cros_ec_dev *ec = sensor_hub->ec; struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev); - u32 ver_mask; + u32 ver_mask, temp; int frequencies[ARRAY_SIZE(state->frequencies) / 2] = { 0 }; int ret, i; @@ -311,10 +311,16 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, &frequencies[2], &state->fifo_max_event_count); } else { - frequencies[1] = state->resp->info_3.min_frequency; - frequencies[2] = state->resp->info_3.max_frequency; - state->fifo_max_event_count = - state->resp->info_3.fifo_max_event_count; + if (state->resp->info_3.max_frequency == 0) { + get_default_min_max_freq(state->resp->info.type, + &frequencies[1], + &frequencies[2], + &temp); + } else { + frequencies[1] = state->resp->info_3.min_frequency; + frequencies[2] = state->resp->info_3.max_frequency; + } + state->fifo_max_event_count = state->resp->info_3.fifo_max_event_count; } for (i = 0; i < ARRAY_SIZE(frequencies); i++) { state->frequencies[2 * i] = frequencies[i] / 1000; -- 2.29.2

4 years, 11 months

1
0
0 0

[PATCH] MIPS: reserve the memblock right after the kernel

by Alexander A Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Linux doesn't own the memory immediately after the kernel image. On Octeon bootloader places a shared structure right close after the kernel _end, refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c. If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc() inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns memory block overlapping with the above octeon_bootinfo structure, which is being overwritten afterwards. Cc: stable(a)vger.kernel.org Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> --- arch/mips/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 0d42532..f6cf2f6 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -504,6 +504,12 @@ static void __init check_kernel_sections_mem(void) if (!memblock_is_region_memory(start, size)) { pr_info("Kernel sections are not in the memory maps\n"); memblock_add(start, size); + /* + * Octeon bootloader places shared data structure right after + * the kernel => make sure it will not be corrupted. + */ + memblock_reserve(__pa_symbol(&_end), + start + size - __pa_symbol(&_end)); } } -- 2.10.2

4 years, 11 months

7
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror