Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753924AbbG2RQ7 (ORCPT ); Wed, 29 Jul 2015 13:16:59 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:45469 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753829AbbG2RQ5 (ORCPT ); Wed, 29 Jul 2015 13:16:57 -0400 Date: Wed, 29 Jul 2015 18:16:13 +0100 From: Mark Brown To: Michal Suchanek 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 Message-ID: <20150729171613.GI11162@sirena.org.uk> References: <557c1962448393b2a8736f26bfa2a3a5ba4aeb7a.1438170519.git.hramrach@gmail.com> <20150729140046.GB11082@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0CMEPKoZzmdAWWDb" Content-Disposition: inline In-Reply-To: X-Cookie: Stay together, drag each other down. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2664 Lines: 63 --0CMEPKoZzmdAWWDb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote: > On 29 July 2015 at 16:00, Mark Brown wrote: > > I can't tell from this commit message what the issue you're trying to > > fix is, sorry. Nodes without compatible strings are entirely normal and > > don't need compatible strings. It sounds like a bug in whatever other > > driver is becoming confused. > The driver that gets confused is ofpart. > The two-line patch to allow it to just ignore controller-data has been > rejected on the basis that s3c64xx should use a compatible string > because ofpart monopolizes all nodes without compatible which are > children of a mtd device. Devicetrees containing such nodes that are > not partitions are presumably invalid and should be rejected when > ofpart is compiled into the kernel. That seems like an extremely limited binding, the normal thing here would be to create a specifically named node to contain the collection of subnodes like many PMICs do for their regulators. As a fix I'd suggest just silently ignoring nodes it can't understand, or printing a warning if that's a serious issue. > >> + if (!of_get_property(data_np, "compatible", NULL) || > >> + strcmp(of_get_property(data_np, "compatible", NULL), > >> + "samsung,s3c-controller-data")) > >> + dev_err(&spi->dev, "child node 'controller-data' does not have correct compatible\n"); > > This will break all existing users which is not acceptable for > > mainline, we need to preserve compatibility with existing device trees. > 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? --0CMEPKoZzmdAWWDb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVuQpZAAoJECTWi3JdVIfQ68kH/jsyNe1U8G5G/KoBfbkvD+oC EEFlCmhxLQbMefRVdRLta7rZYvV72X7YMld3h3ppCQQ62f6Gf3ejCPDaEXYJZbr7 U91T+wyx5pLviUP+D3HVFYdG9RgRogs8LPgwQsHc2yPpO99vzglduW1/lT4btyPK QMeIyZcq+T3f/vIgXCGGrE7l+2vVnGPiyLLXq4AcCA6zEPYupZYNWuIMj4JylUB2 ZbDnAIjYwX4kSYF9y27jN0ihMsHqPd7mxRhiaGb+Rg7Ow6riSH7Xhz0d/kNAVQmc 3cUr/P/N4cNsx9K5Qp8/4t+eQYru/OMra1r/t40BXkWQKYilZ6svTkskbGIYLw4= =IPtn -----END PGP SIGNATURE----- --0CMEPKoZzmdAWWDb-- -- 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/