[PATCH] spi: Force the registration of the spidev devices

[PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

spidev device registration has always been a controversial subject since the
move to DT.

Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.

While this is nicer than the DT solution because of its accurate hardware
representation, it's still not perfect because you might not have access to the
DT, or you might be driving a completely generic device (such as a
microcontroller) that might be used for something else in a different
context/board.

Solve this by registering automatically spidev devices for all the unused chip
selects when a master registers itself against the spi core.

This also adds an i2cdev-like feeling, where you get all the spidev devices all
the time, without any modification.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/spi/spi.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 4eb9bf02996c..e832a5e20e8d 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1402,6 +1402,52 @@ static void acpi_register_spi_devices(struct spi_master *master)
 static inline void acpi_register_spi_devices(struct spi_master *master) {}
 #endif /* CONFIG_ACPI */
 
+#ifdef CONFIG_SPI_SPIDEV
+static void spidev_register_devices(struct spi_master *master)
+{
+	struct spi_device *spi;
+	int i, status;
+
+	for (i = 0; i < master->num_chipselect; i++) {
+		spi = spi_alloc_device(master);
+		if (!spi) {
+			dev_err(&master->dev, "Couldn't allocate spidev device\n");
+			continue;
+		}
+
+		spi->chip_select = i;
+		strlcpy(spi->modalias, "spidev", sizeof(spi->modalias));
+
+		/*
+		 * This is far from perfect since an addition might be
+		 * done between here and the call to spi_add_device,
+		 * but we can't hold the lock and call spi_add_device
+		 * either, as it would trigger a deadlock.
+		 *
+		 * If such a race occurs, spi_add_device will still
+		 * catch it though, as it also checks for devices
+		 * being registered several times on the same chip
+		 * select.
+		*/
+		status = bus_for_each_dev(&spi_bus_type, NULL, spi,
+					  spi_dev_check);
+		if (status) {
+			dev_dbg(&master->dev, "Chipselect already in use.. Skipping.");
+			spi_dev_put(spi);
+			continue;
+		}
+
+		if (spi_add_device(spi)) {
+			dev_err(&master->dev, "Couldn't add spidev device\n");
+			spi_dev_put(spi);
+		}
+	}
+
+}
+#else
+static inline void spidev_register_devices(struct spi_master *master) {}
+#endif /* CONFIG_SPI_SPIDEV */
+
 static void spi_master_release(struct device *dev)
 {
 	struct spi_master *master;
@@ -1591,6 +1637,7 @@ int spi_register_master(struct spi_master *master)
 	/* Register devices from the device tree and ACPI */
 	of_register_spi_devices(master);
 	acpi_register_spi_devices(master);
+	spidev_register_devices(master);
 done:
 	return status;
 }
-- 
1.9.1

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:

> spidev device registration has always been a controversial subject since the
> move to DT.

Why can we not handle this by using sysfs to bind spidev to the device?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

Hi Mark

On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:
> 
> > spidev device registration has always been a controversial subject
> > since the move to DT.
> 
> Why can we not handle this by using sysfs to bind spidev to the
> device?

I just tried it, and apparently, you can't really use this, since spi
devices are created from the device tree (or ACPI) whenever the master
registers.

As such, you still need a DT node for every spidev device you might
want to use.

It doesn't really work either for a device that would be bound to a
driver, that you unbind, and then try to bind to spidev instead. It
looks like the device is released whenever you unbind it, so you can't
really use it afterwards.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:

> > Why can we not handle this by using sysfs to bind spidev to the
> > device?

> I just tried it, and apparently, you can't really use this, since spi
> devices are created from the device tree (or ACPI) whenever the master
> registers.

Can you be more specific as to what the issue is here?  If we actually
have a specific kernel driver for a device I would strongly expect that
we would want to use it and not spidev, if we don't have one I don't see
the issue.

> It doesn't really work either for a device that would be bound to a
> driver, that you unbind, and then try to bind to spidev instead. It
> looks like the device is released whenever you unbind it, so you can't
> really use it afterwards.

I guess this is the issue...  what exactly is the use case here?  I
would only expect spidev to be used if there is no in kernel driver for
a device.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

On Wed, Apr 30, 2014 at 06:18:11PM -0700, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> > On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> 
> > > Why can we not handle this by using sysfs to bind spidev to the
> > > device?
> 
> > I just tried it, and apparently, you can't really use this, since spi
> > devices are created from the device tree (or ACPI) whenever the master
> > registers.
> 
> Can you be more specific as to what the issue is here?  If we actually
> have a specific kernel driver for a device I would strongly expect that
> we would want to use it and not spidev, if we don't have one I don't see
> the issue.
>
> > It doesn't really work either for a device that would be bound to a
> > driver, that you unbind, and then try to bind to spidev instead. It
> > looks like the device is released whenever you unbind it, so you can't
> > really use it afterwards.
> 
> I guess this is the issue...  what exactly is the use case here?  I
> would only expect spidev to be used if there is no in kernel driver for
> a device.

The issue and use case is this: we don't have an upstreamable way to
use spidev.

You suggested a while back to add the compatibles of devices we would
want to drive with spidev in the spidev compatible list. It's fine for
devices where we should have a driver, but don't, or devices that will
never ever be handled by the kernel.

But it actually doesn't work in a case where you can't really predict
what is on the other side of the bus. Either because, on the board
you're using the pins are exposed and it's pretty much up to the user
to know what to put on it. That could be handled by DT overlays
though.

What never works is where the device on the other side is so generic
that you really can't tell what it does. Think of a microcontroller
that would behave as a SPI slave. It's behaviour and what it does is
pretty much dependant of what we flashed on it, and suddenly the
compatible string is not the proper reprensentation anymore.

i2c-dev works great in these cases, because you always have access to
all the bus, and all the devices, except if the device is already used
by someone. The patch I suggested is an attempt to mimic this.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Geert Uytterhoeven]

Hi Maxime,

On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> But it actually doesn't work in a case where you can't really predict
> what is on the other side of the bus. Either because, on the board
> you're using the pins are exposed and it's pretty much up to the user
> to know what to put on it. That could be handled by DT overlays
> though.
>
> What never works is where the device on the other side is so generic
> that you really can't tell what it does. Think of a microcontroller
> that would behave as a SPI slave. It's behaviour and what it does is
> pretty much dependant of what we flashed on it, and suddenly the
> compatible string is not the proper reprensentation anymore.

So you will (hopefully soon) use overlay DT to change the DTS to match what's
connected?

And then you want spidev to bind to it. Would it help if DT offered a feature
to add a compatible entry to a driver at runtime, cfr.
/sys/bus/pci/drivers/.../new_id on PCI?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:

> And then you want spidev to bind to it. Would it help if DT offered a feature
> to add a compatible entry to a driver at runtime, cfr.
> /sys/bus/pci/drivers/.../new_id on PCI?

Yes, that's what I'd been under the impression that the bind file did -
allowed modification of the list of devices to bind.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Hi Geert

