Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1464881 > unrolled thread
| Started by | Rob Herring <robh@kernel.org> |
|---|---|
| First post | 2016-08-18 03:20 +0200 |
| Last post | 2016-08-23 23:20 +0200 |
| Articles | 16 on this page of 96 — 10 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 03:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 12:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 12:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 16:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 15:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 12:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 12:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 14:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 15:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-18 15:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-19 03:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 04:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 17:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 03:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 07:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 09:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 20:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 22:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-22 23:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 23:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-23 09:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 19:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-21 19:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 20:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 11:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 11:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 16:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 14:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 15:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 17:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 17:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 18:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 18:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 23:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 02:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 02:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 03:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-24 16:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-24 16:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-23 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 19:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 00:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-24 14:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 23:20 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-24 16:00 +0200 |
| Message-ID | <s9GSJ-33R-13@gated-at.bofh.it> |
| In reply to | #1468213 |
> 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, you can switch between the kernel
stack and debug tools at runtime. Breaking that is a regression.
> Also what should happen if old userspace use hciattach while
> uart-bus slave-device doesn't have control over it? Do you
You would either use the old hciattach in which case you wouldn't be able
to manage it via a new API while attached, or the new API in which case
you wouldn't be able to manage it via the old interface while it was
being used directly.
> Or do you suggest to register hci1 and one cannot use hci0? I guess
> this breaks even more devices, as the device number changes.
Device numbers are dynamic anyway. Plug a USB adapter in and if it beats
your onboard adapter to registration then the order changes.
> So yes, from your point of view there is a regression, just because
> it's working automatically. So let's just not convert existing boards
> with working hciattach based bluetooth devices. New devices can use
From a distribution point of view that would be a nightmare.
> the uart-bus, as it's not a regression for them and Nokia N series
> can also do it, since they have no working bluetooth at all at the
> moment.
The Nokia N series is a weird corner case.
> > In many cases you'll also still need the tty interface to do
> > things like firmware upgrades.
>
> I would expect the uart-slave driver to know how to do firmware
> updates. Actually most bluetooth chips are initialized by uploading
> a firmware to them.
Usually no - you don't want a ton of kernel code for flashing adapters
when they have built in firmware (similar issue for 3G modems)
> And there are definitely uart drivers not caring about having a tty
> device. Nokia's vendor driver for their bluetooth protocol contains
> a custom omap-serial driver combined with the actual bluetooth
> driver. There is nothing related to the tty framework. I think the
> same would work for the other hardwired bluetooth chips perfectly
> fine.
That means having two different omap serial drivers to maintain which is
not ideal.
To me there are four different things
1. bluetooth devices "just work". That can be user space (eg it seems to
just work on my Fedora boxes and bluetooth enumeration is being done via
user space, or may be via kernel enumeration, or a mix. PPP is an
existing example of this - serial port PPP is an ldisc but ports that are
not UART like speak directly to the PPP layer as network adapters.
2. Sideband controls and power management, where we need to give the
tty_port a child device and power it up/down properly and have the
tty_port hooks to do so based upon the ldisc protocol state machine when
talking stuff like NMEA or HCI.
3. The special case UART power saving features/hacks like GPIO snooping,
again with the right hooks
4. Whether it's useful to be able to create a tty device in kernel and
attach that to stuff with no userspace involved.
All are independent.
Alan
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-24 16:40 +0200 |
| Message-ID | <s9Hvs-3yl-23@gated-at.bofh.it> |
| In reply to | #1469469 |
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 stacks at runtime, you can switch between the kernel
> stack and debug tools at runtime. Breaking that is a regression.
actually that is not true. We have HCI User Channel since a long time that gives you raw access to the devices. And also kernel interfaces to do all vendor / debug tasks.
Regards
Marcel
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-23 13:50 +0200 |
| Message-ID | <s9ino-3ui-33@gated-at.bofh.it> |
| In reply to | #1468199 |
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 basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. > > In many cases you'll also still need the tty interface to do things like > firmware upgrades. actually for Bluetooth you don't. We dealt with all of this crazy vendor stuff and provided proper hooks in the Bluetooth subsystem to support. hciattach / btattach are just the hotplug trigger to attach the hardware. It is like plugging in an USB dongle into your USB port. That is how you have to see this. Killing the hciattach / btattach process is the unplug event. It is that simple. And if you can skip the hciattach / btattach step and use kernel serial bus with proper enumeration and driver binding, then the end result is that you get a hci0 Bluetooth interface. The same way as you would have gotten when calling hciattach / btattach. Meaning you then call hciconfig hci0 up (or let bluetoothd do it for you) and you have Bluetooth working. It worked this way since 2.4.6 kernel. The real power on is done via hciconfig hci0 up and not hciattach. The only difference is that since a long time now, kernel drivers can provide extra vendor hooks. And the kernel can internally and temporally power on the hardware if it has to do certain tasks. For example configuring the BD_ADDR, loading some patches or doing some audio configuration. Regards Marcel
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 01:10 +0200 |
| Message-ID | <s96vT-4jp-9@gated-at.bofh.it> |
| In reply to | #1468085 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-22 19:40 +0200 |
| Message-ID | <s91my-Qk-29@gated-at.bofh.it> |
| In reply to | #1467833 |
On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> 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 to be reused. > > Then your design is broken. 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. >> - 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 talking DT bindings here. Each port will be a separate node otherwise things like serial aliases and stdout-path won't work correctly. Compatible strings for 8250 uarts are for a single port. But if you had h/w such that it has common and per port registers then it may be a single node. I'm not aware of any example offhand (maybe PPC CPM). But it doesn't matter as reg can handle this case just fine if we need to. >> - baudrate and other line configuration (though I would expect the >> slave driver to know all this and set it w/o DT. Also, we already have >> a way to set baudrate in the parent node at least.) >> - other standard device properties for interrupt, gpios, regulators. >> >> Also to consider is whether muxing of multiple slaves is needed. It's >> not anything I've seen come up, but it's not hard to imagine. I think >> that can be considered later and shouldn't impact the initial binding >> or infrastructure. > > You can describe the child of the serial device as a mux and the children > of the mux as whatever so it comes out fine when you get to that point. Yes, that's what I had in mind. Rob
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-22 22:10 +0200 |
| Message-ID | <s93HH-2wg-1@gated-at.bofh.it> |
| In reply to | #1467854 |
[Multipart message — attachments visible in raw view] — view raw
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
> <gnomes@lxorguk.ukuu.org.uk> 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 to be reused.
> >
> > Then your design is broken.
>
> 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.
>
> >> - 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 talking DT bindings here. Each port will be a separate
> node otherwise things like serial aliases and stdout-path won't work
> correctly. Compatible strings for 8250 uarts are for a single port.
> But if you had h/w such that it has common and per port registers then
> it may be a single node. I'm not aware of any example offhand (maybe
> PPC CPM). But it doesn't matter as reg can handle this case just fine
> if we need to.
I would expect, that your imaginary example h/w also has one node
per port using a mfd style h/w description:
multi-uart-device {
uart1 {
child { };
};
uart2 {
child { };
};
};
> >> - baudrate and other line configuration (though I would expect the
> >> slave driver to know all this and set it w/o DT. Also, we already have
> >> a way to set baudrate in the parent node at least.)
I'm not sure if every slave driver knows this. Maybe some generic
slave drivers will come up, once we have the infrastructure. So
it could be useful to have the settings as optional properties.
OTOH it can also be done once it is needed.
> >> - other standard device properties for interrupt, gpios, regulators.
> >>
> >> Also to consider is whether muxing of multiple slaves is needed. It's
> >> not anything I've seen come up, but it's not hard to imagine. I think
> >> that can be considered later and shouldn't impact the initial binding
> >> or infrastructure.
> >
> > You can describe the child of the serial device as a mux and the children
> > of the mux as whatever so it comes out fine when you get to that point.
>
> Yes, that's what I had in mind.
I guess it can be discussed, when it becomes relevant. Until then
let's not open another topic.
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-23 00:10 +0200 |
| Message-ID | <s95zQ-3HK-49@gated-at.bofh.it> |
| In reply to | #1468017 |
On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel <sre@kernel.org> 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
>> <gnomes@lxorguk.ukuu.org.uk> 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 to be reused.
>> >
>> > Then your design is broken.
>>
>> 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.
>>
>> >> - 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 talking DT bindings here. Each port will be a separate
>> node otherwise things like serial aliases and stdout-path won't work
>> correctly. Compatible strings for 8250 uarts are for a single port.
>> But if you had h/w such that it has common and per port registers then
>> it may be a single node. I'm not aware of any example offhand (maybe
>> PPC CPM). But it doesn't matter as reg can handle this case just fine
>> if we need to.
>
> I would expect, that your imaginary example h/w also has one node
> per port using a mfd style h/w description:
>
> multi-uart-device {
> uart1 {
> child { };
> };
> uart2 {
> child { };
> };
> };
Yes, that is certainly possible too.
>> >> - baudrate and other line configuration (though I would expect the
>> >> slave driver to know all this and set it w/o DT. Also, we already have
>> >> a way to set baudrate in the parent node at least.)
>
> I'm not sure if every slave driver knows this. Maybe some generic
> slave drivers will come up, once we have the infrastructure. So
> it could be useful to have the settings as optional properties.
> OTOH it can also be done once it is needed.
Yes, you could have devices that do autobaud detect and don't care
other than some max baudrate which could be limited by either the host
or device. Then you have others that are fixed or start at a fixed
baud and then switch.
As for generic slaves, no doubt they will come up and I will be
nak'ing the generic slave bindings. The "generic slave" is already
supported via tty devices in userspace IMO.
Rob
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 00:20 +0200 |
| Message-ID | <s95Jv-3Lg-3@gated-at.bofh.it> |
| In reply to | #1468091 |
[Multipart message — attachments visible in raw view] — view raw
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 <sre@kernel.org> 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
> >> <gnomes@lxorguk.ukuu.org.uk> 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 to be reused.
> >> >
> >> > Then your design is broken.
> >>
> >> 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.
> >>
> >> >> - 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 talking DT bindings here. Each port will be a separate
> >> node otherwise things like serial aliases and stdout-path won't work
> >> correctly. Compatible strings for 8250 uarts are for a single port.
> >> But if you had h/w such that it has common and per port registers then
> >> it may be a single node. I'm not aware of any example offhand (maybe
> >> PPC CPM). But it doesn't matter as reg can handle this case just fine
> >> if we need to.
> >
> > I would expect, that your imaginary example h/w also has one node
> > per port using a mfd style h/w description:
> >
> > multi-uart-device {
> > uart1 {
> > child { };
> > };
> > uart2 {
> > child { };
> > };
> > };
>
> Yes, that is certainly possible too.
That way aliases and stdout-path also works. I think I would just
make one-node-per-uart-port mandatory and skip the reg part.
Let's assume your imaginary example h/w would be and i2c master with
two ports and some shared registers. Then it immidiatly becomes
clear, that one wants to somehow expose two ports in the DT instead
of using some port selection property (and reg would already be
taken).
> >> >> - baudrate and other line configuration (though I would expect the
> >> >> slave driver to know all this and set it w/o DT. Also, we already have
> >> >> a way to set baudrate in the parent node at least.)
> >
> > I'm not sure if every slave driver knows this. Maybe some generic
> > slave drivers will come up, once we have the infrastructure. So
> > it could be useful to have the settings as optional properties.
> > OTOH it can also be done once it is needed.
>
> Yes, you could have devices that do autobaud detect and don't care
> other than some max baudrate which could be limited by either the host
> or device. Then you have others that are fixed or start at a fixed
> baud and then switch.
>
> As for generic slaves, no doubt they will come up and I will be
> nak'ing the generic slave bindings. The "generic slave" is already
> supported via tty devices in userspace IMO.
Ok I didn't meant that generic. I meant something like "I have a
remote controller with specific protocol, baudrate is board
specific". Anyways it can be discussed once needed
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-22 19:20 +0200 |
| Message-ID | <s913b-JI-3@gated-at.bofh.it> |
| In reply to | #1467714 |
> 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 two are the same basic thing
port x expects ldisc y {with properties ...}
> c) a uart_port slave attached directly to the uart (like in your
> current code)
c) needs to be a tty_port slave attached directly to a tty_port.
Important detail, but as uart_port is just a subset of tty_port it's a
trivial detail to the DT.
> d) the same slave drivers using a new tty line discipline
and this is also just a/b again.
What use cases and connectivity do you need to describe. Looking at the
ACPI platforms we have
- the expected serial port configuration
- the properties of the port (FIFO etc)
- the power management for the port
- the children of the port
- the power management of the children (at a very simplistic abstracted
level)
So we want to be able to describe something like
ttyS0 {
baud: 1152008N1
protocol: bluetooth hci
fixed: yes
powermanagement: { ... }
}
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
- Power up, wait n ms, write, read, wait n ms, power down (which
has to be driven at the ldisc/user level as only the ldisc
understands transactions, or via ioctls (right now Android user
space tends to do hardcoded writes to /sys.. gpio to drive power
- And a few variants thereof (power up on write, off on a timer
etc)
So I can imagine wanting to describe something like
- The bluetooth HCI hardware is managed by gpio 11 (or UART DTR,
or PMIC n etc)
The uart can switch into GPIO mode and is gpio 15
or
- Raise gpio 4 when writing, drop it after 50mS with no read/write
Then the ldisc needs to make port->ops. calls for enabling/disabling low
power mode and expected char, and the uarts that can do it need to
implement the gpio/uart switching and any timers.
Alan
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-22 23:10 +0200 |
| Message-ID | <s94DL-36M-13@gated-at.bofh.it> |
| In reply to | #1467835 |
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 days)
>
> These two are the same basic thing
>
> port x expects ldisc y {with properties ...}
>
>> c) a uart_port slave attached directly to the uart (like in your
>> current code)
>
> c) needs to be a tty_port slave attached directly to a tty_port.
> Important detail, but as uart_port is just a subset of tty_port it's a
> trivial detail to the DT.
>
>> d) the same slave drivers using a new tty line discipline
>
> and this is also just a/b again.
>
>
> What use cases and connectivity do you need to describe. Looking at the
> ACPI platforms we have
>
> - the expected serial port configuration
> - the properties of the port (FIFO etc)
> - the power management for the port
>
> - the children of the port
> - the power management of the children (at a very simplistic abstracted
> level)
>
> So we want to be able to describe something like
>
> ttyS0 {
> baud: 1152008N1
> protocol: bluetooth hci
> fixed: yes
> powermanagement: { ... }
> }
we also need to know what Bluetooth vendor is there. Since we need to match the vendor to the firmware loading and configuration.
Additionally there might be PCM audio configurations that need to be considered. Since we have to configure direct PCM interconnect with the audio codec.
> 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
>
> - Power up, wait n ms, write, read, wait n ms, power down (which
> has to be driven at the ldisc/user level as only the ldisc
> understands transactions, or via ioctls (right now Android user
> space tends to do hardcoded writes to /sys.. gpio to drive power
>
> - And a few variants thereof (power up on write, off on a timer
> etc)
Actually the sad part about the Android mess is that we can fix it for Bluetooth. We have HCI User Channel that allows to grab a HCI device and assign it to Bluedroid stack on Android. So it would work with whatever bus or whatever vendor is underneath. All this hacking would go away. And we have used this successfully for Intel based Android platforms. We know this works.
> So I can imagine wanting to describe something like
>
> - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR,
> or PMIC n etc)
> The uart can switch into GPIO mode and is gpio 15
>
> or
>
> - Raise gpio 4 when writing, drop it after 50mS with no read/write
>
> Then the ldisc needs to make port->ops. calls for enabling/disabling low
> power mode and expected char, and the uarts that can do it need to
> implement the gpio/uart switching and any timers.
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.
One of the problems is that attaching the ldisc from userspace you still need to figure out what /dev/ttyX you get assigned in the end. And figure out which one is the Bluetooth UART. If we want single images where things just work out of the box, we need to get extra information for doing auto-detection. So some sort of bus enumeration is key to make this work smoothly.
Regards
Marcel
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 00:10 +0200 |
| Message-ID | <s95zP-3HK-19@gated-at.bofh.it> |
| In reply to | #1468056 |
[Multipart message — attachments visible in raw view] — view raw
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_MOUSE line discipline (which
> >> happens to cover non-mouse devices these days)
> >
> > These two are the same basic thing
> >
> > port x expects ldisc y {with properties ...}
> >
> >> c) a uart_port slave attached directly to the uart (like in your
> >> current code)
> >
> > c) needs to be a tty_port slave attached directly to a tty_port.
> > Important detail, but as uart_port is just a subset of tty_port it's a
> > trivial detail to the DT.
> >
> >> d) the same slave drivers using a new tty line discipline
> >
> > and this is also just a/b again.
> >
> >
> > What use cases and connectivity do you need to describe. Looking at the
> > ACPI platforms we have
> >
> > - the expected serial port configuration
> > - the properties of the port (FIFO etc)
> > - the power management for the port
> >
> > - the children of the port
> > - the power management of the children (at a very simplistic abstracted
> > level)
> >
> > So we want to be able to describe something like
> >
> > ttyS0 {
> > baud: 1152008N1
> > protocol: bluetooth hci
> > fixed: yes
> > powermanagement: { ... }
> > }
>
> we also need to know what Bluetooth vendor is there. Since we need
> to match the vendor to the firmware loading and configuration.
>
> Additionally there might be PCM audio configurations that need to
> be considered. Since we have to configure direct PCM interconnect
> with the audio codec.
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.
> > 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
> >
> > - Power up, wait n ms, write, read, wait n ms, power down (which
> > has to be driven at the ldisc/user level as only the ldisc
> > understands transactions, or via ioctls (right now Android user
> > space tends to do hardcoded writes to /sys.. gpio to drive power
> >
> > - And a few variants thereof (power up on write, off on a timer
> > etc)
>
> Actually the sad part about the Android mess is that we can fix it
> for Bluetooth. We have HCI User Channel that allows to grab a HCI
> device and assign it to Bluedroid stack on Android. So it would
> work with whatever bus or whatever vendor is underneath. All this
> hacking would go away. And we have used this successfully for
> Intel based Android platforms. We know this works.
>
> > So I can imagine wanting to describe something like
> >
> > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR,
> > or PMIC n etc)
> > The uart can switch into GPIO mode and is gpio 15
> >
> > or
> >
> > - Raise gpio 4 when writing, drop it after 50mS with no read/write
> >
> > Then the ldisc needs to make port->ops. calls for enabling/disabling low
> > power mode and expected char, and the uarts that can do it need to
> > implement the gpio/uart switching and any timers.
>
> 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.
>
> One of the problems is that attaching the ldisc from userspace you
> still need to figure out what /dev/ttyX you get assigned in the
> end. And figure out which one is the Bluetooth UART. If we want
> single images where things just work out of the box, we need to
> get extra information for doing auto-detection. So some sort of
> bus enumeration is key to make this work smoothly.
I don't understand your propsoal. First you write, that no ttyX
needs to be exported at all, then you need to figure out what ttyX
got assigned in the end.
I think the problem with line disciplines is, that they do
not follow the Linux device model. UART slaves may have extra
resources like gpios or regulators. The current workaround from
the drivers is an additional platform device, which only is
used as resource storage and accessed by the line discipline.
I think having a proper slave devices would be better in the long
run than adding more hacks to work around the problem of line
discplines not being devices. It probably makes sense to make the
API similar to the line discipline API, though. That way old code
can be reused.
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-23 01:20 +0200 |
| Message-ID | <s96FA-4mL-17@gated-at.bofh.it> |
| In reply to | #1468086 |
> 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 where ACPI gets it right. For the device tree case you will also need to describe the GPIO lines as part of your power management for that slave device. > I think the problem with line disciplines is, that they do > not follow the Linux device model. UART slaves may have extra They follow it exactly. You have a tty_port which wraps a device, and has the lifetime of the hardware and lives on busses and can support enumeration. You have a tty which is a file system object with a lifetime determined by the use of the file handle, it's like any other file->private_data but quite complex because we must comply with POSIX and historic Unix tty behaviour. You have an ldisc, which is simply a modularisation of the current protocol handler and is carefully engineered not to include any device specific knowledge. That's how you make it scale and actually work sanely. > resources like gpios or regulators. Any resources belong to the tty_port or a child of the tty_port because only it has the correct lifetime. And yes it's perfectly reasonable for us to attach other resources to a tty_port or give it a child that is the device the other end of the fixed link. Everything the DT describes belongs hanging off the tty_port or a child thereof. We don't get this problem in ACPI space in general because as far as ACPI is concerned the tty has a child device and the child device describes its own power management so you just power the child on or off through ACPI and ACPI describes power sanely. Eveything you have that is device specific belongs in the tty_port driver for that hardware, or maybe shared library helpers if common. Everything you have which involves invoking device defined policy according to protocol defined behaviour belongs in the ldisc. Unix has worked like this for well over 30 years and it works very well as a model. Alan
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 01:50 +0200 |
| Message-ID | <s978B-4yf-1@gated-at.bofh.it> |
| In reply to | #1468147 |
[Multipart message — attachments visible in raw view] — view raw
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 the platform_device exactly like Greg doesn't want it. > > This is one of those cases where ACPI gets it right. For the device tree > case you will also need to describe the GPIO lines as part of your power > management for that slave device. > > > I think the problem with line disciplines is, that they do > > not follow the Linux device model. UART slaves may have extra > > They follow it exactly. > > You have a tty_port which wraps a device, and has the lifetime of the > hardware and lives on busses and can support enumeration. > > You have a tty which is a file system object with a lifetime determined > by the use of the file handle, it's like any other file->private_data but > quite complex because we must comply with POSIX and historic Unix tty > behaviour. > > You have an ldisc, which is simply a modularisation of the current > protocol handler and is carefully engineered not to include any device > specific knowledge. That's how you make it scale and actually work sanely. I think the current support is far from sane for hardwired serial-based bluetooth devices. I open the serial device, set the line disector, set the vendor and maybe some other extra information and then do nothing, since the kernel handles everything for me. All of the information given to the kernel could be done automatically using the firmware information. Why should I care how my bluetooth device is connected? > > resources like gpios or regulators. > > Any resources belong to the tty_port or a child of the tty_port because > only it has the correct lifetime. And yes it's perfectly reasonable for > us to attach other resources to a tty_port or give it a child that is the > device the other end of the fixed link. Everything the DT describes > belongs hanging off the tty_port or a child thereof. Right we need a _child_, since we describe the other end of the fixed link. Adding random remote end resources to the tty_port looks like a huge hack. > We don't get this problem in ACPI space in general because as far as ACPI > is concerned the tty has a child device and the child device describes > its own power management so you just power the child on or off through > ACPI and ACPI describes power sanely. > > Eveything you have that is device specific belongs in the tty_port driver > for that hardware, or maybe shared library helpers if common. > > Everything you have which involves invoking device defined policy > according to protocol defined behaviour belongs in the ldisc. ACPI is not better in this regard. Have a look at drivers/bluetooth/hci_bcm.c and you will see a platform device providing the GPIOs, which is then accessed by the line discipline. > Unix has worked like this for well over 30 years and it works very > well as a model. TBH I don't think it does. Why should I need to tell the kernel something, that it could know automatically. Let's think about hci_bcm. The firmware tells the kernel, that some bluetooth device is connected to the uart port. The kernel ignores that information until the user also tells it, that the bluetooth chip is connected to some tty. If the kernel had done the right job, the user wouldn't even know, that bluetooth is connected via UART. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-23 00:20 +0200 |
| Message-ID | <s95Jw-3Lg-21@gated-at.bofh.it> |
| In reply to | #1468056 |
> 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 lifetime for a bus, but you can put the tty_port objects onto the bus, and it is those you need to instantiate the stack. The port exists for hardware lifetime, the tty and ldisc exist only while the port is "up". Alan
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-24 14:30 +0200 |
| Message-ID | <s9FtD-2aP-11@gated-at.bofh.it> |
| In reply to | #1467835 |
On Mon, Aug 22, 2016 at 5:45 PM, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> 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 nasty hardware design, or a software hack to solve a hardware problem: what should have been done is of course create a UART with an asynchronous low-power mode that can recieve a character and wake up the system at any time, handing over the wakeup character(s) to the driver. That is obviously the usecase they were designing for. But yeah, I guess we have to contain hacks like that. > - Power up, wait n ms, write, read, wait n ms, power down (which > has to be driven at the ldisc/user level as only the ldisc > understands transactions, or via ioctls (right now Android user > space tends to do hardcoded writes to /sys.. gpio to drive power This kind of abominational abuse of the GPIO sysfs ABI is partly why I've obsoleted it. The right abstraction is the fixed regulator with a GPIO line obviously, then some sequencing along the lines of what you can find in drivers/mmc/core/pwrseq* Unfortunately that sysfs ABI crept in during a window of time when GPIO was unmaintained and I am trying my best to contain and improve the situation. Yours, Linus Walleij
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-23 23:20 +0200 |
| Message-ID | <s9rh0-140-23@gated-at.bofh.it> |
| In reply to | #1467714 |
+Dmitry to get his opinion on using serio. On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmann <arnd@arndb.de> 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 <arnd@arndb.de> 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 particular). >> > >> > Aside from the things that have already been mentioned in the discussion, >> > I wonder how this should relate to the drivers/input/serio framework. >> >> As I mentioned, I did investigate that route. > > Ok, sorry for missing that. > >> > 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 is what I found so far: >> > >> > For all I can tell, serio is only used for drivers/input/ but could >> > easily be extended to other subsystems. It currently uses its own >> > binary ID matching between drivers and devices through user space >> > interfaces, though adding a DT binding for it would appear to be >> > a good idea regardless. >> > >> > It also has a bus_type already, and with some operations defined on >> > it. In particular, it has an "interrupt" method that is used to >> > notify the client driver when a byte is available (and pass >> > that byte along with it). This seems to be a useful addition to >> > what you have. Since it is based on sending single characters >> > both ways, transferring large amounts of data would be slower, >> > but the interface is somewhat simpler. In principle, both >> > character based and buffer based interfaces could coexist here >> > as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. > > 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 I've looked at serio a bit more and was able to add in DT matching to it. It's a bit hacky to make it work with the ldisc as it gets the DT node from serio->dev.parent->parent (the parent is the tty and grandparent is the uart dev) and still requires inputattach to open the tty and set the ldisc. Otherwise, the mode for inputattach doesn't matter. So I plan to continue down this path. One thing I'm left wondering is serio essentially implements it's own async probing with connect()/disconnect(). Seems like it was because PS/2 port probing and resuming are slow. Is this still necessary or could be converted to use driver core async probing? That would make serio drivers look a bit more "normal". Rob
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.kernel
csiph-web