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:   Sat, 20 Jun 2020 17:40:08 +0200
From:   Andrew Lunn <>
To:     Antoine Tenart <>
Subject: Re: [PATCH net-next v3 6/8] net: phy: mscc: timestamping and PHC

On Fri, Jun 19, 2020 at 02:22:58PM +0200, Antoine Tenart wrote:
> To get and set the PHC time, a GPIO has to be used and changes are only
> retrieved or committed when on a rising edge. The same GPIO is shared by
> all PHYs, so the granularity of the lock protecting it has to be
> different from the ones protecting the 1588 registers (the VSC8584 PHY
> has 2 1588 blocks, and a single load/save pin).

I guess you thought about this GPIO quite a bit.

It appears you have the mutex in the shared structure, but each PHY
has its own gpio_desc, even though it should be for the same GPIO? The
binding requires each PHY has the GPIO, even though it is the same
GPIO. And there does not appear to be any checking that each PHY
really does have the same GPIO.

Ideally there would be a section in DT for the package, and this GPIO
would be there. But i don't see an good way to do this.

This does not feel right to me, but i've no good idea how it can be
made better :-(


Powered by blists - more mailing lists