Hello there Laurent, >Would you be able to send a patch to fix this ? Sadly, no. My success rate with kernel patches is low enough to make it not worth trying. Regards David Binderman From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> Sent: 09 March 2023 09:26 To: David Binderman <dcb314@xxxxxxxxxxx> Cc: andrzej.hajda@xxxxxxxxx <andrzej.hajda@xxxxxxxxx>; neil.armstrong@xxxxxxxxxx <neil.armstrong@xxxxxxxxxx>; rfoss@xxxxxxxxxx <rfoss@xxxxxxxxxx>; jonas@xxxxxxxxx <jonas@xxxxxxxxx>; jernej.skrabec@xxxxxxxxx <jernej.skrabec@xxxxxxxxx>; airlied@xxxxxxxxx <airlied@xxxxxxxxx>; daniel@xxxxxxxx <daniel@xxxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx> Subject: Re: drivers/gpu/drm/bridge/fsl-ldb.c:101: possible loss of information. Hi David, On Thu, Mar 09, 2023 at 07:59:34AM +0000, David Binderman wrote: > Hello there Laurent, > > >We could, but I don't think it will make any difference in practice as > >the maximum pixel clock frequency supported by the SoC is 80MHz (per > >LVDS channel). That would result in a 560MHz frequency returned by this > >function, well below the 31 bits limit. > > Thanks for your explanation. I have a couple of suggestions for possible improvements: > > 1. Your explanatory text in a comment nearby. This helps all readers of the code. > > 2. Might the frequency go up to 300 MHz anytime soon ? The code will stop working then. > In this case, I would suggest to put in a run time sanity check to make sure no 31 bit overflow. As it's a hardware limit of the SoC, I wouldn't expect so. This being said, I think adding a UL suffix to the constants would be better than a comment as it will please static checkers and serve as documentation to humans. Would you be able to send a patch to fix this ? > Just a couple of ideas for the code. Thanks for taking the time to share those. -- Regards, Laurent Pinchart
