Hi,

On Mon, Aug 22, 2016 at 05:00:40PM -0500, Rob Herring wrote:
> On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > Hi,
> >
> > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote:
> >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
> >> <gnomes@lxorguk.ukuu.org.uk> wrote:
> >> >> > I think there are two other valuable features provided by serio:
> >> >> >
> >> >> > - an existing set of drivers written to the API
> >> >> > - the implementation of the tty_ldisc
> >> >>
> >> >> True, though I'd expect little of the data flow part of it to be reused.
> >> >
> >> > Then your design is broken.
> >>
> >> I'm talking about serio, not my design which I already said the
> >> receive side at least needs work.
> >>
> >> The serio API for rx and tx is a single character at a time. I thought
> >> we agreed that's not sufficient for things like BT.
> >>
> >> >> - a child of the uart node
> >> >> - a reg property containing the line number if the parent has multiple
> >> >> uarts (I'd expect this to rarely be used).
> >> >
> >> > That surprises me as for current x86 platforms it would be the norm,
> >> > except that we use ACPI.
> >>
> >> Exactly, we're talking DT bindings here. Each port will be a separate
> >> node otherwise things like serial aliases and stdout-path won't work
> >> correctly. Compatible strings for 8250 uarts are for a single port.
> >> But if you had h/w such that it has common and per port registers then
> >> it may be a single node. I'm not aware of any example offhand (maybe
> >> PPC CPM). But it doesn't matter as reg can handle this case just fine
> >> if we need to.
> >
> > I would expect, that your imaginary example h/w also has one node
> > per port using a mfd style h/w description:
> >
> > multi-uart-device {
> >     uart1 {
> >         child { };
> >     };
> >     uart2 {
> >         child { };
> >     };
> > };
> 
> Yes, that is certainly possible too.

That way aliases and stdout-path also works. I think I would just
make one-node-per-uart-port mandatory and skip the reg part.

Let's assume your imaginary example h/w would be and i2c master with
two ports and some shared registers. Then it immidiatly becomes
clear, that one wants to somehow expose two ports in the DT instead
of using some port selection property (and reg would already be
taken).

> >> >> - baudrate and other line configuration (though I would expect the
> >> >> slave driver to know all this and set it w/o DT. Also, we already have
> >> >> a way to set baudrate in the parent node at least.)
> >
> > I'm not sure if every slave driver knows this. Maybe some generic
> > slave drivers will come up, once we have the infrastructure. So
> > it could be useful to have the settings as optional properties.
> > OTOH it can also be done once it is needed.
> 
> Yes, you could have devices that do autobaud detect and don't care
> other than some max baudrate which could be limited by either the host
> or device. Then you have others that are fixed or start at a fixed
> baud and then switch.
> 
> As for generic slaves, no doubt they will come up and I will be
> nak'ing the generic slave bindings. The "generic slave" is already
> supported via tty devices in userspace IMO.

Ok I didn't meant that generic. I meant something like "I have a
remote controller with specific protocol, baudrate is board
specific". Anyways it can be discussed once needed

-- Sebastian