Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1464881 > unrolled thread

[RFC PATCH 0/3] UART slave device bus

Back to article view | Back to linux.kernel

Contents

  [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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#1467196

> Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
> 
>> 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 workqueue picks those bytes from the queue and
> atomically empties the queue

When and how fast is the work queue scheduled?
And by which event?

> The workqueue involves the receive handler.

This should be faster than if a driver directly processes incoming bytes?

> 
>> But how does the kernel API know how long such a block is?
> 
> It's as long as the data that has arrived in that time.

Which means the work queue handler have to decide if it is enough for a
frame to decode and if not, wait a little until more arrives.

Or you have to assemble chunks into a frame, i.e. copy data around.

Both seems a waste of scarce cpu cycles in high-speed situations to me.

> 
>> Usually there is a start byte/character, sometimes a length indicator, then payload data,
>> some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n.
>> For other serial protocols it might be AT, no length, and \r. Or something different.
>> HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length.
> 
> It doesn't look for any kind of protocol block headers.

Which might become the pitfall of the design because as I have described it is an
essential part of processing UART based protocols. You seem to focus on efficiently
buffering only but not about efficiently processing the queued data.

> The routine
> invoked by the work queue does any frame recovery.

> 
>> So I would even conclude that you usually can't even use DMA based UART receive
>> processing for arbitrary and not well-defined protocols. Or have to assume that the
> 
> 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).

> - it's all about
> data flows not about framing in the protocol sense.

Yes, but you should also take framing into account for a solution that helps to implement
UART slave devices. That is my concern.

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1467493

> 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 workqueue involves the receive handler.  
> 
> This should be faster than if a driver directly processes incoming bytes?

It is in cases like n_tty yes and more importantly the serial port can
take another interrupt while the workqueue is running, so you won't drop
bytes if you have flow control.

> Or you have to assemble chunks into a frame, i.e. copy data around.

You have to do a pass over the data anyway to remove any quoting in the
framing for things like SLIP and PPP.

> Both seems a waste of scarce cpu cycles in high-speed situations to me.

The only case that I am aware of where there is a clear inefficiency is
where the hardware is handling characters in big chunks with good
buffering (eg DMA) and we are driving a protocol like PPP which simply
wants to do one pass over the data and stuff it into the network stack.

That one would be nice to fix with the port->rx suggestion I made.

> Which might become the pitfall of the design because as I have described it is an
> essential part of processing UART based protocols. You seem to focus on efficiently
> buffering only but not about efficiently processing the queued data.

There's a good reason for that - latency and throughput are not the same
thing. We need good latency on the buffering but good throughput on the
processing. Also if we fail to queue all the data reliably it doesn't
matter how efficient the processing side is.

> > 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 are correct that in that
scenario we struggled (it's a lot better since Peter sorted the locking
out to be efficient).

> Yes, but you should also take framing into account for a solution that helps to implement
> UART slave devices. That is my concern.

I understand that I think anyway - you want to know the protocol state in
order to do optimal power management. Use a GPIO edge and assume it's a
'$', pick up via UART from the next byte, power the UART off the moment
you see \n. Leave the power on if you seem to be out of sync so you can
find a '$' and resync.

If you have driver specific code for this your driver gets told when the
line discipline changes so you can actually bury such logic in your low
level driver and even hide what is going on from above. 

I've never had a problemw with what you are doing - just that it needs to
b generic to be upstream, otherwise every serial driver would immediately
develop thousands of lines of code for fifty differently wired and
working phone and IoT devices.

If the tty being open and normal tty operations are acceptable for the
write/configuration side then the point I've been trying to make is you
can't generically handle this at the uart layer. 


At the ldisc layer it would have a slightly higher latency but look
something like (in an NMEA ldisc)


	/* We got newline, tell the port to go into low power mode
	   directly or via whatever helpers it uses and to send us a '$'
	   when it wakes back up if it can't send us the true char */
	if (port->slave) {
		if (ch == '\n')
			port->slave->ops.lowpower(port, '$');
		/* If we get a $ then wakey wakey */
		if (ch == '$')
			port->slave->ops.lowpower(port, 0);
	}
	/* And if ops.lowpower is a no-op it all still works */