On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > But it actually doesn't work in a case where you can't really predict
> > what is on the other side of the bus. Either because, on the board
> > you're using the pins are exposed and it's pretty much up to the user
> > to know what to put on it. That could be handled by DT overlays
> > though.
> >
> > What never works is where the device on the other side is so generic
> > that you really can't tell what it does. Think of a microcontroller
> > that would behave as a SPI slave. It's behaviour and what it does is
> > pretty much dependant of what we flashed on it, and suddenly the
> > compatible string is not the proper reprensentation anymore.
> 
> So you will (hopefully soon) use overlay DT to change the DTS to match what's
> connected?

Not really, because you can't declare a spidev device in the DT.

> And then you want spidev to bind to it. Would it help if DT offered a feature
> to add a compatible entry to a driver at runtime, cfr.
> /sys/bus/pci/drivers/.../new_id on PCI?

The thing is, in the core SPI bus, devices are only instiated (in the
DT case), by parsing the DT. So, to bind a device to a new driver, it
has to exist in the first place, and it won't exist, because there
won't be any node in the DT for this device. But since DT is
unsuitable for such a device, you go back to where we were initially.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Geert Uytterhoeven]

Hi Maxime,

On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
>> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > But it actually doesn't work in a case where you can't really predict
>> > what is on the other side of the bus. Either because, on the board
>> > you're using the pins are exposed and it's pretty much up to the user
>> > to know what to put on it. That could be handled by DT overlays
>> > though.
>> >
>> > What never works is where the device on the other side is so generic
>> > that you really can't tell what it does. Think of a microcontroller
>> > that would behave as a SPI slave. It's behaviour and what it does is
>> > pretty much dependant of what we flashed on it, and suddenly the
>> > compatible string is not the proper reprensentation anymore.
>>
>> So you will (hopefully soon) use overlay DT to change the DTS to match what's
>> connected?
>
> Not really, because you can't declare a spidev device in the DT.

Yes you can. I've done it before.

See also "git grep -w spidev -- arch/arm/*/dts/".

>> And then you want spidev to bind to it. Would it help if DT offered a feature
>> to add a compatible entry to a driver at runtime, cfr.
>> /sys/bus/pci/drivers/.../new_id on PCI?
>
> The thing is, in the core SPI bus, devices are only instiated (in the
> DT case), by parsing the DT. So, to bind a device to a new driver, it
> has to exist in the first place, and it won't exist, because there
> won't be any node in the DT for this device. But since DT is
> unsuitable for such a device, you go back to where we were initially.

So you add a node in the overlay DT? Or what am I missing?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] spi: Force the registration of the spidev devices

[Alexandre Belloni]

On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
> Hi Maxime,
> 
> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
> >> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > But it actually doesn't work in a case where you can't really predict
> >> > what is on the other side of the bus. Either because, on the board
> >> > you're using the pins are exposed and it's pretty much up to the user
> >> > to know what to put on it. That could be handled by DT overlays
> >> > though.
> >> >
> >> > What never works is where the device on the other side is so generic
> >> > that you really can't tell what it does. Think of a microcontroller
> >> > that would behave as a SPI slave. It's behaviour and what it does is
> >> > pretty much dependant of what we flashed on it, and suddenly the
> >> > compatible string is not the proper reprensentation anymore.
> >>
> >> So you will (hopefully soon) use overlay DT to change the DTS to match what's
> >> connected?
> >
> > Not really, because you can't declare a spidev device in the DT.
> 
> Yes you can. I've done it before.
> 
> See also "git grep -w spidev -- arch/arm/*/dts/".
> 

I'm pretty sure that doesn't work as there is no compatible matching
"spidev"

My guess would be that you added it in spidev.c

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] spi: Force the registration of the spidev devices

[Geert Uytterhoeven]

Hi Alexandre,

On Mon, May 5, 2014 at 3:57 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
>> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
>> >> <maxime.ripard@free-electrons.com> wrote:
>> >> > But it actually doesn't work in a case where you can't really predict
>> >> > what is on the other side of the bus. Either because, on the board
>> >> > you're using the pins are exposed and it's pretty much up to the user
>> >> > to know what to put on it. That could be handled by DT overlays
>> >> > though.
>> >> >
>> >> > What never works is where the device on the other side is so generic
>> >> > that you really can't tell what it does. Think of a microcontroller
>> >> > that would behave as a SPI slave. It's behaviour and what it does is
>> >> > pretty much dependant of what we flashed on it, and suddenly the
>> >> > compatible string is not the proper reprensentation anymore.
>> >>
>> >> So you will (hopefully soon) use overlay DT to change the DTS to match what's
>> >> connected?
>> >
>> > Not really, because you can't declare a spidev device in the DT.
>>
>> Yes you can. I've done it before.
>>
>> See also "git grep -w spidev -- arch/arm/*/dts/".
>
> I'm pretty sure that doesn't work as there is no compatible matching
> "spidev"

See the last line of spi_match_device():

        return strcmp(spi->modalias, drv->name) == 0;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Mon, May 05, 2014 at 09:10:43AM +0200, Geert Uytterhoeven wrote:
> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard

> > Not really, because you can't declare a spidev device in the DT.

> Yes you can. I've done it before.

> See also "git grep -w spidev -- arch/arm/*/dts/".

It is technically possible but it is a bad idea that should not get past
review - it's putting a specific bit of Linux implementation detail
about how we want to to control the relevant device at this specific
time into the DT.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

On Thu, May 01, 2014 at 03:36:29PM -0700, Maxime Ripard wrote:

> But it actually doesn't work in a case where you can't really predict
> what is on the other side of the bus. Either because, on the board
> you're using the pins are exposed and it's pretty much up to the user
> to know what to put on it. That could be handled by DT overlays
> though.

Right, that's a completely unrelated issue.

> What never works is where the device on the other side is so generic
> that you really can't tell what it does. Think of a microcontroller
> that would behave as a SPI slave. It's behaviour and what it does is
> pretty much dependant of what we flashed on it, and suddenly the
> compatible string is not the proper reprensentation anymore.

