<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 17 мая 2019 г., 23:18 Christian Lamparter <<a href="mailto:chunkeey@gmail.com" target="_blank" rel="noreferrer">chunkeey@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, May 15, 2019 9:35:28 PM CEST Petr Štetiar wrote:<br>
> Павел <<a href="mailto:be.dissent@gmail.com" rel="noreferrer noreferrer" target="_blank">be.dissent@gmail.com</a>> [2019-05-15 22:14:41]:<br>
> <br>
> > Not a problem, actually, but I've been suggested to squash them :)<br>
> > <a href="https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897</a><br>
> <br>
> ok, thanks for the background, but still, squashing doesn't mean changing<br>
> authorship and Christian has probably also warned you beforehand :-)<br>
<br>
Did it occure to anybody to look at these two patches for a second<br>
before writing long essays about that's right and not? Because Patch<br>
"one" is incomplete and the second patch is clearly doing a "FIXUP"<br>
for the first. That's why they should be squashed. I do think, you'll<br>
be just ignored if you try to post these as-is with your signed-off<br>
on the linux-msm-arm. But then, why not give it a shot, this would<br>
make for some good laughs if it went through as-is.<br>
<br>
But from what I noticed, nobody did any of the requested perf<br>
testing. These are absolutely necessary because the switch<br>
from kpss-v1 to kpss-v2 clearly did have an big impact on the<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Actually I've compared openssl benchmark (difference that you've mentioned) between kpss-acc-v2 and this one - there's completely no difference that I could notice. For example sha256 produces the same result. Here's cortex-a7acc edition:</div><div dir="auto"><div dir="auto">root@OpenWrt:~# openssl speed sha256</div><div dir="auto">Doing sha256 for 3s on 16 size blocks: 859807 sha256's in 3.00s</div><div dir="auto">Doing sha256 for 3s on 64 size blocks: 493458 sha256's in 3.00s</div><div dir="auto">Doing sha256 for 3s on 256 size blocks: 219786 sha256's in 3.00s</div><div dir="auto">Doing sha256 for 3s on 1024 size blocks: 68287 sha256's in 3.00s</div><div dir="auto">Doing sha256 for 3s on 8192 size blocks: 9187 sha256's in 3.00s</div><div dir="auto">Doing sha256 for 3s on 16384 size blocks: 4619 sha256's in 3.00s</div><div dir="auto">OpenSSL 1.1.1b  26 Feb 2019</div><div dir="auto">built on: Thu May 16 12:57:06 2019 UTC</div><div dir="auto">options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) </div><div dir="auto">compiler: arm-openwrt-linux-muslgnueabi-gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -O3 -fpic -ffunction-sections -fdata-sections -znow -zrelro -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -DOPENSSL_PREFER_CHACHA_OVER_GCM</div><div dir="auto">The 'numbers' are in 1000s of bytes per second processed.</div><div dir="auto">type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes</div><div dir="auto">sha256            4585.64k    10527.10k    18755.07k    23308.63k    25086.63k    25225.90k</div></div><div dir="auto"><br></div><div dir="auto">I'm not pasting the kpss-acc-v2 result because it doesn't differ.</div><div dir="auto"><br></div><div dir="auto">But I indeed noticed 2x difference between oem firmware that is probably still on kpss-acc-v1.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
performance. So let's not break anything because of a possible<br>
incomplete patch (that might or might not require "ROM" support<br>
that might or might not be present on all devices).<br>
<br>
> "(Note: In some of the patches the "Author" in the commits is dissent1! So<br>
>   watch out before sending them off)"<br>
> <br>
> > Shouldn't the dev send the patch directly to me in order to be able to post<br>
> > it on his behalf, like openwrt submitting patches guideline describes?<br>
> <br>
> From the kernel docs[1]:<br>
> <br>
> "The contribution is based upon previous work that, to the best of my<br>
>  knowledge, is covered under an appropriate open source license and I have the<br>
>  right under that license to submit that work with modifications, whether<br>
>  created in whole or in part by me, under the same open source license (unless<br>
>  I am permitted to submit under a different license), as indicated in the file;"<br>
> <br>
> so in short, kernel is covered by GPLv2 which allows you to do this if you<br>
> retain the authorship.<br>
The other aspect of this is that you can also "offload" some of the blame<br>
with retaining the original authorship if the patch goes sour. Because as<br>
you have seen even the benight 32KHz (32000Hz vs 32768Hz) non-issue<br>
(since it gets "rounded down" by the qcom-clk to 32000 see kernel debug)<br>
can be a hot topic with conflicting "facts". Simply because we don't know<br>
how the clock count is attained. If it's an external osc then it's probably<br>
the "round" 32768 Hz, but if this sleep clock is generated from the 48 MHz<br>
Osc reference (which we know is there, because these osc are big enough to<br>
be spotted by looking at the PCB) then a "odd" 32000Hz is possible.<br>
<br>
(That said, the highres timer fix seems to be definitely a winner. <br>
I'm glad that you spotted it).<br>
<br>
Regrads,<br>
Christian<br>
<br>
<br>
</blockquote></div></div></div>