At Thu, 01 Nov 2012 10:05:41 +0100, Daniel Mack wrote: > > [cc lkml as this might be of broader interest] > > On 01.11.2012 00:32, maill...@superlative.org wrote: > > Dear Alsa community, > > I've some minor contributions in the form of patches for USB quirks for > > devices in the past. It occurred to me that having these USB quirks > > hardcoded > > into the driver maybe isn't the best thing. > > > > Looking at the current quirks file, the majority of them are relatively > > trivial > > and are really just there to give the USB driver a nudge in the right > > direction. > > > > Having to have these hardcoded into the driver creates a number of issues: > > > > 1. It needs someone with the expertise and will, and access the specific > > device > > for testing, to build the quirk. To hardened ALSA hackers this seems > > trivial, > > but to an average end user who has a device they want to get supported, > > this > > can be pretty inpenatrable. The complexity of just getting the alsa source > > installed and set up for compilation is enough to put off the vast majority > > of > > users. > > > > 2. It makes the process of getting the driver "to market" lengthy as these > > changes have to go through all of the normal release schedules, and these > > are > > pretty opaque. > > > > 3. It makes getting changing a driver (because of a bug, or a new release > > of > > hardware) difficult as the revisions need to go through the whole process > > of > > creating a patch, getting it accepted, and then the long kernel release > > process, as well as the various distribution release processes. > > > > It occured to me that there might be a better way where quirks like this > > could > > be dynamically loaded into the driver after it has loaded. This would a > > structured text file describing the quirk to be created and pushed into the > > driver. Ultimately this could be wrapped into a framework where quirk files > > could be put into a common directory (similar to modprobe.d) with a startup > > script which pushed these into the driver. > > The idea is interesting, but we would need to find a way to not only > cover the entries in quirks-list.h but the other hard-coded details as well. > > I fear that if quirk fixups are done on both the kernel level and loaded > from userspace, it actually makes debugging and maintainance harder. > > Then again, if a versatile and clean solution to this problem is found, > there would be tons of other drivers in Linux to benefit from it, just > think about the hda driver to begin with. But not only in the ALSA area.
HD-audio driver has already a sort of "firmware" support. It can read text data to patch the pre-existing BIOS setup, add extra initialization verbs or give hints for drivers to change the specific behavior. For USB-audio, a simple TLV representation would be feasible for an extra quirk entry. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
