Re: [PATCH v2 0/3] device tree spidev solution - driver_override for SPI

[Trent Piepho <tpiepho@xxxxxxxxxx>]

On Wed, 2019-03-06 at 14:01 +0100, Jan Kundrát wrote:
> On úterý 5. března 2019 19:39:03 CET, Trent Piepho wrote:
> > On Tue, 2019-03-05 at 12:15 +0100, Jan Kundrát wrote:
> > > On čtvrtek 20. září 2018 21:18:27 CEST, Trent Piepho wrote: ...
> > 
> > The first and last are in, 5039563e7c25 and 605b3bec73cb.  The second
> > isn't.  It's not strictly necessary to use it.  But it does make the
> > udev rules a lot smaller and I think makes the system easier to use.
> 
> Indeed :). Do you have an example on how this explicit attach from 
> userspace looks like? I'm already setting ATTR{driver_override} from udev, 
> but that's not enough without your second patch. Should I perhaps poke in 
> sysfs, somehow?

What needs to happen is to write the device name to the spidev driver's
bind attribute to manually attach.  Because of driver_override, this
will work, rather than fail as it does without.

Unfortunately, "bind" is an attribute of the driver while udev is
responding to a uevent for the device.  So there's no handy ATTR{bind}
to use.

I don't recall the exact udev magic, but I did verify it can be done. 
I think it needed udev to run a command, something like:
RUN+="echo %k > %S/%p/subsystem/drivers/spidev/bind"

> 
> > Mark quite rightly pointed out that the other driver_overrides didn't
> > automatically attach and they should all work the same way.  I made
> > patches to convert them all to automatic, but then it fell off the
> > radar and I never finished with it.
> 
> If you ask me, that patch is rather simple and it enables a straightforward 
> way of exporting devices to userspace. From my point of view, this is a 
> desirable property.

Yes, I liked it too, that's why I did it that way.  But it seems like
all the driver_overrides should work the same way and it's not clear to
my trying to change them would be accepted.