linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] radeon: Do not directly dereference pointers to BIOS area.
@ 2015-03-19  3:18 David Miller
  2015-03-19  8:50 ` Christian König
  0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2015-03-19  3:18 UTC (permalink / raw)
  To: alexander.deucher; +Cc: christian.koenig, dri-devel, linux-kernel


Use readb() and memcpy_fromio() accessors instead.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
index 63ccb8f..d27e4cc 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -76,7 +76,7 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
 
 static bool radeon_read_bios(struct radeon_device *rdev)
 {
-	uint8_t __iomem *bios;
+	uint8_t __iomem *bios, val1, val2;
 	size_t size;
 
 	rdev->bios = NULL;
@@ -86,15 +86,19 @@ static bool radeon_read_bios(struct radeon_device *rdev)
 		return false;
 	}
 
-	if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+	val1 = readb(&bios[0]);
+	val2 = readb(&bios[1]);
+
+	if (size == 0 || val1 != 0x55 || val2 != 0xaa) {
 		pci_unmap_rom(rdev->pdev, bios);
 		return false;
 	}
-	rdev->bios = kmemdup(bios, size, GFP_KERNEL);
+	rdev->bios = kzalloc(size, GFP_KERNEL);
 	if (rdev->bios == NULL) {
 		pci_unmap_rom(rdev->pdev, bios);
 		return false;
 	}
+	memcpy_fromio(rdev->bios, bios, size);
 	pci_unmap_rom(rdev->pdev, bios);
 	return true;
 }

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-19  3:18 [PATCH] radeon: Do not directly dereference pointers to BIOS area David Miller
@ 2015-03-19  8:50 ` Christian König
  2015-03-19 16:29   ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Christian König @ 2015-03-19  8:50 UTC (permalink / raw)
  To: David Miller, alexander.deucher; +Cc: dri-devel, linux-kernel

In general I would say yes, but for this particular hardware it's a bit 
questionable to do so.

For radeon hardware to work correctly the CPU access to the PCIE BARs 
should work even without using the specialized IO macros/functions, 
otherwise mapping VRAM CPU accessible isn't really possible.

What's the background of the change? Some problems on a certain CPU 
platform? or just general cleanups?

Regards,
Christian.

