linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warning in Linus' tree
@ 2013-12-17 22:52 Stephen Rothwell
  2013-12-18  2:54 ` Skidmore, Donald C
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2013-12-17 22:52 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, John Fastabend, Neil Horman

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

Hi all,

While building Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c: In function 'ixgbe_pci_sriov_disable':
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c:294:6: warning: unused variable 'current_flags' [-Wunused-variable]
  u32 current_flags = adapter->flags;
      ^

Introduced by commit 2a47fa45d4df ("ixgbe: enable l2 forwarding
acceleration for macvlans") which was merged before v3.13-rc1.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: linux-next: build warning in Linus' tree
  2013-12-17 22:52 linux-next: build warning in Linus' tree Stephen Rothwell
@ 2013-12-18  2:54 ` Skidmore, Donald C
  0 siblings, 0 replies; 85+ messages in thread
From: Skidmore, Donald C @ 2013-12-18  2:54 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, netdev
  Cc: linux-next, linux-kernel, Fastabend, John R, Neil Horman



> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Stephen Rothwell
> Sent: Tuesday, December 17, 2013 2:52 PM
> To: David Miller; netdev@vger.kernel.org
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Fastabend,
> John R; Neil Horman
> Subject: linux-next: build warning in Linus' tree
> 
> Hi all,
> 
> While building Linus' tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c: In function
> 'ixgbe_pci_sriov_disable':
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c:294:6: warning: unused
> variable 'current_flags' [-Wunused-variable]
>   u32 current_flags = adapter->flags;
>       ^
> 
> Introduced by commit 2a47fa45d4df ("ixgbe: enable l2 forwarding
> acceleration for macvlans") which was merged before v3.13-rc1.
> 
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au


Hey Stephen,

Thanks for letting us know about this.   As it turns out we already have a patch to fix this in our internal tree (Jeff K's) just waiting final validation.  It shouldn't be long before he submits it.

Thanks again,
-Don Skidmore <donald.c.skidmore@intel.com>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: linux-next: build warning in Linus' tree
       [not found] ` <ANQAFAC9EhHeWK1g5-2FP4ol.9.1634779695838.Hmail.changfengnan@vivo.com>
@ 2021-10-21  1:32   ` 常凤楠
  0 siblings, 0 replies; 85+ messages in thread
From: 常凤楠 @ 2021-10-21  1:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jaegeuk Kim, Linux Kernel Mailing List, Linux Next Mailing List

I will fix this later, Thanks for your remind.

> -----Original Message-----
> From: changfengnan@vivo.com <changfengnan@vivo.com> On Behalf Of
> Stephen Rothwell
> Sent: Thursday, October 21, 2021 9:28 AM
> To: 常凤楠 <changfengnan@vivo.com>
> Cc: Jaegeuk Kim <jaegeuk@kernel.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Linux Next Mailing List
> <linux-next@vger.kernel.org>
> Subject: Re: linux-next: build warning in Linus' tree
> 
> Hi all,
> 
> On Tue, 5 Oct 2021 20:29:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> >
> > In Linus' tree, today's linux-next build (htmldocs) produced this warning:
> >
> > Documentation/filesystems/f2fs.rst:288: WARNING: Block quote ends
> without a blank line; unexpected unindent.
> >
> > Introduced by commit
> >
> >   151b1982be5d ("f2fs: compress: add nocompress extensions support")
> 
> I ma still seeing this warning.
> 
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2021-10-05  9:29 Stephen Rothwell
@ 2021-10-21  1:28 ` Stephen Rothwell
       [not found] ` <ANQAFAC9EhHeWK1g5-2FP4ol.9.1634779695838.Hmail.changfengnan@vivo.com>
  1 sibling, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2021-10-21  1:28 UTC (permalink / raw)
  To: Fengnan Chang
  Cc: Jaegeuk Kim, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Tue, 5 Oct 2021 20:29:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> In Linus' tree, today's linux-next build (htmldocs) produced this warning:
> 
> Documentation/filesystems/f2fs.rst:288: WARNING: Block quote ends without a blank line; unexpected unindent.
> 
> Introduced by commit
> 
>   151b1982be5d ("f2fs: compress: add nocompress extensions support")

I ma still seeing this warning.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-10-05  9:42 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2021-10-05  9:42 UTC (permalink / raw)
  To: Logan Gunthorpe
  Cc: Christoph Hellwig, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

In Linus' tree, today's linux-next build (htmldocs) produced this warning:

Documentation/driver-api/infrastructure:50: /home/sfr/next/next/kernel/dma/mapping.c:256: WARNING: Definition list ends without a blank line; unexpected unindent.
Documentation/driver-api/infrastructure:50: /home/sfr/next/next/kernel/dma/mapping.c:257: WARNING: Bullet list ends without a blank line; unexpected unindent.

Introduced by commit

  fffe3cc8c219 ("dma-mapping: allow map_sg() ops to return negative error codes")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-10-05  9:29 Stephen Rothwell
  2021-10-21  1:28 ` Stephen Rothwell
       [not found] ` <ANQAFAC9EhHeWK1g5-2FP4ol.9.1634779695838.Hmail.changfengnan@vivo.com>
  0 siblings, 2 replies; 85+ messages in thread
From: Stephen Rothwell @ 2021-10-05  9:29 UTC (permalink / raw)
  To: Fengnan Chang
  Cc: Jaegeuk Kim, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

In Linus' tree, today's linux-next build (htmldocs) produced this warning:

Documentation/filesystems/f2fs.rst:288: WARNING: Block quote ends without a blank line; unexpected unindent.

Introduced by commit

  151b1982be5d ("f2fs: compress: add nocompress extensions support")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-08-30  8:33 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2021-08-30  8:33 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

When building Linus' tree, today's linux-next build (powerpc
ppc44x_defconfig) produced this warning:

block/mq-deadline.c:274:12: warning: 'dd_queued' defined but not used [-Wunused-function]
  274 | static u32 dd_queued(struct deadline_data *dd, enum dd_prio prio)
      |            ^~~~~~~~~

Introduced by commit

  7b05bf771084 ("Revert "block/mq-deadline: Prioritize high-priority requests"")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2021-03-23  5:51 Stephen Rothwell
@ 2021-03-23  8:49 ` Peter Zijlstra
  0 siblings, 0 replies; 85+ messages in thread
From: Peter Zijlstra @ 2021-03-23  8:49 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Mar 23, 2021 at 04:51:45PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Building Linus' tree, today's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> kernel/static_call.c: In function '__static_call_update':
> kernel/static_call.c:153:18: warning: unused variable 'mod' [-Wunused-variable]
>   153 |   struct module *mod = site_mod->mod;
>       |                  ^~~
> 
> Introduced by commit
> 
>   698bacefe993 ("static_call: Align static_call_is_init() patching condition")

Blergh... that's MODULE=n. I'll see if I can find something that's not
too ugly there..

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-03-23  5:51 Stephen Rothwell
  2021-03-23  8:49 ` Peter Zijlstra
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2021-03-23  5:51 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Building Linus' tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

kernel/static_call.c: In function '__static_call_update':
kernel/static_call.c:153:18: warning: unused variable 'mod' [-Wunused-variable]
  153 |   struct module *mod = site_mod->mod;
      |                  ^~~

Introduced by commit

  698bacefe993 ("static_call: Align static_call_is_init() patching condition")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: linux-next: build warning in Linus' tree
  2021-02-23 21:50   ` Stephen Rothwell
@ 2021-02-23 22:01     ` Ernst, Justin
  0 siblings, 0 replies; 85+ messages in thread
From: Ernst, Justin @ 2021-02-23 22:01 UTC (permalink / raw)
  To: Stephen Rothwell, Borislav Petkov, Mauro Carvalho Chehab
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Anderson, Russ

> Hi all,
> 
> On Thu, 18 Feb 2021 22:47:57 +0000 "Ernst, Justin" <justin.ernst@hpe.com> wrote:
> >
> > Hi,
> > We made a special effort to squash the unexpected indentation warnings in c159376490ee
> (https://lore.kernel.org/lkml/20201130214304.369348-1-justin.ernst@hpe.com/), so I was surprised to
> see this again.
> > Commit:
> >
> > 	c9624cb7db1c ("x86/platform/uv: Update sysfs documentation")
> >
> > is the culprit here. I suspect it was written and submitted before we made the effort to fix the
> Unexpected indentation in c159376490ee, so it misplaced the first line of a codeblock, the original
> problem that was reported and fixed.
> >
> > The fix:
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-
> firmware-sgi_uv
> > index 637c668cbe45..12ed843e1d3e 100644
> > --- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
> > +++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
> > @@ -39,8 +39,8 @@ Description:
> >
> >                 The uv_type entry contains the hub revision number.
> >                 This value can be used to identify the UV system version::
> > -                       "0.*" = Hubless UV ('*' is subtype)
> >
> > +                       "0.*" = Hubless UV ('*' is subtype)
> >                         "3.0" = UV2
> >                         "5.0" = UV3
> >                         "7.0" = UV4
> >
> > Thanks,
> > Justin
> >
> > > Building Linus' tree, today's linux-next build (htmldocs) produced
> > > this warning:
> > >
> > > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > >
> > > Introduced by commit
> > >
> > >   c159376490ee ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")
> > >
> > > Or maybe an ealier one.
> > >
> > > This has been around for some time.
> 
> I am still seeing this warning.

I submitted a patch here: https://lore.kernel.org/lkml/20210219182852.385297-1-justin.ernst@hpe.com/

Thanks,
Justin Ernst

> 
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2021-02-18 22:47 ` Ernst, Justin
@ 2021-02-23 21:50   ` Stephen Rothwell
  2021-02-23 22:01     ` Ernst, Justin
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2021-02-23 21:50 UTC (permalink / raw)
  To: Borislav Petkov, Mauro Carvalho Chehab
  Cc: Ernst, Justin, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Thu, 18 Feb 2021 22:47:57 +0000 "Ernst, Justin" <justin.ernst@hpe.com> wrote:
>
> Hi,
> We made a special effort to squash the unexpected indentation warnings in c159376490ee (https://lore.kernel.org/lkml/20201130214304.369348-1-justin.ernst@hpe.com/), so I was surprised to see this again.
> Commit:
> 
> 	c9624cb7db1c ("x86/platform/uv: Update sysfs documentation")
> 
> is the culprit here. I suspect it was written and submitted before we made the effort to fix the Unexpected indentation in c159376490ee, so it misplaced the first line of a codeblock, the original problem that was reported and fixed.
> 
> The fix:
> 
> diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
> index 637c668cbe45..12ed843e1d3e 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
> +++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
> @@ -39,8 +39,8 @@ Description:
> 
>                 The uv_type entry contains the hub revision number.
>                 This value can be used to identify the UV system version::
> -                       "0.*" = Hubless UV ('*' is subtype)
> 
> +                       "0.*" = Hubless UV ('*' is subtype)
>                         "3.0" = UV2
>                         "5.0" = UV3
>                         "7.0" = UV4
> 
> Thanks,
> Justin
> 
> > Building Linus' tree, today's linux-next build (htmldocs) produced
> > this warning:
> > 
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > 
> > Introduced by commit
> > 
> >   c159376490ee ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")
> > 
> > Or maybe an ealier one.
> > 
> > This has been around for some time.

I am still seeing this warning.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: linux-next: build warning in Linus' tree
  2021-02-18 20:58 Stephen Rothwell
@ 2021-02-18 22:47 ` Ernst, Justin
  2021-02-23 21:50   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Ernst, Justin @ 2021-02-18 22:47 UTC (permalink / raw)
  To: Stephen Rothwell, Borislav Petkov
  Cc: Mauro Carvalho Chehab, Linux Kernel Mailing List,
	Linux Next Mailing List

Hi,
We made a special effort to squash the unexpected indentation warnings in c159376490ee (https://lore.kernel.org/lkml/20201130214304.369348-1-justin.ernst@hpe.com/), so I was surprised to see this again.
Commit:

	c9624cb7db1c ("x86/platform/uv: Update sysfs documentation")

is the culprit here. I suspect it was written and submitted before we made the effort to fix the Unexpected indentation in c159376490ee, so it misplaced the first line of a codeblock, the original problem that was reported and fixed.

The fix:

diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 637c668cbe45..12ed843e1d3e 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -39,8 +39,8 @@ Description:

                The uv_type entry contains the hub revision number.
                This value can be used to identify the UV system version::
-                       "0.*" = Hubless UV ('*' is subtype)

+                       "0.*" = Hubless UV ('*' is subtype)
                        "3.0" = UV2
                        "5.0" = UV3
                        "7.0" = UV4

Thanks,
Justin

> Hi all,
> 
> Building Linus' tree, today's linux-next build (htmldocs) produced
> this warning:
> 
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> 
> Introduced by commit
> 
>   c159376490ee ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")
> 
> Or maybe an ealier one.
> 
> This has been around for some time.
> 
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-02-18 20:58 Stephen Rothwell
  2021-02-18 22:47 ` Ernst, Justin
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2021-02-18 20:58 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Justin Ernst, Mauro Carvalho Chehab, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

Building Linus' tree, today's linux-next build (htmldocs) produced
this warning:

Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.

Introduced by commit

  c159376490ee ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")

Or maybe an ealier one.

This has been around for some time.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2021-01-03 22:07 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2021-01-03 22:07 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

While building Linus' tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/pinctrl/nomadik/pinctrl-nomadik.c: In function 'nmk_gpio_dbg_show_one':
drivers/pinctrl/nomadik/pinctrl-nomadik.c:952:8: warning: unused variable 'wake' [-Wunused-variable]
  952 |   bool wake;
      |        ^~~~

Introduced by commit

  f3925032d7fd ("pinctrl: nomadik: Use irq_has_action()")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2020-10-28 15:56 ` Micah Morton
@ 2020-10-28 21:07   ` Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2020-10-28 21:07 UTC (permalink / raw)
  To: Micah Morton
  Cc: Thomas Cedeno, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Micah,

On Wed, 28 Oct 2020 08:56:00 -0700 Micah Morton <mortonm@chromium.org> wrote:
>
> Thanks for the heads up. I think someone sent a patch to fix this
> yesterday: https://marc.info/?l=linux-doc&m=160379233902729&w=2
> 
> Do I need to do anything else or should that cover it?

That should be fine, thanks.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2020-10-28  3:28 Stephen Rothwell
@ 2020-10-28 15:56 ` Micah Morton
  2020-10-28 21:07   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Micah Morton @ 2020-10-28 15:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Cedeno, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 27, 2020 at 8:28 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> In Linus' tree, today's linux-next build (htmldocs) produced
> this warning:
>
> Documentation/admin-guide/LSM/SafeSetID.rst:110: WARNING: Title underline too short.

Thanks for the heads up. I think someone sent a patch to fix this
yesterday: https://marc.info/?l=linux-doc&m=160379233902729&w=2

Do I need to do anything else or should that cover it?

>
> Introduced by commit
>
>   5294bac97e12 ("LSM: SafeSetID: Add GID security policy handling")
>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2020-10-28  3:28 Stephen Rothwell
  2020-10-28 15:56 ` Micah Morton
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2020-10-28  3:28 UTC (permalink / raw)
  To: Micah Morton
  Cc: Thomas Cedeno, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

In Linus' tree, today's linux-next build (htmldocs) produced
this warning:

Documentation/admin-guide/LSM/SafeSetID.rst:110: WARNING: Title underline too short.

Introduced by commit

  5294bac97e12 ("LSM: SafeSetID: Add GID security policy handling")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2020-02-21  3:39 Stephen Rothwell
@ 2020-02-21  6:51 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 85+ messages in thread
From: Gustavo A. R. Silva @ 2020-02-21  6:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Greg Kroah-Hartman, Linux USB Mailing List



On 2/20/20 21:39, Stephen Rothwell wrote:
> Hi all,
> 
> For some time I have been getting the following warning from the powerpc
> allyesconfig build:
> 
> drivers/usb/host/fhci-hcd.c: In function 'fhci_urb_enqueue':
> drivers/usb/host/fhci-hcd.c:398:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
>   398 |   size = 2;
>       |   ~~~~~^~~
> drivers/usb/host/fhci-hcd.c:399:2: note: here
>   399 |  case PIPE_BULK:
>       |  ^~~~
> 
> Introduced by commit
> 
>   236dd4d18f29 ("USB: Driver for Freescale QUICC Engine USB Host Controller")
> 
> from 2009, but exposed only recently.
> 

Thanks for the report, Stephen. The following patch should fix that:

https://lore.kernel.org/lkml/20200213085401.27862-1-linux@rasmusvillemoes.dk/

Greg,

I would just replace the two "Fixes" tags in the patch above with this one:

Fixes: 236dd4d18f29 ("USB: Driver for Freescale QUICC Engine USB Host Controller")

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2020-02-21  3:39 Stephen Rothwell
  2020-02-21  6:51 ` Gustavo A. R. Silva
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2020-02-21  3:39 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Greg Kroah-Hartman, Linux USB Mailing List

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

Hi all,

For some time I have been getting the following warning from the powerpc
allyesconfig build:

drivers/usb/host/fhci-hcd.c: In function 'fhci_urb_enqueue':
drivers/usb/host/fhci-hcd.c:398:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
  398 |   size = 2;
      |   ~~~~~^~~
drivers/usb/host/fhci-hcd.c:399:2: note: here
  399 |  case PIPE_BULK:
      |  ^~~~

Introduced by commit

  236dd4d18f29 ("USB: Driver for Freescale QUICC Engine USB Host Controller")

from 2009, but exposed only recently.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2017-11-02 21:08 ` Ingo Molnar
@ 2017-11-02 21:21   ` Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2017-11-02 21:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Linux-Next Mailing List,
	Linux Kernel Mailing List, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, x86, Arnaldo Carvalho de Melo

Hi Ingo,

On Thu, 2 Nov 2017 22:08:19 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> The warnings are harmless, I'll take care of them tomorrow.

Excellent, thanks.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2017-11-02 20:29 Stephen Rothwell
@ 2017-11-02 21:08 ` Ingo Molnar
  2017-11-02 21:21   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Ingo Molnar @ 2017-11-02 21:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linus Torvalds, Linux-Next Mailing List,
	Linux Kernel Mailing List, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, x86, Arnaldo Carvalho de Melo


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus,
> 
> Just building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> warning: objtool: x86 instruction decoder differs from kernel
> 
> This is a change since yesterday.  Linus' tree has been updated with
> these commits since then:
> 
>   4f2ba5dc183b7..ead751507de8
> 
> so, I assume this is just due to the SPDX ids being added to files that
> objtool cares about.
> 
> The perf build also produced lots of Warnings about differences in
> include files.

The warnings are harmless, I'll take care of them tomorrow.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2017-11-02 20:29 Stephen Rothwell
  2017-11-02 21:08 ` Ingo Molnar
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2017-11-02 20:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86

Hi Linus,

Just building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

warning: objtool: x86 instruction decoder differs from kernel

This is a change since yesterday.  Linus' tree has been updated with
these commits since then:

  4f2ba5dc183b7..ead751507de8

so, I assume this is just due to the SPDX ids being added to files that
objtool cares about.

The perf build also produced lots of Warnings about differences in
include files.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2016-11-13 22:25 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2016-11-13 22:25 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-next, linux-kernel, Linus

Hi all,

Starting with Linus' tree, today's linux-next build (x86_64 allmodconfig) produced
this warning:

WARNING: modpost: missing MODULE_LICENSE() in drivers/media/dvb-frontends/gp8psk-fe.o

Introduced by commit

  7a0786c19d65 ("gp8psk: Fix DVB frontend attach")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-29 21:29     ` Geert Uytterhoeven
@ 2016-10-30 19:05       ` Andrey Ryabinin
  0 siblings, 0 replies; 85+ messages in thread
From: Andrey Ryabinin @ 2016-10-30 19:05 UTC (permalink / raw)
  To: Geert Uytterhoeven, Linus Torvalds
  Cc: Stephen Rothwell, Alexander Potapenko, Dmitry Vyukov, linux-next,
	Linux Kernel Mailing List



On 10/30/2016 12:29 AM, Geert Uytterhoeven wrote:
> Hi Linus,
> 
> On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
>>> does seem to disable a lot of build-time testing.
>>
>> Actually, we should probably just make the MEMORY_HOTPLUG dependency be
>>
>>         depends on COMPILE_TEST || !KASAN
>>
>> since the memory-hotplug code should still *build* with KASAN, it just
>> doesn't work. That's exactly what the COMPILE_TEST config option is
>> there for - to get build coverage even for things that aren't
>> necessarily sane to run.
> 
> In what way does it not work? Does it crash?

It doesn't crash, it will fail to online hotpluged memory.
Originally, we didn't have build-time dependency at all.
It appeared quite recently in 1e185736d214("mm: disable CONFIG_MEMORY_HOTPLUG when KASAN is enabled")

> People do run COMPILE_TEST=y/allmodconfig kernels.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 23:01   ` Linus Torvalds
  2016-10-27 23:05     ` Alexander Potapenko
  2016-10-27 23:40     ` Stephen Rothwell
@ 2016-10-29 21:29     ` Geert Uytterhoeven
  2016-10-30 19:05       ` Andrey Ryabinin
  2 siblings, 1 reply; 85+ messages in thread
From: Geert Uytterhoeven @ 2016-10-29 21:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephen Rothwell, Andrey Ryabinin, Alexander Potapenko,
	Dmitry Vyukov, linux-next, Linux Kernel Mailing List

Hi Linus,

On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
>> does seem to disable a lot of build-time testing.
>
> Actually, we should probably just make the MEMORY_HOTPLUG dependency be
>
>         depends on COMPILE_TEST || !KASAN
>
> since the memory-hotplug code should still *build* with KASAN, it just
> doesn't work. That's exactly what the COMPILE_TEST config option is
> there for - to get build coverage even for things that aren't
> necessarily sane to run.

In what way does it not work? Does it crash?
People do run COMPILE_TEST=y/allmodconfig kernels.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 23:01   ` Linus Torvalds
  2016-10-27 23:05     ` Alexander Potapenko
@ 2016-10-27 23:40     ` Stephen Rothwell
  2016-10-29 21:29     ` Geert Uytterhoeven
  2 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2016-10-27 23:40 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, linux-next,
	Linux Kernel Mailing List

Hi Linus,

On Thu, 27 Oct 2016 16:01:22 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> In the meantime, thanks for noticing and letting me know.

It was pointed out by the extra checking you asked me to add in order
to easier detect new warnings for code added to linux-next :-)

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 23:05     ` Alexander Potapenko
@ 2016-10-27 23:25       ` Linus Torvalds
  0 siblings, 0 replies; 85+ messages in thread
From: Linus Torvalds @ 2016-10-27 23:25 UTC (permalink / raw)
  To: Alexander Potapenko
  Cc: Stephen Rothwell, Andrey Ryabinin, Dmitry Vyukov, linux-next,
	Linux Kernel Mailing List

On Thu, Oct 27, 2016 at 4:05 PM, Alexander Potapenko <glider@google.com> wrote:
>
> Maybe we could just reverse the MEMORY_HOTPLUG->!KASAN dependency to
> make it KASAN->!MEMORY_HOTPLUG?

Yes, that was my initial approach too, but then I decided that I'd
rather build-test both together anyway. Since I can. So that just gets
me the best of both worlds.

We've had issues like this before, and "make allmodconfig" will never
enable _everything_ (ie you always have to make some choices that will
disable other cases, if only for reasons like SLUB-vs-SLAB etc).

But in general the more coverage I get from build testing (without
having to do lots and lots of builds - that's what the build farms are
for after I have pushed things out), the better.

             Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 23:01   ` Linus Torvalds
@ 2016-10-27 23:05     ` Alexander Potapenko
  2016-10-27 23:25       ` Linus Torvalds
  2016-10-27 23:40     ` Stephen Rothwell
  2016-10-29 21:29     ` Geert Uytterhoeven
  2 siblings, 1 reply; 85+ messages in thread
From: Alexander Potapenko @ 2016-10-27 23:05 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephen Rothwell, Andrey Ryabinin, Dmitry Vyukov, linux-next,
	Linux Kernel Mailing List

On Thu, Oct 27, 2016 at 4:01 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
>> does seem to disable a lot of build-time testing.
>
> Actually, we should probably just make the MEMORY_HOTPLUG dependency be
>
>         depends on COMPILE_TEST || !KASAN

Maybe we could just reverse the MEMORY_HOTPLUG->!KASAN dependency to
make it KASAN->!MEMORY_HOTPLUG?

Is it at all correct that allmodconfig enables KASAN? If/when we have
other compiler-based tools, which of them will allmodconfig pick?
> since the memory-hotplug code should still *build* with KASAN, it just
> doesn't work. That's exactly what the COMPILE_TEST config option is
> there for - to get build coverage even for things that aren't
> necessarily sane to run.
>
> I'll do that, to get my build coverage up. I really expected my
> allmodconfig builds to verify that I had removed the per-zone
> waitqueue code completely, and I'm happy that the breakage was
> apparently limited to that unused variable..
>
> In the meantime, thanks for noticing and letting me know.
>
>             Linus



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 22:48 ` Linus Torvalds
@ 2016-10-27 23:01   ` Linus Torvalds
  2016-10-27 23:05     ` Alexander Potapenko
                       ` (2 more replies)
  0 siblings, 3 replies; 85+ messages in thread
From: Linus Torvalds @ 2016-10-27 23:01 UTC (permalink / raw)
  To: Stephen Rothwell, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov
  Cc: linux-next, Linux Kernel Mailing List

On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
> does seem to disable a lot of build-time testing.

Actually, we should probably just make the MEMORY_HOTPLUG dependency be

        depends on COMPILE_TEST || !KASAN

since the memory-hotplug code should still *build* with KASAN, it just
doesn't work. That's exactly what the COMPILE_TEST config option is
there for - to get build coverage even for things that aren't
necessarily sane to run.

I'll do that, to get my build coverage up. I really expected my
allmodconfig builds to verify that I had removed the per-zone
waitqueue code completely, and I'm happy that the breakage was
apparently limited to that unused variable..

In the meantime, thanks for noticing and letting me know.

            Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2016-10-27 22:29 Stephen Rothwell
@ 2016-10-27 22:48 ` Linus Torvalds
  2016-10-27 23:01   ` Linus Torvalds
  0 siblings, 1 reply; 85+ messages in thread
From: Linus Torvalds @ 2016-10-27 22:48 UTC (permalink / raw)
  To: Stephen Rothwell, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov
  Cc: linux-next, Linux Kernel Mailing List

On Thu, Oct 27, 2016 at 3:29 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Building your tree, today's linux-next build (powerpc ppc64_defconfig)
> produced this warning:
>
> mm/memory_hotplug.c: In function 'try_offline_node':
> mm/memory_hotplug.c:2120:6: warning: unused variable 'i' [-Wunused-variable]
>  int i;
>      ^
>
> Introduced by commit
>
>   9dcb8b685fc3 ("mm: remove per-zone hashtable of bitlock waitqueues")

Strange. I wonder why I didn't see that warning. Not with
allmodconfig, and not with my normal build.

[ Looks around ]

Hmm. Apparently "allmodconfig" doesn't actually enable memory hotplug.
And the reason is that allmodconfig enables KASAN, which then disables
MEMORY_HOTPLUG.

I wonder if we should make KASAN depend on !COMPILE_TEST, because it
does seem to disable a lot of build-time testing.

Oh well. I'll remove the stupid unused variable, thanks for the heads-up.

          Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2016-10-27 22:29 Stephen Rothwell
  2016-10-27 22:48 ` Linus Torvalds
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2016-10-27 22:29 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-next, linux-kernel

Hi Linus,

Building your tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

mm/memory_hotplug.c: In function 'try_offline_node':
mm/memory_hotplug.c:2120:6: warning: unused variable 'i' [-Wunused-variable]
 int i;
     ^

Introduced by commit

  9dcb8b685fc3 ("mm: remove per-zone hashtable of bitlock waitqueues")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2016-04-12 23:59 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2016-04-12 23:59 UTC (permalink / raw)
  To: Dave Airlie; +Cc: linux-next, linux-kernel, Rob Clark

Hi Dave,

Staring with Linus' tree, today's (and presumably previous) linux-next
build (arm multi_v7_defconfig) produced this warning:

drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
drivers/gpu/drm/msm/msm_drv.c:468:18: warning: unused variable 'kms' [-Wunused-variable]
  struct msm_kms *kms = priv->kms;
                  ^

Introduced by commit

  4016260ba47a ("rm/msm: fix bug after preclose removal")

merged into v4.6-rc2.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2014-11-11  7:11 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2014-11-11  7:11 UTC (permalink / raw)
  To: Al Viro; +Cc: Linus Torvalds, linux-next, linux-kernel

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

Hi Al,

With Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

fs/isofs/inode.c:177:1: warning: 'isofs_hash_common' defined but not used [-Wunused-function]
 isofs_hash_common(struct qstr *qstr, int ms)
 ^

Since commit b0afd8e5db7b ("isofs: don't bother with ->d_op for normal
case") (which turned up in Linus' tree between v3.18-rc2 and -rc3,
isofs_hash_common() is not used unless CONFIG_JOLIET is set.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2012-10-28 19:44 ` Mauro Carvalho Chehab
@ 2012-11-05 22:36   ` Antti Palosaari
  0 siblings, 0 replies; 85+ messages in thread
From: Antti Palosaari @ 2012-11-05 22:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Stephen Rothwell, linux-next, linux-kernel

On 10/28/2012 09:44 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Oct 2012 13:43:33 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> escreveu:
>
>> Hi Mauro,
>>
>> After merging the origin tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>>
>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usb_ctrl_feed':
>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:291:12: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
>>
>> Which points out some badly formatted and blocked code ...
>>
>> Probably introduced by commit 62a5f449cab5 ("[media] dvb_usb_v2: refactor
>> dvb_usb_ctrl_feed() logic").
>
>
> Hi Stephen,
>
> Thanks for pointing it. It took me some time, but I applied today
> a bunch of patches that are fixing all warnings on everything
> at drivers/media and drivers/staging/media, with:
> 	make ARCH=i386 W=1
> (allyesconfig, gcc 4.7.2)
>
> Maybe there are still a few ones with random configs and other
> archs, but at least on my usual testing environment, we're
> warnings-free on drivers/media for now, probably up to the
> next gcc version.

Sorry for the delay, I was on holiday trip.

hmmm, yes there seems to be something stupid, like missing block braces. 
I will check that during this week and fix properly if Mauro didn't 
already fixed it.

regards
Antti

-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2012-10-24  2:43 Stephen Rothwell
@ 2012-10-28 19:44 ` Mauro Carvalho Chehab
  2012-11-05 22:36   ` Antti Palosaari
  0 siblings, 1 reply; 85+ messages in thread
From: Mauro Carvalho Chehab @ 2012-10-28 19:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Antti Palosaari

Em Wed, 24 Oct 2012 13:43:33 +1100
Stephen Rothwell <sfr@canb.auug.org.au> escreveu:

> Hi Mauro,
> 
> After merging the origin tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usb_ctrl_feed':
> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:291:12: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
> 
> Which points out some badly formatted and blocked code ...
> 
> Probably introduced by commit 62a5f449cab5 ("[media] dvb_usb_v2: refactor
> dvb_usb_ctrl_feed() logic").


Hi Stephen,

Thanks for pointing it. It took me some time, but I applied today
a bunch of patches that are fixing all warnings on everything
at drivers/media and drivers/staging/media, with:
	make ARCH=i386 W=1
(allyesconfig, gcc 4.7.2)

Maybe there are still a few ones with random configs and other
archs, but at least on my usual testing environment, we're
warnings-free on drivers/media for now, probably up to the
next gcc version.

-- 
Regards,
Mauro

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2012-10-24  2:43 Stephen Rothwell
  2012-10-28 19:44 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-10-24  2:43 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-next, linux-kernel, Antti Palosaari

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

Hi Mauro,

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

drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usb_ctrl_feed':
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:291:12: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]

Which points out some badly formatted and blocked code ...

Probably introduced by commit 62a5f449cab5 ("[media] dvb_usb_v2: refactor
dvb_usb_ctrl_feed() logic").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2012-04-24  1:20 Stephen Rothwell
@ 2012-04-24 17:09 ` Ted Ts'o
  0 siblings, 0 replies; 85+ messages in thread
From: Ted Ts'o @ 2012-04-24 17:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Tue, Apr 24, 2012 at 11:20:49AM +1000, Stephen Rothwell wrote:
> 
> Using Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced this warning:
> 
> fs/ext4/super.c: In function 'parse_options':
> fs/ext4/super.c:1600:23: warning: unused variable 'sbi' [-Wunused-variable]
> 
> Introduced by commit 26092bf52478 ("ext4: use a table-driven handler for
> mount options").  This build has CONFIG_QUOTA not set.

This should be fixed in mainline now.

Regards,

					- Ted

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2012-04-24  1:20 Stephen Rothwell
  2012-04-24 17:09 ` Ted Ts'o
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-04-24  1:20 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: linux-next, linux-kernel

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

Hi Ted,

Using Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

fs/ext4/super.c: In function 'parse_options':
fs/ext4/super.c:1600:23: warning: unused variable 'sbi' [-Wunused-variable]

Introduced by commit 26092bf52478 ("ext4: use a table-driven handler for
mount options").  This build has CONFIG_QUOTA not set.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2012-04-17  0:44 Stephen Rothwell
@ 2012-04-17  1:45 ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 85+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-17  1:45 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Tue, Apr 17, 2012 at 10:44:30AM +1000, Stephen Rothwell wrote:
> Hi Konrad,
> 
> Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/block/xen-blkback/xenbus.c: In function 'xen_blkbk_discard':
> drivers/block/xen-blkback/xenbus.c:419:4: warning: passing argument 1 of 'dev_warn' makes pointer from integer without a cast [enabled by default]
> include/linux/device.h:894:5: note: expected 'const struct device *' but argument is of type 'long int'
> 
> Introduced by commit 3389bb8bf761 ("xen/blkback: Make optional features
> be really optional").  Passing "dev-dev" to dev_warn() was hopefully not
> intended ...

No it was not. Not even sure how that mistake passed my compile test.

> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2012-04-17  0:44 Stephen Rothwell
  2012-04-17  1:45 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-04-17  0:44 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: linux-next, linux-kernel

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

Hi Konrad,

Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/block/xen-blkback/xenbus.c: In function 'xen_blkbk_discard':
drivers/block/xen-blkback/xenbus.c:419:4: warning: passing argument 1 of 'dev_warn' makes pointer from integer without a cast [enabled by default]
include/linux/device.h:894:5: note: expected 'const struct device *' but argument is of type 'long int'

Introduced by commit 3389bb8bf761 ("xen/blkback: Make optional features
be really optional").  Passing "dev-dev" to dev_warn() was hopefully not
intended ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2012-01-18 23:36 Stephen Rothwell
@ 2012-01-18 23:47 ` Linus Torvalds
  0 siblings, 0 replies; 85+ messages in thread
From: Linus Torvalds @ 2012-01-18 23:47 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Matthew Wilcox, linux-next, linux-kernel

On Wed, Jan 18, 2012 at 3:36 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/block/nvme.c: In function 'nvme_alloc_ns':
> drivers/block/nvme.c:1336:2: warning: passing argument 2 of 'blk_queue_make_request' from incompatible pointer type [enabled by default]
> include/linux/blkdev.h:830:13: note: expected 'void (*)(struct request_queue *, struct bio *)' but argument is of type 'int (*)(struct request_queue *, struct bio *)'

That's a merge error of mine, resulting from a non-conflicting semantics change.

The type of make_request_fn has changed to void, but the nvme driver
was based on the older version.

It's benign in that in the absence of truly crazy calling conventions
it has no relevance apart from unnecessarily clearing the return value
that now doesn't exist and isn't used, but the warning is clearly
annoying.

I pushed out the obvious fix.

                     Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2012-01-18 23:36 Stephen Rothwell
  2012-01-18 23:47 ` Linus Torvalds
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-01-18 23:36 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: linux-next, linux-kernel, Linus Torvalds

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

Hi all,

Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/block/nvme.c: In function 'nvme_alloc_ns':
drivers/block/nvme.c:1336:2: warning: passing argument 2 of 'blk_queue_make_request' from incompatible pointer type [enabled by default]
include/linux/blkdev.h:830:13: note: expected 'void (*)(struct request_queue *, struct bio *)' but argument is of type 'int (*)(struct request_queue *, struct bio *)'

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2012-01-18 23:09 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-01-18 23:09 UTC (permalink / raw)
  To: Chris Mason
  Cc: linux-next, linux-kernel, Jan Schmidt, Arne Jansen, Linus Torvalds

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

Hi Linus,

Building Linus' tree, today's linux-next build (powerpc_ppc64_defconfig)
produced these warnings:

fs/btrfs/backref.c: In function 'find_parent_nodes':
fs/btrfs/backref.c:482:3: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
fs/btrfs/backref.c:395:6: note: 'ret' was declared here
fs/btrfs/backref.c:381:3: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
fs/btrfs/backref.c:300:6: note: 'ret' was declared here

and indeed, there is a path through to a BUG_ON(ret) that does not set
"ret".  Introduced by commit 8da6d5815c59 ("Btrfs: added
btrfs_find_all_roots()").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2011-05-30  1:43 Stephen Rothwell
@ 2011-05-30  2:01 ` Eric Dumazet
  0 siblings, 0 replies; 85+ messages in thread
From: Eric Dumazet @ 2011-05-30  2:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Patrick McHardy, linux-next, linux-kernel, David S. Miller,
	netfilter-devel, netfilter

Le lundi 30 mai 2011 à 11:43 +1000, Stephen Rothwell a écrit :
> Hi all,
> 
> In Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced this warning:
> 
> net/ipv4/netfilter/nf_nat_standalone.c: In function 'nf_nat_fn':
> net/ipv4/netfilter/nf_nat_standalone.c:119:2: warning: case value '4' not in enumerated type 'enum ip_conntrack_info'
> net/ipv4/netfilter/ipt_CLUSTERIP.c: In function 'clusterip_tg':
> net/ipv4/netfilter/ipt_CLUSTERIP.c:324:3: warning: case value '4' not in enumerated type 'enum ip_conntrack_info'
> 
> I am now using gcc v4.5.2.

I sent a patch for this some days ago, not sure what happened to it.

David Acked it, but Patrick is a bit busy these days.

http://www.spinics.net/lists/netdev/msg164837.html

Thanks

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2011-05-30  1:43 Stephen Rothwell
  2011-05-30  2:01 ` Eric Dumazet
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2011-05-30  1:43 UTC (permalink / raw)
  To: Patrick McHardy
  Cc: linux-next, linux-kernel, David S. Miller, netfilter-devel, netfilter

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

Hi all,

In Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

net/ipv4/netfilter/nf_nat_standalone.c: In function 'nf_nat_fn':
net/ipv4/netfilter/nf_nat_standalone.c:119:2: warning: case value '4' not in enumerated type 'enum ip_conntrack_info'
net/ipv4/netfilter/ipt_CLUSTERIP.c: In function 'clusterip_tg':
net/ipv4/netfilter/ipt_CLUSTERIP.c:324:3: warning: case value '4' not in enumerated type 'enum ip_conntrack_info'

I am now using gcc v4.5.2.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2011-05-25  0:37 Stephen Rothwell
@ 2011-05-26  7:15 ` Greg KH
  0 siblings, 0 replies; 85+ messages in thread
From: Greg KH @ 2011-05-26  7:15 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Antony Pavlov

On Wed, May 25, 2011 at 10:37:40AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> In Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced this warning:
> 
> drivers/tty/serial/8250_pci.c:1457: warning: initialization from incompatible pointer type
> 
> Introduced by commit d9a0fbfd7bc5 ("serial: 8250_pci: add support for
> Cronyx Omega PCI multiserial board").
> 
> Sorry that I didn't notice this earlier.

Thanks, I'll work on this.

greg k-h

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2011-05-26  1:00 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2011-05-26  1:00 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-next, linux-kernel, Linus

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

Hi all,

With Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

mm/slub.c: In function '__slab_alloc':
mm/slub.c:1834: warning: label 'unlock_out' defined but not used

Introduced by commit a71ae47a2cbf ("slub: Fix double bit unlock in debug
mode").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2011-05-25  0:37 Stephen Rothwell
  2011-05-26  7:15 ` Greg KH
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2011-05-25  0:37 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Antony Pavlov

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

Hi Greg,

In Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced this warning:

drivers/tty/serial/8250_pci.c:1457: warning: initialization from incompatible pointer type

Introduced by commit d9a0fbfd7bc5 ("serial: 8250_pci: add support for
Cronyx Omega PCI multiserial board").

Sorry that I didn't notice this earlier.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2011-03-17 23:04 Stephen Rothwell
@ 2011-03-18  1:13 ` David Miller
  0 siblings, 0 replies; 85+ messages in thread
From: David Miller @ 2011-03-18  1:13 UTC (permalink / raw)
  To: sfr
  Cc: roland, linux-next, linux-kernel, hal.rosenstock, eric.dumazet,
	tj, xiaosuo, linux-rdma

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 18 Mar 2011 10:04:18 +1100

> Hi all,
> 
> After merging the Linus' tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> drivers/infiniband/core/addr.c: In function 'addr4_resolve':
> drivers/infiniband/core/addr.c:188: warning: 'ret' may be used uninitialized in this function
> 
> I didn't notice this one before, sorry.
> 
> I don't know what introduced it, but the third if statement in the
> function will make us use "ret" uninitialised.

It was the ipv4 route lookup interface changes.

Roland has received a fix already, and will merge it via the infiniband
tree.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2011-03-17 23:04 Stephen Rothwell
  2011-03-18  1:13 ` David Miller
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2011-03-17 23:04 UTC (permalink / raw)
  To: Roland Dreier
  Cc: linux-next, linux-kernel, David S. Miller, Hal Rosenstock,
	Eric Dumazet, Tejun Heo, Changli Gao, linux-rdma

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

Hi all,

After merging the Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/infiniband/core/addr.c: In function 'addr4_resolve':
drivers/infiniband/core/addr.c:188: warning: 'ret' may be used uninitialized in this function

I didn't notice this one before, sorry.

I don't know what introduced it, but the third if statement in the
function will make us use "ret" uninitialised.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2011-01-13 23:51 Stephen Rothwell
@ 2011-01-14  8:45 ` Lennert Buytenhek
  0 siblings, 0 replies; 85+ messages in thread
From: Lennert Buytenhek @ 2011-01-14  8:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linus, Andrew Morton, linux-next, linux-kernel, Richard Röjfors

On Fri, Jan 14, 2011 at 10:51:23AM +1100, Stephen Rothwell wrote:

> While building Linus' tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> drivers/gpio/timbgpio.c: In function 'timbgpio_irq':
> drivers/gpio/timbgpio.c:202: warning: passing argument 1 of 'irq_get_irq_data' makes integer from pointer without a cast
> include/linux/irq.h:345: note: expected 'unsigned int' but argument is of type 'struct irq_data *'
> drivers/gpio/timbgpio.c:202: warning: passing argument 1 of 'desc-><U be0>.irq_data.chip->ack' makes integer from pointer without a cast
> drivers/gpio/timbgpio.c:202: note: expected 'unsigned int' but argument is of type 'struct irq_data *'
> drivers/gpio/timbgpio.c: In function 'timbgpio_probe':
> drivers/gpio/timbgpio.c:303: warning: passing argument 2 of 'set_irq_chained_handler' from incompatible pointer type
> include/linux/irq.h:294: note: expected 'irq_flow_handler_t' but argument is of type 'void (*)(struct irq_data *, struct irq_desc *)'
> 
> Introduced by commit a1f5f22adc3206c47e70652c12671666c65b579f ("gpio:
> timbgpio: irq_data conversion").

My bad.  Sorry about that.  Have just sent a fixup patch.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2011-01-13 23:51 Stephen Rothwell
  2011-01-14  8:45 ` Lennert Buytenhek
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2011-01-13 23:51 UTC (permalink / raw)
  To: Linus, Andrew Morton; +Cc: linux-next, linux-kernel, Lennert Buytenhek

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

Hi all,

While building Linus' tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/gpio/timbgpio.c: In function 'timbgpio_irq':
drivers/gpio/timbgpio.c:202: warning: passing argument 1 of 'irq_get_irq_data' makes integer from pointer without a cast
include/linux/irq.h:345: note: expected 'unsigned int' but argument is of type 'struct irq_data *'
drivers/gpio/timbgpio.c:202: warning: passing argument 1 of 'desc-><U be0>.irq_data.chip->ack' makes integer from pointer without a cast
drivers/gpio/timbgpio.c:202: note: expected 'unsigned int' but argument is of type 'struct irq_data *'
drivers/gpio/timbgpio.c: In function 'timbgpio_probe':
drivers/gpio/timbgpio.c:303: warning: passing argument 2 of 'set_irq_chained_handler' from incompatible pointer type
include/linux/irq.h:294: note: expected 'irq_flow_handler_t' but argument is of type 'void (*)(struct irq_data *, struct irq_desc *)'

Introduced by commit a1f5f22adc3206c47e70652c12671666c65b579f ("gpio:
timbgpio: irq_data conversion").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'  tree
  2010-10-25  0:57 Stephen Rothwell
@ 2010-10-25  6:36 ` Ingo Molnar
  0 siblings, 0 replies; 85+ messages in thread
From: Ingo Molnar @ 2010-10-25  6:36 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linus, linux-next, linux-kernel, Robert Richter


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> In building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> arch/x86/oprofile/op_model_amd.c: In function 'ibs_eilvt_valid':
> arch/x86/oprofile/op_model_amd.c:289: warning: 'offset' may be used uninitialized in this function
> 
> .. and indeed it may be.

Yep, that looks bogus. I've queued up the fix.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-10-25  2:52 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-10-25  2:52 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Jan Beulich, H. Peter Anvin

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

Hi Linus,

In building Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

In file included from arch/powerpc/platforms/iseries/exception.S:32:
arch/powerpc/include/asm/ptrace.h:60:1: warning: "STACK_FRAME_OVERHEAD" redefined
In file included from arch/powerpc/include/asm/asm-offsets.h:1,
                 from arch/powerpc/platforms/iseries/exception.S:30:
include/generated/asm-offsets.h:87:1: warning: this is the location of the previous definition

Caused by commit 3234282f33b29d349bcada40204fc7c8fda7fe72 ("x86, asm: Fix
CFI macro invocations to deal with shortcomings in gas").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-10-25  0:45 ` Stephen Rothwell
@ 2010-10-25  2:39   ` Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-10-25  2:39 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Mike Miller, Jens Axboe

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

On Mon, 25 Oct 2010 11:45:20 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 25 Oct 2010 11:38:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the hid tree, today's linux-next build (x86_64 allmodconfig)
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^
> Ignore this :-)

It been pointed out that I may have not bee clear enough.  My statement
above was meant to mean:

"Ignore the bit about merging the hid tree, but the report is otherwise
valid"
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus'  tree
@ 2010-10-25  0:57 Stephen Rothwell
  2010-10-25  6:36 ` Ingo Molnar
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-10-25  0:57 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Robert Richter, Ingo Molnar

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

Hi all,

In building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

arch/x86/oprofile/op_model_amd.c: In function 'ibs_eilvt_valid':
arch/x86/oprofile/op_model_amd.c:289: warning: 'offset' may be used uninitialized in this function

.. and indeed it may be.

Introduced by commit 27afdf2008da0b8878a73e32e4eb12381b84e224 ("apic,
x86: Use BIOS settings for IBS and MCE threshold interrupt LVT
offsets").  Sorry I missed this earlier.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-10-25  0:38 Stephen Rothwell
@ 2010-10-25  0:45 ` Stephen Rothwell
  2010-10-25  2:39   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-10-25  0:45 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Mike Miller, Jens Axboe

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

On Mon, 25 Oct 2010 11:38:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the hid tree, today's linux-next build (x86_64 allmodconfig)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^
Ignore this :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-10-25  0:38 Stephen Rothwell
  2010-10-25  0:45 ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-10-25  0:38 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Mike Miller, Jens Axboe

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

Hi Linus,

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

drivers/scsi/hpsa.c:94:1: warning: "PCI_DEVICE_ID_HP_CISSF" redefined
In file included from include/linux/pci.h:58,
                 from drivers/scsi/hpsa.c:25:
include/linux/pci_ids.h:746:1: warning: this is the location of the previous definition

Introduced by commit 6362beea8914cbd4630ccde3617d944aeca2d48f ("cciss:
fix PCI IDs for new Smart Array controllers") a commit that never made it
to linus-next :-(.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-08-16  4:00 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-08-16  4:00 UTC (permalink / raw)
  To: Chen Gong, Andrew Morton; +Cc: linux-next, linux-kernel

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

Hi all,

After merging the slab tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

/scratch/sfr/next/drivers/hwmon/coretemp.c: In function 'coretemp_init':
/scratch/sfr/next/drivers/hwmon/coretemp.c:521: warning: unused variable 'n'
/scratch/sfr/next/drivers/hwmon/coretemp.c:521: warning: unused variable 'p'

Introduced by commit 851b29cb3b196cb66452ec964ab5f66c9c9cd1ed ("hwmon:
coretemp: enable coretemp device add operation failure").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-05-28  0:56 Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-28  0:56 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: linux-next, linux-kernel, Dmitry Torokhov

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

Hi Kevin,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

drivers/input/touchscreen/ads7846.c: In function 'ads7846_probe':
drivers/input/touchscreen/ads7846.c:1167: warning: format '%ld' expects type 'long int', but argument 4 has type 'int'

Introduced by commit 067fb2f648543894ce775082c5636f4c32b99e4f ("Input:
ads7846 - return error on regulator_get() failure").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26 17:31                   ` Joakim Tjernlund
@ 2010-05-26 17:45                     ` Linus Torvalds
  0 siblings, 0 replies; 85+ messages in thread
From: Linus Torvalds @ 2010-05-26 17:45 UTC (permalink / raw)
  To: Joakim Tjernlund
  Cc: Andrew Morton, linux-kernel, linux-next, Stephen Rothwell



On Wed, 26 May 2010, Joakim Tjernlund wrote:
> >
> > So no. The glibc model is _not_ any better in practice.
> 
> In the kernel it is since it breaks the compile. The breakage
> my patch introduced is a sign of that, right?

In the kernel it is _worse_, because it breaks all the years and years of 
code we have. 

The thing is, "reality" > "theory".

Besides, the kernel model is a lot denser, more straightforward, and in my 
opinion much less likely to cause problems due to having just two clear 
identifiers rather than that extraneous and useless __BYTE_ORDER one.

So even in theory, I don't agree. It's not like we've really had problems 
with our model.

> hmm, so then I guess the existing use of __BYTE_ORDER in the
> kernel should be removed?

Yes. Except in the places where it exists solely due to user-space header 
exporting (and there it generally is a big hint that something is wrong 
anyway, as mentioned). From my quick grep (read: "not verified") there's a 
couple of files like that.

It's probably not worth trying to change (one of them is about 
__BIG_ENDIAN_BITFIELD, which is due to people using bitfields for 
transferring data. That _is_ misdesigned. Bitfield ordering is even less 
well defined than byte order, and if you have to use those bitfield 
ordering things, it's almost always a sign that you shouldn't have used 
bitfields, and used explicit shifts-and-masks instead)

		Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26 16:46                 ` Linus Torvalds
@ 2010-05-26 17:31                   ` Joakim Tjernlund
  2010-05-26 17:45                     ` Linus Torvalds
  0 siblings, 1 reply; 85+ messages in thread
From: Joakim Tjernlund @ 2010-05-26 17:31 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-next, Stephen Rothwell

Linus Torvalds <torvalds@linux-foundation.org> wrote on 2010/05/26 18:46:11:
>
> On Wed, 26 May 2010, Joakim Tjernlund wrote:
> >
> > 1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are
> >    defined depending on the endianess of the target CPU.
> >    The glibc model generates a compile error if you forget to include __BYTE_ORDER.
>
> Umm. Except when it doesn't (yes, Linux has the "Wundefined" thing, and
> has had for a long time). I've seen the glibc model do the wrong thing
> exactly because traditional C semantics is "undefined symbol is 0 in
> evaluations"
>
> Try compiling this
>
>    #include <stdio.h>
>
>    #if NOT_HERE == NOT_THERE
>    int main()
>    {
>       printf("Hello world!\n");
>    }
>    #endif
>
> and even with -Wall it compiles perfectly happily.

Ouch! But here -Wundef really helps.

>
> So no. The glibc model is _not_ any better in practice.

In the kernel it is since it breaks the compile. The breakage
my patch introduced is a sign of that, right?

>
> > 2) It clashes with user space so one cannot use it in exported header files.
>
> Which is annoying, I agree. But you shouldn't generally use kernel headers
> for user space anyway, much less export anything that is byteorder-

Not in general, but my case could have been avoided, I sure there are others
too. Why else does some header files bother with __BYTE_ORDER?

> specific. So anybody who has this problem is likely doing something iffy
> to begin with.

hmm, so then I guess the existing use of __BYTE_ORDER in the
kernel should be removed?

>
> Besides, you can solve it cleanly by simply avoiding the crazy glibc
> semantics entirely. IOW, the CONFIG_BIG_ENDIAN option I suggested (and

CONFIG_BIG_ENDIAN would have helped me with my lib/crc32.c problem
but it does not prevent silent breakage so I figured the glibc model
would be better.
Is it such a big difference, readability wise, between
  #ifdef CONFIG_BIG_ENDIAN
and
  #if __BYTE_ORDER == __BIG_ENDIAN
that you rather risk silent breakage?

> again, you should damn well not export things that depend on it to user
> space - there are architectures where user-space might be switchable)

Such arch exists but does any of them run linux in both modes?

  Jocke

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26 16:35               ` Joakim Tjernlund
@ 2010-05-26 16:46                 ` Linus Torvalds
  2010-05-26 17:31                   ` Joakim Tjernlund
  0 siblings, 1 reply; 85+ messages in thread
From: Linus Torvalds @ 2010-05-26 16:46 UTC (permalink / raw)
  To: Joakim Tjernlund
  Cc: Andrew Morton, linux-kernel, linux-next, Stephen Rothwell



On Wed, 26 May 2010, Joakim Tjernlund wrote:
> 
> 1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are
>    defined depending on the endianess of the target CPU.
>    The glibc model generates a compile error if you forget to include __BYTE_ORDER.

Umm. Except when it doesn't (yes, Linux has the "Wundefined" thing, and 
has had for a long time). I've seen the glibc model do the wrong thing 
exactly because traditional C semantics is "undefined symbol is 0 in 
evaluations"

Try compiling this

	#include <stdio.h>

	#if NOT_HERE == NOT_THERE
	int main()
	{
		printf("Hello world!\n");
	}
	#endif

and even with -Wall it compiles perfectly happily.

So no. The glibc model is _not_ any better in practice.

> 2) It clashes with user space so one cannot use it in exported header files.

Which is annoying, I agree. But you shouldn't generally use kernel headers 
for user space anyway, much less export anything that is byteorder- 
specific. So anybody who has this problem is likely doing something iffy 
to begin with.

Besides, you can solve it cleanly by simply avoiding the crazy glibc 
semantics entirely. IOW, the CONFIG_BIG_ENDIAN option I suggested (and 
again, you should damn well not export things that depend on it to user 
space - there are architectures where user-space might be switchable)

			Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26 15:29             ` Linus Torvalds
@ 2010-05-26 16:35               ` Joakim Tjernlund
  2010-05-26 16:46                 ` Linus Torvalds
  0 siblings, 1 reply; 85+ messages in thread
From: Joakim Tjernlund @ 2010-05-26 16:35 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-next, Stephen Rothwell

Linus Torvalds <torvalds@linux-foundation.org> wrote on 2010/05/26 17:29:02:
>
> On Wed, 26 May 2010, Joakim Tjernlund wrote:
> >
> > If my suggestion above works, then one could start transforming current uses
> of __BYTE_ORDER,
> > into similar constructs and once all are done, #define both __LITTLE_ENDIAN/
> __BIG_ENDIAN and
> > move back to #if __BYTE_ORDER == __LITTLE_ENDIAN
>
> No. Don't do it. Why the hell would we want to use the inferior model?

I agree that the glibc model(dunno if this is glibc/gcc specific or some standard)
is less than optimal but the linux model has two major flaws too:

1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are
   defined depending on the endianess of the target CPU.
   The glibc model generates a compile error if you forget to include __BYTE_ORDER.

2) It clashes with user space so one cannot use it in exported header files.

If you grep for __BYTE_ORDER in the kernel you will find some ugly #ifdefs
to overcome 2). It would have been somewhat better if linux had defined its own
names instead of reusing the glibc/gcc names with different semantics.

1) is worse and the reason for this patch. I moved lib/crc32.c
to user space so I could run the builtin unit test program because
I wanted to do some optimizations. It just silently broke depending
on the endianess of the CPU. Took half a day to figure out why :(
This could easily happen in the kernel too.

 Jocke

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  7:14         ` Stephen Rothwell
  2010-05-26 10:21           ` Joakim Tjernlund
@ 2010-05-26 15:33           ` Linus Torvalds
  1 sibling, 0 replies; 85+ messages in thread
From: Linus Torvalds @ 2010-05-26 15:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Joakim Tjernlund, linux-kernel, linux-next



On Wed, 26 May 2010, Stephen Rothwell wrote:
> 
> We also need to revert b3b77c8caef1750ebeea1054e39e358550ea9f55 ("endian:
> #define __BYTE_ORDER") in order to get rid of the other warning I pointed out:

Done.

		Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26 10:21           ` Joakim Tjernlund
@ 2010-05-26 15:29             ` Linus Torvalds
  2010-05-26 16:35               ` Joakim Tjernlund
  0 siblings, 1 reply; 85+ messages in thread
From: Linus Torvalds @ 2010-05-26 15:29 UTC (permalink / raw)
  To: Joakim Tjernlund
  Cc: Stephen Rothwell, Andrew Morton, linux-kernel, linux-next



On Wed, 26 May 2010, Joakim Tjernlund wrote:
> 
> If my suggestion above works, then one could start transforming current uses of __BYTE_ORDER,
> into similar constructs and once all are done, #define both __LITTLE_ENDIAN/__BIG_ENDIAN and
> move back to #if __BYTE_ORDER == __LITTLE_ENDIAN

No. Don't do it. Why the hell would we want to use the inferior model?

		Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  6:41       ` Andrew Morton
  2010-05-26  7:14         ` Stephen Rothwell
@ 2010-05-26 15:26         ` Linus Torvalds
  1 sibling, 0 replies; 85+ messages in thread
From: Linus Torvalds @ 2010-05-26 15:26 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Joakim Tjernlund, Stephen Rothwell, linux-kernel, linux-next



On Tue, 25 May 2010, Andrew Morton wrote:
> 
> > I suspect fixing this entails moving all endian tests to #if __BYTE_ORDER ...
> > and then always define both __LITTLE_ENDIAN and __BIG_ENDIAN
> 
> Yes we can't define __LITTLE_ENDIAN to anything on big-endian without
> breaking lots of other things.

Indeed. The whole glibc thing of doing

	# if __BYTE_ORDER == __BIG_ENDIAN

(see "grep ENDIAN /usr/include/*") is a f*cking idiotic. It is way less 
readable, and insane to do. I guess it's some traditional unix disease.

The way to do it in Linux is to just do

	#ifdef __{BIG,LITTLE}_ENDIAN

which is a lot more readable. 

If anybody wants to change that, they still shouldn't change it to the 
idiotic glibc model. If you want it to be more readable, maybe somebody 
can introduce a CONFIG_{BIG,LITTLE}_ENDIAN{_BITFIELDS}

			Linus

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  7:14         ` Stephen Rothwell
@ 2010-05-26 10:21           ` Joakim Tjernlund
  2010-05-26 15:29             ` Linus Torvalds
  2010-05-26 15:33           ` Linus Torvalds
  1 sibling, 1 reply; 85+ messages in thread
From: Joakim Tjernlund @ 2010-05-26 10:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-kernel, linux-next, Linus

Stephen Rothwell <sfr@canb.auug.org.au> wrote on 2010/05/26 09:14:24:
>
> Hi Andrew, Joakim,
>
> On Tue, 25 May 2010 23:41:16 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Wed, 26 May 2010 08:29:45 +0200 Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> > > Stephen Rothwell <sfr@canb.auug.org.au> wrote on 2010/05/26 06:09:00:
> > > >
> > > > On Tue, 25 May 2010 18:20:40 -0700 Andrew Morton <akpm@linux-
> foundation.org> wrote:
> > > > >
> > > > > hmpf.  Does this fix?
> > > >
> > > > No.
> > > >
> > > > The problem is that __LITTLE_ENDIAN is only defined in
> > > > linux/byteorder/little_endian.h which is only included by little endian
> > > > architectures ...
> > >
> > > Ah, not sure how to fix this ATM. Perhaps best to revert
> > >    crc32: use __BYTE_ORDER macro for endian detection
> > > for now.
> >
> > yup.
>
> We also need to revert b3b77c8caef1750ebeea1054e39e358550ea9f55 ("endian:
> #define __BYTE_ORDER") in order to get rid of the other warning I pointed out:
>
> In file included from fs/jfs/jfs_types.h:33,
>                  from fs/jfs/jfs_incore.h:26,
>                  from fs/jfs/file.c:22:
> fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined
>
> I get this warning on powerpc builds for most of the files in fs/jfs ...

endian24.h has:
#if (defined(__KERNEL__) && defined(__LITTLE_ENDIAN)) || (defined(__BYTE_ORDER) && (__BYTE_ORDER == __LITTLE_ENDIAN))
That won't work for BE CPU's. Perhaps something like this will?
#if defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN) && (__BYTE_ORDER == __LITTLE_ENDIAN) || defined(__LITTLE_ENDIAN)

The kernel borrows __LITTLE_ENDIAN/__BIG_ENDIAN from user space but does not impl. the
full semantics that user space has. Adding full user space semantics isn't easy as it clashes with
current use of __LITTLE_ENDIAN/__BIG_ENDIAN.

If my suggestion above works, then one could start transforming current uses of __BYTE_ORDER,
into similar constructs and once all are done, #define both __LITTLE_ENDIAN/__BIG_ENDIAN and
move back to #if __BYTE_ORDER == __LITTLE_ENDIAN

 Jocke

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  6:41       ` Andrew Morton
@ 2010-05-26  7:14         ` Stephen Rothwell
  2010-05-26 10:21           ` Joakim Tjernlund
  2010-05-26 15:33           ` Linus Torvalds
  2010-05-26 15:26         ` Linus Torvalds
  1 sibling, 2 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-26  7:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Joakim Tjernlund, linux-kernel, linux-next, Linus

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

Hi Andrew, Joakim,

On Tue, 25 May 2010 23:41:16 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 26 May 2010 08:29:45 +0200 Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> 
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote on 2010/05/26 06:09:00:
> > >
> > > On Tue, 25 May 2010 18:20:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > hmpf.  Does this fix?
> > >
> > > No.
> > >
> > > The problem is that __LITTLE_ENDIAN is only defined in
> > > linux/byteorder/little_endian.h which is only included by little endian
> > > architectures ...
> > 
> > Ah, not sure how to fix this ATM. Perhaps best to revert
> >    crc32: use __BYTE_ORDER macro for endian detection
> > for now.
> 
> yup.

We also need to revert b3b77c8caef1750ebeea1054e39e358550ea9f55 ("endian:
#define __BYTE_ORDER") in order to get rid of the other warning I pointed out:

In file included from fs/jfs/jfs_types.h:33,
                 from fs/jfs/jfs_incore.h:26,
                 from fs/jfs/file.c:22:
fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined

I get this warning on powerpc builds for most of the files in fs/jfs ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  6:29     ` Joakim Tjernlund
@ 2010-05-26  6:41       ` Andrew Morton
  2010-05-26  7:14         ` Stephen Rothwell
  2010-05-26 15:26         ` Linus Torvalds
  0 siblings, 2 replies; 85+ messages in thread
From: Andrew Morton @ 2010-05-26  6:41 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Rothwell, linux-kernel, linux-next, Linus

On Wed, 26 May 2010 08:29:45 +0200 Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> Stephen Rothwell <sfr@canb.auug.org.au> wrote on 2010/05/26 06:09:00:
> >
> > Hi Andrew,
> >
> > On Tue, 25 May 2010 18:20:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > hmpf.  Does this fix?
> >
> > No.
> >
> > The problem is that __LITTLE_ENDIAN is only defined in
> > linux/byteorder/little_endian.h which is only included by little endian
> > architectures ...
> 
> Ah, not sure how to fix this ATM. Perhaps best to revert
>    crc32: use __BYTE_ORDER macro for endian detection
> for now.

yup.

> I suspect fixing this entails moving all endian tests to #if __BYTE_ORDER ...
> and then always define both __LITTLE_ENDIAN and __BIG_ENDIAN

Yes we can't define __LITTLE_ENDIAN to anything on big-endian without
breaking lots of other things.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  4:09   ` Stephen Rothwell
@ 2010-05-26  6:29     ` Joakim Tjernlund
  2010-05-26  6:41       ` Andrew Morton
  0 siblings, 1 reply; 85+ messages in thread
From: Joakim Tjernlund @ 2010-05-26  6:29 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-kernel, linux-next, Linus

Stephen Rothwell <sfr@canb.auug.org.au> wrote on 2010/05/26 06:09:00:
>
> Hi Andrew,
>
> On Tue, 25 May 2010 18:20:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > hmpf.  Does this fix?
>
> No.
>
> The problem is that __LITTLE_ENDIAN is only defined in
> linux/byteorder/little_endian.h which is only included by little endian
> architectures ...

Ah, not sure how to fix this ATM. Perhaps best to revert
   crc32: use __BYTE_ORDER macro for endian detection
for now.

I suspect fixing this entails moving all endian tests to #if __BYTE_ORDER ...
and then always define both __LITTLE_ENDIAN and __BIG_ENDIAN

 Jocke

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  1:20 ` Andrew Morton
@ 2010-05-26  4:09   ` Stephen Rothwell
  2010-05-26  6:29     ` Joakim Tjernlund
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-26  4:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linus, linux-next, linux-kernel, Joakim Tjernlund

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

Hi Andrew,

On Tue, 25 May 2010 18:20:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> hmpf.  Does this fix?

No.

The problem is that __LITTLE_ENDIAN is only defined in
linux/byteorder/little_endian.h which is only included by little endian
architectures ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-25 23:24     ` David Miller
@ 2010-05-26  2:04       ` Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-26  2:04 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, linux-next, linux-kernel, NeilJay

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

Hi Dave,

On Tue, 25 May 2010 16:24:46 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: David Miller <davem@davemloft.net>
> Date: Tue, 25 May 2010 16:19:29 -0700 (PDT)
> 
> > Here is how I fixed this:
> > 
> > --------------------
> > drivers/net/usb/asix.c: Fix pointer cast.
> 
> Sorry, that only took care of one of the two warnings :-)
> 
> This patch is better.

Thanks, looks good.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-26  1:51 ` Herbert Xu
@ 2010-05-26  1:54   ` David Miller
  0 siblings, 0 replies; 85+ messages in thread
From: David Miller @ 2010-05-26  1:54 UTC (permalink / raw)
  To: herbert; +Cc: sfr, netdev, linux-next, linux-kernel, torvalds

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 26 May 2010 11:51:10 +1000

> cls_cgroup: Initialise classid when module is absent
> 
> When the cls_cgroup module is not loaded, task_cls_classid will
> return an uninitialised classid instead of zero.
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks Herbert.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-26  1:43 Stephen Rothwell
@ 2010-05-26  1:51 ` Herbert Xu
  2010-05-26  1:54   ` David Miller
  0 siblings, 1 reply; 85+ messages in thread
From: Herbert Xu @ 2010-05-26  1:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel, Linus

On Wed, May 26, 2010 at 11:43:06AM +1000, Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (x86_64 allmodconfig) produced this warning:
> 
> net/core/sock.c: In function 'sock_update_classid':
> include/net/cls_cgroup.h:42: warning: 'classid' may be used uninitialized in this function
> include/net/cls_cgroup.h:42: note: 'classid' was declared here
> 
> In the case that rcu_dereference() returns a value < 0, classid will not
> be assigned in task_cls_classid().  I don't know if this is possible - if
> not, then why is the test there?

This is a genuine bug.  I don't know why my gcc didn't warn about
it.

cls_cgroup: Initialise classid when module is absent

When the cls_cgroup module is not loaded, task_cls_classid will
return an uninitialised classid instead of zero.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/include/net/cls_cgroup.h b/include/net/cls_cgroup.h
index 6cf4486..726cc35 100644
--- a/include/net/cls_cgroup.h
+++ b/include/net/cls_cgroup.h
@@ -39,7 +39,7 @@ extern int net_cls_subsys_id;
 static inline u32 task_cls_classid(struct task_struct *p)
 {
 	int id;
-	u32 classid;
+	u32 classid = 0;
 
 	if (in_interrupt())
 		return 0;

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-05-26  1:43 Stephen Rothwell
  2010-05-26  1:51 ` Herbert Xu
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-26  1:43 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Linus, Herbert Xu

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

Hi Dave,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

net/core/sock.c: In function 'sock_update_classid':
include/net/cls_cgroup.h:42: warning: 'classid' may be used uninitialized in this function
include/net/cls_cgroup.h:42: note: 'classid' was declared here

In the case that rcu_dereference() returns a value < 0, classid will not
be assigned in task_cls_classid().  I don't know if this is possible - if
not, then why is the test there?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus'tree
  2010-05-26  1:05 linux-next: build warning in Linus'tree Stephen Rothwell
@ 2010-05-26  1:20 ` Andrew Morton
  2010-05-26  4:09   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Andrew Morton @ 2010-05-26  1:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linus, linux-next, linux-kernel, Joakim Tjernlund

On Wed, 26 May 2010 11:05:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus,
> 
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
> 
> lib/crc32.c:53:22: warning: "__LITTLE_ENDIAN" is not defined
> lib/crc32.c:53:22: warning: "__LITTLE_ENDIAN" is not defined
> In file included from fs/jfs/jfs_types.h:33,
>                  from fs/jfs/jfs_incore.h:26,
>                  from fs/jfs/file.c:22:
> fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined
> 
> and more of the same ...
> 
> Introduced by commit 4762bbc1a3a1f22095278b74dd1b8cee04858641 ("crc32:
> use __BYTE_ORDER macro for endian detection") and (probably) commit b3b77c8caef1750ebeea1054e39e358550ea9f55 ("endian: #define __BYTE_ORDER").
> 

hmpf.  Does this fix?

--- a/lib/crc32.c~a
+++ a/lib/crc32.c
@@ -26,6 +26,7 @@
 #include <linux/compiler.h>
 #include <linux/types.h>
 #include <linux/init.h>
+#include <asm/byteorder.h>
 #include <asm/atomic.h>
 #include "crc32defs.h"
 #if CRC_LE_BITS == 8
_

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus'tree
@ 2010-05-26  1:05 Stephen Rothwell
  2010-05-26  1:20 ` Andrew Morton
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-26  1:05 UTC (permalink / raw)
  To: Linus; +Cc: linux-next, linux-kernel, Andrew Morton, Joakim Tjernlund

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

Hi Linus,

Today's linux-next build (powerpc ppc64_defconfig) produced this warning:

lib/crc32.c:53:22: warning: "__LITTLE_ENDIAN" is not defined
lib/crc32.c:53:22: warning: "__LITTLE_ENDIAN" is not defined
In file included from fs/jfs/jfs_types.h:33,
                 from fs/jfs/jfs_incore.h:26,
                 from fs/jfs/file.c:22:
fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined

and more of the same ...

Introduced by commit 4762bbc1a3a1f22095278b74dd1b8cee04858641 ("crc32:
use __BYTE_ORDER macro for endian detection") and (probably) commit b3b77c8caef1750ebeea1054e39e358550ea9f55 ("endian: #define __BYTE_ORDER").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-25 23:19   ` David Miller
@ 2010-05-25 23:24     ` David Miller
  2010-05-26  2:04       ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: David Miller @ 2010-05-25 23:24 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, NeilJay

From: David Miller <davem@davemloft.net>
Date: Tue, 25 May 2010 16:19:29 -0700 (PDT)

> Here is how I fixed this:
> 
> --------------------
> drivers/net/usb/asix.c: Fix pointer cast.

Sorry, that only took care of one of the two warnings :-)

This patch is better.

--------------------
drivers/net/usb/asix.c: Fix pointer cast.

Stephen Rothwell reports the following new warning:

drivers/net/usb/asix.c: In function 'asix_rx_fixup':
drivers/net/usb/asix.c:325: warning: cast from pointer to integer of different size
drivers/net/usb/asix.c:354: warning: cast from pointer to integer of different size

The code just cares about the low alignment bits, so use
an "unsigned long" cast instead of one to "u32".

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/usb/asix.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 31b7331..1f802e9 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -322,7 +322,7 @@ static int asix_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 		size = (u16) (header & 0x0000ffff);
 
 		if ((skb->len) - ((size + 1) & 0xfffe) == 0) {
-			u8 alignment = (u32)skb->data & 0x3;
+			u8 alignment = (unsigned long)skb->data & 0x3;
 			if (alignment != 0x2) {
 				/*
 				 * not 16bit aligned so use the room provided by
@@ -351,7 +351,7 @@ static int asix_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 		}
 		ax_skb = skb_clone(skb, GFP_ATOMIC);
 		if (ax_skb) {
-			u8 alignment = (u32)packet & 0x3;
+			u8 alignment = (unsigned long)packet & 0x3;
 			ax_skb->len = size;
 
 			if (alignment != 0x2) {
-- 
1.7.0.4

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-25  4:58 ` David Miller
@ 2010-05-25 23:19   ` David Miller
  2010-05-25 23:24     ` David Miller
  0 siblings, 1 reply; 85+ messages in thread
From: David Miller @ 2010-05-25 23:19 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, NeilJay

From: David Miller <davem@davemloft.net>
Date: Mon, 24 May 2010 21:58:22 -0700 (PDT)

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 May 2010 11:46:14 +1000
> 
>> Hi Dave,
>> 
>> Today's linux-next build (x86_64 allmodconfig) produced this warning:
>> 
>> drivers/net/usb/asix.c: In function 'asix_rx_fixup':
>> drivers/net/usb/asix.c:325: warning: cast from pointer to integer of different size
>> drivers/net/usb/asix.c:354: warning: cast from pointer to integer of different size
>> 
>> Introduced by commit 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> ("drivers/net/usb/asix.c: Fix unaligned accesses").  This commit casts
>> skb->data to u32.
> 
> Thanks I'll look into this.

Here is how I fixed this:

--------------------
drivers/net/usb/asix.c: Fix pointer cast.

Stephen Rothwell reports the following new warning:

drivers/net/usb/asix.c: In function 'asix_rx_fixup':
drivers/net/usb/asix.c:325: warning: cast from pointer to integer of different size
drivers/net/usb/asix.c:354: warning: cast from pointer to integer of different size

The code just cares about the low alignment bits, so use
an "unsigned long" cast instead of one to "u32".

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/usb/asix.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 31b7331..ea75f47 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -322,7 +322,7 @@ static int asix_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 		size = (u16) (header & 0x0000ffff);
 
 		if ((skb->len) - ((size + 1) & 0xfffe) == 0) {
-			u8 alignment = (u32)skb->data & 0x3;
+			u8 alignment = (unsigned long)skb->data & 0x3;
 			if (alignment != 0x2) {
 				/*
 				 * not 16bit aligned so use the room provided by
-- 
1.7.0.4

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-05-25  1:46 linux-next: build warning in Linus' tree Stephen Rothwell
@ 2010-05-25  4:58 ` David Miller
  2010-05-25 23:19   ` David Miller
  0 siblings, 1 reply; 85+ messages in thread
From: David Miller @ 2010-05-25  4:58 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, NeilJay

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 May 2010 11:46:14 +1000

> Hi Dave,
> 
> Today's linux-next build (x86_64 allmodconfig) produced this warning:
> 
> drivers/net/usb/asix.c: In function 'asix_rx_fixup':
> drivers/net/usb/asix.c:325: warning: cast from pointer to integer of different size
> drivers/net/usb/asix.c:354: warning: cast from pointer to integer of different size
> 
> Introduced by commit 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> ("drivers/net/usb/asix.c: Fix unaligned accesses").  This commit casts
> skb->data to u32.

Thanks I'll look into this.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus'  tree
@ 2010-05-25  1:46 Stephen Rothwell
  2010-05-25  4:58 ` David Miller
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-05-25  1:46 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Neil Jones

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

Hi Dave,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

drivers/net/usb/asix.c: In function 'asix_rx_fixup':
drivers/net/usb/asix.c:325: warning: cast from pointer to integer of different size
drivers/net/usb/asix.c:354: warning: cast from pointer to integer of different size

Introduced by commit 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
("drivers/net/usb/asix.c: Fix unaligned accesses").  This commit casts
skb->data to u32.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-04-26 23:42 ` Greg KH
@ 2010-04-27  3:09   ` Stephen Rothwell
  0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2010-04-27  3:09 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Alex Manoussakis

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

Hi Greg,

On Mon, 26 Apr 2010 16:42:50 -0700 Greg KH <greg@kroah.com> wrote:
>
> Thanks, Randy has already sent me a fix for this, I'm working on apply
> it to my tree soon (doing must-fix things first...)

Of course, I just note these sort of warnings in case they get missed.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: linux-next: build warning in Linus' tree
  2010-04-26 23:30 Stephen Rothwell
@ 2010-04-26 23:42 ` Greg KH
  2010-04-27  3:09   ` Stephen Rothwell
  0 siblings, 1 reply; 85+ messages in thread
From: Greg KH @ 2010-04-26 23:42 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alex Manoussakis

On Tue, Apr 27, 2010 at 09:30:19AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (x86_64 allmodconfig) produced this warning:
> 
> drivers/usb/serial/ti_usb_3410_5052.c: In function 'ti_download_firmware':
> drivers/usb/serial/ti_usb_3410_5052.c:1738: warning: format '%d' expects type 'int', but argument 5 has type 'size_t'
> 
> Introduced by commit cdc04834ce70343aa6f87c5332ec66c35d968967 ("USB:
> ti_usb_3410_5052: adding multitech dialup fax/modem devices").

Thanks, Randy has already sent me a fix for this, I'm working on apply
it to my tree soon (doing must-fix things first...)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 85+ messages in thread

* linux-next: build warning in Linus' tree
@ 2010-04-26 23:30 Stephen Rothwell
  2010-04-26 23:42 ` Greg KH
  0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2010-04-26 23:30 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Alex Manoussakis

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

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

drivers/usb/serial/ti_usb_3410_5052.c: In function 'ti_download_firmware':
drivers/usb/serial/ti_usb_3410_5052.c:1738: warning: format '%d' expects type 'int', but argument 5 has type 'size_t'

Introduced by commit cdc04834ce70343aa6f87c5332ec66c35d968967 ("USB:
ti_usb_3410_5052: adding multitech dialup fax/modem devices").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

end of thread, other threads:[~2021-10-21  1:33 UTC | newest]

Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-17 22:52 linux-next: build warning in Linus' tree Stephen Rothwell
2013-12-18  2:54 ` Skidmore, Donald C
  -- strict thread matches above, loose matches on Subject: below --
2021-10-05  9:42 Stephen Rothwell
2021-10-05  9:29 Stephen Rothwell
2021-10-21  1:28 ` Stephen Rothwell
     [not found] ` <ANQAFAC9EhHeWK1g5-2FP4ol.9.1634779695838.Hmail.changfengnan@vivo.com>
2021-10-21  1:32   ` 常凤楠
2021-08-30  8:33 Stephen Rothwell
2021-03-23  5:51 Stephen Rothwell
2021-03-23  8:49 ` Peter Zijlstra
2021-02-18 20:58 Stephen Rothwell
2021-02-18 22:47 ` Ernst, Justin
2021-02-23 21:50   ` Stephen Rothwell
2021-02-23 22:01     ` Ernst, Justin
2021-01-03 22:07 Stephen Rothwell
2020-10-28  3:28 Stephen Rothwell
2020-10-28 15:56 ` Micah Morton
2020-10-28 21:07   ` Stephen Rothwell
2020-02-21  3:39 Stephen Rothwell
2020-02-21  6:51 ` Gustavo A. R. Silva
2017-11-02 20:29 Stephen Rothwell
2017-11-02 21:08 ` Ingo Molnar
2017-11-02 21:21   ` Stephen Rothwell
2016-11-13 22:25 Stephen Rothwell
2016-10-27 22:29 Stephen Rothwell
2016-10-27 22:48 ` Linus Torvalds
2016-10-27 23:01   ` Linus Torvalds
2016-10-27 23:05     ` Alexander Potapenko
2016-10-27 23:25       ` Linus Torvalds
2016-10-27 23:40     ` Stephen Rothwell
2016-10-29 21:29     ` Geert Uytterhoeven
2016-10-30 19:05       ` Andrey Ryabinin
2016-04-12 23:59 Stephen Rothwell
2014-11-11  7:11 Stephen Rothwell
2012-10-24  2:43 Stephen Rothwell
2012-10-28 19:44 ` Mauro Carvalho Chehab
2012-11-05 22:36   ` Antti Palosaari
2012-04-24  1:20 Stephen Rothwell
2012-04-24 17:09 ` Ted Ts'o
2012-04-17  0:44 Stephen Rothwell
2012-04-17  1:45 ` Konrad Rzeszutek Wilk
2012-01-18 23:36 Stephen Rothwell
2012-01-18 23:47 ` Linus Torvalds
2012-01-18 23:09 Stephen Rothwell
2011-05-30  1:43 Stephen Rothwell
2011-05-30  2:01 ` Eric Dumazet
2011-05-26  1:00 Stephen Rothwell
2011-05-25  0:37 Stephen Rothwell
2011-05-26  7:15 ` Greg KH
2011-03-17 23:04 Stephen Rothwell
2011-03-18  1:13 ` David Miller
2011-01-13 23:51 Stephen Rothwell
2011-01-14  8:45 ` Lennert Buytenhek
2010-10-25  2:52 Stephen Rothwell
2010-10-25  0:57 Stephen Rothwell
2010-10-25  6:36 ` Ingo Molnar
2010-10-25  0:38 Stephen Rothwell
2010-10-25  0:45 ` Stephen Rothwell
2010-10-25  2:39   ` Stephen Rothwell
2010-08-16  4:00 Stephen Rothwell
2010-05-28  0:56 Stephen Rothwell
2010-05-26  1:43 Stephen Rothwell
2010-05-26  1:51 ` Herbert Xu
2010-05-26  1:54   ` David Miller
2010-05-26  1:05 linux-next: build warning in Linus'tree Stephen Rothwell
2010-05-26  1:20 ` Andrew Morton
2010-05-26  4:09   ` Stephen Rothwell
2010-05-26  6:29     ` Joakim Tjernlund
2010-05-26  6:41       ` Andrew Morton
2010-05-26  7:14         ` Stephen Rothwell
2010-05-26 10:21           ` Joakim Tjernlund
2010-05-26 15:29             ` Linus Torvalds
2010-05-26 16:35               ` Joakim Tjernlund
2010-05-26 16:46                 ` Linus Torvalds
2010-05-26 17:31                   ` Joakim Tjernlund
2010-05-26 17:45                     ` Linus Torvalds
2010-05-26 15:33           ` Linus Torvalds
2010-05-26 15:26         ` Linus Torvalds
2010-05-25  1:46 linux-next: build warning in Linus' tree Stephen Rothwell
2010-05-25  4:58 ` David Miller
2010-05-25 23:19   ` David Miller
2010-05-25 23:24     ` David Miller
2010-05-26  2:04       ` Stephen Rothwell
2010-04-26 23:30 Stephen Rothwell
2010-04-26 23:42 ` Greg KH
2010-04-27  3:09   ` Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).