> Subject: Re: [PATCH RFC 2/6] dpaa2-eth: add support for new link state APIs
>
> > /**
> > + * Advertised link speeds
> > + */
> > +#define DPNI_ADVERTISED_10BASET_FULL BIT_ULL(0)
> > +#define DPNI_ADVERTISED_100BASET_FULL BIT_ULL(1)
> > +#define DPNI_ADVERTISED_1000BASET_FULL BIT_ULL(2)
> > +#define DPNI_ADVERTISED_10000BASET_FULL BIT_ULL(4)
>
> So 10 Half and 100Half are not supported by the PHYs you use? What happens if
> somebody does connect a PHY which supports these speeds? Do you need to
> change the firmware? I suppose you do anyway, since it is the firmware which
> is
> driving the PHY.
First of all, if the firmware had access to the open-source PHY driver code,
the design wouldn't have been like this. But as it is, the DPMAC object/driver
is used squarely as a way to gather this information from the PHY library.
Half duplex modes are not supported in our MAC. This is why the firmware does
not export any advertisement bits for these modes.
If somebody connects a PHY which supports 10 Half and 100Half modes, the
intersection of the MAC capabilities and the PHY one's will be only the Full
duplex modes.
>
> > struct dpni_link_state {
> > u32 rate;
> > u64 options;
> > + u64 supported;
> > + u64 advertising;
> > int up;
> > + int state_valid;
> > };
>
> Does the firmware report Pause? Asym Pause? EEE? Is this part of options? Can
> you control the advertisement of these options?
The firmware knows about conveying the pause and asym pause configuration
from/to the mac driver.
EEE is not a feature supported by our MAC so there is no configuration knob for
this.
--
Ioana
>
> Andrew
