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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160822234610.39d33dda@lxorguk.ukuu.org.uk>
Date:   Mon, 22 Aug 2016 23:46:10 +0100
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     Sebastian Reichel <sre@...nel.org>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Arnd Bergmann <arnd@...db.de>, Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        NeilBrown <neil@...wn.name>,
        "Dr . H . Nikolaus Schaller" <hns@...delico.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] UART slave device bus

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

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

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.

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

Alan