On 12/18/2017 12:01 AM, Andrew Lunn wrote: > Hi Sean > >> It probably can't. Because before the GPIO line is manipulated to reset, >> certain power control should be handled such as power sources from >> external PMIC to let devices actually enter the proper state. >> >> So, I thought the kind of reset should be better controlled by the >> specific driver, not by generic core. > > Yes, the driver should do it in that case. > > So we have a few choices: > > 1) Change the name of one of the properties > > 2) Make the new code look at the compatible string, any only apply a > reset if it is a PHY. > > 3) Make the new code only hold the gpio when it needs it. Same for the > driver, so that they both can reset the device. > > Any other ideas? Any preferences? 2) and 3) are probably simpler to > do, less backwards compatibility issues. 3) potentially could cause > issues when a device is reset in the wrong context, because of > external PMIC etc. So i'm thinking 2).
We could also add some sort of flag that indicates whether the reset should be managed by the core, or the driver, I would have to double check there is not a chicken and egg problem and that the driver probe is early enough this can happen... -- Florian
