Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

[Mark Brown]

On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote:

> Of course I could add "my-shiny-new-board" compatible to the device
> tree and spidev. Then when I build my-shiny-new-board2 and it happens
> to also use userspace driver I will not bother to update the
> compatible nor will anyone else doing this. So it's equivalent to
> having "foobar123" in there from the start. Your proposed solution is
> so complex that it will never be used as intended even if changing the
> compatible on the node and driver could be both accomplished by an
> echo to sysfs.

If you are describing the connected SPI device as the board rather than
the actual device you're doing things wrong, and if you have the same
thing on two boards then /of course/ they should list the same
compatible string so the existing software stack should work.  If people
just use some random board description that happens to work right now
even if it doesn't match their actual hardware then they're no worse off
than with your hacks but we've been pushing people to do something long
term supportable so a bunch of other people who paid attention will be
better off.

> >  If the tooling around this is too hard to use then that
> > seems like a useful thing to work on, having simple ways for people to
> > describe modules they build for maker type systems (ideally integrated
> > with schematic capture software) would be great for example.

> Again, what simple to use tooling do you use to describe the modem you
> connect to a serial port in the kernel (ideally integrated with
> schematic capture software)? I use none. I just connect the modem. I
> want to do that with all SPI devices that I do not intend to use with
> an in-kernel driver above the spi master driver that provides the
> communication channel as is the case with the serial modem.

This has been gone through repeatedly.  There's obvious differences here
- quite apart from anything else dedicated SPI connectors that are
completely fixed function and also not part of a bigger expansion
connector are rather rare and are a clear subset of the more general
plugin module case.  The way we handle serial ports is currently not
ideal anyway, and the general software stacks sitting on top of serial
ports are very different to those for SPI.

> It is not my very specific use case. It's common use case for
> devboards which have spi connectors.

That's really not that common - it *is* common to have expansion
connectors, but single function ones not so much and certainly not in
sufficient numbers that it's worth doing something that only works for
them alone (and then only in cases where spidev happens to be the best
way to control the device which is a further subset).  There's also the
fact that the limited connectors are more commonly found on the more
expensive eval boards which of course tend to have users who are more
technically experienced than the maker boards and should really not
struggle with basic tasks.

> If this particular way to solve the problem does not fit with the
> driver model does any of the previously listed ones fit better,
> perhaps with some changes?

> Or since you are familiar with the driver model perhaps you are away
> of a solution that was not mentioned so far that would accomplish this
> and fits with the driver model?

The answer remains the same, describe your module with a DT overlay and
load the overlay.  Or modify your DT directly if you like given that the
board is probably not enumerable anyway, especially if it's a flying
wire job.  If you want to bind devices at runtime you'll need new_id.

> Or if this use case does not fit into the driver model at all then
> perhaps the driver model needs updating to catch up with real world?

The problem isn't that the driver model can't cope, the problem is that
you are flat out refusing to do anything that involves describing the
hardware.

Attachment: signature.asc
Description: PGP signature