linux-kernel - Re: [PATCH v1 2/3] PM / Sleep: introduce dpm_for_each

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:	Sat, 18 Aug 2012 22:49:06 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Borislav Petkov <borislav.petkov@....com>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v1 2/3] PM / Sleep: introduce dpm_for_each_dev

On Saturday, August 18, 2012, Rafael J. Wysocki wrote:
> On Saturday, August 18, 2012, Ming Lei wrote:
> > On Sat, Aug 18, 2012 at 9:38 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > >
> > > My question was about the number of current users of it.  Sorry for not
> > > being clear.
> > 
> > Sorry for misunderstanding your question.
> > 
> > >
> > > If there are no more anticipated users than the current only one, please
> > > drop the unused (void *) argument.  We can always extend it in the future
> > > if need be and for now passing that NULL every time is just pointless.
> > 
> > One usage is to get statistics info about devices for debug purpose,
> > so the parameter is needed to return something.
> 
> So, what's the name of the _second_ function using dpm_for_each_dev()?
> 
> I don't see any and device_cache_fw_images() in [3/3] clearly passes
> NULL as the first argument.
> 
> > > And please fold [2/3] into [3/3] in this series.
> > 
> > IMO, it is better to split them to avoid coupling between fw loader and
> > device PM.
> > 
> > Looks you agreed on the patch,
> 
> On the idea, not on the actual code.  I told you what I wanted to to change in
> it, didn't I?
> 
> > and Greg has added the
> > patch into his driver-core next tree to fix -next build failure, so could
> > you just let them be that?
> 
> -next is not cast in stone, you can replace patches in it with other ones
> if need be.

And it actually would be better if you replaced the patches that had introduced
the build problems with new fixed ones, because otherwise your whole series
has bisection issues potentially.

And since the Greg's patch queue is quilt-based, for what I can tell, that's
entirely doable.

So the fact that your patches in this series fix build issues in -next
introduced by your previous patches isn't any excuse at all.  There still is
a plenty of time before the v3.7 merge window to fix things properly.

Thanks,
Rafael
--
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/