On 22 August 2016 at 23:23, H. Nikolaus Schaller wrote:
> Hi Sebastian,
>
>> Am 22.08.2016 um 22:39 schrieb Sebastian Reichel :
>>
>> Hi,
>>
>> On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:
Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes
:
> What it is not
> Either we'd have to call tty_port->rx a character at a time or
> implement some temporary buffer. I don't think we want to call things
> like BT receive code a byte at a time. This needs to be a layer
> higher. flush_to_ldisc either needs to be duplicated to handle
> tty_port->rx or generalized t
On Thu, Aug 18, 2016 at 10:04 AM, One Thousand Gnomes
wrote:
>> No, the code should be fast as it is so simple. I assume there is some
>> reason the tty buffering is more complex than just a circular buffer.
>
> I would suggest you read n_tty.c carefully and then it'll make a fair bit
> of sense.
Hi Alan,
>> So you mean if I do "hciconfig hci0 down", then the uart-bus should
>> "down" the tty and only on "hciconfig hci0 up" it should "up" the
>> tty? I would expect a uart-bus slave-device takes control of the
>> device ("up" it) on probe. It's hardwired anyway.
>
> Today you can switch st
> So you mean if I do "hciconfig hci0 down", then the uart-bus should
> "down" the tty and only on "hciconfig hci0 up" it should "up" the
> tty? I would expect a uart-bus slave-device takes control of the
> device ("up" it) on probe. It's hardwired anyway.
Today you can switch stacks at runtime, y
On Mon, Aug 22, 2016 at 5:45 PM, One Thousand Gnomes
wrote:
> and if I look at the usermode crapfest on a lot of Android systems it
> looks similar but with the notion of things like being able to describe
>
> - Use GPIO mode sleeping and assume first char is X to save power
It's really na
+Dmitry to get his opinion on using serio.
On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmann wrote:
> On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote:
>> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote:
>> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
>> >>
>
Hi Alan,
>>> 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
Hi,
> Am 23.08.2016 um 00:42 schrieb Sebastian Reichel :
>
>> I am not a specialist for such things, but I think you have three
>> options to connect bluetooth:
>>
>> a) SoC-UART <-> BT-Chip-UART-port
>> b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port
>> c) USB <-> BT-Chip-USB-port (not
Hi,
On Tue, Aug 23, 2016 at 01:15:21AM +0100, One Thousand Gnomes wrote:
> > > 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 wh
> > 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 al
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 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. Let
Hi,
On Mon, Aug 22, 2016 at 11:46:10PM +0100, One Thousand Gnomes wrote:
> > 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
Hi,
On Mon, Aug 22, 2016 at 11:52:56PM +0100, One Thousand Gnomes wrote:
> > There are usb-serial devices, which could benefit from support
> > btw. I would find it really useful, if the Dangerous Prototype's
> > Bus Pirate would expose native /dev/i2c and /dev/spi and it's
> > based on FT232.
>
> 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
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.
> There are usb-serial devices, which could benefit from support
> btw. I would find it really useful, if the Dangerous Prototype's
> Bus Pirate would expose native /dev/i2c and /dev/spi and it's
> based on FT232.
That should just need an ldisc. I2C and SPI should at this point be sane
for hotplug
On Tue, 23 Aug 2016 00:00:17 +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.
> >
>
Hi,
On Mon, Aug 22, 2016 at 11:23:26PM +0200, H. Nikolaus Schaller wrote:
> > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel :
> >
> > Hi,
> >
> > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:
> >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes
> >>> :
> What
Hi,
On Mon, Aug 22, 2016 at 05:00:40PM -0500, Rob Herring wrote:
> On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote:
> > Hi,
> >
> > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote:
> >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
> >> wrote:
> >> >> > I think there
> I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc
> bus that exposes devices that have no business of having a userspace
> /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc
> driver on the ldisc bus.
The ldisc and tty have the wrong object l
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 brea
Hi,
On Mon, Aug 22, 2016 at 05:07:06PM -0400, Marcel Holtmann wrote:
> >> Would it make sense then to define a DT binding that can cover these
> >> four cases independent of the Linux usage:
> >>
> >> a) an existing tty line discipline matched to a tty port
> >> b) a serio device using the N_MOUS
On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote:
>> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
>> wrote:
>> >> > I think there are two other valuable features provided by serio:
>> >> >
>> >> > - an existin
On Monday, August 22, 2016 11:23:26 PM CEST H. Nikolaus Schaller wrote:
> I see what you mean, but kernel divides between directly connected UART and
> USB-connected UART.
>
> drivers/usb/serial/ vs. drivers/tty/serial/
That distinction purely exists for historic reasons. I'd argue that the
form
> 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.
> Internally the setup stage does a hcicon
Hi Sebastian,
> Am 22.08.2016 um 22:39 schrieb Sebastian Reichel :
>
> Hi,
>
> On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:
>>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes
>>> :
What it is not about are UART/RS232 converters connected through USB or
vi
Hi Alan,
- a child of the uart node
- a reg property containing the line number if the parent has multiple
uarts (I'd expect this to rarely be used).
>>>
>>> That surprises me as for current x86 platforms it would be the norm,
>>> except that we use ACPI.
>>
>> Exactly, we're
Hi Alan,
>> Would it make sense then to define a DT binding that can cover these
>> four cases independent of the Linux usage:
>>
>> a) an existing tty line discipline matched to a tty port
>> b) a serio device using the N_MOUSE line discipline (which
>> happens to cover non-mouse devices these
Hi,
On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:
> > Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes
> > :
> >> What it is not about are UART/RS232 converters connected through USB or
> >> virtual
> >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHS
Hi,
On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote:
> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
> wrote:
> >> > I think there are two other valuable features provided by serio:
> >> >
> >> > - an existing set of drivers written to the API
> >> > - the implementation of th
> I'm talking about serio, not my design which I already said the
> receive side at least needs work.
>
> The serio API for rx and tx is a single character at a time. I thought
> we agreed that's not sufficient for things like BT.
Yes.
>
> >> - a child of the uart node
> >> - a reg property con
On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes
wrote:
>> > I think there are two other valuable features provided by serio:
>> >
>> > - an existing set of drivers written to the API
>> > - the implementation of the tty_ldisc
>>
>> True, though I'd expect little of the data flow part of it t
> Would it make sense then to define a DT binding that can cover these
> four cases independent of the Linux usage:
>
> a) an existing tty line discipline matched to a tty port
> b) a serio device using the N_MOUSE line discipline (which
>happens to cover non-mouse devices these days)
These t
> > I think there are two other valuable features provided by serio:
> >
> > - an existing set of drivers written to the API
> > - the implementation of the tty_ldisc
>
> True, though I'd expect little of the data flow part of it to be reused.
Then your design is broken.
> - a child of the uar
On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmann wrote:
> On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote:
>> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote:
>> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
>> >>
>> >> Before I spend more time on this, I'm l
On Monday, August 22, 2016 11:28:02 AM CEST Marcel Holtmann wrote:
> >>> My impression is that there is some overlap in what you want
> >>> to do here, and what serio does today as a line discipline on top
> >>> of a tty line discipline (and on top of other non-uart serial
> >>> connections), so we
Hi Arnd,
>>> My impression is that there is some overlap in what you want
>>> to do here, and what serio does today as a line discipline on top
>>> of a tty line discipline (and on top of other non-uart serial
>>> connections), so we should look into whether the two can be unified
>>> or not. Here
On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote:
> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote:
> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
> >>
> >> Before I spend more time on this, I'm looking mainly for feedback on the
> >> general direction and s
On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote:
> On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
>>
>> Before I spend more time on this, I'm looking mainly for feedback on the
>> general direction and structure (the interface with the existing serial
>> drivers in particula
On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
>
> Before I spend more time on this, I'm looking mainly for feedback on the
> general direction and structure (the interface with the existing serial
> drivers in particular).
Aside from the things that have already been mentioned
Hi Alan,
>>> We do, today for bluetooth and other protocols just fine
>> I think it works (even with user-space HCI daemon) because bluetooth HCI is
>> slow (<300kByte/s).
>
> We do it for PPP over 3G modem as well. Modern 3G modems pretend to be
> network devices, older ones didn't - and you
> When and how fast is the work queue scheduled?
> And by which event?
That depends upon the platform and how busy the machine is. The dumb
uarts generally schedule it as soon as they've emptied the hardware. Some
controllers it may be done off a timer, others off DMA completion events
> > The w
> Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes
> :
>
>> Let me ask a question about your centralized and pre-cooked buffering
>> approach.
>>
>> As far as I see, even then the kernel API must notify the driver at the
>> right moment
>> that a new block has arrived. Right?
>
> The low l
> Let me ask a question about your centralized and pre-cooked buffering
> approach.
>
> As far as I see, even then the kernel API must notify the driver at the right
> moment
> that a new block has arrived. Right?
The low level driver queues words (data byte, flag byte)
The buffer processing wo
> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes
> :
>> What it is not about are UART/RS232 converters connected through USB or
>> virtual
>> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT
>> devices
>> connected through USB (even if they also run HCI protocol).
> Am 20.08.2016 um 15:22 schrieb One Thousand Gnomes
> :
>
> On Fri, 19 Aug 2016 19:42:37 +0200
> "H. Nikolaus Schaller" wrote:
>
>>> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes
>>> :
>>>
If possible, please do a callback for every character that arrives.
And not only if the
> A single one is already difficult... And some scenarios need to shield the
> UART
> from user space (currently there is always one /dev/tty per UART - unless the
> UART is completely disabled).
That bit is already covered and one or two devices support this because
they have things like 3 seria
On Fri, 19 Aug 2016 19:42:37 +0200
"H. Nikolaus Schaller" wrote:
> > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes
> > :
> >
> >> If possible, please do a callback for every character that arrives.
> >> And not only if the rx buffer becomes full, to give the slave driver
> >> a chance to
Am 19.08.2016 um 19:50 schrieb H. Nikolaus Schaller:
> Hi,
>
>> Am 19.08.2016 um 09:49 schrieb Oleksij Rempel :
>>
>> Hallo Nikolaus,
>>
>> do i understand it correctly. This driver is to make kind of interchip
>> communication and represent uart as a bus to allow use this bus from
>> multiple ker
Hi,
> Am 19.08.2016 um 09:49 schrieb Oleksij Rempel :
>
> Hallo Nikolaus,
>
> do i understand it correctly. This driver is to make kind of interchip
> communication and represent uart as a bus to allow use this bus from
> multiple kernel driver or expose it to user space?
The idea for UART slav
> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes
> :
>
>> If possible, please do a callback for every character that arrives.
>> And not only if the rx buffer becomes full, to give the slave driver
>> a chance to trigger actions almost immediately after every character.
>> This probably runs
Hi,
On Fri, Aug 19, 2016 at 12:38:08PM +0100, One Thousand Gnomes wrote:
> There are also some other slight complications when you look at
> real world implementations. Android devices tend to keep the GPS
> in userspace so most of them can't use some magic extra API but
> just drive GPIO lines vi
Hi Alan,
On Fri, Aug 19, 2016 at 12:03:05PM +0100, One Thousand Gnomes wrote:
> > I meant "Either some function similar to userspace's poll() is
> > needed, ...". Something like uart_dev_wait_for_rx()
>
> You can't really do that - it might never return and then how do
> you want to handle timeou
> Plenty? Really?. Lets break down the tty drivers in the kernel which
> don't use uart_port.
That's the wrong list - those that use uart port but don't always use the
uart_insert_char helpers will also break. So you can start by adding
8250
amba-pl011
atmel_serial
bcm63xx_uart
bfin_
> If possible, please do a callback for every character that arrives.
> And not only if the rx buffer becomes full, to give the slave driver
> a chance to trigger actions almost immediately after every character.
> This probably runs in interrupt context and can happen often.
We don't realisticall
> > 2. Only n_tty actually uses the tty_port layer buffering
>
> So the first point on 4K is not enough only applies to n_tty? If I
> don't need the tty_port buffer logic, then how am I re-inventing it?
There are two layers of buffering.
1. Some devices buffer bytes into an internal ring buffe
> I meant "Either some function similar to userspace's poll() is
> needed, ...". Something like uart_dev_wait_for_rx()
You can't really do that - it might never return and then how do you want
to handle timeouts and cleanups
> Alternatively the rx function could be a callback, that
> is called wh
Hallo Nikolaus,
do i understand it correctly. This driver is to make kind of interchip
communication and represent uart as a bus to allow use this bus from
multiple kernel driver or expose it to user space?
Correct?
Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller:
> Hi,
>
>> Am 19.08.2016 u
Hi,
> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel :
>
> Hi,
>
> On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote:
>> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel wrote:
>>> Thanks for going forward and implementing this. I also started,
>>> but was far from a functional st
Hi,
On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote:
> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel wrote:
> > Thanks for going forward and implementing this. I also started,
> > but was far from a functional state.
> >
> > On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring w
On Thu, Aug 18, 2016 at 9:25 AM, One Thousand Gnomes
wrote:
> On Wed, 17 Aug 2016 20:14:42 -0500
> Rob Herring wrote:
>
> This was proposed ages ago and the point clearly made that
>
> a) the idea doesn't work because uarts are not required to use the uart
> layer and even those that do sometimes
Hi Linus,
>> Currently, devices attached via a UART are not well supported in the
>> kernel. The problem is the device support is done in tty line disciplines,
>> various platform drivers to handle some sideband, and in userspace with
>> utilities such as hciattach.
>
> Freaking *awesome* Rob, th
On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel wrote:
> Hi Rob,
>
> Thanks for going forward and implementing this. I also started,
> but was far from a functional state.
>
> On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote:
>> Currently, devices attached via a UART are not well sup
On Thu, Aug 18, 2016 at 10:04 AM, One Thousand Gnomes
wrote:
>> No, the code should be fast as it is so simple. I assume there is some
>> reason the tty buffering is more complex than just a circular buffer.
>
> I would suggest you read n_tty.c carefully and then it'll make a fair bit
> of sense.
Hi Rob,
Thanks for going forward and implementing this. I also started,
but was far from a functional state.
On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote:
> Currently, devices attached via a UART are not well supported in
> the kernel. The problem is the device support is done in t
Hi Alan,
> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes
> :
>
> On Wed, 17 Aug 2016 20:14:42 -0500
> Rob Herring wrote:
>
> This was proposed ages ago and the point clearly made that
>
> a) the idea doesn't work because uarts are not required to use the uart
> layer and even those that
> Am 18.08.2016 um 17:38 schrieb One Thousand Gnomes
> :
>
>>> Your changes also don't work because serial uart drivers are not obliged
>>> to use any of the uart buffering helpers and particularly on the rx side
>>> many do not do so and the performance hit would be too high.
>>
>> The SoC I
On Thu, 18 Aug 2016 12:57:59 +0200
Greg Kroah-Hartman wrote:
> On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote:
> > Hi Pavel,
> >
> > > Am 18.08.2016 um 12:47 schrieb Pavel Machek :
> > >
> > >
> > >>
> > >> Thereof 4 files, ~260 changes w/o gps demo and documentation
On Wed, 17 Aug 2016 20:14:42 -0500
Rob Herring wrote:
This was proposed ages ago and the point clearly made that
a) the idea doesn't work because uarts are not required to use the uart
layer and even those that do sometimes only use half of it
b) that you should use the tty_port abstraction
So
On Thu, Aug 18, 2016 at 5:53 AM, Greg Kroah-Hartman
wrote:
> On Thu, Aug 18, 2016 at 12:30:32PM +0200, Marcel Holtmann wrote:
>> Hi Greg,
>>
>> >> Currently, devices attached via a UART are not well supported in the
>> >> kernel. The problem is the device support is done in tty line disciplines,
>
On Thu, Aug 18, 2016 at 5:22 AM, Greg Kroah-Hartman
wrote:
> On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote:
>> Currently, devices attached via a UART are not well supported in the
>> kernel. The problem is the device support is done in tty line disciplines,
>> various platform driver
On Thu, Aug 18, 2016 at 3:14 AM, Rob Herring wrote:
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line disciplines,
> various platform drivers to handle some sideband, and in userspace with
> utilities such as hci
Hi!
> >>> I am actually not convinced that GPS should be represented as
> >>> /dev/ttyS0 or similar TTY. It think they deserve their own driver
> >>> exposing them as simple character devices. That way we can have a
> >>> proper DEVTYPE and userspace can find them correctly. We can also
> >>> anno
> Am 18.08.2016 um 13:49 schrieb Marcel Holtmann :
>
> Hi Nikolaus,
>
> I am actually not convinced that GPS should be represented as
> /dev/ttyS0 or similar TTY. It think they deserve their own driver
> exposing them as simple character devices. That way we can have a
> proper D
Hi Marcel,
> Am 18.08.2016 um 13:41 schrieb Marcel Holtmann :
>
> Hi Nikolaus,
>
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line disciplines,
> various platform drivers to handle some sideband, and
Hi Greg,
>> Currently, devices attached via a UART are not well supported in the
>> kernel. The problem is the device support is done in tty line
>> disciplines,
>> various platform drivers to handle some sideband, and in userspace with
>> utilities such as hciattach.
>>
Hi Nikolaus,
I am actually not convinced that GPS should be represented as
/dev/ttyS0 or similar TTY. It think they deserve their own driver
exposing them as simple character devices. That way we can have a
proper DEVTYPE and userspace can find them correctly. We can also
Hi Pavel,
>>> I am actually not convinced that GPS should be represented as
>>> /dev/ttyS0 or similar TTY. It think they deserve their own driver
>>> exposing them as simple character devices. That way we can have a
>>> proper DEVTYPE and userspace can find them correctly. We can also
>>> annotate
Hi!
> > > I would _love_ to see that happen, but what about the GPS line
> > > discipline that we have today? How would that match up with a char
> > > device driver?
> >
> > we have a GPS line discipline? What is that one doing? As far as I
> > know all GPS implementations are fully userspace.
Hi Nikolaus,
Currently, devices attached via a UART are not well supported in the
kernel. The problem is the device support is done in tty line disciplines,
various platform drivers to handle some sideband, and in userspace with
utilities such as hciattach.
There hav
Because it was misunderstood, here a longer answer.
> Am 18.08.2016 um 12:47 schrieb Pavel Machek :
>
>
>>
>> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
>
> So what do you use for the serial devices?
You misunderstood the w/o documentation/bindings in a way that th
On Thu, Aug 18, 2016 at 01:01:24PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line
> disciplines,
> various platform drivers to handle some sideban
> Am 18.08.2016 um 13:10 schrieb Pavel Machek :
>
> Hi!
>
>>> I am actually not convinced that GPS should be represented as
>>> /dev/ttyS0 or similar TTY. It think they deserve their own driver
>>> exposing them as simple character devices. That way we can have a
>>> proper DEVTYPE and userspace
Hi Greg,
> Am 18.08.2016 um 12:57 schrieb Greg Kroah-Hartman
> :
>
> On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>>
>>> Am 18.08.2016 um 12:47 schrieb Pavel Machek :
>>>
>>>
Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings
Hi!
> > I am actually not convinced that GPS should be represented as
> > /dev/ttyS0 or similar TTY. It think they deserve their own driver
> > exposing them as simple character devices. That way we can have a
> > proper DEVTYPE and userspace can find them correctly. We can also
> > annotate them
Hi!
> Before I spend more time on this, I'm looking mainly for feedback on the
> general direction and structure (the interface with the existing serial
> drivers in particular).
Looks good to me.
Thanks,
Pavel
--
(english
Hi Marcel,
> Am 18.08.2016 um 12:49 schrieb Marcel Holtmann :
>
> Hi Nikolaus,
>
>>> Currently, devices attached via a UART are not well supported in the
>>> kernel. The problem is the device support is done in tty line disciplines,
>>> various platform drivers to handle some sideband, and in us
Hi Greg,
Currently, devices attached via a UART are not well supported in the
kernel. The problem is the device support is done in tty line disciplines,
various platform drivers to handle some sideband, and in userspace with
utilities such as hciattach.
There have be
On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 18.08.2016 um 12:47 schrieb Pavel Machek :
> >
> >
> >>
> >> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
> >
> > So what do you use for the serial devices? platform_device was
On Thu, Aug 18, 2016 at 12:49:47PM +0200, Marcel Holtmann wrote:
> Hi Nikolaus,
>
> >> Currently, devices attached via a UART are not well supported in the
> >> kernel. The problem is the device support is done in tty line disciplines,
> >> various platform drivers to handle some sideband, and in
Hi Pavel,
> Am 18.08.2016 um 12:47 schrieb Pavel Machek :
>
>
>>
>> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
>
> So what do you use for the serial devices? platform_device was vetoed
> for that purpose by Greg.
device tree?
This adds code of course - but only fo
On Thu, Aug 18, 2016 at 12:30:32PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> >> Currently, devices attached via a UART are not well supported in the
> >> kernel. The problem is the device support is done in tty line disciplines,
> >> various platform drivers to handle some sideband, and in user
Hi Nikolaus,
>> Currently, devices attached via a UART are not well supported in the
>> kernel. The problem is the device support is done in tty line disciplines,
>> various platform drivers to handle some sideband, and in userspace with
>> utilities such as hciattach.
>>
>> There have been sever
>
> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
So what do you use for the serial devices? platform_device was vetoed
for that purpose by Greg.
Pavel
--
(english) http://www.livejournal.com/~pave
Hi Rob,
many thanks for picking up this unsolved topic!
> Am 18.08.2016 um 03:14 schrieb Rob Herring :
>
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line disciplines,
> various platform drivers to handle some si
Hi Greg,
>> Currently, devices attached via a UART are not well supported in the
>> kernel. The problem is the device support is done in tty line disciplines,
>> various platform drivers to handle some sideband, and in userspace with
>> utilities such as hciattach.
>>
>> There have been several a
On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote:
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line disciplines,
> various platform drivers to handle some sideband, and in userspace with
> utilities such
Currently, devices attached via a UART are not well supported in the
kernel. The problem is the device support is done in tty line disciplines,
various platform drivers to handle some sideband, and in userspace with
utilities such as hciattach.
There have been several attempts to improve support,
99 matches
Mail list logo
