Hi,

On Mon, Aug 22, 2016 at 05:07:06PM -0400, Marcel Holtmann wrote:

quoted

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.

It's not enough to automatically set a ldisc. There is also need for
additional resouces. For example the Nokia bluetooth driver needs
some extra GPIOs. The same is true for the in-tree hci_bcm, which
misuses the platform_device exactly like Greg doesn't want it.

quoted

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.

quoted

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.

I don't understand your propsoal. First you write, that no ttyX
needs to be exported at all, then you need to figure out what ttyX
got assigned in the end.

I think the problem with line disciplines is, that they do
not follow the Linux device model. UART slaves may have extra
resources like gpios or regulators. The current workaround from
the drivers is an additional platform device, which only is
used as resource storage and accessed by the line discipline.

I think having a proper slave devices would be better in the long
run than adding more hacks to work around the problem of line
discplines not being devices. It probably makes sense to make the
API similar to the line discipline API, though. That way old code
can be reused.

-- Sebastian