Fix common USB matching options for bcmxcp_usb#2270
Fix common USB matching options for bcmxcp_usb#2270jimklimov wants to merge 12 commits intonetworkupstools:masterfrom
Conversation
…in nut_usb_addvars() where needed [networkupstools#1754]
4b6002b to
410da30
Compare
|
❌ Build nut 2.8.1.1313-master failed (commit 4132f4deee by @jimklimov) |
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
❌ Build nut 2.8.3.3011-master failed (commit 8c9f2bc899 by @jimklimov) |
|
Resyncing with main NUT code base after v2.8.3 release. |
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Parked code has got a few issues to address: |
networkupstools#2270] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…om PR networkupstools#2270 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…cp sources [networkupstools#2270] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…o avoid linker conflict with libusb{0,1}.c [networkupstools#2270]
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…s#2270 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Resolved the basic language/recipe conflicts at least, so the driver variables should be there. Whether they get picked up by |
…orkupstools#2270, networkupstools#1764] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
7787cdf to
e957768
Compare
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
e957768 to
023906d
Compare
|
Seems these common options are not used still, but at least are recognized: |
|
Yeah, with added debugging we can see this driver deals with its device table only (e.g. no custom vendorid/productid/bus... matching like done with most other drivers): |
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Recap: so far this PR got updated to pass the builds with code "knowing" about the common driver option names, but the rest (actually honouring them) still needs to be implemented, and falls out of the nearest release cycle. |
Parked per #1764 and #1763, something like this should be needed to solve #597 (but progress on development should better be tested against real devices):
Posting as a PR to avoid dropping the source branch (and to let CI give it a shot) :)