Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754948AbbG3IZW (ORCPT ); Thu, 30 Jul 2015 04:25:22 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:38584 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752703AbbG3IZS (ORCPT ); Thu, 30 Jul 2015 04:25:18 -0400 MIME-Version: 1.0 In-Reply-To: <20150729184043.GL11162@sirena.org.uk> References: <557c1962448393b2a8736f26bfa2a3a5ba4aeb7a.1438170519.git.hramrach@gmail.com> <20150729140046.GB11082@sirena.org.uk> <20150729171613.GI11162@sirena.org.uk> <20150729184043.GL11162@sirena.org.uk> From: Michal Suchanek Date: Thu, 30 Jul 2015 10:24:37 +0200 Message-ID: Subject: Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data To: Mark Brown Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , David Woodhouse , Brian Norris , Kukjin Kim , Krzysztof Kozlowski , Padmavathi Venna , Boris BREZILLON , devicetree , Linux Kernel Mailing List , MTD Maling List , "linux-arm-kernel@lists.infradead.org" , linux-samsung-soc , 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: 2564 Lines: 67 On 29 July 2015 at 20:40, Mark Brown wrote: > On Wed, Jul 29, 2015 at 08:21:34PM +0200, Michal Suchanek wrote: >> On 29 July 2015 at 19:16, Mark Brown wrote: > >> >> It will not break anything. It will just spam dmesg. > >> > I'm confused - if all this change does is to spam dmesg then what's the >> > point? > >> Presumably when your SPI NOR flash fails to probe this message will be >> just above and you will look into the binding doc and add the >> compatible. > > If you're looking to add a warning message when the flash device fails > to probe then add that in the flash driver when it detects an error, > this will cause needless noise for everyone else using this controller > purely to work around the broken binding. Technically nobody needs to see the warning with in-tree boards since the dts can be amended with the compatible. There is no error in flash device driver. There is only error parsing partition scheme. In my opinion this should never cause an error. With disk drives failure to parse partition table results in unpartitioned disk. As there are number of partitioning schemes failure to parse one still does not prevent other in succeding. > > And like I say compatible really seems like it isn't an appropriate > property here. So to sum up the discussion adding compatible to s3c64xx controller-data is not desirable and making ofpart more robust is desirable. I think the suggestion to use a subnode for ofpart gives the most robust solution. Even adding compatibles to the partition subnodes ofpart still monopolizes the address and cells property of the mtd node which does not pass the 'if another driver did the same would it work together?' test. So my suggestion is to 1) search of ofpart subnode in mtd node. If present read address and reg from it and search partitions as subnodes of the ofpart node. In this case unknown nodes can cause error. 2) failing that issue a warning and try to parse ofpart partitions from the mtd node itself. In this case unknown nodes cannot cause error for compatibility with other drivers including the already exisitn s3c64xx controller-data node. The parser code can be the same for both cases and only operate on different node with a flag to reject unknown subnodes or not. Thanks Michal -- 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/