Date:	Thu, 30 Jun 2016 10:03:57 +0100
From:	Dan O'Donovan <dan@...tex.com>
To:	Michal Suchanek <hramrach@...il.com>,
	Mark Brown <broonie@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] drivers core: allow id match override when
 manually binding driver

On 06/30/2016 08:47 AM, Michal Suchanek wrote:
> On 29 June 2016 at 20:02, Mark Brown <broonie@...nel.org> wrote:
>> On Wed, Jun 29, 2016 at 05:32:48AM +0200, Michal Suchanek wrote:
>>
>>> The other is to get a generic expansion board and jumper wires. Of
>>> course, you will not use all pins of your expansion connector this
>>> way. On the other hand using the remaining pins becomes challenging
>>> because of the jumper wires you just added. You can use some of the
>>> remaining pins as GPIO or add more jumper wires and use some of the
>>> remaining functions of the connector for another expansion board.
>> I'm more than familiar with flying wire systems.  They just aren't a big
>> deal here, this is a very technical audience making systems that aren't
>> going to have their software meaningfully distributed.  Users making
>> flying wire systems really ought to be capable of making the trivial DT
>> changes required for them, and if they just hack something not great up
>> locally that's not really a problem so long as it works for them.
> No. Arduino tutorials made flying wire systems accessible to
> non-technical audience. There are similar tutorials for boards running
> vendor kernels.
In case its relevant, I'd like add to this point by emphasising that there is an increasing number of "maker" boards available, such as UP, Minnowboard, Intel Galileo, Intel Edison, Raspberry Pi, and more, which expose an open SPI bus interface on a pin header with the intention that a primary use of that SPI interface is decided at application level.  'spidev' is the adopted method for making that SPI interface accessible to those applications, and those boards do typically ship with Linux kernel that either (i) use spi_register_board_info in some board-specific platform driver to enable spidev by default for those interfaces, or (ii) include some hack in a custom kernel (such as adding a "spidev" compatible string) to allow it to be enabled with a DT or ACPI overlay, neither of which seem ideal.  Sorry if I'm just re-stating what's already been said.  Anyway, I would love to see a solution integrated for this, whatever the appropriate solution may be.
>
> Of course somebody with technical skill has to write the tutorial but
> following it requires only understanding of written text - which is
> becoming increasingly rare but is still not uncommon skill.
>
> So to write such tutorial you have to give some steps to follow which
> are reasonably likely to succeed on wide variety of boards and require
> smallest possible changes to the board software.
>
> For mainline this would currently entail
>
> a) loading an overlay that lists spidev directly as compatible and
> joke about obtuseness of the kernel developers that force you to read
> the log spam
>
> b) failing a) decompile your board devicetree, add the spidev
> compatible - apply the overlay manually offline, recompile, and reboot
>
> Adding new_id to spi bus does not simplify the thing at all. You still
> have to modify your devicetree. It will at most remove the log spam.
>
> I can even imagine people listing *all* their devices as compatible on
> single dt node when the board does not ship with kernel patched for
> loading overlays.
>
> Thanks
>
> Michal
> --
> To unsubscribe from this list: send the line "unsubscribe linux-spi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists