[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4484c007-132c-ce47-fa71-87f33c87fe07@linux.dev>
Date: Mon, 17 Jul 2023 18:12:56 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Lucas Stach <l.stach@...gutronix.de>,
Russell King <linux+etnaviv@...linux.org.uk>,
Christian Gmeiner <christian.gmeiner@...il.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>
Cc: loongson-kernel@...ts.loongnix.cn,
Sui Jingfeng <suijingfeng@...ngson.cn>,
etnaviv@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/8] drm/etnaviv: Using the size_t variable to store
the number of pages
Hi
On 2023/7/17 17:43, Lucas Stach wrote:
> Hi Jingfeng,
>
> Am Freitag, dem 23.06.2023 um 18:08 +0800 schrieb Sui Jingfeng:
>> From: Sui Jingfeng <suijingfeng@...ngson.cn>
>>
>> Because the etnaviv_gem_new_private() function receives the size_t argument
>> for the number of pages. And the number of pages should be unsigned.
>>
>> Note that Most 32-bit architectures use "unsigned int" size_t,
>> and all 64-bit architectures use "unsigned long" size_t.
>> So, let's keep the argument and parameter consistent.
>>
> This explanation doesn't add up. npages is just that: a number of
> pages. Why would it make sense to use size_t here?
Because the 'size' variable in the etnaviv_gem_prime_import_sg_table()
function is declared
as size_t type. On 64-bit machine, size_t is actually is 64-bit wide and
it is *unsigned*.
While 'int' is actually 32-bit wide(at both 32-bit system and 64-bit
system) and it is *signed*,
So, my point (argument) is that
1) This patch help to avoid the unnecessary 64 bit to 32 bit conversion.
2) The kvmalloc_array() function also accept size_t type (see the
prototype of kvmalloc_array function include/linux/slab.h)
So my patch do helps to keep the code style consistent.
> If you want to be consistent I would have expected this change to
> switch things to unsigned int,
This may introduce a truncate operation (from a 64-bit to 32-bit), which
is necessary.
And when you pass the 'npages' parameter to kvmalloc_array() function,
The compiler probably has to do the integer promotion (from a 32-bit to
64-bit) for you.
> as you did in the second patch of this
> series.
>
> Regards,
> Lucas
>
>> Signed-off-by: Sui Jingfeng <suijingfeng@...ngson.cn>
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> index 3524b5811682..b003481adc2b 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> @@ -114,7 +114,8 @@ struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device *dev,
>> {
>> struct etnaviv_gem_object *etnaviv_obj;
>> size_t size = PAGE_ALIGN(attach->dmabuf->size);
>> - int ret, npages;
>> + size_t npages = size / PAGE_SIZE;
>> + int ret;
>>
>> ret = etnaviv_gem_new_private(dev, size, ETNA_BO_WC,
>> &etnaviv_gem_prime_ops, &etnaviv_obj);
>> @@ -123,8 +124,6 @@ struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device *dev,
>>
>> lockdep_set_class(&etnaviv_obj->lock, &etnaviv_prime_lock_class);
>>
>> - npages = size / PAGE_SIZE;
>> -
>> etnaviv_obj->sgt = sgt;
>> etnaviv_obj->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
>> if (!etnaviv_obj->pages) {
Powered by blists - more mailing lists