[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMqctTivbDfvTO1dzVi+j=8JOvmGCdLOTnqb6U9R_TG8Hkypg@mail.gmail.com>
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