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  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, 1 Sep 2017 15:18:12 -0700
From:   Florian Fainelli <>
To:     Pavel Machek <>,
Subject: Re: [PATCH] DSA support for Micrel KSZ8895

On 09/01/2017 05:15 AM, Pavel Machek wrote:
> Hi!
> On Wed 2017-08-30 21:32:07, wrote:
>>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
>>>>> I may be confused here, but AFAICT:
>>>>> 1) Yes, it has standard layout when accessed over MDIO.
>>>> 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 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.

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?

Powered by blists - more mailing lists