Re: [RFC PATCH 0/3] UART slave device bus

[Sebastian Reichel]

Hi,

On Mon, Aug 22, 2016 at 11:46:10PM +0100, One Thousand Gnomes wrote:
> > 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.
> 
> This is one of those cases where ACPI gets it right. For the device tree
> case you will also need to describe the GPIO lines as part of your power
> management for that slave device.
>
> > I think the problem with line disciplines is, that they do
> > not follow the Linux device model. UART slaves may have extra
> 
> They follow it exactly.
> 
> You have a tty_port which wraps a device, and has the lifetime of the
> hardware and lives on busses and can support enumeration.
> 
> You have a tty which is a file system object with a lifetime determined
> by the use of the file handle, it's like any other file->private_data but
> quite complex because we must comply with POSIX and historic Unix tty
> behaviour.
> 
> You have an ldisc, which is simply a modularisation of the current
> protocol handler and is carefully engineered not to include any device
> specific knowledge. That's how you make it scale and actually work sanely.

I think the current support is far from sane for hardwired
serial-based bluetooth devices. I open the serial device,
set the line disector, set the vendor and maybe some other
extra information and then do nothing, since the kernel
handles everything for me. All of the information given to
the kernel could be done automatically using the firmware
information. Why should I care how my bluetooth device is
connected?

> > resources like gpios or regulators. 
> 
> Any resources belong to the tty_port or a child of the tty_port because
> only it has the correct lifetime. And yes it's perfectly reasonable for
> us to attach other resources to a tty_port or give it a child that is the
> device the other end of the fixed link. Everything the DT describes
> belongs hanging off the tty_port or a child thereof.

Right we need a _child_, since we describe the other end of the
fixed link. Adding random remote end resources to the tty_port
looks like a huge hack.

> We don't get this problem in ACPI space in general because as far as ACPI
> is concerned the tty has a child device and the child device describes
> its own power management so you just power the child on or off through
> ACPI and ACPI describes power sanely.
>
> Eveything you have that is device specific belongs in the tty_port driver
> for that hardware, or maybe shared library helpers if common.
> 
> Everything you have which involves invoking device defined policy
> according to protocol defined behaviour belongs in the ldisc.

ACPI is not better in this regard. Have a look at
drivers/bluetooth/hci_bcm.c and you will see a platform device
providing the GPIOs, which is then accessed by the line discipline.

> Unix has worked like this for well over 30 years and it works very
> well as a model.

TBH I don't think it does.

Why should I need to tell the kernel something, that it could know
automatically. Let's think about hci_bcm. The firmware tells the
kernel, that some bluetooth device is connected to the uart port.
The kernel ignores that information until the user also tells it,
that the bluetooth chip is connected to some tty. If the kernel had
done the right job, the user wouldn't even know, that bluetooth is
connected via UART.

-- Sebastian

Attachment: signature.asc
Description: PGP signature