> On 23.04.2015, at 20:13, Mark Brown <broo...@kernel.org> wrote:
>
> As *repeatedly* mentioned before please stop taking things off-list. I
> really shouldn't need to remind you of this quite so often, I'm very
> tempted to start ignoring such messages.
>
This was NOT my intention and I am really sorry for that.
>> I agree, that we need a long-term solution, but the way it is right now
>> in for-next/for-linux people think something is broken and will call it
>> a regression or maybe an API change (because of a change in behaviour on
>> the device-tree).
>
> The entire point of this change is to make it look like things are
> broken because they are, in fact, broken. We continue to support these
> systems, we just complain loudly about them.
Essentially you say: let us produce an error-message for some
situation where there is NO way around making it work without
an error message.
>> But even with that change proposed to automatically register spidev in
>> the absence of a dedicated driver, this would basically drive the
>> distributions for boards like the raspberry pi, beaglebone black or
>> similar to change:
>> compatiblity="spidev";
>> to:
>> compatiblity="spi,unknown_device";
>
>> The distribution does not know what people will connect, so they can
>> not set the "right" value, so they have to use a dummy - and spidev
>> is the "typical" dummy that works right now.
>
> The distributions should not be registering any devices at all, they've
> no idea if anything is there in the first place or if spidev is a
> suitable way of controlling it - it may even be that the pin
> configuration for SPI is totally unsuitable. Users should be using
> device tree overlays to instantiate whatever hardware they have fitted
> to their system or there should be some other system which enumerates
> connected modules (in the rare cases where that's viable), it was the
> BeagleBone people who started the overlay work in the first place for
> precisely this reason.
OK, so how should someone deploy a RFM12B device correctly with
device-tree?
There exists no (official) kernel support, but several user-drivers that
make use of spidev.
If I would define the following in my device-tree (overlay) as per your
request:
compatiblity=“hoperf,rfm12b”;
then (as of now) no spidev would get loaded and I can not use a
user-space driver that relies on spidev.
Similar for a max187 ADC.
Also note that the "beagle-bone people” still provide device-trees that
explicitly set up compatiblity=“spidev” - I just did a quick check:
/boot/dtbs/3.19.3-bone4/omap3-ha-lcd.dtb contains spidev.
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
