Hi, I'm writing a driver for the Corsair Void family of headsets, but I have a few questions before I submit a patch for v1. 1. I can see there's already a hid-corsair driver, but my driver is around the same size as it so far, and shares almost nothing in common with it, as they're completely different devices. Should I still attempt to merge my corsair-void driver with hid-corsair, or submit it as a separate driver, such as hid-corsair-void? 2. The headsets can be queried for their firmware versions (separate versions for the headset and the receiver). However, the wired version of the headset doesn't have a receiver to report the version for, and the wireless version isn't always connected to the receiver, so the version can't always be retrieved. Should I just register and unregister the attributes as the versions are made available / unavailable, or always show them and just return something like -ENODEV if there's no device to return a version for? 3. How should I expose the limits for some of the sysfs attributes? For example, the headset can play a few alert tones, and I wired that up by playing the tone whose ID is passed to the send_alert attribute. If it only supports IDs 0 and 1, should I document this in the docs for the driver, in the source code, or as another attribute to return the highest supported ID? I have the same issue for sidetone, where the headset supports values 0-55, but I'm not sure how to communicate this. 4. The wireless variant of the headset reports a value for its charge that's ~54 higher than reality while plugged in. The Windows driver just conveniently reports 'Charging' instead of a value, I'm not sure how to communicate that the charge value can't be trusted while plugged in. Who do I need to ask about this? I'm assuming someone that's responsible for the power_supply class, but I'm not sure who that is. Thanks, Stuart
