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
Attachment:
signature.asc
Description: PGP signature
