On 1/21/21 2:13 PM, Nishanth Menon wrote:

On 13:57-20210121, Suman Anna wrote:

quoted

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.

quoted

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.

regards
Suman