public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Lucas Stach <l.stach@pengutronix.de>,
	Russell King <linux+etnaviv@armlinux.org.uk>,
	Christian Gmeiner <christian.gmeiner@gmail.com>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: loongson-kernel@lists.loongnix.cn,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/8] drm/etnaviv: Using the size_t variable to store the number of pages
Date: Mon, 17 Jul 2023 18:12:56 +0800	[thread overview]
Message-ID: <4484c007-132c-ce47-fa71-87f33c87fe07@linux.dev> (raw)
In-Reply-To: <4f80b175f94eaf386354d1f3425208ca6cf20482.camel@pengutronix.de>

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@loongson.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@loongson.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) {

  reply	other threads:[~2023-07-17 10:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 10:08 [PATCH v1 0/8] drm/etnaviv: Various cleanup Sui Jingfeng
2023-06-23 10:08 ` [PATCH v1 1/8] drm/etnaviv: Using the size_t variable to store the number of pages Sui Jingfeng
2023-07-17  9:43   ` Lucas Stach
2023-07-17 10:12     ` Sui Jingfeng [this message]
2023-07-17 10:38       ` Lucas Stach
2023-06-23 10:08 ` [PATCH v1 2/8] drm/etnaviv: Using the unsigned int type to count " Sui Jingfeng
2023-06-23 10:08 ` [PATCH v1 3/8] drm/etnaviv: Drop the second argument of the etnaviv_gem_new_impl() Sui Jingfeng
2023-07-17  9:51   ` Lucas Stach
2023-07-17 18:34     ` suijingfeng
2023-07-18  8:12       ` Lucas Stach
2023-07-18 16:16         ` suijingfeng
2023-07-18 16:24           ` Sui Jingfeng
2023-07-19  8:16           ` Lucas Stach
2023-06-23 10:08 ` [PATCH v1 4/8] drm/etnaviv: Remove surplus else after return Sui Jingfeng
2023-07-17  9:58   ` Lucas Stach
2023-06-23 10:08 ` [PATCH v1 5/8] drm/etnaviv: Keep the curly brace aligned Sui Jingfeng
2023-06-23 10:08 ` [PATCH v1 6/8] drm/etnaviv: No indentation by double tabs Sui Jingfeng
2023-06-23 10:08 ` [PATCH v1 7/8] drm/etnaviv: Add dedicated functions to create and destroy platform device Sui Jingfeng
2023-06-23 10:08 ` [PATCH v1 8/8] drm/etnaviv: Add a helper to get a pointer to the first available node Sui Jingfeng
2023-07-17 10:07   ` Lucas Stach
2023-07-17 10:20     ` suijingfeng
2023-07-17 10:36     ` Sui Jingfeng
2023-07-17  8:36 ` [PATCH v1 0/8] drm/etnaviv: Various cleanup suijingfeng
2023-07-17 10:09   ` Lucas Stach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4484c007-132c-ce47-fa71-87f33c87fe07@linux.dev \
    --to=sui.jingfeng@linux.dev \
    --cc=airlied@gmail.com \
    --cc=christian.gmeiner@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongson-kernel@lists.loongnix.cn \
    --cc=suijingfeng@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox