I wonder what the difference between link status and netif status is.
I mean, reading documentation:
- netif_set_link_up(struct netif *netif)
This is the hardware link state; e.g. whether cable is plugged for wired
Ethernet interface. This function must be called even if you don't know
the current state. Having link up and link down events is optional but
DHCP and IPv6 discover benefit well from those events.
- netif_set_up(struct netif *netif)
This is the administrative (= software) state of the netif, when the
netif is fully configured this function must be called.
butI can not figure out what conditions can lead to link up and netif down.
In other words what I would do is set the flag up following the link up
flag and vice versa. but in this scenario up flag and link up flag would
be the same. Another question is about the sentence "This function [netif_set_link_up()] must be called even if you don't know the current state". Why?What happens if I call netif_set_link_up()but the link is actually down (Unplugged cable)?
best regards
Max
On 09/07/2017 08:39, Noam Weissman wrote:
Hi Max,
I just read your comments. In my case I have two tasks… one that poll
the link and one handling
the application DHCP. The link task changes the DHCP task state when
link is established and therefore
they are independent and no deadlock happens.
The link call back is used to update parameters or do special
operations at the application level.
I am for example call announce for my discovery protocol.
BR,
Noam.
*From:*lwip-users
[mailto:[email protected]] *On Behalf Of
*Krzysztof Wesolowski
*Sent:* Friday, July 07, 2017 8:22 PM
*To:* Mailing list for lwIP users
*Subject:* Re: [lwip-users] how to set the link up
One simplification would be to do those link monitoring operations on
timer running on LwIP thread, it removes threading issues (ie.
Modifying stack data, accessing PHY). Only dhcp/ip setup would need to
come from external memory/queue.
On Fri, 7 Jul 2017, 18:52 massimiliano cialdi,
<[email protected]
<mailto:[email protected]>> wrote:
On 07/07/2017 18:04, Noam Weissman wrote:
>
> Speed, duplex, link etc... is low level handling and the TCP
stack is
> not aware of that.
>
>
> This is why you call the set_link_up/down in your task,
informing the
> stack !.
>
Yes, of course
> The MDIO interface between your micro and PHY has no relation with
> netif so why do you
>
> pass it as argument ?
>
because, in our implementation (NXP), netif->state is pointer to
structure containing information to interface with PHY.
> You several options to get the link state. You can connect the link
> led in the ETH connector
>
> to your micro and read it as a simple IO.
>
>
> If your PHY supports MII and it is connected as an MII you can
hook an
> interrupt to the link line.
>
We are compliant to RMII, except interrupt signal that is not
routed, so
we have to poll PHY.
> The third option is what I suggested to read the PHY basic register
> and check for the link bit.
>
Is what I do.
> Your link task should not only check if link is up or down but also
> know if it has changed !!. In your
>
> code is constantly calling the netifapi functions unless I missed
> something ?
>
Yes, I have further modified the task:
static void PhyStatus_Task( struct netif *netif )
{
enum { link_up, link_down } linkstatus = link_down;
phy_speed_t physpeed;
phy_duplex_t phyduplex;
bool link;
status_t result;
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
while(1)
{
result = ethernetif_GetLinkStatus(netif, &link);
if(result == kStatus_Success)
{
switch(linkstatus)
{
case link_down:
if(true == link)
{
linkstatus = link_up;
netifapi_netif_set_link_up(netif);
}
break;
case link_up:
if(false == link)
{
linkstatus = link_down;
netifapi_netif_set_link_down(netif);
ETHSPDOFF();
}
else
{
result = ethernetif_GetLinkSpeedDuplex(netif,
&physpeed, &phyduplex);
if(result == kStatus_Success)
{
ETHSPD(physpeed);
}
}
break;
}
}
vTaskDelay(100);
}
}
I have investigated the problems: netifapi_netif_set_link_up() is
called
and it cause call to link callback, in this function I call another
function in netifapi (netifapi_dhcp_start()), so I have a deadlock.
best regards
Max
_______________________________________________
lwip-users mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Pozdrawiam,
Krzysztof Wesołowski
+48 721 337 238
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
