I have no idea what this abbreviation means. It is present in many device manager-based drivers, example: https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/busses/i2c/pch_i2c.cpp#n527?
Cast @korli.
SIM comes from SCSI Interface Module, it’s misused to name host adapter interface modules.
1 Like
Also why 2 nested nodes are usually used instead of one? For example i2c has “Device” and “SIM” nodes.
When I implemented the SD/MMC stack I found that I need to stack up a lot of drivers, busses and modules to get it working. Currently it is like this:
PCI device (published by PCI bus) -> SDHCI device (sdhci_pci) -> SD/MMC bus controller (there can be multiple busses in one PCI device) -> SD/MMC bus -> bus root device -> SD cards
I am not sure if all these levels of nesting are needed. I think one limitation is that the SDHCI device “owns” the PCI device exclusively, so there can only be one SDHCI device per PCI device. Then it wants to publish sub-devices (possibly one per SDHC bus available), and each of these expose a bus where finally we can add the SD and MMC devices themselves.
I did not manage to find a simpler solution. Maybe we need to improve this API a bit.
2 Likes
I found one problem with single node: it is not possible to set cookie when registering device. Setting device attributes (such as VirtIO device type that is needed to find child driver) may require commuticating with hardware so device state should be already created. But attributes are passed to gDeviceManager->register_node and can’t be changed after creation. Passing cookie to register_node is not suppored. init_device() function that set cookie can’t change attributes.
It actually makes sense because different outer node implementations can be used such as FDT VirtIO, ACPI VirtIO.
1 Like