linux-next: manual merge of the drivers-x86 tree with the watchdog tree

linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drivers-x86 tree got a conflict in:

  drivers/watchdog/iTCO_wdt.c

between commit:

  38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
(which also appears in the drivers-x86 tree as commit f583a884afec)

from the watchdog tree and commit:

  140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")

from the drivers-x86 tree.

I fixed it up and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drivers-x86 tree got a conflict in:

  drivers/watchdog/iTCO_wdt.c

between commit:

  38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
(which also appears in the drivers-x86 tree as commit f583a884afec)

from the watchdog tree and commit:

  140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")

from the drivers-x86 tree.

I fixed it up and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> 
>   drivers/watchdog/iTCO_wdt.c
> 
> between commit:
> 
>   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> (which also appears in the drivers-x86 tree as commit f583a884afec)
> 

Andy and Guenter, I presume the two of you discussed how this patch would get
submitted as I see the following in the platform driver x86 for-next branch:

    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

for both:

140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions

This suggests these were deliberately added to our tree and not accidentally
included through a rebase without --preserve-merges or something like that.

Guenter, if you prefer/need to submit this through your tree, can you provide
us with an immutable branch to merge for the dependencies of our later patches?
If you can drop these two patches without a dependency problem in your tree,
that would be the cleanest solution as we could avoid an additional merge.

Thanks,

Darren



> from the watchdog tree and commit:
> 
>   140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")
> 
> from the drivers-x86 tree.
> 
> I fixed it up and can carry the fix as necessary. This is now fixed as
> far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> 
>   drivers/watchdog/iTCO_wdt.c
> 
> between commit:
> 
>   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> (which also appears in the drivers-x86 tree as commit f583a884afec)
> 

Andy and Guenter, I presume the two of you discussed how this patch would get
submitted as I see the following in the platform driver x86 for-next branch:

    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

for both:

140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions

This suggests these were deliberately added to our tree and not accidentally
included through a rebase without --preserve-merges or something like that.

Guenter, if you prefer/need to submit this through your tree, can you provide
us with an immutable branch to merge for the dependencies of our later patches?
If you can drop these two patches without a dependency problem in your tree,
that would be the cleanest solution as we could avoid an additional merge.

Thanks,

Darren



> from the watchdog tree and commit:
> 
>   140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")
> 
> from the drivers-x86 tree.
> 
> I fixed it up and can carry the fix as necessary. This is now fixed as
> far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Guenter Roeck]

On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > 
> >   drivers/watchdog/iTCO_wdt.c
> > 
> > between commit:
> > 
> >   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> > (which also appears in the drivers-x86 tree as commit f583a884afec)
> > 
> 
> Andy and Guenter, I presume the two of you discussed how this patch would get
> submitted as I see the following in the platform driver x86 for-next branch:
> 
>     Acked-by: Guenter Roeck <linux@roeck-us.net>
>     Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> for both:
> 
> 140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
> f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions
> 

I did not expect f583a88/38a700fa1df9 to show up in some other tree, sorry.
I don't recall discussing how to handle it either, though my memory may defeat
me. If so, my apologies.

> This suggests these were deliberately added to our tree and not accidentally
> included through a rebase without --preserve-merges or something like that.
> 
> Guenter, if you prefer/need to submit this through your tree, can you provide
> us with an immutable branch to merge for the dependencies of our later patches?
> If you can drop these two patches without a dependency problem in your tree,
> that would be the cleanest solution as we could avoid an additional merge.
> 

Please check with Wim.

Thanks,
Guenter

> Thanks,
> 
> Darren
> 
> 
> 
> > from the watchdog tree and commit:
> > 
> >   140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")
> > 
> > from the drivers-x86 tree.
> > 
> > I fixed it up and can carry the fix as necessary. This is now fixed as
> > far as linux-next is concerned, but any non trivial conflicts should be
> > mentioned to your upstream maintainer when your tree is submitted for
> > merging.  You may also want to consider cooperating with the maintainer
> > of the conflicting tree to minimise any particularly complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> 
> -- 
> Darren Hart
> VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Guenter Roeck]

