What was the rationale for 8 bit wide channels again?

Btw: the rationale for my proposed PR was that packages that access this netdev option may often use uint8_t for channel numbers (which seems to be a reasonable size). Of course, one could extend this to uint16_t in the adaptation layer or a patch file, but somehow this feels wrong.

What was the rationale for 8 bit wide channels again?

Did you mean 16-bit wide? If not: You proposed to change the type in #7427, so you have to answer that. If yes: I think @haukepetersen aimed for simplicity in API usage, so all scalar numbers were either int16_t or uint16_t when he started NETOPT.

Btw: the rationale for my proposed PR was that packages that access this netdev option may often use uint8_t for channel numbers (which seems to be a reasonable size). Of course, one could extend this to uint16_t in the adaptation layer or a patch file, but somehow this feels wrong.

But your proposed PR was an API change in disguise (handing over uint16_t after your PR to get/set would potentially break the behaviour + it didn't even change it for all devices), that's the main reason why I was against that PR and opted for this solution.

Yes, I mean 16 bit. And yes I agree that my PR is broken. Let's see if we can find a better solution.

In the meantime, let's fix the bug and merge this PR?

Rebased to current master.

@haukepetersen could you maybe re-ACK? You ACK'd already on Aug 29.