bdm add support for getting USB device port number.

[DKWDRV]

Need this for multiple USB support in DKWDRV after game launch. Used to identify the correct USB device no matter the initialization order.

resolves DKWDRV/DKWDRV#82
resolves ps2homebrew/Open-PS2-Loader#1316 (partly)

@rickgaiser

[DKWDRV]

@rickgaiser suggestion on how to expose mass_dev struct?

[rickgaiser]

The end goal I think would be to be able to access a path like "usb0:" and "usb1:". Where "usb0" would always be the first port, and "usb1" would always be the second port. Extending this to support mutiple partitions you would get something like "usb0p0" for the entire device in the first port, and "usb0p1" for the first partition in the first port.

BDM was made to support this and in fact you will see these exact texts when you enable debugging on the BDM module.

ps2sdk/iop/fs/bdm/include/bdm.h

Lines 26 to 31 in 88fdeb0

	// Device name + number + partition number
	// Can be used to create device names like:
	// - mass0p1
	char *name;
	unsigned int devNr;
	unsigned int parNr;

However, no filesystem ever supported this. The old vfat driver didn't support it, and the new fatfs driver also does not support it. They only use "mass0" for the first one to register, and then "mass1" for the second, and so on and so on. But a workaround has already been created in the fatfs driver, with the following ioctl:

ps2sdk/common/include/usbhdfsd-common.h

Lines 38 to 39 in 88fdeb0

	/** Get the device number for the block device backing the mass partition */
	#define USBMASS_IOCTL_GET_DEVICE_NUMBER 0x0006

So for the USB driver to support this, all you need to do is make sure devNr is eaqual to the port number being used. Then use the ioctl to figure out what port "mass0" or "mass1" is.

[DKWDRV]

The end goal I think would be to be able to access a path like "usb0:" and "usb1:". Where "usb0" would always be the first port, and "usb1" would always be the second port. Extending this to support mutiple partitions you would get something like "usb0p0" for the entire device in the first port, and "usb0p1" for the first partition in the first port.
Most likely won't be used much. This is not the PS3 where the number is always the port. Almost all homebrew is using mass0. Even OPL has no good multiple drives support.

However, no filesystem ever supported this. The old vfat driver didn't support it, and the new fatfs driver also does not support it. They only use "mass0" for the first one to register, and then "mass1" for the second, and so on and so on. But a workaround has already been created in the fatfs driver, with the following ioctl:

ps2sdk/common/include/usbhdfsd-common.h

Lines 38 to 39 in 88fdeb0

	/** Get the device number for the block device backing the mass partition */
	#define USBMASS_IOCTL_GET_DEVICE_NUMBER 0x0006

So for the USB driver to support this, all you need to do is make sure devNr is eaqual to the port number being used. Then use the ioctl to figure out what port "mass0" or "mass1" is.

I am pretty sure bd "devNr", usbd "devId" and the actual port number are three different things. Usbd devId depends on the timing, whatever responds faster.
Only port number is solid and works perfectly with DKWDRV. OPL multiple devices is failing because of this.

bd "devNr" in this case would something completely random but matches 90% of the cases after reboot. I may wrong, so perhaps you can instruct more?

Nevertheless, can we still have port number ioctl? It can be very useful. Need a way to export mass_dev structure though.

[rickgaiser]

I am pretty sure bd "devNr", usbd "devId" and the actual port number are three different things.

devNr is whatever we define it to be. I say we define it to be the actual port number:

• USB: the actual port number (0, 1 or larger if it's in a hub)
• MX4SIO: the actual port number (0 or 1)
• ATA: master=0, slave=1
• etc...

[DKWDRV]

@rickgaiser for USB that number won't always be the same per same device if multiple devices are connected.

Can we still keep this ioctl aswell? Need a way to export the mass_dev struct but it's missing scsi definition, that is used and defined in many different places.

[DKWDRV]

Bump @rickgaiser
Need this on DKWDRV.

[rickgaiser]

@rickgaiser for USB that number won't always be the same per same device if multiple devices are connected.

We're discussing multiple numbers, so please be more clear than "that number". Your initial PR states:

Need this for multiple USB support in DKWDRV after game launch. Used to identify the correct USB device no matter the initialization order.

The most simple solution to fix that is to define BDM's devNr to be the actual port number. 0=first port, 1=second port. Then use the USBMASS_IOCTL_GET_DEVICE_NUMBER ioctl to figure out what port the device is in.

Can we still keep this ioctl aswell?

USBMASS_IOCTL_GET_USB_DEVICE_PORT_NUMBER in this PR does the same as USBMASS_IOCTL_GET_DEVICE_NUMBER if we make devNr equal to the actual port number. So then no.

Need a way to export the mass_dev struct but it's missing scsi definition

Please be more clear what you need and why. Also I don't see any exporting the mass_dev struct in this PR.

[DKWDRV]

@rickgaiser for USB that number won't always be the same per same device if multiple devices are connected.

We're discussing multiple numbers, so please be more clear than "that number". Your initial PR states:

Need this for multiple USB support in DKWDRV after game launch. Used to identify the correct USB device no matter the initialization order.

bd->devNr for two devices can be random between 0 and 1 for same device. After an iop reset USBD will reregister devid depending on the order they can which can be different each time.

The most simple solution to fix that is to define BDM's devNr to be the actual port number. 0=first port, 1=second port. Then use the USBMASS_IOCTL_GET_DEVICE_NUMBER ioctl to figure out what port the device is in.

How would we do that? And would that not impact other devices? BDM is used for many types of devices right?

Can we still keep this ioctl aswell?

USBMASS_IOCTL_GET_USB_DEVICE_PORT_NUMBER in this PR does the same as USBMASS_IOCTL_GET_DEVICE_NUMBER if we make devNr equal to the actual port number. So then no.
That is if we make port number the same as devNr for usbd devices. How do you suggest we do that?

We can still keep the new ioctl since it still gives the ability to recheck for port number.

Need a way to export the mass_dev struct but it's missing scsi definition

Please be more clear what you need and why. Also I don't see any exporting the mass_dev struct in this PR.

Here

I need to retrieve the usb port number which is part of mass_dev structure. I moved it to usbhdfsd-common.h which makes sense but now it needs struct scsi_interface definition which is used in many other pieces of code and many other devices so adding that defintion to usbhdfsd-common.h might cause problems for other internal scsi devices.

[rickgaiser]

How would we do that?

The usbmass_bd driver defines that number, here:

ps2sdk/iop/usb/usbmass_bd/src/scsi.c

Line 333 in 0abdcd5

g_scsi_bd[i].devNr = i;

Instead of just being an incrementing number, you need to find an elegant solution to put the port number in there.

And would that not impact other devices?

No becouse you're only changing the usbmass_bd driver, not BDM or fatfs (like your PR does).

BDM is used for many types of devices right?

Yes. usb(scsi), iLink(scsi), mx4sio, ata and udpbd.

[DKWDRV]

How would we do that?

The usbmass_bd driver defines that number, here:

ps2sdk/iop/usb/usbmass_bd/src/scsi.c

Line 333 in 0abdcd5

g_scsi_bd[i].devNr = i;

Instead of just being an incrementing number, you need to find an elegant solution to put the port number in there.

And would that not impact other devices?

No becouse you're only changing the usbmass_bd driver, not BDM or fatfs (like your PR does).

BDM is used for many types of devices right?

Yes. usb(scsi), iLink(scsi), mx4sio, ata and udpbd.

@rickgaiser the only elegant solution I can give you is not to mess more with it and cause havoc everywhere. That devNr is used to create a device path like mass0, mass1? If we do it by port then sometimes one single device will be as mass0 and sometimes mass1 depending on where it is plugged it. This will cause more compability issues.

I have settled on this for now and will do just fine.

[rickgaiser]

That devNr is used to create a device path like mass0, mass1? If we do it by port then sometimes one single device will be as mass0 and sometimes mass1 depending on where it is plugged it. This will cause more compability issues.

No, again, devNr is not used, just read my first reply:

However, no filesystem ever supported this. The old vfat driver didn't support it, and the new fatfs driver also does not support it. They only use "mass0" for the first one to register, and then "mass1" for the second, and so on and so on. But a workaround has already been created in the fatfs driver, with the following ioctl:

ps2sdk/common/include/usbhdfsd-common.h

Lines 38 to 39 in 88fdeb0

	/** Get the device number for the block device backing the mass partition */
	#define USBMASS_IOCTL_GET_DEVICE_NUMBER 0x0006

So for the USB driver to support this, all you need to do is make sure devNr is eaqual to the port number being used. Then use the ioctl to figure out what port "mass0" or "mass1" is.

For an elegant solution you can look at the ATA driver. It already uses devNr for master=0, slave=1.

[DKWDRV]

That devNr is used to create a device path like mass0, mass1? If we do it by port then sometimes one single device will be as mass0 and sometimes mass1 depending on where it is plugged it. This will cause more compability issues.

No, again, devNr is not used, just read my first reply:

However, no filesystem ever supported this. The old vfat driver didn't support it, and the new fatfs driver also does not support it. They only use "mass0" for the first one to register, and then "mass1" for the second, and so on and so on. But a workaround has already been created in the fatfs driver, with the following ioctl:

ps2sdk/common/include/usbhdfsd-common.h

Lines 38 to 39 in 88fdeb0

	/** Get the device number for the block device backing the mass partition */
	#define USBMASS_IOCTL_GET_DEVICE_NUMBER 0x0006

So for the USB driver to support this, all you need to do is make sure devNr is eaqual to the port number being used. Then use the ioctl to figure out what port "mass0" or "mass1" is.

For an elegant solution you can look at the ATA driver. It already uses devNr for master=0, slave=1.

@rickgaiser with all due respect, I really think there are no problems with my PR. I agree it adds more to the the driver but only the minimum needed. In the end is a good ioctl for the future too. I am terribly sorry, I can not just go and investigate a whole ata driver (which is different from USB in many direction) and figure out elegant ways.

The changes done here break nothing for you, they only add a way for me and future users. What is the problem then?

[rickgaiser]

@rickgaiser with all due respect, I really think there are no problems with my PR.

What is the problem then?

1. The new ioctl is redundant to the existing one.
2. The filesystem drivers have to be independent of the block device used. I don't want fatfs to know anything about usb or scsi. fatfs or any other filesystem should only care about block devices. No more.
3. The new ioctl will CRASH on any device other than usb and iLink, becouse of point 2.

You're breaking the design:

The solution I'm providing is very simple, so I don't see why you keep discussing it. I could have made the code changes twice in all the time it took me to discuss this.

[DKWDRV]

@rickgaiser with all due respect, I really think there are no problems with my PR.

What is the problem then?

1. The new ioctl is redundant to the existing one.

No, it's not. The new ioctl gives something that the old one does not. It gives me physical port number for my uses. Does your existing one give me actual port number? No, it does not. It only gives me a devNr which does not always correspond to the port number because it can not be so. Again, I want a port number which is different from the devNr, so please stop calling it "the same thing", "redudant". Right now there is no other way to get it, unless you rewrite things.

2. The filesystem drivers have to be independent of the block device used. I don't want fatfs to know anything about usb or scsi. fatfs or any other filesystem should only care about block devices. No more.

This will cause no real problem on the driver, and it's only there the ioctl are exposed. So how else am I supposed to get it then?

3. The new ioctl will **CRASH** on any device other than usb and iLink, becouse of point 2.

No it won't. It is checking for "mass" before doing anything else.

Where did one even knew of such design? BDM is more confusing rather than straightforward.

The solution I'm providing is very simple, so I don't see why you keep discussing it. I could have made the code changes twice in all the time it took me to discuss this.

Discuss what? What is your solution then? I am in a hurry too.