That also means that the port->slave-> method would be called in a
workqueue so can do sensible stuff even on things like USB


And the driver would presumably do something like

	name = find_slave_name(blah);	/* From DeviceTree etc */
	if (name)
		port->slave = request_tty_slave(name);

(if you for some reason needed different behaviour knowledge at the slave
level a tty ldisc change does notify the tty_port so we can do that too)


Alan

[toc] | [prev] | [next] | [standalone]

#1467501

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 are correct that in that
> scenario we struggled (it's a lot better since Peter sorted the locking
> out to be efficient).

you have this backwards. Older 3G modems pretended to by Hayes compatible and pretended to be talking PPP. However PPP is terminated in the modem itself. It is not spoken over the 3GPP networks. These are purely IP.

And yes, in theory there was a dialup in GSM, but I don't know of any users. Even early 9600 baud communication was RLP based. And for modern things like LTE it is IP all the way (including voice).

What some modems still do today is pretend they are Ethernet devices. That is faked by the modem as well and mainly for some odd Windows crap. However many modern modems give you the raw IP stream. You just have to ask nicely.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1466292

> 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 when there is new data.

That's what the existing API gives you as an ldisc, it can't be immediate
in many cases however but must be buffered.

> > I'm assuming the only immediate consumers are in-kernel.  
> 
> Yes, but the driver should be notified about incoming data.

Alan

[toc] | [prev] | [next] | [standalone]

#1466470

[Multipart message — attachments visible in raw view] — view raw

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 timeouts and cleanups

Well there could be some timeout. As I said, I was thinking about
an API similar to poll(), but I agree, that a callback based API
is probably the better solution. It's simpler to implement and in
most cases simpler to use.

> > Alternatively the rx function could be a callback, that
> > is called when there is new data.
> 
> That's what the existing API gives you as an ldisc, it can't be
> immediate in many cases however but must be buffered.

I know and I think the ldisc API is fine in this regard. Also
the buffering allows DMA, so that's obviously preferred.

> > > I'm assuming the only immediate consumers are in-kernel.  
> > 
> > Yes, but the driver should be notified about incoming data.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1467586

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.

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).

While serio is typically layered on top of tty-ldisc (on top of
tty_port, which is often on top of uart_port) or on top of
i8042/ps2 drivers, I suppose we could add another back-end on top
of uart_port directly to avoid the ldisc configuration in many
cases when using devicetree based setup. This should also address
the main concern that Alan raised about generality of the
subsystem: we'd always leave the option of either manual configuration
of the tty-ldisc (for any tty_port) or configuring on-chip devices
(using uart_port) directly through DT. Of course the same thing
can be done if we hook into tty_port rather than uart_port.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1467643

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.

> 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.

I agree we'll probably need a character at time interface, but for
initial targets a buffer based interface is what's needed.

> While serio is typically layered on top of tty-ldisc (on top of
> tty_port, which is often on top of uart_port) or on top of
> i8042/ps2 drivers, I suppose we could add another back-end on top
> of uart_port directly to avoid the ldisc configuration in many
> cases when using devicetree based setup. This should also address
> the main concern that Alan raised about generality of the
> subsystem: we'd always leave the option of either manual configuration
> of the tty-ldisc (for any tty_port) or configuring on-chip devices
> (using uart_port) directly through DT. Of course the same thing
> can be done if we hook into tty_port rather than uart_port.

There are also some uart drivers that register directly with serio.

I'm also thinking of using an ldisc backend as well as a way to move
forward with the slave drivers while tty_port rework is being done. Of
course that doesn't solve the fundamental problems with using an ldisc
already. Going the tty_port route is going take some time to
restructure things in the tty layer and require tree wide changes to
tty drivers.

Rob

[toc] | [prev] | [next] | [standalone]

#1467714

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 agree we'll probably need a character at time interface, but for
> initial targets a buffer based interface is what's needed.

