All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: ulf.hansson@linaro.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com, linux-mmc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible combinations
Date: Fri, 6 Jan 2023 20:33:58 +0100	[thread overview]
Message-ID: <20230106203358.14878660@aktux> (raw)
In-Reply-To: <d7c407dc-0a6c-97d5-a06f-b432a923d74d@linaro.org>

On Fri, 6 Jan 2023 09:41:01 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 05/01/2023 22:38, Andreas Kemnade wrote:
> > Currently make dtbs_check shows lots of errors because imx*.dtsi does
> > not use single compatibles but combinations of them.
> > Allow all the combinations used there.
> > 
> > Patches fixing the dtsi files according to binding documentation were
> > submitted multiple times and are commonly rejected, so relax the rules.
> > Example:
> > https://lore.kernel.org/linux-devicetree/72e1194e10ccb4f87aed96265114f0963e805092.camel@pengutronix.de/
> > 
> > Reason: compatibility of new dtbs with old kernels or bootloaders.
> > 
> > This will significantly reduce noise on make dtbs_check.
> > 
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> >  .../bindings/mmc/fsl-imx-esdhc.yaml           | 24 +++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > index dc6256f04b42..118ebb75f136 100644
> > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > @@ -37,6 +37,30 @@ properties:
> >            - fsl,imx8mm-usdhc
> >            - fsl,imxrt1050-usdhc
> >            - nxp,s32g2-usdhc  
> 
> You must drop the items from enum above. Binding saying:
> compatible="A"
> or:
> compatible="A", "B"
> 
> is not correct. Either A is or is not compatible with B.
> 
hmm, here we have A = B + some additional features
or
A = B + some additional features and additional quirks required.

For the latter we have e.g.
A=
static const struct esdhc_soc_data usdhc_imx6sx_data = {
        .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
                        | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
                        | ESDHC_FLAG_STATE_LOST_IN_LPMODE
                        | ESDHC_FLAG_BROKEN_AUTO_CMD23,
};
B=
static const struct esdhc_soc_data usdhc_imx6sl_data = {
        .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
                        | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536
                        | ESDHC_FLAG_HS200
                        | ESDHC_FLAG_BROKEN_AUTO_CMD23,
};

so there is the difference in ESDHC_FLAG_STATE_LOST_IN_LPMODE.
That might make no difference in some usage scenario (e.g. some bootloader
not doing any LPMODE), but I wonder why
we need to *enforce* specifying such half-compatible things.

Regards,
Andreas

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Kemnade <andreas@kemnade.info>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: ulf.hansson@linaro.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com, linux-mmc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible combinations
Date: Fri, 6 Jan 2023 20:33:58 +0100	[thread overview]
Message-ID: <20230106203358.14878660@aktux> (raw)
In-Reply-To: <d7c407dc-0a6c-97d5-a06f-b432a923d74d@linaro.org>

On Fri, 6 Jan 2023 09:41:01 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 05/01/2023 22:38, Andreas Kemnade wrote:
> > Currently make dtbs_check shows lots of errors because imx*.dtsi does
> > not use single compatibles but combinations of them.
> > Allow all the combinations used there.
> > 
> > Patches fixing the dtsi files according to binding documentation were
> > submitted multiple times and are commonly rejected, so relax the rules.
> > Example:
> > https://lore.kernel.org/linux-devicetree/72e1194e10ccb4f87aed96265114f0963e805092.camel@pengutronix.de/
> > 
> > Reason: compatibility of new dtbs with old kernels or bootloaders.
> > 
> > This will significantly reduce noise on make dtbs_check.
> > 
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> >  .../bindings/mmc/fsl-imx-esdhc.yaml           | 24 +++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > index dc6256f04b42..118ebb75f136 100644
> > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > @@ -37,6 +37,30 @@ properties:
> >            - fsl,imx8mm-usdhc
> >            - fsl,imxrt1050-usdhc
> >            - nxp,s32g2-usdhc  
> 
> You must drop the items from enum above. Binding saying:
> compatible="A"
> or:
> compatible="A", "B"
> 
> is not correct. Either A is or is not compatible with B.
> 
hmm, here we have A = B + some additional features
or
A = B + some additional features and additional quirks required.

For the latter we have e.g.
A=
static const struct esdhc_soc_data usdhc_imx6sx_data = {
        .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
                        | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
                        | ESDHC_FLAG_STATE_LOST_IN_LPMODE
                        | ESDHC_FLAG_BROKEN_AUTO_CMD23,
};
B=
static const struct esdhc_soc_data usdhc_imx6sl_data = {
        .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
                        | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536
                        | ESDHC_FLAG_HS200
                        | ESDHC_FLAG_BROKEN_AUTO_CMD23,
};

so there is the difference in ESDHC_FLAG_STATE_LOST_IN_LPMODE.
That might make no difference in some usage scenario (e.g. some bootloader
not doing any LPMODE), but I wonder why
we need to *enforce* specifying such half-compatible things.

Regards,
Andreas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-01-06 19:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 21:38 [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible combinations Andreas Kemnade
2023-01-05 21:38 ` Andreas Kemnade
2023-01-06  8:41 ` Krzysztof Kozlowski
2023-01-06  8:41   ` Krzysztof Kozlowski
2023-01-06 19:33   ` Andreas Kemnade [this message]
2023-01-06 19:33     ` Andreas Kemnade
2023-01-07 13:23     ` Krzysztof Kozlowski
2023-01-07 13:23       ` Krzysztof Kozlowski
2023-01-07 13:43       ` Andreas Kemnade
2023-01-07 13:43         ` Andreas Kemnade
2023-01-07 14:00         ` Krzysztof Kozlowski
2023-01-07 14:00           ` Krzysztof Kozlowski
2023-01-07 14:07           ` Andreas Kemnade
2023-01-07 14:07             ` Andreas Kemnade
2023-01-07 14:09             ` Krzysztof Kozlowski
2023-01-07 14:09               ` Krzysztof Kozlowski
2023-01-07 15:01               ` Andreas Kemnade
2023-01-07 15:01                 ` Andreas Kemnade
2023-01-07 15:07                 ` Krzysztof Kozlowski
2023-01-07 15:07                   ` Krzysztof Kozlowski
2023-01-07 15:54                   ` Andreas Kemnade
2023-01-07 15:54                     ` Andreas Kemnade
2023-01-08 14:45                     ` Krzysztof Kozlowski
2023-01-08 14:45                       ` Krzysztof Kozlowski
2023-01-08 17:20                       ` Andreas Kemnade
2023-01-08 17:20                         ` Andreas Kemnade
2023-01-09  9:14                         ` Krzysztof Kozlowski
2023-01-09  9:14                           ` Krzysztof Kozlowski
2023-01-08 22:46                     ` Rob Herring
2023-01-08 22:46                       ` Rob Herring
2023-01-09 23:15                       ` Andreas Kemnade
2023-01-09 23:15                         ` Andreas Kemnade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230106203358.14878660@aktux \
    --to=andreas@kemnade.info \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.