__fls() on sparc64 return "int", but here it is expected as "unsigned
long" (x86). It will cause the build errors because the warning becomes
fatal while it is using sparc configuration. As suggested by Linus, it
can use min_t instead of min to force the type as "unsigned int".
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Huang Rui <[email protected]>
Cc: Christian König <[email protected]>
---
drivers/gpu/drm/ttm/ttm_pool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index af1b41369626..c961a788b519 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -382,7 +382,8 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
else
gfp_flags |= GFP_HIGHUSER;
- for (order = min(MAX_ORDER - 1UL, __fls(num_pages)); num_pages;
+ for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
+ num_pages;
order = min_t(unsigned int, order, __fls(num_pages))) {
bool apply_caching = false;
struct ttm_pool_type *pt;
--
2.25.1
Am 07.09.21 um 12:03 schrieb Huang Rui:
> __fls() on sparc64 return "int", but here it is expected as "unsigned
> long" (x86). It will cause the build errors because the warning becomes
> fatal while it is using sparc configuration. As suggested by Linus, it
> can use min_t instead of min to force the type as "unsigned int".
>
> Suggested-by: Linus Torvalds <[email protected]>
> Signed-off-by: Huang Rui <[email protected]>
> Cc: Christian König <[email protected]>
Reviewed-by: Christian König <[email protected]>
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index af1b41369626..c961a788b519 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -382,7 +382,8 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> else
> gfp_flags |= GFP_HIGHUSER;
>
> - for (order = min(MAX_ORDER - 1UL, __fls(num_pages)); num_pages;
> + for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> + num_pages;
> order = min_t(unsigned int, order, __fls(num_pages))) {
> bool apply_caching = false;
> struct ttm_pool_type *pt;
On Tue, Sep 7, 2021 at 6:25 AM Christian König <[email protected]> wrote:
>
> Am 07.09.21 um 12:03 schrieb Huang Rui:
> > __fls() on sparc64 return "int", but here it is expected as "unsigned
> > long" (x86). It will cause the build errors because the warning becomes
> > fatal while it is using sparc configuration. As suggested by Linus, it
> > can use min_t instead of min to force the type as "unsigned int".
> >
> > Suggested-by: Linus Torvalds <[email protected]>
> > Signed-off-by: Huang Rui <[email protected]>
> > Cc: Christian König <[email protected]>
>
> Reviewed-by: Christian König <[email protected]>
Is one of you going to push this to drm-misc?
Alex
>
> > ---
> > drivers/gpu/drm/ttm/ttm_pool.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index af1b41369626..c961a788b519 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -382,7 +382,8 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> > else
> > gfp_flags |= GFP_HIGHUSER;
> >
> > - for (order = min(MAX_ORDER - 1UL, __fls(num_pages)); num_pages;
> > + for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > + num_pages;
> > order = min_t(unsigned int, order, __fls(num_pages))) {
> > bool apply_caching = false;
> > struct ttm_pool_type *pt;
>
On Tue, Sep 14, 2021 at 12:48 PM Alex Deucher <[email protected]> wrote:
>
> On Tue, Sep 7, 2021 at 6:25 AM Christian König <[email protected]> wrote:
> >
> >
> > Reviewed-by: Christian König <[email protected]>
>
> Is one of you going to push this to drm-misc?
I was assuming it was there already.
I guess I'll just apply it directly.
Linus
Am 14.09.21 um 22:03 schrieb Linus Torvalds:
> On Tue, Sep 14, 2021 at 12:48 PM Alex Deucher <[email protected]> wrote:
>> On Tue, Sep 7, 2021 at 6:25 AM Christian König <[email protected]> wrote:
>>>
>>> Reviewed-by: Christian König <[email protected]>
>> Is one of you going to push this to drm-misc?
> I was assuming it was there already.
>
> I guess I'll just apply it directly.
I had it already prepared and just forgot to push it.
Just did so a few minutes ago before reading this mail.
Sorry for the noise,
Christian.
>
> Linus