What is the intended behaviour of usb_host_get_port for root hubs?

What is the intended behaviour of usb_host_get_port for root hubs?

[Ben Leslie]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

When usb_host_get_port is called for a root-hub device what string should
be output in the port parameter?

The current behaviour writes a string with whatever stack value happened to
be in the paths stack array.

Possible behaviours that I can see being useful are:

1: Don't modify the port parameter.
2: Write an empty string.

My preference would be for #2, but possibly #1 is intended. I can provide a
patch if someone can let me know the intended behaviour. If #1 is intended,
then I think the usage in hmp_info_usbhost might need changing as well. The
other usage in usb_host_auto_check where the provided port parameter is set
to "-" prior to calling the function; it's not clear what the intent of
that is. Finally, the function returns zero on error and string length on
success (which actually makes #2 a problem), however none of the callers
check the return value, so perhaps it can be made a void function? Or
possibly it should return -1 on error, rather than zero.

Regards,

Ben

[-- Attachment #2: Type: text/html, Size: 1220 bytes --]

Re: What is the intended behaviour of usb_host_get_port for root hubs?

[Gerd Hoffmann]

On Tue, Mar 09, 2021 at 10:54:15AM +1100, Ben Leslie wrote:
> When usb_host_get_port is called for a root-hub device what string should
> be output in the port parameter?

Just the port number, as string.

(and in case this isn't a root port the hub port number(s) are appended,
separated by a dot).

> The current behaviour writes a string with whatever stack value happened to
> be in the paths stack array.

Huh?  Isn't paths updated by the libusb_get_port_numbers() call?

take care,
  Gerd

Re: What is the intended behaviour of usb_host_get_port for root hubs?

[Ben Leslie]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Tue, 9 Mar 2021 at 18:24, Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Tue, Mar 09, 2021 at 10:54:15AM +1100, Ben Leslie wrote:
> > When usb_host_get_port is called for a root-hub device what string should
> > be output in the port parameter?
>
> Just the port number, as string.
>
> (and in case this isn't a root port the hub port number(s) are appended,
> separated by a dot).
>
> > The current behaviour writes a string with whatever stack value happened
> to
> > be in the paths stack array.
>
> Huh?  Isn't paths updated by the libusb_get_port_numbers() call?
>

libusb_get_port_numbers() can return zero (for the root hub); or at least
it does
on the Linux systems I tried. If that happens path[0] won't be changed by
libusb_get_port_numbers. The rest of the function assumes that the path is
at least 1 item long and unconditionally access path[0], which isn't true
if a root-hub
device is passed to the function.

Of course, reading the current code more carefully, usb_host_get_port is
never
actually called with a hub device (let alone a root hub), so I guess it is
a valid
assumption that libusb_get_port_numbers will always return at least 1 in
the non-error
path. I hit the problem as I was trying to reuse the function with a hub
device, so my
bad.

Thanks,

Ben

[-- Attachment #2: Type: text/html, Size: 2177 bytes --]

Re: What is the intended behaviour of usb_host_get_port for root hubs?

[Gerd Hoffmann]

  Hi,

> Of course, reading the current code more carefully, usb_host_get_port
> is never actually called with a hub device (let alone a root hub),

Ah, the root hub itself.  I've assumed you mean a device plugged into
the root hub.  That explains the confusion.

Yes, passing through hubs is simply not supported, only individual
devices, so that should never happen.

> so I guess it is a valid assumption that libusb_get_port_numbers will
> always return at least 1 in the non-error path.

Correct.

take care,
  Gerd