Re: [PATCH 2/3] spidev: Add DT binding example.

[Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi,

On 27-04-15 12:04, Hans de Goede wrote:
> Hi Mark,
>
> On 27-04-15 11:36, Mark Brown wrote:
>> On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote:
>>> On 26 April 2015 at 14:51, Maxime Ripard
>>
>>>> No, you add a compatible for the device that is connected to the bus
>>>> through that slot.
>>
>>> There is no device connected in the slot by design. The slot is there
>>> for connecting random stuff you find in your mailbox or other drawers
>>> and boxes.
>>
>> You should be using device tree overlays to describe what actually ended
>> up getting connected there.
>
> Have you seen my mail about the raspberry pi use-case? Using dt-overlays
> simply is not an acceptable answer there. There are legitimate use-cases
> for a "generic spi bus" concept with the bus only being accessible via
> spidev.
>
> Blocking this use-case because you do not believe it is a valid use-case
> is not going to help, this will just lead to the custom distros these
> boards are shipping doing some ugly hack, which is not what we want
> IMHO.
>
> I hope that with the raspberry pi 2 the raspberry pi-s will eventually
> go fully devicetree / multi-platform kernel so that they can be supported
> ootb by distros which only want to ship a single multi-platform kernel
> like Debian, but that does require us to solve problems like this one.

To expand a bit on this, as you know there is this whole maker movement
thing going on, these are people using arduinos and raspberry pi-s and
they expect things to be easy and just work. This is also a huge pool
of potential new FOSS / Linux contributors. I believe that it is
important that we cater to these people.

One day one of them may have a kernel related itch and decide to scratch
it, do we work that person to then work on some weird (and often ugly)
fork of the kernel, or do we want such boards to be running a pristine
upstream kernel and have potential new contributors work on the upstream
kernel and hopefully also engage with the upstream kernel community,
where we can teach them our best practices which are often lacking in
the various "fork" communities ?

Regards,

Hans