From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932142AbcGAPkx (ORCPT ); Fri, 1 Jul 2016 11:40:53 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:59134 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752687AbcGAPkq (ORCPT ); Fri, 1 Jul 2016 11:40:46 -0400 From: Arnd Bergmann To: Jon Mason Cc: =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , davem@davemloft.net, Florian Fainelli , Hauke Mehrtens , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Ray Jui , Scott Branden , BCM Kernel Feedback , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel Subject: Re: [PATCH 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac Date: Fri, 01 Jul 2016 17:42:39 +0200 Message-ID: <6488341.IDGze89kcW@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1467327554-22074-1-git-send-email-jon.mason@broadcom.com> <29091648.CIZSyGWL7u@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:0rMYXupvpSwhq/ozHZg3fpW+IAjDGYIuQVWxpZ0f7+0U/Hx/3VB NNdr77yXGXN03p0Q4uLVjKC83qvM/voERTI3bZZOVhI7eoEyIS3xZvQ/hra703U/PJqlsf8 m7TJOW9tldtumd74Xu7X9H1Z4oPqFxUcKnRyybCdFR2IBSVTC9R4ZdRQkz880Jo2qectxKz sXprvaAeeqgJFIud0EZdQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0st04OXj+6A=:SOVmaW66qK8R3goE1MOsO1 OskXwGCwYbZwY8sSh4e6T9KVHQm07OhiPwNs1sO8NnaRio1lm0TRjbGURMKYSX9hxTHpwjmnx nUHwONgylt/iWYm2dNsbmUNJFxlMV2NZItREk9NSp3i7iWUIDdb+Zgfy6gMR5+10jAXxYTbH2 u2dbfniBFlfhJKz7VDcPDAMDq07m8cluYDUO/Hf03DYDuUJ/f87Gv8L/zvXn4LZI6gZwaSpNQ i/pOlVpJhytCgh2wTsHqSGHFK+L1fXfYFGuUUSXFnkFUCK4RiPxait9nwwcMxUydzkZ5Svk92 IN8jwGvMwZ6aRReQ1SinvOOQFwtXChav6LZvejVRnudZ5Hnp5IMvmqTIs0okeR/0PVGHrIaDV vBELjfdq5a98HJKQ//RaSHlocIZscntNpz/wVv7Eea4Fz2ZChTHDdrHJkUW8gh2FQ63jucvYC OOex5i4HIPO/CFxoaqpsXZv24S2FfPHhuAXjxvovF+iqUEG0fhyWEQF0s3Q/ZXSd6Jy+ITcXr 8RG5vpBd5kdZjK5OrhnESXH48im83cBF+hf9i0CwINIKyS5DN99cUsRJQu28mZYjUI428ybh+ A8Id/RLGCRAhgorok5JyCnXHzs1w6nIZXwWs5hl1oprA3QxhxpVTTI7xFG+zBmjtn2r9VN34l mguPaj5kFIL4eP1d9m9TuuvsZinUHaHe1vkRwypLH2jD4s0Br9XdF/W3DkBmdK0Oph9h1t2qD HvOS2+pMYIuLbf2l Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, July 1, 2016 11:17:25 AM CEST Jon Mason wrote: > On Fri, Jul 1, 2016 at 5:46 AM, Arnd Bergmann wrote: > > On Thursday, June 30, 2016 6:59:13 PM CEST Jon Mason wrote: > >> + > >> +Required properties: > >> + - compatible: "brcm,bgmac-nsp" > >> + - reg: Address and length of the GMAC registers, > >> + Address and length of the GMAC IDM registers > >> + - reg-names: Names of the registers. Must have both "gmac_base" and > >> + "idm_base" > >> + - interrupts: Interrupt number > >> + > > > > > > "brcm,bgmac-nsp" sounds a bit too general. As I understand, this is a family > > of SoCs that might not all have the exact same implementation of this > > ethernet device, as we can see from the long lookup table in bgmac_probe(). > > The Broadcom iProc family of SoCs contains: > Northstar > Northstar Plus > Cygnus > Northstar 2 > a few SoCs that are under development > and a number of ethernet switches (which might never be officially supported) > > Each one of these SoCs could have a different revision of the gmac IP > block, but they should be uniform within each SoC (though there might > be a A0/B0 change necessary). The Northstar Plus product family has a > number of different implementations, but the SoC is unchanged. So, I > think this might be too specific, when we really need a general compat > string. Ok, thanks for the clarification, that sounds good enough. > Broadcom has a history of sharing IP blocks amongst the different > divisions. So, this driver might be used on other SoC families (as it > apparently has been done in the past, based on the code you > reference). I do not know of any way to know what legacy, non-iProc > chips have used this IP block. I can make this "brcm,iproc-bgmac", > and add "brcm,iproc-nsp-bgmac" as an alternative compatible string in > this file (which I believe you are suggesting), but there might be > non-iProc SoCs that use this driver. Is this acceptable? If it is also used outside of iProc, then I see no need for the extra compatible string, although it would not do any harm either. Ideally we should name it whatever the name for this IP block is inside of the company, with "nsp" as the designation for the variant in Northstar Plus. A lot of Broadcom IP blocks themselves seem to have some four-digit or five-digit number, maybe this one does too? Arnd