Re: [PATCH RFC v4 02/13] efi: bgrt: export the BGRT table and image size

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 2 Oct 2026, at 12:31, Màxim Pedraza Padilla wrote:
> Hi Jani,
>
> On Fri, 02 Oct 2026, Jani Nikula wrote:
>> Data is not an interface.
>>
>> If these will be used more, perhaps it would be better to wrap access to
>> them in functions? I think most of the time it will help with
>> maintenance.
>>
>> And you can add stubs for CONFIG_ACPI_BGRT=n where they belong,
>> i.e. include/linux/efi-bgrt.h instead of drm_splash.c like in patch 11
>> of this series.
>
> Agreed, and the same goes for your comment on patch 3. For v5 I would
> replace the export with accessors in efi-bgrt.c, stubbed in
> efi-bgrt.h for CONFIG_ACPI_BGRT=n:
>
>       bool efi_bgrt_has_image(void);
>       phys_addr_t efi_bgrt_image_address(void);
>       size_t efi_bgrt_image_size(void);
>       u8 efi_bgrt_status(void);
>       u32 efi_bgrt_image_offset_x(void);
>       u32 efi_bgrt_image_offset_y(void);
>
> The splash client then drops its own wrappers and stubs, and the
> "static inline" in drm_splash.c go as well.
>
> drivers/acpi/bgrt.c is the only other user of bgrt_tab and
> bgrt_image_size. I can move it to the accessors too, so that both
> variables become static, if that is wanted; otherwise they stay
> global for it and are no longer exported.
>
> Ard, this changes the patch you acked, so I will not carry your
> Acked-by unless the above works for you. Both variables become
> __ro_after_init either way, as you asked.
>

This sounds good to me - please cc me again on the result and
I'll take another look.