On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > 
> >   drivers/watchdog/iTCO_wdt.c
> > 
> > between commit:
> > 
> >   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> > (which also appears in the drivers-x86 tree as commit f583a884afec)
> > 
> 
> Andy and Guenter, I presume the two of you discussed how this patch would get
> submitted as I see the following in the platform driver x86 for-next branch:
> 
>     Acked-by: Guenter Roeck <linux@roeck-us.net>
>     Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> for both:
> 
> 140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
> f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions
> 

I did not expect f583a88/38a700fa1df9 to show up in some other tree, sorry.
I don't recall discussing how to handle it either, though my memory may defeat
me. If so, my apologies.

> This suggests these were deliberately added to our tree and not accidentally
> included through a rebase without --preserve-merges or something like that.
> 
> Guenter, if you prefer/need to submit this through your tree, can you provide
> us with an immutable branch to merge for the dependencies of our later patches?
> If you can drop these two patches without a dependency problem in your tree,
> that would be the cleanest solution as we could avoid an additional merge.
> 

Please check with Wim.

Thanks,
Guenter

> Thanks,
> 
> Darren
> 
> 
> 
> > from the watchdog tree and commit:
> > 
> >   140c91b26ebc ("watchdog: iTCO_wdt: Add PMC specific noreboot update api")
> > 
> > from the drivers-x86 tree.
> > 
> > I fixed it up and can carry the fix as necessary. This is now fixed as
> > far as linux-next is concerned, but any non trivial conflicts should be
> > mentioned to your upstream maintainer when your tree is submitted for
> > merging.  You may also want to consider cooperating with the maintainer
> > of the conflicting tree to minimise any particularly complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> 
> -- 
> Darren Hart
> VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > > 
> > >   drivers/watchdog/iTCO_wdt.c
> > > 
> > > between commit:
> > > 
> > >   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> > > (which also appears in the drivers-x86 tree as commit f583a884afec)
> > > 
> > 
> > Andy and Guenter, I presume the two of you discussed how this patch would get
> > submitted as I see the following in the platform driver x86 for-next branch:
> > 
> >     Acked-by: Guenter Roeck <linux@roeck-us.net>
> >     Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > for both:
> > 
> > 140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
> > f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions
> > 
> 
> I did not expect f583a88/38a700fa1df9 to show up in some other tree, sorry.
> I don't recall discussing how to handle it either, though my memory may defeat
> me. If so, my apologies.
> 
> > This suggests these were deliberately added to our tree and not accidentally
> > included through a rebase without --preserve-merges or something like that.
> > 
> > Guenter, if you prefer/need to submit this through your tree, can you provide
> > us with an immutable branch to merge for the dependencies of our later patches?
> > If you can drop these two patches without a dependency problem in your tree,
> > that would be the cleanest solution as we could avoid an additional merge.
> > 
> 
> Please check with Wim.

Thanks Guenter.

Wim, for context, this was a 6 patch series, with 4 patches to the platform
driver x86 tree and 2patches to the watchdog tree. The series was reviewed by
Guenter and Andy, and in v7 Andy replied that he had pushed the series to
testing (the testing branch of the platform driver x86 tree).

https://lkml.org/lkml/2017/4/25/666

