Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754719AbcK1PpG (ORCPT ); Mon, 28 Nov 2016 10:45:06 -0500 Received: from arcturus.kleine-koenig.org ([78.47.169.190]:36358 "EHLO arcturus.kleine-koenig.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754372AbcK1PpB (ORCPT ); Mon, 28 Nov 2016 10:45:01 -0500 Subject: Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support To: Andrew Lunn References: <1480280279-9552-1-git-send-email-afaerber@suse.de> <1480280279-9552-2-git-send-email-afaerber@suse.de> <20161127212709.GD13318@lunn.ch> <9500470d-09c3-3ecb-994b-3d108bffc99e@suse.de> <20161127220846.GH13318@lunn.ch> <20161127231009.GA17704@lunn.ch> <20161128080939.ippqlytvojitefkp@perseus.defre.kleine-koenig.org> <20161128131735.GA4379@lunn.ch> Cc: Rob Herring , Frank Rowand , =?UTF-8?Q?Andreas_F=c3=a4rber?= , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Michal Hrusecki , Tomas Hlavacek , Bed??icha Ko??atu , Vivien Didelot , Florian Fainelli , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org From: =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= Message-ID: <2c59cc79-b6dc-9920-1725-a7785ff3b6bf@kleine-koenig.org> Date: Mon, 28 Nov 2016 16:44:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161128131735.GA4379@lunn.ch> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6R5W68SatoGG2CiNqM5FTEJOrnrwkneFf" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5198 Lines: 129 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6R5W68SatoGG2CiNqM5FTEJOrnrwkneFf Content-Type: multipart/mixed; boundary="hbs5AHDaKWKp8K6XgQMO3iS2BIRGrI701"; protected-headers="v1" From: =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= To: Andrew Lunn Cc: Rob Herring , Frank Rowand , =?UTF-8?Q?Andreas_F=c3=a4rber?= , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Michal Hrusecki , Tomas Hlavacek , Bed??icha Ko??atu , Vivien Didelot , Florian Fainelli , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Message-ID: <2c59cc79-b6dc-9920-1725-a7785ff3b6bf@kleine-koenig.org> Subject: Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support References: <1480280279-9552-1-git-send-email-afaerber@suse.de> <1480280279-9552-2-git-send-email-afaerber@suse.de> <20161127212709.GD13318@lunn.ch> <9500470d-09c3-3ecb-994b-3d108bffc99e@suse.de> <20161127220846.GH13318@lunn.ch> <20161127231009.GA17704@lunn.ch> <20161128080939.ippqlytvojitefkp@perseus.defre.kleine-koenig.org> <20161128131735.GA4379@lunn.ch> In-Reply-To: <20161128131735.GA4379@lunn.ch> --hbs5AHDaKWKp8K6XgQMO3iS2BIRGrI701 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/28/2016 02:17 PM, Andrew Lunn wrote: >> I still wonder (and didn't get an answer back when I asked about this)= >> why a comment is preferred here. For other devices I know it's usual a= nd >> requested by the maintainers to use: >> >> compatible =3D "exact name", "earlyer device to match driver"; >> >> . This is more robust, documents the situation more formally and makes= >> it better greppable. The price to pay is only a few bytes in the dtb >> which IMO is ok. >=20 > We did discuss this a while back. The information is useless and > should to be ignored if present. Who is "we"? > The switch has a register which contains its model and revision. Each > port has a set of registers, and register 3 contains the > model/version. For all devices compatible with the 6085, the port > registers start at address 0x10. For the 6190, the port registers > start at 0x0. So given one of these two compatible strings, we can > find the model of the device, from something which is burned into the > silicon. >=20 > Now, say we did add per device compatible strings. We look up the > model burned into the silicon, find it is different to what the device > tree is and do what? Fail the probe? Or just keep going using the I'd say fail to probe is the right thing to do. Of course that doesn't work for already supported models because it will break compatibility. I'd value the advantages (i.e. easily find machines with a given hardware) higher than making broken dtbs work, so being a bit silly is fine for me. > value in the silicon? It seems silly to fail the probe if the driver > does support the model, but that means the device tree is never > verified and hence probably wrong. Why have wrong information in the > device tree, especially wrong information which we never use. It is > better to not have that information in the device tree. At least we'd have a canonical way to specify the type of switch. If it's not verified it's as good and bad as a dts comment. But the latter isn't available in the dtb, which I consider a small disadvantage. Also it seems wrong to write "marvell,mv88e6085" (only) if I know the hardware is really a "marvell,mv88e6176". > Linus has said he does not like ARM devices because of all the busses > which are not enumerable. Here we have a device which with a little > bit of help we can enumerate. So we should.=20 If you write compatible =3D "marvell,mv88e6176", "marvell,mv88e6085"; you can still enumerate in the same way as before. There are several more instances where the device tree specifies something that could be probed instead. Some examples: compatible =3D "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";= compatible =3D "spansion,s25fl164k", "jedec,spi-nor"; compatible =3D "fsl,imx25-flexcan", "fsl,p1010-flexcan"; compatible =3D "arm,pl011", "arm,primecell"; So you think they are all doing it wrong? Best regards Uwe --hbs5AHDaKWKp8K6XgQMO3iS2BIRGrI701-- --6R5W68SatoGG2CiNqM5FTEJOrnrwkneFf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAlg8UO8ACgkQwfwUeK3K 7AkbXQf/Z7Tw0gFA71X5Bz5JOjmorHEMNQ5ZrxP7fQ4YiiDUyjWj4WxgF3qiyrwG KQBYlMBNRd8IKtPaadbgage8O2KCCb/5rbjY5okuStpka0z+qNbBlWV/YpA8CJ+M jT5KBXWBVrziRWwjai+18rI8GiMB+DkbrmYbnpanQ+wpT5N6LmiDt7lmbM3+3I2d 1Je2d6Zb25YCahkYj3Jd4VqkplfVwkwelyu7bv2BOo+2bzQS28Xup1/Af1BN7zvG wwlobWwCEYZxZUyE9PUr0au0W3NfBOLWqgStYYB05MAv0IfwUFPsULSBcsC5QxaS PUymZR6EmxtSmLIyuOM3+vSmxcAFrw== =7GDN -----END PGP SIGNATURE----- --6R5W68SatoGG2CiNqM5FTEJOrnrwkneFf--