August 2020 - Linux-stable-mirror

Re: [PATCH 1/7] x86/debug: Allow a single level of #DB recursion

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a "Fixes:" tag fixing commit: 9f58fdde95c9 ("x86/db: Split out dr6/7 handling"). The bot has tested the following trees: v5.8.2. v5.8.2: Failed to apply! Possible dependencies: 0b085e68f407 ("x86/entry: Consolidate 32/64 bit syscall entry") 27d6b4d14f5c ("x86/entry: Use generic syscall entry function") 517e499227be ("x86/entry: Cleanup idtentry_entry/exit_user") 8d5ea35c5e91 ("x86/entry: Consolidate check_user_regs()") a377ac1cd9d7 ("x86/entry: Move user return notifier out of loop") b037b09b9058 ("x86/entry: Rename idtentry_enter/exit_cond_rcu() to idtentry_enter/exit()") ba1f2b2eaa2a ("x86/entry: Fix NMI vs IRQ state tracking") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

4 years, 4 months

1
0
0 0

[PATCH] HID: i2c-hid: Always sleep 1ms after I2C_HID_PWR_ON commands

by Hans de Goede

Before this commit i2c_hid_parse() consists of the following steps: 1. Send power on cmd 2. usleep_range(1000, 5000) 3. Send reset cmd 4. Wait for reset to complete (device interrupt, or msleep(100)) 5. Send power on cmd 6. Try to read HID descriptor Notice how there is an usleep_range(1000, 5000) after the first power-on command, but not after the second power-on command. Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad, not having a delay after the second power-on command causes the HID descriptor to read as all zeros. In case we hit this on other devices too, the descriptor being all zeros can be recognized by the following message being logged many, many times: hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 Having 2 cases where we need a delay after sending the power-on command, seems to indicate that we should always sleep after the power-on command. So this commit fixes the all zeros HID descriptor issue by moving the existing usleep_range(1000, 5000) to the i2c_hid_set_power() function. Cc: stable(a)vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247 Reported-and-tested-by: Andrea Borgia <andrea(a)borgia.bo.it> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/hid/i2c-hid/i2c-hid-core.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 294c84e136d7..e5d7aaf39b5e 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -420,6 +420,17 @@ static int i2c_hid_set_power(struct i2c_client *client, int power_state) dev_err(&client->dev, "failed to change power setting.\n"); set_pwr_exit: + + /* + * The HID over I2C specification states that if a DEVICE needs time + * after the PWR_ON request, it should utilise CLOCK stretching. + * However, it has been observered that the Windows driver provides a + * 1ms sleep between the PWR_ON and RESET requests and that some devices + * rely on having a short delay after PWR_ON commands. + */ + if (power_state == I2C_HID_PWR_ON) + usleep_range(1000, 5000); + return ret; } @@ -441,15 +452,6 @@ static int i2c_hid_hwreset(struct i2c_client *client) if (ret) goto out_unlock; - /* - * The HID over I2C specification states that if a DEVICE needs time - * after the PWR_ON request, it should utilise CLOCK stretching. - * However, it has been observered that the Windows driver provides a - * 1ms sleep between the PWR_ON and RESET requests and that some devices - * rely on this. - */ - usleep_range(1000, 5000); - i2c_hid_dbg(ihid, "resetting...\n"); ret = i2c_hid_command(client, &hid_reset_cmd, NULL, 0); -- 2.26.2

4 years, 4 months

2
3
0 0

[PATCH 1/4] usb: typec: ucsi: Fix AB BA lock inversion

by Hans de Goede

