netdev - Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Nov 2017 14:05:32 +0200
From:   Roman Yeryomin <roman@...em.lv>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        netdev@...r.kernel.org,
        Antti Seppälä <a.seppala@...il.com>,
        Colin Leitner <colin.leitner@...glemail.com>,
        Gabor Juhos <juhosg@...nwrt.org>
Subject: Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

On 2017-11-09 20:08, Florian Fainelli wrote:
> On 11/09/2017 09:24 AM, Andrew Lunn wrote:
>>> The registers writing code is where? switchdev driver?
>>> All I care about is that all the switch specific code should be in 
>>> one
>>> place.
>> 
>> The switch specific code is in the switch specific driver.
>> 
>> Take a look under drivers/net/dsa for the switches which are currently
>> supported by DSA.
> 
> And Roman, if you are thinking about converting existing swconfig
> drivers from OpenWrt/LEDE into DSA, please do it! The conversion is
> reasonably simple even if the APIs do not exactly match. Quite a lot of
> swconfig driers in OpenWrt/LEDE are implemented as phy_device, and the
> conversion for that is to use a proper mdio_device (see
> drivers/net/dsa/b53/b53_mdio.c for an example).

Yes, I'm thinking about that from time to time :)

> For the record, I tried submitting swconfig back in 2013, but this was
> rejected under the premise that it did not follow the simple paradigm
> that switch ports must be network devices. Also, swconfig is too
> permissive in that it allows switch drivers to come up with their own
> netlink attributes, whereas the desire is to standardize as much as
> possible on features, even if there is just one implementation for 
> that.

Yes, saw it back then...

> The downside of not using swconfig is that you need multiple tools,
> iproute2 namely in order to obtain the same type of configuration, but
> this is a small price to pay because DSA is upstream, and upstream
> usually wins, and it wins even more when people start contributing the
> things they see missing.

Fully agree here


Regards,
Roman