Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932508AbbERSvv (ORCPT ); Mon, 18 May 2015 14:51:51 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:34275 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbbERSvr (ORCPT ); Mon, 18 May 2015 14:51:47 -0400 MIME-Version: 1.0 In-Reply-To: <20150518183442.GR11598@ld-irv-0074> References: <1431624773-4165-1-git-send-email-computersforpeace@gmail.com> <20150515195541.GL11598@ld-irv-0074> <20150518104501.GD3551@leverpostej> <20150518183442.GR11598@ld-irv-0074> Date: Mon, 18 May 2015 20:51:46 +0200 X-Google-Sender-Auth: JeRpmxrzGT5py0et8ocdKFiTgQo Message-ID: Subject: Re: [PATCH] Documentation: dt: mtd: replace "nor-jedec" binding with "jedec,spi-nor" From: Geert Uytterhoeven To: Brian Norris Cc: Mark Rutland , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , "linux-mtd@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stephen Warren , Marek Vasut , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , linux-spi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3199 Lines: 89 Hi Brian, On Mon, May 18, 2015 at 8:34 PM, Brian Norris wrote: > On Mon, May 18, 2015 at 11:45:01AM +0100, Mark Rutland wrote: >> On Fri, May 15, 2015 at 08:55:41PM +0100, Brian Norris wrote: >> > It really helps if I test patches... >> > >> > On Thu, May 14, 2015 at 10:32:53AM -0700, Brian Norris wrote: > [...] >> > > @@ -305,7 +305,7 @@ static const struct spi_device_id m25p_ids[] = { >> > > * Generic support for SPI NOR that can be identified by the JEDEC READ >> > > * ID opcode (0x9F). Use this, if possible. >> > > */ >> > > - {"nor-jedec"}, >> > > + {"jedec,spi-nor"}, >> > >> > So I forgot (again; we hit this before) that the SPI/OF framework strips >> > everything before the first comma before binding devices. See >> > of_modalias_node(). So I'll have to squash in the patch below to get a >> > usable binding. >> >> Is it not possible to use the of_match_table on spi_driver::driver? If >> not, we really should make it so. > > Hmm, it does look like spi.c supports multiple matching mechanisms, so I > guess m25p80.c could match some with of_match_table and some with > modalias/spi_driver.id_table. See: > > static int spi_match_device(struct device *dev, struct device_driver *drv) > { > const struct spi_device *spi = to_spi_device(dev); > const struct spi_driver *sdrv = to_spi_driver(drv); > > /* Attempt an OF style match */ > if (of_driver_match_device(dev, drv)) > return 1; > // ^^^^ we aren't yet (but could be) using this > > /* Then try ACPI */ > if (acpi_driver_match_device(dev, drv)) > return 1; > > if (sdrv->id_table) > return !!spi_match_id(sdrv->id_table, spi); > // ^^^^ we're currently only using this > > return strcmp(spi->modalias, drv->name) == 0; > } > > I'll see about patching this for 4.2. We have a working solution for > 4.1 at least. When using DT: - spi_driver.id_table is used to match with vendor-stripped DT "compatible" entries. - spi_driver.driver.of_match_table is used to match with full DT "compatible" entries. Note that stripping of vendor names from DT "compatible" entries is done for the _first_ "compatible" entry in the device node only! Hence compatible = "myvendor,m25p80"; will match against "m25p80" in m25p_ids[], while compatible = "myvendor,shinynewdevice", "st,m25p80"; will _not_ match against "m25p80" in m25p_ids[], and fail to probe in the absence of a driver entry for the first (real) "compatible" entry. I2c behaves similarly. 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 -- 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/