>From my perspective, the most direct solution would be to drop these two patches
from the watchdog tree and let them go through the platform driver x86 tree with
Guenter's Acked-by. If you have additional patches which depend on these two,
then if you will provide an immutable branch we can merge, we can do that too
(but I try to keep the number of external merges to a minimum - which is
becoming increasingly difficult lately for some reason).

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > > 
> > >   drivers/watchdog/iTCO_wdt.c
> > > 
> > > between commit:
> > > 
> > >   38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> > > (which also appears in the drivers-x86 tree as commit f583a884afec)
> > > 
> > 
> > Andy and Guenter, I presume the two of you discussed how this patch would get
> > submitted as I see the following in the platform driver x86 for-next branch:
> > 
> >     Acked-by: Guenter Roeck <linux@roeck-us.net>
> >     Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > for both:
> > 
> > 140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
> > f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions
> > 
> 
> I did not expect f583a88/38a700fa1df9 to show up in some other tree, sorry.
> I don't recall discussing how to handle it either, though my memory may defeat
> me. If so, my apologies.
> 
> > This suggests these were deliberately added to our tree and not accidentally
> > included through a rebase without --preserve-merges or something like that.
> > 
> > Guenter, if you prefer/need to submit this through your tree, can you provide
> > us with an immutable branch to merge for the dependencies of our later patches?
> > If you can drop these two patches without a dependency problem in your tree,
> > that would be the cleanest solution as we could avoid an additional merge.
> > 
> 
> Please check with Wim.

Thanks Guenter.

Wim, for context, this was a 6 patch series, with 4 patches to the platform
driver x86 tree and 2patches to the watchdog tree. The series was reviewed by
Guenter and Andy, and in v7 Andy replied that he had pushed the series to
testing (the testing branch of the platform driver x86 tree).

https://lkml.org/lkml/2017/4/25/666

>From my perspective, the most direct solution would be to drop these two patches
from the watchdog tree and let them go through the platform driver x86 tree with
Guenter's Acked-by. If you have additional patches which depend on these two,
then if you will provide an immutable branch we can merge, we can do that too
(but I try to keep the number of external merges to a minimum - which is
becoming increasingly difficult lately for some reason).

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Andy Shevchenko]

On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
>> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
>> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:

> From my perspective, the most direct solution would be to drop these two patches
> from the watchdog tree and let them go through the platform driver x86 tree with
> Guenter's Acked-by. If you have additional patches which depend on these two,
> then if you will provide an immutable branch we can merge, we can do that too
> (but I try to keep the number of external merges to a minimum - which is
> becoming increasingly difficult lately for some reason).

Sorry for not being in doubt, I just decided that Ack from Guenter
means that default case is to go through PDx86 tree without any
additional agreement.

-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Andy Shevchenko]

On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
>> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
>> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:

> From my perspective, the most direct solution would be to drop these two patches
> from the watchdog tree and let them go through the platform driver x86 tree with
> Guenter's Acked-by. If you have additional patches which depend on these two,
> then if you will provide an immutable branch we can merge, we can do that too
> (but I try to keep the number of external merges to a minimum - which is
> becoming increasingly difficult lately for some reason).

Sorry for not being in doubt, I just decided that Ack from Guenter
means that default case is to go through PDx86 tree without any
additional agreement.

-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> 
> > From my perspective, the most direct solution would be to drop these two patches
> > from the watchdog tree and let them go through the platform driver x86 tree with
> > Guenter's Acked-by. If you have additional patches which depend on these two,
> > then if you will provide an immutable branch we can merge, we can do that too
> > (but I try to keep the number of external merges to a minimum - which is
> > becoming increasingly difficult lately for some reason).
> 
> Sorry for not being in doubt, I just decided that Ack from Guenter
> means that default case is to go through PDx86 tree without any
> additional agreement.

I assumed that was the case, yes. I read through the thread and would have
thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
file doesn't really capture the logistics of the watchdog maintainer model, as a
Reviewed-by from a listed maintainer wouldn't be typical unless they expected
someone else to merge it - in this case, I suppose Guenter meant Wim and not us
:-)

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> 
> > From my perspective, the most direct solution would be to drop these two patches
> > from the watchdog tree and let them go through the platform driver x86 tree with
> > Guenter's Acked-by. If you have additional patches which depend on these two,
> > then if you will provide an immutable branch we can merge, we can do that too
> > (but I try to keep the number of external merges to a minimum - which is
> > becoming increasingly difficult lately for some reason).
> 
> Sorry for not being in doubt, I just decided that Ack from Guenter
> means that default case is to go through PDx86 tree without any
> additional agreement.