That sounds like another situation for overlays, really the thing that's
compatible here is going to be the whole assembly rather than just the
device in isolation (or you're in a similar situation to the one you're
in with FPGAs where you have a driver implementing an application like a
loadeer

> i2c-dev works great in these cases, because you always have access to
> all the bus, and all the devices, except if the device is already used
> by someone. The patch I suggested is an attempt to mimic this.

It seems better to implement something like this at the device model
level, provide a way to have a default UIO driver for anything on a
given bus.  I don't see anything bus specific apart from saying what the
default driver to use is and it avoids the icky code fiddling about with
what devices are bound and the races that might be involved duplicated
in individual buses.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > i2c-dev works great in these cases, because you always have access to
> > all the bus, and all the devices, except if the device is already used
> > by someone. The patch I suggested is an attempt to mimic this.
> 
> It seems better to implement something like this at the device model
> level, provide a way to have a default UIO driver for anything on a
> given bus.  I don't see anything bus specific apart from saying what the
> default driver to use is and it avoids the icky code fiddling about with
> what devices are bound and the races that might be involved duplicated
> in individual buses.

Hmmm, yes, that's probably a great long-term way of dealing with this,
but I don't see it happening soon.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
> On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > > i2c-dev works great in these cases, because you always have access to
> > > all the bus, and all the devices, except if the device is already used
> > > by someone. The patch I suggested is an attempt to mimic this.

> > It seems better to implement something like this at the device model
> > level, provide a way to have a default UIO driver for anything on a
> > given bus.  I don't see anything bus specific apart from saying what the
> > default driver to use is and it avoids the icky code fiddling about with
> > what devices are bound and the races that might be involved duplicated
> > in individual buses.

> Hmmm, yes, that's probably a great long-term way of dealing with this,
> but I don't see it happening soon.

Isn't the code in the patch that started this thread roughly what's
needed, just done in a SPI specific way instead of a generic way?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Mon, May 05, 2014 at 12:17:23PM -0700, Mark Brown wrote:
> On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
> > On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > > > i2c-dev works great in these cases, because you always have access to
> > > > all the bus, and all the devices, except if the device is already used
> > > > by someone. The patch I suggested is an attempt to mimic this.
> 
> > > It seems better to implement something like this at the device model
> > > level, provide a way to have a default UIO driver for anything on a
> > > given bus.  I don't see anything bus specific apart from saying what the
> > > default driver to use is and it avoids the icky code fiddling about with
> > > what devices are bound and the races that might be involved duplicated
> > > in individual buses.
> 
> > Hmmm, yes, that's probably a great long-term way of dealing with this,
> > but I don't see it happening soon.
> 
> Isn't the code in the patch that started this thread roughly what's
> needed, just done in a SPI specific way instead of a generic way?

Hmmm, I think I get your point now. Yes, we could do it. Let me find
some time to actually write something :)

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

spidev device registration has always been a controversial subject since the
move to DT.

Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.

While this is nicer than the DT solution because of its accurate hardware
representation, it's still not perfect because you might not have access to the
DT, or you might be driving a completely generic device (such as a
microcontroller) that might be used for something else in a different
context/board.

Solve this by registering automatically spidev devices for all the unused chip
selects when a master registers itself against the spi core.

This also adds an i2cdev-like feeling, where you get all the spidev devices all
the time, without any modification.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/spi/spi.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d5d7d2235163..e6ca46e1e0fc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1384,6 +1384,52 @@ static void acpi_register_spi_devices(struct spi_master *master)
 static inline void acpi_register_spi_devices(struct spi_master *master) {}
 #endif /* CONFIG_ACPI */
 
+#ifdef CONFIG_SPI_SPIDEV
+static void spidev_register_devices(struct spi_master *master)
+{
+	struct spi_device *spi;
+	int i, status;
+
+	for (i = 0; i < master->num_chipselect; i++) {
+		spi = spi_alloc_device(master);
+		if (!spi) {
+			dev_err(&master->dev, "Couldn't allocate spidev device\n");
+			continue;
+		}
+
+		spi->chip_select = i;
+		strlcpy(spi->modalias, "spidev", sizeof(spi->modalias));
+
+		/*
+		 * This is far from perfect since an addition might be
+		 * done between here and the call to spi_add_device,
+		 * but we can't hold the lock and call spi_add_device
+		 * either, as it would trigger a deadlock.
+		 *
+		 * If such a race occurs, spi_add_device will still
+		 * catch it though, as it also checks for devices
+		 * being registered several times on the same chip
+		 * select.
+		*/
+		status = bus_for_each_dev(&spi_bus_type, NULL, spi,
+					  spi_dev_check);
+		if (status) {
+			dev_dbg(&master->dev, "Chipselect already in use.. Skipping.");
+			spi_dev_put(spi);
+			continue;
+		}
+
+		if (spi_add_device(spi)) {
+			dev_err(&master->dev, "Couldn't add spidev device\n");
+			spi_dev_put(spi);
+		}
+	}
+
+}
+#else
+static inline void spidev_register_devices(struct spi_master *master) {}
+#endif /* CONFIG_SPI_SPIDEV */
+
 static void spi_master_release(struct device *dev)
 {
 	struct spi_master *master;
@@ -1575,6 +1621,7 @@ int spi_register_master(struct spi_master *master)
 	/* Register devices from the device tree and ACPI */
 	of_register_spi_devices(master);
 	acpi_register_spi_devices(master);
+	spidev_register_devices(master);
 done:
 	return status;
 }
-- 
2.4.0

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:

> While this is nicer than the DT solution because of its accurate hardware
> representation, it's still not perfect because you might not have access to the
> DT, or you might be driving a completely generic device (such as a
> microcontroller) that might be used for something else in a different
> context/board.

Greg, you're copied on this because this seems to be a generic problem
that should perhaps be solved at a driver model level - having a way to
bind userspace access to devices that we don't otherwise have a driver
for.  The subsystem could specify the UIO driver to use when no other
driver is available.

> Solve this by registering automatically spidev devices for all the unused chip
> selects when a master registers itself against the spi core.

So, aside from the concern about this being generic the other thing here
is that we often have devices offering more chip selects than can
physically be used in a system but not doing anything to ensure that the
invalid ones can't be used.  It's unclear to me if that's OK or not, it
might be since it's root only I think but I need to think it through a
bit.

> This also adds an i2cdev-like feeling, where you get all the spidev devices all
> the time, without any modification.

I2C is a bit safer here here since it's a shared bus so you can't do
anything to devices not connected to the bus by mistake.

> +		/*
> +		 * This is far from perfect since an addition might be
> +		 * done between here and the call to spi_add_device,
> +		 * but we can't hold the lock and call spi_add_device
> +		 * either, as it would trigger a deadlock.
> +		 *
> +		 * If such a race occurs, spi_add_device will still
> +		 * catch it though, as it also checks for devices
> +		 * being registered several times on the same chip
> +		 * select.
> +		*/
> +		status = bus_for_each_dev(&spi_bus_type, NULL, spi,
> +					  spi_dev_check);
> +		if (status) {
> +			dev_dbg(&master->dev, "Chipselect already in use.. Skipping.");
> +			spi_dev_put(spi);
> +			continue;
> +		}

This still leaves us in the situation where if we do know the device
that is connected we have to explicitly bind it in spidev which is
apparently unreasonably difficult for people.  I'm also concerned about
the interactions with DT overlays here - what happens if a DT overlay
or other dynamic hardware instantiation comes along later and does bind
something to this chip select?  It seems like we should be able to
combine the two models, and the fact that we only create these devices
with a Kconfig option is a bit of an interesting thing here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Michal Suchanek]

