linux-kernel - Re: [PATCH v6 2/3] drm: Add support for the LogiCVC display controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACvgo52dMPk_KPyNYhBTDOo_+s7hJuGDNjoWun63Jj4uMidszA@mail.gmail.com>
Date:   Fri, 8 May 2020 11:32:46 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     ML dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        David Airlie <airlied@...ux.ie>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH v6 2/3] drm: Add support for the LogiCVC display controller

On Thu, 7 May 2020 at 21:11, Paul Kocialkowski
<paul.kocialkowski@...tlin.com> wrote:
>
> Hi Emil,
>
> Thanks for the review!
>
> On Mon 04 May 20, 14:28, Emil Velikov wrote:
> > Just had a casual quick look for custom KMS properties, since new
> > drivers made that mistake in the past.
> > Thanks for not including any o/
>
> Yeah I made sure not to include any, I know it easily gets very problematic and
> creates disparity between drivers while needing to be kept alive even when a
> standard way arises due to the no API breakage policy.
>
> The not-for-merge patch that I've sent does introduce some for the colorkey,
> and that's why they are marked as such :)
>
> > I made a couple of trivial suggestions - if you agree, feel free to
> > keep them as follow-up patches.
> >
> > On Thu, 30 Apr 2020 at 20:28, Paul Kocialkowski
> > <paul.kocialkowski@...tlin.com> wrote:
> >
> > > +int logicvc_of_property_parse_u32(struct device_node *of_node,
> > > +                                 const char *name, u32 *target)
> > > +{
> > > +       struct logicvc_of_property *property;
> > > +       const char *string;
> > > +       u32 value;
> > > +       int ret;
> > > +
> > > +       property = logicvc_of_property_lookup(name);
> > > +       if (!property)
> > > +               return -EINVAL;
> > > +
> > One could have the logicvc_of_properties[] entries indexed with the
> > logicvc_of_property_parse_{u32,bool} caller, using that instead of the
> > name string.
>
> Do I understand correctly that you're suggesting passing each entry's
> struct logicvc_of_property pointer to the function?
>
> I went for strings to make the code explicit and easy to read so I'd really
> like to keep it that way and avoid passing things like
> &logicvc_of_properties[4] or an index integer.
>
Add a some #define/enum and go to town. Example with sub-optimal names below:

enum foobar {
 LVC_OF_DISP_INTF,
 LVC_OF_DISP_CLRSPC,
...
};

static struct logicvc_of_property logicvc_of_properties[] = {
[LVC_OF_DISP_INTF]  = {
               .name           = "xylon,display-interface",
...
       },
[LVC_OF_DISP_CLRSPC] = {
               .name           = "xylon,display-colorspace",
...
       },
...
}

While the callers are:

       ret = logicvc_of_property_parse_u32(of_node, LVC_OF_DISP_INTF,
                                           &config->display_colorspace);
       ret = logicvc_of_property_parse_u32(of_node, LVC_OF_DISP_CLRSPC,
                                           &config->display_depth);

-Emil