[OpenWrt-Devel] Using ethtool or swconfig to change link settings for mt7620a?

[Daniel Santos]

Hello Daniel,

Thanks for your help!

On 6/8/19 6:51 AM, Daniel Golle wrote:
> Hi Daniel,
>
> On Sat, Jun 08, 2019 at 04:06:54AM -0500, Daniel Santos wrote:
>> Hello,
>>
>> I need to change auto-negotiate, speed and duplex for a port on my
>> mt7620a-based device, but I'm not quite certain that I understand the
>> structure here.  When using ethtool on eth0 I always get ENODEV,
>> apparently because priv->phy_dev is always NULL in fe_get_link_ksettings
>> of drivers/net/ethernet/mtk/ethtool.c.  But I'm being told that eth0 is
>> only an internal device between the µC and the switch hardware, so it
>> isn't even the one I need to change.
> That's correct.

It always helps when my idea about what I'm doing matches reality.

>> If this is true, then it looks like I will need to implement a
>> get_port_link function for struct switch_dev_ops?  Can anybody confirm
>> this to be the case?  Also, are there any examples aside from the
>> Broadcom drivers?  I have the mt7620 programmer's guide and it specifies
>> the registers I need to change.
> Currently MT7620 still uses our legacy swconfig switch driver, which
> also doesn't support setting autoneg, speed and duplex. However, rather
> than implementing it there, it'd be great to add support for the FE-
> version of the MT7530 swtich found in the MT7620(A/N) WiSoC to the now
> upstream DSA driver[1].

Ok, this makes much more sense now.  So swconfig is on its way out in
favor of DSA (which I've never heard of until now)?  I presume this will
also abstract away changes of ethtool to netlink-based instead of ioctl
on a random socket as well?

> While this driver was originally intended for
> use with standalone MT7530 GE switch chip or the ARM-based MT7623 SoC,
> the same switch fabric is also implemented in MT7621 and support for
> that chip was added to the driver recently[2]. MT7620 basically also
> features the same switch internally, however, it comes with only one
> CPU port, supports only FastEthernet and lacks some of the management
> counters.
>
> Assuming your MT7620 datasheet includes the decription of the MT7530
> switch registers, it'd be great if you can help working on supporting
> MT7620 in the DSA driver as well -- gaining per-port ethtool support
> as a reward :)

Wonderful!  So if I understand correctly, this is the same switch
hardware (internally at least), so has all of the same MAC and MII
registers on 7530, 7621, 7620, etc?  For now I have to get a fix for a
customer on a 3.18 kernel, so I'll be doing the swconfig first and then
see how much time we can put into the DSA implementation.

>
> Cheers
>
>
> Daniel
>
>
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/mt7530.c
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ddda1ac116c852bb969541ed53cffef7255c4961
>

Also, would you happen to know why the mt7620 mdio driver is using a
32-bit read for MII registers that are 32-bit?  For example, in
_mt7620_mii_read.  It looks like some of this can use some improved
error management, since return codes are being ignored in a few places.

From what I can tell thus far, it looks like these MII registers are
standardized, so the "generic" version might do most or all of what I
need in some cases.  But as far as implementing DSA, I guess I'll have
to examine the mainlined driver and see how it works.  I just didn't
have a struct phy_device to work with when trying to get it to work.

Thanks,
Daniel



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel