Hi Alan,

quoted

Would it make sense then to define a DT binding that can cover these
four cases independent of the Linux usage:

a) an existing tty line discipline matched to a tty port
b) a serio device using the N_MOUSE line discipline (which
  happens to cover non-mouse devices these days)

These two are the same basic thing

	port x expects ldisc y {with properties ...}

quoted

c) a uart_port slave attached directly to the uart (like in your
  current code)

c) needs to be a tty_port slave attached directly to a tty_port.
Important detail, but as uart_port is just a subset of tty_port it's a
trivial detail to the DT.

quoted

d) the same slave drivers using a new tty line discipline

and this is also just a/b again.


What use cases and connectivity do you need to describe. Looking at the
ACPI platforms we have

- the expected serial port configuration
- the properties of the port (FIFO etc)
- the power management for the port

- the children of the port
- the power management of the children (at a very simplistic abstracted
 level)

So we want to be able to describe something like

 ttyS0 {
	baud: 1152008N1
	protocol: bluetooth hci
	fixed: yes
	powermanagement: { ... }
 }

we also need to know what Bluetooth vendor is there. Since we need to match the vendor to the firmware loading and configuration.

Additionally there might be PCM audio configurations that need to be considered. Since we have to configure direct PCM interconnect with the audio codec.

and if I look at the usermode crapfest on a lot of Android systems it
looks similar but with the notion of things like being able to describe

-	Use GPIO mode sleeping and assume first char is X to save power

-	Power up, wait n ms, write, read, wait n ms, power down (which
	has to be driven at the ldisc/user level as only the ldisc
	understands transactions, or via ioctls (right now Android user
	space tends to do hardcoded writes to /sys.. gpio to drive power

-	And a few variants thereof (power up on write, off on a timer
 	etc)

Actually the sad part about the Android mess is that we can fix it for Bluetooth. We have HCI User Channel that allows to grab a HCI device and assign it to Bluedroid stack on Android. So it would work with whatever bus or whatever vendor is underneath. All this hacking would go away. And we have used this successfully for Intel based Android platforms. We know this works.

So I can imagine wanting to describe something like

-	The bluetooth HCI hardware is managed by gpio 11 (or UART DTR,
	or PMIC n etc)
	The uart can switch into GPIO mode and is gpio 15

or

-	Raise gpio 4 when writing, drop it after 50mS with no read/write

Then the ldisc needs to make port->ops. calls for enabling/disabling low
power mode and expected char, and the uarts that can do it need to
implement the gpio/uart switching and any timers.

I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc bus that exposes devices that have no business of having a userspace /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc driver on the ldisc bus.

One of the problems is that attaching the ldisc from userspace you still need to figure out what /dev/ttyX you get assigned in the end. And figure out which one is the Bluetooth UART. If we want single images where things just work out of the box, we need to get extra information for doing auto-detection. So some sort of bus enumeration is key to make this work smoothly.

Regards

Marcel