From: "Michal Suchánek" <msuchanek@suse.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Erhard F." <erhard_f@mailbox.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Javier Martinez Canillas <javierm@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2] of: Fix of platform build on powerpc due to bad of disaply code
Date: Fri, 20 Jan 2023 13:10:55 +0100 [thread overview]
Message-ID: <20230120121055.GU16547@kitsune.suse.cz> (raw)
In-Reply-To: <20230119103446.GO16547@kitsune.suse.cz>
On Thu, Jan 19, 2023 at 11:34:46AM +0100, Michal Suchánek wrote:
> Hello,
>
> On Thu, Jan 19, 2023 at 10:24:07AM +0000, Christophe Leroy wrote:
> >
> >
> > Le 19/01/2023 à 10:53, Michal Suchanek a écrit :
> > > The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > > breaks build because of wrong argument to snprintf. That certainly
> > > avoids the runtime error but is not the intended outcome.
> > >
> > > Also use standard device name format of-display.N for all created
> > > devices.
> > >
> > > Fixes: 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > ---
> > > v2: Update the device name format
> > > ---
> > > drivers/of/platform.c | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > > index f2a5d679a324..8c1b1de22036 100644
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -525,7 +525,9 @@ static int __init of_platform_default_populate_init(void)
> > > if (IS_ENABLED(CONFIG_PPC)) {
> > > struct device_node *boot_display = NULL;
> > > struct platform_device *dev;
> > > - int display_number = 1;
> > > + int display_number = 0;
> > > + char buf[14];
> >
> > Can you declare that in the for block where it is used instead ?
>
> No, there are two for blocks.
>
> >
> > > + char *of_display_format = "of-display.%d";
> >
> > Should be const ?
>
> Yes, could be.
>
> >
> > > int ret;
> > >
> > > /* Check if we have a MacOS display without a node spec */
> > > @@ -556,7 +558,10 @@ static int __init of_platform_default_populate_init(void)
> > > if (!of_get_property(node, "linux,opened", NULL) ||
> > > !of_get_property(node, "linux,boot-display", NULL))
> > > continue;
> > > - dev = of_platform_device_create(node, "of-display", NULL);
> > > + ret = snprintf(buf, sizeof(buf), of_display_format, display_number++);
> > > + if (ret >= sizeof(buf))
> > > + continue;
> >
> >
> > Can you make buf big enough to avoid that ?
>
> It would be a bit fragile that way.
>
> The buffer would have to theoretically accomodate
> "of-display.-9223372036854775808", and any change to the format requires
> recalculating the length, by hand.
>
> Of course, the memory would run out way before allocating that many
> devices so it's kind of pointless to try and accomodate all possible
> device numbers.
>
> >
> > And by the way could it be called something else than 'buf' ?
> >
> > See exemple here :
> > https://elixir.bootlin.com/linux/v6.1/source/drivers/fsi/fsi-occ.c#L690
>
> Yes, that is quite possible. Nonetheless, just like 'ret' generic
> variable names also work.
And in fact judicious use of short generic variable names is more
readeable than naming all variables foobar_* as far as I am concerned.
Of course, YMMV.
Thanks
Michal
WARNING: multiple messages have this Message-ID (diff)
From: "Michal Suchánek" <msuchanek@suse.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Erhard F." <erhard_f@mailbox.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Javier Martinez Canillas <javierm@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Frank Rowand <frowand.list@gmail.com>
Subject: Re: [PATCH v2] of: Fix of platform build on powerpc due to bad of disaply code
Date: Fri, 20 Jan 2023 13:10:55 +0100 [thread overview]
Message-ID: <20230120121055.GU16547@kitsune.suse.cz> (raw)
In-Reply-To: <20230119103446.GO16547@kitsune.suse.cz>
On Thu, Jan 19, 2023 at 11:34:46AM +0100, Michal Suchánek wrote:
> Hello,
>
> On Thu, Jan 19, 2023 at 10:24:07AM +0000, Christophe Leroy wrote:
> >
> >
> > Le 19/01/2023 à 10:53, Michal Suchanek a écrit :
> > > The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > > breaks build because of wrong argument to snprintf. That certainly
> > > avoids the runtime error but is not the intended outcome.
> > >
> > > Also use standard device name format of-display.N for all created
> > > devices.
> > >
> > > Fixes: 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > ---
> > > v2: Update the device name format
> > > ---
> > > drivers/of/platform.c | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > > index f2a5d679a324..8c1b1de22036 100644
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -525,7 +525,9 @@ static int __init of_platform_default_populate_init(void)
> > > if (IS_ENABLED(CONFIG_PPC)) {
> > > struct device_node *boot_display = NULL;
> > > struct platform_device *dev;
> > > - int display_number = 1;
> > > + int display_number = 0;
> > > + char buf[14];
> >
> > Can you declare that in the for block where it is used instead ?
>
> No, there are two for blocks.
>
> >
> > > + char *of_display_format = "of-display.%d";
> >
> > Should be const ?
>
> Yes, could be.
>
> >
> > > int ret;
> > >
> > > /* Check if we have a MacOS display without a node spec */
> > > @@ -556,7 +558,10 @@ static int __init of_platform_default_populate_init(void)
> > > if (!of_get_property(node, "linux,opened", NULL) ||
> > > !of_get_property(node, "linux,boot-display", NULL))
> > > continue;
> > > - dev = of_platform_device_create(node, "of-display", NULL);
> > > + ret = snprintf(buf, sizeof(buf), of_display_format, display_number++);
> > > + if (ret >= sizeof(buf))
> > > + continue;
> >
> >
> > Can you make buf big enough to avoid that ?
>
> It would be a bit fragile that way.
>
> The buffer would have to theoretically accomodate
> "of-display.-9223372036854775808", and any change to the format requires
> recalculating the length, by hand.
>
> Of course, the memory would run out way before allocating that many
> devices so it's kind of pointless to try and accomodate all possible
> device numbers.
>
> >
> > And by the way could it be called something else than 'buf' ?
> >
> > See exemple here :
> > https://elixir.bootlin.com/linux/v6.1/source/drivers/fsi/fsi-occ.c#L690
>
> Yes, that is quite possible. Nonetheless, just like 'ret' generic
> variable names also work.
And in fact judicious use of short generic variable names is more
readeable than naming all variables foobar_* as far as I am concerned.
Of course, YMMV.
Thanks
Michal
next prev parent reply other threads:[~2023-01-20 12:11 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 16:58 [PATCH] of: Make of framebuffer devices unique Michal Suchanek
2023-01-17 16:58 ` Michal Suchanek
2023-01-18 16:24 ` Rob Herring
2023-01-18 16:24 ` Rob Herring
2023-01-18 20:13 ` Erhard F.
2023-01-18 20:13 ` Erhard F.
2023-01-18 21:46 ` Michal Suchánek
2023-01-18 21:46 ` Michal Suchánek
2023-01-19 8:00 ` Thomas Zimmermann
2023-01-19 8:00 ` Thomas Zimmermann
2023-01-19 9:01 ` Michal Suchánek
2023-01-19 9:01 ` Michal Suchánek
2023-01-19 9:18 ` Thomas Zimmermann
2023-01-19 9:18 ` Thomas Zimmermann
2023-01-18 21:50 ` [PATCH] of: Fix of platform build on powerpc due to bad of disaply code Michal Suchanek
2023-01-18 21:50 ` Michal Suchanek
2023-01-19 9:53 ` [PATCH v2] " Michal Suchanek
2023-01-19 9:53 ` Michal Suchanek
2023-01-19 10:00 ` Thomas Zimmermann
2023-01-19 10:00 ` Thomas Zimmermann
2023-01-19 10:24 ` Christophe Leroy
2023-01-19 10:34 ` Michal Suchánek
2023-01-19 10:34 ` Michal Suchánek
2023-01-20 12:10 ` Michal Suchánek [this message]
2023-01-20 12:10 ` Michal Suchánek
2023-01-19 13:11 ` Thomas Zimmermann
2023-01-19 13:11 ` Thomas Zimmermann
2023-01-19 13:23 ` Michal Suchánek
2023-01-19 13:23 ` Michal Suchánek
2023-01-19 15:20 ` Thomas Zimmermann
2023-01-19 15:20 ` Thomas Zimmermann
2023-01-20 11:27 ` Michal Suchánek
2023-01-20 11:27 ` Michal Suchánek
2023-01-20 11:39 ` Thomas Zimmermann
2023-01-20 11:39 ` Thomas Zimmermann
2023-01-20 11:56 ` Michal Suchánek
2023-01-20 11:56 ` Michal Suchánek
2023-01-19 11:42 ` Erhard F.
2023-01-19 11:42 ` Erhard F.
2023-01-19 15:18 ` Rob Herring
2023-01-19 15:18 ` Rob Herring
2023-01-20 17:23 ` Rob Herring
2023-01-20 17:23 ` Rob Herring
2023-01-20 17:52 ` Michal Suchánek
2023-01-20 17:52 ` Michal Suchánek
2023-01-20 18:09 ` [PATCH v3] of: Make of framebuffer devices unique Michal Suchanek
2023-01-20 18:09 ` Michal Suchanek
2023-01-30 16:50 ` Rob Herring
2023-01-30 16:50 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230120121055.GU16547@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=christophe.leroy@csgroup.eu \
--cc=devicetree@vger.kernel.org \
--cc=erhard_f@mailbox.org \
--cc=frowand.list@gmail.com \
--cc=javierm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=robh+dt@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.