Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752187AbbDZOfI (ORCPT ); Sun, 26 Apr 2015 10:35:08 -0400 Received: from down.free-electrons.com ([37.187.137.238]:35385 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751335AbbDZOfF (ORCPT ); Sun, 26 Apr 2015 10:35:05 -0400 Date: Sun, 26 Apr 2015 16:33:59 +0200 From: Maxime Ripard To: Michal Suchanek Cc: Martin Sperl , Hans de Goede , Mark Brown , linux-sunxi , Jonathan Corbet , linux-spi , linux-doc , Linux Kernel Mailing List Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example. Message-ID: <20150426143359.GI5627@lukather> References: <20150426103257.GJ22845@sirena.org.uk> <20150426110144.GK22845@sirena.org.uk> <553CCABA.3090504@redhat.com> <12F80B18-7418-430E-94F7-5A20C133BA9A@martin.sperl.org> <20150426125113.GF5627@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6lCXDTVICvIQMz0h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6183 Lines: 163 --6lCXDTVICvIQMz0h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 14:51, Maxime Ripard > wrote: > > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > >> On 26 April 2015 at 13:56, Martin Sperl wrot= e: > >> > > >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: > >> >> I think there is actual a use for just binding spidev as spidev, > >> >> think e.g. the spi pins on the raspberry pi. > >> >> > >> >> How do you deal we suggest with such a situation ? > >> > > >> > I actually asked the same question a few days ago on the spi list > >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as =E2= =80=9Cspidev=E2=80=9D) > >> > and the summary was: > >> > > >> > You can still do as before, but you have to accept that long > >> > irritating warning. > >> > > >> > Or you patch spidev.c to include your pattern of choice for compatib= lity > >> > >> So the suggestion is to add a compatible string like olimex,uext-slot > >> to spidev and use that compatible in the DT? > > > > No, you add a compatible for the device that is connected to the bus > > through that slot. >=20 > There is no device connected in the slot by design. The slot is there > for connecting random stuff you find in your mailbox or other drawers > and boxes. I know. Our point is add a compatible for that random device you find in your mailbox. > >> That can certainly be done but adding a new compatible for every board > >> that has some random pins looks like a needless nuisance to me. > >> Especially compared to i2c where you can just open the bus so long as > >> ti is enabled. > >> > >> > > >> > Or you implement the following proposal (which needs a volunteer): > >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven = wrote: > >> >> > >> >> So what you need is a way to handover from generic spidev to a devi= ce-specific > >> >> driver, cfr. what graphics drivers do when the device has been boun= d to by > >> >> vesafb or simplefb. > >> >> > >> >> Could this be implemented in a generic way in the spi or DT code? > >> > > >> > ... > >> >> On 23.04.2015, at 12:36, Mark Brown wrote: > >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> >> > >> >>> I guess this has been suggested before: the spi core could provide= spidev > >> >>> access to all spi client devices which are not bound by a driver? > >> >> > >> >> I don't know if it's been suggested before, certainly nobody did the > >> >> work to make it happen. I don't think I have a massive objection in > >> >> principal. > > > > Actually, I did it a year ago, and it looked at the time that it > > wasn't what should be done either. >=20 > There is nothing like unclaimed device. Either there is a device and > driver for it may in principle be loaded later as a module or the chip > select is reserved for use from userspace. I never said it was perfect. > Userspace driver is valid option and should have the ability to have > the chip select reserved. Whether an userspace driver is a valid option can spawn a whole debate by its own, but it's true that we should be able to have it exported to the userspace. However, having a spidev compatible is not the solution to that problem. > > https://lkml.org/lkml/2014/4/28/612 > > > >> But how do you know there is a device? > >> > >> Devices on i2c can be probed. On spi you just transfer random data and > >> hope it does something useful. Some devices have readable registers > >> and can be probed in a device-specific way but others are write-only. > > > > Well, what's the point of communicating with a non-existent device in > > the first place? >=20 > I have multitude of SPI devices which are not part of the board and > hence its DT and can be connected to the board with jumper wires. >=20 > Most of them don't have a linux driver or compatible to bind with. Then create such a compatible... > >> So binding spidev is in my view just saying that you are going to > >> transfer random data from userspace on this bus. > > > > Yes, to a device connected on that bus. >=20 > Yes, so I have this red rectangular PCB, blue PCB, and red square PCB > and blue very thin rectangular PCB. >=20 > Please enlighten me how to add DT bindings for these and the PCB which > is in the mail and I did not pick up at the post office yet. >=20 > Of course, I have some hope that the chips on the PCBs are at least > somewhat compatible with what I ordered but I cannot be sure until I > test that. Come on, this is pure bad faith. If you don't even know what that device is, how do you even know how to interact with it? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --6lCXDTVICvIQMz0h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVPPdWAAoJEBx+YmzsjxAgcDgP/Rc40SDcA3oqf+qFUVNTPWmK 4PBCA24GEP4JPqPdn0OgY55DiEZuEDZWtdPW2ZUImvOpBS12pj+DQbncV/pjUHUg NdWQd9ZgW5M8KOzs/fnNzZwKD+TZSwLhBYw5MZlG+Wf3pjcB18LQTyXCgPsOpq5g IBc/en1TuJYoFX+GNB0NAiXxoUrW4cDxV4UJIkjr6QjYYNJ21BW+EihZie8+VMro hPCIz49ZjpdvFLaLndrFVpeo6inDjc9zKdMg0NmvJrOlEXEwPeIx29iuqfrmWNJx KP7F1rzmShcfuELCGFwyab7+0zF3JTcIHzUzmg+ry3KErsulxXkTJnq61cRogonf gYneMaQ8LVztsv2o+OC2hOrmDJ6MmJ8EsyMBsamQUFNyGSq5WduACuDcXE075tSa ukjvWjC0XRGA53dC8eRSGDhI7tcH0dMeo3gsClZUhL83yKo6Oi/a6CzyN42ZNzii gvb32vR0GK/vUj1237S2w8WRk5TerXJqBHXWmgbHzMp2DmDOCZH0Iu3tnA13+qs8 jUG0yEvg4bILtQz/MnuHlCZjCjya9zhoLLGZf/tKeLEgjJ9240Neq2xqsxMDZfZw cwk5N4VC9VMOFgHy3kg8YDhyJcPFBL4hnf38HV9hTD70Dy4K9sxiv2dN8D1Ak4Ad 3SVRxhqNMCGekx6FmiA5 =BsEO -----END PGP SIGNATURE----- --6lCXDTVICvIQMz0h-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/