similar to: [PATCH AUTOSEL 5.4 108/108] PCI: Use ioremap(), not phys_to_virt() for platform ROM

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > On some EFI systems, the video BIOS is provided by the EFI firmware. The > boot stub code stores the physical address of the ROM image in pdev->rom. > Currently we attempt to access this pointer using phys_to_virt(), which > doesn't work with CONFIG_HIGHMEM. > > On these systems, attempting to load the

[AMD Public Use] > -----Original Message----- > From: Bjorn Helgaas <helgaas at kernel.org> > Sent: Saturday, March 28, 2020 4:19 PM > To: Mikel Rychliski <mikel at mikelr.com> > Cc: amd-gfx at lists.freedesktop.org; linux-pci at vger.kernel.org; > nouveau at lists.freedesktop.org; Deucher, Alexander > <Alexander.Deucher at amd.com>; Koenig, Christian >

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page

This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Changes in v2: - Add iounmap() call in nouveau - Update function comment for pci_platform_rom() - Minor changes to commit messages Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use

Hi Christoph, Thanks for your comments. I'm also replying here to your comments on the previous series. On Tuesday, March 17, 2020 10:28:35 AM EDT Christoph Hellwig wrote: > Any reason drivers can't just use pci_map_rom instead? which already > does the right thing? Some machines don't expose the video BIOS in the PCI BAR and instead only make it available via EFI boot

This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use ioremap(), not phys_to_virt() for platform ROM drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 +

On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote: > /** > + * pci_platform_rom - ioremap() the ROM image provided by the platform > * @pdev: pointer to pci device struct > * @size: pointer to receive size of pci window over ROM > + * > + * Return: kernel virtual pointer to image of ROM > + * > + * The caller is responsible for removing the mapping with

pci_platform_rom() returns an __iomem pointer which should not be accessed directly. Change radeon_read_platform_bios() to use memcpy_fromio() instead of calling kmemdup() on the __iomem pointer. Signed-off-by: Mikel Rychliski <mikel at mikelr.com> --- drivers/gpu/drm/radeon/radeon_bios.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the need. For example, if an application want to process all PCI(e) display devices in a

Hi, I think there has a incorrect kfree in pcirom_init function. In pcirom_init function priv porinter could be free only when priv != null and priv->rom is null. Signed-off-by: wuxu.wu <wuxu.wu at huawei.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c

From: Sui Jingfeng <suijingfeng at loongson.cn> Should be no functional change. Cc: Alex Deucher <alexander.deucher at amd.com> Signed-off-by: Sui Jingfeng <suijingfeng at loongson.cn> --- drivers/gpu/drm/radeon/radeon_bios.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_bios.c

priv porinter could be free only when priv != null and priv->rom is null. --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c index 9b91da0..d776e01 100644 ---

priv porinter could be free only when priv != null and priv->rom is null. Signed-off-by: wuxu.wu <wuxu.wu at huawei.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c index 9b91da0..d776e01 100644 ---

(re-sending as plain text) NACK. The before and after of this patch are functionally identical. The if-block returns unconditionally ("return priv;"), so the kfree will only ever be reached if the condition in the if-statement evaluates to false. Explicitly writing out an else-block is thus superfluous. Op 03-01-2020 om 09:10 schreef wuxu.wu: > Hi, I think there has a incorrect

Currently, every single piece of code in amdgpu that loops through connectors does it incorrectly and doesn't use the proper list iteration helpers, drm_connector_list_iter_begin() and drm_connector_list_iter_end(). Yeesh. So, do that. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Currently, every single piece of code in amdgpu that loops through > connectors does it incorrectly and doesn't use the proper list iteration > helpers, drm_connector_list_iter_begin() and > drm_connector_list_iter_end(). Yeesh. > > So, do that. In fairness, I think the origin of this code