[PATCH v4 06/13] drm/bridge: lvds-codec: Add "lvds-decoder" support

[Fabrizio Castro]

Hi Geert,

Thank you for your feedback!

> From: linux-renesas-soc-owner at vger.kernel.org <linux-renesas-soc-owner at vger.kernel.org> 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
> 
> Hi Fabrizio,
> 
> On Tue, Dec 17, 2019 at 12:03 PM Fabrizio Castro
> <fabrizio.castro at bp.renesas.com> wrote:
> > > From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > > 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 at bp.renesas.com>
> > > >
> > > > ---
> > > > v3->v4:
> > > > * New patch
> > > > ---
> > > >  drivers/gpu/drm/bridge/lvds-codec.c | 19 ++++++++++++++++---
> > > >  1 file changed, 16 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > index b5801a2..c32e125 100644
> > > > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > @@ -7,6 +7,7 @@
> > > >  #include <linux/gpio/consumer.h>
> > > >  #include <linux/module.h>
> > > >  #include <linux/of.h>
> > > > +#include <linux/of_device.h>
> > > >  #include <linux/of_graph.h>
> > > >  #include <linux/platform_device.h>
> > > >
> > > > @@ -17,6 +18,7 @@ struct lvds_codec {
> > > >     struct drm_bridge bridge;
> > > >     struct drm_bridge *panel_bridge;
> > > >     struct gpio_desc *powerdown_gpio;
> > > > +   u32 connector_type;
> > > >  };
> > > >
> > > >  static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > @@ -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).

Cheers,
Fab

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> 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