On Wed, Oct 15, 2008 at 11:58 PM, David Miller wrote:
>> There's already a completely different fix queued in netdev patchworks
>> (for myri10ge only right now, to be duplicated for Intel drivers). The
>> idea is to stop having almost-unrelated drivers select each other
>> directly, let people select which drivers they really want, and have
>> Kconfig handle modules/builtin-stuff correctly. See
>> http://patchwork.ozlabs.org/patch/4506/
>
> Right, my plan was to duplicate this for the other drivers.

The work is already done for ixgbe and igb, and we have it in testing.
It should be in your inbox today or tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 16 Oct 2008 14:21:17 +0400, Sergei Shtylyov wrote:
> > drivers/serial/serial_txx9.c: In function 'serial_txx9_probe':
> > drivers/serial/serial_txx9.c:1041: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
> >
>
> Atsushi-san, are you seeing this one?

Yes, I'll send a one-liner patch soon.

---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Johannes Berg
Date: Thu, 16 Oct 2008 16:57:19 +0200

> On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> >
> >
> > > net/sched/sch_generic.c: In function 'dev_watchdog':
> > > net/sched/sch_generic.c:224: warning: unused variable 'drivername'
> >
> > Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
> > on the stack looks unused.
>
> I've complained about this to Arjan before, we actually lose all
> messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
> for warnings too.

Ok I see how that works, yes, it should be fixed.

If the platform defines a __WARN (which powerpc does) the
whole format string and printf args go unevaluated, it's
because of the following sequence in asm-generic/bug.h:

#ifndef __WARN
#ifndef __ASSEMBLY__
extern void warn_on_slowpath(const char *file, const int line);
extern void warn_slowpath(const char *file, const int line,
const char *fmt, ...) __attribute__((format(printf, 3, 4)));
#define WANT_WARN_ON_SLOWPATH
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define __WARN_printf(arg...) __WARN()
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller wrote:
> #endif
> #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
> #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
> #else
> #define __WARN_printf(arg...) __WARN()

the easiest way I suppose would be to do

#define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)

any obvious problems with this ?


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* David Miller wrote:

> > net/dccp/options.c: In function 'dccp_parse_options':
> > net/dccp/options.c:67: warning: 'value' may be used uninitialized in
> > this function
>
> Known issue, not trivial to fix, gcc is just being incredibly silly
> here as it can't see all of the control flow.

i just ran into this - do you have any objection against the patch
below?

Should we have a cleaner annotation perhaps instead of
uninitialized_var()? Something like:

#define __used __attribute__((used))

?

Ingo

---------->
From d917af0bd043eab40d57f79cba9cf7a7b265a205 Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Fri, 17 Oct 2008 12:41:30 +0200
Subject: [PATCH] fix warning in net/dccp/options.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

fix this warning:

net/dccp/options.c: In function ‘dccp_parse_options’:
net/dccp/options.c:67: warning: ‘value’ may be used uninitialized in this function

This is a bogus GCC warning. The compiler does not recognize the relation
between "value" and "mandatory" variables: the code flow can ever reach
the "out_invalid_option:" label if 'mandatory' is set to 1, and when
'mandatory' is non-zero, we'll always have 'value' initialized.

Help out the compiler by annotating the variable.

Signed-off-by: Ingo Molnar
---
net/dccp/options.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/dccp/options.c b/net/dccp/options.c
index 0809b63..18dcfb9 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -64,7 +64,7 @@ int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq,
(dh->dccph_doff * 4);
struct dccp_options_received *opt_recv = &dp->dccps_options_received;
unsigned char opt, len;
- unsigned char *value;
+ unsigned char *uninitialized_var(value);
u32 elapsed_time;
__be32 opt_val;
int rc;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thursday 16 October 2008, Josh Boyer wrote:
> +#ifdef CONFIG_PPC_DCR_NATIVE
> ********if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
> ****************mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
> ********************************(mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | ICINTSTAT_ICTX));
> +#endif
> *

So what if you have a mmio based DRC implementation and still want to use
this feature?

I guess you really should use dcr_read/dcr_write here instead of mtdcr/mfdcr.

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 17 Oct 2008 14:56:52 +0200
Arnd Bergmann wrote:

> On Thursday 16 October 2008, Josh Boyer wrote:
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > Â*Â*Â*Â*Â*Â*Â*Â*if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
> > Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
> > Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*(mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | ICINTSTAT_ICTX));
> > +#endif
> > Â*
>
> So what if you have a mmio based DRC implementation and still want to use
> this feature?

You have to have hardware that does that. When it exists, we can
probably worry about it. Hopefully that will never happen. (Axon is
an abomination that should not be repeated.)

> I guess you really should use dcr_read/dcr_write here instead of mtdcr/mfdcr.

