On 27 April 2015 at 17:13, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Mon, Apr 27, 2015 at 4:28 PM, Michal Suchanek <hramr...@gmail.com> wrote: >> When you have a serial port and just connect serial device to it with >> no special requirement you just specify the serial port in DT and talk >> to the device directly without any DT foo. >> >> When there is a BT module with reset lines and a kernel driver you >> write in DT that you have such and such BT module with such and such >> reset lines on the uart so the driver picks it up. >> >> Same for USB attached on-board WiFi - that some USB device needs >> special handling does not mean you have to specify your keyboard in DT >> to connect it to an USB port. >> >> What you are mandating here, basically, is equivalent of requiring a >> DT overlay to connect an USB keyboard or mouse because it is a device >> connected in hardware to the USB port and DT is supposed to describe >> the hardware. > > Unlike the spi bus, the USB bus is a discoverable bus. So you can probe > for connected devices. No need to put them in DT (but you can, if the > firmware does the probing and updates the DTB. E.g. Open Firmware did > that for PCI (which was not hot-pluggable)). > > Unlike the spi bus, you can (more or less) find out if a device is attached > to a uart, by listening to the bus, and waiting for a start bit. > > I do agree that it would be nice to put the other end of the uart link in DT, > as you can't always know what you're talking to. Is it a modem? Is it a > printer? Is it a BT module? Is it Super Grover? Is it Mega Mindy?
And the point is that it can be any of those and you can swap them. So the DT cannot and will not describe the other end of the bus. There is some point where the static part of the hardware configuration ends and pluggable devices start and DT has to deal with that. Sticking your head into the sand and pretending there is no connector on the device will only give you a fork. When the DT is unusable for me and it is unusable for other people then either a change gets upstream which would be nice or it's bound to be floating around the net as a patchset which would be annoying but has happened in the past and will again. And we are not really discussing some fundamental change to the kernel that might have unexpected effects on unrelated subsystems. We are just having a bikeshedding debate if and how a SPI connector is represented in DT. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
