linux-kernel - Re: [GIT PULL] sound updates for 3.1-rc1

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:	Sat, 23 Jul 2011 21:42:43 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] sound updates for 3.1-rc1

At Sat, 23 Jul 2011 11:06:14 -0700,
Linus Torvalds wrote:
> 
> On Sat, Jul 23, 2011 at 9:32 AM, Takashi Iwai <tiwai@...e.de> wrote:
> >
> > As you can see below, the diffstat shows awfully huge numbers.  It's
> > mainly the reworks of two HD-audio drivers after I finally had some
> > spare time and a gut to face them.  Most of LOCs there are due to code
> > split, but also a significant amount of code reduction has been done,
> > too.  In addition, as usual, many ASoC fixes/updates have been applied
> > in this cycle, too.
> 
> So wrt that whole HDA thing, can somebody explain what the difference
> between a "patch" and a "quirk" is? It looks like the "quirks" are
> smaller patches (they all seem to be about realtek, at least
> currently).

The "patch" came from the initial design to allow the non-generic
codec parsers.  It ended up with the codec-driver of each codec chip.
Thus patch_*.c corresponds to each HD-audio "codec" driver (while
hda_intel.c is HD-audio "controller" driver).

In the development of Realtek and other codec drivers, we faced the
problem of broken BIOSen and complex tree structure.  As a workaround,
the "quirk" was introduced -- it's a kind of static configuration without
parsing the whole tree.  (This is called also as "models", since it can
be selected via model module option.)  Quirks have grown up quickly in
the early time because the parser itself was not smart enough, and
there have been numerous broken setups.

Now, I finally tried to do radical diet.  Together with the
improvement of the parser code to handle all tree graphs, the quirks
are stripped out of the main parser code.  These are alc*_quirks.c.
The remaining patch_realtek.c contains the pure parser code with a few
other minimal static configurations.

My further plan is to convert most of quirks into the minimal static
configurations that are just required for the tree-parser.  Thus,
alc*_quirks.c will be eliminated in near future again, hopefully in a
couple of kernel releases.

> And does it really make sense to use #include to get the *.c files?
> Wouldn't it be much nicer to have a "realtek" subdirectory and link
> those together.

That would work, certainly yes.  As said, this was the first step
toward a bigger clean-up.  So I didn't want to change the quirk codes
so much but just cut them off from the main code.

If you prefer that way, I can move and change the code before the
merge window closes.

> I don't care deeply, but the whole HDA source organization is getting
> pretty darn ugly, I have to say.

Yeah, it's awfully messy and hence I'm working on it.  This is still
in the early ugly stage during the beauty surgery :)

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/