lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Apr 2015 12:09:36 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Mark Brown <broonie@...nel.org>,
	Michal Suchanek <hramrach@...il.com>
CC:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Martin Sperl <kernel@...tin.sperl.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>,
	Jonathan Corbet <corbet@....net>,
	linux-spi <linux-spi@...r.kernel.org>,
	linux-doc <linux-doc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