On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote: > Am 29.06.23 um 14:35 schrieb Arnd Bergmann: >> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote: >>> The global variable edid_info contains the firmware's EDID information >>> as an extension to the regular screen_info on x86. Therefore move it to >>> <asm/screen_info.h>. >>> >>> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on >>> architectures that don't provide edid_info. Select it on x86. >> >> I'm not sure we need another symbol in addition to >> CONFIG_FIRMWARE_EDID. Since all the code behind that >> existing symbol is also x86 specific, would it be enough >> to just add either 'depends on X86' or 'depends on X86 || >> COMPILE_TEST' there? > > FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO > announces an architecture feature. They do different things. I still have trouble seeing the difference. > Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA > systems. In the future, I want to add support for EDID data from EFI and > OF as well. It would be stored in edid_info. I assume that the new > symbol will become useful then. I don't see why an OF based system would have the same limitation as legacy BIOS with supporting only a single monitor, if we need to have a generic representation of EDID data in DT, that would probably be in a per device property anyway. I suppose you could use FIRMWARE_EDID on EFI or OF systems without the need for a global edid_info structure, but that would not share any code with the current fb_firmware_edid() function. Arnd