I assumed that was the case, yes. I read through the thread and would have
thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
file doesn't really capture the logistics of the watchdog maintainer model, as a
Reviewed-by from a listed maintainer wouldn't be typical unless they expected
someone else to merge it - in this case, I suppose Guenter meant Wim and not us
:-)

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Guenter Roeck]

On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > 
> > > From my perspective, the most direct solution would be to drop these two patches
> > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > then if you will provide an immutable branch we can merge, we can do that too
> > > (but I try to keep the number of external merges to a minimum - which is
> > > becoming increasingly difficult lately for some reason).
> > 
> > Sorry for not being in doubt, I just decided that Ack from Guenter
> > means that default case is to go through PDx86 tree without any
> > additional agreement.
> 
> I assumed that was the case, yes. I read through the thread and would have
> thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> file doesn't really capture the logistics of the watchdog maintainer model, as a

Now I am confused. Please apologize my lack of understanding.

I am listed as "Reviewer", not "Maintainer", for watchdog drivers.
Please let me know how that does not capture the logistics of the watchdog
(or any other) maintainer model, and how to better reflect that I review
watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
is what "R:" and "M:" is for ?

The only possibly unusual detail is that I maintain a branch with all patches
I have reviewed. This branch is picked up by Wim and either accepted as-is or,
if he does not agree with some patch, modified accordingly. This branch is
not in linux-next and thus not part of any official maintainer model,
but exists for convenience and to enable additional testing through 0day
and my own test farm.

> Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> :-)
> 

You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
it would be expected for a designated reviewer. I tend to use "Acked-by:"
if I assume or expect that a patch will be picked up by a different maintainer,
though I typically add a note saying that this is the case (no idea if I did
that here). Is there some different set of tags I should use ?

On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".

Thanks,
Guenter

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Guenter Roeck]

On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > 
> > > From my perspective, the most direct solution would be to drop these two patches
> > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > then if you will provide an immutable branch we can merge, we can do that too
> > > (but I try to keep the number of external merges to a minimum - which is
> > > becoming increasingly difficult lately for some reason).
> > 
> > Sorry for not being in doubt, I just decided that Ack from Guenter
> > means that default case is to go through PDx86 tree without any
> > additional agreement.
> 
> I assumed that was the case, yes. I read through the thread and would have
> thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> file doesn't really capture the logistics of the watchdog maintainer model, as a

Now I am confused. Please apologize my lack of understanding.

I am listed as "Reviewer", not "Maintainer", for watchdog drivers.
Please let me know how that does not capture the logistics of the watchdog
(or any other) maintainer model, and how to better reflect that I review
watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
is what "R:" and "M:" is for ?

The only possibly unusual detail is that I maintain a branch with all patches
I have reviewed. This branch is picked up by Wim and either accepted as-is or,
if he does not agree with some patch, modified accordingly. This branch is
not in linux-next and thus not part of any official maintainer model,
but exists for convenience and to enable additional testing through 0day
and my own test farm.

> Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> :-)
> 

You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
it would be expected for a designated reviewer. I tend to use "Acked-by:"
if I assume or expect that a patch will be picked up by a different maintainer,
though I typically add a note saying that this is the case (no idea if I did
that here). Is there some different set of tags I should use ?

On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".

Thanks,
Guenter

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
> On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> > On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > 
> > > > From my perspective, the most direct solution would be to drop these two patches
> > > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > > then if you will provide an immutable branch we can merge, we can do that too
> > > > (but I try to keep the number of external merges to a minimum - which is
> > > > becoming increasingly difficult lately for some reason).
> > > 
> > > Sorry for not being in doubt, I just decided that Ack from Guenter
> > > means that default case is to go through PDx86 tree without any
> > > additional agreement.
> > 
> > I assumed that was the case, yes. I read through the thread and would have
> > thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> > file doesn't really capture the logistics of the watchdog maintainer model, as a
> 
> Now I am confused. Please apologize my lack of understanding.
> 
> I am listed as "Reviewer", not "Maintainer", for watchdog drivers.

