mad-jrodriguez
commented
1 year ago Hi guys,
After 2 days of investigation, here they are the conclusions that @mad-jsanjuan and I have found:
First of all, we have looked for the MEN drivers that are part of the upstream kernel. Below, the list such drivers.
| IP Core | File Path |
|---|---|
| Z125 | drivers/tty/serial/8250/8250_men_mcb.c |
| Z135 | drivers/tty/serial/men_z135_uart.c |
| Z069 | drivers/watchdog/menz69_wdt.c |
| Z188 | drivers/iio/adc/men_z188_adc.c |
| Z127 | drivers/gpio/gpio-menz127.c |
After that, I have just checked which kind of driver are in MDIS:
| IP Core | MDIS Driver type |
|---|---|
| Z125 | Native |
| Z135 | Native |
| Z069 | Native |
| Z188 | Without MDIS support |
| Z127 | Low Level |
As you can see, except Z127, all are Native drivers in MDIS project.
Our next step was to check if MCB support can be compiled only as a module or as a module and kernel built-in. After check it, we have found that, MCB and its drivers can be compiled in both ways (modules and built-in).
Once we have such information, for each IP Core, we have the next table:
| MCB | MDIS | Possible Actions |
|---|---|---|
| Supported | Native driver | Configure to use MCB/MDIS native drivers (using mdiswiz) |
| Supported | Low Level driver | Release MCB native driver before load MDIS associated LL_Driver |
| Not supported | Native driver | Use MDIS driver |
| Not supported | Low Level driver | Use MDIS driver |
It is impossible that 2 drivers can use the same hardware as the resources they request cannot be shared. Exists the option to request a memory region with the flag IORESOURCE_MUXED.
https://lwn.net/Articles/338837/
However, requesting a memory region with this flag, does not ensure to use the resource in a concurrent way, it means that the second driver that requests the region will wait until the first release the resource so it is not a valid approach, additionally, lots of rework on MCB driver should be done and this is not the correct approach.
Finally, after brainstorming with @mad-jsanjuan we think that the best way to coexist both environments is to modify MDIS project to work in the same way we defined in the table above.
MCB has IP Core support and the MDIS driver is native, we can modify modify MDIS to use MCB or MDIS for each module. To configure each Native driver with a preference parameter on whether to default to MDIS or MCB driver if available.
To achieve this, we have proposed to create a new user-space binary called mdis_modprobe. It will check such configuration parameter and will unload MCB driver first (if needed) previously to load MDIS driver.
MCB has IP Core support and the MDIS driver is LL_Driver, the men_mdis_kernel must be able to check if MCB driver is already loaded and unload it first, because MCB driver is full incompatible with LL_Driver interface, but it has the resources needed by LL_Driver so, the MCB driver must unloaded anyway.
The function to load a kernel module from other kernel module is called request_module( ) as in well implemented in kernel upstream, however it is not exist in kernel a function to release a module but exists a syscall, so men_mdis_kernel should trigger such syscall or implement a function like request_module( ).
The syscall can be found the rmmod source code:
/* And the system call of the day is... */
_syscall1(int, delete_module, const char *, name)However, these hypothesis are only valid if the MCB kernel drivers are compiled as loadable modules. If they are compiled built-in, this approach won't be available and only the MCB driver would be usable so MDIS driver would be discarded, even the LL_Driver.
I don't know if there could be another different approach to make coexist both environments.
Tasks
Goal Provide a document that: