Message-ID: <CAB=NE6WEQ3LmscwRAv=d1T8FpW3_cr3wxpbb_RBRqZgxFdiPcg@mail.gmail.com>
Date:	Mon, 22 Apr 2013 23:18:24 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	Johannes Berg <johannes@...solutions.net>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	"backports@...r.kernel.org" <backports@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/7] backports: add support for voltage / current
 regulator drivers

On Mon, Apr 22, 2013 at 6:11 AM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, Apr 15, 2013 at 06:33:52PM +0200, Johannes Berg wrote:
>> On Mon, 2013-04-15 at 17:26 +0100, Mark Brown wrote:
>
>> > Please let's at least discuss the issues here, I'm not sure what this is
>> > supposed to do but the analysis of the subsystem didn't seem complete.
>
>> I wouldn't worry about it too much. For some reason (media drivers
>> related?) Luis decided that it was worth including this in the backports
>> project (see http://backports.wiki.kernel.org) and I am currently
>> maintaining the git tree for that, at least while I was doing some
>> refactoring.
>
>> I do notice that it doesn't quite work, there are a lot of unresolved
>> symbols :)
>
>> If you think you'd be impacted by this because users demand support from
>> you for the backport or whatever I can revert this (or probably just
>> remove it from the copy list for now.) I don't really have an opinion on
>> it, I'm doing this because I'm interested in one specific wireless
>> driver.
>
> Well, I'd much rather have a sane backport if we're going to have one -
> whatever problem is being solved here it seems likely that someone else
> will have the same need and if there's a general kernel project for this
> (which preusmably has some overlap with LTSI?) it seems bad to have one
> that people have to be warned away from using.

LTSI is for folks who stick to a kernel revision. backports project is
for folks who do not have control over what kernel they are on -- yet
or as a model. backports provides support for backporting new kernel
drivers down to any range of kernels. We strive for 802.11 down to
2.6.24, for BT 2.6.27, DRM to 3.2, regulator 3.2, Media 3.2. There are
both daily snapshots based on linux-next, and stable release snapshots
based on linux-stable. This enables Linux distributions, either
rolling or non-rolling, to embraces released bast on latest and
greatest drivers or based on stable releases.

The target here was not to make an assessment over quality of work on
the subsystem but instead more on the backportability nature of it. In
this case the regulator ends up using some data structures defined
upon late_initcall() and core_initcall() which implicates what you can
backport unless you can genuinely provide gaurantee a proper backport
of regulator as a module and forcing drivers to use a separate
namespace or somehow modifying the kernel's init calls with things
like ksplice. Neither of these two are possible today and as such what
is backported for regulator is things that do not depend on these
calls having fired off as is today. 3.2 as a target seemed reasonable
given that DRM was backported down to 3.2 and so was media.

> Given how big the misunderstandings in the cover letter for Luis' patch
> were I'd be really concerned about seeing this going into anything
> officialish without some discussion about what's going on.

Official? Huh?

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