On Wed, 25 Nov 2020 at 16:42, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: > > On 11/25/2020 8:43 AM, Loic Poulain wrote: > > Today the MHI controller name is simply cloned from the underlying > > bus device (its parent), that gives the following device structure > > for e.g. a MHI/PCI controller: > > devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:02:00.0 > > devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:02:00.0/0000:02:00.0_IPCR > > ... > > > > That's quite misleading/confusing and can cause device registering > > issues because of duplicate dev name (e.g. if a PCI device register > > two different MHI instances). > > > > This patch changes MHI core to create indexed mhi controller names > > (mhi0, mhi1...) in the same way as other busses (i2c0, usb0...). > > > > The previous example becomes: > > devices/pci0000:00/0000:00:01.2/0000:02:00.0/mhi0 > > devices/pci0000:00/0000:00:01.2/0000:02:00.0/mhi0/mhi0_IPCR > > ... > > > > Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxx> > > > How does this change /sys/bus/mhi/devices/ ? That does change sysfs device dir names: $ ls -al /sys/bus/mhi/devices/ lrwxrwxrwx 1 root root 0 nov. 25 16:27 mhi0 -> ../../../devices/pci0000:00/0000:00:01.2/0000:02:00.0/mhi0 lrwxrwxrwx 1 root root 0 nov. 25 16:28 mhi0_DIAG -> ../../../devices/pci0000:00/0000:00:01.2/0000:02:00.0/mhi0/mhi0_DIAG lrwxrwxrwx 1 root root 0 nov. 25 16:28 mhi0_IPCR -> ../../../devices/pci0000:00/0000:00:01.2/0000:02:00.0/mhi0/mhi0_IPCR > The point of having the bus name in the mhi device name is to give an > easy way to correlate those devices back to the "root" device (I have a > lot of users which do that). I see your point but it's not a problem specific to MHI bus, user can rely on sysfs/uevent to get device information such ass devices attributes, children, or parent devices. Do you have a concrete example in mind for your case? > > Also, do we actually have some device that actually exposes multiple MHI > interfaces? No, but better to fix possible problems ahead of time. Regards, Loic
