[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABxcv=nFx9r+=qMXop6kp6E4KoXaX_8duLY7S9fo6uqs_539jw@mail.gmail.com>
Date: Tue, 14 Dec 2021 09:37:29 +0100
From: Javier Martinez Canillas <javier@...hile0.org>
To: Rob Herring <robh+dt@...nel.org>
Cc: Hector Martin <marcan@...can.st>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Hans de Goede <hdegoede@...hat.com>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Pekka Paalanen <ppaalanen@...il.com>,
devicetree@...r.kernel.org,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from
simplefb to of
On Mon, Dec 13, 2021 at 3:50 PM Rob Herring <robh+dt@...nel.org> wrote:
>
> On Mon, Dec 13, 2021 at 5:30 AM Javier Martinez Canillas
> <javier@...hile0.org> wrote:
[snip]
> >
> > You are right that passing NULL is a safe code path for now due the
> > of_device_is_available(node) check, but that seems fragile to me since
> > just adding a similar debug output to of_platform_device_create()
> > could trigger the NULL pointer dereference.
>
> All/most DT functions work with a NULL node ptr, so why should this
> one be different?
>
If you are OK with the patch as is, then I won't object :)
> Rob
Best regards,
Javier
Powered by blists - more mailing lists