tinnedkarma commented on PR #16999: URL: https://github.com/apache/nuttx/pull/16999#issuecomment-3289509238
> Please, check compatibility with PHY access according to Clause 45 / MMD Ethernet standard implemented by @matiamic and mainlined in > > #16926 include/net/if.h: Add mechanism for MMD access with SIOCxMIIREG ioctls > > The final IOCTLs has been defined Linux kernel compatible way. The MMD has been used only for SPI OA MAC-PHY drivers till now #16936 but many already included MAC drivers can be extended to support MMD if underlaying hardware supports it. There is high probability that Elektroline adds that support for integrated SAMv7 MAC is some time (@michallenc and @Cynerd are closer to such planning). > > If the given STM32 family provides MMD functionality in PHY/MDIO interface then it would worth to think about testing it implementing it with MMD support from the start. > > The MMD PHY API functions should be considered from start in each case. > > MMD is important today to allow seamlessly connect and configure PLCA T1S PHYs directly to existing MCUs where probably many of them include MMD support in MDIO interface. _Let me start by presenting the concept/design of my work. Then we'll have a common starting point to make is suit everyone's work._ Lately, my work was mainly on the stm32 mcus. There, the netdevs _(usually living in stm32_ethernet.c or stm32_eth.c)_ handles everything. From register access to memory mamagement to packets that gets in and out of the net subsystem. It is plain hard to understand the logic there, and it also led to code duplication across st mcu families. I try to improve what is going on there as follows: * MDIO handling, a separate upperhalf/lowerhalf device that handles the mdio data transation. Nothing more, nothing less. Upperhalf as generic as possible, handling as much as posible. Lowerhalf concerned with the registers. * PHY handling, a separate upperhalf/lowerhalf device that holds a handle to mdio bus/device. It should handle negotiations, both forced and auto, device detection (phy id) and interrupt signalling. You mention IOCTLs. I did not plan anything of this sort. The current upperhalf/lowerhalf netdev approach want to handle the IOCTLs, so no IOCTLs for MDIO or PHY. My take on the netdevs architecture is as follows: netdev->phy->mdio * lowerhalf netdev take a phy handle to any phy. Things like link management, power management through if_up, if_down * lowerhalf phy holds a handle to mdio bus. It controls higher level interaction over mdio bus, negotiations and status. So to try giving an answer. I think ioctls should be handled two layers up, by the netdev, not the mdio bus, this is why there is nothing ioctl related in my bus. Anything else is up for debate. I would really need some feedback for the phy api, or we can work in parallel after agreeing on a common approach. The current changes for the stm32_ethernet.c file is part of my testing, work validation, I'll continue updating this file when I start work on the phy. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
