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 [off-list ref] wrote:

quoted

Hi,

On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote:

quoted

On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
[off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

quoted

- 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).

quoted

quoted

quoted

quoted

- 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