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. > >> >> 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