linux-kernel - Re: [alsa-devel] Idea: dynamic loading of USB quirks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 05 Nov 2012 12:44:50 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Daniel Mack <zonque@...il.com>
Cc:	alsa-devel@...a-project.org, maillist@...erlative.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] Idea: dynamic loading of USB quirks

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, maillist@...erlative.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/