[RFC PATCH 3/3] efi: Remove support for pointless, unused EFI services

2025-07-13 Thread Ard Biesheuvel
From: Ard Biesheuvel The get/set wakeup time EFI runtime services are often broken, and rarely if ever used in practice. But the GetNextHighMonoCount() EFI runtime services really takes the cake for most pointless API in the history of computing. So let's stop exposing them in Linux, hopefully r

[RFC PATCH 2/3] efi/test: Don't bother pseudo-testing unused EFI services

2025-07-13 Thread Ard Biesheuvel
From: Ard Biesheuvel The EFI test module covers the get/set wakeup time EFI runtime services, as well as GetNextHighMonoCount(). In both cases, though, it just mindlessly exercises the API, without any functional testing. In case of the get/set wakeup time services, this would involve setting th

[RFC PATCH 1/3] efi-rtc: Remove wakeup functionality

2025-07-13 Thread Ard Biesheuvel
From: Ard Biesheuvel The EFI rtc driver is used by non-x86 architectures only, and exposes the get/set wakeup time functionality provided by the underlying platform. This is usually broken on most platforms, and not widely used to begin with [if at all], so let's just remove it. Signed-off-by: A

[RFC PATCH 0/3] Remove unused EFI runtime APIs

2025-07-13 Thread Ard Biesheuvel
From: Ard Biesheuvel Using EFI runtime services to program the RTC to wake up the system is supported in theory, but rarely works in practice. Fortunately, this functionality is rarely [if ever] used to begin with so we can just drop it. (Note that the EFI rtc driver is not used by x86, which pro

Re: [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality

2025-07-13 Thread Demi Marie Obenour
On 7/14/25 02:08, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > The EFI rtc driver is used by non-x86 architectures only, and exposes > the get/set wakeup time functionality provided by the underlying > platform. This is usually broken on most platforms, and not widely used > to begin with [if

Re: [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality

2025-07-13 Thread Ard Biesheuvel
On Mon, 14 Jul 2025 at 16:13, Demi Marie Obenour wrote: > > On 7/14/25 02:08, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > > > The EFI rtc driver is used by non-x86 architectures only, and exposes > > the get/set wakeup time functionality provided by the underlying > > platform. This is usu

Re: [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality

2025-07-13 Thread Demi Marie Obenour
On 7/14/25 02:19, Ard Biesheuvel wrote: > On Mon, 14 Jul 2025 at 16:13, Demi Marie Obenour > wrote: >> >> On 7/14/25 02:08, Ard Biesheuvel wrote: >>> From: Ard Biesheuvel >>> >>> The EFI rtc driver is used by non-x86 architectures only, and exposes >>> the get/set wakeup time functionality provi

Re: [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality

2025-07-13 Thread Ard Biesheuvel
On Mon, 14 Jul 2025 at 16:22, Demi Marie Obenour wrote: > > On 7/14/25 02:19, Ard Biesheuvel wrote: > > On Mon, 14 Jul 2025 at 16:13, Demi Marie Obenour > > wrote: > >> > >> On 7/14/25 02:08, Ard Biesheuvel wrote: > >>> From: Ard Biesheuvel > >>> > >>> The EFI rtc driver is used by non-x86 arch

Re: [XEN PATCH v2] misra: address violation of MISRA C Rule 10.1

2025-07-13 Thread Jan Beulich
On 12.07.2025 00:00, Stefano Stabellini wrote: > On Fri, 11 Jul 2025, Dmytro Prokopchuk1 wrote: >> Hi All. >> >> In this 2nd version I made changes according to the >> https://patchew.org/Xen/d92cf08a64d8197a1d1a45f901e59183105d3da5.1752183472.git.dmytro._5fprokopch...@epam.com/ >> >> There are 0 v

RE: Discussion on the delayed start of major frame with ARINC653 scheduler

2025-07-13 Thread Nathan Studer
On 7/10/25 2:36, Choi, Anderson wrote: > What would be the next step? Will you submit the patch or should I revise the > patch I have already submitted with the change you suggested? I do not have a preference, but since you already have a patch thread started, it is probably easiest to just hav

Re: [PATCH v3 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions

2025-07-13 Thread Sergii Dmytruk
On Tue, Jul 08, 2025 at 08:52:36AM +0200, Jan Beulich wrote: > On 07.07.2025 19:31, Sergii Dmytruk wrote: > > On Mon, Jul 07, 2025 at 10:29:46AM +0200, Jan Beulich wrote: > ... then isn't used right here, instead requiring a cast somewhere > (presumably, > as code using this isn't v

Re: [PATCH v3 03/22] x86/boot: add MLE header and Secure Launch entry point

2025-07-13 Thread Sergii Dmytruk
On Tue, Jul 08, 2025 at 09:02:55AM +0200, Jan Beulich wrote: > >>> +.long 0x00020002 /* MLE version 2.2 */ > >>> +.long (slaunch_stub_entry - start) /* Linear entry point of > >>> MLE (SINIT virt. address) */ > >>> +.long 0x /* First valid page of MLE */ >

[PATCH] xen: Remove some deadcode (x)

2025-07-13 Thread linux
From: "Dr. David Alan Gilbert" Remove three uncalled functions: xenbus_mkdir() was added in 2007 by commit 4bac07c993d0 ("xen: add the Xenbus sysfs and virtual device hotplug driver") but has remained unused. xen_get_runstate_snapshot() last use was removed in 2016 by commit 6ba286ad8457 ("