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]

Date:   Tue, 23 Aug 2016 01:02:18 +0200
From:   Sebastian Reichel <sre@...nel.org>
To:     Pavel Machek <pavel@....cz>
Cc:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Marcel Holtmann <marcel@...tmann.org>,
        Rob Herring <robh@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        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

Hi,

On Tue, Aug 23, 2016 at 12:00:17AM +0200, Pavel Machek wrote:
> On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote:
> > > why would we even have it create a /dev/ttyX for these devices
> > > in the first place. Lets just not create an uevent for it and
> > > lets not create a dev_t for it.
> > 
> > Because if you don't it's a regression. It's not permissible to break
> > existing userspace.

I guess there are three classes

1.) support for uart-slaves on new devices -> tty can be safely
    disabled, as it was never exposed
2.) support for uart-slaves on devices, which exported a useless
    tty (-> port could not be used from userspace without kernel
    modifications) [this is what N900 falls under]
3.) support for uart-slaves on devices, which could use hciattach
    or similar tools previously. I think these devices can't
    switch to the new API without a regression anyways. If the
    kernel already registered the bluetooth stuff hciattach will
    fail due to the -EBUSY (or whatever is returned).

So from my point of view there is no real regression when we avoid
exporting the tty at all.

> Yes, renumbering people's serials is bad, OTOH for new platforms it
> would be nice not to expose ttyS15 which can only return -EBUSY.

No need to renumber, there is the serial mapping in DT. We can just
export ttyS0, ttyS2 and ttyS3 (and skip ttyS1, which is used for
hardwired serial device).

> And we may want to do incompatible change at some point. People should
> not have to use hciattach on n900 from now

Don't worry, since platform_driver approach has been NAK'd by Greg,
the N900 bluetooth driver can only proceed once this patchset has
gone into the kernel. So N900 will never use hciattach.

> on until end of time, just because we exposed USB port as ttyO1 in
> past.

USB port as ttyO1?

> ...actually. I guess we should disable that ttyO1 in the device tree
> for now, so nobody can start using it. As we currently have 2-3 people
> in world who got that bluetooth to work with out-of-tree patches,
> breakage should be quite acceptable :-).

If you just disable ttyO1 in the N900's DT, you break runtime PM,
since the kernel does not access disabled devices. We could add
some kernel quirk, but who should use ttyO1 (which is btw named
ttyS1 with 8251 based omap driver)? It's basically unusable from
userspace.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)