From: Michal Suchanek <hramrach@gmail.com> To: Mark Brown <broonie@kernel.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Hans de Goede <hdegoede@redhat.com>, linux-spi <linux-spi@vger.kernel.org>, Martin Sperl <kernel@martin.sperl.org> Subject: Re: [PATCH] spi: Force the registration of the spidev devices Date: Wed, 13 May 2015 17:31:05 +0200 [thread overview] Message-ID: <CAOMqctTd7xG6mwX9AojTH4uaGDY06xOgDFUP437VDiE0rp0sXA@mail.gmail.com> (raw) In-Reply-To: <20150513143610.GT2761@sirena.org.uk> 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Suchanek <hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org> Subject: Re: [PATCH] spi: Force the registration of the spidev devices Date: Wed, 13 May 2015 17:31:05 +0200 [thread overview] Message-ID: <CAOMqctTd7xG6mwX9AojTH4uaGDY06xOgDFUP437VDiE0rp0sXA@mail.gmail.com> (raw) In-Reply-To: <20150513143610.GT2761-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> On 13 May 2015 at 16:36, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-05-13 15:31 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-12 20:33 [PATCH] spi: Force the registration of the spidev devices Maxime Ripard 2015-05-12 20:33 ` Maxime Ripard 2015-05-13 9:34 ` [PATCH] spi: Add option to bind spidev to all chipselects Michal Suchanek 2015-05-13 9:34 ` Michal Suchanek 2015-05-13 10:16 ` Maxime Ripard 2015-05-13 10:16 ` Maxime Ripard 2015-05-13 10:40 ` Michal Suchanek 2015-05-13 10:40 ` Michal Suchanek 2015-05-13 11:05 ` Mark Brown 2015-05-13 11:05 ` Mark Brown 2015-05-13 11:26 ` [PATCH] spi: Force the registration of the spidev devices Mark Brown 2015-05-13 11:26 ` Mark Brown 2015-05-13 12:35 ` Michal Suchanek 2015-05-13 12:35 ` Michal Suchanek 2015-05-13 12:51 ` Maxime Ripard 2015-05-13 12:51 ` Maxime Ripard 2015-05-13 14:36 ` Mark Brown 2015-05-13 14:36 ` Mark Brown 2015-05-13 15:31 ` Michal Suchanek [this message] 2015-05-13 15:31 ` Michal Suchanek 2015-05-13 17:43 ` Mark Brown 2015-05-13 17:43 ` Mark Brown 2015-05-13 19:09 ` Maxime Ripard 2015-05-13 19:10 ` Geert Uytterhoeven 2015-05-13 19:10 ` Geert Uytterhoeven 2015-05-13 19:41 ` Maxime Ripard 2015-05-13 19:41 ` Maxime Ripard 2015-05-13 15:37 ` Greg Kroah-Hartman 2015-05-13 15:37 ` Greg Kroah-Hartman 2015-05-13 15:52 ` Michal Suchanek 2015-05-13 15:52 ` Michal Suchanek 2015-05-13 17:13 ` Mark Brown 2015-05-13 17:13 ` Mark Brown 2015-05-13 17:20 ` Greg Kroah-Hartman 2015-05-13 17:20 ` Greg Kroah-Hartman 2015-05-13 17:39 ` Mark Brown 2015-05-13 17:39 ` Mark Brown 2015-05-13 18:16 ` Greg Kroah-Hartman 2015-05-13 18:16 ` Greg Kroah-Hartman 2015-05-13 18:32 ` Mark Brown 2015-05-13 18:36 ` Greg Kroah-Hartman 2015-05-13 18:36 ` Greg Kroah-Hartman 2015-05-13 18:51 ` Mark Brown 2015-05-13 18:51 ` Mark Brown 2015-05-13 19:17 ` Maxime Ripard 2015-05-13 19:17 ` Maxime Ripard 2015-05-13 17:50 ` Maxime Ripard 2015-05-13 17:50 ` Maxime Ripard 2015-05-13 18:12 ` Mark Brown 2015-05-13 18:17 ` Greg Kroah-Hartman 2015-05-13 18:17 ` Greg Kroah-Hartman 2015-05-13 19:23 ` Geert Uytterhoeven 2015-05-13 19:23 ` Geert Uytterhoeven 2015-05-13 19:26 ` Maxime Ripard 2015-05-13 19:26 ` Maxime Ripard 2015-05-13 22:33 ` Greg Kroah-Hartman 2015-05-13 22:33 ` Greg Kroah-Hartman 2015-05-14 14:34 ` Mark Brown 2015-05-14 14:34 ` Mark Brown 2015-05-15 8:09 ` Maxime Ripard 2015-07-15 6:27 ` Lucas De Marchi 2015-07-15 6:27 ` Lucas De Marchi -- strict thread matches above, loose matches on Subject: below -- 2014-04-28 17:22 Maxime Ripard 2014-04-28 17:22 ` Maxime Ripard 2014-04-29 18:37 ` Mark Brown 2014-04-29 18:37 ` Mark Brown [not found] ` <20140429183758.GH15125-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2014-04-29 21:31 ` Martin Sperl [not found] ` <24BF05CB-35FF-42E8-BE5C-A5E4E3D0C52A-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org> 2014-04-30 18:14 ` Maxime Ripard 2014-04-30 20:00 ` Martin Sperl [not found] ` <DA3907EB-0C1B-42FB-B288-9E33F6E24E3E-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org> 2014-04-30 22:19 ` Maxime Ripard 2014-05-01 1:21 ` Mark Brown 2014-04-30 18:06 ` Maxime Ripard 2014-04-30 18:06 ` Maxime Ripard 2014-05-01 1:18 ` Mark Brown 2014-05-01 1:18 ` Mark Brown 2014-05-01 22:36 ` Maxime Ripard 2014-05-01 22:36 ` Maxime Ripard 2014-05-01 23:28 ` Geert Uytterhoeven 2014-05-02 16:55 ` Mark Brown 2014-05-02 16:55 ` Mark Brown 2014-05-05 4:17 ` Maxime Ripard 2014-05-05 7:10 ` Geert Uytterhoeven 2014-05-05 13:57 ` Alexandre Belloni 2014-05-05 13:57 ` Alexandre Belloni 2014-05-05 14:22 ` Geert Uytterhoeven 2014-05-05 14:22 ` Geert Uytterhoeven 2014-05-05 19:16 ` Mark Brown 2014-05-02 17:40 ` Mark Brown 2014-05-02 17:40 ` Mark Brown 2014-05-05 4:21 ` Maxime Ripard 2014-05-05 19:17 ` Mark Brown 2014-05-05 19:17 ` Mark Brown 2014-05-08 2:22 ` Maxime Ripard 2014-05-08 2:22 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOMqctTd7xG6mwX9AojTH4uaGDY06xOgDFUP437VDiE0rp0sXA@mail.gmail.com \ --to=hramrach@gmail.com \ --cc=broonie@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=hdegoede@redhat.com \ --cc=kernel@martin.sperl.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=maxime.ripard@free-electrons.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.