Re: Aw: Re: Re: [PATCH v5 1/5] dt-bindings: ata: ahci-platform: Convert DT bindings to yaml

From: Rob Herring
Date: Mon Mar 07 2022 - 17:06:05 EST


On Sun, Mar 06, 2022 at 12:15:39PM +0100, Krzysztof Kozlowski wrote:
> On 06/03/2022 11:41, Frank Wunderlich wrote:
> >> Gesendet: Sonntag, 06. März 2022 um 11:27 Uhr
> >> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@xxxxxxxxxxxxx>
> >>> add compatibles used together with generic-ahci
> >>> - marvell,berlin2-ahci
> >>
> >> This is fine, just mention it in commit msg.
> >>
> >>> - qcom,apq8064-ahci
> >>> - qcom,ipq806x-ahci
> >>
> >> These you need to consult with qcom-sata.txt. This could be a following
> >> commit which will integrate qcom-sata.txt and remove it.
> >
> > this depends on Robs opinion
>
> Then maybe precise the question for Rob...

I would leave qcom separate, but the warnings should be fixed. For that
you need a custom 'select' schema that lists everything but
'generic-ahci'. Adding the berlin compatible looks right.

> >> Either you have
> >> binding document for all devices or you create a common part, like for UFS:
> >> https://lore.kernel.org/linux-devicetree/20220222145854.358646-1-krzysztof.kozlowski@xxxxxxxxxxxxx/
> >> https://github.com/krzk/linux/commits/n/dt-bindings-ufs-v2
> >>
> >> The choice depends more or less on complexity of bindings, IOW, how big
> >> and complicated bindings would be if you combine everything to one YAML.
> >>
> >> In the case of UFS, the devices differ - by clocks, resets, phys and
> >> sometimes supplies. Therefore it easier to have one common shared part
> >> and several device bindings.
> >>
> >> AHCI looks more consistent - except that Qualcomm - so maybe better to
> >> have one document.
> >>
> >>> increase reg-count to 2 (used in omap5-l4.dtsi)
> >>> increase clock-count to 5 (used in qcom-apq8064.dtsi)
> >>
> >> This would need allOf+if.
> >
> > if i get ok from rob i add only the berlin-compatible and skip the
> > qcom+reg/clock-change in the first applied version. Adding the
> > allOf/if (and making it right) will only delay the sata-binding/dts-change.
>
> I don't get what is the problem with delaying this patch for the time
> needed to make the bindings correct? Especially that alternative is to
> add bindings document which soon will need to be modified, e.g. split
> into common part. Is there a particular hurry with these bindings
> conversion?

Qcom doesn't use sata-port nodes, so I don't think there is anything to
share. And if it did, that's already in sata-common.yaml.

Rob