On 27 April 2015 at 12:10, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: > >> Hi, > > Please always provide context in your replies so people know what you're > talking about. > >> I've a feeling everyone in this thread is ignoring the >> raspberry pi use-case. Where the board is specifically >> designed for educational purposes and used with lots of >> peripherals which are usually programmed from userspace >> using e.g. python bindings for i2c-dev or spidev, for >> such a setup we really want spidev to be loaded on the >> spibus by default and we really do not have a proper >> compatible for a child device. > > No, that's a different problem - the context you describe just happens > to be your use case but it's in no way universal, there are plenty of > expansion boards out there that have devices that use real drivers > connected to them normally (and some of those could even be used in the > educational contexts you describe). I think the underlying need here is > either for a better way of registering things or better tooling around > device tree overlays to address the usability issues. No. 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. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html