Displaying 20 results from an estimated 200 matches similar to: "[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init"
2020 Jan 03
0
[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init
(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
2019 Dec 21
0
[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init
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
---
2019 Dec 20
0
[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init
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
---
2020 Mar 19
2
[PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM
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
2020 Mar 30
1
[PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM
[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
>
2020 Apr 11
0
[PATCH AUTOSEL 5.5 121/121] 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,
2020 Apr 11
0
[PATCH AUTOSEL 5.6 149/149] 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,
2020 Apr 11
0
[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,
2020 Apr 11
0
[PATCH AUTOSEL 4.19 66/66] 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,
2020 Mar 28
0
[PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM
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
2020 Mar 05
2
[PATCH v2 0/2] Fix loading of platform ROM from 32-bit EFI
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 +
2020 Mar 13
3
[PATCH RESEND v2 0/2] Fix loading of platform ROM from 32-bit EFI
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
2020 Mar 13
0
[PATCH RESEND v2 2/2] PCI: Use ioremap(), not phys_to_virt() for platform ROM
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
2020 Mar 17
2
[PATCH RESEND v2 2/2] PCI: Use ioremap(), not phys_to_virt() for platform ROM
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
2020 Jul 15
0
[PATCH] drm/nouveau: add the missed kfree() for nouveau_bo_alloc()
> ? to fix it.
I suggest to replace this wording by the tag ?Fixes?.
?
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,
> break;
> }
>
> - if (WARN_ON(pi < 0))
> + if (WARN_ON(pi < 0)) {
> + kfree(nvbo);
> return ERR_PTR(-EINVAL);
> + }
I propose to
2020 Jul 15
0
[PATCH] drm/nouveau: add the missed kfree() for nouveau_bo_alloc()
nouveau_bo_alloc() misses to call kfree() in an error path. Add the
missed function call to fix it.
Signed-off-by: Jing Xiangfeng <jingxiangfeng at huawei.com>
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c40f127de3d0..abd80b1a6de3 100644
---
2017 Dec 11
0
[PATCH 1/3] virtio_pci: use put_device instead of kfree
don't free vp_dev until vp_dev->vdev.dev.release be called.
Signed-off-by: weiping zhang <zhangweiping at didichuxing.com>
---
drivers/virtio/virtio_pci_common.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 1c4797e..91d20f7 100644
---
2017 Dec 11
0
[PATCH 2/3] virtio: use put_device instead of kfree
don't free vp_vdev until vp_vdev.dev.release be called.
Signed-off-by: weiping zhang <zhangweiping at didichuxing.com>
---
drivers/misc/mic/vop/vop_main.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/mic/vop/vop_main.c b/drivers/misc/mic/vop/vop_main.c
index a341938..8c716a0 100644
--- a/drivers/misc/mic/vop/vop_main.c
+++
2017 Dec 12
1
[PATCH 1/3] virtio_pci: use put_device instead of kfree
On Mon, 11 Dec 2017 23:55:16 +0800
weiping zhang <zhangweiping at didichuxing.com> wrote:
> don't free vp_dev until vp_dev->vdev.dev.release be called.
Maybe add the same description as in your virtio_mmio patch so that it
is clear why the kfree() is not ok?
>
> Signed-off-by: weiping zhang <zhangweiping at didichuxing.com>
> ---
>
2017 Dec 12
0
[PATCH v2 2/3] virtio: use put_device instead of kfree
As mentioned at drivers/base/core.c:
/*
* NOTE: _Never_ directly free @dev after calling this function, even
* if it returned an error! Always use put_device() to give up the
* reference initialized in this function instead.
*/
so we don't free vp_vdev until vp_vdev.dev.release be called.
Signed-off-by: weiping zhang <zhangweiping at didichuxing.com>
---