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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 17 Jul 2018 00:31:02 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Rob Herring <robh@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, openwrt-devel@...ts.openwrt.org,
        LEDE Development List <lede-dev@...ts.infradead.org>,
        Antti Seppälä <a.seppala@...il.com>,
        Roman Yeryomin <roman@...em.lv>,
        Colin Leitner <colin.leitner@...glemail.com>,
        Gabor Juhos <juhosg@...nwrt.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

> > +Realtek SMI-based Switches
> > +==========================
> > +
> > +The SMI "Simple Management Interface" is a two-wire protocol using
> 
> At least for some other Realtek chips, the documentation I find says the 
> S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.
> 
> Just want to make sure we don't define GPIOs directly when there should 
> be a layer of abstraction like mdio-gpio.

Hi Rob

There was a bit of discussion about this with the RFC patches. The bit
stream protocol used here is not that used by SMI in MDIO. It is
something proprietary to Realtek. I don't expect we will be re-using
the code with other vendors. The only real reason to abstract this out
is if there happens to be other Realtek switches which uses the same
SMI bitstream, but have completely different registers, meaning a
separate DSA driver would be needed. The SMI code is well structured,
so it should not be too hard to turn it into a library which drivers
can share.

So i personally don't see a problem with this.

   Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