[-mmotm] some different buliding failures

[-mmotm] some different buliding failures

[Li Zefan]

drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type


drivers/media/video/ivtv/ivtv-ioctl.c: In function 'ivtv_set_funcs':
drivers/media/video/ivtv/ivtv-ioctl.c:1899: error: 'struct video_device' has no member named 'vidioc_g_register'
drivers/media/video/ivtv/ivtv-ioctl.c:1900: error: 'struct video_device' has no member named 'vidioc_s_register'


mm/hugetlb.c: In function 'vma_needs_reservation':
mm/hugetlb.c:859: error: implicit declaration of function 'vma_pagecache_offset'

Re: [-mmotm] some different buliding failures

[Andrew Morton]

On Wed, 02 Jul 2008 14:23:28 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:

> 
> drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type
> 

Ben, can you please take a look?  I suspect the fix is to disable this
driver on x86.

> 
> drivers/media/video/ivtv/ivtv-ioctl.c: In function 'ivtv_set_funcs':
> drivers/media/video/ivtv/ivtv-ioctl.c:1899: error: 'struct video_device' has no member named 'vidioc_g_register'
> drivers/media/video/ivtv/ivtv-ioctl.c:1900: error: 'struct video_device' has no member named 'vidioc_s_register'

Seems to have been fixed.

> 
> mm/hugetlb.c: In function 'vma_needs_reservation':
> mm/hugetlb.c:859: error: implicit declaration of function 'vma_pagecache_offset'

Against hugetlb-reservations-fix-hugetlb-map_private-reservations-across-vma-splits-v2.patch:

 mm/hugetlb.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff -puN mm/hugetlb.c~hugetlb-reservations-fix-hugetlb-map_private-reservations-across-vma-splits-v2-fix mm/hugetlb.c
