November 2020 - Linux-stable-mirror

FAILED: patch "[PATCH] null_blk: Fix scheduling in atomic with zoned mode" failed to apply to 5.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From e1777d099728a76a8f8090f89649aac961e7e530 Mon Sep 17 00:00:00 2001 From: Damien Le Moal <damien.lemoal(a)wdc.com> Date: Fri, 6 Nov 2020 20:01:41 +0900 Subject: [PATCH] null_blk: Fix scheduling in atomic with zoned mode Commit aa1c09cb65e2 ("null_blk: Fix locking in zoned mode") changed zone locking to using the potentially sleeping wait_on_bit_io() function. This is acceptable when memory backing is enabled as the device queue is in that case marked as blocking, but this triggers a scheduling while in atomic context with memory backing disabled. Fix this by relying solely on the device zone spinlock for zone information protection without temporarily releasing this lock around null_process_cmd() execution in null_zone_write(). This is OK to do since when memory backing is disabled, command processing does not block and the memory backing lock nullb->lock is unused. This solution avoids the overhead of having to mark a zoned null_blk device queue as blocking when memory backing is unused. This patch also adds comments to the zone locking code to explain the unusual locking scheme. Fixes: aa1c09cb65e2 ("null_blk: Fix locking in zoned mode") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Cc: stable(a)vger.kernel.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/block/null_blk.h b/drivers/block/null_blk.h index cfd00ad40355..c24d9b5ad81a 100644 --- a/drivers/block/null_blk.h +++ b/drivers/block/null_blk.h @@ -47,7 +47,7 @@ struct nullb_device { unsigned int nr_zones_closed; struct blk_zone *zones; sector_t zone_size_sects; - spinlock_t zone_dev_lock; + spinlock_t zone_lock; unsigned long *zone_locks; unsigned long size; /* device size in MB */ diff --git a/drivers/block/null_blk_zoned.c b/drivers/block/null_blk_zoned.c index 8775acbb4f8f..beb34b4f76b0 100644 --- a/drivers/block/null_blk_zoned.c +++ b/drivers/block/null_blk_zoned.c @@ -46,11 +46,20 @@ int null_init_zoned_dev(struct nullb_device *dev, struct request_queue *q) if (!dev->zones) return -ENOMEM; - spin_lock_init(&dev->zone_dev_lock); - dev->zone_locks = bitmap_zalloc(dev->nr_zones, GFP_KERNEL); - if (!dev->zone_locks) { - kvfree(dev->zones); - return -ENOMEM; + /* + * With memory backing, the zone_lock spinlock needs to be temporarily + * released to avoid scheduling in atomic context. To guarantee zone + * information protection, use a bitmap to lock zones with + * wait_on_bit_lock_io(). Sleeping on the lock is OK as memory backing + * implies that the queue is marked with BLK_MQ_F_BLOCKING. + */ + spin_lock_init(&dev->zone_lock); + if (dev->memory_backed) { + dev->zone_locks = bitmap_zalloc(dev->nr_zones, GFP_KERNEL); + if (!dev->zone_locks) { + kvfree(dev->zones); + return -ENOMEM; + } } if (dev->zone_nr_conv >= dev->nr_zones) { @@ -137,12 +146,17 @@ void null_free_zoned_dev(struct nullb_device *dev) static inline void null_lock_zone(struct nullb_device *dev, unsigned int zno) { - wait_on_bit_lock_io(dev->zone_locks, zno, TASK_UNINTERRUPTIBLE); + if (dev->memory_backed) + wait_on_bit_lock_io(dev->zone_locks, zno, TASK_UNINTERRUPTIBLE); + spin_lock_irq(&dev->zone_lock); } static inline void null_unlock_zone(struct nullb_device *dev, unsigned int zno) { - clear_and_wake_up_bit(zno, dev->zone_locks); + spin_unlock_irq(&dev->zone_lock); + + if (dev->memory_backed) + clear_and_wake_up_bit(zno, dev->zone_locks); } int null_report_zones(struct gendisk *disk, sector_t sector, @@ -322,7 +336,6 @@ static blk_status_t null_zone_write(struct nullb_cmd *cmd, sector_t sector, return null_process_cmd(cmd, REQ_OP_WRITE, sector, nr_sectors); null_lock_zone(dev, zno); - spin_lock(&dev->zone_dev_lock); switch (zone->cond) { case BLK_ZONE_COND_FULL: @@ -375,9 +388,17 @@ static blk_status_t null_zone_write(struct nullb_cmd *cmd, sector_t sector, if (zone->cond != BLK_ZONE_COND_EXP_OPEN) zone->cond = BLK_ZONE_COND_IMP_OPEN; - spin_unlock(&dev->zone_dev_lock); + /* + * Memory backing allocation may sleep: release the zone_lock spinlock + * to avoid scheduling in atomic context. Zone operation atomicity is + * still guaranteed through the zone_locks bitmap. + */ + if (dev->memory_backed) + spin_unlock_irq(&dev->zone_lock); ret = null_process_cmd(cmd, REQ_OP_WRITE, sector, nr_sectors); - spin_lock(&dev->zone_dev_lock); + if (dev->memory_backed) + spin_lock_irq(&dev->zone_lock); + if (ret != BLK_STS_OK) goto unlock; @@ -392,7 +413,6 @@ static blk_status_t null_zone_write(struct nullb_cmd *cmd, sector_t sector, ret = BLK_STS_OK; unlock: - spin_unlock(&dev->zone_dev_lock); null_unlock_zone(dev, zno); return ret; @@ -516,9 +536,7 @@ static blk_status_t null_zone_mgmt(struct nullb_cmd *cmd, enum req_opf op, null_lock_zone(dev, i); zone = &dev->zones[i]; if (zone->cond != BLK_ZONE_COND_EMPTY) { - spin_lock(&dev->zone_dev_lock); null_reset_zone(dev, zone); - spin_unlock(&dev->zone_dev_lock); trace_nullb_zone_op(cmd, i, zone->cond); } null_unlock_zone(dev, i); @@ -530,7 +548,6 @@ static blk_status_t null_zone_mgmt(struct nullb_cmd *cmd, enum req_opf op, zone = &dev->zones[zone_no]; null_lock_zone(dev, zone_no); - spin_lock(&dev->zone_dev_lock); switch (op) { case REQ_OP_ZONE_RESET: @@ -550,8 +567,6 @@ static blk_status_t null_zone_mgmt(struct nullb_cmd *cmd, enum req_opf op, break; } - spin_unlock(&dev->zone_dev_lock); - if (ret == BLK_STS_OK) trace_nullb_zone_op(cmd, zone_no, zone->cond);

4 years, 5 months

4
3
0 0

[PATCH for 5.4] powerpc/603: Always fault when _PAGE_ACCESSED is not set

by Christophe Leroy

[That is backport of 11522448e641e8f1690c9db06e01985e8e19b401 to linux 5.4] The kernel expects pte_young() to work regardless of CONFIG_SWAP. Make sure a minor fault is taken to set _PAGE_ACCESSED when it is not already set, regardless of the selection of CONFIG_SWAP. Fixes: 84de6ab0e904 ("powerpc/603: don't handle PAGE_ACCESSED in TLB miss handlers.") Cc: stable(a)vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/a44367744de54e2315b2f1a8cbbd7f88488072e0.16023428… --- arch/powerpc/kernel/head_32.S | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 5e2f2fd78b94..126ba5438430 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -418,11 +418,7 @@ InstructionTLBMiss: cmplw 0,r1,r3 #endif mfspr r2, SPRN_SPRG_PGDIR -#ifdef CONFIG_SWAP li r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC -#else - li r1,_PAGE_PRESENT | _PAGE_EXEC -#endif #if defined(CONFIG_MODULES) || defined(CONFIG_DEBUG_PAGEALLOC) bge- 112f lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address, use */ @@ -484,11 +480,7 @@ DataLoadTLBMiss: lis r1,PAGE_OFFSET@h /* check if kernel address */ cmplw 0,r1,r3 mfspr r2, SPRN_SPRG_PGDIR -#ifdef CONFIG_SWAP li r1, _PAGE_PRESENT | _PAGE_ACCESSED -#else - li r1, _PAGE_PRESENT -#endif bge- 112f lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address, use */ addi r2, r2, (swapper_pg_dir - PAGE_OFFSET)@l /* kernel page table */ @@ -564,11 +556,7 @@ DataStoreTLBMiss: lis r1,PAGE_OFFSET@h /* check if kernel address */ cmplw 0,r1,r3 mfspr r2, SPRN_SPRG_PGDIR -#ifdef CONFIG_SWAP li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED -#else - li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT -#endif bge- 112f lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address, use */ addi r2, r2, (swapper_pg_dir - PAGE_OFFSET)@l /* kernel page table */ -- 2.25.0

4 years, 5 months

2
1
0 0

Stable backport request for 44492e70adc8 ("rtw88: pci: Power cycle device during shutdown")

by Kai-Heng Feng

Hi, Please backport 44492e70adc8 to 5.4 stable. The commit fixes broken WiFi for many users. Currently only stable 5.4 misses this patch, older kernels don't have rtw88. Kai-Heng

4 years, 5 months

2
1
0 0

[PATCH stable-5.4] drm/i915: Correctly set SFC capability for video engines

by Daniele Ceraolo Spurio

From: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota(a)intel.com> Commit 5ce6861d36ed5207aff9e5eead4c7cc38a986586 upstream. This backport targets stable version 5.4, since the original patch fails to apply there, due to a variable having moved from one struct to another. The only change required for the patch to apply to 5.4 is to use the correct structure: - (engine->gt->info.vdbox_sfc_access & ++ (RUNTIME_INFO(i915)->vdbox_sfc_access & Original commit message below. SFC capability of video engines is not set correctly because i915 is testing for incorrect bits. Fixes: c5d3e39caa45 ("drm/i915: Engine discovery query") Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota(a)intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: <stable(a)vger.kernel.org> # v5.3+ Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201106011842.36203-1-daniel… (cherry picked from commit ad18fa0f5f052046cad96fee762b5c64f42dd86a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 4ce8626b140e..8073758d1036 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -354,7 +354,8 @@ static void __setup_engine_capabilities(struct intel_engine_cs *engine) * instances. */ if ((INTEL_GEN(i915) >= 11 && - RUNTIME_INFO(i915)->vdbox_sfc_access & engine->mask) || + (RUNTIME_INFO(i915)->vdbox_sfc_access & + BIT(engine->instance))) || (INTEL_GEN(i915) >= 9 && engine->instance == 0)) engine->uabi_capabilities |= I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC; -- 2.29.2

4 years, 5 months

2
1
0 0

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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2020