:facepalm:

Yes you are, I misread the get_maintainer.pl output ... somehow.

> Please let me know how that does not capture the logistics of the watchdog
> (or any other) maintainer model, and how to better reflect that I review
> watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
> is what "R:" and "M:" is for ?

Nope, it's right, I messed up.

> 
> The only possibly unusual detail is that I maintain a branch with all patches
> I have reviewed. This branch is picked up by Wim and either accepted as-is or,
> if he does not agree with some patch, modified accordingly. This branch is
> not in linux-next and thus not part of any official maintainer model,
> but exists for convenience and to enable additional testing through 0day
> and my own test farm.
> 
> > Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> > someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> > :-)
> > 
> 
> You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
> it would be expected for a designated reviewer. I tend to use "Acked-by:"
> if I assume or expect that a patch will be picked up by a different maintainer,
> though I typically add a note saying that this is the case (no idea if I did
> that here). Is there some different set of tags I should use ?

Nope, we just should have confirmed with Wim.

> On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
> set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".

I noticed this as well. If Wim drops these, we'll correct that in our branch.

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
> On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> > On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > 
> > > > From my perspective, the most direct solution would be to drop these two patches
> > > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > > then if you will provide an immutable branch we can merge, we can do that too
> > > > (but I try to keep the number of external merges to a minimum - which is
> > > > becoming increasingly difficult lately for some reason).
> > > 
> > > Sorry for not being in doubt, I just decided that Ack from Guenter
> > > means that default case is to go through PDx86 tree without any
> > > additional agreement.
> > 
> > I assumed that was the case, yes. I read through the thread and would have
> > thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> > file doesn't really capture the logistics of the watchdog maintainer model, as a
> 
> Now I am confused. Please apologize my lack of understanding.
> 
> I am listed as "Reviewer", not "Maintainer", for watchdog drivers.

:facepalm:

Yes you are, I misread the get_maintainer.pl output ... somehow.

> Please let me know how that does not capture the logistics of the watchdog
> (or any other) maintainer model, and how to better reflect that I review
> watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
> is what "R:" and "M:" is for ?

Nope, it's right, I messed up.

> 
> The only possibly unusual detail is that I maintain a branch with all patches
> I have reviewed. This branch is picked up by Wim and either accepted as-is or,
> if he does not agree with some patch, modified accordingly. This branch is
> not in linux-next and thus not part of any official maintainer model,
> but exists for convenience and to enable additional testing through 0day
> and my own test farm.
> 
> > Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> > someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> > :-)
> > 
> 
> You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
> it would be expected for a designated reviewer. I tend to use "Acked-by:"
> if I assume or expect that a patch will be picked up by a different maintainer,
> though I typically add a note saying that this is the case (no idea if I did
> that here). Is there some different set of tags I should use ?

Nope, we just should have confirmed with Wim.

> On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
> set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".

I noticed this as well. If Wim drops these, we'll correct that in our branch.

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Wim Van Sebroeck]

Hi All,

