From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753276AbbHUOCE (ORCPT ); Fri, 21 Aug 2015 10:02:04 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:61212 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751769AbbHUOBj (ORCPT ); Fri, 21 Aug 2015 10:01:39 -0400 From: Arnd Bergmann To: "Liguozhu (Kenneth)" Cc: "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "Zhuangyuzeng (Yisen)" , "davem@davemloft.net" , "paul.gortmaker@windriver.com" , Dingtianhong , "zhangfei.gao@linaro.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , Linuxarm , Salil Mehta , huangdaode Subject: Re: =?UTF-8?B?562U5aSNOg==?= [PATCH 1/5] net: add Hisilicon Network Subsystem support (config and documents) Date: Fri, 21 Aug 2015 16:00:35 +0200 Message-ID: <2543796.7JthO5WCfI@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <161EFA05D917D0419F95C4CAEEF86C1094E95FAA@SZXEMA504-MBS.china.huawei.com> References: <1439548222-231611-1-git-send-email-liguozhu@hisilicon.com> <1536926.jEJjsM70Lj@wuerfel> <161EFA05D917D0419F95C4CAEEF86C1094E95FAA@SZXEMA504-MBS.china.huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:nfeU0rGSB+LehnpqukF9xFkHFKljd4oV9TjDtK/9wQPfa/9dMzy g5EIYmEPfzf9RoeUHiuE8yiaZiuL+Ml0bz2F8YmTpBGQrV7pdIAcL7i73Zjuz93n1TCFdS7 TeZRsaKNqSuaDn9/jXPERAb7AJpWo2w+hF3MjYK++XgllAyOJQoZxaLS1B3qJlIAKHEWKLq B7fYLJCAg4eS58diSpPiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:pki0blNwOdg=:/zUjKcifDYF9Iw9Lip2ILE aoulWHnQCM1vKufEN4kH45qnDFvrVWqpnndk0wCXOF19w3zmI8Bbvuj9gnre8vOQn8BK0Znyw WPiNWP1GHqdAjCyqFtTUpnEklqQPR+WWkorDAKbAV7AK4/NefC38OKrcjYITCDB+LgxKUYjoW CrNxL0F7sdgBY68omZE3Y/bAeetDN8kdVArV6kN9fUN+zpqBVr9ah7jFqwWNaV8jtSfzpQHvj jnKP6DmEWsJ2bbNZQ4UF/XZJ+1gDahB3s3d3nSPhDqb5e3KuT9GwVgvOCn7HPwiOADZUo34aX mQunP3WdpD7/eTlbB1S2qDrk/C6QjZGj97lEYVq5tCI31TXGnGNdcnLFnTnFYapAgEFpsgrrz 436s+kOtGJAQLXBJSvBhoMFnd5mhERiXA9uwwzO7QraiDg4wZpWm1p90FKWCNKe2hUL3CM2i4 v9skoUU0yAB443zrH0sjNud7ZVY4eO14mZ8JKzfBK4LV8+E70axDcXElCe4I5GHYoWijg/byo AIWdeELaM9CFsjQ2isEMh2FRXPrgJ7CO7EN5ZJUYM+uQMbDlQnydomodTldJH8ZNrH0g9Di5x B3pSY/e1N5YSlBNEnRJtYnypiu5Z5QAZezq7DGQhH65n8IIgcT088RWkYKVUNiFe3l81C2cKN +ZDb239pZxnSbq8UnfYx4ws701mYlYQ3KvTrC049UD/7PvxnTiqXFqJ2xTrcJfKy+impGhe+n yjxJ3ebuxztMuTLo Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 17 August 2015 01:28:07 Liguozhu wrote: > Thanks, Arnd. > > Regarding the ae-name: it is the name of the Acceleration Engine. It is provided > by the BIOS according to the position and the feature enabled of the IP. > So "soc0" means it is on SoC No. 0, while "n4" means it is running on >"Non-dsaf mode 4". Ideally, we should setup the rule to name it. But as I > said in the patchset, the IP is original designed for a bare metal solution, > it is worthless to export all modes and we are planning to add more mode > for Linux itself in the IP in future version. So I think the better way is > to leave it as a "name" but add more meaning in the future. The name property is a bit awkward. The position is normally implied by the location of the parent device in the DT, so you should not need that at all and instead derive it elsewhere. You can also add strings to the compatible property instead of this, to signify differences in the programming that are based on how the IP block is used. > Regarding the ae-opts: it is the initial value for the AE's runtime options, > Currently, we have only "port number" (there are 6XGE+2GE port for a DSAF AE) > as option. But for future version, we will add other options such as "enable > Spanning Tree Protocol algorithm)" and so on. I think these can easily be converted into an index property and boolean flags (present if true, absent otherwise) for additional features. > Should I add these background to somewhere? The binding document needs to list all supported configurations, if you have a string property, describe specifically what strings are allowed and what they mean, but better try to avoid strings altogether. Arnd