Thread (67 messages) 67 messages, 18 authors, 2016-01-25

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

From: Rob Herring <hidden>
Date: 2016-01-22 16:50:20
Also in: linux-serial, lkml

On Fri, Jan 22, 2016 at 9:45 AM, Tomeu Vizoso [off-list ref] wrote:
On 20 January 2016 at 19:03, H. Nikolaus Schaller [off-list ref] wrote:
quoted
Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes [off-list ref]:
quoted
quoted
The problem is that *I* have no control over user space. But I also don't want
to say to my users "that is not my problem - get it solved yourself". This does
not help them.
Stuffing things into the kernel because the user space of a given
platform can't get itself organised isn't helpful to the other billion
plus Linux devices out there.
The assumption that there is  "the" user space of a given platform is wrong.
I'm a bit surprised at the arguments being exchanged here regarding
why the kernel may or may not deal with the detail that a (say) BT
chip is behind a uart.

I would have expected that the main (and IMO sufficient) reason why
the kernel should do it is because the particular bus used to connect
a BT chip to the CPU is a hw detail that a kernel that does its job
should keep to itself. Same as userspace not needing to care if a BT
chip is behind SDIO or USB, why does it have to tell the kernel behind
which UART a BT chip is sitting?
Thanks for writing exactly what I had not gotten around to writing.
You are exactly right. While historically UART devices where not
probe-able like SDIO (in theory) and USB are and maybe that was a
reason to handle in userspace, we do have the technology to describe
the UART connections now.

Adding Marcel who has also previously commented on the reasons why
this belongs in the kernel [1].

Rob

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002212.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help