According to recent mailing list discussion, situation where NUT USB drivers ignore the user-provided device path and imply port = auto because some port value is required, arose because libusb-0 only allowed enumeration of devices at run-time (no way to request a device node named by OS) and opening a chosen item by matching among discovered objects.

I believe (but did not check further) that code to support libusb-1 did not change this logic, so the port setting remains ignored. However per that discussion, allegedly libusb-1 does have a way to use a requested device path.

If so, builds of NUT drivers against libusb-1 API should benefit from that:

• not ignore port and assume/enforce it as auto
• do support port=auto for automated matching by vendorid/productid etc. as done now
• if further options for matching (like vendorid/productid etc.) are requested - verify that the device on the port path does match, or error out otherwise
• no change for libusb-0 API support (unless its recent revisions also got a way to request by device path? something to read up on...)
• change docs and man pages to reflect this; note that specific path name may be volatile in some OSes (subject to change with re-enumeration, re-plug, reboot) so this configuration may be less reliable than matching, however it can help manage seemingly identical devices (e.g. two UPSes of same model with zeroed serial numbers, which is a firmware bug to bring up with vendors)