> On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
> > On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> > > On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > > > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > > > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > > > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > > 
> > > > > From my perspective, the most direct solution would be to drop these two patches
> > > > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > > > then if you will provide an immutable branch we can merge, we can do that too
> > > > > (but I try to keep the number of external merges to a minimum - which is
> > > > > becoming increasingly difficult lately for some reason).
> > > > 
> > > > Sorry for not being in doubt, I just decided that Ack from Guenter
> > > > means that default case is to go through PDx86 tree without any
> > > > additional agreement.
> > > 
> > > I assumed that was the case, yes. I read through the thread and would have
> > > thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> > > file doesn't really capture the logistics of the watchdog maintainer model, as a
> > 
> > Now I am confused. Please apologize my lack of understanding.
> > 
> > I am listed as "Reviewer", not "Maintainer", for watchdog drivers.
> 
> :facepalm:
> 
> Yes you are, I misread the get_maintainer.pl output ... somehow.
> 
> > Please let me know how that does not capture the logistics of the watchdog
> > (or any other) maintainer model, and how to better reflect that I review
> > watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
> > is what "R:" and "M:" is for ?
> 
> Nope, it's right, I messed up.
> 
> > 
> > The only possibly unusual detail is that I maintain a branch with all patches
> > I have reviewed. This branch is picked up by Wim and either accepted as-is or,
> > if he does not agree with some patch, modified accordingly. This branch is
> > not in linux-next and thus not part of any official maintainer model,
> > but exists for convenience and to enable additional testing through 0day
> > and my own test farm.
> > 
> > > Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> > > someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> > > :-)
> > > 
> > 
> > You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
> > it would be expected for a designated reviewer. I tend to use "Acked-by:"
> > if I assume or expect that a patch will be picked up by a different maintainer,
> > though I typically add a note saying that this is the case (no idea if I did
> > that here). Is there some different set of tags I should use ?
> 
> Nope, we just should have confirmed with Wim.
> 
> > On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
> > set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".
> 
> I noticed this as well. If Wim drops these, we'll correct that in our branch.

It makes sence to keep the patches together. I will drop the patches from the watchdog tree.

Kind regards,
Wim.

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Wim Van Sebroeck]

Hi All,

> On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
> > On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:
> > > On Tue, May 02, 2017 at 11:57:18PM +0300, Andy Shevchenko wrote:
> > > > On Tue, May 2, 2017 at 11:21 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > > > On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> > > > >> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > > > >> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > > 
> > > > > From my perspective, the most direct solution would be to drop these two patches
> > > > > from the watchdog tree and let them go through the platform driver x86 tree with
> > > > > Guenter's Acked-by. If you have additional patches which depend on these two,
> > > > > then if you will provide an immutable branch we can merge, we can do that too
> > > > > (but I try to keep the number of external merges to a minimum - which is
> > > > > becoming increasingly difficult lately for some reason).
> > > > 
> > > > Sorry for not being in doubt, I just decided that Ack from Guenter
> > > > means that default case is to go through PDx86 tree without any
> > > > additional agreement.
> > > 
> > > I assumed that was the case, yes. I read through the thread and would have
> > > thought the same. As Guenter is directing us to Wim, I think the MAINTAINERS
> > > file doesn't really capture the logistics of the watchdog maintainer model, as a
> > 
> > Now I am confused. Please apologize my lack of understanding.
> > 
> > I am listed as "Reviewer", not "Maintainer", for watchdog drivers.
> 
> :facepalm:
> 
> Yes you are, I misread the get_maintainer.pl output ... somehow.
> 
> > Please let me know how that does not capture the logistics of the watchdog
> > (or any other) maintainer model, and how to better reflect that I review
> > watchdog patches and Wim, as maintainer, sends them to Linus. I thought that
> > is what "R:" and "M:" is for ?
> 
> Nope, it's right, I messed up.
> 
> > 
> > The only possibly unusual detail is that I maintain a branch with all patches
> > I have reviewed. This branch is picked up by Wim and either accepted as-is or,
> > if he does not agree with some patch, modified accordingly. This branch is
> > not in linux-next and thus not part of any official maintainer model,
> > but exists for convenience and to enable additional testing through 0day
> > and my own test farm.
> > 
> > > Reviewed-by from a listed maintainer wouldn't be typical unless they expected
> > > someone else to merge it - in this case, I suppose Guenter meant Wim and not us
> > > :-)
> > > 
> > 
> > You are correct, "Reviewed-by:" typically is intended for Wim, as I thought
> > it would be expected for a designated reviewer. I tend to use "Acked-by:"
> > if I assume or expect that a patch will be picked up by a different maintainer,
> > though I typically add a note saying that this is the case (no idea if I did
> > that here). Is there some different set of tags I should use ?
> 
> Nope, we just should have confirmed with Wim.
> 
> > On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
> > set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".
> 
> I noticed this as well. If Wim drops these, we'll correct that in our branch.

