netdev - Re: [PATCH] DSA support for Micrel KSZ8895

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]

Message-ID: <20170902154014.GA21453@amd>
Date:   Sat, 2 Sep 2017 17:40:14 +0200
From:   Pavel Machek <pavel@....cz>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Tristram.Ha@...rochip.com, Woojung.Huh@...rochip.com,
        nathan.leigh.conrad@...il.com, vivien.didelot@...oirfairelinux.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew@...n.ch
Subject: Re: [PATCH] DSA support for Micrel KSZ8895

Hi!

> >>>> Section 4.8 of the datasheet says:
> >>>>
> >>>> 	All the registers defined in this section can be also accessed
> >>>> 	via the SPI interface.
> >>>>
> >>>> Meaning all PHY registers can be access via the SPI interface. So you
> >>>> should be able to make a standard Linux MDIO bus driver which performs
> >>>> SPI reads.
> >>>
> >>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
> >>> accessed over the SPI, they are just shuffled around... hence MDIO
> >>> emulation code. I copied it from their code (see the copyrights) so no, I don't
> >>> believe there's nicer solution.
> >>>
> >>> Best regards,
> >>
> >> Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
> >>
> > 
> > Well, thanks for heads up... but its too late to stop now. I already
> > have working code, without the advanced features.
> 
> No driver has landed yet nor has any driver been posted in a proper form
> or shape, so at this point neither of you are able to make any claims as
> to which one should be chosen.

I certainly do not want to make any claims. Tristram's driver is
likely to support all (most?) features of the chip, which is not my
goal.

> > I don't know how far away you are with the development. You may want
> > to start from my driver (but its probably too late now).
> 
> I would tend to favor Tristram's submission when we see it because he
> claims support for more devices and it is likely to be backed and
> maintained by Microchip in the future.

Well, I guess we decide when we see the code, that's how it works, right?

> I am sure there will be opportunity for you to contribute a lot to this
> driver. Of course, this all depends on the code quality and timing, but
> having two people work on the same things in parallel is just a complete
> waste of each other's time so we might as well wait for Tristram to post
> the said driver and define a plan of action from there?

Well, it would be good to see the code, so we can judge the
quality. Normally, code is posted before testing, so this kind of
problems does not arise.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)