Today's linux-next build (x86_64_allmodconfig) produced these warnings:
drivers/base/memory.c:319: warning: initialization from incompatible pointer type
drivers/base/memory.c:353: warning: initialization from incompatible pointer type
drivers/base/memory.c:408: warning: initialization from incompatible pointer type
drivers/base/memory.c:409: warning: initialization from incompatible pointer type
Introduced by commit 8ff410daa009c4b44be445ded5b0cec00abc0426 ("sysdev:
fix prototype for memory_sysdev_class show/store functions").
The third parameter to SYSDEV_CLASS_ATTR should be a "ssize_t (*)(struct
sysdev_class *, char *)", but this commit changes them to "ssize_t (*)
(struct sysdev_class *, struct sysdev_class_attribute *, char *buf)". Or
maybe the definition of "struct sysdev_class_attribute" is wrong?
It actually looks like commit c29af9636 ("sysdev: Pass attribute in
sysdev_class attributes show/store") referred to in the changelog for the
above commit has not yet been applied to Linus' tree?
--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
On Mon, 18 Jan 2010 15:05:01 +1100 Stephen Rothwell <s...@canb.auug.org.au> wrote:
>
> It actually looks like commit c29af9636 ("sysdev: Pass attribute in
> sysdev_class attributes show/store") referred to in the changelog for the
> above commit has not yet been applied to Linus' tree?
Commit c29af9636 ("sysdev: Pass attribute in sysdev_class attributes
show/store") does appear in linux-next since next-20100111 (in the
driver-core quilt series - therefore intended for 2.6.34) (it will have a
different SHA1 today)
So let's queue 8ff410daa009c (sysdev: fix prototype for memory_sysdev_class show/store functions)
in driver-core and delay it to 2.6.34?
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@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 Mon, 18 Jan 2010 12:29:52 +0800 "Wu, Fengguang" <fenggu...@intel.com> wrote:
>
> On Mon, 18 Jan 2010 15:05:01 +1100 Stephen Rothwell <s...@canb.auug.org.au> wrote:
> > >
> > > It actually looks like commit c29af9636 ("sysdev: Pass attribute in
> > > sysdev_class attributes show/store") referred to in the changelog for the
> > > above commit has not yet been applied to Linus' tree?
> >
> > Commit c29af9636 ("sysdev: Pass attribute in sysdev_class attributes
> > show/store") does appear in linux-next since next-20100111 (in the
> > driver-core quilt series - therefore intended for 2.6.34) (it will have a
> > different SHA1 today)
>
> So let's queue 8ff410daa009c (sysdev: fix prototype for memory_sysdev_class show/store functions)
> in driver-core and delay it to 2.6.34?
Then it would need to be reverted from Linus' tree.
Greg?
On Mon, 18 Jan 2010 16:40:39 +1100 Stephen Rothwell <s...@canb.auug.org.au> wrote:
>
> On Mon, 18 Jan 2010 12:29:52 +0800 "Wu, Fengguang" <fenggu...@intel.com> wrote:
> >
> > On Mon, 18 Jan 2010 15:05:01 +1100 Stephen Rothwell <s...@canb.auug.org.au> wrote:
> > > >
> > > > It actually looks like commit c29af9636 ("sysdev: Pass attribute in
> > > > sysdev_class attributes show/store") referred to in the changelog for the
> > > > above commit has not yet been applied to Linus' tree?
> > >
> > > Commit c29af9636 ("sysdev: Pass attribute in sysdev_class attributes
> > > show/store") does appear in linux-next since next-20100111 (in the
> > > driver-core quilt series - therefore intended for 2.6.34) (it will have a
> > > different SHA1 today)
> >
> > So let's queue 8ff410daa009c (sysdev: fix prototype for memory_sysdev_class show/store functions)
> > in driver-core and delay it to 2.6.34?
>
> Then it would need to be reverted from Linus' tree.
I have reverted commit 8ff410daa009c for today. It looks like Greg
already has the alternate patches queued in the driver-core tree to take
care of this problem when it arises.
So, Greg, can you ask Linus to revert 8ff410daa009c (sysdev: fix
prototype for memory_sysdev_class show/store functions), please? Or
should I? Or should we hope he notices these emails? :-)
No, I think the patch in Linus's tree is correct, so I have fixed up my
tree now.
thanks,
greg k-h
Ick, no, you are correct, Wu's patch shouldn't have been sent to Linus
yet. I'll revert it, and then keep the fixes that were in my tree,
which should make everything safe for the .34 merge.
On Tue, 19 Jan 2010 13:11:17 -0800 Greg KH <gr...@kroah.com> wrote:
>
> Ick, no, you are correct, Wu's patch shouldn't have been sent to Linus
> yet. I'll revert it, and then keep the fixes that were in my tree,
> which should make everything safe for the .34 merge.
Great, thanks.