tinnedkarma commented on PR #16999: URL: https://github.com/apache/nuttx/pull/16999#issuecomment-3289622714
> > 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. > > The MMD/MDIO extension compatible with Linux kernel one has been mainlined #16926 and then OA SPI MAC-PHY driver #16646 > > The OA SPI MAC-PHY driver provides PHY IOCTLs with MMD support and tool to set OA SPI MAC-PHY for PLCA (Physical Layer Collision Avoidance) is near to the pull request ([development branch](https://github.com/matiamic/nuttx-apps/commits/plcatool/) intended to be squashed for PR). The mapping of the drivers for BSPs is prepared for [boards/arm/samv7/samv71-xult](https://github.com/matiamic/nuttx/commits/oa-pr-sam/) and [boards/risc-v/esp32c6](https://github.com/matiamic/nuttx/commits/oa-pr-esp). > > The PLCA tool is planned to work even with discrete T1S PHYs connected to MCUs, priority for Elektroline.cz is SAMv7. > > The related thesis text [there](https://dspace.cvut.cz/bitstream/handle/10467/123231/F3-BP-2025-Matias-Michal-bp.pdf). But even that the final version prototype of the thesis worked the work in the GSoC frame moved project to the another level which allowed start mainlining where core is already accepted. PLCA functionality has been reached during last weeks and tested as well. > > So I think that it worth to think how the IOCTLs level would be mapped to read and write. It is possible to keep that MMD/MDIO multiplexing in the single phyadr and register, but I think that it would be cleaner to separate it same way as it is done in the Linux kernel. Thanks for the update, I'll check the drivers in more details tomorrow. At the first glance. I see the ioctl function mapping, and it currently returning `OA_TC6_IOCTL_CMD_NOT_IMPLEMENTED`. Also, talking about mac-phy, mac is onboard the external chip, so your lowerhalf mdio bus implementation will be managing spi translations, some part of the Control transactions, if i understand correctly. I'm not even sure that having a explicit mdio bus would help you, maybe is easier just to treat everything as spi data regardless if it is Ethernet MAC Frame data transactions or Control transactions. I'll need more time to read the datasheets. Your architectural concept, even just a sketch, can help me a lot. -- 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]
