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@xxxxxxxxxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
