[OpenWrt-Devel] [PATCH 4/4] ipq40xx: add support for secondary cores bringup

[Павел]

пт, 17 мая 2019 г., 23:18 Christian Lamparter <chunkeey at gmail.com>:

> On Wednesday, May 15, 2019 9:35:28 PM CEST Petr Štetiar wrote:
> > Павел <be.dissent at gmail.com> [2019-05-15 22:14:41]:
> >
> > > Not a problem, actually, but I've been suggested to squash them :)
> > > https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897
> >
> > ok, thanks for the background, but still, squashing doesn't mean changing
> > authorship and Christian has probably also warned you beforehand :-)
>
> Did it occure to anybody to look at these two patches for a second
> before writing long essays about that's right and not? Because Patch
> "one" is incomplete and the second patch is clearly doing a "FIXUP"
> for the first. That's why they should be squashed. I do think, you'll
> be just ignored if you try to post these as-is with your signed-off
> on the linux-msm-arm. But then, why not give it a shot, this would
> make for some good laughs if it went through as-is.
>
> But from what I noticed, nobody did any of the requested perf
> testing. These are absolutely necessary because the switch
> from kpss-v1 to kpss-v2 clearly did have an big impact on the
>

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:
root at OpenWrt:~# openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 859807 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 493458 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 219786 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 68287 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 9187 sha256's in 3.00s
Doing sha256 for 3s on 16384 size blocks: 4619 sha256's in 3.00s
OpenSSL 1.1.1b  26 Feb 2019
built on: Thu May 16 12:57:06 2019 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr)
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
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes  16384 bytes
sha256            4585.64k    10527.10k    18755.07k    23308.63k
25086.63k    25225.90k

I'm not pasting the kpss-acc-v2 result because it doesn't differ.

But I indeed noticed 2x difference between oem firmware that is probably
still on kpss-acc-v1.

performance. So let's not break anything because of a possible
> incomplete patch (that might or might not require "ROM" support
> that might or might not be present on all devices).
>
> > "(Note: In some of the patches the "Author" in the commits is dissent1!
> So
> >   watch out before sending them off)"
> >
> > > Shouldn't the dev send the patch directly to me in order to be able to
> post
> > > it on his behalf, like openwrt submitting patches guideline describes?
> >
> > From the kernel docs[1]:
> >
> > "The contribution is based upon previous work that, to the best of my
> >  knowledge, is covered under an appropriate open source license and I
> have the
> >  right under that license to submit that work with modifications, whether
> >  created in whole or in part by me, under the same open source license
> (unless
> >  I am permitted to submit under a different license), as indicated in
> the file;"
> >
> > so in short, kernel is covered by GPLv2 which allows you to do this if
> you
> > retain the authorship.
> The other aspect of this is that you can also "offload" some of the blame
> with retaining the original authorship if the patch goes sour. Because as
> you have seen even the benight 32KHz (32000Hz vs 32768Hz) non-issue
> (since it gets "rounded down" by the qcom-clk to 32000 see kernel debug)
> can be a hot topic with conflicting "facts". Simply because we don't know
> how the clock count is attained. If it's an external osc then it's probably
> the "round" 32768 Hz, but if this sleep clock is generated from the 48 MHz
> Osc reference (which we know is there, because these osc are big enough to
> be spotted by looking at the PCB) then a "odd" 32000Hz is possible.
>
> (That said, the highres timer fix seems to be definitely a winner.
> I'm glad that you spotted it).
>
> Regrads,
> Christian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190518/832007c7/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel