Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753265AbbD0QZc (ORCPT ); Mon, 27 Apr 2015 12:25:32 -0400 Received: from 212-186-180-163.dynamic.surfer.at ([212.186.180.163]:47868 "EHLO cgate.sperl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753012AbbD0QZa convert rfc822-to-8bit (ORCPT ); Mon, 27 Apr 2015 12:25:30 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example. From: Martin Sperl In-Reply-To: <20150427152705.GU22845@sirena.org.uk> Date: Mon, 27 Apr 2015 18:25:26 +0200 Cc: Hans de Goede , Michal Suchanek , Maxime Ripard , linux-sunxi , Jonathan Corbet , linux-spi , linux-doc , Linux Kernel Mailing List Content-Transfer-Encoding: 8BIT Message-Id: References: <20150426110144.GK22845@sirena.org.uk> <553CCABA.3090504@redhat.com> <12F80B18-7418-430E-94F7-5A20C133BA9A@martin.sperl.org> <20150426125113.GF5627@lukather> <20150427093618.GL22845@sirena.org.uk> <553E099C.4070208@redhat.com> <20150427112539.GR22845@sirena.org.uk> <553E4447.6080202@martin.sperl.org> <20150427152705.GU22845@sirena.org.uk> To: Mark Brown X-Mailer: Apple Mail (2.2098) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3576 Lines: 80 > On 27.04.2015, at 17:27, Mark Brown wrote: > > > OK, so that is just a default overlay which is abusing the fact that we > will bind to spidev without a DT compatible and when the binding is > undocumented (which also applies to other devices and buses sadly). > > Unfortunately nobody ever mentioned this upstream and the feedback > upstream that listing spidev in a DT is a bad idea has been ignored. Maybe it should also have been documented as such in Documentation/spi/spidev or in Documentation/devicetree/bindings/spi/ > The whole reason we're doing this in the first place is that we got sick > of telling people that using spidev in DTs like this was a bad idea. The only reference I found in my history of the spi-list is this email: > On 08.10.2014, at 22:05, Mark Brown wrote: > > On Wed, Oct 08, 2014 at 02:27:08PM -0500, tthayer@opensource.altera.com wrote: > >> + spidev@0 { >> + compatible = "spidev"; >> + reg = <0>; /* chip select */ >> + spi-max-frequency = <100000000>; >> + }; > > No, if you're putting spidev into the DT that's broken - describe the > hardware, not the software you're using to control it. And google found this patch from a little earlier: http://comments.gmane.org/gmane.linux.ports.arm.kernel/231050 So finding this piece of information on the “use-policy” is quite hard - google finds lots of links where it is described as working that way. > It does sound like the people maintianing the u-boot fork for the Pi > need to talk to both u-boot upstream (nothing here is specific to the > Pi that I can see) and the kernel community a bit more. I'd be a bit > worried that they may be relying on other things that just happen to > work without being intentional (and are therefore more vulnerable to > issues) and it's a bit depressing to see things like this stuck in a > fork where only a limited community can make use of them. Actually this functionality is not in u-boot, but in the firmware boot-loader itself, which can load the kernel (and the devicetree) without u-boot, but which can also load u-boot as an additional intermediate boot-stage. >> The only thing that could possibly be better would be that >> the user would define the "real" name of the device in the >> device tree and spidev would bind to it if there is no driver >> available (but that would require this "fallback" binding by >> spidev in case of no driver). > > Yes, that is exactly the solution I'd suggest - change the UI to provide > a DT compatible to be used for the new device. That would also have the > benefit of meaning that users who have connected some device that does > have a driver that works with a simple binding wouldn't need to write an > overlay which seems like it should be useful. Well then why did you just make the system complain loudly and bringing problems to people instead of solving it in a usable manner that does not require people to maintain an out of tree patch to work around that warning? We still have the one-line warning about using the depreciated spi_master.transfer interface, but it is not such loud warning as this one. I guess the time spent discussing this could have been better spent implementing that solution instead. All we need is a volunteer to get that implemented. -- 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/