linux-kernel - Re: [PATCH] drm: vc4: Use of_property

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqKZSk+zY49CAzDisA3kBQf46TOvN-OF+wTH=LGLGwSQUw@mail.gmail.com>
Date: Fri, 6 Sep 2024 14:15:11 -0500
From: Rob Herring <robh@...nel.org>
To: Dave Stevenson <dave.stevenson@...pberrypi.com>
Cc: Maxime Ripard <mripard@...nel.org>, 
	Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm: vc4: Use of_property_present()

On Fri, Sep 6, 2024 at 9:24 AM Dave Stevenson
<dave.stevenson@...pberrypi.com> wrote:
>
> On Wed, 4 Sept 2024 at 14:19, Rob Herring <robh@...nel.org> wrote:
> >
> > On Wed, Sep 4, 2024 at 6:18 AM Dave Stevenson
> > <dave.stevenson@...pberrypi.com> wrote:
> > >
> > > Hi Rob
> > >
> > > On Tue, 3 Sept 2024 at 20:19, Rob Herring <robh@...nel.org> wrote:
> > > >
> > > > On Wed, Jul 31, 2024 at 2:13 PM Rob Herring (Arm) <robh@...nel.org> wrote:
> > > > >
> > > > > Use of_property_present() to test for property presence rather than
> > > > > of_find_property(). This is part of a larger effort to remove callers
> > > > > of of_find_property() and similar functions. of_find_property() leaks
> > > > > the DT struct property and data pointers which is a problem for
> > > > > dynamically allocated nodes which may be freed.
> > > > >
> > > > > Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
> > > > > ---
> > > > >  drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > Ping!
> > >
> > > Sorry, this fell through the cracks.
> > >
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > index d57c4a5948c8..049de06460d5 100644
> > > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > @@ -2211,7 +2211,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
> > > > >         struct device *dev = &vc4_hdmi->pdev->dev;
> > > > >         struct platform_device *codec_pdev;
> > > > >         const __be32 *addr;
> > > > > -       int index, len;
> > > > > +       int index;
> > > > >         int ret;
> > > > >
> > > > >         /*
> > > > > @@ -2234,7 +2234,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
> > > > >         BUILD_BUG_ON(offsetof(struct vc4_hdmi_audio, card) != 0);
> > > > >         BUILD_BUG_ON(offsetof(struct vc4_hdmi, audio) != 0);
> > > > >
> > > > > -       if (!of_find_property(dev->of_node, "dmas", &len) || !len) {
> > > > > +       if (!of_property_present(dev->of_node, "dmas")) {
> > >
> > > The existing conditional is true if the property is not present or is 0 length.
> > > Your new one is only true if the property isn't present, so it isn't the same.
> >
> > It is not the kernel's job to validate the DT. It does a terrible job
> > of it and we have better tools for that now (schemas (though RPi
> > platforms are in a pretty sad state for schemas)). I'm pretty sure a
> > zero length or otherwise malformed "dmas" property would also cause a
> > dtc warning as well. Non-zero length is hardly a complete test
> > anyways. Any bogus value of "dmas" would pass. Or it can be completely
> > valid, but the DMA driver is not enabled (whether you even probe
> > depends on fw_devlinks).
> >
> > The kernel should just parse the properties it wants and handle any errors then.
>
> I've followed up over the rationale of this.
>
> The base DT enables HDMI audio.
> On some systems there is a need to use the DMA channels for other
> purposes and no need for HDMI audio.

If that's a user decision, I wouldn't use overlays to decide that, but
make it a run-time OS decision...

> As we understand it, an overlay can't remove a property from the base
> DT, but it can set it to being empty. (Please correct us if there is a
> way to delete an existing property).

There isn't currently.

> The current check therefore allows an overlay to disable the HDMI
> audio that is enabled in the base DT. It doesn't care how long the
> property actually is, just whether it is totally empty or not as an
> alternative to being present.
>
> I understand that you may consider that abuse of DT, but that is the
> reasoning behind it. We can drop it to a downstream patch if
> necessary.

I guess it's going to be use of_count_phandle_with_args() instead.

Rob