Gregory, Thank you for your support. I will work on this.
Best regards. Flavio Em qua., 14 de abr. de 2021 11:09, Gregory Nutt <spudan...@gmail.com> escreveu: > You board must provide CONFIG_ARCH_PHY_INTERRUPT: > > $ find boards/ -name Kconfig | xargs grep ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT if SAMA5_EMACA || > SAMA5_EMAC0 || SAMA5_EMAC1 || SAMA5_GMAC > boards/Kconfig: select ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT > boards/Kconfig: select ARCH_PHY_INTERRUPT > > and you must implement PHY interrupt handling as documented in > include/nuttx/arch.h: > > > /**************************************************************************** > * Name: arch_phy_irq > * > * Description: > * This function may be called to register an interrupt handler > that will > * be called when a PHY interrupt occurs. This function both > attaches > * the interrupt handler and enables the interrupt if 'handler' > is non- > * NULL. If handler is NULL, then the interrupt is detached and > disabled > * instead. > * > * The PHY interrupt is always disabled upon return. The caller > must > * call back through the enable function point to control the > state of > * the interrupt. > * > * This interrupt may or may not be available on a given platform > depending > * on how the network hardware architecture is implemented. In a > typical > * case, the PHY interrupt is provided to board-level logic as a > GPIO > * interrupt (in which case this is a board-specific interface > and really > * should be called board_phy_irq()); In other cases, the PHY > interrupt > * may be cause by the chip's MAC logic (in which case > arch_phy_irq()) is > * an appropriate name. Other other boards, there may be no PHY > interrupts > * available at all. If client attachable PHY interrupts are > available > * from the board or from the chip, then > CONFIG_ARCH_PHY_INTERRUPT should > * be defined to indicate that fact. > * > * Typical usage: > * a. OS service logic (not application logic*) attaches to the PHY > * PHY interrupt and enables the PHY interrupt. > * b. When the PHY interrupt occurs: (1) the interrupt should be > * disabled and () work should be scheduled on the worker > thread (or > * perhaps a dedicated application thread). > * c. That worker thread should use the SIOCGMIIPHY, SIOCGMIIREG, > * and SIOCSMIIREG ioctl calls** to communicate with the PHY, > * determine what network event took place (Link Up/Down?), and > * take the appropriate actions. > * d. It should then interact the PHY to clear any pending > * interrupts, then re-enable the PHY interrupt. > * > * * This is an OS internal interface and should not be used from > * application space. Rather applications should use the > SIOCMIISIG > * ioctl to receive a signal when a PHY event occurs. > * ** This interrupt is really of no use if the Ethernet MAC driver > * does not support these ioctl calls. > * > * Input Parameters: > * intf - Identifies the network interface. For example > "eth0". Only > * useful on platforms that support multiple Ethernet > interfaces > * and, hence, multiple PHYs and PHY interrupts. > * handler - The client interrupt handler to be invoked when the PHY > * asserts an interrupt. Must reside in OS space, but can > * signal tasks in user space. A value of NULL can be > passed > * in order to detach and disable the PHY interrupt. > * arg - The argument that will accompany the interrupt > * enable - A function pointer that be unused to enable or > disable the > * PHY interrupt. > * > * Returned Value: > * Zero (OK) returned on success; a negated errno value is > returned on > * failure. > * > > > ****************************************************************************/ > > #ifdef CONFIG_ARCH_PHY_INTERRUPT > int arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > phy_enable_t *enable); > #endif > > > Lots of examples. Note that it already exists for STM32F4 Discovery: > > $ find boards/ -name "*.c" | xargs grep arch_phy_irq > boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * Name: > arch_phy_irq > boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: * Name: > arch_phy_irq > boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c: * Name: > arch_phy_irq > boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c: * Name: arch_phy_irq > boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c: * may be cause > by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/sam34/sam4e-ek/src/sam_ethernet.c: * Name: arch_phy_irq > boards/arm/sam34/sam4e-ek/src/sam_ethernet.c: * may be cause by > the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/sam34/sam4e-ek/src/sam_ethernet.c:int arch_phy_irq(FAR > const char *intf, xcpt_t handler, void *arg, > boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c: * Name: arch_phy_irq > boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c: * may be cause > by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c: * Name: > arch_phy_irq > boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c: * Name: arch_phy_irq > boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c: * may be cause by > the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c:int arch_phy_irq(FAR > const char *intf, xcpt_t handler, void *arg, > boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c: * Name: arch_phy_irq > boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c: * may be cause by > the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c:int arch_phy_irq(FAR > const char *intf, xcpt_t handler, void *arg, > boards/arm/samv7/same70-xplained/src/sam_ethernet.c: * Name: > arch_phy_irq > boards/arm/samv7/same70-xplained/src/sam_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/samv7/same70-xplained/src/sam_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > boards/arm/samv7/samv71-xult/src/sam_ethernet.c: * Name: arch_phy_irq > boards/arm/samv7/samv71-xult/src/sam_ethernet.c: * may be cause by > the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/samv7/samv71-xult/src/sam_ethernet.c:int arch_phy_irq(FAR > const char *intf, xcpt_t handler, void *arg, > boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c: * Name: > arch_phy_irq > boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c: * may be > cause by the chip's MAC logic (in which case arch_phy_irq()) is > boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c:int > arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, > > > On 4/14/2021 7:59 AM, Flavio Castro Alves Filho wrote: > > The netinit_monitor code is self-explanatory :-/ > > > > I could understand what must be done ... and, naturally, it is in > > accord with the documents. > > > > In my case, I cannot easily enable it from menuconfig ... as far as I > > understood. > > > > Em qua., 14 de abr. de 2021 às 10:49, Gregory Nutt > > <spudan...@gmail.com> escreveu: > >> This is very out of date, but 90% accurate: > >> > >> > https://cwiki.apache.org/confluence/display/NUTTX/Network+Link+Management > >> > https://cwiki.apache.org/confluence/display/NUTTX/NSH+Network+Link+Management > >> > >> This was not updated after the network initialization and network > >> monitor were removed from NSH and made a separate feature. It needs so > >> clean-up. > >> > >> On 4/14/2021 7:40 AM, Alan Carvalho de Assis wrote: > >>> I think this is kind of question that should be in some FAQ or in our > >>> documentation, it is asked often... > >>> > >>> Is there some only place in our Documentation where we could include > it? > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On 4/14/21, Gregory Nutt <spudan...@gmail.com> wrote: > >>>> Normally this is done using the PHY driver at > >>>> nuttx/drivers/net/phy_notify.c that provides PHY-related events to > >>>> applications via signals. It requires board-level support to handle > PHY > >>>> interrupts. > >>>> > >>>> The network monitor thread at apps/netutils/netinit (see > >>>> CONFIG_NETINIT_MONITOR) will handle taking the network down if the > cable > >>>> is unplugged and bringing it back up when the cable is restored. > >>>> > >>>> On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote: > >>>>> Hello, > >>>>> > >>>>> I am implementing an application using NuttX where I need to detect > if > >>>>> the network cable is plugged or not in my board. > >>>>> > >>>>> Today I implemented the function netlib_getifstatus(), which > automates > >>>>> the read of SIOCGIFFLAGS, similar to what we have in Linux. > >>>>> > >>>>> But, in my tests, it seems that it is not working correctly. > >>>>> > >>>>> What is the recommended approach to have this feature implemented? > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Flavio > >>>>> > > > >
