From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755436Ab2DQSGW (ORCPT ); Tue, 17 Apr 2012 14:06:22 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37448 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751474Ab2DQSGU (ORCPT ); Tue, 17 Apr 2012 14:06:20 -0400 Date: Tue, 17 Apr 2012 20:06:19 +0200 Message-ID: From: Takashi Iwai To: Mark Brown Cc: Ondrej Zary , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [alsa-devel] [PATCH 3/4] Add Wolfson Microelectronics WM8776 codec ALSA driver In-Reply-To: <20120417170431.GT6652@opensource.wolfsonmicro.com> References: <1334611118-10301-1-git-send-email-linux@rainbow-software.org> <1334611118-10301-4-git-send-email-linux@rainbow-software.org> <20120417150234.GB22575@sirena.org.uk> <201204171813.44044.linux@rainbow-software.org> <20120417161820.GP6652@opensource.wolfsonmicro.com> <20120417165005.GR6652@opensource.wolfsonmicro.com> <20120417170431.GT6652@opensource.wolfsonmicro.com> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Tue, 17 Apr 2012 18:04:31 +0100, Mark Brown wrote: > > On Tue, Apr 17, 2012 at 06:52:49PM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > > This isn't just adding something into a specific driver which fails at > > > abstraction, it's adding generic code. If it were adding something to > > > the ice17xx driver then that'd be one thing but look at the subject line > > > and location of the file... this stuff should be buried inside the > > > driver if it's too painful to make the driver sane. > > > The codes in sound/i2c are mostly oly for ice1712/ice1724 drivers > > after all... They could be used by others, but I don't think there > > will be any more at this point. > > If they're specific to that driver we should make them specific to that > driver and make sure the pain is confined there. We really don't want > to end up going back to the bad old days of having to do per-CPU/card > drivers for CODECs because nobody had thought to abstract this stuff, > that just makes everyone miserable. > > Looking at these commits I'd not expect anyone to figure out that this > isn't how we want or expect people to add generic CODEC drivers. Yeah, these stuff can be better put in pci/ice1712/ directory only for ice1724 driver. In that way, you can avoid unnecessary exported symbols, too. Takashi