Lockdep reports an AB BA lock inversion between ucsi_init() and ucsi_handle_connector_change(): AB order: 1. ucsi_init takes ucsi->ppm_lock (it runs with that locked for the duration of the function) 2. usci_init eventually end up calling ucsi_register_displayport, which takes ucsi_connector->lock BA order: 1. ucsi_handle_connector_change work is started, takes ucsi_connector->lock 2. ucsi_handle_connector_change calls ucsi_send_command which takes ucsi->ppm_lock The ppm_lock really only needs to be hold during 2 functions: ucsi_reset_ppm() and ucsi_run_command(). This commit fixes the AB BA lock inversion by making ucsi_init drop the ucsi->ppm_lock before it starts registering ports; and replacing any ucsi_run_command() calls after this point with ucsi_send_command() (which is a wrapper around run_command taking the lock while handling the command). Some of the replacing of ucsi_run_command with ucsi_send_command in the helpers used during port registration also fixes a number of code paths after registration which call ucsi_run_command() without holding the ppm_lock: 1. ucsi_altmode_update_active() call in ucsi/displayport.c 2. ucsi_register_altmodes() call from ucsi_handle_connector_change() (through ucsi_partner_change()) Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/usb/typec/ucsi/ucsi.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index d0c63afaf345..d9d93f83b2a6 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -205,7 +205,7 @@ void ucsi_altmode_update_active(struct ucsi_connector *con) int i; command = UCSI_GET_CURRENT_CAM | UCSI_CONNECTOR_NUMBER(con->num); - ret = ucsi_run_command(con->ucsi, command, &cur, sizeof(cur)); + ret = ucsi_send_command(con->ucsi, command, &cur, sizeof(cur)); if (ret < 0) { if (con->ucsi->version > 0x0100) { dev_err(con->ucsi->dev, @@ -354,7 +354,7 @@ ucsi_register_altmodes_nvidia(struct ucsi_connector *con, u8 recipient) command |= UCSI_GET_ALTMODE_RECIPIENT(recipient); command |= UCSI_GET_ALTMODE_CONNECTOR_NUMBER(con->num); command |= UCSI_GET_ALTMODE_OFFSET(i); - len = ucsi_run_command(con->ucsi, command, &alt, sizeof(alt)); + len = ucsi_send_command(con->ucsi, command, &alt, sizeof(alt)); /* * We are collecting all altmodes first and then registering. * Some type-C device will return zero length data beyond last @@ -431,7 +431,7 @@ static int ucsi_register_altmodes(struct ucsi_connector *con, u8 recipient) command |= UCSI_GET_ALTMODE_RECIPIENT(recipient); command |= UCSI_GET_ALTMODE_CONNECTOR_NUMBER(con->num); command |= UCSI_GET_ALTMODE_OFFSET(i); - len = ucsi_run_command(con->ucsi, command, alt, sizeof(alt)); + len = ucsi_send_command(con->ucsi, command, alt, sizeof(alt)); if (len <= 0) return len; @@ -904,7 +904,7 @@ static int ucsi_register_port(struct ucsi *ucsi, int index) /* Get connector capability */ command = UCSI_GET_CONNECTOR_CAPABILITY; command |= UCSI_CONNECTOR_NUMBER(con->num); - ret = ucsi_run_command(ucsi, command, &con->cap, sizeof(con->cap)); + ret = ucsi_send_command(ucsi, command, &con->cap, sizeof(con->cap)); if (ret < 0) return ret; @@ -953,8 +953,7 @@ static int ucsi_register_port(struct ucsi *ucsi, int index) /* Get the status */ command = UCSI_GET_CONNECTOR_STATUS | UCSI_CONNECTOR_NUMBER(con->num); - ret = ucsi_run_command(ucsi, command, &con->status, - sizeof(con->status)); + ret = ucsi_send_command(ucsi, command, &con->status, sizeof(con->status)); if (ret < 0) { dev_err(ucsi->dev, "con%d: failed to get status\n", con->num); return 0; @@ -1044,6 +1043,8 @@ int ucsi_init(struct ucsi *ucsi) goto err_reset; } + mutex_unlock(&ucsi->ppm_lock); + /* Register all connectors */ for (i = 0; i < ucsi->cap.num_connectors; i++) { ret = ucsi_register_port(ucsi, i); @@ -1054,12 +1055,10 @@ int ucsi_init(struct ucsi *ucsi) /* Enable all notifications */ ucsi->ntfy = UCSI_ENABLE_NTFY_ALL; command = UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy; - ret = ucsi_run_command(ucsi, command, NULL, 0); + ret = ucsi_send_command(ucsi, command, NULL, 0); if (ret < 0) goto err_unregister; - mutex_unlock(&ucsi->ppm_lock); - return 0; err_unregister: @@ -1071,6 +1070,7 @@ int ucsi_init(struct ucsi *ucsi) con->port = NULL; } + mutex_lock(&ucsi->ppm_lock); err_reset: ucsi_reset_ppm(ucsi); err: -- 2.26.2

4 years, 4 months

2
2
0 0

[PATCH v3] HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands

by Hans de Goede

Before this commit i2c_hid_parse() consists of the following steps: 1. Send power on cmd 2. usleep_range(1000, 5000) 3. Send reset cmd 4. Wait for reset to complete (device interrupt, or msleep(100)) 5. Send power on cmd 6. Try to read HID descriptor Notice how there is an usleep_range(1000, 5000) after the first power-on command, but not after the second power-on command. Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad, not having a delay after the second power-on command causes the HID descriptor to read as all zeros. In case we hit this on other devices too, the descriptor being all zeros can be recognized by the following message being logged many, many times: hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 At the same time as the BMAX Y13's touchpad issue was debugged, Kai-Heng was working on debugging some issues with Goodix i2c-hid touchpads. It turns out that these need a delay after a PWR_ON command too, otherwise they stop working after a suspend/resume cycle. According to Goodix a delay of minimal 60ms is needed. Having multiple cases where we need a delay after sending the power-on command, seems to indicate that we should always sleep after the power-on command. This commit fixes the mentioned issues by moving the existing 1ms sleep to the i2c_hid_set_power() function and changing it to a 60ms sleep. Cc: stable(a)vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247 Reported-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Reported-and-tested-by: Andrea Borgia <andrea(a)borgia.bo.it> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v3: - Fix Subject to say 60ms instead of 1ms Changes in v2: - Add Kai-Heng's case, with Goodix touchpads needing a delay after PWR_ON too, to the commit message - Add a Reported-by tag for Kai-Heng - Increase the delay to 60ms --- drivers/hid/i2c-hid/i2c-hid-core.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 294c84e136d7..dbd04492825d 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -420,6 +420,19 @@ static int i2c_hid_set_power(struct i2c_client *client, int power_state) dev_err(&client->dev, "failed to change power setting.\n"); set_pwr_exit: + + /* + * The HID over I2C specification states that if a DEVICE needs time + * after the PWR_ON request, it should utilise CLOCK stretching. + * However, it has been observered that the Windows driver provides a + * 1ms sleep between the PWR_ON and RESET requests. + * According to Goodix Windows even waits 60 ms after (other?) + * PWR_ON requests. Testing has confirmed that several devices + * will not work properly without a delay after a PWR_ON request. + */ + if (!ret && power_state == I2C_HID_PWR_ON) + msleep(60); + return ret; } @@ -441,15 +454,6 @@ static int i2c_hid_hwreset(struct i2c_client *client) if (ret) goto out_unlock; - /* - * The HID over I2C specification states that if a DEVICE needs time - * after the PWR_ON request, it should utilise CLOCK stretching. - * However, it has been observered that the Windows driver provides a - * 1ms sleep between the PWR_ON and RESET requests and that some devices - * rely on this. - */ - usleep_range(1000, 5000); - i2c_hid_dbg(ihid, "resetting...\n"); ret = i2c_hid_command(client, &hid_reset_cmd, NULL, 0); -- 2.28.0

4 years, 4 months

3
3
0 0

[PATCH v2 0/7] usb: dwc3: gadget: Fix TRB preparation

by Thinh Nguyen

There are a few issues in DWC3 driver when preparing for TRB. The driver needs to account the following: * MPS alignment for ZLP OUT direction * Extra TRBs when checking for available TRBs * SG entries size > request length Along with these fixes, there are some cleanup/refactoring patches in this series. Changes in v2: - Update remaining length when resume request - Remove unused variables - Add a missing "return 0" for dwc3_prepare_trbs() - Update doc indicating dwc3_prepare_trbs() can return other -errno Thinh Nguyen (7): usb: dwc3: gadget: Don't setup more than requested usb: dwc3: gadget: Fix handling ZLP usb: dwc3: gadget: Handle ZLP for sg requests usb: dwc3: gadget: Refactor preparing TRBs usb: dwc3: gadget: Account for extra TRB usb: dwc3: gadget: Rename misleading function names usb: dwc3: ep0: Skip ZLP setup for OUT drivers/usb/dwc3/ep0.c | 2 +- drivers/usb/dwc3/gadget.c | 247 +++++++++++++++++++++++--------------- 2 files changed, 148 insertions(+), 101 deletions(-) base-commit: e3ee0e740c3887d2293e8d54a8707218d70d86ca -- 2.28.0

4 years, 4 months

2
8
0 0

Re: [PATCH RESEND v3] iommu/tegra-smmu: Add missing locks around mapping operations

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140, v4.14.193, v4.9.232, v4.4.232. v5.8.2: Build OK! v5.7.16: Build OK! v5.4.59: Failed to apply! Possible dependencies: 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map") v4.19.140: Failed to apply! Possible dependencies: 06d60728ff5c ("iommu/dma: move the arm64 wrappers to common code") 44f6876a00e8 ("iommu/arm-smmu: Support non-strict mode") 46053c736854 ("dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops") 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map") 886643b76632 ("arm64: use the generic swiotlb_dma_ops") 92aec09cc879 ("iommu/dma: Move __iommu_dma_map") 96a299d24cfb ("iommu/arm-smmu: Add pm_runtime/sleep ops") c4dae366925f ("swiotlb: refactor swiotlb_map_page") d4a44f0750bb ("iommu/arm-smmu: Invoke pm_runtime across the driver") dff8d6c1ed58 ("swiotlb: remove the overflow buffer") fafadcd16595 ("swiotlb: don't dip into swiotlb pool for coherent allocations") v4.14.193: Failed to apply! Possible dependencies: 06d60728ff5c ("iommu/dma: move the arm64 wrappers to common code") 10dac04c79b1 ("mips: fix an off-by-one in dma_capable") 32b124492bdf ("iommu/io-pgtable-arm: Convert to IOMMU API TLB sync") 32ce3862af3c ("powerpc/lib: Implement PMEM API") 44f6876a00e8 ("iommu/arm-smmu: Support non-strict mode") 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map") 92aec09cc879 ("iommu/dma: Move __iommu_dma_map") 96a299d24cfb ("iommu/arm-smmu: Add pm_runtime/sleep ops") d4a44f0750bb ("iommu/arm-smmu: Invoke pm_runtime across the driver") ea8c64ace866 ("dma-mapping: move swiotlb arch helpers to a new header") v4.9.232: Failed to apply! Possible dependencies: 125458ab3aef ("iommu/arm-smmu: Fix 16-bit ASID configuration") 280b683ceace ("iommu/arm-smmu: Simplify ASID/VMID handling") 32b124492bdf ("iommu/io-pgtable-arm: Convert to IOMMU API TLB sync") 3677a649a751 ("iommu/arm-smmu: Fix for ThunderX erratum #27704") 44f6876a00e8 ("iommu/arm-smmu: Support non-strict mode") 452107c79035 ("iommu/arm-smmu: Tidy up context bank indexing") 523d7423e21b ("iommu/arm-smmu: Remove io-pgtable spinlock") 58188afeb727 ("iommu/arm-smmu-v3: Remove io-pgtable spinlock") 61bc671179f1 ("iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains") 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map") bdf95923086f ("iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed") d4a44f0750bb ("iommu/arm-smmu: Invoke pm_runtime across the driver") v4.4.232: Failed to apply! Possible dependencies: 267b62a96951 ("clk: tegra: pll: Update PLLM handling") 287980e49ffc ("remove lots of IS_ERR_VALUE abuses") 407254da291c ("clk: tegra: pll: Add logic for out-of-table rates for T210") 56fd27b31f1a ("clk: tegra: pll: Change misc_reg count from 3 to 6") 58188afeb727 ("iommu/arm-smmu-v3: Remove io-pgtable spinlock") 6583a6309e83 ("clk: tegra: pll: Add tegra_pll_wait_for_lock to clk header") 6929715cf6b9 ("clk: tegra: pll: Add support for PLLMB for Tegra210") 6b301a059eb2 ("clk: tegra: Add support for Tegra210 clocks") 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map") 7db864c9deb2 ("clk: tegra: pll: Simplify clk_enable_path") 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") 8f78515425da ("iommu/arm-smmu: Implement of_xlate() for SMMUv3") 9adb95949a34 ("iommu/arm-smmu: Support DMA-API domains") bc7f2ce0a7b5 ("iommu/arm-smmu: Don't fail device attach if already attached to a domain") bdf95923086f ("iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed") d907f4b4a178 ("clk: tegra: pll: Add logic for handling SDM data") f8d31489629c ("ACPICA: Debugger: Convert some mechanisms to OSPM specific") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

4 years, 4 months

1
0
0 0

[PATCH] powerpc/pseries: Do not initiate shutdown when system is running on UPS

by Vasant Hegde

As per PAPR specification whenever system is running on UPS we have to wait for predefined time (default 10mins) before initiating shutdown. We have user space tool (rtas_errd) to monitor for EPOW events and initiate shutdown after predefined time. Hence do not initiate shutdown whenever we get EPOW_SHUTDOWN_ON_UPS event. Fixes: 79872e35 (powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown) Cc: stable(a)vger.kernel.org # v4.0+ Cc: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Vasant Hegde <hegdevasant(a)linux.vnet.ibm.com> --- arch/powerpc/platforms/pseries/ras.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c index f3736fcd98fc..13c86a292c6d 100644 --- a/arch/powerpc/platforms/pseries/ras.c +++ b/arch/powerpc/platforms/pseries/ras.c @@ -184,7 +184,6 @@ static void handle_system_shutdown(char event_modifier) case EPOW_SHUTDOWN_ON_UPS: pr_emerg("Loss of system power detected. System is running on" " UPS/battery. Check RTAS error log for details\n"); - orderly_poweroff(true); break; case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS: -- 2.26.2

4 years, 4 months

3
3
0 0

Re: [PATCH 5/9] crypto: caam/qi - add support for more XTS key lengths

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a "Fixes:" tag fixing commit: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms"). The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140, v4.14.193. v5.8.2: Failed to apply! Possible dependencies: 1108da08e2c1 ("crypto: caam/qi - add fallback for XTS with more than 8B IV") a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys") b185a68710e0 ("crypto: qat - validate xts key") b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY") v5.7.16: Failed to apply! Possible dependencies: 1108da08e2c1 ("crypto: caam/qi - add fallback for XTS with more than 8B IV") a85211f36f3d ("crypto: qat - fallback for xts with 192 bit keys") b185a68710e0 ("crypto: qat - validate xts key") b8aa7dc5c753 ("crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY") v5.4.59: Failed to apply! Possible dependencies: 1108da08e2c1 ("crypto: caam/qi - add fallback for XTS with more than 8B IV") 64db5e7439fb ("crypto: sparc/aes - convert to skcipher API") 66d7fb94e4ff ("crypto: blake2s - generic C library implementation and selftest") 674f368a952c ("crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN") 746b2e024c67 ("crypto: lib - tidy up lib/crypto Kconfig and Makefile") 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") 7f725f41f627 ("crypto: powerpc - convert SPE AES algorithms to skcipher API") 7f9b0880925f ("crypto: blake2s - implement generic shash driver") 91d689337fe8 ("crypto: blake2b - add blake2b generic implementation") b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes") b95bba5d0114 ("crypto: skcipher - rename the crypto_blkcipher module and kconfig option") d00c06398154 ("crypto: s390/paes - convert to skcipher API") da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length") ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation") v4.19.140: Failed to apply! Possible dependencies: 0a5dff9882e5 ("crypto: arm/ghash - provide a synchronous version") 1108da08e2c1 ("crypto: caam/qi - add fallback for XTS with more than 8B IV") 1ca1b917940c ("crypto: chacha20-generic - refactor to allow varying number of rounds") 5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion") 674f368a952c ("crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN") 8a5a79d5556b ("crypto: x86/chacha20 - Add a 4-block AVX2 variant") 99680c5e9182 ("crypto: arm - convert to use crypto_simd_usable()") 9b17608f15b9 ("crypto: x86/chacha20 - Use larger block functions more aggressively") 9dbe3072c6b1 ("crypto: caam/qi - ablkcipher -> skcipher conversion") a5dd97f86211 ("crypto: x86/chacha20 - Add a 2-block AVX2 variant") aec48adce85d ("crypto: caam/qi - remove ablkcipher IV generation") c3b734dd325d ("crypto: x86/chacha20 - Support partial lengths in 8-block AVX2 variant") cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation") da6a66853a38 ("crypto: caam - silence .setkey in case of bad key length") db8e15a24957 ("crypto: x86/chacha20 - Support partial lengths in 4-block SSSE3 variant") e4e72063d3c0 ("crypto: x86/chacha20 - Support partial lengths in 1-block SSSE3 variant") v4.14.193: Failed to apply! Possible dependencies: 1108da08e2c1 ("crypto: caam/qi - add fallback for XTS with more than 8B IV") 5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion") 662f70ede597 ("crypto: caam - remove needless ablkcipher key copy") 7e0880b9fbbe ("crypto: caam - add Derived Key Protocol (DKP) support") 9dbe3072c6b1 ("crypto: caam/qi - ablkcipher -> skcipher conversion") cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

