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: <20150714110713.GT11162@sirena.org.uk>
Date:	Tue, 14 Jul 2015 12:07:13 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-fbdev@...r.kernel.org, linux-acpi@...r.kernel.org,
	alsa-devel@...a-project.org,
	Stephen Warren <swarren@...dotorg.org>,
	Takashi Iwai <tiwai@...e.de>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Liam Girdwood <lgirdwood@...il.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-gpio@...r.kernel.org,
	Thierry Reding <thierry.reding@...il.com>,
	Linux PWM List <linux-pwm@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>
Subject: Re: [alsa-devel] [PATCH v2 11/12] ASoC: tegra: register dependency
 parser for firmware nodes

On Tue, Jul 14, 2015 at 09:34:22AM +0200, Tomeu Vizoso wrote:
> On 13 July 2015 at 17:42, Mark Brown <broonie@...nel.org> wrote:

> > No, I'm looking at how we already have all the "did all my dependencies
> > appear" logic in the core based on data provided by the drivers.

> Sorry, but I still don't get what you mean.

I'm not sure how I can be clearer here...  you're replacing something
that is currently pure data with open coding in each device.  That seems
like a step back in terms of ease of use.

> Information about dependencies is currently available only after
> probe() starts executing, and used to decide whether we want to defer
> the probe.

> The goal of this series is to eliminate most or all of the deferred
> probes by checking that all dependencies are available before probe()
> is called.

Right, but the way it does this is by moving code out of the core into
the drivers - currently drivers just tell the core what resources to
look up and the core then makes sure that they're all present.

> I thought you were pointing out that the property names would be
> duplicated, once in the probe() implementation and also in the
> implementation of the get_dependencies callback.

Yes, that is another part of issue with this approach - drivers now have
to specify things twice, once for this new interface and once for
actually looking things up.  That doesn't seem awesome and adding the
code into the individual drivers and then having to pull it out again
when the redundancy is removed is going to be an enormous amount of
churn.

> A way to consolidate the code and remove that duplication would be
> having a declarative API for expressing dependencies, which could be
> used for both fetching dependencies and for preventing deferred
> probes. That's why I mentioned devm_probe.

Part of what I'm saying here is that in ASoC we already have (at least
as far as the individual drivers are concerned) a declarative way of
specifying dependencies.  This new code should be able to make use of
that, if it can't and especially if none of the code can be shared
between drivers then that seems like the interface needs another spin.

I've not seen this devm_probe() code but the name sounds worryingly like
it might be fixing the wrong problem :/

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