June 2023 - Linux-stable-mirror

[v2, 1/2] mtd: spinand: toshiba: Fix ecc_get_status

by Olivier Maignial

Reading ECC status is failing. tx58cxgxsxraix_ecc_get_status() is using on-stack buffer for SPINAND_GET_FEATURE_OP() output. It is not suitable for DMA needs of spi-mem. Fix this by using the spi-mem operations dedicated buffer spinand->scratchbuf. See spinand->scratchbuf: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc… spi_mem_check_op(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… Fixes: 10949af1681d ("mtd: spinand: Add initial support for Toshiba TC58CVG2S0H") Cc: stable(a)vger.kernel.org Signed-off-by: Olivier Maignial <olivier.maignial(a)hotmail.fr> --- drivers/mtd/nand/spi/toshiba.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c index 7380b1ebaccd..a80427c13121 100644 --- a/drivers/mtd/nand/spi/toshiba.c +++ b/drivers/mtd/nand/spi/toshiba.c @@ -73,7 +73,7 @@ static int tx58cxgxsxraix_ecc_get_status(struct spinand_device *spinand, { struct nand_device *nand = spinand_to_nand(spinand); u8 mbf = 0; - struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, &mbf); + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, spinand->scratchbuf); switch (status & STATUS_ECC_MASK) { case STATUS_ECC_NO_BITFLIPS: @@ -92,7 +92,7 @@ static int tx58cxgxsxraix_ecc_get_status(struct spinand_device *spinand, if (spi_mem_exec_op(spinand->spimem, &op)) return nanddev_get_ecc_conf(nand)->strength; - mbf >>= 4; + mbf = *(spinand->scratchbuf) >> 4; if (WARN_ON(mbf > nanddev_get_ecc_conf(nand)->strength || !mbf)) return nanddev_get_ecc_conf(nand)->strength; -- 2.34.1

10 months, 1 week

2
1
0 0

[v2, 2/2] mtd: spinand: winbond: Fix ecc_get_status

by Olivier Maignial

Reading ECC status is failing. w25n02kv_ecc_get_status() is using on-stack buffer for SPINAND_GET_FEATURE_OP() output. It is not suitable for DMA needs of spi-mem. Fix this by using the spi-mem operations dedicated buffer spinand->scratchbuf. See spinand->scratchbuf: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc… spi_mem_check_op(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… Fixes: 6154c7a58348 ("mtd: spinand: winbond: add Winbond W25N02KV flash support") Cc: stable(a)vger.kernel.org Signed-off-by: Olivier Maignial <olivier.maignial(a)hotmail.fr> --- drivers/mtd/nand/spi/winbond.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c index 3ad58cd284d8..f507e3759301 100644 --- a/drivers/mtd/nand/spi/winbond.c +++ b/drivers/mtd/nand/spi/winbond.c @@ -108,7 +108,7 @@ static int w25n02kv_ecc_get_status(struct spinand_device *spinand, { struct nand_device *nand = spinand_to_nand(spinand); u8 mbf = 0; - struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, &mbf); + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, spinand->scratchbuf); switch (status & STATUS_ECC_MASK) { case STATUS_ECC_NO_BITFLIPS: @@ -126,7 +126,7 @@ static int w25n02kv_ecc_get_status(struct spinand_device *spinand, if (spi_mem_exec_op(spinand->spimem, &op)) return nanddev_get_ecc_conf(nand)->strength; - mbf >>= 4; + mbf = *(spinand->scratchbuf) >> 4; if (WARN_ON(mbf > nanddev_get_ecc_conf(nand)->strength || !mbf)) return nanddev_get_ecc_conf(nand)->strength; -- 2.34.1

10 months, 1 week

2
1
0 0

[RESEND] gpio: ws16c48: Fix off-by-one error in WS16C48 resource region extent

by William Breathitt Gray

The WinSystems WS16C48 I/O address region spans offsets 0x0 through 0xA, which is a total of 11 bytes. Fix the WS16C48_EXTENT define to the correct value of 11 so that access to necessary device registers is properly requested in the ws16c48_probe() callback by the devm_request_region() function call. Fixes: 2c05a0f29f41 ("gpio: ws16c48: Implement and utilize register structures") Cc: stable(a)vger.kernel.org Cc: Paul Demetrotion <pdemetrotion(a)winsystems.com> Signed-off-by: William Breathitt Gray <william.gray(a)linaro.org> --- drivers/gpio/gpio-ws16c48.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c index e73885a4dc32..afb42a8e916f 100644 --- a/drivers/gpio/gpio-ws16c48.c +++ b/drivers/gpio/gpio-ws16c48.c @@ -18,7 +18,7 @@ #include <linux/spinlock.h> #include <linux/types.h> -#define WS16C48_EXTENT 10 +#define WS16C48_EXTENT 11 #define MAX_NUM_WS16C48 max_num_isa_dev(WS16C48_EXTENT) static unsigned int base[MAX_NUM_WS16C48]; base-commit: 4827aae061337251bb91801b316157a78b845ec7 -- 2.39.2

10 months, 1 week

2
5
0 0

[PATCH AUTOSEL 6.1 01/15] wifi: cfg80211: remove links only on AP

by Sasha Levin

From: Johannes Berg <johannes.berg(a)intel.com> [ Upstream commit 34d4e3eb67fed9c19719bedb748e5a8b6ccc97a5 ] Since links are only controlled by userspace via cfg80211 in AP mode, also only remove them from the driver in that case. Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Gregory Greenman <gregory.greenman(a)intel.com> Link: https://lore.kernel.org/r/20230608163202.ed65b94916fa.I2458c46888284cc5ce30… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/wireless/util.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/net/wireless/util.c b/net/wireless/util.c index 39680e7bad45a..f433f3fdd9e94 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -5,7 +5,7 @@ * Copyright 2007-2009 Johannes Berg <johannes(a)sipsolutions.net> * Copyright 2013-2014 Intel Mobile Communications GmbH * Copyright 2017 Intel Deutschland GmbH - * Copyright (C) 2018-2022 Intel Corporation + * Copyright (C) 2018-2023 Intel Corporation */ #include <linux/export.h> #include <linux/bitops.h> @@ -2479,6 +2479,13 @@ void cfg80211_remove_links(struct wireless_dev *wdev) { unsigned int link_id; + /* + * links are controlled by upper layers (userspace/cfg) + * only for AP mode, so only remove them here for AP + */ + if (wdev->iftype != NL80211_IFTYPE_AP) + return; + wdev_lock(wdev); if (wdev->valid_links) { for_each_valid_link(wdev, link_id) -- 2.39.2

10 months, 1 week

2
15
0 0

Regression in 6.1.35 / 6.3.9

by Limonciello, Mario

[Public] Hi, A regression was reported in 6.4-rc6 that monitor resolutions are no longer present for anything but native resolution on eDP panels. This specific change backported into stable at 6.1.35 and 6.3.9: e749dd10e5f29 ("drm/amd/display: edp do not add non-edid timings") After discussing it with the original author, they submitted a revert commit for review: https://patchwork.freedesktop.org/patch/544273/ I suggested the revert also CC stable, and I expect this will go up in 6.5-rc1, but given the timing of the merge window and the original issue hit the stable trees, can we revert it sooner in the stable trees to avoid exposing the regression to more people? Thanks!

10 months, 1 week

5
6
0 0

[PATCH] KVM: arm64: timers: Use CNTHCTL_EL2 when setting non-CNTKCTL_EL1 bits

by Marc Zyngier

It recently appeared that, whien running VHE, there is a notable difference between using CNTKCTL_EL1 and CNTHCTL_EL2, despite what the architecture documents: - When accessed from EL2, bits [19:18] and [16:10] same bits have the same assignment as CNTHCTL_EL2 - When accessed from EL1, bits [19:18] and [16:10] are RES0 It is all OK, until you factor in NV, where the EL2 guest runs at EL1. In this configuration, CNTKCTL_EL11 doesn't trap, nor ends up in the VNCR page. This means that any write from the guest affecting CNTHCTL_EL2 using CNTKCTL_EL1 ends up losing some state. Not good. The fix it obvious: don't use CNTKCTL_EL1 if you want to change bits that are not part of the EL1 definition of CNTKCTL_EL1, and use CNTHCTL_EL2 instead. This doesn't change anything for a bare-metal OS, and fixes it when running under NV. The NV hypervisor will itself have to work harder to merge the two accessors. Note that there is a pending update to the architecture to address this issue by making the affected bits UNKNOWN when CNTKCTL_EL1 is user from EL2 with VHE enabled. Fixes: c605ee245097 ("KVM: arm64: timers: Allow physical offset without CNTPOFF_EL2") Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org # v6.4 --- arch/arm64/kvm/arch_timer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c index 0696732fa38c..6dcdae4d38cb 100644 --- a/arch/arm64/kvm/arch_timer.c +++ b/arch/arm64/kvm/arch_timer.c @@ -827,8 +827,8 @@ static void timer_set_traps(struct kvm_vcpu *vcpu, struct timer_map *map) assign_clear_set_bit(tpt, CNTHCTL_EL1PCEN << 10, set, clr); assign_clear_set_bit(tpc, CNTHCTL_EL1PCTEN << 10, set, clr); - /* This only happens on VHE, so use the CNTKCTL_EL1 accessor */ - sysreg_clear_set(cntkctl_el1, clr, set); + /* This only happens on VHE, so use the CNTHCTL_EL2 accessor. */ + sysreg_clear_set(cnthctl_el2, clr, set); } void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu) @@ -1563,7 +1563,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu) void kvm_timer_init_vhe(void) { if (cpus_have_final_cap(ARM64_HAS_ECV_CNTPOFF)) - sysreg_clear_set(cntkctl_el1, 0, CNTHCTL_ECV); + sysreg_clear_set(cnthctl_el2, 0, CNTHCTL_ECV); } int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr) -- 2.34.1

10 months, 1 week

3
5
0 0

[PATCH] HID: logitech-hidpp: rework one more time the retries attempts

by Benjamin Tissoires

Make the code looks less like Pascal. Extract the internal code inside a helper function, fix the initialization of the parameters used in the helper function (`hidpp->answer_available` was not reset and `*response` wasn't too), and use a `do {...} while();` loop. Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Cc: stable(a)vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> --- as requested by https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_V… This is a rewrite of that particular piece of code. --- drivers/hid/hid-logitech-hidpp.c | 102 +++++++++++++++++++++++---------------- 1 file changed, 61 insertions(+), 41 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index dfe8e09a18de..3d1ffe199f08 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -275,21 +275,20 @@ static int __hidpp_send_report(struct hid_device *hdev, } /* - * hidpp_send_message_sync() returns 0 in case of success, and something else - * in case of a failure. - * - If ' something else' is positive, that means that an error has been raised - * by the protocol itself. - * - If ' something else' is negative, that means that we had a classic error - * (-ENOMEM, -EPIPE, etc...) + * Effectively send the message to the device, waiting for its answer. + * + * Must be called with hidpp->send_mutex locked + * + * Same return protocol than hidpp_send_message_sync(): + * - success on 0 + * - negative error means transport error + * - positive value means protocol error */ -static int hidpp_send_message_sync(struct hidpp_device *hidpp, +static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp, struct hidpp_report *message, struct hidpp_report *response) { - int ret = -1; - int max_retries = 3; - - mutex_lock(&hidpp->send_mutex); + int ret; hidpp->send_receive_buf = response; hidpp->answer_available = false; @@ -300,41 +299,62 @@ static int hidpp_send_message_sync(struct hidpp_device *hidpp, */ *response = *message; - for (; max_retries != 0 && ret; max_retries--) { - ret = __hidpp_send_report(hidpp->hid_dev, message); + ret = __hidpp_send_report(hidpp->hid_dev, message); + if (ret) { + dbg_hid("__hidpp_send_report returned err: %d\n", ret); + memset(response, 0, sizeof(struct hidpp_report)); + return ret; + } - if (ret) { - dbg_hid("__hidpp_send_report returned err: %d\n", ret); - memset(response, 0, sizeof(struct hidpp_report)); - break; - } + if (!wait_event_timeout(hidpp->wait, hidpp->answer_available, + 5*HZ)) { + dbg_hid("%s:timeout waiting for response\n", __func__); + memset(response, 0, sizeof(struct hidpp_report)); + return -ETIMEDOUT; + } - if (!wait_event_timeout(hidpp->wait, hidpp->answer_available, - 5*HZ)) { - dbg_hid("%s:timeout waiting for response\n", __func__); - memset(response, 0, sizeof(struct hidpp_report)); - ret = -ETIMEDOUT; - break; - } + if (response->report_id == REPORT_ID_HIDPP_SHORT && + response->rap.sub_id == HIDPP_ERROR) { + ret = response->rap.params[1]; + dbg_hid("%s:got hidpp error %02X\n", __func__, ret); + return ret; + } - if (response->report_id == REPORT_ID_HIDPP_SHORT && - response->rap.sub_id == HIDPP_ERROR) { - ret = response->rap.params[1]; - dbg_hid("%s:got hidpp error %02X\n", __func__, ret); + if ((response->report_id == REPORT_ID_HIDPP_LONG || + response->report_id == REPORT_ID_HIDPP_VERY_LONG) && + response->fap.feature_index == HIDPP20_ERROR) { + ret = response->fap.params[1]; + dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret); + return ret; + } + + return 0; +} + +/* + * hidpp_send_message_sync() returns 0 in case of success, and something else + * in case of a failure. + * - If ' something else' is positive, that means that an error has been raised + * by the protocol itself. + * - If ' something else' is negative, that means that we had a classic error + * (-ENOMEM, -EPIPE, etc...) + */ +static int hidpp_send_message_sync(struct hidpp_device *hidpp, + struct hidpp_report *message, + struct hidpp_report *response) +{ + int ret; + int max_retries = 3; + + mutex_lock(&hidpp->send_mutex); + + do { + ret = __do_hidpp_send_message_sync(hidpp, message, response); + if (ret != HIDPP20_ERROR_BUSY) break; - } - if ((response->report_id == REPORT_ID_HIDPP_LONG || - response->report_id == REPORT_ID_HIDPP_VERY_LONG) && - response->fap.feature_index == HIDPP20_ERROR) { - ret = response->fap.params[1]; - if (ret != HIDPP20_ERROR_BUSY) { - dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret); - break; - } - dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret); - } - } + dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret); + } while (--max_retries); mutex_unlock(&hidpp->send_mutex); return ret; --- base-commit: b98ec211af5508457e2b1c4cc99373630a83fa81 change-id: 20230621-logitech-fixes-a4c0e66ea2ad Best regards, -- Benjamin Tissoires <benjamin.tissoires(a)redhat.com>

10 months, 1 week

4
9
0 0

[PATCH v4 00/17] Venus QoL / maintainability fixes

by Konrad Dybcio

v3 -> v4: - Rebase on Stanimir's venus-for-next-v6.5 - Collapse 2 identical if-statements in "Sanitize venus_boot_core() per-VPU-version" - Reword "Assign registers based on VPU version" - Check for IS_IRIS2_1() instead of wrongly checking for core->use_tz, update commit msg in "media: venus: firmware: Correct IS_V6() checks" - Access correct struct fields in "Use newly-introduced hfi_buffer_requirements accessors", drop Bryan's r-b v3: https://lore.kernel.org/r/20230228-topic-venus-v3-0-6092ae43b58f@linaro.org v2 -> v3: - Rephrase "Write to VIDC_CTRL_INIT after unmasking interrupts" commit msg - Drop "Remap bufreq fields on HFI6XX" - Rephrase "Introduce VPU version distinction" commit msg - Better explain "Leave a clue for homegrown porters" - Drop incorrect fixes tags/rephrase version check alternations - Drop AR50L/IRIS1 from if-conditions, they'll be introduced separately - pick up tags - rebase on next-20230517 (no effective changes) v2: https://lore.kernel.org/r/20230228-topic-venus-v2-0-d95d14949c79@linaro.org v1 -> v2: - Move "Write to VIDC_CTRL_INIT after unmasking interrupts" up and add a Fixes tag & Cc stable - Reword the comment in "Correct IS_V6() checks" - Move up "media: venus: Remap bufreq fields on HFI6XX", add Fixes and Cc stable - Use better English in "Use newly-introduced hfi_buffer_requirements accessors" commit message - Mention "Restrict writing SCIACMDARG3 to Venus V1/V2" doesn't seem to regress SM8250 in the commit message - Pick up tags (note: I capitalized the R in Dikshita's 'reviewed-by' and removed one occurrence of random '**' to make sure review tools like b4 don't go crazy) - Handle AR50_LITE in "Assign registers based on VPU version" - Drop /* VPUn */ comments, they're invalid as explained by Vikash - Take a different approach to the sys_idle problem in patch 1 v1: https://lore.kernel.org/r/20230228-topic-venus-v1-0-58c2c88384e9@linaro.org Currently upstream assumes all (well, almost all - see 7280 or CrOS specific checks) Venus implementations using the same version of the Hardware Firmware Interface can be treated the same way. This is however not the case. This series tries to introduce the groundwork to start differentiating them based on the VPU (Video Processing Unit) hardware type, fixes a couple of issues that were an effect of that generalized assumption and lays the foundation for supporting 8150 (IRIS1) and SM6115/QCM2290 (AR50 Lite), which will hopefully come soon. Tested on 8250, but pretty please test it on your boards too! Signed-off-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> --- Konrad Dybcio (17): media: venus: hfi_venus: Only consider sys_idle_indicator on V1 media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts media: venus: Introduce VPU version distinction media: venus: Add vpu_version to most SoCs media: venus: firmware: Leave a clue about obtaining CP VARs media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version media: venus: core: Assign registers based on VPU version media: venus: hfi_venus: Sanitize venus_halt_axi() per-VPU-version media: venus: hfi_venus: Sanitize venus_isr() per-VPU-version media: venus: hfi_venus: Sanitize venus_cpu_and_video_core_idle() per-VPU-version media: venus: hfi_venus: Sanitize venus_cpu_idle_and_pc_ready() per-VPU-version media: venus: firmware: Sanitize per-VPU-version media: venus: hfi_platform: Check vpu_version instead of device compatible media: venus: vdec: Sanitize vdec_set_work_route() per-VPU-version media: venus: Introduce accessors for remapped hfi_buffer_reqs members media: venus: Use newly-introduced hfi_buffer_requirements accessors media: venus: hfi_venus: Restrict writing SCIACMDARG3 to Venus V1/V2 drivers/media/platform/qcom/venus/core.c | 7 ++- drivers/media/platform/qcom/venus/core.h | 15 ++++++ drivers/media/platform/qcom/venus/firmware.c | 18 +++++-- drivers/media/platform/qcom/venus/helpers.c | 7 +-- drivers/media/platform/qcom/venus/hfi_helper.h | 61 +++++++++++++++++++--- drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +- .../media/platform/qcom/venus/hfi_plat_bufs_v6.c | 22 ++++---- drivers/media/platform/qcom/venus/hfi_platform.c | 2 +- drivers/media/platform/qcom/venus/hfi_venus.c | 42 +++++++-------- drivers/media/platform/qcom/venus/vdec.c | 10 ++-- drivers/media/platform/qcom/venus/vdec_ctrls.c | 2 +- drivers/media/platform/qcom/venus/venc.c | 4 +- drivers/media/platform/qcom/venus/venc_ctrls.c | 2 +- 13 files changed, 133 insertions(+), 61 deletions(-) --- base-commit: 9f9f8ca6f012d25428f8605cb36369a449db8508 change-id: 20230228-topic-venus-70ea3bc76688 Best regards, -- Konrad Dybcio <konrad.dybcio(a)linaro.org>

10 months, 1 week

2
3
0 0

[PATCH v3 1/4] tpm_tis: Explicitly check for error code

by Alexander Steffen

recv_data either returns the number of received bytes, or a negative value representing an error code. Adding the return value directly to the total number of received bytes therefore looks a little weird, since it might add a negative error code to a sum of bytes. The following check for size < expected usually makes the function return ETIME in that case, so it does not cause too many problems in practice. But to make the code look cleaner and because the caller might still be interested in the original error code, explicitly check for the presence of an error code and pass that through. Cc: stable(a)vger.kernel.org Fixes: cb5354253af2 ("[PATCH] tpm: spacing cleanups 2") Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com> --- drivers/char/tpm/tpm_tis_core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index 558144fa707a..aaaa136044ae 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -363,8 +363,13 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count) goto out; } - size += recv_data(chip, &buf[TPM_HEADER_SIZE], - expected - TPM_HEADER_SIZE); + rc = recv_data(chip, &buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE); + if (rc < 0) { + size = rc; + goto out; + } + size += rc; if (size < expected) { dev_err(&chip->dev, "Unable to read remainder of result\n"); size = -ETIME; -- 2.25.1

10 months, 1 week

2
1
0 0

[PATCH 2/2] drm/ofdrm: Update expected device name

by Cyril Brulebois

Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"), as spotted by Frédéric Bonnard, the historical "of-display" device is gone: the updated logic creates "of-display.0" instead, then as many "of-display.N" as required. This means that offb no longer finds the expected device, which prevents the Debian Installer from setting up its interface, at least on ppc64el. Given the code similarity it is likely to affect ofdrm in the same way. It might be better to iterate on all possible nodes, but updating the hardcoded device from "of-display" to "of-display.0" is likely to help as a first step. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217328 Link: https://bugs.debian.org/1033058 Fixes: 241d2fb56a18 ("of: Make OF framebuffer device names unique") Cc: stable(a)vger.kernel.org # v6.2+ Signed-off-by: Cyril Brulebois <cyril(a)debamax.com> --- drivers/gpu/drm/tiny/ofdrm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c index 6e349ca42485..92df021d71df 100644 --- a/drivers/gpu/drm/tiny/ofdrm.c +++ b/drivers/gpu/drm/tiny/ofdrm.c @@ -1390,7 +1390,7 @@ MODULE_DEVICE_TABLE(of, ofdrm_of_match_display); static struct platform_driver ofdrm_platform_driver = { .driver = { - .name = "of-display", + .name = "of-display.0", .of_match_table = ofdrm_of_match_display, }, .probe = ofdrm_probe, -- 2.30.2

10 months, 1 week

6
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023