On Tue, Dec 17, 2019 at 10:06:14PM +0000, Fabrizio Castro wrote:
> On 17 December 2019 13:54, Laurent Pinchart wrote:
> > On Tue, Dec 17, 2019 at 01:38:51PM +0100, Geert Uytterhoeven wrote:
> >> On Tue, Dec 17, 2019 at 1:31 PM Fabrizio Castro wrote:
> >>> On 17 December 2019 12:21, Geert Uytterhoeven wrote:
> >>>> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro wrote:
> >>>>> On 13 December 2019 17:11, Laurent Pinchart wrote:
> >>>>>> On Wed, Nov 13, 2019 at 03:51:25PM +0000, Fabrizio Castro wrote:
> >>>>>>> Add support for transparent LVDS decoders by adding a new
> >>>>>>> compatible string ("lvds-decoder") to the driver.
> >>>>>>> This patch also adds member connector_type to struct lvds_codec,
> >>>>>>> and that's because LVDS decoders have a different connector type
> >>>>>>> from LVDS encoders. We fill this new member up with the data
> >>>>>>> matching the compatible string.
> >>>>>>>
> >>>>>>> Signed-off-by: Fabrizio Castro <fabrizio.castro@xxxxxxxxxxxxxx>
> >>>>>>>
> >>>>>>> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> >>>>>>> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> >>>>>>>
> >>>>>>> @@ -65,6 +67,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> >>>>>>> if (!lvds_codec)
> >>>>>>> return -ENOMEM;
> >>>>>>>
> >>>>>>> + lvds_codec->connector_type = (u32)of_device_get_match_data(&pdev->dev);
> >>>>>>
> >>>>>> I'm now getting a compilation failure here:
> >>>>>>
> >>>>>> drivers/gpu/drm/bridge/lvds-codec.c: In function ‘lvds_codec_probe’:
> >>>>>> drivers/gpu/drm/bridge/lvds-codec.c:68:31: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> >>>>>> lvds_codec->connector_type = (u32)of_device_get_match_data(&pdev->dev);
> >>>>>> ^
> >>>>>>
> >>>>>> The fix should be simple:
> >>>>>>
> >>>>>> lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
> >>>>>>
> >>>>>> I'm bothered by the fact that I've compiled this before without any
> >>>>>> issue, so this really puzzles me. Do you get the same warning ?
> >>>>>
> >>>>> The warning appears when compiling for arm64, understandably so.
> >>>>> We must have compiled this for arm only the first time around.
> >>>>>
> >>>>> I think the right way to solve this is to either cast to (u32)(uintptr_t) or (u32)(unsigned long).
> >>>>
> >>>> Just casting to uintptr_t should be sufficient.
> >>>
> >>> It should be sufficient for the compiler, but I have seen examples where people
> >>> preferred to be explicit, like in:
> >>> drivers/mailbox/mtk-cmdq-mailbox.c
> >>> drivers/leds/leds-pm8058.c
> >>>
> >>> Since the kernel is increasing its tightness with respect to warnings, I personally prefer
> >>> (u32)(uintptr_t), even though not strictly necessary, but I am fine with (uintptr_t) if you
> >>> don't like (u32)(uintptr_t).
> >>
> >> It depends. I try to have as few casts as possible ("casts are evil").
> >>
> >> While adding the extra (u32) cast makes it clearer that the intended
> >> result is a u32 (for now), it will cause silent truncation on 64-bit if
> >> connector_type is ever enlarged to unsigned long, and larger values are
> >> used.
> >>
> >> In this particular case this is unlikely, though, as unsigned long would
> >> still be 32-bit on 32-bit platforms, so the larger values cannot be
> >> used.
> >
> > I also try to add as few casts as possible, so (uintptr_t) would be my
> > preference.
> >
> > Fabrizio, could you submit a new version of this patch with the problem
> > fixed (and with the casts you decide to use, but using uintptr_t instead
> > of unsigned long in any case) ?
>
> Will send a new version tomorrow with (uintptr_t)
Done as v4.1 :-)
--
Regards,
Laurent Pinchart
