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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 6 Mar 2022 19:38:55 +0100 From: Gerhard Engleder <gerhard@...leder-embedded.com> To: Richard Cochran <richardcochran@...il.com> Cc: yangbo.lu@....com, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, mlichvar@...hat.com, Vinicius Costa Gomes <vinicius.gomes@...el.com>, netdev <netdev@...r.kernel.org> Subject: Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time On Sun, Mar 6, 2022 at 6:05 PM Richard Cochran <richardcochran@...il.com> wrote: > > ptp vclocks require a clock with free running time for the timecounter. > > Currently only a physical clock forced to free running is supported. > > If vclocks are used, then the physical clock cannot be synchronized > > anymore. The synchronized time is not available in hardware in this > > case. As a result, timed transmission with ETF/TAPRIO hardware support > > is not possible anymore. > > NAK. > > I don't see why you don't simply provide two PHC instances from this > one device. Because with vclocks the user space interface is already available. Also In my opinion it is a good fit. The second PHC would be based on the free running hardware counter. So it would not provide any additional functionality compared to the vclocks based on it. Are two PHC instances supported? At least for ethtool there is only a single phc_index field. > AFAICT, this series is not needed at all, as the existing API covers > this use case already. I assume that you mean for ETF the transmission time can be converted, similar like for time stamps. So for ETF you are right. It was too quick to mention ETF along with TAPRIO. My use case is TAPRIO with hardware support. For TAPRIO the hardware has to act based on the synchronized time within the TSN network. No transmission times, which could be converted, are used. The hardware is in charge to transmit frames from a certain queue only during defined intervals. These intervals are based on the synchronized time. So the hardware must be synchronized somehow. This is my solution to keep the hardware synchronized while vclocks are in use. How can I cover my use case with the existing API? I had no idea so far. Thanks! Gerhard
Powered by blists - more mailing lists