On 13 May 2015 at 13:26, Mark Brown <broonie@kernel.org> wrote:
> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>
>> While this is nicer than the DT solution because of its accurate hardware
>> representation, it's still not perfect because you might not have access to the
>> DT, or you might be driving a completely generic device (such as a
>> microcontroller) that might be used for something else in a different
>> context/board.
>
> Greg, you're copied on this because this seems to be a generic problem
> that should perhaps be solved at a driver model level - having a way to
> bind userspace access to devices that we don't otherwise have a driver
> for.  The subsystem could specify the UIO driver to use when no other
> driver is available.
>
>> Solve this by registering automatically spidev devices for all the unused chip
>> selects when a master registers itself against the spi core.
>
> So, aside from the concern about this being generic the other thing here
> is that we often have devices offering more chip selects than can
> physically be used in a system but not doing anything to ensure that the
> invalid ones can't be used.  It's unclear to me if that's OK or not, it
> might be since it's root only I think but I need to think it through a
> bit.

Presumably you could add dt nodes for the chipselects and specify they
are disabled but it does not work for me currently.

This is mostly a cosmetic issue. The chipselects were always there but
now they are visible. Unlike the case when you explicitly bind spidev
using dt node the unusable chipselects are also bound.

>
>> This also adds an i2cdev-like feeling, where you get all the spidev devices all
>> the time, without any modification.
>
> I2C is a bit safer here here since it's a shared bus so you can't do
> anything to devices not connected to the bus by mistake.

This is quite safe too. Unless the device chipselect is activated the
device should ignore whatever you write on the bus - unless you get
the chipselect polarity wrong.

But you can get i2c address and lots of other things wrong too.

>
>> +             /*
>> +              * This is far from perfect since an addition might be
>> +              * done between here and the call to spi_add_device,
>> +              * but we can't hold the lock and call spi_add_device
>> +              * either, as it would trigger a deadlock.
>> +              *
>> +              * If such a race occurs, spi_add_device will still
>> +              * catch it though, as it also checks for devices
>> +              * being registered several times on the same chip
>> +              * select.
>> +             */
>> +             status = bus_for_each_dev(&spi_bus_type, NULL, spi,
>> +                                       spi_dev_check);
>> +             if (status) {
>> +                     dev_dbg(&master->dev, "Chipselect already in use.. Skipping.");
>> +                     spi_dev_put(spi);
>> +                     continue;
>> +             }
>
> This still leaves us in the situation where if we do know the device
> that is connected we have to explicitly bind it in spidev which is
> apparently unreasonably difficult for people.  I'm also concerned about
> the interactions with DT overlays here - what happens if a DT overlay
> or other dynamic hardware instantiation comes along later and does bind
> something to this chip select?  It seems like we should be able to
> combine the two models, and the fact that we only create these devices
> with a Kconfig option is a bit of an interesting thing here.

It does not bind anything because the chiselect is busy. That's why I
use a patch which disregards spidev when determining if a chiselect is
busy. That has the problem that you can access devices in use by
kernel using spidev then. Ideally spidev (as checked by module alias
or whatever) would be unbound when other driver requests the
chipselect and rebound when the driver quits.

Thanks

Michal

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3552 bytes --]

On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > Solve this by registering automatically spidev devices for all the unused chip
> > selects when a master registers itself against the spi core.
> 
> So, aside from the concern about this being generic the other thing here
> is that we often have devices offering more chip selects than can
> physically be used in a system but not doing anything to ensure that the
> invalid ones can't be used.  It's unclear to me if that's OK or not, it
> might be since it's root only I think but I need to think it through a
> bit.

I might plead guilty here... :)

I'd say we're also ok because if we delegate the device driving logic
to userspace, we should expect it to know what it does to first drive
the device properly, but also to open the right device for this.

What's the worst that could happen in such a case? The data are output
without any chipselect line being driven by the controller? Isn't that
supposed to be ignored by the devices?

> > This also adds an i2cdev-like feeling, where you get all the
> > spidev devices all the time, without any modification.
> 
> I2C is a bit safer here since it's a shared bus so you can't do
> anything to devices not connected to the bus by mistake.

I'm not sure to understand what you mean here. How is SPI different
from that aspect?

> > +		/*
> > +		 * This is far from perfect since an addition might be
> > +		 * done between here and the call to spi_add_device,
> > +		 * but we can't hold the lock and call spi_add_device
> > +		 * either, as it would trigger a deadlock.
> > +		 *
> > +		 * If such a race occurs, spi_add_device will still
> > +		 * catch it though, as it also checks for devices
> > +		 * being registered several times on the same chip
> > +		 * select.
> > +		*/
> > +		status = bus_for_each_dev(&spi_bus_type, NULL, spi,
> > +					  spi_dev_check);
> > +		if (status) {
> > +			dev_dbg(&master->dev, "Chipselect already in use.. Skipping.");
> > +			spi_dev_put(spi);
> > +			continue;
> > +		}
> 
> This still leaves us in the situation where if we do know the device
> that is connected we have to explicitly bind it in spidev which is
> apparently unreasonably difficult for people.

You can still do that, but the point is that you don't have to.

If you know what device you have, and want to use spidev on that
device, it will still work, since it will create an spidev device when
we will parse the DT.

That device will then be skipped by that logic, which is ok.

However, if you don't specify anything in your DT, and have no device
created because you don't really know what's on the other end, this
logic will create the spidev device so that you'll still get an spidev
node exported to the userspace.

> I'm also concerned about the interactions with DT overlays here -
> what happens if a DT overlay or other dynamic hardware instantiation
> comes along later and does bind something to this chip select?  It
> seems like we should be able to combine the two models, and the fact
> that we only create these devices with a Kconfig option is a bit of
> an interesting thing here.

I think the safe approach would be, just like I told in this thread,
to just check whether the modalias is spidev. If it is, destroy the
previous (spidev) device, create a new device as specified by the DT,
you're done.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:

> I'd say we're also ok because if we delegate the device driving logic
> to userspace, we should expect it to know what it does to first drive
> the device properly, but also to open the right device for this.

> What's the worst that could happen in such a case? The data are output
> without any chipselect line being driven by the controller? Isn't that
> supposed to be ignored by the devices?

I'm more worried about the chip select line being connected to the
"make the board catch fire" signal or whatever (more realistically
causing us to drive against some other external component) if the extra
chip selects weren't pinmuxed away.

> > > This also adds an i2cdev-like feeling, where you get all the
> > > spidev devices all the time, without any modification.

> > I2C is a bit safer here since it's a shared bus so you can't do
> > anything to devices not connected to the bus by mistake.

> I'm not sure to understand what you mean here. How is SPI different
> from that aspect?

Chip select signals.

> > This still leaves us in the situation where if we do know the device
> > that is connected we have to explicitly bind it in spidev which is
> > apparently unreasonably difficult for people.

> You can still do that, but the point is that you don't have to.

Right, but that's not what I'd expect to happen (and seems to make it
easier for people to not list things in the DT at all which doesn't seem
great).  If we're going to make it available by default I'd expect to be
able to use a userspace driver with anything that doesn't have a driver
bound rather than with devices that explicitly don't have any
identification.

