Re: [lwip-users] how to set the link up

[massimiliano cialdi]

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:address@hidden *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, 
> <address@hidden 
> <mailto:address@hidden>> 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
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> --
>
> Pozdrawiam,
>
> Krzysztof Wesołowski
>
> +48 721 337 238