linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Erhard F." <erhard_f@mailbox.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Rob Herring <robh+dt@kernel.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>,
	"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: Thu, 19 Jan 2023 11:34:46 +0100	[thread overview]
Message-ID: <20230119103446.GO16547@kitsune.suse.cz> (raw)
In-Reply-To: <8a9f7ba5-37a4-0927-4ab2-d212f1b098a9@csgroup.eu>

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.

Thanks

Michal

  parent reply	other threads:[~2023-01-19 10:35 UTC|newest]

Thread overview: 24+ 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-18 16:24 ` Rob Herring
2023-01-18 20:13 ` Erhard F.
2023-01-18 21:46   ` Michal Suchánek
2023-01-19  8:00     ` Thomas Zimmermann
2023-01-19  9:01       ` Michal Suchánek
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-19  9:53     ` [PATCH v2] " Michal Suchanek
2023-01-19 10:00       ` Thomas Zimmermann
2023-01-19 11:42       ` Erhard F.
     [not found]       ` <8a9f7ba5-37a4-0927-4ab2-d212f1b098a9@csgroup.eu>
2023-01-19 10:34         ` Michal Suchánek [this message]
2023-01-20 12:10           ` Michal Suchánek
2023-01-19 13:11         ` Thomas Zimmermann
2023-01-19 13:23           ` Michal Suchánek
2023-01-19 15:20             ` Thomas Zimmermann
2023-01-20 11:27               ` Michal Suchánek
2023-01-20 11:39                 ` Thomas Zimmermann
2023-01-20 11:56                   ` Michal Suchánek
2023-01-19 15:18       ` Rob Herring
2023-01-20 17:23       ` Rob Herring
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-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=20230119103446.GO16547@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).