> > I'm also concerned about the interactions with DT overlays here -
> > what happens if a DT overlay or other dynamic hardware instantiation
> > comes along later and does bind something to this chip select?  It
> > seems like we should be able to combine the two models, and the fact
> > that we only create these devices with a Kconfig option is a bit of
> > an interesting thing here.

> I think the safe approach would be, just like I told in this thread,
> to just check whether the modalias is spidev. If it is, destroy the
> previous (spidev) device, create a new device as specified by the DT,
> you're done.

Sure, but I don't see code for that here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Michal Suchanek]

On 13 May 2015 at 16:36, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
>
>> I'd say we're also ok because if we delegate the device driving logic
>> to userspace, we should expect it to know what it does to first drive
>> the device properly, but also to open the right device for this.
>
>> What's the worst that could happen in such a case? The data are output
>> without any chipselect line being driven by the controller? Isn't that
>> supposed to be ignored by the devices?
>
> I'm more worried about the chip select line being connected to the
> "make the board catch fire" signal or whatever (more realistically
> causing us to drive against some other external component) if the extra
> chip selects weren't pinmuxed away.

They would not be pinmuxed away if

1) they are unused by anything else and cs happens to be the default
2) they are used by a device not in DT

right?

For the latter case we might want some way to disable unused
chipselects as well as for the cosmetic issue of multitude of useless
devices popping up.

But you know, unused i2c bus can be also connected to "make the board
catch fire" trace and nobody would notice until somebody has the great
idea to probe it. Incidentally, both i2c and spi cs are active-low
iirc.

>> > This still leaves us in the situation where if we do know the device
>> > that is connected we have to explicitly bind it in spidev which is
>> > apparently unreasonably difficult for people.
>
>> You can still do that, but the point is that you don't have to.
>
> Right, but that's not what I'd expect to happen (and seems to make it
> easier for people to not list things in the DT at all which doesn't seem
> great).  If we're going to make it available by default I'd expect to be
> able to use a userspace driver with anything that doesn't have a driver
> bound rather than with devices that explicitly don't have any
> identification.

Remember that spidev can and is used for boards which have spi
*CONNECTOR* to which you can connect some random gadget and use a
userspace program to communicate with it.

It is cool that you can load a dt overlay if the gadget happens to
have a kernel driver.

However, what identification do you write in the dt when there is no
need to use a kernel driver at all?

The option to create a node with 'spidev' compatible was rejected as broken.

The option to add new compatible to the spidev driver every time you
want to connect a new device was rejected as absurdly complex for end
users who have a board with system already preinstalled because it
requires adding the compatible in the spidev source and rebuilding the
kernel.

So this patch implements another option which is to bind spidev
*always*. The configuration of the port is then not recorded in the DT
and it's up to the user to visually check the port or apply other
relevant heuristic and run the correct userspace application.

Thanks

Michal

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

On Wed, May 13, 2015 at 05:31:05PM +0200, Michal Suchanek wrote:

> But you know, unused i2c bus can be also connected to "make the board
> catch fire" trace and nobody would notice until somebody has the great
> idea to probe it. Incidentally, both i2c and spi cs are active-low
> iirc.

Someone would need to go and explicitly mark an I2C controller as
enabled on a board for that to happen.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]

On Wed, May 13, 2015 at 03:36:10PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
> 
> > I'd say we're also ok because if we delegate the device driving logic
> > to userspace, we should expect it to know what it does to first drive
> > the device properly, but also to open the right device for this.
> 
> > What's the worst that could happen in such a case? The data are output
> > without any chipselect line being driven by the controller? Isn't that
> > supposed to be ignored by the devices?
> 
> I'm more worried about the chip select line being connected to the
> "make the board catch fire" signal or whatever (more realistically
> causing us to drive against some other external component) if the extra
> chip selects weren't pinmuxed away.

It seems we've had this discussion at lot lately ;)

That indeed might be problematic....

> > > > This also adds an i2cdev-like feeling, where you get all the
> > > > spidev devices all the time, without any modification.
> 
> > > I2C is a bit safer here since it's a shared bus so you can't do
> > > anything to devices not connected to the bus by mistake.
> 
> > I'm not sure to understand what you mean here. How is SPI different
> > from that aspect?
> 
> Chip select signals.

Well, if it's not connected to the bus, it probably won't be connected
to the chip select either, will it?

> > > This still leaves us in the situation where if we do know the device
> > > that is connected we have to explicitly bind it in spidev which is
> > > apparently unreasonably difficult for people.
> 
> > You can still do that, but the point is that you don't have to.
> 
> Right, but that's not what I'd expect to happen (and seems to make it
> easier for people to not list things in the DT at all which doesn't seem
> great).  If we're going to make it available by default I'd expect to be
> able to use a userspace driver with anything that doesn't have a driver
> bound rather than with devices that explicitly don't have any
> identification.

The point is that if we don't have anything declared in the DT, we
won't even have a device. So we can't really expect that the device
will not be bound to a driver, because it won't even be there in the
first place.

> > > I'm also concerned about the interactions with DT overlays here -
> > > what happens if a DT overlay or other dynamic hardware instantiation
> > > comes along later and does bind something to this chip select?  It
> > > seems like we should be able to combine the two models, and the fact
> > > that we only create these devices with a Kconfig option is a bit of
> > > an interesting thing here.
> 
> > I think the safe approach would be, just like I told in this thread,
> > to just check whether the modalias is spidev. If it is, destroy the
> > previous (spidev) device, create a new device as specified by the DT,
> > you're done.
> 
> Sure, but I don't see code for that here.

No, of course. Remember that this code was written before the overlays
were posted.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Geert Uytterhoeven]

On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>> > This also adds an i2cdev-like feeling, where you get all the
>> > spidev devices all the time, without any modification.
>>
>> I2C is a bit safer here since it's a shared bus so you can't do
>> anything to devices not connected to the bus by mistake.
>
> I'm not sure to understand what you mean here. How is SPI different
> from that aspect?

If you talk to a nonexistent i2c device, nothing happens, as it just sends
a message with a nonexistent address on the shared bus.

If you talk to a nonexistent spi device, hell may break loose if e.g. some
"smart" hardware engineer used the "unused" CS as a pull-up for the
_RESET line on an external device... It's a bit like banging random
"unused" GPIOs.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Wed, May 13, 2015 at 09:10:48PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> >> > This also adds an i2cdev-like feeling, where you get all the
> >> > spidev devices all the time, without any modification.
> >>
> >> I2C is a bit safer here since it's a shared bus so you can't do
> >> anything to devices not connected to the bus by mistake.
> >
> > I'm not sure to understand what you mean here. How is SPI different
> > from that aspect?
> 
> If you talk to a nonexistent i2c device, nothing happens, as it just sends
> a message with a nonexistent address on the shared bus.
> 
> If you talk to a nonexistent spi device, hell may break loose if e.g. some
> "smart" hardware engineer used the "unused" CS as a pull-up for the
> _RESET line on an external device... It's a bit like banging random
> "unused" GPIOs.

