Openssl hackers wanted
Hi, I'm aware of a project that needs Secure Enclave[1], [2] (TrustZone or Trusted Execution Environment [TEE]) support added to Openssl 3.0.x for Android [3] and iOS secure keystores. Probably at some point also for TPM keystores. Anyway, an RFP went out to the Openssl developer community but no one has responded, so I thought I'd mention it here. I'm working on some projects that could stand to benefit from Secure Enclave providers being added to Openssl, so I'm happy to facilitate making introductions, etc. This is a broad community here with some vary diverse and eclectic talent, so I'm hoping someone might be capable. Reply to me privately. Thanks, -Philip [1] https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a [2] https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web [3] https://developer.android.com/training/articles/keystore ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] octeontx: add linux 5.10 testing kernel support
On Fri, 2021-09-03 at 15:08 +0200, Daniel Danzberger wrote: > > > > > > +CONFIG_HZ=250 > > > > Why 250 Hz? Does the 100 Hz all other targets use cause any > > measurable > > increase in latency? > > [snipped] > I did not notice this changed. The config I made for 5.10 was before > your commit 3326b5e75c277b4fac21bffd2085df4aa40d2775 which changed > the > default frequency to 100 Hz. > There should be no issue with 100 Hz on octecontx, but I will confirm > this with new builds on my test devices. Confirmed. No issues here with 100 Hz. > > > > > > +CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y > > > > CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y might not be a performance > > win, > > especially with only 1 GiB of RAM. Should be measured, otherwise > > MADVISE should be selected instead. > Same here, it was selected in the 5.4 kernel config and I have only > run > tested with this option so far. > Let me do some benchmarking with MADVISE before we continue here ... Looks like none of the processes running even gets a huge page: -- root@OpenWrt:~# grep AnonHugePages /proc/meminfo AnonHugePages: 0 kB root@OpenWrt:~# -- Even my test tool that just allocs one 8MB block doesn't get one. Looks like CONFIG_TRANSPARENT_HUGEPAGE isn't working on this platform. > > > > Best regards, > > Rui > > > -- Regards Daniel Danzberger embeDD GmbH, Alter Postplatz 2, CH-6370 Stans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.0 - First Stable Release
Hauke Mehrtens wrote on Sat Sep 4 16:16:04 PDT 2021: > Hi, > > The OpenWrt community is proud to announce the first stable release of the OpenWrt 21.02 stable version series. > ... Who could edit the download server's front page? https://downloads.openwrt.org/ still calls 21.02 as "Upcoming", "currently in the release candidate phase" and advertises rc4. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Broken ARP broadcast on master (commit 0f688797)
Hi Felix,
On 9/6/21 2:18 PM, Felix Fietkau wrote:
>
>> On 6. Sep 2021, at 02:03, David Bauer wrote:
>>
>> Hi Felix,
>>
>> updating my Wireless APs (ath9k+ath10k / mt7603+mt7915) broke ARP broadcast
>> delivery to clients
>> connected to the radios with SW rate control.
>>
>> Bisecting this problem revealed commit 0f688797 ("mac80211: add missing
>> change for encap offload
>> on devices with sw rate control") introduces this problem, reverting it
>> restored the desired
>> functionality.
>>
>> Can you have a look what is going wrong here?
>
>
> Hi David,
>
> Please try the latest version, it should resolve the issue
Thanks, your patch fixes this issue.
And also thanks for submitting a fix upstream.
Best
David
>
> Thanks,
> - Felix
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: GPIO mapping on Onion Omega2+ (MT7688)
Hi John, Thanks! This is great info. I was able to apply that patch but I gather something changed with the gpiochip struct since this patch was valid: drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe': drivers/gpio/gpio-mt7621.c:244:11: error: 'struct gpio_chip' has no member named 'offset'; did you mean 'set'? rg->chip.offset = bank * MTK_BANK_WIDTH; ^~ set make[7]: *** [scripts/Makefile.build:262: drivers/gpio/gpio-mt7621.o] Error 1 I haven't had as much time as I'd like to work on this, I'm not sure it matters much for my purpose since the following is working: gpioset -m wait gpiochip0 1=1 So it sounds like I do have working gpio, and maybe I will be able to make flashing the arduino dock work. Mike > On 2021/08/31, at 07:22:08 CDT (-05:00), John Thomson > wrote: > > Hi Mike, > > On Mon, 30 Aug 2021, at 21:05, Mike Bernardo wrote: > >> root@onion1:~# echo 15 > /sys/class/gpio/export >> ash: write error: Invalid argument >> >> I guess the number I specify to export would need to be at least 416? > > Yes, that's it. > You need to add the Linux gpiochip base to the (SoC) GPIO number you want to > use. > You may need to try each bank to get the correct one. > See https://openwrt.org/docs/techref/hardware/port.gpio#software > >> All of the GPIOs are unlableled, am I missing some type of ACPI mapping >> table? Or some kind of mapping in U-boot? > > If you want these names populated, > you can add the details to your dts file. > The Linux binding documentation shows how (gpio-line-names): > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/gpio/gpio.txt > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7628an_onion_omega2.dtsi > shows that GPIO 38 is a reset button, and 44 is the system LED, > so you could have 38 blank names: "", and the 39th as "reset" > >> I can create all of the GPIOs from 416-511 and they show in >> /sys/kernel/debug/gpio but most are labeled with "sysfs", I guess I was >> looking for one to be labeled like "GPIO15"? > > sysfs here is the driver that has claimed this GPIO number, > because you (or something else) has exported that gpio number in > /sys/class/gpio/ > >> It seems crazy it would have 3 GPIO chips with 32 lines each, so >> something seems wrong. > > Expected: This is the way this system on a chip is built. > >> Is it possible this might help? >> >> http://patchwork.ozlabs.org/project/linux-gpio/patch/20210727152026.31019-3-sergio.paracuel...@gmail.com/ > > That patch is part of a series which fixes lazy labelling: > An incomplete gpio-line-names array (where the number of passed > named are less than ngpios) > > > Hope that helps. > > -- > John Thomson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Broken ARP broadcast on master (commit 0f688797)
Hi, Felix, On Mon, 6 Sept 2021 at 13:19, Felix Fietkau wrote: > > Please try the latest version, it should resolve the issue I know I'm not the original complainer, but I tested a while ago and indeed this revert fixes the broadcast issue for me. :) Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Broken ARP broadcast on master (commit 0f688797)
> On 6. Sep 2021, at 02:03, David Bauer wrote:
>
> Hi Felix,
>
> updating my Wireless APs (ath9k+ath10k / mt7603+mt7915) broke ARP broadcast
> delivery to clients
> connected to the radios with SW rate control.
>
> Bisecting this problem revealed commit 0f688797 ("mac80211: add missing
> change for encap offload
> on devices with sw rate control") introduces this problem, reverting it
> restored the desired
> functionality.
>
> Can you have a look what is going wrong here?
Hi David,
Please try the latest version, it should resolve the issue
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
