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
