On Mon, Apr 27, 2015 at 04:14:31PM +0200, Martin Sperl wrote: > On 2015-04-27 13:25, Mark Brown wrote: > >I don't think you've fully considered your use case here. As I said in > >my reply to your earlier e-mail I think what you're looking for here is > >something like better UI around overlays. Registering a SPI bus without > >knowing what's connected to it doesn't allow generic maker style usage > >of the board, it's just as likely to hinder a user as help them. For > So you see that spi is disabled by default - the pins are > free to use for anything. > The firmware then integrates the overrrides into the device-tree > before loading the kernel. > So to enable spi in general you add the following to /boot/config.txt: > dtparam=spi=on > That gives you spi plus two "generic" spidev devices. OK, so that is just a default overlay which is abusing the fact that we will bind to spidev without a DT compatible and when the binding is undocumented (which also applies to other devices and buses sadly). Unfortunately nobody ever mentioned this upstream and the feedback upstream that listing spidev in a DT is a bad idea has been ignored. The whole reason we're doing this in the first place is that we got sick of telling people that using spidev in DTs like this was a bad idea. > If you want to include a mcp2515 you add also the following: > dtoverlay=mcp2515-can0-overlay > and that loads also the overlay for the mcp2515 can module. And this is just a user specified overlay which is completely fine already. > So coming from this perspective I believe that there is some > concern in the raspberry pi community, because the description > they provide is now specific to the HW and their intent and so > the loud "croaking" of spidev will irritate people even when > they have done everything the best they can. It does sound like the people maintianing the u-boot fork for the Pi need to talk to both u-boot upstream (nothing here is specific to the Pi that I can see) and the kernel community a bit more. I'd be a bit worried that they may be relying on other things that just happen to work without being intentional (and are therefore more vulnerable to issues) and it's a bit depressing to see things like this stuck in a fork where only a limited community can make use of them. > The only thing that could possibly be better would be that > the user would define the "real" name of the device in the > device tree and spidev would bind to it if there is no driver > available (but that would require this "fallback" binding by > spidev in case of no driver). Yes, that is exactly the solution I'd suggest - change the UI to provide a DT compatible to be used for the new device. That would also have the benefit of meaning that users who have connected some device that does have a driver that works with a simple binding wouldn't need to write an overlay which seems like it should be useful.
Attachment:
signature.asc
Description: Digital signature
