refactor: address transport switch enumeration warning

[xudongzheng]

When building without USB or Bluetooth, the compiler would emit a warning due to ZMK_TRANSPORT_USB or ZMK_TRANSPORT_BLE not being handled.

[petejohanson]

Doesn't this cause this to fall through to the next label with this change? Maybe better to only define the given transport in the enum if that feature is enabled, instead?

[joelspadin]

enum zmk_transport is written to settings, so conditionally defining values could cause the meaning of a saved value to change from one build to another. Sort of a theoretical problem when we only have two transports, and disabling one means you can't switch at all, but that could become a problem if we ever added another RF protocol as a transport for example.

I'd recommend changing these to something more like

case ZMK_TRANSPORT_USB:
#if IS_ENABLED(CONFIG_ZMK_USB)
    return ...
#else
    return -ENOTSUP;
#endif

to avoid the fallthrough.

Alternatively, you could add a default case, but then you wouldn't get a warning if a new transport is added and someone forgot to add handling for it somewhere.

[petejohanson]

Good call on the settings storage issue. I agree with the -ENOTSUP version you proposed.

[joelspadin]

Looks good to me, Some existing error messages could be improved a bit if you want though.

[joelspadin]

Suggested change

	LOG_ERR("Unsupported endpoint transport %d", current_instance.transport);
	LOG_ERR("Unhandled endpoint transport %d", current_instance.transport);

Now that we only fall into this case if current_instance.transport isn't a valid enum value, or we add a new enum value and forget to add handling for it above, the error message could be improved a little.

[joelspadin]

Same as above.

[petejohanson]

Can you please rebase this so we can get it merged? Updated version LGTM.

[xudongzheng]

Rebased as requested, and the mouse report should be handled as well.