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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Apr 2015 16:28:36 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	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.

On 27 April 2015 at 12:10, Mark Brown <broonie@...nel.org> 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-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