We can look at that. It's not going to be high on my TODO list at the
moment though. (hint, there are other places that do the same thing
here and they should all be cleaned up if we're going to bother.)

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 2008-10-16 at 13:02 -0700, Arjan van de Ven wrote:
> On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
> David Miller wrote:
> > #endif
> > #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
> > #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
> > #else
> > #define __WARN_printf(arg...) __WARN()
>
> the easiest way I suppose would be to do
>
> #define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)
>
> any obvious problems with this ?

No, not really. You won't get it on kerneloops, but I guess that's not
an easily tractable problem.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJI+dRuAAoJEKVg1VMiehFYmDYP/0kTJWdpsf24PrUnYtMIXVLv
C46H78KmP/qVYLbDiE0uK4fCq6T5agsZga7fSK5kBA8NiNIL1wXc4X7Kjiba DWkr
lEmpAchTZZZgcgO4oW7AAuxoPtFJwJ0GVe8IOU93N+ItbPuCah A+XgbSC670VOIT
G5655z9ApbE1Zk2ovPVezBgOhsQgCNEX+V57ALRLqNrW5/w3yFsaAcJSjWdNQQ6z
YqKBNB96Ds8Y9aJNoFSoG9Y09FU3tuCvN0RyQTURxpwHKZ6f/PWBzdlGUZRYMUh0
dHSrUvow0SzAFhWyZmhmAeRtCwC2F0T95wxun9LOht4o37hrKE 3xN9ScIbSOFIYq
m8KD5ZAd39nFuCEj41GBi4B0CRy0IhTqGeCIRqyVFYtKSFR4M+ eJ9fskrPyWYJXI
zofkGWlIqKBIGM9v8vMBWX5dalocIFBZFyYiPj/NYMsMRsRfJ33i0UVYk6VGijIs
8b5gyl5ASmS/yjJAB5DwOQEW7UZs2RrTFSKI0A9BlQOp73Qplwdie7zas7QK/wHM
vtosJ2/aTo3SdLumy+B9KphBwJBk09FxhNiU76aJnLtXsWnQ0/9kxQKlfW9dctTi
bKCqB8k2XhGkZ13SEJvpKs9WGSfLXchv2kAOs/O7P+OWEMaz/4FpbZPhV+CGn5Ty
Ff7sKOr58jw93iMShX+S
=OjGy
-----END PGP SIGNATURE-----

On Thu, 2008-10-16 at 10:38 -0400, Josh Boyer wrote:
> On Thu, Oct 16, 2008 at 03:56:50PM +1100, Benjamin Herrenschmidt wrote:
> >> drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
> >> drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 'mtdcri'
> >> drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in this function)
> >> drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is reported only once
> >> drivers/net/ibm_newemac/mal.c:284: error: for each function it appears in.)
> >> drivers/net/ibm_newemac/mal.c:285: error: implicit declaration of function 'mfdcri'
> >> drivers/net/ibm_newemac/mal.c: In function 'mal_rxeob':
> >> drivers/net/ibm_newemac/mal.c:302: error: 'SDR0' undeclared (first use in this function)
> >
> >That's annoying, I'll have a look.
>
> Support for new features needed by the PPC 405EZ boards
> introduced some errors in the MAL and EMAC feature handling.
> This broke 'allmodconfig' builds as CONFIG_PPC_DCR_NATIVE is
> not set for those.
>
> This patch fixes these errors by wrapping the code in the
> appropriate #ifdefs.
>
> Signed-off-by: Josh Boyer

Acked-by: Benjamin Herrenschmidt
---

Jeff, this breaks build, I'll put it in powerpc.git for a merge today,

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Benjamin Herrenschmidt wrote:
> On Thu, 2008-10-16 at 10:38 -0400, Josh Boyer wrote:
>> On Thu, Oct 16, 2008 at 03:56:50PM +1100, Benjamin Herrenschmidt wrote:
>>>> drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
>>>> drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 'mtdcri'
>>>> drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in this function)
>>>> drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is reported only once
>>>> drivers/net/ibm_newemac/mal.c:284: error: for each function it appears in.)
>>>> drivers/net/ibm_newemac/mal.c:285: error: implicit declaration of function 'mfdcri'
>>>> drivers/net/ibm_newemac/mal.c: In function 'mal_rxeob':
>>>> drivers/net/ibm_newemac/mal.c:302: error: 'SDR0' undeclared (first use in this function)
>>> That's annoying, I'll have a look.
>> Support for new features needed by the PPC 405EZ boards
>> introduced some errors in the MAL and EMAC feature handling.
>> This broke 'allmodconfig' builds as CONFIG_PPC_DCR_NATIVE is
>> not set for those.
>>
>> This patch fixes these errors by wrapping the code in the
>> appropriate #ifdefs.
>>
>> Signed-off-by: Josh Boyer
>
> Acked-by: Benjamin Herrenschmidt
> ---
>
> Jeff, this breaks build, I'll put it in powerpc.git for a merge today,

ACK


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/