> >> I'm currently working on an RFC to propose a rework of the fpga > >> subsystem in order to make it more aligned with the device model. One of > >> the ideas I'm experimenting with is having a bus (struct bus_type) for > >> fpga regions (devices) so that we can have region drivers that could > >> handle internal device enumeration/management whenever a new region is > >> configured on the fabric. Does this make sense in your opinions? > > > > mm.. I didn't fully understand the need to have a region driver, what's > > the issue to solve? > > > > Sorry for the late reply. The general idea is to handle regions in a way > that is more aligned with the device model without having to resort to > extra ops and additional devices. > > Having an fpga bus would allow us to handle enumeration using proper > region drivers (in the device model sense of the term, i.e., struct > device_driver) instead of derived region devices. > > On second thought, I think having a reconfiguration interface at the > fpga manager level is sounder than having it at the region level (one > for each region). I don't think so. A firmware image may contain enumeration info, e.g. of-fpga-region. And I think the fpga-region should parse these enumeration info rather than fpga manager. fpga manager should only deal with content writing stuff and not be exposed to user. > > With that in place, the fpga manager could request a firmware image, > parse it, write the content into the fpga configuration memory, and then > instantiate the region devices and add them to its fpga bus. Then, if I think an fpga-region is always there no matter it is cleared, being reprogrammed, or working. So I don't think an fpga-region needs to be re-instantated. The sub devices inside fpga-region needs re-instantating. That's also why I'm hesitating to fpga bus. Thanks, Yilun > there is a match, a specific region driver can handle the enumeration > within the new region. > > What do you think? > > Thanks, > Marco >
