linux-kernel - Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

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:	Thu, 4 Dec 2014 16:46:12 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Darren Hart <dvhart@...ux.intel.com>,
	Ben Zhang <benzh@...omium.org>,
	alsa-devel <alsa-devel@...a-project.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Bard Liao <bardliao@...ltek.com>,
	Oder Chiou <oder_chiou@...ltek.com>,
	Anatol Pomozov <anatol@...gle.com>,
	Dylan Reid <dgreid@...omium.org>, flove@...ltek.com,
	Al Stone <al.stone@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

On Thu, Dec 04, 2014 at 10:48:19AM +0000, Grant Likely wrote:
> On Tue, 25 Nov 2014 22:40:53 +0100

> > We absolutely need to start registering the existing bindings in there, but
> > that needs to be rate limited somehow, because the process may not be very
> > efficient to start with.

> Beyond having the document point to the existing DT binding
> documentation, I think this is a non-starter. It won't be helpful for
> anyone to have two separate repositories containing the same bindings.
> They will get out of sync and we will have pain as a result.

Right, I think we have to pick one and reference it from the other.
Having the one place be inside the Linux kernel doesn't seem super
awesome.

> For existing bindings we need to have a way to share the documentation,
> and I don't think we can even talk about whether it makes sense to
> migrate the documetation to the UEFI managed repo before the UEFI process is
> fully flushed out.

We definitely don't want to start dumping everything in immediately but
but starting the conversation to both provide urgency and requirements
and and be engaged in the process seems sensible.  Let's try to take
advantage of the recent changes in UEFI governance to help shape the
firmware interfaces we'll be working with.

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