Hi Fabrizio, On Tue, Dec 17, 2019 at 1:31 PM Fabrizio Castro <fabrizio.castro@xxxxxxxxxxxxxx> wrote: > > From: linux-renesas-soc-owner@xxxxxxxxxxxxxxx <linux-renesas-soc-owner@xxxxxxxxxxxxxxx> On Behalf Of Geert Uytterhoeven > > Sent: 17 December 2019 12:21 > > Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support > > > > On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro > > <fabrizio.castro@xxxxxxxxxxxxxx> wrote: > > > > From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > > Sent: 13 December 2019 17:11 > > > > Subject: Re: [PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support > > > > > > > > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds