Re: [RFC v3 1/1] fpga-region: Introduce ConfigFS interface for runtime FPGA configuration

[Xu Yilun]

> I’ve implemented the FPGA Region ConfigFS interface with the following hierarchy:
> 
> /configfs
> └── fpga_regions             ← Registered via configfs_register_subsystem()
>       └── region0                ← Added using configfs_add_default_group()
>            └── my_image      ← Created via mkdir from userspace
>                 ├── firmware    ← Write firmware name here
>                 └── config        ← Trigger programming/unloading

Yes this is good to me.

> Observation:
> If configfs is not mounted before configfs_add_default_group() is invoked
> (e.g., when regions are registered early via base DTB), the path
> /configfs/fpga_regions/region0 does not appear in userspace,
> even though it’s properly initialized in the kernel.
> 
> This appears to be due to how default groups function.
> they require the configfs filesystem to be mounted prior to the group
> addition in order to be visible. As a result, the mount order becomes
> a strict dependency, which may affect or break early-boot FPGA flows
> where regions are created before configfs is available.

I don't have answer here. But IIUC you are describing some generic
problem of configfs_add_default_group(). According to configfs.rst,
subsystem is also a config_group so it doesn't make sense to me a
subsystem works but a default subgroup can't. Unless configfs people
have proper justification, your observation is a bug and should try to
fix it.

> 
> Proposal:
> Use configfs_register_subsystem(&region->cfg_subsys) for each FPGA region
> instead of relying on configfs_add_default_group().

This seems a workaround. I don't prefer we give up on it so early...

Thanks,
Yilun

> 
> This approach places each FPGA region directly under /configfs/region0,
> avoiding the timing issues associated with default groups.
> The interface becomes available as soon as configfs is mounted.
> regardless of when the region was registered
> (boot time via base DTB or dynamically via overlays).
> 
> New user hierarchy:
> /configfs
> └── region0              ← Region appears as its own root node
>       └── my_image   ← Created via mkdir from userspace
>            ├── firmware ← Write firmware name here
>            └── config     ← Trigger programming/unloading
> 
> Would like to know if this approach looks good, or if there are better
> suggestions to handle this scenario?
> 
> Regards,
> Navakishore.