Ah, right. I'm always surprised by how creative the hardware engineers
actually are :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> 
> > While this is nicer than the DT solution because of its accurate hardware
> > representation, it's still not perfect because you might not have access to the
> > DT, or you might be driving a completely generic device (such as a
> > microcontroller) that might be used for something else in a different
> > context/board.
> 
> Greg, you're copied on this because this seems to be a generic problem
> that should perhaps be solved at a driver model level - having a way to
> bind userspace access to devices that we don't otherwise have a driver
> for.  The subsystem could specify the UIO driver to use when no other
> driver is available.

That doesn't really work.  I've been talking to the ACPI people about
this, and the problem is "don't otherwise have a driver for" is an
impossible thing to prove, as you never know when a driver is going to
be loaded from userspace.

You can easily bind drivers to devices today from userspace, why not
just use the built-in functionality you have today if you "know" that
there is no driver for this hardware.

thanks,

greg k-h

Re: [PATCH] spi: Force the registration of the spidev devices

[Michal Suchanek]

On 13 May 2015 at 17:37, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
>> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>>
>> > While this is nicer than the DT solution because of its accurate hardware
>> > representation, it's still not perfect because you might not have access to the
>> > DT, or you might be driving a completely generic device (such as a
>> > microcontroller) that might be used for something else in a different
>> > context/board.
>>
>> Greg, you're copied on this because this seems to be a generic problem
>> that should perhaps be solved at a driver model level - having a way to
>> bind userspace access to devices that we don't otherwise have a driver
>> for.  The subsystem could specify the UIO driver to use when no other
>> driver is available.
>
> That doesn't really work.  I've been talking to the ACPI people about
> this, and the problem is "don't otherwise have a driver for" is an
> impossible thing to prove, as you never know when a driver is going to
> be loaded from userspace.

Yes, exactly. That's why binding spidev in addition to regular drivers
or have spidev bind always and get unbound when another driver tries
to bind the CS is preferable. The latter is pretty much specifying an
UIO driver to use when no other driver is available in the light of
the fact that 'is available' might change over time. You can prove
that a driver is not available right now.

>
> You can easily bind drivers to devices today from userspace, why not
> just use the built-in functionality you have today if you "know" that
> there is no driver for this hardware.
>

And what exactly do you bind the driver to when there is no device
created with the built-in functionality you have today?

Thanks

Michal

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:

> You can easily bind drivers to devices today from userspace, why not
> just use the built-in functionality you have today if you "know" that
> there is no driver for this hardware.

So, that was my original suggestion too but people were complaining that
this wasn't a generally supported feature and requires specific support
of some kind in the bus (which nobody posted a patch for).  I have to
confess I didn't investigate too deeply myself.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> 
> > You can easily bind drivers to devices today from userspace, why not
> > just use the built-in functionality you have today if you "know" that
> > there is no driver for this hardware.
> 
> So, that was my original suggestion too but people were complaining that
> this wasn't a generally supported feature and requires specific support
> of some kind in the bus (which nobody posted a patch for).

I don't understand the complaint, it's a very "generally supported
feature" and has been there for a very long time for any bus that wants
to use it.

greg k-h

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:

> > So, that was my original suggestion too but people were complaining that
> > this wasn't a generally supported feature and requires specific support
> > of some kind in the bus (which nobody posted a patch for).

> I don't understand the complaint, it's a very "generally supported
> feature" and has been there for a very long time for any bus that wants
> to use it.

So it's not something that just works for all buses and someone would
need to write a patch (hint, hint - that's one of the big blockers
here)?  It is a bit surprising to me that this would be something that
the buses would need to cope with individually since for most things the
matching mechanics are taken care of in the driver core and we're
explicitly overriding them here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 06:39:22PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
> 
> > > So, that was my original suggestion too but people were complaining that
> > > this wasn't a generally supported feature and requires specific support
> > > of some kind in the bus (which nobody posted a patch for).
> 
> > I don't understand the complaint, it's a very "generally supported
> > feature" and has been there for a very long time for any bus that wants
> > to use it.
> 
> So it's not something that just works for all buses and someone would
> need to write a patch (hint, hint - that's one of the big blockers
> here)?  It is a bit surprising to me that this would be something that
> the buses would need to cope with individually since for most things the
> matching mechanics are taken care of in the driver core and we're
> explicitly overriding them here.

It should "just work" for all busses, but if you want to add a "new_id"
sysfs file, you need to add the logic for that to your bus.  It's the
bind/unbind files in the driver directories.

greg k-h

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:

> It should "just work" for all busses, but if you want to add a "new_id"
> sysfs file, you need to add the logic for that to your bus.  It's the
> bind/unbind files in the driver directories.

Oh, right.  For this to be useful here we'd need to implement a new_id
file, bind and unbind don't do anything helpful here.  I think I'd have
expected this to have a default implementation that non-enumerable buses
could pick up.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:
> 
> > It should "just work" for all busses, but if you want to add a "new_id"
> > sysfs file, you need to add the logic for that to your bus.  It's the
> > bind/unbind files in the driver directories.
> 
> Oh, right.  For this to be useful here we'd need to implement a new_id
> file, bind and unbind don't do anything helpful here.  I think I'd have
> expected this to have a default implementation that non-enumerable buses
> could pick up.

No one has ever asked for that, so feel free to make a patch that adds
it :)

thanks,

greg k-h

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:

> > Oh, right.  For this to be useful here we'd need to implement a new_id
> > file, bind and unbind don't do anything helpful here.  I think I'd have
> > expected this to have a default implementation that non-enumerable buses
> > could pick up.

> No one has ever asked for that, so feel free to make a patch that adds
> it :)

Maxime?  :P

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Wed, May 13, 2015 at 07:51:49PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
> 
> > > Oh, right.  For this to be useful here we'd need to implement a new_id
> > > file, bind and unbind don't do anything helpful here.  I think I'd have
> > > expected this to have a default implementation that non-enumerable buses
> > > could pick up.
> 
> > No one has ever asked for that, so feel free to make a patch that adds
> > it :)
> 
> Maxime?  :P

I can try to give it a shot.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

Hi Greg,

On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > 
> > > While this is nicer than the DT solution because of its accurate hardware
> > > representation, it's still not perfect because you might not have access to the
> > > DT, or you might be driving a completely generic device (such as a
> > > microcontroller) that might be used for something else in a different
> > > context/board.
> > 
> > Greg, you're copied on this because this seems to be a generic problem
> > that should perhaps be solved at a driver model level - having a way to
> > bind userspace access to devices that we don't otherwise have a driver
> > for.  The subsystem could specify the UIO driver to use when no other
> > driver is available.
> 
> That doesn't really work.  I've been talking to the ACPI people about
> this, and the problem is "don't otherwise have a driver for" is an
> impossible thing to prove, as you never know when a driver is going to
> be loaded from userspace.
> 
> You can easily bind drivers to devices today from userspace, why not
> just use the built-in functionality you have today if you "know" that
> there is no driver for this hardware.

