October 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/dp_mst: Fix NULL deref in" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 3d887d512494d678b17c57b835c32f4e48d34f26 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023102726-arousal-ransack-d969@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3d887d512494d678b17c57b835c32f4e48d34f26 Mon Sep 17 00:00:00 2001 From: Lukasz Majczak <lma(a)semihalf.com> Date: Fri, 22 Sep 2023 08:34:10 +0200 Subject: [PATCH] drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper() As drm_dp_get_mst_branch_device_by_guid() is called from drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked, otherwise NULL dereference may occur in the call to the memcpy() and cause following: [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049 [12579.365878] #PF: supervisor read access in kernel mode [12579.365880] #PF: error_code(0x0000) - not-present page [12579.365882] PGD 0 P4D 0 [12579.365887] Oops: 0000 [#1] PREEMPT SMP NOPTI ... [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work [12579.365899] RIP: 0010:memcmp+0xb/0x29 [12579.365921] Call Trace: [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64 [12579.365930] drm_dp_mst_up_req_work+0x137/0x416 [12579.365933] process_one_work+0x1d0/0x419 [12579.365935] worker_thread+0x11a/0x289 [12579.365938] kthread+0x13e/0x14f [12579.365941] ? process_one_work+0x419/0x419 [12579.365943] ? kthread_blkcg+0x31/0x31 [12579.365946] ret_from_fork+0x1f/0x30 As get_mst_branch_device_by_guid_helper() is recursive, moving condition to the first line allow to remove a similar one for step over of NULL elements inside a loop. Fixes: 5e93b8208d3c ("drm/dp/mst: move GUID storage from mgr, port to only mst branch") Cc: <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> Reviewed-by: Radoslaw Biernacki <rad(a)chromium.org> Signed-off-by: Manasi Navare <navaremanasi(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230922063410.23626-1-lma@se… diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index ed96cfcfa304..8c929ef72c72 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -2574,14 +2574,14 @@ static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper( struct drm_dp_mst_branch *found_mstb; struct drm_dp_mst_port *port; + if (!mstb) + return NULL; + if (memcmp(mstb->guid, guid, 16) == 0) return mstb; list_for_each_entry(port, &mstb->ports, next) { - if (!port->mstb) - continue; - found_mstb = get_mst_branch_device_by_guid_helper(port->mstb, guid); if (found_mstb)

1 year, 5 months

2
1
0 0