I think what's more important than the 'character-at-a-time' interface
is the notification about new data. Maybe I missed how you handle that
today, but it seems that you can currently only handle polling
for data using a blocking read.

> > While serio is typically layered on top of tty-ldisc (on top of
> > tty_port, which is often on top of uart_port) or on top of
> > i8042/ps2 drivers, I suppose we could add another back-end on top
> > of uart_port directly to avoid the ldisc configuration in many
> > cases when using devicetree based setup. This should also address
> > the main concern that Alan raised about generality of the
> > subsystem: we'd always leave the option of either manual configuration
> > of the tty-ldisc (for any tty_port) or configuring on-chip devices
> > (using uart_port) directly through DT. Of course the same thing
> > can be done if we hook into tty_port rather than uart_port.
> 
> There are also some uart drivers that register directly with serio.

Right, I think this is done to have automatic probing for the keyboard,
rather than relying on the user space interface configuration.

> I'm also thinking of using an ldisc backend as well as a way to move
> forward with the slave drivers while tty_port rework is being done. Of
> course that doesn't solve the fundamental problems with using an ldisc
> already. Going the tty_port route is going take some time to
> restructure things in the tty layer and require tree wide changes to
> tty drivers.

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)
c) a uart_port slave attached directly to the uart (like in your
   current code)
d) the same slave drivers using a new tty line discipline

If we can handle all four, then at least we have some flexibility
with moving around or merging the Linux implementation later.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1467719

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 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.

if we need any kind of userspace ABI to setup of Bluetooth over UART devices, then we have failed. We want that the special UARTs are identified via ACPI or DT and become an enumeratable bus. So we can attach a driver to it.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1467762

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 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.
> 
> if we need any kind of userspace ABI to setup of Bluetooth 
> over UART devices, then we have failed. We want that the 
> special UARTs are identified via ACPI or DT and become an
> enumeratable bus. So we can attach a driver to it.

I was not referring to new devices here, only to the existing user
space ABI that is used for serio (input) devices. If we have
any tools relying on e.g. the 'serio' name for the sysfs path, 
using another name for the new bus_type may cause incompatibility
when merging the two.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1467796

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

True, though I'd expect little of the data flow part of it to be reused.

>> I agree we'll probably need a character at time interface, but for
>> initial targets a buffer based interface is what's needed.
>
> I think what's more important than the 'character-at-a-time' interface
> is the notification about new data. Maybe I missed how you handle that
> today, but it seems that you can currently only handle polling
> for data using a blocking read.

What's there now I expect to change anyway. Probably will mirror the
ldisc interface based on the discussion.

>> > While serio is typically layered on top of tty-ldisc (on top of
>> > tty_port, which is often on top of uart_port) or on top of
>> > i8042/ps2 drivers, I suppose we could add another back-end on top
>> > of uart_port directly to avoid the ldisc configuration in many
>> > cases when using devicetree based setup. This should also address
>> > the main concern that Alan raised about generality of the
>> > subsystem: we'd always leave the option of either manual configuration
>> > of the tty-ldisc (for any tty_port) or configuring on-chip devices
>> > (using uart_port) directly through DT. Of course the same thing
>> > can be done if we hook into tty_port rather than uart_port.
>>
>> There are also some uart drivers that register directly with serio.
>
> Right, I think this is done to have automatic probing for the keyboard,
> rather than relying on the user space interface configuration.
>
>> I'm also thinking of using an ldisc backend as well as a way to move
>> forward with the slave drivers while tty_port rework is being done. Of
>> course that doesn't solve the fundamental problems with using an ldisc
>> already. Going the tty_port route is going take some time to
>> restructure things in the tty layer and require tree wide changes to
>> tty drivers.
>
> 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)

I agree with Alan these are the same. tty ldisc and tty ports are
Linux concepts which shouldn't leak into DT. I've rejected bindings
with "ttyBLAH" in them several times. Even if we did allow it, that
sounds a half solution to me. Now if the binding is the same as (c)
and there is some mapping of slave compatible string to ldisc, then
perhaps that is fine.