What we're really after here is that we want to have an spidev
instance when we don't even have a device.

And since SPI isn't really doing any kind of hotplug, the only
situation that might be problematic is if we have the DT overlays
registering new devices.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:

> > That doesn't really work.  I've been talking to the ACPI people about
> > this, and the problem is "don't otherwise have a driver for" is an
> > impossible thing to prove, as you never know when a driver is going to
> > be loaded from userspace.

> > You can easily bind drivers to devices today from userspace, why not
> > just use the built-in functionality you have today if you "know" that
> > there is no driver for this hardware.

> What we're really after here is that we want to have an spidev
> instance when we don't even have a device.

We do?

> And since SPI isn't really doing any kind of hotplug, the only
> situation that might be problematic is if we have the DT overlays
> registering new devices.

Well, we still have the driver loaded from userspace in the future
situation as well - the hardware might be static but the software isn't.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> Hi Greg,
> 
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > > 
> > > > While this is nicer than the DT solution because of its accurate hardware
> > > > representation, it's still not perfect because you might not have access to the
> > > > DT, or you might be driving a completely generic device (such as a
> > > > microcontroller) that might be used for something else in a different
> > > > context/board.
> > > 
> > > Greg, you're copied on this because this seems to be a generic problem
> > > that should perhaps be solved at a driver model level - having a way to
> > > bind userspace access to devices that we don't otherwise have a driver
> > > for.  The subsystem could specify the UIO driver to use when no other
> > > driver is available.
> > 
> > That doesn't really work.  I've been talking to the ACPI people about
> > this, and the problem is "don't otherwise have a driver for" is an
> > impossible thing to prove, as you never know when a driver is going to
> > be loaded from userspace.
> > 
> > You can easily bind drivers to devices today from userspace, why not
> > just use the built-in functionality you have today if you "know" that
> > there is no driver for this hardware.
> 
> What we're really after here is that we want to have an spidev
> instance when we don't even have a device.

That's crazy, just create a device, things do not work without one.

> And since SPI isn't really doing any kind of hotplug, the only
> situation that might be problematic is if we have the DT overlays
> registering new devices.

I have no idea what this all is, sorry, patches would be good if you
want to get your idea across.  Maybe it was sent early in this thread,
but I can't seem to find one...

greg k-h

Re: [PATCH] spi: Force the registration of the spidev devices

[Geert Uytterhoeven]

On Wed, May 13, 2015 at 8:17 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
>> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
>> > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
>> > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>> > >
>> > > > While this is nicer than the DT solution because of its accurate hardware
>> > > > representation, it's still not perfect because you might not have access to the
>> > > > DT, or you might be driving a completely generic device (such as a
>> > > > microcontroller) that might be used for something else in a different
>> > > > context/board.
>> > >
>> > > Greg, you're copied on this because this seems to be a generic problem
>> > > that should perhaps be solved at a driver model level - having a way to
>> > > bind userspace access to devices that we don't otherwise have a driver
>> > > for.  The subsystem could specify the UIO driver to use when no other
>> > > driver is available.
>> >
>> > That doesn't really work.  I've been talking to the ACPI people about
>> > this, and the problem is "don't otherwise have a driver for" is an
>> > impossible thing to prove, as you never know when a driver is going to
>> > be loaded from userspace.
>> >
>> > You can easily bind drivers to devices today from userspace, why not
>> > just use the built-in functionality you have today if you "know" that
>> > there is no driver for this hardware.
>>
>> What we're really after here is that we want to have an spidev
>> instance when we don't even have a device.
>
> That's crazy, just create a device, things do not work without one.

One simple way that works today is to create a device tree overlay with a
device that's compatible with "spidev". That does violate DT policy, as it
doesn't describe the hardware. But it works. This can be done from userspace,
so we (the naggers about incorrect description of the hardware) will never
see the abusive dtso.

Alternatively, you can write some kernel code that does more or less the same
thing, i.e. create a device for "spidev", but without any DT involved.
If you add remove support, and make this controllable through sysfs, I think
this could be a viable solution. It would be similar to gpio export.
A DT overlay with the real device can still take over, if you instruct the
removal of the "spidev" device through sysfs first.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > Hi Greg,
> > 
> > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > > > 
> > > > > While this is nicer than the DT solution because of its accurate hardware
> > > > > representation, it's still not perfect because you might not have access to the
> > > > > DT, or you might be driving a completely generic device (such as a
> > > > > microcontroller) that might be used for something else in a different
> > > > > context/board.
> > > > 
> > > > Greg, you're copied on this because this seems to be a generic problem
> > > > that should perhaps be solved at a driver model level - having a way to
> > > > bind userspace access to devices that we don't otherwise have a driver
> > > > for.  The subsystem could specify the UIO driver to use when no other
> > > > driver is available.
> > > 
> > > That doesn't really work.  I've been talking to the ACPI people about
> > > this, and the problem is "don't otherwise have a driver for" is an
> > > impossible thing to prove, as you never know when a driver is going to
> > > be loaded from userspace.
> > > 
> > > You can easily bind drivers to devices today from userspace, why not
> > > just use the built-in functionality you have today if you "know" that
> > > there is no driver for this hardware.
> > 
> > What we're really after here is that we want to have an spidev
> > instance when we don't even have a device.
> 
> That's crazy, just create a device, things do not work without one.

Our use case is this one: we want to export spidev files so that "dev
boards" with a header that allows to plug virtually anything on it
(Raspberry Pi, Cubieboards, Xplained, and all the likes) without
having to change the kernel and / or device tree.

That would mean that if we plug something to that port, no device will
be created because the DT itself won't have that device declared in
the first place.

This patch is actually doing this: creating a new device for all the
chipselects that are not in use that will be bound to the spidev
driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
> On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > > Hi Greg,
> > > 
> > > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > > > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > > > > 
> > > > > > While this is nicer than the DT solution because of its accurate hardware
> > > > > > representation, it's still not perfect because you might not have access to the
> > > > > > DT, or you might be driving a completely generic device (such as a
> > > > > > microcontroller) that might be used for something else in a different
> > > > > > context/board.
> > > > > 
> > > > > Greg, you're copied on this because this seems to be a generic problem
> > > > > that should perhaps be solved at a driver model level - having a way to
> > > > > bind userspace access to devices that we don't otherwise have a driver
> > > > > for.  The subsystem could specify the UIO driver to use when no other
> > > > > driver is available.
> > > > 
> > > > That doesn't really work.  I've been talking to the ACPI people about
> > > > this, and the problem is "don't otherwise have a driver for" is an
> > > > impossible thing to prove, as you never know when a driver is going to
> > > > be loaded from userspace.
> > > > 
> > > > You can easily bind drivers to devices today from userspace, why not
> > > > just use the built-in functionality you have today if you "know" that
> > > > there is no driver for this hardware.
> > > 
> > > What we're really after here is that we want to have an spidev
> > > instance when we don't even have a device.
> > 
> > That's crazy, just create a device, things do not work without one.
> 
> Our use case is this one: we want to export spidev files so that "dev
> boards" with a header that allows to plug virtually anything on it
> (Raspberry Pi, Cubieboards, Xplained, and all the likes) without
> having to change the kernel and / or device tree.