On 19.03.2015 04:18, David Miller wrote:
> Use readb() and memcpy_fromio() accessors instead.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> index 63ccb8f..d27e4cc 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -76,7 +76,7 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>   
>   static bool radeon_read_bios(struct radeon_device *rdev)
>   {
> -	uint8_t __iomem *bios;
> +	uint8_t __iomem *bios, val1, val2;
>   	size_t size;
>   
>   	rdev->bios = NULL;
> @@ -86,15 +86,19 @@ static bool radeon_read_bios(struct radeon_device *rdev)
>   		return false;
>   	}
>   
> -	if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
> +	val1 = readb(&bios[0]);
> +	val2 = readb(&bios[1]);
> +
> +	if (size == 0 || val1 != 0x55 || val2 != 0xaa) {
>   		pci_unmap_rom(rdev->pdev, bios);
>   		return false;
>   	}
> -	rdev->bios = kmemdup(bios, size, GFP_KERNEL);
> +	rdev->bios = kzalloc(size, GFP_KERNEL);
>   	if (rdev->bios == NULL) {
>   		pci_unmap_rom(rdev->pdev, bios);
>   		return false;
>   	}
> +	memcpy_fromio(rdev->bios, bios, size);
>   	pci_unmap_rom(rdev->pdev, bios);
>   	return true;
>   }


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-19  8:50 ` Christian König
@ 2015-03-19 16:29   ` David Miller
  2015-03-20  9:38     ` Christian König
  0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2015-03-19 16:29 UTC (permalink / raw)
  To: christian.koenig; +Cc: alexander.deucher, dri-devel, linux-kernel

From: Christian König <christian.koenig@amd.com>
Date: Thu, 19 Mar 2015 09:50:58 +0100

> In general I would say yes, but for this particular hardware it's a
> bit questionable to do so.
> 
> For radeon hardware to work correctly the CPU access to the PCIE BARs
> should work even without using the specialized IO macros/functions,
> otherwise mapping VRAM CPU accessible isn't really possible.
> 
> What's the background of the change? Some problems on a certain CPU
> platform? or just general cleanups?

It's an _iomem_ pointer, it's not a virtual address.

Therefore it is illegal to dereference the pointer.

The value is opaque and has values that only make sense when used
with the readb() et al. interfaces.

This code is relying upon the fact that on x86 it happens to be
a virtual address, but this won't work on many other architectures.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-19 16:29   ` David Miller
@ 2015-03-20  9:38     ` Christian König
  2015-03-20 13:50       ` Alex Deucher
  2015-03-20 17:24       ` David Miller
  0 siblings, 2 replies; 7+ messages in thread
From: Christian König @ 2015-03-20  9:38 UTC (permalink / raw)
  To: David Miller; +Cc: alexander.deucher, dri-devel, linux-kernel

On 19.03.2015 17:29, David Miller wrote:
> From: Christian König <christian.koenig@amd.com>
> Date: Thu, 19 Mar 2015 09:50:58 +0100
>
>> In general I would say yes, but for this particular hardware it's a
>> bit questionable to do so.
>>
>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>> should work even without using the specialized IO macros/functions,
>> otherwise mapping VRAM CPU accessible isn't really possible.
>>
>> What's the background of the change? Some problems on a certain CPU
>> platform? or just general cleanups?
> It's an _iomem_ pointer, it's not a virtual address.
>
> Therefore it is illegal to dereference the pointer.
>
> The value is opaque and has values that only make sense when used
> with the readb() et al. interfaces.
>
> This code is relying upon the fact that on x86 it happens to be
> a virtual address, but this won't work on many other architectures.

In this case I'm perfectly fine with it and the patch is Reviewed-by: 
Christian König <christian.koenig@amd.com>

Just wanted to make sure that you're not trying to get Radeon working on 
a platform which will never really support the necessary hardware features.

Regards,
Christian.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-20  9:38     ` Christian König
@ 2015-03-20 13:50       ` Alex Deucher
  2015-03-20 17:24       ` David Miller
  1 sibling, 0 replies; 7+ messages in thread
From: Alex Deucher @ 2015-03-20 13:50 UTC (permalink / raw)
  To: Christian König
  Cc: David Miller, Deucher, Alexander, LKML, Maling list - DRI developers

On Fri, Mar 20, 2015 at 5:38 AM, Christian König
<christian.koenig@amd.com> wrote:
> On 19.03.2015 17:29, David Miller wrote:
>>
>> From: Christian König <christian.koenig@amd.com>
>> Date: Thu, 19 Mar 2015 09:50:58 +0100
>>
>>> In general I would say yes, but for this particular hardware it's a
>>> bit questionable to do so.
>>>
>>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>>> should work even without using the specialized IO macros/functions,
>>> otherwise mapping VRAM CPU accessible isn't really possible.
>>>
>>> What's the background of the change? Some problems on a certain CPU
>>> platform? or just general cleanups?
>>
>> It's an _iomem_ pointer, it's not a virtual address.
>>
>> Therefore it is illegal to dereference the pointer.
>>
>> The value is opaque and has values that only make sense when used
>> with the readb() et al. interfaces.
>>
>> This code is relying upon the fact that on x86 it happens to be
>> a virtual address, but this won't work on many other architectures.
>
>
> In this case I'm perfectly fine with it and the patch is Reviewed-by:
> Christian König <christian.koenig@amd.com>
>
> Just wanted to make sure that you're not trying to get Radeon working on a
> platform which will never really support the necessary hardware features.
>

Applied to my tree.  Thanks!

Alex

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-20  9:38     ` Christian König
  2015-03-20 13:50       ` Alex Deucher
@ 2015-03-20 17:24       ` David Miller
  2015-03-20 17:39         ` Deucher, Alexander
  1 sibling, 1 reply; 7+ messages in thread
