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 21:33:55 +0800 [thread overview]
Message-ID: <b224d17b-4889-a913-8856-bad1f4262f9c@linux.dev> (raw)
In-Reply-To: <8b0d82d48ff24f578e7a1c7433e56ddaadc3188b.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
Hi,
On 2023/7/17 18:38, Lucas Stach wrote:
> Am Montag, dem 17.07.2023 um 18:12 +0800 schrieb Sui Jingfeng:
>> 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.
>>
> But then we go on to call drm_prime_sq_to_page_array(), which takes a
> integer as the number of pages parameter, so the parameter types are
> inconsistent before and after your patch, it just switches which
> function call has to do some conversion.
>
But the drm_prime_sg_to_page_array() function is going to be depreciated,
We probably could modified it also to unified it, that is to take size_t
arguments.
[-- Attachment #2: Type: text/html, Size: 2953 bytes --]
next prev parent reply other threads:[~2023-07-17 13:34 UTC|newest]
Thread overview: 25+ 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
2023-07-17 10:38 ` Lucas Stach
2023-07-17 13:33 ` Sui Jingfeng [this message]
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=b224d17b-4889-a913-8856-bad1f4262f9c@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