Hi Jan, all, I cannot make the meeting today, apologies. Kind regards, Chris

cip-gitlab/ci/pavel/linux-test smc: 9 runs, 1 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab | compiler |

cip-gitlab/ci/pavel/linux-test ltp-timers: 8 runs, 8 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab |

cip-gitlab/ci/pavel/linux-test kselftest-futex: 9 runs, 1 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab |

cip-gitlab/ci/pavel/linux-test kselftest-filesystems: 9 runs, 1 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab

cip-gitlab/ci/pavel/linux-test baseline-nfs: 34 runs, 2 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab |

cip-gitlab/ci/pavel/linux-test baseline: 111 runs, 12 regressions (v5.10.147-cip18-12-gcb2b164780be) Regressions Summary ------------------- platform | arch | lab |

cip-gitlab/ci/pavel/linux-test build: 176 builds: 3 failed, 173 passed, 4 errors, 10 warnings (v5.10.147-cip18-12-gcb2b164780be) Full Build Summary:

From: Quirin Gylstorff <quirin.gylstorff@...> This allows using the Debian upstream version of efibootguard in place. Also add the new libebgenv to the installation. This fixes the missing

Yes, performance is one thing, also it will avoid unnecessary races when you start handling IRQ's in both the cores. Eg:- ch0 IRQ handler executed on core0 and ch1 IRQ handler on core 1,

Hi! I understand it is just a performance tweak. Correct me if I'm wrong. If there are no other comments and if testing passes I can apply the patch. Best regards, Pavel -- DENX Software

IRQ processing should be fast as possible. You are improving latency of the system by avoiding unnecessary checks and by calling an unwanted function call. If it is shared IRQ, then it make sense

Hi! Understood, but checking ch1 status on ch0 IRQ is not going to cause any problems, right? Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang

Basically, tx IRQs are channel specific. Previously if any txIRQ is triggered, you are unnecessarily Checking IRQ status of the txIRQ which is not triggered. For eg: if ch0 IRQ is triggered you are

Hi! Can you elaborate what "the issue" is? AFAICT the code worked before, and will work after the patch, with maybe tiny little less overhead after the patch? Thanks and best

Hi all, Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today. Our channel is the following: irc:irc.libera.chat:6667/cip The IRC meeting

Hi ! It's this week's CVE report. This week reported 6 new CVEs and 3 updated CVEs. CVE-2022-44034, CVE-2022-44032, and CVE-2022-44033 are related issues. * New CVEs CVE-2022-3544: A memory leak

commit d887087c896881715c1a82f1d4f71fbfe5344ffd upstream. RZ/G2L has separate channel specific IRQs for transmit and error interrupts. But the IRQ handler processes both channels, even if there no

Oh, sorry, I confused optee and tf-a. Jan -- Siemens AG, Technology Competence Center Embedded Linux

Pulling now from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot/trusted -firmware-a-${PV}.tar.gz Where do you see a 3.19? All I can find is a 2.7 fixed build mean Moved into