Segher Boessenkool wrote:
And further, there is no separation of warning classes into
might-be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
Indeed. Please file a bug report.
Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
-Scott
(cc's added)
On Wed, 8 Apr 2009 14:57:42 -0700
"Jeff Haran" wrote:
> Hi,
>
> Recent versions of this function start off with:
>
> static void mpc85xx_mc_check(struct mem_ctl_info *mci)
> {
> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
> ...
>
> err_detect = in_be32(pdata->mc_v
From: Suneel
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel
Signed-off-by: John Linn
---
V2 - In
And further, there is no separation of warning classes into might-
be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
Indeed. Please file a bug report.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/m
The problem is that GCC does not give an error (only a warning)
even for
things like this where it should be trivial to detect that the
usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not reject this code, because the undefined
behavi
While adding native EEH support to Emulex and Qlogic drivers, it was
discovered that dev->error_state was set to pci_io_channel_normal too
late in the recovery process. These drivers rely on error_state to
determine if they can access the device in their slot_reset callback,
thus error_state ne
On Mon, Feb 23, 2009 at 05:27:53PM +0530, Vijay Nikam wrote:
> Hello,
Sorry for the late reply; I just noticed this sitting in my inbox.
> I created a device node for gpio-controller for evaluation board
> mpc83313erdb. I created the dtb and loaded on target and the interrupt
> is generated succe
Andreas Schwab wrote:
Scott Wood writes:
The problem is that GCC does not give an error (only a warning) even for
things like this where it should be trivial to detect that the usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not rejec
Scott Wood writes:
> The problem is that GCC does not give an error (only a warning) even for
> things like this where it should be trivial to detect that the usage *is*
> uninitialized, not just might be:
>
> int foo(void)
> {
>int a;
>
>return a;
> }
The compiler must not reject this c
Segher Boessenkool wrote:
Unfortunately -Wno-uninitialized also suppresses the warnings that point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error, i
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function
'associativity_show':
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562:
warning: 'associativity' may be used uninitialized in this function
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function
'size_show
On Fri, 10 Apr 2009 17:07:26 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> keywest sound driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> ---
> sound/ppc/keywest.c | 81
>
The i2c_device_name macro doesn't have much value, get rid of it.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 16:22:08.0
+0200
++
The legacy i2c binding model is going away soon, so convert the ppc
keywest sound driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c | 81 +--
1 file changed, 40 insertions(+)
On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> From: Jean Delvare
> Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
>
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
> Signed-off-by: Jean Delv
On Thu, 9 Apr 2009, Andrew Morton wrote:
> On Mon, 6 Apr 2009 22:01:15 +0100 (BST)
> Hugh Dickins wrote:
>
> > Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
> > let powerpc 256kB pages coexist with CONFIG_SHMEM again.
> >
> > Signed-off-by: Hugh Dickins
> > ---
> > Added lin
16 matches
Mail list logo
