linux-kernel - Re: [PATCH 2/4] regulator: add STw481x VMMC driver

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] [day] [month] [year] [list]

Date:	Fri, 13 Sep 2013 22:52:57 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] regulator: add STw481x VMMC driver

On Fri, Sep 13, 2013 at 9:15 PM, Mark Brown <broonie@...nel.org> wrote:
> On Fri, Sep 13, 2013 at 09:00:08PM +0200, Linus Walleij wrote:
>> On Sun, Sep 1, 2013 at 10:13 PM, Mark Brown <broonie@...nel.org> wrote:
>
>> > I can put it on a branch so it can be pulled into arm-soc - it makes
>> > life easier for framework refactorings to have the driver in the
>> > regulator tree as well.  Would that be OK?
>
>> Sure but then you need patch 1/4 in there as well. I don't know if that
>
> It shouldn't do, the Kconfig dependencies should stop it actually
> getting built until the MFD is merged into the same tree I'd expect?

Yes you're right of course. It's just me being sensitive about
things like it's including yet non-existant headers etc. It is indeed
possible to apply it right off.

> But if it is required then I'm fine with it going via arm-soc only, it's
> just easier to avoid mistakes if there's no new drivers in other trees.

There's no need if we are convinced the MFD driver goes in
through the MFD tree.

The ARM SoC tree changes are only DT changes and those
could anyway live in through a stand-alone git the other day.

>> comment pertained to the situation prior to the v3.12 merge window
>> though, can I take this in now maybe or is there still a stir in the
>> regulator tree?
>
> There's still stuff going on - devm_regulator_register() is the main one
> I'm thinking of immediately.

OK better handle it there then. Feel free to apply when you're
happy with it.

Yours,
Linus Walleij
--
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/