From mboxrd@z Thu Jan 1 00:00:00 1970 From: srinivas kandagatla Subject: Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller Date: Thu, 17 Oct 2013 10:33:33 +0100 Message-ID: <525FAEED.7030207@st.com> References: <1381754813-4679-1-git-send-email-maxime.coquelin@st.com> <1381754813-4679-2-git-send-email-maxime.coquelin@st.com> <20131016151419.GA14104@ns203013.ovh.net> <525F915D.9020501@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <525F915D.9020501@st.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Maxime COQUELIN Cc: Mark Rutland , "devicetree@vger.kernel.org" , Ian Campbell , Russell King , Pawel Moll , Stephen Warren , Lee Jones , Wolfram Sang , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Rob Herring , Stephen GALLIMORE , Stuart MENEFY , "linux-i2c@vger.kernel.org" , Rob Landley , Grant Likely , Jean-Christophe PLAGNIOL-VILLARD , Gabriel FERNANDEZ , "linux-arm-kernel@lists.infradead.org" List-Id: linux-i2c@vger.kernel.org On 17/10/13 08:27, Maxime COQUELIN wrote: > ... >>> >> + >>> >> +static struct of_device_id st_i2c_match[] = { >>> >> + { .compatible = "st,comms-ssc-i2c", }, >> > the rules is to put the first soc that use the ip in the compatible >> > as st,sti7100-scc-i2c > Ok. There are no plans to upstream the SH4 platforms, it will only > remains in stlinux.com. > Maybe I can set the first ARM platform (STiH415)? > That would give st,stih415-ssc-i2c. NAK, for st,stih415-ssc-i2c naming. IMO, this makes sense when the same IP integration done on different SOC changes slightly/very differently. But in this case the "comms" IP remains unchanged across all the SOCs. I would still prefer "st,comms-ssc-i2c", allowing a single device driver to match against several SoCs. ST "comms" IP it is integrated across all the STi series of SoCs, so we don't want to add new entry in compatible for every new SOC. Thanks, srini > > Thanks for the review, > Maxime > >> > From mboxrd@z Thu Jan 1 00:00:00 1970 From: srinivas.kandagatla@st.com (srinivas kandagatla) Date: Thu, 17 Oct 2013 10:33:33 +0100 Subject: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller In-Reply-To: <525F915D.9020501@st.com> References: <1381754813-4679-1-git-send-email-maxime.coquelin@st.com> <1381754813-4679-2-git-send-email-maxime.coquelin@st.com> <20131016151419.GA14104@ns203013.ovh.net> <525F915D.9020501@st.com> Message-ID: <525FAEED.7030207@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 17/10/13 08:27, Maxime COQUELIN wrote: > ... >>> >> + >>> >> +static struct of_device_id st_i2c_match[] = { >>> >> + { .compatible = "st,comms-ssc-i2c", }, >> > the rules is to put the first soc that use the ip in the compatible >> > as st,sti7100-scc-i2c > Ok. There are no plans to upstream the SH4 platforms, it will only > remains in stlinux.com. > Maybe I can set the first ARM platform (STiH415)? > That would give st,stih415-ssc-i2c. NAK, for st,stih415-ssc-i2c naming. IMO, this makes sense when the same IP integration done on different SOC changes slightly/very differently. But in this case the "comms" IP remains unchanged across all the SOCs. I would still prefer "st,comms-ssc-i2c", allowing a single device driver to match against several SoCs. ST "comms" IP it is integrated across all the STi series of SoCs, so we don't want to add new entry in compatible for every new SOC. Thanks, srini > > Thanks for the review, > Maxime > >> > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754181Ab3JQJl6 (ORCPT ); Thu, 17 Oct 2013 05:41:58 -0400 Received: from eu1sys200aog102.obsmtp.com ([207.126.144.113]:52613 "EHLO eu1sys200aog102.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753583Ab3JQJly (ORCPT ); Thu, 17 Oct 2013 05:41:54 -0400 Message-ID: <525FAEED.7030207@st.com> Date: Thu, 17 Oct 2013 10:33:33 +0100 From: srinivas kandagatla User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Maxime COQUELIN Cc: Jean-Christophe PLAGNIOL-VILLARD , Wolfram Sang , Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Rob Landley , Russell King , Grant Likely , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" , Stuart MENEFY , Lee Jones , Stephen GALLIMORE , Gabriel FERNANDEZ Subject: Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller References: <1381754813-4679-1-git-send-email-maxime.coquelin@st.com> <1381754813-4679-2-git-send-email-maxime.coquelin@st.com> <20131016151419.GA14104@ns203013.ovh.net> <525F915D.9020501@st.com> In-Reply-To: <525F915D.9020501@st.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.51.59] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/10/13 08:27, Maxime COQUELIN wrote: > ... >>> >> + >>> >> +static struct of_device_id st_i2c_match[] = { >>> >> + { .compatible = "st,comms-ssc-i2c", }, >> > the rules is to put the first soc that use the ip in the compatible >> > as st,sti7100-scc-i2c > Ok. There are no plans to upstream the SH4 platforms, it will only > remains in stlinux.com. > Maybe I can set the first ARM platform (STiH415)? > That would give st,stih415-ssc-i2c. NAK, for st,stih415-ssc-i2c naming. IMO, this makes sense when the same IP integration done on different SOC changes slightly/very differently. But in this case the "comms" IP remains unchanged across all the SOCs. I would still prefer "st,comms-ssc-i2c", allowing a single device driver to match against several SoCs. ST "comms" IP it is integrated across all the STi series of SoCs, so we don't want to add new entry in compatible for every new SOC. Thanks, srini > > Thanks for the review, > Maxime > >> >