From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jassi Brar Subject: Re: [PATCH v7 4/6] dt-bindings: mailbox: imx-mu: add i.MX6SX and i.MX7S SoCs. Date: Thu, 26 Jul 2018 17:22:33 +0530 Message-ID: References: <20180726065331.6186-1-o.rempel@pengutronix.de> <20180726065331.6186-5-o.rempel@pengutronix.de> <1532601691.32306.28.camel@pengutronix.de>

Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Vladimir Zapolskiy Cc: Mark Rutland , Devicetree List , Oleksij Rempel , Rob Herring , ", linux-arm-kernel"@lists.infradead.org, dl-linux-imx , ", Sascha Hauer" , Fabio Estevam , ", linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, srv_heupstream" , Shawn Guo , "A.s. Dong" srv_heupstream , Lucas Stach List-Id: devicetree@vger.kernel.org On Thu, Jul 26, 2018 at 5:14 PM, Vladimir Zapolskiy wrote: > On 07/26/2018 02:15 PM, Jassi Brar wrote: >> On Thu, Jul 26, 2018 at 4:11 PM, Lucas Stach wrote: >>> Hi Jassi, >>> >>> Am Donnerstag, den 26.07.2018, 15:25 +0530 schrieb Jassi Brar: >>>> On Thu, Jul 26, 2018 at 12:23 PM, Oleksij Rempel >>>>> wrote: >>>>> This are currently tested SoCs with imx-mailbox driver. >>>>> >>>>>>> Signed-off-by: Oleksij Rempel >>>>> --- >>>>> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> index 113d6ab931ef..5616d2afca45 100644 >>>>> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> @@ -18,7 +18,7 @@ Messaging Unit Device Node: >>>>> Required properties: >>>>> ------------------- >>>>> - compatible : should be "fsl,-mu", the supported chips include >>>>> - imx8qxp, imx8qm. >>>>> + imx6sx, imx7s, imx8qxp, imx8qm. >>>>> >>>> >>>> This is not scalable. Do we add every new SoC that contains the same controller? >>> >>> Yes, we do. This is a policy direction from the DT maintainers. >>> >> I would love to read the post/documentation. > > Some notes are found in Documentation/devicetree/bindings/ABI.txt > Thanks. I have been through the ABI.txt. > To guarantee "a stable binding" of a compatible property, to avoid > unintentionally added incompatibilities and to fix a list of supported > compatibles in the device driver code there should be a SoC specific > compatible value in the list of 'compatible' property elements. > >> Consider the same h/w - controller and platforms, but only the the MU >> chapter said the controller name is, say, 'MU121'. I am sure now you >> will see it correct to call it "fsl,mu121" compatible. >> What changed? just the name, right? >> >> >>> If we >>> ever going to want to validate DTs against the binding, all compatibles >>> used in the DTs must be specified in the binding. >>> >>> As we can't really tell if the controller is exactly the same or even >>> has some SoC integration bugs, we generally add a new compatible for >>> each SoC to key off any workarounds necessary in the driver without the >>> need to change the DTs, breaking compatibility. >>> >> I think if the h/w resources and behaviour remain the same and the >> documentation does not call it by a different name -- it is safe to >> assume its the same IP. Especially when the driver is absolutely >> indifferent to the 5 SoC names. >> >> If/when we find the controller changes, we could revisit the binding >> and add another compatible option and modify the driver to catch that >> and adapt. >> > > Unfortunately it does not work well this way due to limited possibilities > to distinugush different device IPs on different SoCs, if identical > compatibles are given in both cases, and often it is not obvious that > two IPs are different. > Please note the submitted driver absolutely don't care which of the five SoCs it is. In other words, all these SoCs have the same controller. So its about have just one compatible right now, and add more if some new SoC comes with a variation of the controller. From mboxrd@z Thu Jan 1 00:00:00 1970 From: jassisinghbrar@gmail.com (Jassi Brar) Date: Thu, 26 Jul 2018 17:22:33 +0530 Subject: [PATCH v7 4/6] dt-bindings: mailbox: imx-mu: add i.MX6SX and i.MX7S SoCs. In-Reply-To: References: <20180726065331.6186-1-o.rempel@pengutronix.de> <20180726065331.6186-5-o.rempel@pengutronix.de> <1532601691.32306.28.camel@pengutronix.de>

Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jul 26, 2018 at 5:14 PM, Vladimir Zapolskiy wrote: > On 07/26/2018 02:15 PM, Jassi Brar wrote: >> On Thu, Jul 26, 2018 at 4:11 PM, Lucas Stach wrote: >>> Hi Jassi, >>> >>> Am Donnerstag, den 26.07.2018, 15:25 +0530 schrieb Jassi Brar: >>>> On Thu, Jul 26, 2018 at 12:23 PM, Oleksij Rempel >>>>> wrote: >>>>> This are currently tested SoCs with imx-mailbox driver. >>>>> >>>>>>> Signed-off-by: Oleksij Rempel >>>>> --- >>>>> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> index 113d6ab931ef..5616d2afca45 100644 >>>>> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt >>>>> @@ -18,7 +18,7 @@ Messaging Unit Device Node: >>>>> Required properties: >>>>> ------------------- >>>>> - compatible : should be "fsl,-mu", the supported chips include >>>>> - imx8qxp, imx8qm. >>>>> + imx6sx, imx7s, imx8qxp, imx8qm. >>>>> >>>> >>>> This is not scalable. Do we add every new SoC that contains the same controller? >>> >>> Yes, we do. This is a policy direction from the DT maintainers. >>> >> I would love to read the post/documentation. > > Some notes are found in Documentation/devicetree/bindings/ABI.txt > Thanks. I have been through the ABI.txt. > To guarantee "a stable binding" of a compatible property, to avoid > unintentionally added incompatibilities and to fix a list of supported > compatibles in the device driver code there should be a SoC specific > compatible value in the list of 'compatible' property elements. > >> Consider the same h/w - controller and platforms, but only the the MU >> chapter said the controller name is, say, 'MU121'. I am sure now you >> will see it correct to call it "fsl,mu121" compatible. >> What changed? just the name, right? >> >> >>> If we >>> ever going to want to validate DTs against the binding, all compatibles >>> used in the DTs must be specified in the binding. >>> >>> As we can't really tell if the controller is exactly the same or even >>> has some SoC integration bugs, we generally add a new compatible for >>> each SoC to key off any workarounds necessary in the driver without the >>> need to change the DTs, breaking compatibility. >>> >> I think if the h/w resources and behaviour remain the same and the >> documentation does not call it by a different name -- it is safe to >> assume its the same IP. Especially when the driver is absolutely >> indifferent to the 5 SoC names. >> >> If/when we find the controller changes, we could revisit the binding >> and add another compatible option and modify the driver to catch that >> and adapt. >> > > Unfortunately it does not work well this way due to limited possibilities > to distinugush different device IPs on different SoCs, if identical > compatibles are given in both cases, and often it is not obvious that > two IPs are different. > Please note the submitted driver absolutely don't care which of the five SoCs it is. In other words, all these SoCs have the same controller. So its about have just one compatible right now, and add more if some new SoC comes with a variation of the controller.