FAILED: patch "[PATCH] drm/dp_mst: Fix NULL deref in" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 3d887d512494d678b17c57b835c32f4e48d34f26 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023102725-spiral-unglue-4f7c@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3d887d512494d678b17c57b835c32f4e48d34f26 Mon Sep 17 00:00:00 2001 From: Lukasz Majczak <lma(a)semihalf.com> Date: Fri, 22 Sep 2023 08:34:10 +0200 Subject: [PATCH] drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper() As drm_dp_get_mst_branch_device_by_guid() is called from drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked, otherwise NULL dereference may occur in the call to the memcpy() and cause following: [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049 [12579.365878] #PF: supervisor read access in kernel mode [12579.365880] #PF: error_code(0x0000) - not-present page [12579.365882] PGD 0 P4D 0 [12579.365887] Oops: 0000 [#1] PREEMPT SMP NOPTI ... [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work [12579.365899] RIP: 0010:memcmp+0xb/0x29 [12579.365921] Call Trace: [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64 [12579.365930] drm_dp_mst_up_req_work+0x137/0x416 [12579.365933] process_one_work+0x1d0/0x419 [12579.365935] worker_thread+0x11a/0x289 [12579.365938] kthread+0x13e/0x14f [12579.365941] ? process_one_work+0x419/0x419 [12579.365943] ? kthread_blkcg+0x31/0x31 [12579.365946] ret_from_fork+0x1f/0x30 As get_mst_branch_device_by_guid_helper() is recursive, moving condition to the first line allow to remove a similar one for step over of NULL elements inside a loop. Fixes: 5e93b8208d3c ("drm/dp/mst: move GUID storage from mgr, port to only mst branch") Cc: <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> Reviewed-by: Radoslaw Biernacki <rad(a)chromium.org> Signed-off-by: Manasi Navare <navaremanasi(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230922063410.23626-1-lma@se… diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index ed96cfcfa304..8c929ef72c72 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -2574,14 +2574,14 @@ static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper( struct drm_dp_mst_branch *found_mstb; struct drm_dp_mst_port *port; + if (!mstb) + return NULL; + if (memcmp(mstb->guid, guid, 16) == 0) return mstb; list_for_each_entry(port, &mstb->ports, next) { - if (!port->mstb) - continue; - found_mstb = get_mst_branch_device_by_guid_helper(port->mstb, guid); if (found_mstb)

1 year, 5 months

2
1
0 0

[PATCH] platform/x86: Add s2idle quirk for more Lenovo laptops

by David Lazar

commit 3bde7ec13c971445faade32172cb0b4370b841d9 upstream. When suspending to idle and resuming on some Lenovo laptops using the Mendocino APU, multiple NVME IOMMU page faults occur, showing up in dmesg as repeated errors: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b address=0xb6674000 flags=0x0000] The system is unstable afterwards. Applying the s2idle quirk introduced by commit 455cd867b85b ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops") allows these systems to work with the IOMMU enabled and s2idle resume to work. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024 Suggested-by: Mario Limonciello <mario.limonciello(a)amd.com> Suggested-by: Mark Pearson <mpearson-lenovo(a)squebb.ca> Signed-off-by: David Lazar <dlazar(a)gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Reviewed-by: Mark Pearson <mpearson-lenovo(a)squebb.ca> Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/platform/x86/amd/pmc/pmc-quirks.c | 73 +++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c index ad702463a65d3..6bbffb081053e 100644 --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c @@ -111,6 +111,79 @@ static const struct dmi_system_id fwbug_list[] = { DMI_MATCH(DMI_PRODUCT_NAME, "21A1"), } }, + /* https://bugzilla.kernel.org/show_bug.cgi?id=218024 */ + { + .ident = "V14 G4 AMN", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82YT"), + } + }, + { + .ident = "V14 G4 AMN", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "83GE"), + } + }, + { + .ident = "V15 G4 AMN", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82YU"), + } + }, + { + .ident = "V15 G4 AMN", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "83CQ"), + } + }, + { + .ident = "IdeaPad 1 14AMN7", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82VF"), + } + }, + { + .ident = "IdeaPad 1 15AMN7", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82VG"), + } + }, + { + .ident = "IdeaPad 1 15AMN7", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82X5"), + } + }, + { + .ident = "IdeaPad Slim 3 14AMN8", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82XN"), + } + }, + { + .ident = "IdeaPad Slim 3 15AMN8", + .driver_data = &quirk_s2idle_bug, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"), + } + }, /* https://gitlab.freedesktop.org/drm/amd/-/issues/2684 */ { .ident = "HP Laptop 15s-eq2xxx", -- cgit

1 year, 5 months

2
2
0 0

[PATCH v2] usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()

by Jimmy Hu

It is possible that typec_register_partner() returns ERR_PTR on failure. When port->partner is an error, a NULL pointer dereference may occur as shown below. [91222.095236][ T319] typec port0: failed to register partner (-17) ... [91225.061491][ T319] Unable to handle kernel NULL pointer dereference at virtual address 000000000000039f [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc [91225.308067][ T319] Call trace: [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8 [91225.355900][ T319] kthread_worker_fn+0x178/0x58c [91225.355902][ T319] kthread+0x150/0x200 [91225.355905][ T319] ret_from_fork+0x10/0x30 Add a check for port->partner to avoid dereferencing a NULL pointer. Fixes: 5e1d4c49fbc8 ("usb: typec: tcpm: Determine common SVDM Version") Cc: stable(a)vger.kernel.org Signed-off-by: Jimmy Hu <hhhuuu(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 6e843c511b85..792ec4ac7d8d 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -1625,6 +1625,9 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct typec_altmode *adev, if (PD_VDO_VID(p[0]) != USB_SID_PD) break; + if (IS_ERR_OR_NULL(port->partner)) + break; + if (PD_VDO_SVDM_VER(p[0]) < svdm_version) { typec_partner_set_svdm_version(port->partner, PD_VDO_SVDM_VER(p[0])); -- 2.42.0.758.gaed0368e0e-goog

1 year, 5 months

2
1
0 0

[PATCH v1] usb: typec: tcpm: only discover modes the port supports svids for

by RD Babiera

DisplayPort Alt Mode CTS test 10.3.1 verifies that the device can recognize the DP SVID in arbitrary locations within the Discover SVIDs response message. The test expects that the TCPM sends Discover Modes for the DisplayPort SVID first, but fails because the TCPM sends Discover Modes for all SVIDs regardless of whether or not the port supports them. After discovering the port partner's SVIDs, skip to the first SVID supported by the device when preparing the Discover Modes request. If other modes need to be discovered after the first Discover Modes message is returned, skip over SVIDs not supported by the device. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 46 +++++++++++++++++++++++++++++++---- 1 file changed, 41 insertions(+), 5 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 6e843c511b85..96636a6f1f7c 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -1543,6 +1543,38 @@ static bool svdm_consume_svids(struct tcpm_port *port, const u32 *p, int cnt) return false; } +static bool svdm_port_supports_svid(struct tcpm_port *port, u16 svid) +{ + int i; + + for (i = 0; i < ALTMODE_DISCOVERY_MAX; i++) { + struct typec_altmode *altmode = port->port_altmode[i]; + + if (!altmode) + return false; + if (altmode->svid == svid) + return true; + } + return false; +} + +/* + * This helper will continue to return the next supported SVID that the port + * needs to send DISCOVER_MODES to until the pmdata->svid_index is incremented after + * svdm_consume_modes() in tcpm_pd_svdm(). + */ +static int svdm_get_next_supported_svid(struct tcpm_port *port, struct pd_mode_data *pmdata) +{ + while (pmdata->svid_index < pmdata->nsvids) { + u16 svid = pmdata->svids[pmdata->svid_index]; + + if (svdm_port_supports_svid(port, svid)) + return svid; + pmdata->svid_index++; + } + return 0; +} + static void svdm_consume_modes(struct tcpm_port *port, const u32 *p, int cnt) { struct pd_mode_data *pmdata = &port->mode_data; @@ -1705,9 +1737,11 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct typec_altmode *adev, if (svdm_consume_svids(port, p, cnt)) { response[0] = VDO(USB_SID_PD, 1, svdm_version, CMD_DISCOVER_SVID); rlen = 1; - } else if (modep->nsvids && supports_modal(port)) { - response[0] = VDO(modep->svids[0], 1, svdm_version, - CMD_DISCOVER_MODES); + } else if (modep->nsvids && supports_modal(port) && + svdm_get_next_supported_svid(port, modep)) { + u16 svid = svdm_get_next_supported_svid(port, modep); + + response[0] = VDO(svid, 1, svdm_version, CMD_DISCOVER_MODES); rlen = 1; } break; @@ -1715,8 +1749,10 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct typec_altmode *adev, /* 6.4.4.3.3 */ svdm_consume_modes(port, p, cnt); modep->svid_index++; - if (modep->svid_index < modep->nsvids) { - u16 svid = modep->svids[modep->svid_index]; + if (modep->svid_index < modep->nsvids && + svdm_get_next_supported_svid(port, modep)) { + u16 svid = svdm_get_next_supported_svid(port, modep); + response[0] = VDO(svid, 1, svdm_version, CMD_DISCOVER_MODES); rlen = 1; } else { base-commit: d0d27ef87e1ca974ed93ed4f7d3c123cbd392ba6 -- 2.42.0.655.g421f12c284-goog

1 year, 5 months

2
3
0 0

[PATCH AUTOSEL 4.14 01/11] fbdev: atyfb: only use ioremap_uc() on i386 and ia64

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Helge Deller <deller(a)gmx.de> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/aty/atyfb_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index d4b938276d238..71e95533613cd 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3435,11 +3435,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0

1 year, 5 months

1
10
0 0

[PATCH AUTOSEL 4.19 01/12] fbdev: atyfb: only use ioremap_uc() on i386 and ia64

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Helge Deller <deller(a)gmx.de> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/aty/atyfb_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 05111e90f1681..5ef008e9c61c3 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3435,11 +3435,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0

1 year, 5 months

1
11
0 0

[PATCH AUTOSEL 5.4 01/13] fbdev: atyfb: only use ioremap_uc() on i386 and ia64

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Helge Deller <deller(a)gmx.de> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/aty/atyfb_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 6dda5d885a03b..bb9ecf12e7630 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3410,11 +3410,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0

1 year, 5 months

1
12
0 0

[PATCH AUTOSEL 5.10 01/16] fbdev: atyfb: only use ioremap_uc() on i386 and ia64

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Helge Deller <deller(a)gmx.de> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/aty/atyfb_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index c8feff0ee8da9..eb32ff0910d3e 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3440,11 +3440,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0

1 year, 5 months

1
15
0 0

[PATCH AUTOSEL 6.1 01/39] fbdev: atyfb: only use ioremap_uc() on i386 and ia64

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Helge Deller <deller(a)gmx.de> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/aty/atyfb_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index b3463d1371520..faaa64fa5dfe9 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3447,11 +3447,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0

1 year, 5 months

1
38
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023