It makes sence to keep the patches together. I will drop the patches from the watchdog tree.

Kind regards,
Wim.

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Andy Shevchenko]

On Wed, May 3, 2017 at 5:24 PM, Wim Van Sebroeck <wim@iguana.be> wrote:
>> On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
>> > On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:

>> > On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
>> > set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".
>>
>> I noticed this as well. If Wim drops these, we'll correct that in our branch.
>
> It makes sence to keep the patches together. I will drop the patches from the watchdog tree.

Thanks, Wim.

-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Andy Shevchenko]

On Wed, May 3, 2017 at 5:24 PM, Wim Van Sebroeck <wim@iguana.be> wrote:
>> On Tue, May 02, 2017 at 02:58:22PM -0700, Guenter Roeck wrote:
>> > On Tue, May 02, 2017 at 02:30:46PM -0700, Darren Hart wrote:

>> > On a side note, it appears that I tagged "watchdog: iTCO_wdt: cleanup
>> > set/unset no_reboot_bit functions" with "Reviewed-by:", not with "Acked-by:".
>>
>> I noticed this as well. If Wim drops these, we'll correct that in our branch.
>
> It makes sence to keep the patches together. I will drop the patches from the watchdog tree.

Thanks, Wim.

-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Wed, Mar 06, 2019 at 09:27:01PM -0800, Darren Hart wrote:
> On Mon, Mar 04, 2019 at 02:37:35PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > 
> >   include/linux/platform_data/mlxreg.h
> > 
> > between commit:
> > 
> >   9f03161a1bd8 ("platform_data/mlxreg: additions for Mellanox watchdog driver.")
> > 
> > from the watchdog tree and commit:
> > 
> >   9b28aa1d0eae ("platform_data/mlxreg: Document fixes for core platform data")
> > 
> > from the drivers-x86 tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> 
> Thanks Stephen.
> 
> I suspect this will be a rare occurence. That said - Vadim - could you please
> ensure that all the mellanox driver changes Cc the platform driver x86 mailing
> list by adding it to MAINTAINERS?

And, turns out, not so rare. We've been down this road before. I'll just prepare
the patch for the MAINTAINERS.

-- 
Darren Hart
VMware Open Source Technology Center

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Mon, Mar 04, 2019 at 02:37:35PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> 
>   include/linux/platform_data/mlxreg.h
> 
> between commit:
> 
>   9f03161a1bd8 ("platform_data/mlxreg: additions for Mellanox watchdog driver.")
> 
> from the watchdog tree and commit:
> 
>   9b28aa1d0eae ("platform_data/mlxreg: Document fixes for core platform data")
> 
> from the drivers-x86 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen.

I suspect this will be a rare occurence. That said - Vadim - could you please
ensure that all the mellanox driver changes Cc the platform driver x86 mailing
list by adding it to MAINTAINERS?

-- 
Darren Hart
VMware Open Source Technology Center

linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

Hi all,

Today's linux-next merge of the drivers-x86 tree got a conflict in:

  include/linux/platform_data/mlxreg.h

between commit:

  9f03161a1bd8 ("platform_data/mlxreg: additions for Mellanox watchdog driver.")

from the watchdog tree and commit:

  9b28aa1d0eae ("platform_data/mlxreg: Document fixes for core platform data")

from the drivers-x86 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/platform_data/mlxreg.h
index 31f7c25a44da,1b2f86f96743..000000000000
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@@ -120,12 -109,9 +122,12 @@@ struct mlxreg_core_item 
  /**
   * struct mlxreg_core_platform_data - platform data:
   *
-  * @led_data: led private data;
+  * @data: instance private data;
   * @regmap: register map of parent device;
-  * @counter: number of led instances;
+  * @counter: number of instances;
 + * @features: supported features of device;
 + * @version: implementation version;
 + * @identity: device identity name;
   */
  struct mlxreg_core_platform_data {
  	struct mlxreg_core_data *data;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]