Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1449063 > unrolled thread

linux-next: build warning after merge of the tip tree

Back to article view | Back to linux.kernel

Contents

  linux-next: build warning after merge of the tip tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-24 07:40 +0200
    Re: linux-next: build warning after merge of the tip tree Thomas Gleixner <tglx@linutronix.de> - 2016-07-25 09:20 +0200
      Re: linux-next: build warning after merge of the tip tree Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-07-25 15:20 +0200
        Re: linux-next: build warning after merge of the tip tree Rich Felker <dalias@libc.org> - 2016-07-25 17:00 +0200
          Re: linux-next: build warning after merge of the tip tree Mark Brown <broonie@kernel.org> - 2016-07-25 18:50 +0200
            Re: linux-next: build warning after merge of the tip tree Rich Felker <dalias@libc.org> - 2016-07-25 20:00 +0200
      Re: linux-next: build warning after merge of the tip tree Rich Felker <dalias@libc.org> - 2016-07-25 17:00 +0200

#1449063 — linux-next: build warning after merge of the tip tree

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

In file included from include/linux/clocksource.h:18:0,
                 from include/linux/clockchips.h:13,
                 from drivers/clocksource/jcore-pit.c:14:
include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
        .data = (fn == (fn_type)NULL) ? fn : fn  }
                    ^
include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
   _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
   ^
include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
  OF_DECLARE_1_RET(clksrc, name, compat, fn)
  ^
drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
 CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
 ^

Introduced by commits

  b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
  177cf6e52b0a ("clocksources: Switch back to the clksrc table")

interacting with commit

  e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")

from the sh tree.

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1449321

On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> In file included from include/linux/clocksource.h:18:0,
>                  from include/linux/clockchips.h:13,
>                  from drivers/clocksource/jcore-pit.c:14:
> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
>         .data = (fn == (fn_type)NULL) ? fn : fn  }
>                     ^
> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
>    ^
> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
>   ^
> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
>  ^
> 
> Introduced by commits
> 
>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> 
> interacting with commit
> 
>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> 
> from the sh tree.

And why is that driver coming through the superh tree and not through the
clocksource maintainers? It's not only based on an old interface it's probably
unreviewed as well ...

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1449470

On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> produced this warning:
>>
>> In file included from include/linux/clocksource.h:18:0,
>>                  from include/linux/clockchips.h:13,
>>                  from drivers/clocksource/jcore-pit.c:14:
>> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
>>         .data = (fn == (fn_type)NULL) ? fn : fn  }
>>                     ^
>> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
>>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
>>    ^
>> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
>>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
>>   ^
>> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
>>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
>>  ^
>>
>> Introduced by commits
>>
>>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
>>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
>>
>> interacting with commit
>>
>>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
>>
>> from the sh tree.
> 
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...

Rich,

why are these changes in linux-next ?

Except I am missing something, I don't see a new version sent for review
on the mailing list. The interrupt controller driver is almost empty as
stated by Marc Zyngier and there is no explanation / discussion about it.

I don't know the goal of adding those patches in linux-next via your
tree, may be you misunderstood how linux-next works and you should
remove them. But if the purpose was to merge the patches, I remind you
that being an arch maintainer does not give you the right to apply any
patches, everywhere, at all cost, without review, because you want them
in, you must follow the process, otherwise you take the risk to upset a
lot of people and to be kicked out.

 -- Daniel




-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [prev] | [next] | [standalone]

#1449555

On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> > On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> produced this warning:
> >>
> >> In file included from include/linux/clocksource.h:18:0,
> >>                  from include/linux/clockchips.h:13,
> >>                  from drivers/clocksource/jcore-pit.c:14:
> >> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> >>         .data = (fn == (fn_type)NULL) ? fn : fn  }
> >>                     ^
> >> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> >>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> >>    ^
> >> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> >>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
> >>   ^
> >> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> >>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> >>  ^
> >>
> >> Introduced by commits
> >>
> >>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> >>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> >>
> >> interacting with commit
> >>
> >>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> >>
> >> from the sh tree.
> > 
> > And why is that driver coming through the superh tree and not through the
> > clocksource maintainers? It's not only based on an old interface it's probably
> > unreviewed as well ...
> 
> Rich,
> 
> why are these changes in linux-next ?
> 
> Except I am missing something, I don't see a new version sent for review
> on the mailing list. The interrupt controller driver is almost empty as
> stated by Marc Zyngier and there is no explanation / discussion about it.
> 
> I don't know the goal of adding those patches in linux-next via your
> tree, may be you misunderstood how linux-next works and you should
> remove them. But if the purpose was to merge the patches, I remind you
> that being an arch maintainer does not give you the right to apply any
> patches, everywhere, at all cost, without review, because you want them
> in, you must follow the process, otherwise you take the risk to upset a
> lot of people and to be kicked out.

