net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

> Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
> supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:
> 
> root at verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Full 
>                                 100baseT/Full 
>                                 1000baseT/Full 

So maybe we actually want ethtool to report -EINVAL when asked to do
something which is not supported! Humm:

https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783


	/* We make sure that we don't pass unsupported values in to the PHY */
	linkmode_and(advertising, advertising, phydev->supported);

So maybe the unsupported mode got removed, and the PHY was asked to
advertise nothing!

Anyway, this is roughly there the check should go.

> ...
> 
> Once I remove them queues being setup via device tree it shows all modes as supported again:
> 
> root at verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Half 10baseT/Full 
>                                 100baseT/Half 100baseT/Full 
>                                 1000baseT/Full 
> ...
> 
> However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
> traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
> for that matter).

So the answers are on the wire, just not received? 

> Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
> 100baseT/Full work fine now.
> 
> Any idea what else could still be going wrong with them 10baseT modes?

I would use mii-tool to check the status of the PHY. Make sure it
really has negotiated 10/Half mode. After that, it is very likely to
be a MAC problem, and i don't think i can help you.

> On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
> there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
> half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
> half-duplex communication in this day and age (;-p).

You seem to need it for some reason!

Anyway, it is just code. You have all the needed information in the
adjust_link callback, so you could implement it.

	    Andrew