linux-kernel - Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

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]

Message-ID: <CAOMqctSW=yDAHGSNAMkueK9aP4eh5eM_N9SkRjHBQY74UwfkCA@mail.gmail.com>
Date:	Mon, 27 Apr 2015 17:44:34 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Mark Brown <broonie@...nel.org>,
	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 17:13, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Mon, Apr 27, 2015 at 4:28 PM, Michal Suchanek <hramrach@...il.com> wrote:
>> 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.
>
> Unlike the spi bus, the USB bus is a discoverable bus. So you can probe
> for connected devices. No need to put them in DT (but you can, if the
> firmware does the probing and updates the DTB. E.g. Open Firmware did
> that for PCI (which was not hot-pluggable)).
>
> Unlike the spi bus, you can (more or less) find out if a device is attached
> to a uart, by listening to the bus, and waiting for a start bit.
>
> I do agree that it would be nice to put the other end of the uart link in DT,
> as you can't always know what you're talking to. Is it a modem? Is it a
> printer? Is it a BT module? Is it Super Grover? Is it Mega Mindy?

And the point is that it can be any of those and you can swap them. So
the DT cannot and will not describe the other end of the bus. There is
some point where the static part of the hardware configuration ends
and pluggable devices start and DT has to deal with that. Sticking
your head into the sand and pretending there is no connector on the
device will only give you a fork.

When the DT is unusable for me and it is unusable for other people
then either a change gets upstream which would be nice or it's bound
to be floating around the net as a patchset which would be annoying
but has happened in the past and will again.

And we are not really discussing some fundamental change to the kernel
that might have unexpected effects on unrelated subsystems. We are
just having a bikeshedding debate if and how a SPI connector is
represented in DT.

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/