If this is upsetting people I can remove them. Last time I got
feedback from at least one (driver) subsystem maintainer that (if I
understood it correctly) indicated they would like to have seen the
patch in linux-next without problems before upstreaming it through
their tree. That was my motivation for including it here. I'm not
trying to bypass other maintainers to push patches upstream and I can
remove all non-arch/sh stuff from for-next if that would be better.

Rich

[toc] | [prev] | [next] | [standalone]

#1449655

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:

> > I don't know the goal of adding those patches in linux-next via your
> > tree, may be you misunderstood how linux-next works and you should
> > remove them. But if the purpose was to merge the patches, I remind you
> > that being an arch maintainer does not give you the right to apply any
> > patches, everywhere, at all cost, without review, because you want them
> > in, you must follow the process, otherwise you take the risk to upset a
> > lot of people and to be kicked out.

> If this is upsetting people I can remove them. Last time I got
> feedback from at least one (driver) subsystem maintainer that (if I
> understood it correctly) indicated they would like to have seen the
> patch in linux-next without problems before upstreaming it through

I think that was me and you've very much misunderstood what I was
saying.  A that time you were sending new drivers during the merge
window with the apparent expectation that they would be merged during
that merge window.  That's not going to happen, things need to go into
-next before the merge window.  This means that you need to submit your
patches well in advance of the merge window so they can be reviewed and
ideally applied to maintainer trees before the merge window opens.

It does not mean that you should include unreviewed code for other trees
in your -next tree, that's not the purpose of -next.  What goes into
-next from each maintainer tree should be what is currently intended to
go to Linus for that tree in the next merge window.

[toc] | [prev] | [next] | [standalone]

#1449699

On Mon, Jul 25, 2016 at 05:42:09PM +0100, Mark Brown wrote:
> On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> > On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> 
> > > I don't know the goal of adding those patches in linux-next via your
> > > tree, may be you misunderstood how linux-next works and you should
> > > remove them. But if the purpose was to merge the patches, I remind you
> > > that being an arch maintainer does not give you the right to apply any
> > > patches, everywhere, at all cost, without review, because you want them
> > > in, you must follow the process, otherwise you take the risk to upset a
> > > lot of people and to be kicked out.
> 
> > If this is upsetting people I can remove them. Last time I got
> > feedback from at least one (driver) subsystem maintainer that (if I
> > understood it correctly) indicated they would like to have seen the
> > patch in linux-next without problems before upstreaming it through
> 
> I think that was me and you've very much misunderstood what I was
> saying.  A that time you were sending new drivers during the merge
> window with the apparent expectation that they would be merged during
> that merge window.  That's not going to happen, things need to go into
> -next before the merge window.  This means that you need to submit your
> patches well in advance of the merge window so they can be reviewed and
> ideally applied to maintainer trees before the merge window opens.
> 
> It does not mean that you should include unreviewed code for other trees
> in your -next tree, that's not the purpose of -next.  What goes into
> -next from each maintainer tree should be what is currently intended to
> go to Linus for that tree in the next merge window.

OK, thanks for the clarification. I'll remove the drivers from my
for-next branch.

Rich

[toc] | [prev] | [next] | [standalone]

#1449549

On Mon, Jul 25, 2016 at 09:16:48AM +0200, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> > 
> > In file included from include/linux/clocksource.h:18:0,
> >                  from include/linux/clockchips.h:13,
> >                  from drivers/clocksource/jcore-pit.c:14:
> > include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> >         .data = (fn == (fn_type)NULL) ? fn : fn  }
> >                     ^
> > include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> >    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> >    ^
> > include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> >   OF_DECLARE_1_RET(clksrc, name, compat, fn)
> >   ^
> > drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> >  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> >  ^
> > 
> > Introduced by commits
> > 
> >   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> >   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> > 
> > interacting with commit
> > 
> >   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> > 
> > from the sh tree.
> 
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...

Drivers will go upstream through their proper subsystem maintainers,
not from my tree, but last time I got feedback that these drivers had
not seen any testing in linux-next. I can refrain from including
patches that I can't upstream directly in my for-next branch in the
future if you'd prefer but this way seemed to make less work for
others.

Rich

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web