[PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC

[Nishanth Menon]

On 14:42-20210121, Suman Anna wrote:
> On 1/21/21 2:13 PM, Nishanth Menon wrote:
> > On 13:57-20210121, Suman Anna wrote:
> >> This is all moot when your own tree doesn't boot properly. In this case, you are
> >> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> >> nodes that were added or you need additional driver patches (which is not how
> >> maintainer-level trees are verified).
> > 
> > Get your facts straight please.
> > 
> > What do you mean does'nt boot? It does boot with initramfs which is
> > the minimum qual i had set for any new platform (along with. - your
> > need is for a device node to work - which is both a combination of
> > defconfig + driver updates.
> 
> And please re-read my first email, and what I started out with. I am not sure "I
> will pick MMC nodes, but the entry criteria is only initramfs, and you need
> additional patches to get MMC boot to work" is right. Normal thing to do is to
> take in the next merge cycle.

Sigh.

As I stated, the reason I prefer not to do that is because the drivers
will bit-rot for a kernel window without users. Why is it just MMC?

Start off with uart:

compatible = "ti,am64-uart", "ti,am654-uart";

That is not in v5.11-rc1 - it only works because driver is falling back
on the backward compatible nature of the device. The binding and driver
fixes are already on next.

MMC by itself wont boot unless the defconfig changes were merged in
upstream - and that was a painful choice to make to prevent the common Image
file from bloating too much..

I mean, is there a real concern that
https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/
or
https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/
or ....

will be dropped, in which case, we should'nt introduce in the next
kernel version, so that also means that those drivers will remain as is
without users for a complete kernel cycle.

I am not saying there are'nt instances where things have happened..
these changes have been in next for sufficiently long cycles for that
NOT to happen. Without users, they can unfortunately break and no one
will be the wiser till we enable the nodes again.. That would be a waste
of everyone's time.


> >>
> >> Arnd,
> >> Can you please guide us here as to what is expected in general, given that the
> >> pull-request from Nishanth goes through you, and if there is some pre-existing
> >> norms around this?
> >>
> >> Tony,
> >> Appreciate your input as well since you probably have dealt with these kinda of
> >> dependencies on OMAP.
> > 
> > I am more than happy to drop this entire SoC off my queue (I am yet to
> > pick it up), which is probably what I will do.
> > 
> 
> You are the maintainer, do what feels right to you. You can as well wait for the
> MMC driver changes to be in, and then pick up the series next merge window. Or
> you can accept the versions without taking in pieces that have external
> dependencies.


Sure, I explained the rationale, you are adamant on not being convinced,
without a counter reason - what is the breakage here that you can see
when merged through to rc1 target OR to linux-next?

And maybe doing some thing like this will help on (say on arm-soc PR in
5.11?)

 for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done


At all points in time, nodes are just inactive if the driver is
disabled for some reason (either the driver is not enabled or the
binding changes are not in) - they are never broken, Boot is not
broken (a function is broken when that function support exists in
Image file AND dts node for some reason results in that function
not working) - yes, someone can claim NFS boot is broken or WIFI is
brokken when NFS boot or WIFI is not even introduced. etc.

If I go by the strictest rules, then I cannot even introduce a bugfix
which involves dts via arm-soc dts pull request since the dependencies
of erratum and property enabling the erratum all should come from the
subsystem trees.

Drivers being broken is not in anyone's interest. They tend to get
broken if there are no active users.. let us release often and test
often.. and I believe there is plenty of precedence in doing this
already - if there is a risky property, OK fine, lets discuss about it.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D