* Re: linux-next: Tree for September 29 (media & IR build errors)
From: Mauro Carvalho Chehab @ 2010-09-30 4:38 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-media, linux-next, LKML
In-Reply-To: <20100929083128.4efc3f0d.randy.dunlap@oracle.com>
Em 29-09-2010 12:31, Randy Dunlap escreveu:
> On Wed, 29 Sep 2010 14:36:04 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20100928:
>
>
> ERROR: "ir_keydown" [drivers/media/video/ir-kbd-i2c.ko] undefined!
> ERROR: "__ir_input_register" [drivers/media/video/ir-kbd-i2c.ko] undefined!
> ERROR: "get_rc_map" [drivers/media/video/ir-kbd-i2c.ko] undefined!
> ERROR: "ir_input_unregister" [drivers/media/video/ir-kbd-i2c.ko] undefined!
> ERROR: "get_rc_map" [drivers/media/video/cx88/cx88xx.ko] undefined!
> ERROR: "ir_repeat" [drivers/media/video/cx88/cx88xx.ko] undefined!
> ERROR: "ir_input_unregister" [drivers/media/video/cx88/cx88xx.ko] undefined!
> ERROR: "ir_keydown" [drivers/media/video/cx88/cx88xx.ko] undefined!
> ERROR: "__ir_input_register" [drivers/media/video/cx88/cx88xx.ko] undefined!
> ERROR: "get_rc_map" [drivers/media/video/bt8xx/bttv.ko] undefined!
> ERROR: "ir_input_unregister" [drivers/media/video/bt8xx/bttv.ko] undefined!
> ERROR: "__ir_input_register" [drivers/media/video/bt8xx/bttv.ko] undefined!
> ERROR: "ir_core_debug" [drivers/media/IR/ir-common.ko] undefined!
> ERROR: "ir_g_keycode_from_table" [drivers/media/IR/ir-common.ko] undefined!
Randy,
Thanks for the test.
With Sept, 29 + my linux-next tree (that weren't merged on yesterday's build,
I didn't notice the above errors). I suspect that the fixes were already on my
tree.
I noticed, however, two Kconfig errors on staging (for go7007 and cx25821), related
to IR_CORE changes:
warning: (VIDEO_GO7007 && STAGING && !STAGING_EXCLUDE_BUILD && VIDEO_DEV && PCI && I2C && INPUT && BKL && SND || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE)
warning: (VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE)
I'm adding the enclosed patch to my linux-next tree in order to fix this trouble.
On a test after the patch on my tree, your randconfig applied well over my tree.
So, I'm pushing it to my tree at kernel.org.
Cheers,
Mauro
---
commit 9c1eba02d90134fdfa4140b594b2367e90df1dbf
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date: Thu Sep 30 00:56:08 2010 -0300
V4L/DVB: Fix Kconfig dependencies for VIDEO_IR
warning: (VIDEO_GO7007 && STAGING && !STAGING_EXCLUDE_BUILD && VIDEO_DEV && PCI && I2C && INPUT && BKL && SND || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE)
warning: (VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
diff --git a/drivers/staging/cx25821/Kconfig b/drivers/staging/cx25821/Kconfig
index df7756a..a766d0b 100644
--- a/drivers/staging/cx25821/Kconfig
+++ b/drivers/staging/cx25821/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_CX25821
select I2C_ALGOBIT
select VIDEO_BTCX
select VIDEO_TVEEPROM
- select VIDEO_IR
+ depends on VIDEO_IR
select VIDEOBUF_DVB
select VIDEOBUF_DMA_SG
select VIDEO_CX25840
diff --git a/drivers/staging/go7007/Kconfig b/drivers/staging/go7007/Kconfig
index e47f683..b816a60 100644
--- a/drivers/staging/go7007/Kconfig
+++ b/drivers/staging/go7007/Kconfig
@@ -3,7 +3,7 @@ config VIDEO_GO7007
depends on VIDEO_DEV && PCI && I2C && INPUT
depends on SND
select VIDEOBUF_DMA_SG
- select VIDEO_IR
+ depends on VIDEO_IR
select VIDEO_TUNER
select VIDEO_TVEEPROM
select SND_PCM
^ permalink raw reply related
* linux-next: build failure after merge of the final tree (nfs tree related)
From: Stephen Rothwell @ 2010-09-30 3:58 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-next, linux-kernel, Bryan Schumaker
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi Trond,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
fs/nfs/idmap.c: In function 'nfs_idmap_init':
fs/nfs/idmap.c:79: error: implicit declaration of function 'IS_ERR'
fs/nfs/idmap.c:80: error: implicit declaration of function 'PTR_ERR'
fs/nfs/idmap.c: In function 'nfs_idmap_request_key':
fs/nfs/idmap.c:170: error: implicit declaration of function 'IS_ERR_OR_NULL'
Caused by commit 892c16b2faae80ce1a3b3bd280a93533cd4f04a6 ("NFS: new
idmapper"). I guess an include of linux/err.h is missing.
I have reverted that commit for today.
--
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
* Re: linux-next: build failure after merge of the v4l-dvb tree
From: Mauro Carvalho Chehab @ 2010-09-30 3:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jean Delvare
In-Reply-To: <20100929112904.3fd117e0.sfr@canb.auug.org.au>
Em 28-09-2010 22:29, Stephen Rothwell escreveu:
> Hi Mauro,
>
> After merging the v4l-dvb tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/media/video/bt8xx/bttv-input.c: In function 'init_bttv_i2c_ir':
> drivers/media/video/bt8xx/bttv-input.c:306: error: too few arguments to function 'i2c_new_probed_device'
>
> Caused by commit 3c81f945a74224d6e3017596297ee9903929b1a7 ("V4L/DVB:
> bttv: Move PV951 IR to the right driver") interacting with commit
> 9a94241afcc9a481691a9c29b7460217925b59b8 ("i2c: Add support for custom
> probe function") that entered Linus' tree in v2.6.36-rc1. I guess that
> the v4l-dvb commit moved that code to a driver that is now being built.
>
> I have used the v4l-dvb tree from next-20100928 for today.
Ok, that's easy. a new parameter were added to this function, probably via Jean's tree.
The fix is as simple as:
- i2c_new_probed_device(&btv->c.i2c_adap, &info, addr_list);
+ i2c_new_probed_device(&btv->c.i2c_adap, &info, addr_list, NULL);
The extra parameter is for an extra customized probe function, that it is not
needed in this case.
I got a small merge problem on this function:
drivers/media/video/wm8739.c
I just merged the conflict resolution at the merge object, and added a new
patch for the extra parameter in order to solve I2C conflict.
I did a compilation test after merging it with next-20100929 and those issues
were solved on my local build.
Cheers,
Mauro.
^ permalink raw reply
* Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree
From: Mark Brown @ 2010-09-30 3:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Liam Girdwood, linux-next, linux-kernel, Uwe Kleine-König,
Sascha Hauer
In-Reply-To: <20100930112302.e554d367.sfr@canb.auug.org.au>
On Thu, Sep 30, 2010 at 11:23:02AM +1000, Stephen Rothwell wrote:
> The former removed that code that the latter changed. I just used the
> former.
> The latter was just changing some names, so ti may be able to be
> integrated into the former.
Though doing that would break bisection. The other option would be to
revert the bit of the multi-component change that does the rename which
I think should be safe - Sacha, Liam, does that seem sensible? There is
the issue with other potential non-audio users of the SSI to be
considered.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (hwpoison tree related)
From: Naoya Horiguchi @ 2010-09-30 2:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andi Kleen, linux-next, linux-kernel, Jun'ichi Nomura
In-Reply-To: <20100927155551.2e4e4b26.sfr@canb.auug.org.au>
Hi,
On Mon, Sep 27, 2010 at 03:55:51PM +1000, Stephen Rothwell wrote:
> Hi Andi,
>
> After merging the final tree, today's linux-next build (powerpc allnoconfig)
> failed like this:
>
> mm/mprotect.o: In function `migrate_huge_page_move_mapping':
> mprotect.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
> mm/shmem.o:shmem.c:(.text+0x0): first defined here
> mm/rmap.o: In function `migrate_huge_page_move_mapping':
> rmap.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
> mm/shmem.o:shmem.c:(.text+0x0): first defined here
>
> Caused by commit 7b217c52ce7f33379beb27aa7685109fa74ed6bf ("hugetlb:
> hugepage migration core").
>
> This function is declared as "extern int ..." with a body in
> include/linux/migrate.h for the non CONFIG_MIGRATION case.
This build error reappears for x86_64 with !CONFIG_MIGRATION.
As you commented, "extern int" declaration causes it.
So please apply the following patch.
Thank you for reporting.
Thanks,
Naoya Horiguchi
---
Date: Thu, 30 Sep 2010 09:56:02 +0900
Subject: [PATCH] fix build error with !CONFIG_MIGRATION
migrate_huge_page_move_mapping() is declared as "extern int ..."
in include/linux/migrate.h for !CONFIG_MIGRATION,
which causes the build error like below:
mm/mprotect.o: In function `migrate_huge_page_move_mapping':
mprotect.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
mm/shmem.o:shmem.c:(.text+0x0): first defined here
mm/rmap.o: In function `migrate_huge_page_move_mapping':
rmap.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
mm/shmem.o:shmem.c:(.text+0x0): first defined here
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
---
include/linux/migrate.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 3c1941e..085527f 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -50,7 +50,7 @@ static inline int migrate_vmas(struct mm_struct *mm,
static inline void migrate_page_copy(struct page *newpage,
struct page *page) {}
-extern int migrate_huge_page_move_mapping(struct address_space *mapping,
+static inline int migrate_huge_page_move_mapping(struct address_space *mapping,
struct page *newpage, struct page *page)
{
return -ENOSYS;
--
1.7.2.3
^ permalink raw reply related
* Re: [Vipin.Mehta@Atheros.com: [PATCH] staging: ath6kl: Fixing the driver to use modified mmc_host structure
From: Greg KH @ 2010-09-30 2:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Vipin Mehta, linux-next
In-Reply-To: <20100930105748.5b049c44.sfr@canb.auug.org.au>
On Thu, Sep 30, 2010 at 10:57:48AM +1000, Stephen Rothwell wrote:
> Hi Vipin,
>
> On Wed, 29 Sep 2010 17:34:19 -0700 Vipin Mehta <vmehta@atheros.com> wrote:
> >
> > Can you pls help me apply the following patch to the linux-next
> > tree. The patch fixes a compilation problem with ath6kl due to a
> > change in the mmc_host structure. The driver compiles fine in the
> > staging-next-2.6 tree which is where the changes for this driver
> > actually go. However, the mmc stack in the linux-next tree and
> > staging-next-2.6 is out of sync and so this patch is only applicable
> > to linux-next.
>
> I will carry it as a merge fixup patch for the staging-next tree.
> Someone just needs to make sure that this patch gets applied (or sent to
> Linus) at the right time.
I'll keep in my "todo" file to handle it when the merge happens.
thanks,
greg k-h
^ permalink raw reply
* linux-next: manual merge of the sound-asoc tree with the i.MX tree
From: Stephen Rothwell @ 2010-09-30 1:23 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood
Cc: linux-next, linux-kernel, "Uwe Kleine-König",
Sascha Hauer
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in
arch/arm/mach-mx3/devices.c between commit
4697bb926f43b8012ebd111ef43834f42126a0ef ("ARM: imx: dynamically allocate
imx-ssi devices") from the i.MX tree and commit
f0fba2ad1b6b53d5360125c41953b7afcd6deff0 ("ASoC: multi-component - ASoC
Multi-Component Support") from the sound-asoc tree.
The former removed that code that the latter changed. I just used the
former.
The latter was just changing some names, so ti may be able to be
integrated into the former.
--
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
* Re: [Vipin.Mehta@Atheros.com: [PATCH] staging: ath6kl: Fixing the driver to use modified mmc_host structure
From: Stephen Rothwell @ 2010-09-30 0:57 UTC (permalink / raw)
To: Vipin Mehta; +Cc: linux-next, greg
In-Reply-To: <20100930003419.GB5906@vmehta-desktop>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Hi Vipin,
On Wed, 29 Sep 2010 17:34:19 -0700 Vipin Mehta <vmehta@atheros.com> wrote:
>
> Can you pls help me apply the following patch to the linux-next
> tree. The patch fixes a compilation problem with ath6kl due to a
> change in the mmc_host structure. The driver compiles fine in the
> staging-next-2.6 tree which is where the changes for this driver
> actually go. However, the mmc stack in the linux-next tree and
> staging-next-2.6 is out of sync and so this patch is only applicable
> to linux-next.
I will carry it as a merge fixup patch for the staging-next tree.
Someone just needs to make sure that this patch gets applied (or sent to
Linus) at the right time.
--
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
* linux-next: build warning after merge of the kbuild tree
From: Stephen Rothwell @ 2010-09-30 0:52 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-next, linux-kernel, Arnaud Lacombe, Sam Ravnborg
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi Michal,
After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/symbol.c: In function 'sym_expand_string_value':
scripts/kconfig/symbol.c:881: warning: ignoring return value of 'realloc', declared with attribute warn_unused_result
Introduced by commit 76a540958af5390a94b7f68c46cb7f2aed34ccf1 ("kconfig:
add a symbol string expansion helper").
--
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
* linux-next: build warning after merge of the kbuild tree
From: Stephen Rothwell @ 2010-09-30 0:50 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-next, linux-kernel, Arnaud Lacombe, Sam Ravnborg
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Hi Michal,
After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
scripts/kconfig/kxgettext.c: In function 'menu_build_message_list':
scripts/kconfig/kxgettext.c:175: warning: passing argument 3 of 'message__add' discards qualifiers from pointer target type
scripts/kconfig/kxgettext.c:148: note: expected 'char *' but argument is of type 'const char * const'
scripts/kconfig/kxgettext.c:180: warning: passing argument 3 of 'message__add' discards qualifiers from pointer target type
scripts/kconfig/kxgettext.c:148: note: expected 'char *' but argument is of type 'const char * const'
Probably caused by commit 2e7a091833f014cac8a6b92573ca6cd2edd2753c
("kconfig: constify file name").
--
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
* [Vipin.Mehta@Atheros.com: [PATCH] staging: ath6kl: Fixing the driver to use modified mmc_host structure
From: Vipin Mehta @ 2010-09-30 0:34 UTC (permalink / raw)
To: sfr; +Cc: linux-next, greg, vmehta
Stephen,
Can you pls help me apply the following patch to the linux-next
tree. The patch fixes a compilation problem with ath6kl due to a
change in the mmc_host structure. The driver compiles fine in the
staging-next-2.6 tree which is where the changes for this driver
actually go. However, the mmc stack in the linux-next tree and
staging-next-2.6 is out of sync and so this patch is only applicable
to linux-next.
Regards,
Vipin
----- Forwarded message from Vipin Mehta <Vipin.Mehta@Atheros.com> -----
Date: Fri, 17 Sep 2010 18:45:38 -0700
From: Vipin Mehta <Vipin.Mehta@Atheros.com>
To: "greg@kroah.com" <greg@kroah.com>
CC: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Vipin Mehta <Vipin.Mehta@Atheros.com>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"randy.dunlap@oracle.com" <randy.dunlap@oracle.com>
Subject: [PATCH] staging: ath6kl: Fixing the driver to use modified mmc_host
structure
A recent change in the mmc_host structure removed the distinction
between hw and phys segments (58cb50c20fde6059f3f8db4466a1bd4d1fff999c)
Changing the driver to use the modified structure.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Vipin Mehta <vmehta@atheros.com>
---
.../ath6kl/hif/sdio/linux_sdio/src/hif_scatter.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ath6kl/hif/sdio/linux_sdio/src/hif_scatter.c b/drivers/staging/ath6kl/hif/sdio/linux_sdio/src/hif_scatter.c
index 22c6c66..ee8b477 100644
--- a/drivers/staging/ath6kl/hif/sdio/linux_sdio/src/hif_scatter.c
+++ b/drivers/staging/ath6kl/hif/sdio/linux_sdio/src/hif_scatter.c
@@ -285,9 +285,9 @@ A_STATUS SetupHIFScatterSupport(HIF_DEVICE *device, HIF_DEVICE_SCATTER_SUPPORT_I
do {
/* check if host supports scatter requests and it meets our requirements */
- if (device->func->card->host->max_hw_segs < MAX_SCATTER_ENTRIES_PER_REQ) {
+ if (device->func->card->host->max_segs < MAX_SCATTER_ENTRIES_PER_REQ) {
AR_DEBUG_PRINTF(ATH_DEBUG_ERR,("HIF-SCATTER : host only supports scatter of : %d entries, need: %d \n",
- device->func->card->host->max_hw_segs, MAX_SCATTER_ENTRIES_PER_REQ));
+ device->func->card->host->max_segs, MAX_SCATTER_ENTRIES_PER_REQ));
status = A_ENOTSUP;
break;
}
--
1.6.3.3
----- End forwarded message -----
^ permalink raw reply related
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 19:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Steve Wise, linux-rdma, linux-next, linux-kernel
In-Reply-To: <201009292129.31415.arnd@arndb.de>
> Yes, but it's a very weak "should". My automatic conversion script
> uses default_llseek.
OK, I'll just take steve's patch that does default_llseek if it really
doesn't matter.
- R.
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Arnd Bergmann @ 2010-09-29 19:29 UTC (permalink / raw)
To: Roland Dreier; +Cc: Steve Wise, linux-rdma, linux-next, linux-kernel
In-Reply-To: <ada4od82w5x.fsf@cisco.com>
On Wednesday 29 September 2010 21:21:14 Roland Dreier wrote:
>
> > The main difference between default_llseek and generic_file_llseek
> > is that default_llseek doesn't care about the maximum file size
> > of the underlying file system, which is ULONG_MAX on debugfs,
> > so they are equivalent.
>
> I thought default_llseek also takes the BKL still?
Not any more in linux-next.
> > In general, the preferred one is no_llseek for those files where
> > you know you do not need to seek. If you do, I'd use default_llseek
> > for character devices and generic_file_llseek for file systems
> > that set the s_maxbytes.
>
> The case in question is for debugfs files, so we should use
> generic_file_llseek, right?
Yes, but it's a very weak "should". My automatic conversion script
uses default_llseek.
Arnd
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 19:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201009292117.54828.arnd-r2nGTMty4D4@public.gmane.org>
> The main difference between default_llseek and generic_file_llseek
> is that default_llseek doesn't care about the maximum file size
> of the underlying file system, which is ULONG_MAX on debugfs,
> so they are equivalent.
I thought default_llseek also takes the BKL still?
> In general, the preferred one is no_llseek for those files where
> you know you do not need to seek. If you do, I'd use default_llseek
> for character devices and generic_file_llseek for file systems
> that set the s_maxbytes.
The case in question is for debugfs files, so we should use
generic_file_llseek, right?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Arnd Bergmann @ 2010-09-29 19:17 UTC (permalink / raw)
To: Roland Dreier
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <adawrq431sr.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Wednesday 29 September 2010 19:19:32 Roland Dreier wrote:
> > @@ -182,6 +182,7 @@ static const struct file_operations qp_debugfs_fops = {
> > .open = qp_open,
> > .release = qp_release,
> > .read = debugfs_read,
> > + .llseek = default_llseek,
> > };
>
> I think this could actually be generic_file_llseek (right, Arnd?).
The main difference between default_llseek and generic_file_llseek
is that default_llseek doesn't care about the maximum file size
of the underlying file system, which is ULONG_MAX on debugfs,
so they are equivalent.
In general, the preferred one is no_llseek for those files where
you know you do not need to seek. If you do, I'd use default_llseek
for character devices and generic_file_llseek for file systems
that set the s_maxbytes.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 18:52 UTC (permalink / raw)
To: Steve Wise
Cc: stable-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100929141112.26944.21931.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
> --- a/drivers/infiniband/hw/cxgb4/device.c
> +++ b/drivers/infiniband/hw/cxgb4/device.c
> @@ -182,6 +182,7 @@ static const struct file_operations qp_debugfs_fops = {
> .open = qp_open,
> .release = qp_release,
> .read = debugfs_read,
> + .llseek = default_llseek,
> };
>
> static int dump_stag(int id, void *p, void *data)
> @@ -255,6 +256,7 @@ static const struct file_operations stag_debugfs_fops = {
> .open = stag_open,
> .release = stag_release,
> .read = debugfs_read,
> + .llseek = default_llseek,
> };
>
> static int setup_debugfs(struct c4iw_dev *devp)
>
>
Steve, can you also do a quick test to make sure this works OK with
generic_file_llseek instead of default_llseek?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] RDMA/cxgb4: use simple_read_from_buffer() for debugfs handlers.
From: Steve Wise @ 2010-09-29 18:21 UTC (permalink / raw)
To: rdreier-FYB4Gu1CFyUAvxtiuMwx3w, stable-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/device.c | 26 +-------------------------
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c b/drivers/infiniband/hw/cxgb4/device.c
index b254357..22a290d 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -68,32 +68,8 @@ static ssize_t debugfs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
{
struct c4iw_debugfs_data *d = file->private_data;
- loff_t pos = *ppos;
- loff_t avail = d->pos;
- if (pos < 0)
- return -EINVAL;
- if (pos >= avail)
- return 0;
- if (count > avail - pos)
- count = avail - pos;
-
- while (count) {
- size_t len = 0;
-
- len = min((int)count, (int)d->pos - (int)pos);
- if (copy_to_user(buf, d->buf + pos, len))
- return -EFAULT;
- if (len == 0)
- return -EINVAL;
-
- buf += len;
- pos += len;
- count -= len;
- }
- count = pos - *ppos;
- *ppos = pos;
- return count;
+ return simple_read_from_buffer(buf, count, ppos, d->buf, d->pos);
}
static int dump_qp(int id, void *p, void *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 17:50 UTC (permalink / raw)
To: Steve Wise; +Cc: Arnd Bergmann, linux-rdma, linux-next, linux-kernel
In-Reply-To: <4CA37C11.2040603@opengridcomputing.com>
> I'll change it, test it, and send you a patch.
great, thanks.
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Steve Wise @ 2010-09-29 17:49 UTC (permalink / raw)
To: Roland Dreier; +Cc: Arnd Bergmann, linux-rdma, linux-next, linux-kernel
In-Reply-To: <adask0s30sr.fsf@cisco.com>
On 09/29/2010 12:41 PM, Roland Dreier wrote:
> > I assume you mean debugs_read()...Like this?
>
> Sorry, yeah, was looking at the old code. But yes, that code seems a
> lot simpler.
> --
> 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/
>
I'll change it, test it, and send you a patch.
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 17:41 UTC (permalink / raw)
To: Steve Wise; +Cc: Arnd Bergmann, linux-rdma, linux-next, linux-kernel
In-Reply-To: <4CA37715.4020302@opengridcomputing.com>
> I assume you mean debugs_read()...Like this?
Sorry, yeah, was looking at the old code. But yes, that code seems a
lot simpler.
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Steve Wise @ 2010-09-29 17:27 UTC (permalink / raw)
To: Roland Dreier
Cc: Arnd Bergmann, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <adawrq431sr.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On 09/29/2010 12:19 PM, Roland Dreier wrote:
> > @@ -182,6 +182,7 @@ static const struct file_operations qp_debugfs_fops = {
> > .open = qp_open,
> > .release = qp_release,
> > .read = debugfs_read,
> > + .llseek = default_llseek,
> > };
>
> I think this could actually be generic_file_llseek (right, Arnd?).
>
> Also could qp_read() and other read methods be simplified by using
> simple_read_from_buffer()? I don't see anything fancy there, seems like
> the read methods could become one-liners that way.
>
>
I assume you mean debugs_read()...Like this?
static ssize_t debugfs_read(struct file *file, char __user *buf, size_t
count,
loff_t *ppos)
{
struct c4iw_debugfs_data *d = file->private_data;
return simple_read_from_buffer(buf, ppos, d->buf, d->pos);
}
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] RDMA/cxgb4: Add default_llseek to debugfs files.
From: Roland Dreier @ 2010-09-29 17:19 UTC (permalink / raw)
To: Steve Wise
Cc: Arnd Bergmann, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100929141112.26944.21931.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
> @@ -182,6 +182,7 @@ static const struct file_operations qp_debugfs_fops = {
> .open = qp_open,
> .release = qp_release,
> .read = debugfs_read,
> + .llseek = default_llseek,
> };
I think this could actually be generic_file_llseek (right, Arnd?).
Also could qp_read() and other read methods be simplified by using
simple_read_from_buffer()? I don't see anything fancy there, seems like
the read methods could become one-liners that way.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: null dereference in ipip6_get_stats in linux-next
From: Eric Dumazet @ 2010-09-29 16:48 UTC (permalink / raw)
To: Jesse Gross
Cc: J. Bruce Fields, Stephen Rothwell, linux-next, linux-kernel,
netdev
In-Reply-To: <AANLkTin2E2ACB5yiAUA7MbYqzYyMKAi+syFOCzXWqVrY@mail.gmail.com>
Le mercredi 29 septembre 2010 à 09:39 -0700, Jesse Gross a écrit :
> On Wed, Sep 29, 2010 at 9:26 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > Last night's linux-next fails to boot for me; apologies if this is already
> > known.
>
> Eric sent out a patch for this:
> http://patchwork.ozlabs.org/patch/65961/
Also same kind of problem for ipip :
http://patchwork.ozlabs.org/patch/65951/
Sorry guys :(
^ permalink raw reply
* Re: null dereference in ipip6_get_stats in linux-next
From: Jesse Gross @ 2010-09-29 16:39 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Stephen Rothwell, linux-next, linux-kernel, Eric Dumazet, netdev
In-Reply-To: <20100929162625.GB17087@fieldses.org>
On Wed, Sep 29, 2010 at 9:26 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> Last night's linux-next fails to boot for me; apologies if this is already
> known.
Eric sent out a patch for this:
http://patchwork.ozlabs.org/patch/65961/
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (Was: linux-next: build warning after merge of the final tree)
From: J. Bruce Fields @ 2010-09-29 16:30 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <4CA322DA.90705@parallels.com>
On Wed, Sep 29, 2010 at 03:28:26PM +0400, Pavel Emelyanov wrote:
> > This actually causes a build failure on a sparc32 defconfig build:
> >
> > `rpcauth_remove_module' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
> >
> > I applied the following patch for today:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Wed, 29 Sep 2010 14:07:07 +1000
> > Subject: [PATCH] sunrpc: fix up section mismatch
> >
> > Fixes:
> >
> > `rpcauth_remove_module' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Oops :(
>
> Acked-by: Pavel Emelyanov <xemul@openvz.org>
Thanks, applied, and I'll push that out soon.
--b.
>
> > ---
> > include/linux/sunrpc/auth.h | 4 ++--
> > net/sunrpc/auth.c | 2 +-
> > net/sunrpc/auth_generic.c | 2 +-
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h
> > index 5bbc447..b202475 100644
> > --- a/include/linux/sunrpc/auth.h
> > +++ b/include/linux/sunrpc/auth.h
> > @@ -122,8 +122,8 @@ extern const struct rpc_authops authnull_ops;
> > int __init rpc_init_authunix(void);
> > int __init rpc_init_generic_auth(void);
> > int __init rpcauth_init_module(void);
> > -void __exit rpcauth_remove_module(void);
> > -void __exit rpc_destroy_generic_auth(void);
> > +void rpcauth_remove_module(void);
> > +void rpc_destroy_generic_auth(void);
> > void rpc_destroy_authunix(void);
> >
> > struct rpc_cred * rpc_lookup_cred(void);
> > diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
> > index e9eaaf7..2c0d9e6 100644
> > --- a/net/sunrpc/auth.c
> > +++ b/net/sunrpc/auth.c
> > @@ -658,7 +658,7 @@ out1:
> > return err;
> > }
> >
> > -void __exit rpcauth_remove_module(void)
> > +void rpcauth_remove_module(void)
> > {
> > rpc_destroy_authunix();
> > rpc_destroy_generic_auth();
> > diff --git a/net/sunrpc/auth_generic.c b/net/sunrpc/auth_generic.c
> > index 43162bb..e010a01 100644
> > --- a/net/sunrpc/auth_generic.c
> > +++ b/net/sunrpc/auth_generic.c
> > @@ -158,7 +158,7 @@ int __init rpc_init_generic_auth(void)
> > return rpcauth_init_credcache(&generic_auth);
> > }
> >
> > -void __exit rpc_destroy_generic_auth(void)
> > +void rpc_destroy_generic_auth(void)
> > {
> > rpcauth_destroy_credcache(&generic_auth);
> > }
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox