You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Flavio Castro Alves Filho <fl...@gmail.com> on 2021/04/14 13:24:11 UTC
Ethernet cable (network interface availability) detection
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
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello Gregory,
Got it! The flags are populated by the monitor thread.
I will enable here in my setup, test and report here.
Thank you very much.
Best regards,
Flavio
Em qua., 14 de abr. de 2021 às 10:31, Gregory Nutt
<sp...@gmail.com> escreveu:
>
> Examples:
>
> $ find boards/ -name defconfig | xargs grep CONFIG_NETINIT_MONITOR
> boards/arm/samv7/same70-xplained/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/samv7/samv71-xult/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/tiva/dk-tm4c129x/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/tiva/dk-tm4c129x/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/tiva/tm4c1294-launchpad/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/tiva/tm4c1294-launchpad/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
>
> On 4/14/2021 7:29 AM, Gregory Nutt 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
> >>
> >
>
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Gregory Nutt <sp...@gmail.com>.
Examples:
$ find boards/ -name defconfig | xargs grep CONFIG_NETINIT_MONITOR
boards/arm/samv7/same70-xplained/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
boards/arm/samv7/samv71-xult/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
boards/arm/tiva/dk-tm4c129x/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
boards/arm/tiva/dk-tm4c129x/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
boards/arm/tiva/tm4c1294-launchpad/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
boards/arm/tiva/tm4c1294-launchpad/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
On 4/14/2021 7:29 AM, Gregory Nutt 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
>>
>
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello,
In my case, there is an additional challenge: the
CONFIG_NETINIT_MONITOR is not supported by STM32F4DISCOVERY.
What should I have to do to enable the feature for the board?
Best regards,
Flavio
Em qua., 14 de abr. de 2021 às 10:41, Alan Carvalho de Assis
<ac...@gmail.com> escreveu:
>
> 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 <sp...@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
> >>
> >
> >
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by "Matias N." <ma...@imap.cc>.
Contributing and Glossary should be left at the end. I would put it right before Guides.
Maybe one file with subsections is enough for now.
On Wed, Apr 14, 2021, at 11:03, Alan Carvalho de Assis wrote:
> Hi Matias,
>
> I can submit a PR with it.
>
> Where the FAQ should be added? Is it ok to be after Glossary?
>
> BR,
>
> Alan
>
> On 4/14/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
> > We do not yet have a "Networking" section under "OS Components" where a lot
> > of network related stuff should
> > be. However, I have thought about a FAQ section for having brief
> > question/answers where this kind of information can be (until a proper
> > section is added). If anyone wants to start this it would be welcome. It
> > should be categorized by topic.
> >
> > Best,
> > Matias
> >
> > On Wed, Apr 14, 2021, at 10:40, 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 <spudaneco@gmail.com <mailto:spudaneco%40gmail.com>
> >> <mailto:spudaneco%40gmail.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
> >> >>
> >> >
> >> >
> >>
> >
>
Re: Ethernet cable (network interface availability) detection
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Matias,
I can submit a PR with it.
Where the FAQ should be added? Is it ok to be after Glossary?
BR,
Alan
On 4/14/21, Matias N. <ma...@imap.cc> wrote:
> We do not yet have a "Networking" section under "OS Components" where a lot
> of network related stuff should
> be. However, I have thought about a FAQ section for having brief
> question/answers where this kind of information can be (until a proper
> section is added). If anyone wants to start this it would be welcome. It
> should be categorized by topic.
>
> Best,
> Matias
>
> On Wed, Apr 14, 2021, at 10:40, 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 <spudaneco@gmail.com
>> <mailto:spudaneco%40gmail.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
>> >>
>> >
>> >
>>
>
Re: Ethernet cable (network interface availability) detection
Posted by "Matias N." <ma...@imap.cc>.
We do not yet have a "Networking" section under "OS Components" where a lot of network related stuff should
be. However, I have thought about a FAQ section for having brief question/answers where this kind of information can be (until a proper section is added). If anyone wants to start this it would be welcome. It should be categorized by topic.
Best,
Matias
On Wed, Apr 14, 2021, at 10:40, 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 <spudaneco@gmail.com <mailto:spudaneco%40gmail.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
> >>
> >
> >
>
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello,
At the end, I implement in my application main loop the following procedure:
=> I get the current interface status using netlib_getifstatus() (devup)
=> check the link state using ioctl with the key SIOCGMIIREG and the
register MII_MSR.
=> I check the result with the MII_MSR_LINKSTATUS flag (linkup)
=> Then I performed the following verifications:
if (!devup && linkup) => netlib_ifup()
if (devup && !linkup) => netlib_down()
In fact, that's quite the same approach found in net_monitor. But, the
net_monitor cannot be called due the lack of interruption.
Best regards,
Flavio
Em qua., 19 de mai. de 2021 às 21:49, Flavio Castro Alves Filho
<fl...@gmail.com> escreveu:
>
> Hello David,
>
> I will try this option.
>
> Thank you very much.
>
> Best regards,
>
> Flavio
>
>
> Em qua., 19 de mai. de 2021 19:28, David Sidrane <Da...@nscdg.com> escreveu:
>>
>> This https://github.com/apache/incubator-nuttx/pull/1924 was merged. It adds
>> the polling.
>>
>> This is the app https://github.com/PX4/NuttX-apps/pull/8 does the rest.
>>
>> It was not upstreamed because it was not everything others wanted and I
>> could not test what they wanted.
>>
>> David
>>
>> -----Original Message-----
>> From: Gregory Nutt [mailto:spudaneco@gmail.com]
>> Sent: Wednesday, May 19, 2021 2:56 PM
>> To: dev@nuttx.apache.org
>> Subject: Re: Ethernet cable (network interface availability) detection
>>
>>
>> > Considering this scenario, is there any alternative approach that I
>> > could use to have this detection? Polling the phy, or something
>> > similar?
>>
>> As I recall, David Sidrane submitted a PR to do just this but it was not
>> incoporated. I don't recall why. I recall having some concerns that
>> polling the PHY in maintenance mode would interfere with normal
>> operational mode, but I think David demonstrated that there was not an
>> issue with that.
>>
>> I think these:
>>
>> https://github.com/apache/incubator-nuttx-apps/pull/402
>>
>> https://github.com/apache/incubator-nuttx-apps/pull/415
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello David,
I will try this option.
Thank you very much.
Best regards,
Flavio
Em qua., 19 de mai. de 2021 19:28, David Sidrane <Da...@nscdg.com>
escreveu:
> This https://github.com/apache/incubator-nuttx/pull/1924 was merged. It
> adds
> the polling.
>
> This is the app https://github.com/PX4/NuttX-apps/pull/8 does the rest.
>
> It was not upstreamed because it was not everything others wanted and I
> could not test what they wanted.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Wednesday, May 19, 2021 2:56 PM
> To: dev@nuttx.apache.org
> Subject: Re: Ethernet cable (network interface availability) detection
>
>
> > Considering this scenario, is there any alternative approach that I
> > could use to have this detection? Polling the phy, or something
> > similar?
>
> As I recall, David Sidrane submitted a PR to do just this but it was not
> incoporated. I don't recall why. I recall having some concerns that
> polling the PHY in maintenance mode would interfere with normal
> operational mode, but I think David demonstrated that there was not an
> issue with that.
>
> I think these:
>
> https://github.com/apache/incubator-nuttx-apps/pull/402
>
> https://github.com/apache/incubator-nuttx-apps/pull/415
>
RE: Ethernet cable (network interface availability) detection
Posted by David Sidrane <Da...@nscdg.com>.
This https://github.com/apache/incubator-nuttx/pull/1924 was merged. It adds
the polling.
This is the app https://github.com/PX4/NuttX-apps/pull/8 does the rest.
It was not upstreamed because it was not everything others wanted and I
could not test what they wanted.
David
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Wednesday, May 19, 2021 2:56 PM
To: dev@nuttx.apache.org
Subject: Re: Ethernet cable (network interface availability) detection
> Considering this scenario, is there any alternative approach that I
> could use to have this detection? Polling the phy, or something
> similar?
As I recall, David Sidrane submitted a PR to do just this but it was not
incoporated. I don't recall why. I recall having some concerns that
polling the PHY in maintenance mode would interfere with normal
operational mode, but I think David demonstrated that there was not an
issue with that.
I think these:
https://github.com/apache/incubator-nuttx-apps/pull/402
https://github.com/apache/incubator-nuttx-apps/pull/415
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello Gregory,
Thank you for your quick response.
Looking at the PRs, they seemed a bit complex for me :-| And I'm not
sure if it is that what I want or need.
What I was thinking was to use this call:
stm32_phyread(CONFIG_STM32F4_PHYADDR,MII_MSR,&phyval);
Then make the check:
if ((phyval & MII_MSR_LINKSTATUS) != 0) {
==> change the net driver flag that indicates if the network interface
is up or not;
}
Then in the application, I continue to check regularly the netlib_getifstatus().
Is there any way, or is it feasible, to have something like that? How
should I proceed?
Best regards,
Flavio
Em qua., 19 de mai. de 2021 às 18:55, Gregory Nutt
<sp...@gmail.com> escreveu:
>
>
> > Considering this scenario, is there any alternative approach that I
> > could use to have this detection? Polling the phy, or something
> > similar?
>
> As I recall, David Sidrane submitted a PR to do just this but it was not
> incoporated. I don't recall why. I recall having some concerns that
> polling the PHY in maintenance mode would interfere with normal
> operational mode, but I think David demonstrated that there was not an
> issue with that.
>
> I think these:
>
> https://github.com/apache/incubator-nuttx-apps/pull/402
>
> https://github.com/apache/incubator-nuttx-apps/pull/415
>
>
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Gregory Nutt <sp...@gmail.com>.
> Considering this scenario, is there any alternative approach that I
> could use to have this detection? Polling the phy, or something
> similar?
As I recall, David Sidrane submitted a PR to do just this but it was not
incoporated. I don't recall why. I recall having some concerns that
polling the PHY in maintenance mode would interfere with normal
operational mode, but I think David demonstrated that there was not an
issue with that.
I think these:
https://github.com/apache/incubator-nuttx-apps/pull/402
https://github.com/apache/incubator-nuttx-apps/pull/415
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello,
Coming back to this issue.
Looking at STM32F4DISCOVERY code, I could see that the NETINIT_THREAD
is disabled because the IRQ pin from the PHY is not available.
It happens when the RMII configuration is set and the IRQ pin is also
used as REFCLK0.
This is also the situation with my hardware.
Considering this scenario, is there any alternative approach that I
could use to have this detection? Polling the phy, or something
similar?
Best regards,
Flavio
Em qua., 14 de abr. de 2021 às 11:45, Flavio Castro Alves Filho
<fl...@gmail.com> escreveu:
>
> 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 <sp...@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
>> > <sp...@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 <sp...@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
>> >>>>>
>> >
>>
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
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 <sp...@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
> > <sp...@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 <sp...@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
> >>>>>
> >
>
>
Re: Ethernet cable (network interface availability) detection
Posted by Gregory Nutt <sp...@gmail.com>.
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
> <sp...@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 <sp...@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
>>>>>
>
Re: Ethernet cable (network interface availability) detection
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
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
<sp...@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 <sp...@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
> >>>
> >>
>
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: Ethernet cable (network interface availability) detection
Posted by Gregory Nutt <sp...@gmail.com>.
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 <sp...@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
>>>
>>
Re: Ethernet cable (network interface availability) detection
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
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 <sp...@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
>>
>
>
Re: Ethernet cable (network interface availability) detection
Posted by Gregory Nutt <sp...@gmail.com>.
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
>