On Thu, Sep 12, 2024 at 07:06:45AM +0200, Greg KH wrote: > On Thu, Sep 12, 2024 at 06:15:18AM +0530, Abhishek Tamboli wrote: > > Hi Alan, > > On Thu, Aug 01, 2024 at 10:51:35AM -0400, Alan Stern wrote: > > > On Thu, Aug 01, 2024 at 08:54:18AM +0200, 'Oliver Neukum' via USB Mass Storage on Linux wrote: > > > > > > > > > > > > On 31.07.24 20:19, Alan Stern wrote: > > > > > On Wed, Jul 31, 2024 at 11:34:45PM +0530, Abhishek Tamboli wrote: > > > > > > On Wed, Jul 31, 2024 at 10:04:33AM -0400, Alan Stern wrote: > > > > > > > > Hi, > > > > > > > > I should make my reasoning clearer. > > > > > > > > > > > Replacing the variable with a constant won't make much difference. The > > > > > > > compiler will realize that bl_len has a constant value and will generate > > > > > > > appropriate code anyway. I think just changing the type is a fine fix. > > > > > > > > While that is absolutely true, it kind of removes the reason for the patch > > > > in the first place. The code gcc generates is unlikely to be changed. > > > > > > > > We are reacting to a warning an automatic tool generates. That is a good thing. > > > > We should have clean code. The question is how we react to such a report. > > > > It just seems to me that if we fix such a warning, the code should really be clean > > > > after that. Just doing the minimum that will make the checker shut up is > > > > no good. > > > > > > With this fix, the code seems clean to me. It may not be as short as > > > possible, but it's clean. > > > > I noticed that the patch has not yet been pulled into linux-next, > > even though it has been acked-by you for over a month. Is there > > anything else I need to do on my end? > > Yes, please resend it, it is long gone from my review queue, sorry. No problem, I will resend it. Thanks, Abhishek
