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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <42094a87-09e6-1278-97c5-b6faaaca0a95@pobox.com>
Date:   Sat, 8 Jun 2019 19:12:41 -0500
From:   Daniel Santos <daniel.santos@...ox.com>
To:     Daniel Golle <daniel@...rotopia.org>
Cc:     Felix Fietkau <nbd@....name>,
        openwrt-devel <openwrt-devel@...ts.openwrt.org>,
        netdev@...r.kernel.org, Vitaly Chekryzhev <13hakta@...il.com>,
        Luis Soltero <lsoltero@...balmarinenet.com>
Subject: Re: [OpenWrt-Devel] Using ethtool or swconfig to change link settings
 for mt7620a?

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