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: <a7d99915-a65e-8f3d-67da-57fe39986bd3@hauke-m.de>
Date:   Tue, 13 Apr 2021 23:49:39 +0200
From:   Hauke Mehrtens <hauke@...ke-m.de>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kuba@...nel.org, davem@...emloft.net, olteanv@...il.com,
        f.fainelli@...il.com, vivien.didelot@...il.com
Subject: Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping
 the registers

On 4/13/21 12:24 AM, Martin Blumenstingl wrote:
> Hi Andrew,
> 
> On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn <andrew@...n.ch> wrote:
>>
>> On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
>>> Add support for .get_regs_len and .get_regs so it is easier to find out
>>> about the state of the ports on the GSWIP hardware. For this we
>>> specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
>>> register #defines as these contain the current port status (as well as
>>> the result of the auto polling mechanism). Other global and per-port
>>> registers which are also considered useful are included as well.
>>
>> Although this is O.K, there has been a trend towards using devlink
>> regions for this, and other register sets in the switch. Take a look
>> at drivers/net/dsa/mv88e6xxx/devlink.c.
>>
>> There is a userspace tool for the mv88e6xxx devlink regions here:
>>
>> https://github.com/lunn/mv88e6xxx_dump
>>
>> and a few people have forked it and modified it for other DSA
>> switches. At some point we might want to try to merge the forks back
>> together so we have one tool to dump any switch.
> actually I was wondering if there is some way to make the registers
> "easier to read" in userspace.
> It turns out there is :-)
> 
> Hauke, which approach do you recommend?:
> - update this patch with your suggestion and ask Andrew to still merge
> it soon-ish
> - put this topic somewhere on my or your TODO-list and come up with a
> devlink solution at some point in the future

Would you work on the devlink solution in the next weeks?
I think this is part of the ABI when we add it, can we later remove the 
ethtool registers when we add devlink support or is this not allowed?

Hauke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