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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D502DBF.3050205@metafoo.de>
Date:	Mon, 07 Feb 2011 18:37:03 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Liam Girdwood <lrg@...mlogic.co.uk>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] ASoC: Samsung: neo1973_gta02: Fix bluetooth DAI registration

On 02/07/2011 06:02 PM, Mark Brown wrote:
> Please fix your MUA to word wrap at less than 80 columns, I've reflowed
> your text so it's legible.
> 
> On Mon, Feb 07, 2011 at 05:53:56PM +0100, Lars-Peter Clausen wrote:
> 
>>> In any
>>> case, we clearly shouldn't be applying patches which bodge around the
>>> core.
> 
>> Well the alternative would be a patch looking like this:
> 
>> -	.cpu_dai_name = "bluetooth-dai",
>> +	.cpu_dai_name = "soc-core",
> 
>> Which isn't really nice either.
> 
> If you think the core isn't behaving helpfully the core should be
> changed.  This is part of how APIs evolve to be maximally useful.
> 

As I see it the problem is that we have a deviceless dai and there is not really a
way to register a dai without a device. But I have no idea right now how to change
the core to make it "behave helpfully".

And in a sense snd_soc_register_dais seems to be the right thing to use for now,
because the sound card as a whole has multiple dais they just not all registered at
the same time.

> To be honest it's not massively obvious that we shouldn't just be taking
> the name of the device here, either using a device to represent the
> modem

Seriously? I don't see how adding a dummy device wouldn't be "bodging around the
core". Especially if using snd_soc_register_dais is.

> or registering the card using snd_soc_register_machine() and using
> a more meaningful name for the card seems like a sensible approach here.

Well, if were using snd_soc_register_machine to give the card a different name the
bluetooth-dai would still be named after the card, wouldn't it? So there is no
improvement here as to giving the dai a meaningful name.

- Lars
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