From: David Miller @ 2015-03-20 17:24 UTC (permalink / raw)
  To: christian.koenig; +Cc: alexander.deucher, dri-devel, linux-kernel

From: Christian König <christian.koenig@amd.com>
Date: Fri, 20 Mar 2015 10:38:32 +0100

> On 19.03.2015 17:29, David Miller wrote:
>> From: Christian König <christian.koenig@amd.com>
>> Date: Thu, 19 Mar 2015 09:50:58 +0100
>>
>>> In general I would say yes, but for this particular hardware it's a
>>> bit questionable to do so.
>>>
>>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>>> should work even without using the specialized IO macros/functions,
>>> otherwise mapping VRAM CPU accessible isn't really possible.
>>>
>>> What's the background of the change? Some problems on a certain CPU
>>> platform? or just general cleanups?
>> It's an _iomem_ pointer, it's not a virtual address.
>>
>> Therefore it is illegal to dereference the pointer.
>>
>> The value is opaque and has values that only make sense when used
>> with the readb() et al. interfaces.
>>
>> This code is relying upon the fact that on x86 it happens to be
>> a virtual address, but this won't work on many other architectures.
> 
> In this case I'm perfectly fine with it and the patch is Reviewed-by:
> Christian König <christian.koenig@amd.com>
> 
> Just wanted to make sure that you're not trying to get Radeon working
> on a platform which will never really support the necessary hardware
> features.

I would like this to get merged via the Radeon DRM maintainer, thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
  2015-03-20 17:24       ` David Miller
@ 2015-03-20 17:39         ` Deucher, Alexander
  0 siblings, 0 replies; 7+ messages in thread
From: Deucher, Alexander @ 2015-03-20 17:39 UTC (permalink / raw)
  To: David Miller, Koenig, Christian; +Cc: dri-devel, linux-kernel

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, March 20, 2015 1:24 PM
> To: Koenig, Christian
> Cc: Deucher, Alexander; dri-devel@lists.freedesktop.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] radeon: Do not directly dereference pointers to BIOS
> area.
> 
> From: Christian König <christian.koenig@amd.com>
> Date: Fri, 20 Mar 2015 10:38:32 +0100
> 
> > On 19.03.2015 17:29, David Miller wrote:
> >> From: Christian König <christian.koenig@amd.com>
> >> Date: Thu, 19 Mar 2015 09:50:58 +0100
> >>
> >>> In general I would say yes, but for this particular hardware it's a
> >>> bit questionable to do so.
> >>>
> >>> For radeon hardware to work correctly the CPU access to the PCIE BARs
> >>> should work even without using the specialized IO macros/functions,
> >>> otherwise mapping VRAM CPU accessible isn't really possible.
> >>>
> >>> What's the background of the change? Some problems on a certain CPU
> >>> platform? or just general cleanups?
> >> It's an _iomem_ pointer, it's not a virtual address.
> >>
> >> Therefore it is illegal to dereference the pointer.
> >>
> >> The value is opaque and has values that only make sense when used
> >> with the readb() et al. interfaces.
> >>
> >> This code is relying upon the fact that on x86 it happens to be
> >> a virtual address, but this won't work on many other architectures.
> >
> > In this case I'm perfectly fine with it and the patch is Reviewed-by:
> > Christian König <christian.koenig@amd.com>
> >
> > Just wanted to make sure that you're not trying to get Radeon working
> > on a platform which will never really support the necessary hardware
> > features.
> 
> I would like this to get merged via the Radeon DRM maintainer, thanks.

Already added to my tree.  Thanks!

Alex

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-03-20 17:39 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-19  3:18 [PATCH] radeon: Do not directly dereference pointers to BIOS area David Miller
2015-03-19  8:50 ` Christian König
2015-03-19 16:29   ` David Miller
2015-03-20  9:38     ` Christian König
2015-03-20 13:50       ` Alex Deucher
2015-03-20 17:24       ` David Miller
2015-03-20 17:39         ` Deucher, Alexander

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).