You want to do that on a bus that is not self-describing or dynamic?
I too want a pony.  Please go kick the hardware engineer who designed
such a mess, we solved this problem 20+ years ago with "real" busses.

> That would mean that if we plug something to that port, no device will
> be created because the DT itself won't have that device declared in
> the first place.

Because you can't dynamically determine that something was plugged in,
of course.

> This patch is actually doing this: creating a new device for all the
> chipselects that are not in use that will be bound to the spidev
> driver.

I have yet to see a patch...

Re: [PATCH] spi: Force the registration of the spidev devices

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:

> > Our use case is this one: we want to export spidev files so that "dev
> > boards" with a header that allows to plug virtually anything on it
> > (Raspberry Pi, Cubieboards, Xplained, and all the likes) without
> > having to change the kernel and / or device tree.

> You want to do that on a bus that is not self-describing or dynamic?
> I too want a pony.  Please go kick the hardware engineer who designed
> such a mess, we solved this problem 20+ years ago with "real" busses.

The hardware engineers for some of these things did build enumeration in
but none of them with any sort of community have been able to make it
stick - the community just ends up ignoring the ID allocation.

> > This patch is actually doing this: creating a new device for all the
> > chipselects that are not in use that will be bound to the spidev
> > driver.

> I have yet to see a patch...

That was the first message in the thread.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]

On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
> > On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > > > Hi Greg,
> > > > 
> > > > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > > > > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > > > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > > > > > 
> > > > > > > While this is nicer than the DT solution because of its accurate hardware
> > > > > > > representation, it's still not perfect because you might not have access to the
> > > > > > > DT, or you might be driving a completely generic device (such as a
> > > > > > > microcontroller) that might be used for something else in a different
> > > > > > > context/board.
> > > > > > 
> > > > > > Greg, you're copied on this because this seems to be a generic problem
> > > > > > that should perhaps be solved at a driver model level - having a way to
> > > > > > bind userspace access to devices that we don't otherwise have a driver
> > > > > > for.  The subsystem could specify the UIO driver to use when no other
> > > > > > driver is available.
> > > > > 
> > > > > That doesn't really work.  I've been talking to the ACPI people about
> > > > > this, and the problem is "don't otherwise have a driver for" is an
> > > > > impossible thing to prove, as you never know when a driver is going to
> > > > > be loaded from userspace.
> > > > > 
> > > > > You can easily bind drivers to devices today from userspace, why not
> > > > > just use the built-in functionality you have today if you "know" that
> > > > > there is no driver for this hardware.
> > > > 
> > > > What we're really after here is that we want to have an spidev
> > > > instance when we don't even have a device.
> > > 
> > > That's crazy, just create a device, things do not work without one.
> > 
> > Our use case is this one: we want to export spidev files so that "dev
> > boards" with a header that allows to plug virtually anything on it
> > (Raspberry Pi, Cubieboards, Xplained, and all the likes) without
> > having to change the kernel and / or device tree.
> 
> You want to do that on a bus that is not self-describing or dynamic?
> I too want a pony.  Please go kick the hardware engineer who designed
> such a mess, we solved this problem 20+ years ago with "real" busses.

Well, we do have such ponies on some bus that don't have any kind of
enumeration. i2cdev allows to do just that already. That would seem
logical to have a similar behaviour for SPI.

> > That would mean that if we plug something to that port, no device will
> > be created because the DT itself won't have that device declared in
> > the first place.
> 
> Because you can't dynamically determine that something was plugged in,
> of course.

Well.. Yeah.

> 
> > This patch is actually doing this: creating a new device for all the
> > chipselects that are not in use that will be bound to the spidev
> > driver.
> 
> I have yet to see a patch...

You were in Cc of that patch, which is the first message in this thread.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] spi: Force the registration of the spidev devices

[Lucas De Marchi]

On Wed, May 13, 2015 at 7:33 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
>> On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
>> > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
>> > > Hi Greg,
>> > >
>> > > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
>> > > > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
>> > > > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>> > > > >
>> > > > > > While this is nicer than the DT solution because of its accurate hardware
>> > > > > > representation, it's still not perfect because you might not have access to the
>> > > > > > DT, or you might be driving a completely generic device (such as a
>> > > > > > microcontroller) that might be used for something else in a different
>> > > > > > context/board.
>> > > > >
>> > > > > Greg, you're copied on this because this seems to be a generic problem
>> > > > > that should perhaps be solved at a driver model level - having a way to
>> > > > > bind userspace access to devices that we don't otherwise have a driver
>> > > > > for.  The subsystem could specify the UIO driver to use when no other
>> > > > > driver is available.
>> > > >
>> > > > That doesn't really work.  I've been talking to the ACPI people about
>> > > > this, and the problem is "don't otherwise have a driver for" is an
>> > > > impossible thing to prove, as you never know when a driver is going to
>> > > > be loaded from userspace.
>> > > >
>> > > > You can easily bind drivers to devices today from userspace, why not
>> > > > just use the built-in functionality you have today if you "know" that
>> > > > there is no driver for this hardware.
>> > >
>> > > What we're really after here is that we want to have an spidev
>> > > instance when we don't even have a device.
>> >
>> > That's crazy, just create a device, things do not work without one.
>>
>> Our use case is this one: we want to export spidev files so that "dev
>> boards" with a header that allows to plug virtually anything on it
>> (Raspberry Pi, Cubieboards, Xplained, and all the likes) without
>> having to change the kernel and / or device tree.
>
> You want to do that on a bus that is not self-describing or dynamic?
> I too want a pony.  Please go kick the hardware engineer who designed
> such a mess, we solved this problem 20+ years ago with "real" busses.

Mind you we are talking about buses created more than 20+ years ago.
(Unfortunately) They are still used today for all kind of sensors.
Boards like RPi, beaglebone, minnowboard expose the pins so we can
actually talk to those sensors, plugging in anyone we'd like to.  For
some of them for example there are IIO drivers that we could use the
driver model to allow binding them. But spidev/i2c-dev allow userspace
to talk directly to them. And you don't know what *others* will plug
into that bus... might even be their own microntrollers with no
identification at all.

Without something like the patch in the first message, people need to
create DT overlays for platforms that support that. ACPI doesn't
support overlays (yet) so we need to keep awful external platform
drivers[1] just to make spidev to work.

-- 
Lucas De Marchi

[1] https://github.com/MinnowBoard/minnow-max-extras/blob/master/modules/low-speed-spidev/low-speed-spidev.c