4 years, 4 months

1
0
0 0

[PATCH 8/9] drm/amd/display: Fix EDID parsing after resume from suspend

by Qingqing Zhuo

From: Stylon Wang <stylon.wang(a)amd.com> [Why] Resuming from suspend, CEA blocks from EDID are not parsed and no video modes can support YUV420. When this happens, output bpc cannot go over 8-bit with 4K modes on HDMI. [How] In amdgpu_dm_update_connector_after_detect(), drm_add_edid_modes() is called after drm_connector_update_edid_property() to fully parse EDID and update display info. Cc: stable(a)vger.kernel.org Signed-off-by: Stylon Wang <stylon.wang(a)amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas(a)amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 53bf8f60d30c..bfb06c168fba 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2202,6 +2202,7 @@ void amdgpu_dm_update_connector_after_detect( drm_connector_update_edid_property(connector, aconnector->edid); + drm_add_edid_modes(connector, aconnector->edid); if (aconnector->dc_link->aux_mode) drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux, -- 2.17.1

4 years, 4 months

2
3
0 0

[PATCH v8 02/17] drm/i915: Clear the repeater bit on HDCP disable

by Sean Paul

From: Sean Paul <seanpaul(a)chromium.org> On HDCP disable, clear the repeater bit. This ensures if we connect a non-repeater sink after a repeater, the bit is in the state we expect. Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c(a)intel.com> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@… #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@… #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-sean@… #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-sean@… #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-sean@p… #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-sean@p… #v7 Changes in v2: -Added to the set Changes in v3: -None I had previously agreed that clearing the rep_ctl bits on enable would also be a good idea. However when I committed that idea to code, it didn't look right. So let's rely on enables and disables being paired and everything outside of that will be considered a bug Changes in v4: -s/I915_(READ|WRITE)/intel_de_(read|write)/ Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None --- drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index 6189b7583277..1a0d49af2a08 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector) struct intel_hdcp *hdcp = &connector->hdcp; enum port port = dig_port->base.port; enum transcoder cpu_transcoder = hdcp->cpu_transcoder; + u32 repeater_ctl; int ret; drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n", @@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector *connector) return -ETIMEDOUT; } + repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder, + port); + intel_de_write(dev_priv, HDCP_REP_CTL, + intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl); + ret = hdcp->shim->toggle_signalling(dig_port, false); if (ret) { drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n"); -- Sean Paul, Software Engineer, Google / Chromium OS

4 years, 4 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020