> c) a uart_port slave attached directly to the uart (like in your
>    current code)

From a binding standpoint, I think it is pretty simple. It's been
discussed several times, but does need to get written down in a common
binding doc. IMO it is:

- 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).
- 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.

> d) the same slave drivers using a new tty line discipline

As with (a) and (b), this should be an internal kernel detail or manual config.

Rob

[toc] | [prev] | [next] | [standalone]

#1467833

> > 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 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.

> - 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.

Alan

[toc] | [prev] | [next] | [standalone]

#1467851

> 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 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.

For the tty side by the way here's a first RFC of one approach we could
take. This should (unless I missed anything) allow the core tty framework
to be used directly from a kernel created tty object rather than one
backed by a file.

commit fcd072e755594f9c9c0533d45223f56f76e3d104
Author: Alan <alan@linux.intel.com>
Date:   Mon Aug 22 18:05:56 2016 +0100

    [RFC] tty_port: allow a port to be opened with a tty that has no file handle
    
    Let us create tty objects entirely in kernel space. Untested proposal to
    show why all the ideas around rewriting half the uart stack are not needed.
    
    With this a kernel created non file backed tty object could be used to handle
    data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in
    particular has to work back to the fs/tty layer.
    
    The tty_port code is however otherwise clean of file handles as far as I can
    tell as is the low level tty port write path used by the ldisc, the
    configuration low level interfaces and most of the ldiscs.
    
    Currently you don't have any exposure to see tty hangups because those are
    built around the file layer. However a) it's a fixed port so you probably
    don't care about that b) if you do we can add a callback and c) you almost
    certainly don't want the userspace tear down/rebuild behaviour anyway.
    
    This should however be sufficient if we wanted for example to enumerate all
    the bluetooth bound fixed ports via ACPI and make them directly available.
    
    It doesn't deal with the case of a user opening a port that's also kernel
    opened and that would need some locking out (so it returned EBUSY if bound
    to a kernel device of some kind). That needs resolving along with how you
    "up" or "down" your new bluetooth device, or enumerate it while providing
    the existing tty API to avoid regressions (and to debug).
    
    Alan

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 734a635..6210cff 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -855,7 +855,7 @@ static void tty_vhangup_session(struct tty_struct *tty)
 
 int tty_hung_up_p(struct file *filp)
 {
-	return (filp->f_op == &hung_up_tty_fops);
+	return (filp && filp->f_op == &hung_up_tty_fops);
 }
 
 EXPORT_SYMBOL(tty_hung_up_p);
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index c3f9d93..606d9e5 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -335,7 +335,7 @@ EXPORT_SYMBOL(tty_port_lower_dtr_rts);
  *	tty_port_block_til_ready	-	Waiting logic for tty open
  *	@port: the tty port being opened
  *	@tty: the tty device being bound
- *	@filp: the file pointer of the opener
+ *	@filp: the file pointer of the opener or NULL
  *
  *	Implement the core POSIX/SuS tty behaviour when opening a tty device.
  *	Handles:
@@ -369,7 +369,7 @@ int tty_port_block_til_ready(struct tty_port *port,
 		tty_port_set_active(port, 1);
 		return 0;
 	}
