Thread (98 messages) 98 messages, 11 authors, 2016-08-27

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

From: Sebastian Reichel <sre@kernel.org>
Date: 2016-08-22 23:58:28
Also in: linux-bluetooth, lkml

Hi,

On Mon, Aug 22, 2016 at 11:54:14PM +0100, One Thousand Gnomes wrote:
On Tue, 23 Aug 2016 00:00:17 +0200
Pavel Machek [off-list ref] wrote:
quoted
On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote:
quoted
quoted
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.  
Well... it would be good to do the right thing, at least in the places
where we can.

Yes, renumbering people's serials is bad, OTOH for new platforms it
would be nice not to expose ttyS15 which can only return -EBUSY.
That would still be a regression. Not everyone even uses the kernel
bluetooth stack. It would only return EBUSY if you had done an "up"
on it via the direct bluetooth stack.
So it returns EBUSY when uart-bus is used. Since uart-bus is about
hardwired devices that's basically always.

Also I wonder how relevant your "I want to handle all UART stuff out of
kernel" scenario is for uart-bus, which is about in-kernel UART
drivers.

-- Sebastian

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help