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] [day] [month] [year] [list]
Message-ID: <1502897189.2586.37.camel@synopsys.com>
Date:   Wed, 16 Aug 2017 15:26:30 +0000
From:   Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
To:     "robherring2@...il.com" <robherring2@...il.com>
CC:     "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jslaby@...e.com" <jslaby@...e.com>,
        "Eugeniy.Paltsev@...opsys.com" <Eugeniy.Paltsev@...opsys.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>
Subject: Re: [PATCH] earlycon: initialise baud field of earlycon device
 structure

On Wed, 2017-08-16 at 08:46 -0500, Rob Herring wrote:
> On Wed, Aug 16, 2017 at 6:52 AM, Eugeniy Paltsev
> <Eugeniy.Paltsev@...opsys.com> wrote:
> > Hi Rob,
> > 
> > On Tue, 2017-08-15 at 14:26 -0500, Rob Herring wrote:
> > > On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev
> > > <Eugeniy.Paltsev@...opsys.com> wrote:
> > > > [snip]
> > > > @@ -282,7 +283,15 @@ int __init of_setup_earlycon(const struct
> > > > earlycon_id *match,
> > > >                 }
> > > >         }
> > > > 
> > > > +       val = of_get_flat_dt_prop(node, "baud", NULL);
> > > 
> > > No, we already have a defined way to set the baud, we don't need
> > > a
> > > property in addition. Plus you didn't document it.
> > 
> > I guess by defined way to set the baud you mean setting baud after
> > device alias
> > in stdout-path property (like stdout-path = "serial:115200n8"),
> > right?
> > 
> > The idea was to reuse "baud" property from serial node to set the
> > earlycon baud:
> > 
> > chosen {
> >     ...
> >     stdout-path = &serial;
> > };
> > 
> > serial: uart@... {
> >     ...
> >     baud = <115200>;   /* Get baud from here */
> 
> "current-speed" is already defined for this purpose. If you want to
> add that, that's fine.
Ok, I'll add "current-speed".

> > };
> > 
> > > > +       if (val)
> > > > +               early_console_dev.baud = be32_to_cpu(*val);
> > > > +
> > > >         if (options) {
> > > > +               err = kstrtoul(options, 10, &baud);
> > > > +               if (!err)
> > > > +                       early_console_dev.baud = baud;
> > > 
> > > This seems fine to do here, but then we should also parse the
> > > other
> > > standard options here too. And we should make sure we're not
> > > doing it
> > > twice.
> > 
> > I added only baud parsing here because we parse only baud from
> > standard
> > options
> > when register_earlycon is used. (see parse_options function which
> > is
> > called
> > from register_earlycon)
> > 
> > But I can add other standard options parsing here (probably using
> > uart_parse_options + uart_set_options).
> > What do you think?
> 
> That seems fine as long as consoles can still have their own options.
Ok.

Should I also add standard options parsing to register_earlycon?
(as we parse only baud from standard options in register_earlycon)

> Rob
-- 
 Eugeniy Paltsev

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