On 08/05/2022 19:04, Peter Geis wrote: > On Sun, May 8, 2022 at 8:12 AM Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx> wrote: >>> >>> I think the issue is more for the description itself. >>> >>> Devicetree is only meant to describe the hardware and does in general don't >>> care how any firmware (Linux-kernel, *BSD, etc) handles it. So going with >>> "the kernel does it this way" is not a valid reason for a binding change ;-) . Exactly. The argument in commit msg was not matching the change, because driver implementation should not be (mostly) a reason for such changes. >>> >>> Instead in general want to reason that there are boards without this reset >>> facility and thus make it optional for those. >> >> if only the wording is the problem i try to rephrase it from hardware PoV. >> >> maybe something like this? >> >> https://github.com/frank-w/BPI-R2-4.14/commits/5.18-mt7531-mainline2/Documentation/devicetree/bindings/net/dsa/mediatek%2Cmt7530.yaml Looks ok. >> >> Another way is maybe increasing the delay after the reset (to give more time all >> come up again), but imho it is no good idea resetting the gmac/mdio-bus from the >> child device. >> >> have not looked into the gmac driver if this always does the initial reset to >> have a "clean state". In this initial reset the switch will be resetted too >> and does not need an additional one which needs the gmac/mdio initialization >> to be done again. > > For clarification, the reset gpio line is purely to reset the phy. > If having the switch driver own the reset gpio instead of the gmac > breaks initialization that means there's a bug in the gmac driver > handling phy init. > In testing I've seen issues moving the reset line to the mdio node > with other phys and the stmmac gmac driver, so I do believe this is > the case. Yes, this seems reasonable, although Frank mentioned that reset is shared with gmac, so it resets some part of it as well? Best regards, Krzysztof
