tinnedkarma commented on PR #16999: URL: https://github.com/apache/nuttx/pull/16999#issuecomment-3289594571
> > > I am not up to date regarding the mentioned work. Last I checked, there was a thesis published at CTU which I read, something about OpenAlliance MAC-PHY , but there was no mdio involved, phy used spi, but correct me if I am wrong. > > > > > > @tinnedkarma I read a little bit about that Clause 45 and maybe these documents could help: https://www.ieee802.org/3/efm/public/nov02/oam/pannell_oam_1_1102.pdf TN1305 Technical note from ST https://pebblebay.com/rtos-clause-45-phy-support/ features supported by QNX and VxWorks. > > I think we can add this initial driver to support the common/old Clause 22 and later improve it to support Clause 45. What do you think @ppisa ? > > I think that we should think at least about parameters to read and write functions and define them such way, that they can be used for both C22 and C45 accesses without changes. Actual C45 functionality for drivers, even STM32, can wait. It is not a problem from my side. Great, then I see here two approaches: * I'll update the Kconfig file with an clause choice, so the phy driver (or user) can y select c22, c45, or both. I'll update mdio bus so it provides independent mdio_read/write_c22 and mdio_read/write_c45, each guarded by the choice above. * I'll add a new an new parameter (enum or int) to mdio_bus_s to specify what clauses it supports. I'll add the prtad parameter to the function signature, and pass it as NULL if c22 is used. I'd opt for the first one, it's a bit more static by design, but is up for debate either choice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