--- a/mm/hugetlb.c~hugetlb-reservations-fix-hugetlb-map_private-reservations-across-vma-splits-v2-fix
+++ a/mm/hugetlb.c
@@ -856,7 +856,7 @@ static int vma_needs_reservation(struct 
 
 	} else  {
 		int err;
-		pgoff_t idx = vma_pagecache_offset(h, vma, addr);
+		pgoff_t idx = vma_hugecache_offset(h, vma, addr);
 		struct resv_map *reservations = vma_resv_map(vma);
 
 		err = region_chg(&reservations->regions, idx, idx + 1);
@@ -876,7 +876,7 @@ static void vma_commit_reservation(struc
 		region_add(&inode->i_mapping->private_list, idx, idx + 1);
 
 	} else if (is_vma_resv_set(vma, HPAGE_RESV_OWNER)) {
-		pgoff_t idx = vma_pagecache_offset(h, vma, addr);
+		pgoff_t idx = vma_hugecache_offset(h, vma, addr);
 		struct resv_map *reservations = vma_resv_map(vma);
 
 		/* Mark this page used in the map. */
@@ -1553,8 +1553,8 @@ static void hugetlb_vm_op_close(struct v
 	unsigned long end;
 
 	if (reservations) {
-		start = vma_pagecache_offset(h, vma, vma->vm_start);
-		end = vma_pagecache_offset(h, vma, vma->vm_end);
+		start = vma_hugecache_offset(h, vma, vma->vm_start);
+		end = vma_hugecache_offset(h, vma, vma->vm_end);
 
 		reserve = (end - start) -
 			region_count(&reservations->regions, start, end);
_

Re: [-mmotm] some different buliding failures

[Andrew Morton]

On Wed, 02 Jul 2008 14:23:28 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:

> drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type

OK, this monstrosity seems to make it compile:


diff -puN drivers/mfd/sm501.c~sm501-guess-n-giggle-build-fix drivers/mfd/sm501.c
--- a/drivers/mfd/sm501.c~sm501-guess-n-giggle-build-fix
+++ a/drivers/mfd/sm501.c
@@ -19,7 +19,9 @@
 #include <linux/device.h>
 #include <linux/platform_device.h>
 #include <linux/pci.h>
+#ifdef CONFIG_MFD_SM501_GPIO
 #include <linux/gpio.h>
+#endif
 #include <linux/i2c-gpio.h>
 
 #include <linux/sm501.h>
@@ -33,6 +35,7 @@ struct sm501_device {
 	struct platform_device		pdev;
 };
 
+#ifdef CONFIG_MFD_SM501_GPIO
 struct sm501_gpio;
 
 struct sm501_gpio_chip {
@@ -50,13 +53,15 @@ struct sm501_gpio {
 	void __iomem		*regs;
 	struct resource		*regs_res;
 };
+#endif
 
 struct sm501_devdata {
 	spinlock_t			 reg_lock;
 	struct mutex			 clock_lock;
 	struct list_head		 devices;
+#ifdef CONFIG_MFD_SM501_GPIO
 	struct sm501_gpio		 gpio;
-
+#endif
 	struct device			*dev;
 	struct resource			*io_res;
 	struct resource			*mem_res;
@@ -1116,6 +1121,7 @@ static inline int sm501_gpio_pin2nr(stru
 }
 #endif
 
+#ifdef CONFIG_MFD_SM501_GPIO
 static int sm501_register_gpio_i2c_instance(struct sm501_devdata *sm,
 					    struct sm501_platdata_gpio_i2c *iic)
 {
@@ -1168,6 +1174,7 @@ static int sm501_register_gpio_i2c(struc
 
 	return 0;
 }
+#endif
 
 /* sm501_dbg_regs
  *
@@ -1329,12 +1336,14 @@ static int sm501_init_dev(struct sm501_d
 			sm501_register_gpio(sm);
 	}
 
+#ifdef CONFIG_MFD_SM501_GPIO
 	if (pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) {
 		if (!sm->gpio.registered)
 			dev_err(sm->dev, "no gpio registered for i2c gpio.\n");
 		else
 			sm501_register_gpio_i2c(sm, pdata);
 	}
+#endif
 
 	ret = sm501_check_clocks(sm);
 	if (ret) {
@@ -1643,8 +1652,10 @@ static void sm501_dev_remove(struct sm50
 
 	device_remove_file(sm->dev, &dev_attr_dbg_regs);
 
+#ifdef CONFIG_MFD_SM501_GPIO
 	if (sm->gpio.registered)
 		sm501_gpio_remove(sm);
+#endif
 }
 
 static void sm501_pci_remove(struct pci_dev *dev)
_

Re: [-mmotm] some different buliding failures

[Li Zefan]

Andrew Morton wrote:
> On Wed, 02 Jul 2008 14:23:28 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:
> 
>> drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type
> 
> OK, this monstrosity seems to make it compile:
> 

Yes, it passed compile with my config. :)

Re: [-mmotm] some different buliding failures

[Paul Mundt]

On Wed, Jul 02, 2008 at 01:02:12AM -0700, Andrew Morton wrote:
> On Wed, 02 Jul 2008 14:23:28 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:
> > drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type
> > 
> 
> Ben, can you please take a look?  I suspect the fix is to disable this
> driver on x86.
> 
Note that there are SM501 PCI cards that are architecture independent..

Re: [-mmotm] some different buliding failures

[Ben Dooks]

On Wed, Jul 02, 2008 at 05:20:21PM +0900, Paul Mundt wrote:
> On Wed, Jul 02, 2008 at 01:02:12AM -0700, Andrew Morton wrote:
> > On Wed, 02 Jul 2008 14:23:28 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:
> > > drivers/mfd/sm501.c:39: error: field 'gpio' has incomplete type
> > > 
> > 
> > Ben, can you please take a look?  I suspect the fix is to disable this
> > driver on x86.
> > 
> Note that there are SM501 PCI cards that are architecture independent..

The best fix would be to enable the gpiolib[1] for x86. I agree the
changes to ensure it builds with gpio turned off where incomplete. I'll
re-issue these as soon as possible.

[1] why is this a library anyway? it isn't as if you can export it to use
    in other projects, and the choice is gpiolib or nothing.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: [-mmotm] some different buliding failures

[Andrew Morton]

OK, I uploaded another mmotm (http://userweb.kernel.org/~akpm/mmotm/). 
It passes i386 allnoconfig and allmodconfig.  Heaven knows what it does
at runtime.  We'll take a look at that tomorrow.

People have been madly adding new warnings.  I don't know how this
happens.

kvm is particularly noisy.

Re: [-mmotm] some different buliding failures

[Avi Kivity]

Andrew Morton wrote:
> OK, I uploaded another mmotm (http://userweb.kernel.org/~akpm/mmotm/). 
> It passes i386 allnoconfig and allmodconfig.  Heaven knows what it does
> at runtime.  We'll take a look at that tomorrow.
>
> People have been madly adding new warnings.  I don't know how this
> happens.
>
> kvm is particularly noisy.
>   

I'm sure you have before, but can you remind me how to figure out what 
commit to apply mmotm onto?  I looked in series and origin.patch, but no 
luck.  Applying on top of the last (first) commit in origin.patch's head 
did not work.

Also, can I suggest including series in b-o.tar.gz?  Nice to have 
everything in one tarball.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [-mmotm] some different buliding failures

[Hugh Dickins]

On Wed, 2 Jul 2008, Avi Kivity wrote:
> 
> I'm sure you have before, but can you remind me how to figure out what commit
> to apply mmotm onto?  I looked in series and origin.patch, but no luck.
> Applying on top of the last (first) commit in origin.patch's head did not
> work.

I look at its mm.patch, which today shows

 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 26
-EXTRAVERSION = -rc8
+EXTRAVERSION = -rc8-mm1

which hints that it applies to a 2.6.26-rc8 tree.

> Also, can I suggest including series in b-o.tar.gz?
> Nice to have everything in one tarball.

It is included, but (I can't tell you why) one level up.
You should find these three in the directory you extracted
into, I promptly move them down into broken-out itself.

.DATE
.DATE=2008-07-02-04-02
series

Hugh (probably _not_ extracted into your current directory ;)

Re: [-mmotm] some different buliding failures

[Avi Kivity]

Hugh Dickins wrote:
> On Wed, 2 Jul 2008, Avi Kivity wrote:
>   
>> I'm sure you have before, but can you remind me how to figure out what commit
>> to apply mmotm onto?  I looked in series and origin.patch, but no luck.
>> Applying on top of the last (first) commit in origin.patch's head did not
>> work.
>>     
>
> I look at its mm.patch, which today shows
>
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 26
> -EXTRAVERSION = -rc8
> +EXTRAVERSION = -rc8-mm1
>
> which hints that it applies to a 2.6.26-rc8 tree.
>
>   

Thanks.  That worked.

>> Also, can I suggest including series in b-o.tar.gz?
>> Nice to have everything in one tarball.
>>     
>
> It is included, but (I can't tell you why) one level up.
> You should find these three in the directory you extracted
> into, I promptly move them down into broken-out itself.
>
> .DATE
> .DATE=2008-07-02-04-02
> series
>
> Hugh (probably _not_ extracted into your current directory ;)
>   

Thanks 2.

Anyway I've fixed the warnings and will push out the fix shortly.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.