[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d7870b0-6b63-430b-8885-2509b33dc78a@suse.com>
Date: Wed, 31 Jul 2024 11:15:28 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Abhishek Tamboli <abhishektamboli9@...il.com>,
Oliver Neukum <oneukum@...e.com>
Cc: stern@...land.harvard.edu, gregkh@...uxfoundation.org,
usb-storage@...ts.one-eyed-alien.net, linux-usb@...r.kernel.org,
skhan@...uxfoundation.org, dan.carpenter@...aro.org, rbmarliere@...il.com,
linux-kernel-mentees@...ts.linuxfoundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: storage: ene_ub6250: Fix right shift warnings
Hi,
On 30.07.24 19:56, Abhishek Tamboli wrote:
> On Tue, Jul 30, 2024 at 09:09:05AM +0200, Oliver Neukum wrote:
>> 1. use a constant, where a constant is used
> I think you are suggesting that I should replace hard-coded values like the
> buffer size with named constants. For example:
>
> #define BUF_SIZE 8
> unsigned char buf[BUF_SIZE];
Yes, but the constant we need to look at here is bl_len.
This is a variable needlessly.
>> 2. use the macros for converting endianness
> Can I use macros like cpu_to_le32 for converting the bl_num and bl_len values.
> Should I replace all instances of manual bitwise shifts with these macros?
Yes.
> For example:
>
> u32 bl_len = 0x200;
> buf[0] = cpu_to_le32(bl_num) >> 24;
> buf[4] = cpu_to_le32(bl_len) >> 24;
>
> Is using cpu_to_le32 appropriate for the data format required by this
> device?
Well, the format is big endian. So, cpu_to_be32() will be required.
Regards
Oliver
Powered by blists - more mailing lists