Re: [PATCH] serial: core: Add support for dev_name:0.0 naming for kernel console

[Tony Lindgren <tony@atomide.com>]

* Jiri Slaby <jirislaby@kernel.org> [230719 05:36]:
> On 19. 07. 23, 7:32, Tony Lindgren wrote:
> > * Jiri Slaby <jirislaby@kernel.org> [230719 05:29]:
> > > On 19. 07. 23, 7:28, Tony Lindgren wrote:
> > > > * Jiri Slaby <jirislaby@kernel.org> [230719 05:25]:
> > > > > On 19. 07. 23, 7:15, Tony Lindgren wrote:
> > > > > > +/*
> > > > > > + * Add preferred console if configured on kernel command line with naming
> > > > > > + * "console=dev_name:0.0".
> > > > > > + */
> > > > > > +static int serial_core_add_preferred_console(struct uart_driver *drv,
> > > > > > +					     struct uart_port *port)
> > > > > > +{
> > > > > > +	char *port_match, *opt, *name;
> > > > > > +	int len, ret = 0;
> > > > > > +
> > > > > > +	port_match = kasprintf(GFP_KERNEL, "console=%s:%i.%i",
> > > > > > +			       dev_name(port->dev), port->ctrl_id,
> > > > > > +			       port->port_id);
> > > > > > +	if (!port_match)
> > > > > > +		return -ENOMEM;
> > > > > > +
> > > > > > +	opt = strstr(saved_command_line, port_match);
> > > > > > +	if (!opt)
> > > > > > +		goto free_port_match;
> > > > > > +
> > > > > > +	len = strlen(port_match);
> > > > > > +
> > > > > > +	if (strlen(opt) > len + 1 && opt[len] == ',')
> > > > > > +		opt += len + 1;
> > > > > > +	else
> > > > > > +		opt = NULL;
> > > > > > +
> > > > > > +	name = kstrdup(drv->dev_name, GFP_KERNEL);
> > > > > 
> > > > > Why do you dup the name here?
> > > > 
> > > > I was getting ignoring const warning, but maybe the right solution is
> > > > to just use const char *name here.. Let me check.
> > > 
> > > So fix add_preferred_console() instead ;).
> > 
> > Let's see what kind of trouble changing it to use const char *name
> > might be.
> 
> I don't see any, the string is copied internally. So it should be
> straightforward. Actually all three parameters of __add_preferred_console()
> should be const, IMO. But that involves changing struct console_cmdline. But
> that should be straightforward too.

Yeah I'll send a patch for that.

> Aside from that, why do you parse saved_command_line on your own? Instead of
> using setup() or other commonly used mechanisms for command line handling?

Hmm that might be easier yeah :)

Regards,

Tony