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.pinch...@ideasonboard.com> Sent: 09 March 2023 09:26 To: David Binderman <dcb...@hotmail.com> Cc: andrzej.ha...@intel.com <andrzej.ha...@intel.com>; neil.armstr...@linaro.org <neil.armstr...@linaro.org>; rf...@kernel.org <rf...@kernel.org>; jo...@kwiboo.se <jo...@kwiboo.se>; jernej.skra...@gmail.com <jernej.skra...@gmail.com>; airl...@gmail.com <airl...@gmail.com>; dan...@ffwll.ch <dan...@ffwll.ch>; dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>; linux-ker...@vger.kernel.org <linux-ker...@vger.kernel.org> 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
