Hi all,
Today's linux-next merge of the char-misc tree got a conflict in
drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
clean the state on power up") from Linus' tree and commit b950ac1dabfc
("mei: don't get stuck in select during reset") from the char-misc tree.
(Unrelated white space changes are a pest :-()
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell [email protected]
diff --cc drivers/misc/mei/init.c
index e6f16f8,557eed2..0000000
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@@ -148,8 -148,8 +148,9 @@@ void mei_reset(struct mei_device *dev,
dev->hbm_state = MEI_HBM_IDLE;
- if (dev->dev_state != MEI_DEV_INITIALIZING) {
+ if (dev->dev_state != MEI_DEV_INITIALIZING &&
+ dev->dev_state != MEI_DEV_POWER_UP) {
+
if (dev->dev_state != MEI_DEV_DISABLED &&
dev->dev_state != MEI_DEV_POWER_DOWN)
dev->dev_state = MEI_DEV_RESETTING;
On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in
> drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> clean the state on power up") from Linus' tree and commit b950ac1dabfc
> ("mei: don't get stuck in select during reset") from the char-misc tree.
>
> (Unrelated white space changes are a pest :-()
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
merge problem should no longer be there.
greg k-h
>> (Unrelated white space changes are a pest :-()
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> merge problem should no longer be there.
I've preferred the blank line there as these ifs became a bit dense
nevertheless thanks for taking care of it.
Tomas
PS: sorry for the previous HTML mistake.
On Tue, Jul 30, 2013 at 01:16:38AM +0300, Tomas Winkler wrote:
> >> (Unrelated white space changes are a pest :-()
> >>
> >> I fixed it up (see below) and can carry the fix as necessary (no action
> >> is required).
> >
> > Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> > merge problem should no longer be there.
>
> I've preferred the blank line there as these ifs became a bit dense
> nevertheless thanks for taking care of it.
Ah, sorry about that, feel free to change it back in the next round of
patches you send :)
greg k-h
Hi Greg,
On Mon, 29 Jul 2013 12:26:49 -0700 Greg KH <[email protected]> wrote:
>
> On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the char-misc tree got a conflict in
> > drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> > clean the state on power up") from Linus' tree and commit b950ac1dabfc
> > ("mei: don't get stuck in select during reset") from the char-misc tree.
> >
> > (Unrelated white space changes are a pest :-()
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> merge problem should no longer be there.
Unfortunately, I think this is exactly the sort of back merge that Linus
hates. He and I are quite capable of coping with relatively complex
merge conflicts, so ones like this are really not a problem (and "git
rerere" takes care of it once I have resolved it the first time). That
is why I added "no action is required" to my notification messages.
These messages are really more "this is what I did, please tell me if I
did something wrong", not "please fix this up" (I know this message from
me has changed over time - we can all learn, even us oldies :-))
Also, if you are doing a merge of fixes that you have submitted to
Linus, it is probably better to merge your fixes branch rather that
Linus' tree after he has merged it - that way you are not dragging
irrelevant stuff from Linus' tree into yours and complicating the git
history/bisecting so much.
Of course, if you need something from Linus' tree that someone else put
there to continue development, then you need to back merge Linus' tree,
but after rc2 or 3 that should be rare. And, of course, such a back
merge needs a good changelog explaining exactly why it was done.
--
Cheers,
Stephen Rothwell [email protected]
On Tue, Jul 30, 2013 at 10:27:54AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 29 Jul 2013 12:26:49 -0700 Greg KH <[email protected]> wrote:
> >
> > On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the char-misc tree got a conflict in
> > > drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> > > clean the state on power up") from Linus' tree and commit b950ac1dabfc
> > > ("mei: don't get stuck in select during reset") from the char-misc tree.
> > >
> > > (Unrelated white space changes are a pest :-()
> > >
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> >
> > Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> > merge problem should no longer be there.
>
> Unfortunately, I think this is exactly the sort of back merge that Linus
> hates. He and I are quite capable of coping with relatively complex
> merge conflicts, so ones like this are really not a problem (and "git
> rerere" takes care of it once I have resolved it the first time). That
> is why I added "no action is required" to my notification messages.
> These messages are really more "this is what I did, please tell me if I
> did something wrong", not "please fix this up" (I know this message from
> me has changed over time - we can all learn, even us oldies :-))
>
> Also, if you are doing a merge of fixes that you have submitted to
> Linus, it is probably better to merge your fixes branch rather that
> Linus' tree after he has merged it - that way you are not dragging
> irrelevant stuff from Linus' tree into yours and complicating the git
> history/bisecting so much.
>
> Of course, if you need something from Linus' tree that someone else put
> there to continue development, then you need to back merge Linus' tree,
> but after rc2 or 3 that should be rare. And, of course, such a back
> merge needs a good changelog explaining exactly why it was done.
I usually want those fixes from the rcs and merge at that point in time
every other -rc release or so, just to make it much easier for me to
test with, and to pick in the patches I've sent to Linus.
Yes, I could just suck in my fixes branch, but I would be stuck with
trees based on -rc1, which is almost always a pain to test with.
I'm not doing "merges every week", and have been doing it this way for a
few years now with no complaints. The -rc point in time is a good place
to sync up with it seems.
thanks,
greg k-h