Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32
>> mask, int m, u32 num_mb)
>> test_hash_speed("streebog512", sec,
>> generic_hash_speed_template);
>> if (mode > 300 && mode < 400) break;
>> -fallthrough;
>> +break;
>> case 399:
>> break;
>
> Just imho, this change makes the preceding 'if' look even more
> pointless. Maybe the fallthrough was a deliberate choice? Not that my
> opinion matters here as I don't know this module, but it looked a bit
> odd to me.
>
Yea this does look very odd..
Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
In contrast to the standard Linux system clock, a PHC is adjustable in hardware, for example using frequency compensation registers or a VCO. The ability to directly tune the PHC is essential to reap the benefit of hardware timestamping. There is a reason for not being able to shift posix clocks: The system has one time base. The various clocks are contributing to maintaining that sytem wide time. Adjusting clocks is absolutely essential for proper functioning of the PTP protocol. The slave obtains and calculates the offset from master and uses that in order to adjust the clock properly, The problem is that the timestamps are done via the hardware. We need a method to expose that hardware so that the ptp software can properly adjust those clocks. I do not understand why you want to maintain different clocks running at different speeds. Certainly interesting for some uses I guess that I do not have the energy to imagine right now. But can we get the PTP killer feature of synchronized accurate system time first? The problem is maintaining a hardware clock at the correct speed/frequency and time. The timestamping is done via hardware, and that hardware clock needs to be accurate. We need to be able to modify that clock. Yes, having the system time be the same value would be nice, but the problem comes because we don't want to jump through hoops to keep that hardware clock accurate to the ptp protocol running on the network. Instead, the patch set provides a way to offer a Pulse Per Second (PPS) event from the PHC to the Linux PPS subsystem. A user space application can read the PPS events and tune the system clock, just like when using other external time sources like radio clocks or GPS. User space is subject to various latencies created by the OS etc. I would that in order to have fine grained (read microsecond) accurary we would have to run the portions that are relevant to obtaining the desired accuracy in the kernel. All of the necessary features for microsecond or better accuracy are done via the hardware. You can get accuracy to within 10 mircoseconds while only sending sync packets and such once per second. The reason is because the hardware timestamps are very accurate. But if we can't properly adjust the clocks time and frequency, we cannot maintain the accuracy of the timestamps. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Fri, Aug 27, 2010 at 8:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote system time bimble track a source makes sense just as with NTP but making it a new clock seems the wrong model extending a non-too-bright API when you can just put the time sources in a file tree. Don't get your meaning here, what did you mean by file tree? Something like /sys/class/timesource/name/... at which point we don't have to enumerate them all, add special system calls and then fret about the fact you can't access them from things like shell scripts. I agree that this interface is the best way to be future proof. This appears to allow for multiple clocks or nodes, and doesn't get messed up when we add more than one NIC with separate clocks to a machine. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
