On Wed, Jun 24, 2020 at 6:06 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > [snip!] > > > > This has evolved into several new concepts being proposed vs my > > use-case which is relatively simple. The former will probably take > > several months of development, reviews and discussions and it will > > block supporting the phy supply on pumpkin boards upstream. I would > > prefer not to redo what other MAC drivers do (phy-supply property on > > the MAC node, controlling it from the MAC driver itself) if we've > > already established it's wrong. > > You are not new to Linux development, so none of this should come as a > surprise to you. Your proposed solution has clearly short comings and is > a hack, especially around the PHY_ID_NONE business to get a phy_device > only then to have the real PHY device ID. You should also now that "I > need it now because my product deliverable depends on it" has never been > received as a valid argument to coerce people into accepting a solution > for which there are at review time known deficiencies to the proposed > approach. > Don't get me wrong, I understand that full well. On the other hand a couple years ago I put a significant amount of work into the concept of early platform device drivers for linux clocksource, clock and interrupt drivers. Every reviewer had his own preferred approach and after something like three completely different submissions and several conversations at conferences I simply gave up due to all the bikeshedding. It just wasn't moving forward and frankly: I expect any changes to the core driver model to follow a similar path of most resistance. I will give it a shot but at some point getting the job done is better than not getting it done just because the solution isn't perfect. IMO this approach is still slightly more correct than controlling the PHY's supply from the MAC driver. Bartosz
