Hi Tom, On Mon, 6 Oct 2025 at 15:44, Tom Rini <[email protected]> wrote: > > On Mon, Oct 06, 2025 at 02:38:23PM -0600, Simon Glass wrote: > > Hi Kory, > > > > On Fri, 3 Oct 2025 at 10:34, Kory Maincent <[email protected]> > > wrote: > > > > > > Migrate TI board cape detection from legacy extension support to the > > > new UCLASS-based extension board framework. > > > > > > Signed-off-by: Kory Maincent <[email protected]> > > > --- > > > arch/arm/mach-omap2/am33xx/Kconfig | 2 +- > > > arch/arm/mach-omap2/omap5/Kconfig | 2 +- > > > board/ti/common/cape_detect.c | 24 +++++++++++------------- > > > 3 files changed, 13 insertions(+), 15 deletions(-) > > > > > > diff --git a/arch/arm/mach-omap2/am33xx/Kconfig > > > b/arch/arm/mach-omap2/am33xx/Kconfig > > > index dff4f1cf202..77f7938305b 100644 > > > --- a/arch/arm/mach-omap2/am33xx/Kconfig > > > +++ b/arch/arm/mach-omap2/am33xx/Kconfig > > > @@ -15,7 +15,7 @@ config TARGET_AM335X_EVM > > > select DM_GPIO > > > select DM_SERIAL > > > select TI_I2C_BOARD_DETECT > > > - select SUPPORT_EXTENSION_SCAN > > > + select SUPPORT_DM_EXTENSION_SCAN > > > imply CMD_DM > > > imply SPL_DM > > > imply SPL_DM_SEQ_ALIAS > > > diff --git a/arch/arm/mach-omap2/omap5/Kconfig > > > b/arch/arm/mach-omap2/omap5/Kconfig > > > index 5394529658b..819490a8cf8 100644 > > > --- a/arch/arm/mach-omap2/omap5/Kconfig > > > +++ b/arch/arm/mach-omap2/omap5/Kconfig > > > @@ -38,7 +38,7 @@ config TARGET_AM57XX_EVM > > > select CMD_DDR3 > > > select DRA7XX > > > select TI_I2C_BOARD_DETECT > > > - select SUPPORT_EXTENSION_SCAN > > > + select SUPPORT_DM_EXTENSION_SCAN > > > imply DM_THERMAL > > > imply SCSI > > > imply SPL_THERMAL > > > diff --git a/board/ti/common/cape_detect.c b/board/ti/common/cape_detect.c > > > index 7786bdda5d1..23c93964dc3 100644 > > > --- a/board/ti/common/cape_detect.c > > > +++ b/board/ti/common/cape_detect.c > > > @@ -22,7 +22,7 @@ static void sanitize_field(char *text, size_t size) > > > } > > > } > > > > > > -int extension_board_scan(struct list_head *extension_list) > > > +static int ti_extension_board_scan(struct alist *extension_list) > > > { > > > unsigned char addr; > > > int num_capes = 0; > > > @@ -31,7 +31,7 @@ int extension_board_scan(struct list_head > > > *extension_list) > > > struct am335x_cape_eeprom_id eeprom_header; > > > char process_cape_part_number[17] = {'0'}; > > > char process_cape_version[5] = {'0'}; > > > - struct extension *cape; > > > + struct extension cape = {0}, *_cape; > > > struct udevice *dev; > > > u8 cursor = 0; > > > int ret, i; > > > @@ -78,22 +78,20 @@ int extension_board_scan(struct list_head > > > *extension_list) > > > > I suppose that a method called scan() could be added to the uclass and > > implemented by this driver. > > > > > > > > printf("BeagleBone Cape: %s (0x%x)\n", > > > eeprom_header.board_name, addr); > > > > > > - cape = calloc(1, sizeof(struct extension)); > > > - if (!cape) { > > > - printf("Error in memory allocation\n"); > > > - return num_capes; > > > - } > > > - > > > - snprintf(cape->overlay, sizeof(cape->overlay), > > > "%s-%s.dtbo", > > > + snprintf(cape.overlay, sizeof(cape.overlay), "%s-%s.dtbo", > > > process_cape_part_number, process_cape_version); > > > - strlcpy(cape->name, eeprom_header.board_name, > > > + strlcpy(cape.name, eeprom_header.board_name, > > > sizeof(eeprom_header.board_name)); > > > - strlcpy(cape->version, process_cape_version, > > > + strlcpy(cape.version, process_cape_version, > > > sizeof(process_cape_version)); > > > - strlcpy(cape->owner, eeprom_header.manufacturer, > > > + strlcpy(cape.owner, eeprom_header.manufacturer, > > > sizeof(eeprom_header.manufacturer) + 1); > > > - list_add_tail(&cape->list, extension_list); > > > + _cape = alist_add(extension_list, cape); > > > + if (!_cape) > > > + return -ENOMEM; > > > num_capes++; > > > } > > > return num_capes; > > > } > > > + > > > +U_BOOT_EXTENSION(cape, ti_extension_board_scan); > > > > Can the extension information go in the devicetree, so boards can > > select their scheme that way? > > Since we're scanning to see what extension boards are present and so > what device tree overlays to apply, I don't think that can work?
My understanding is that the scanning process is board-specific. For example we would not want the Beagle mechanism to be compiled into rpi. The idea of scanning things in a board-specific way seems like a driver to me. Note there is also the SYSINFO uclass which can do similar things. The overlays being applied here are additions to what should already be a fairly complete devicetree. If this isn't possible, then where is the information known? Regards, SImon
