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]
Date:	Tue, 24 Sep 2013 10:58:03 +0100
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Stephen Warren <swarren@...dotorg.org>, lee.jones@...aro.org,
	sameo@...ux.intel.com, rob.herring@...xeda.com, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	rob@...dley.net, patches@...nsource.wolfsonmicro.com,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] mfd: arizona: Add device tree binding for
	max_channels_clocked

On Tue, Sep 24, 2013 at 12:28:32AM +0100, Mark Brown wrote:
> On Mon, Sep 23, 2013 at 03:38:10PM -0600, Stephen Warren wrote:
> > On 09/23/2013 12:30 PM, Charles Keepax wrote:
> 
> > > +  - wlf,max-channels-clocked : The maximum number of channels to be clocked on
> > > +    each AIF, useful for I2S systems with multiple data lines being mastered.
> > > +    If specified three cells must supplied one for each AIF, specify zero for
> > > +    AIFs that should be handled normally.
> 
> > What determines the value of this property? Is it really a definition of
> > HW, or some kind of run-time configuration/limit? What goes into each of
> > the 3 cells?
> 
> It's hardware, it's other devices wired in parallel on the bus that use
> the CODEC as a clock master.  Personally I'd have this be set by the
> ASoC machine driver so it's invisible from a DT point of view, that's
> what it's really a property of.

I don't have any really problem with setting this from the
machine driver, I will have a look at doing that.

I think based on the comments here I would suggest that we put
the first patch in but I need to rethink the other patches and
decide what is actually OS independant here.

Thanks,
Charles

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