-	if (filp->f_flags & O_NONBLOCK) {
+	if (filp == NULL || (filp->f_flags & O_NONBLOCK)) {
 		/* Indicate we are open */
 		if (C_BAUD(tty))
 			tty_port_raise_dtr_rts(port);

[toc] | [prev] | [next] | [standalone]

#1468061

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 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.
> 
> For the tty side by the way here's a first RFC of one approach we could
> take. This should (unless I missed anything) allow the core tty framework
> to be used directly from a kernel created tty object rather than one
> backed by a file.
> 
> commit fcd072e755594f9c9c0533d45223f56f76e3d104
> Author: Alan <alan@linux.intel.com>
> Date:   Mon Aug 22 18:05:56 2016 +0100
> 
>    [RFC] tty_port: allow a port to be opened with a tty that has no file handle
> 
>    Let us create tty objects entirely in kernel space. Untested proposal to
>    show why all the ideas around rewriting half the uart stack are not needed.
> 
>    With this a kernel created non file backed tty object could be used to handle
>    data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in
>    particular has to work back to the fs/tty layer.
> 
>    The tty_port code is however otherwise clean of file handles as far as I can
>    tell as is the low level tty port write path used by the ldisc, the
>    configuration low level interfaces and most of the ldiscs.
> 
>    Currently you don't have any exposure to see tty hangups because those are
>    built around the file layer. However a) it's a fixed port so you probably
>    don't care about that b) if you do we can add a callback and c) you almost
>    certainly don't want the userspace tear down/rebuild behaviour anyway.
> 
>    This should however be sufficient if we wanted for example to enumerate all
>    the bluetooth bound fixed ports via ACPI and make them directly available.
> 
>    It doesn't deal with the case of a user opening a port that's also kernel
>    opened and that would need some locking out (so it returned EBUSY if bound
>    to a kernel device of some kind). That needs resolving along with how you
>    "up" or "down" your new bluetooth device, or enumerate it while providing
>    the existing tty API to avoid regressions (and to debug).

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.

The Bluetooth power on (aka hciconfig hci0 up/down) is already solved with modern Intel and Broadcom UART drivers. Essentially we attach the ldisc and tell it which vendor it is. That is it. Everything else is done inside the kernel from that point on.

So attaching the ldisc (via btattach tool) is similar to plugging in a dongle via USB. It runs that basic setup like firmware loading and configuration and then goes back into sleep mode. Only when powering the Bluetooth hciX device up (via bluetoothd or manually) it gets out of sleep mode. And the details for that are left up to the driver.

Internally the setup stage does a hciconfig hci0 up and it is already abstracted out that way. So there has been a lot of work in the Bluetooth subsystem to allow for this. That part is really solved.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1468076

> 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 hciconfig hci0 up and it is already abstracted out that way. So there has been a lot of work in the Bluetooth subsystem to allow for this. That part is really solved.

So you'd create a kernel side tty struct and bind it to the tty_port on
hci0 up and drop it on hci0 down ?

Alan

[toc] | [prev] | [next] | [standalone]

#1468085

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.

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.

And we may want to do incompatible change at some point. People should
not have to use hciattach on n900 from now on until end of time, just
because we exposed USB port as ttyO1 in past.

...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 :-).

Best regards,
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1468134

On Tue, 23 Aug 2016 00:00:17 +0200
Pavel Machek <pavel@ucw.cz> 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.  
> 
> 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.

Alan

[toc] | [prev] | [next] | [standalone]

#1468192

[Multipart message — attachments visible in raw view] — view raw

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 <pavel@ucw.cz> 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.  
> > 
> > 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

[toc] | [prev] | [next] | [standalone]

#1468199

> > 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.

Alan

[toc] | [prev] | [next] | [standalone]

#1468213

[Multipart message — attachments visible in raw view] — view raw

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 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.

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.

Also what should happen if old userspace use hciattach while
uart-bus slave-device doesn't have control over it? Do you
suggest to implement some dummy code, that detects uart-bus already
registered a hci device and returns success without doing anything?
Then "hciconfig hci0 up" will fail, since the tty is already taken
by hciattach.

Or do you suggest to register hci1 and one cannot use hci0? I guess
this breaks even more devices, as the device number changes.

Also note, that there is a chance, that hci0 will go up by some
script before hciattach has been called in your legacy userspace.
Then it will also fail.

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
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.

> 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.

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.

Note: I'm not in favour of merging uart and bluetooth drivers. This
is really bad design. But it shows, that /dev/tty interface is not
needed by in-kernel drivers.

Of course tty is needed by userland drivers, but I expect, that
those do not use the uart-bus. They already require all kind of
hardware knowledge and don't work out-of-the-box anyway, so they
do not gain from this framework.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.kernel

csiph-web