Hi all,
Changes since 20110520:
My fixes tree contains:
sparc32: fix build, move inline function to .c file
sparc32: fix build, fix missing cpu_relax declaration
Linus' tree lost its build failures.
The i.MX tree gained conflicts against the arm tree.
The s5p tree gained a conflict against the arm tree.
The s390 tree lost its build failure.
The sparc tree gained a conflict against the fixes tree.
The ubifs tree gained a build failure for which I reverted a commit.
The net tree lost its conflict.
The block tree lost its conflicts.
The mfd tree lost its conflict.
The tip tree lost its conflicts and build failure.
The driver-core tree lost its conflict.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 190 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell [email protected]
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
CONFLICT (content): Merge conflict in include/linux/clocksource.h
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-imx/Kconfig
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/Kconfig
Merging linux-spec/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
CONFLICT (content): Merge conflict in arch/sparc/include/asm/smp_32.h
CONFLICT (content): Merge conflict in arch/sparc/kernel/smp_32.c
Merging tile/master
Merging unicore32/unicore32
CONFLICT (content): Merge conflict in drivers/net/Kconfig
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
CONFLICT (content): Merge conflict in include/linux/pci_ids.h
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
Merging kbuild/for-next
CONFLICT (content): Merge conflict in Makefile
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
Merging wireless/master
Merging bluetooth/master
CONFLICT (content): Merge conflict in net/bluetooth/l2cap_core.c
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging cpufreq-move/move-drivers
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
CONFLICT (content): Merge conflict in drivers/mmc/host/tmio_mmc_pio.c
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in mm/slub.c
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
CONFLICT (content): Merge conflict in drivers/video/omap2/dss/dsi.c
CONFLICT (content): Merge conflict in drivers/video/omap2/dss/dss_features.c
CONFLICT (content): Merge conflict in drivers/video/omap2/dss/dss_features.h
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/mfd/Kconfig
CONFLICT (content): Merge conflict in drivers/mfd/Makefile
Merging security-testing/next
Merging selinux/master
CONFLICT (content): Merge conflict in lib/flex_array.c
CONFLICT (content): Merge conflict in security/selinux/avc.c
CONFLICT (content): Merge conflict in security/selinux/hooks.c
CONFLICT (content): Merge conflict in security/selinux/ss/policydb.c
CONFLICT (content): Merge conflict in security/smack/smack_lsm.c
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging suspend/linux-next
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
Merging devicetree/devicetree/next
Merging spi/spi/next
Merging tip/auto-latest
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/percpu.h
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
CONFLICT (content): Merge conflict in drivers/platform/x86/Kconfig
CONFLICT (content): Merge conflict in drivers/platform/x86/Makefile
CONFLICT (content): Merge conflict in drivers/platform/x86/eeepc-laptop.c
CONFLICT (content): Merge conflict in drivers/platform/x86/sony-laptop.c
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
CONFLICT (content): Merge conflict in arch/alpha/include/asm/unistd.h
CONFLICT (content): Merge conflict in arch/alpha/kernel/systbls.S
CONFLICT (content): Merge conflict in arch/m68k/kernel/entry_mm.S
Merging driver-core/driver-core-next
Merging tty/tty-next
CONFLICT (content): Merge conflict in drivers/bluetooth/hci_ldisc.c
CONFLICT (content): Merge conflict in drivers/tty/serial/Makefile
Merging usb/usb-next
CONFLICT (content): Merge conflict in arch/arm/mach-exynos4/mach-nuri.c
Merging staging/staging-next
CONFLICT (content): Merge conflict in drivers/staging/brcm80211/brcmfmac/wl_cfg80211.c
CONFLICT (content): Merge conflict in drivers/staging/intel_sst/intelmid.c
CONFLICT (delete/modify): drivers/staging/rt2860/common/cmm_data_pci.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rt2860/common/cmm_data_pci.c left in tree.
CONFLICT (delete/modify): drivers/staging/rt2860/common/cmm_data_usb.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rt2860/common/cmm_data_usb.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/usbip/vhci_sysfs.c
$ git rm -f drivers/staging/rt2860/common/cmm_data_pci.c drivers/staging/rt2860/common/cmm_data_usb.c
Merging slabh/slabh
Merging bkl-config/config
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in fs/btrfs/extent_io.c
Merging arm-dt/devicetree/arm-next
Merging scsi-post-merge/merge-base:master
[master c01731f] Revert "UBIFS: switch to dynamic printks"
On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110520:
when CONFIG_NET is not enabled:
ERROR: "skb_trim" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_kernel_create" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_kernel_release" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_rcv_skb" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "nla_put" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "init_net" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_dump_start" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "skb_put" [drivers/infiniband/core/ib_core.ko] undefined!
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Randy Dunlap <[email protected]>
apic_flat_64.c needs to include module.h to fix these warnings:
arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
Signed-off-by: Randy Dunlap <[email protected]>
---
arch/x86/kernel/apic/apic_flat_64.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
+++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
@@ -16,6 +16,7 @@
#include <linux/ctype.h>
#include <linux/init.h>
#include <linux/hardirq.h>
+#include <linux/module.h>
#include <asm/smp.h>
#include <asm/apic.h>
#include <asm/ipi.h>
On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110520:
when CONFIG_SMP is not enabled:
drivers/hwmon/coretemp.c:765: error: implicit declaration of function 'cpu_sibling_mask'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 05/23/2011 09:43 PM, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> apic_flat_64.c needs to include module.h to fix these warnings:
>
> arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
> arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
> arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
>
> Signed-off-by: Randy Dunlap <[email protected]>
> ---
> arch/x86/kernel/apic/apic_flat_64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
> @@ -16,6 +16,7 @@
> #include <linux/ctype.h>
> #include <linux/init.h>
> #include <linux/hardirq.h>
> +#include <linux/module.h>
> #include <asm/smp.h>
> #include <asm/apic.h>
> #include <asm/ipi.h>
Thanks Randy! For some reason I didn't hit this problem while
were compiling the kernel and testing it (I usually do not use
modules though).
I've CC'ed Ingo and Suresh.
--
Cyrill
Sigh. And I was sure I tested that :(. I'll look into it immediately.
Guenter
On Mon, 2011-05-23 at 13:49 -0400, Randy Dunlap wrote:
> On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20110520:
>
> when CONFIG_SMP is not enabled:
>
> drivers/hwmon/coretemp.c:765: error: implicit declaration of function 'cpu_sibling_mask'
>
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> _______________________________________________
> lm-sensors mailing list
> [email protected]
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
On Mon, May 23, 2011 at 9:42 AM, Randy Dunlap <[email protected]> wrote:
> On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20110520:
>
> when CONFIG_NET is not enabled:
>
> ERROR: "skb_trim" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_kernel_create" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_kernel_release" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_rcv_skb" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "nla_put" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "init_net" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_dump_start" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "skb_put" [drivers/infiniband/core/ib_core.ko] undefined!
Guess we have to depend on CONFIG_NET now.
I'll fix it up.
Thanks,
Roland
On 05/23/2011 09:51 PM, Cyrill Gorcunov wrote:
> On 05/23/2011 09:43 PM, Randy Dunlap wrote:
>> From: Randy Dunlap <[email protected]>
>>
>> apic_flat_64.c needs to include module.h to fix these warnings:
>>
>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
>>
>> Signed-off-by: Randy Dunlap <[email protected]>
>> ---
>> arch/x86/kernel/apic/apic_flat_64.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
>> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
>> @@ -16,6 +16,7 @@
>> #include <linux/ctype.h>
>> #include <linux/init.h>
>> #include <linux/hardirq.h>
>> +#include <linux/module.h>
>> #include <asm/smp.h>
>> #include <asm/apic.h>
>> #include <asm/ipi.h>
>
> Thanks Randy! For some reason I didn't hit this problem while
> were compiling the kernel and testing it (I usually do not use
> modules though).
>
> I've CC'ed Ingo and Suresh.
>
Randy, while adding module.h here is correct I fail to see why I didn't
hit this problem before, could you please post your config?
--
Cyrill
On 05/23/11 11:09, Cyrill Gorcunov wrote:
> On 05/23/2011 09:51 PM, Cyrill Gorcunov wrote:
>> On 05/23/2011 09:43 PM, Randy Dunlap wrote:
>>> From: Randy Dunlap <[email protected]>
>>>
>>> apic_flat_64.c needs to include module.h to fix these warnings:
>>>
>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
>>>
>>> Signed-off-by: Randy Dunlap <[email protected]>
>>> ---
>>> arch/x86/kernel/apic/apic_flat_64.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
>>> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
>>> @@ -16,6 +16,7 @@
>>> #include <linux/ctype.h>
>>> #include <linux/init.h>
>>> #include <linux/hardirq.h>
>>> +#include <linux/module.h>
>>> #include <asm/smp.h>
>>> #include <asm/apic.h>
>>> #include <asm/ipi.h>
>>
>> Thanks Randy! For some reason I didn't hit this problem while
>> were compiling the kernel and testing it (I usually do not use
>> modules though).
>>
>> I've CC'ed Ingo and Suresh.
>>
>
> Randy, while adding module.h here is correct I fail to see why I didn't
> hit this problem before, could you please post your config?
Certainly, it's attached. It's a randconfig file.
I saw this build error on roughly 5 out of 15 randconfig builds.
CONFIG_SMP is disabled...
Thanks.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 05/23/2011 10:12 PM, Randy Dunlap wrote:
> On 05/23/11 11:09, Cyrill Gorcunov wrote:
>> On 05/23/2011 09:51 PM, Cyrill Gorcunov wrote:
>>> On 05/23/2011 09:43 PM, Randy Dunlap wrote:
>>>> From: Randy Dunlap <[email protected]>
>>>>
>>>> apic_flat_64.c needs to include module.h to fix these warnings:
>>>>
>>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
>>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
>>>> arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
>>>>
>>>> Signed-off-by: Randy Dunlap <[email protected]>
>>>> ---
>>>> arch/x86/kernel/apic/apic_flat_64.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
>>>> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
>>>> @@ -16,6 +16,7 @@
>>>> #include <linux/ctype.h>
>>>> #include <linux/init.h>
>>>> #include <linux/hardirq.h>
>>>> +#include <linux/module.h>
>>>> #include <asm/smp.h>
>>>> #include <asm/apic.h>
>>>> #include <asm/ipi.h>
>>>
>>> Thanks Randy! For some reason I didn't hit this problem while
>>> were compiling the kernel and testing it (I usually do not use
>>> modules though).
>>>
>>> I've CC'ed Ingo and Suresh.
>>>
>>
>> Randy, while adding module.h here is correct I fail to see why I didn't
>> hit this problem before, could you please post your config?
>
> Certainly, it's attached. It's a randconfig file.
> I saw this build error on roughly 5 out of 15 randconfig builds.
>
> CONFIG_SMP is disabled...
>
>
> Thanks.
>
>
CONFIG_SMP seems to be the point, unweaving headers deps backward is not
that convenient task, probably there is kinda automation tools exist? I
have a gut feeling I saw something but can't remember where exactly ;)
--
Cyrill
From: Randy Dunlap <[email protected]>
Fix printk format warning:
drivers/target/tcm_fc/tfc_io.c:209: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'size_t'
Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/target/tcm_fc/tfc_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
and please put an entry in the MAINTAINERS file for drivers/target/
--- linux-next-20110523.orig/drivers/target/tcm_fc/tfc_io.c
+++ linux-next-20110523/drivers/target/tcm_fc/tfc_io.c
@@ -203,7 +203,7 @@ int ft_queue_data_in(struct se_cmd *se_c
/* XXX For now, initiator will retry */
if (printk_ratelimit())
printk(KERN_ERR "%s: Failed to send frame %p, "
- "xid <0x%x>, remaining <0x%x>, "
+ "xid <0x%x>, remaining <0x%zx>, "
"lso_max <0x%x>\n",
__func__, fp, ep->xid,
remaining, lport->lso_max);
From: Randy Dunlap <[email protected]>
Fix build warnings in physmap.h:
include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
Signed-off-by: Randy Dunlap <[email protected]>
---
include/linux/mtd/physmap.h | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20110523.orig/include/linux/mtd/physmap.h
+++ linux-next-20110523/include/linux/mtd/physmap.h
@@ -19,6 +19,7 @@
#include <linux/mtd/partitions.h>
struct map_info;
+struct platform_device;
struct physmap_flash_data {
unsigned int width;
* Randy Dunlap <[email protected]> wrote:
> >>> arch/x86/kernel/apic/apic_flat_64.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
> >>> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
> >>> @@ -16,6 +16,7 @@
> >>> #include <linux/ctype.h>
> >>> #include <linux/init.h>
> >>> #include <linux/hardirq.h>
> >>> +#include <linux/module.h>
> >>> #include <asm/smp.h>
> >>> #include <asm/apic.h>
> >>> #include <asm/ipi.h>
> >>
> >> Thanks Randy! For some reason I didn't hit this problem while
> >> were compiling the kernel and testing it (I usually do not use
> >> modules though).
> >>
> >> I've CC'ed Ingo and Suresh.
> >>
> >
> > Randy, while adding module.h here is correct I fail to see why I didn't
> > hit this problem before, could you please post your config?
>
> Certainly, it's attached. It's a randconfig file.
> I saw this build error on roughly 5 out of 15 randconfig builds.
>
> CONFIG_SMP is disabled...
Your config builds just fine here, using latest -tip:
tip/master 726281b: Merge branch 'tools/kvm'
Kernel: arch/x86/boot/bzImage is ready (#2)
or using x86/apic directly:
tip/x86/apic 1a8880a: x86, apic: Make apic drivers static
System is 3001 kB
CRC 882c2d5c
Kernel: arch/x86/boot/bzImage is ready (#3)
Has linux-next changed something that triggers this build bug?
Thanks,
Ingo
* Ingo Molnar <[email protected]> wrote:
>
> * Randy Dunlap <[email protected]> wrote:
>
> > >>> arch/x86/kernel/apic/apic_flat_64.c | 1 +
> > >>> 1 file changed, 1 insertion(+)
> > >>>
> > >>> --- linux-next-20110523.orig/arch/x86/kernel/apic/apic_flat_64.c
> > >>> +++ linux-next-20110523/arch/x86/kernel/apic/apic_flat_64.c
> > >>> @@ -16,6 +16,7 @@
> > >>> #include <linux/ctype.h>
> > >>> #include <linux/init.h>
> > >>> #include <linux/hardirq.h>
> > >>> +#include <linux/module.h>
> > >>> #include <asm/smp.h>
> > >>> #include <asm/apic.h>
> > >>> #include <asm/ipi.h>
> > >>
> > >> Thanks Randy! For some reason I didn't hit this problem while
> > >> were compiling the kernel and testing it (I usually do not use
> > >> modules though).
> > >>
> > >> I've CC'ed Ingo and Suresh.
> > >>
> > >
> > > Randy, while adding module.h here is correct I fail to see why I didn't
> > > hit this problem before, could you please post your config?
> >
> > Certainly, it's attached. It's a randconfig file.
> > I saw this build error on roughly 5 out of 15 randconfig builds.
> >
> > CONFIG_SMP is disabled...
>
> Your config builds just fine here, using latest -tip:
oh, stupid me, it's a warning, not a build failure.
Applied your fix, thanks Randy!
Ingo
Commit-ID: b18bf0948e1037e7ed33378c80f1ecb8c77c30e9
Gitweb: http://git.kernel.org/tip/b18bf0948e1037e7ed33378c80f1ecb8c77c30e9
Author: Randy Dunlap <[email protected]>
AuthorDate: Mon, 23 May 2011 10:43:00 -0700
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 23 May 2011 21:27:35 +0200
x86, apic: Include module.h header in apic_flat_64.c
apic_flat_64.c needs to include module.h because it uses
EXPORT_SYMBOL_GPL().
This fixes these warnings on some !SMP randconfigs:
arch/x86/kernel/apic/apic_flat_64.c:31: warning: data definition has no type or storage class
arch/x86/kernel/apic/apic_flat_64.c:31: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/x86/kernel/apic/apic_flat_64.c:31: warning: parameter names (without types) in function declaration
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/apic/apic_flat_64.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/apic/apic_flat_64.c b/arch/x86/kernel/apic/apic_flat_64.c
index 9570ee5..f7a41e4 100644
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -16,6 +16,7 @@
#include <linux/ctype.h>
#include <linux/init.h>
#include <linux/hardirq.h>
+#include <linux/module.h>
#include <asm/smp.h>
#include <asm/apic.h>
#include <asm/ipi.h>
On Mon, 2011-05-23 at 11:35 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Fix printk format warning:
>
> drivers/target/tcm_fc/tfc_io.c:209: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'size_t'
>
> Signed-off-by: Randy Dunlap <[email protected]>
> ---
Hey Randy,
Kiran (CC'ed) was going to include this along with a bugfix patch for
scsi-misc, but it's probably easier to just change this in linux-next
now..
Signed-off-by: Nicholas A. Bellinger <[email protected]>
> drivers/target/tcm_fc/tfc_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> and please put an entry in the MAINTAINERS file for drivers/target/
>
<nod>, sending out that patch shortly.
Thanks,
--nab
>
> --- linux-next-20110523.orig/drivers/target/tcm_fc/tfc_io.c
> +++ linux-next-20110523/drivers/target/tcm_fc/tfc_io.c
> @@ -203,7 +203,7 @@ int ft_queue_data_in(struct se_cmd *se_c
> /* XXX For now, initiator will retry */
> if (printk_ratelimit())
> printk(KERN_ERR "%s: Failed to send frame %p, "
> - "xid <0x%x>, remaining <0x%x>, "
> + "xid <0x%x>, remaining <0x%zx>, "
> "lso_max <0x%x>\n",
> __func__, fp, ep->xid,
> remaining, lport->lso_max);
On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110520:
when CONFIG_GPIOLIB is not enabled
and CONFIG_GENERIC_GPIO is not enabled:
sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
sound/soc/codecs/wm8915.c:2857: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Mon, May 23, 2011 at 01:48:15PM -0700, Randy Dunlap wrote:
> On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
> when CONFIG_GPIOLIB is not enabled
> and CONFIG_GENERIC_GPIO is not enabled:
> sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
> sound/soc/codecs/wm8915.c:2857: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
What architecture is this on (you should always include information like
this anyway so people can try to reproduce what you're seeing)? In any
case, please talk to the architecture maintainers about this - it's an
issue in the architecture GPIO support (or lack thereof) rather than a
driver problem.
Also adding Dmitry who submitted the driver - Randy, please try to
remember to CC relevant people.
On Tue, 24 May 2011 06:47:28 +0800 Mark Brown wrote:
> On Mon, May 23, 2011 at 01:48:15PM -0700, Randy Dunlap wrote:
> > On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
>
> > when CONFIG_GPIOLIB is not enabled
> > and CONFIG_GENERIC_GPIO is not enabled:
>
> > sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
> > sound/soc/codecs/wm8915.c:2857: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
>
> What architecture is this on (you should always include information like
> this anyway so people can try to reproduce what you're seeing)? In any
on x86_64 [adding [email protected] == arch maintainers]
> case, please talk to the architecture maintainers about this - it's an
> issue in the architecture GPIO support (or lack thereof) rather than a
> driver problem.
except that a driver should not assume that defines like
GPIOF_OUT_INIT_LOW are always available.
> Also adding Dmitry who submitted the driver - Randy, please try to
> remember to CC relevant people.
Which driver did Dmitry submit? how would I know that?
I don't download every linux-next git tree -- just linux-next tarballs.
ak4641.c says:
MODULE_AUTHOR("Harald Welte <[email protected]>");
[which bounces]
and wm8915.c says:
MODULE_AUTHOR("Mark Brown <[email protected]>");
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Mon, May 23, 2011 at 03:53:43PM -0700, Randy Dunlap wrote:
> On Tue, 24 May 2011 06:47:28 +0800 Mark Brown wrote:
> > case, please talk to the architecture maintainers about this - it's an
> > issue in the architecture GPIO support (or lack thereof) rather than a
> > driver problem.
> except that a driver should not assume that defines like
> GPIOF_OUT_INIT_LOW are always available.
No, really we should. The GPIO APIs are stubbed out when not in use for
a very good reason, think about the usability here. The goal here isn't
to litter the code with ifdefs - if architectures aren't able to keep up
with API changes they should convert to using gpiolib so this stuff
happens automatically (indeed, I can't think of any good reason for an
architecture to not be using gpiolib at this point).
> > Also adding Dmitry who submitted the driver - Randy, please try to
> > remember to CC relevant people.
> Which driver did Dmitry submit? how would I know that?
> I don't download every linux-next git tree -- just linux-next tarballs.
I *strongly* suggest looking at git if you want to find relevant people
to mail; the internal documentation in the code really isn't a terribly
useful guide, the authors listed in the code often bear no relation to
who's actually working on it at the current time.
> and wm8915.c says:
> MODULE_AUTHOR("Mark Brown <[email protected]>");
You've clearly not looked at MAINTAINERS for this one.
On 05/23/11 17:08, Mark Brown wrote:
> On Mon, May 23, 2011 at 03:53:43PM -0700, Randy Dunlap wrote:
>> On Tue, 24 May 2011 06:47:28 +0800 Mark Brown wrote:
>
>>> case, please talk to the architecture maintainers about this - it's an
>>> issue in the architecture GPIO support (or lack thereof) rather than a
>>> driver problem.
>
>> except that a driver should not assume that defines like
>> GPIOF_OUT_INIT_LOW are always available.
>
> No, really we should. The GPIO APIs are stubbed out when not in use for
> a very good reason, think about the usability here. The goal here isn't
> to litter the code with ifdefs - if architectures aren't able to keep up
> with API changes they should convert to using gpiolib so this stuff
> happens automatically (indeed, I can't think of any good reason for an
> architecture to not be using gpiolib at this point).
No, I would say that there are a lot of drivers in sound/soc/codecs/
that are missing some GPIO pieces in the Kconfig file.
>>> Also adding Dmitry who submitted the driver - Randy, please try to
>>> remember to CC relevant people.
>
>> Which driver did Dmitry submit? how would I know that?
>> I don't download every linux-next git tree -- just linux-next tarballs.
>
> I *strongly* suggest looking at git if you want to find relevant people
> to mail; the internal documentation in the code really isn't a terribly
> useful guide, the authors listed in the code often bear no relation to
> who's actually working on it at the current time.
>
>> and wm8915.c says:
>> MODULE_AUTHOR("Mark Brown <[email protected]>");
>
> You've clearly not looked at MAINTAINERS for this one.
It's not listed in the MAINTAINERS file.
But maybe you mean scripts/get_maintainer.pl, which I did try.
I found that using git log <that source file name> was better info
than using scripts/get_maintainer.pl.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Mon, May 23, 2011 at 06:21:51PM -0700, Randy Dunlap wrote:
> On 05/23/11 17:08, Mark Brown wrote:
> > No, really we should. The GPIO APIs are stubbed out when not in use for
> > a very good reason, think about the usability here. The goal here isn't
> > to litter the code with ifdefs - if architectures aren't able to keep up
> > with API changes they should convert to using gpiolib so this stuff
> > happens automatically (indeed, I can't think of any good reason for an
> > architecture to not be using gpiolib at this point).
> No, I would say that there are a lot of drivers in sound/soc/codecs/
> that are missing some GPIO pieces in the Kconfig file.
Have you actually looked at the code here? Vanishingly few of the
drivers need GPIOs at all, they can just optionally use GPIOs if the
system makes them available. There is absolutely no dependency on GPIOs
for them, anything in Kconfig would be entirely unconstructive.
> >> MODULE_AUTHOR("Mark Brown <[email protected]>");
> > You've clearly not looked at MAINTAINERS for this one.
> It's not listed in the MAINTAINERS file.
MAINTAINERS has a pattern sound/soc/codecs/wm*.
> But maybe you mean scripts/get_maintainer.pl, which I did try.
> I found that using git log <that source file name> was better info
> than using scripts/get_maintainer.pl.
get_maintainers is just a script that reads MAINTAINERS and trawls logs
for it; the reason I mentioned MAINTAINERs was that you were saying you
didn't use git. In general you're better off doing things by hand
rather than using get_maintainers.
On 05/23/11 18:50, Mark Brown wrote:
> On Mon, May 23, 2011 at 06:21:51PM -0700, Randy Dunlap wrote:
>> On 05/23/11 17:08, Mark Brown wrote:
>
>>> No, really we should. The GPIO APIs are stubbed out when not in use for
>>> a very good reason, think about the usability here. The goal here isn't
>>> to litter the code with ifdefs - if architectures aren't able to keep up
>>> with API changes they should convert to using gpiolib so this stuff
>>> happens automatically (indeed, I can't think of any good reason for an
>>> architecture to not be using gpiolib at this point).
>
>> No, I would say that there are a lot of drivers in sound/soc/codecs/
>> that are missing some GPIO pieces in the Kconfig file.
>
> Have you actually looked at the code here? Vanishingly few of the
> drivers need GPIOs at all, they can just optionally use GPIOs if the
> system makes them available. There is absolutely no dependency on GPIOs
> for them, anything in Kconfig would be entirely unconstructive.
>
>>>> MODULE_AUTHOR("Mark Brown <[email protected]>");
>
>>> You've clearly not looked at MAINTAINERS for this one.
>
>> It's not listed in the MAINTAINERS file.
>
> MAINTAINERS has a pattern sound/soc/codecs/wm*.
Thanks for that hint.
>> But maybe you mean scripts/get_maintainer.pl, which I did try.
>> I found that using git log <that source file name> was better info
>> than using scripts/get_maintainer.pl.
>
> get_maintainers is just a script that reads MAINTAINERS and trawls logs
> for it; the reason I mentioned MAINTAINERs was that you were saying you
> didn't use git. In general you're better off doing things by hand
> rather than using get_maintainers.
Yes.
OK, I didn't mean to get into a blame game on this.
You mentioned stubs earlier and that's what is not working AFAICT.
Below is a patch that makes the 2 reported drivers build when
CONFIG_GPIOLIB is disabled and CONFIG_GENERIC_GPIO is disabled.
What do you think of the patch?
---
From: Randy Dunlap <[email protected]>
Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
is enabled by moving them to <linux/gpio.h>.
Signed-off-by: Randy Dunlap <[email protected]>
---
include/asm-generic/gpio.h | 10 ----------
include/linux/gpio.h | 11 +++++++++++
2 files changed, 11 insertions(+), 10 deletions(-)
--- linux-next-20110523.orig/include/asm-generic/gpio.h
+++ linux-next-20110523/include/asm-generic/gpio.h
@@ -170,16 +170,6 @@ extern int __gpio_cansleep(unsigned gpio
extern int __gpio_to_irq(unsigned gpio);
-#define GPIOF_DIR_OUT (0 << 0)
-#define GPIOF_DIR_IN (1 << 0)
-
-#define GPIOF_INIT_LOW (0 << 1)
-#define GPIOF_INIT_HIGH (1 << 1)
-
-#define GPIOF_IN (GPIOF_DIR_IN)
-#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
-#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
-
/**
* struct gpio - a structure describing a GPIO with configuration
* @gpio: the GPIO number
--- linux-next-20110523.orig/include/linux/gpio.h
+++ linux-next-20110523/include/linux/gpio.h
@@ -3,6 +3,17 @@
/* see Documentation/gpio.txt */
+/* make these flag values available regardless of GPIO kconfig options */
+#define GPIOF_DIR_OUT (0 << 0)
+#define GPIOF_DIR_IN (1 << 0)
+
+#define GPIOF_INIT_LOW (0 << 1)
+#define GPIOF_INIT_HIGH (1 << 1)
+
+#define GPIOF_IN (GPIOF_DIR_IN)
+#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
+#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
+
#ifdef CONFIG_GENERIC_GPIO
#include <asm/gpio.h>
On 21:58 Mon 23 May , Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
> is enabled by moving them to <linux/gpio.h>.
>
> Signed-off-by: Randy Dunlap <[email protected]>
Looks good.
We probably may also want to move definition of struct gpio into
include/linux/gpio.h to make things like this work as well:
static struct gpio some_gpios[] = {
{ GPIO_BLAH, GPIOF_IN, "BLAH"},
{ GPIO_BLAH2, GPIOF_OUT_INIT_LOW, "BLAH2"},
};
static int some_init_function(void)
{
/* ... */
gpio_request_array(some_gpios, ARRAY_SIZE(some_gpios));
/* ... */
}
These gpio_request_one() and gpio_request_array() are quite handy, so I
suppose more and more drivers will use it as we go...
--
Best regards,
Dmitry "MAD" Artamonow
On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Fix build warnings in physmap.h:
>
> include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
>
> Signed-off-by: Randy Dunlap <[email protected]>
Oh, this was missed during review. This was introduced in
b7281ca2a4b00044c60c25059f467d05772cdbe3 which is going in via Russel's
tree, so I guess Russel could pick up your patch.
CCed relevant people.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
On Tue, 2011-05-24 at 08:53 +0300, Artem Bityutskiy wrote:
> On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <[email protected]>
> >
> > Fix build warnings in physmap.h:
> >
> > include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> > include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> > include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
> >
> > Signed-off-by: Randy Dunlap <[email protected]>
>
> Oh, this was missed during review. This was introduced in
> b7281ca2a4b00044c60c25059f467d05772cdbe3 which is going in via Russel's
> tree, so I guess Russel could pick up your patch.
My big apologies, s/Russel/Russell/.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
On Tue, May 24, 2011 at 08:58:03AM +0300, Artem Bityutskiy wrote:
> On Tue, 2011-05-24 at 08:53 +0300, Artem Bityutskiy wrote:
> > On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> > > From: Randy Dunlap <[email protected]>
> > >
> > > Fix build warnings in physmap.h:
> > >
> > > include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> > > include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> > > include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> > > include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
> > >
> > > Signed-off-by: Randy Dunlap <[email protected]>
> >
> > Oh, this was missed during review. This was introduced in
> > b7281ca2a4b00044c60c25059f467d05772cdbe3 which is going in via Russel's
> > tree, so I guess Russel could pick up your patch.
>
> My big apologies, s/Russel/Russell/.
Which patch? Neither of these messages contained Randy's patch and I
wasn't included on the original posting.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, 2011-05-24 at 08:40 +0100, Russell King wrote:
> On Tue, May 24, 2011 at 08:58:03AM +0300, Artem Bityutskiy wrote:
> > On Tue, 2011-05-24 at 08:53 +0300, Artem Bityutskiy wrote:
> > > On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> > > > From: Randy Dunlap <[email protected]>
> > > >
> > > > Fix build warnings in physmap.h:
> > > >
> > > > include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> > > > include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> > > > include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> > > > include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
> > > >
> > > > Signed-off-by: Randy Dunlap <[email protected]>
> > >
> > > Oh, this was missed during review. This was introduced in
> > > b7281ca2a4b00044c60c25059f467d05772cdbe3 which is going in via Russel's
> > > tree, so I guess Russel could pick up your patch.
> >
> > My big apologies, s/Russel/Russell/.
>
> Which patch? Neither of these messages contained Randy's patch and I
> wasn't included on the original posting.
Sorry, I assumed you'd look that lkml is in CC and would find it in lkml
(I assumed you are subscribed there). I'll send this patch shortly.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
From: Randy Dunlap <[email protected]>
Subject: [PATCH] mtd: fix physmap.h warnings
Fix build warnings in physmap.h:
include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
---
include/linux/mtd/physmap.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/mtd/physmap.h b/include/linux/mtd/physmap.h
index 49b9590..697cc98 100644
--- a/include/linux/mtd/physmap.h
+++ b/include/linux/mtd/physmap.h
@@ -19,6 +19,7 @@
#include <linux/mtd/partitions.h>
struct map_info;
+struct platform_device;
struct physmap_flash_data {
unsigned int width;
--
1.7.2.3
From: Randy Dunlap <[email protected]>
Subject: [PATCH] mtd: fix physmap.h warnings
Fix build warnings in physmap.h:
include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
---
include/linux/mtd/physmap.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/mtd/physmap.h b/include/linux/mtd/physmap.h
index 49b9590..697cc98 100644
--- a/include/linux/mtd/physmap.h
+++ b/include/linux/mtd/physmap.h
@@ -19,6 +19,7 @@
#include <linux/mtd/partitions.h>
struct map_info;
+struct platform_device;
struct physmap_flash_data {
unsigned int width;
--
1.7.2.3
On Mon, May 23, 2011 at 09:58:39PM -0700, Randy Dunlap wrote:
> Below is a patch that makes the 2 reported drivers build when
> CONFIG_GPIOLIB is disabled and CONFIG_GENERIC_GPIO is disabled.
> What do you think of the patch?
Looks OK for me on a first scan, though probably the best approach is to
go through and just enable gpiolib on all the architectures that don't
have it already yet - that's the more generally useful approach as it
means that if plugin boards for the platform need to use gpiolib they
can. I already did this for Alpha, I guess I'll try to look see what
other architectures could use it.
On Tue, 24 May 2011 09:23:42 +0400 Dmitry Artamonow wrote:
> On 21:58 Mon 23 May , Randy Dunlap wrote:
> > From: Randy Dunlap <[email protected]>
> >
> > Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
> > is enabled by moving them to <linux/gpio.h>.
> >
> > Signed-off-by: Randy Dunlap <[email protected]>
>
> Looks good.
>
> We probably may also want to move definition of struct gpio into
> include/linux/gpio.h to make things like this work as well:
>
> static struct gpio some_gpios[] = {
> { GPIO_BLAH, GPIOF_IN, "BLAH"},
> { GPIO_BLAH2, GPIOF_OUT_INIT_LOW, "BLAH2"},
> };
>
> static int some_init_function(void)
> {
> /* ... */
>
> gpio_request_array(some_gpios, ARRAY_SIZE(some_gpios));
>
> /* ... */
> }
>
> These gpio_request_one() and gpio_request_array() are quite handy, so I
> suppose more and more drivers will use it as we go...
That could help this one:
linux-next-20110524/include/linux/mfd/tps65910.h:774: error: field 'gpio' has incomplete type
and then add some way to handle (e.g.):
struct tps65910 *tps65910 = container_of(gc, struct tps65910, gpio);
=>
linux-next-20110524/drivers/gpio/tps65910-gpio.c:25: warning: type defaults to 'int' in declaration of '__mptr'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, May 24, 2011 at 08:52:48AM +0100, Mark Brown wrote:
> On Mon, May 23, 2011 at 09:58:39PM -0700, Randy Dunlap wrote:
>
> > Below is a patch that makes the 2 reported drivers build when
> > CONFIG_GPIOLIB is disabled and CONFIG_GENERIC_GPIO is disabled.
> > What do you think of the patch?
>
> Looks OK for me on a first scan, though probably the best approach is to
> go through and just enable gpiolib on all the architectures that don't
> have it already yet - that's the more generally useful approach as it
> means that if plugin boards for the platform need to use gpiolib they
> can. I already did this for Alpha, I guess I'll try to look see what
> other architectures could use it.
Looks okay. Please repost with proper s-o-b so I can pick it up.
g.
From: Randy Dunlap <[email protected]>
Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
is enabled by moving them to <linux/gpio.h>.
Signed-off-by: Randy Dunlap <[email protected]>
---
include/asm-generic/gpio.h | 10 ----------
include/linux/gpio.h | 11 +++++++++++
2 files changed, 11 insertions(+), 10 deletions(-)
--- linux-next-20110523.orig/include/asm-generic/gpio.h
+++ linux-next-20110523/include/asm-generic/gpio.h
@@ -170,16 +170,6 @@ extern int __gpio_cansleep(unsigned gpio
extern int __gpio_to_irq(unsigned gpio);
-#define GPIOF_DIR_OUT (0 << 0)
-#define GPIOF_DIR_IN (1 << 0)
-
-#define GPIOF_INIT_LOW (0 << 1)
-#define GPIOF_INIT_HIGH (1 << 1)
-
-#define GPIOF_IN (GPIOF_DIR_IN)
-#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
-#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
-
/**
* struct gpio - a structure describing a GPIO with configuration
* @gpio: the GPIO number
--- linux-next-20110523.orig/include/linux/gpio.h
+++ linux-next-20110523/include/linux/gpio.h
@@ -3,6 +3,17 @@
/* see Documentation/gpio.txt */
+/* make these flag values available regardless of GPIO kconfig options */
+#define GPIOF_DIR_OUT (0 << 0)
+#define GPIOF_DIR_IN (1 << 0)
+
+#define GPIOF_INIT_LOW (0 << 1)
+#define GPIOF_INIT_HIGH (1 << 1)
+
+#define GPIOF_IN (GPIOF_DIR_IN)
+#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
+#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
+
#ifdef CONFIG_GENERIC_GPIO
#include <asm/gpio.h>
On Fri, May 27, 2011 at 10:46:57AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
> is enabled by moving them to <linux/gpio.h>.
>
> Signed-off-by: Randy Dunlap <[email protected]>
Applied, thanks.
g.
> ---
> include/asm-generic/gpio.h | 10 ----------
> include/linux/gpio.h | 11 +++++++++++
> 2 files changed, 11 insertions(+), 10 deletions(-)
>
> --- linux-next-20110523.orig/include/asm-generic/gpio.h
> +++ linux-next-20110523/include/asm-generic/gpio.h
> @@ -170,16 +170,6 @@ extern int __gpio_cansleep(unsigned gpio
>
> extern int __gpio_to_irq(unsigned gpio);
>
> -#define GPIOF_DIR_OUT (0 << 0)
> -#define GPIOF_DIR_IN (1 << 0)
> -
> -#define GPIOF_INIT_LOW (0 << 1)
> -#define GPIOF_INIT_HIGH (1 << 1)
> -
> -#define GPIOF_IN (GPIOF_DIR_IN)
> -#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
> -#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
> -
> /**
> * struct gpio - a structure describing a GPIO with configuration
> * @gpio: the GPIO number
> --- linux-next-20110523.orig/include/linux/gpio.h
> +++ linux-next-20110523/include/linux/gpio.h
> @@ -3,6 +3,17 @@
>
> /* see Documentation/gpio.txt */
>
> +/* make these flag values available regardless of GPIO kconfig options */
> +#define GPIOF_DIR_OUT (0 << 0)
> +#define GPIOF_DIR_IN (1 << 0)
> +
> +#define GPIOF_INIT_LOW (0 << 1)
> +#define GPIOF_INIT_HIGH (1 << 1)
> +
> +#define GPIOF_IN (GPIOF_DIR_IN)
> +#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
> +#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
> +
> #ifdef CONFIG_GENERIC_GPIO
> #include <asm/gpio.h>
>
On Tue, 2011-05-24 at 10:42 +0300, Artem Bityutskiy wrote:
> From: Randy Dunlap <[email protected]>
> Subject: [PATCH] mtd: fix physmap.h warnings
>
> Fix build warnings in physmap.h:
>
> include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Signed-off-by: Artem Bityutskiy <[email protected]>
David, it looks like Russel did not merge this patch and people
complain. Could you please merge it?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
On Wed, Jun 01, 2011 at 10:45:54AM +0300, Artem Bityutskiy wrote:
> On Tue, 2011-05-24 at 10:42 +0300, Artem Bityutskiy wrote:
> > From: Randy Dunlap <[email protected]>
> > Subject: [PATCH] mtd: fix physmap.h warnings
> >
> > Fix build warnings in physmap.h:
> >
> > include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
> > include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
> > include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
> >
> > Signed-off-by: Randy Dunlap <[email protected]>
> > Signed-off-by: Artem Bityutskiy <[email protected]>
>
> David, it looks like Russel did not merge this patch and people
^^
> complain. Could you please merge it?
Bah, it got lost in the depths of my mailboxes and forgotten...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Fri, May 27, 2011 at 2:12 PM, Grant Likely <[email protected]> wrote:
> On Fri, May 27, 2011 at 10:46:57AM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <[email protected]>
>>
>> Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
>> is enabled by moving them to <linux/gpio.h>.
>>
>> Signed-off-by: Randy Dunlap <[email protected]>
>
> Applied, thanks.
Hi Randy,
I ended up not pushing this one to Linus. Turns out it causes other
breakage on other platforms that don't include include/linux/gpio.h.
Since I don't have confidence that I'll be able to find all the
offenders, I'm dropping it. I recommend making any drivers that are
breaking on these symbols depend on GPIOLIB. Platforms not using
gpiolib are strongly discouraged now anyways, and there only a handful
of files in drivers/ that reference GPIOF_*.
g.
On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
> I ended up not pushing this one to Linus. Turns out it causes other
> breakage on other platforms that don't include include/linux/gpio.h.
> Since I don't have confidence that I'll be able to find all the
> offenders, I'm dropping it. I recommend making any drivers that are
So, this originally came about because I pushed back on adding random
dependencies like this for features which are pretty much optional in
drivers - their use of GPIOs is totally optional and the dependencies
are just too fragile, leading to noise with all the randconfigs. It
seems better to get the architectures to keep up with enhancements to
gpiolib (or convert to it) than to have to worry about this in drivers.
> breaking on these symbols depend on GPIOLIB. Platforms not using
> gpiolib are strongly discouraged now anyways, and there only a handful
> of files in drivers/ that reference GPIOF_*.
That's more a result of it being a pretty new feature than anything else
I think.
On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
<[email protected]> wrote:
> On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
>
>> I ended up not pushing this one to Linus. ?Turns out it causes other
>> breakage on other platforms that don't include include/linux/gpio.h.
>> Since I don't have confidence that I'll be able to find all the
>> offenders, I'm dropping it. ?I recommend making any drivers that are
>
> So, this originally came about because I pushed back on adding random
> dependencies like this for features which are pretty much optional in
> drivers - their use of GPIOs is totally optional and the dependencies
> are just too fragile, leading to noise with all the randconfigs. ?It
> seems better to get the architectures to keep up with enhancements to
> gpiolib (or convert to it) than to have to worry about this in drivers.
Fair enough. Randy, if you or someone else can check that all GPIOF_
users have the required #include <linux/gpio.h>, then I'm okay with
this patch.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On 06/03/11 10:42, Grant Likely wrote:
> On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> <[email protected]> wrote:
>> On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
>>
>>> I ended up not pushing this one to Linus. Turns out it causes other
>>> breakage on other platforms that don't include include/linux/gpio.h.
>>> Since I don't have confidence that I'll be able to find all the
>>> offenders, I'm dropping it. I recommend making any drivers that are
>>
>> So, this originally came about because I pushed back on adding random
>> dependencies like this for features which are pretty much optional in
>> drivers - their use of GPIOs is totally optional and the dependencies
>> are just too fragile, leading to noise with all the randconfigs. It
>> seems better to get the architectures to keep up with enhancements to
>> gpiolib (or convert to it) than to have to worry about this in drivers.
>
> Fair enough. Randy, if you or someone else can check that all GPIOF_
> users have the required #include <linux/gpio.h>, then I'm okay with
> this patch.
OK, I'll look at that.
Do you have any examples of builds that failed with this patch?
thanks,
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Sun, 05 Jun 2011 20:45:43 -0700 Randy Dunlap wrote:
> On 06/03/11 10:42, Grant Likely wrote:
> > On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> > <[email protected]> wrote:
> >> On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
> >>
> >>> I ended up not pushing this one to Linus. Turns out it causes other
> >>> breakage on other platforms that don't include include/linux/gpio.h.
> >>> Since I don't have confidence that I'll be able to find all the
> >>> offenders, I'm dropping it. I recommend making any drivers that are
> >>
> >> So, this originally came about because I pushed back on adding random
> >> dependencies like this for features which are pretty much optional in
> >> drivers - their use of GPIOs is totally optional and the dependencies
> >> are just too fragile, leading to noise with all the randconfigs. It
> >> seems better to get the architectures to keep up with enhancements to
> >> gpiolib (or convert to it) than to have to worry about this in drivers.
> >
> > Fair enough. Randy, if you or someone else can check that all GPIOF_
> > users have the required #include <linux/gpio.h>, then I'm okay with
> > this patch.
>
> OK, I'll look at that.
Of the 70 files that use GPIOF_ macros:
hdr missing in: ./arch/arm/mach-pxa/spitz_pm.c
hdr missing in: ./arch/avr32/mach-at32ap/pio.c
hdr missing in: ./arch/avr32/mach-at32ap/include/mach/portmux.h
hdr missing in: ./arch/avr32/boards/hammerhead/setup.c
hdr missing in: ./arch/avr32/boards/hammerhead/flash.c
hdr missing in: ./arch/avr32/boards/mimc200/setup.c
hdr missing in: ./arch/avr32/boards/atstk1000/setup.c
hdr missing in: ./drivers/pcmcia/pxa2xx_vpac270.c
> Do you have any examples of builds that failed with this patch?
and would you merge patch(es) that add this header file to those source
files? If not, I'll need to make 3 separate patches for them.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, Jun 14, 2011 at 09:12:11AM -0700, Randy Dunlap wrote:
> On Sun, 05 Jun 2011 20:45:43 -0700 Randy Dunlap wrote:
>
> > On 06/03/11 10:42, Grant Likely wrote:
> > > On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> > > <[email protected]> wrote:
> > >> On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
> > >>
> > >>> I ended up not pushing this one to Linus. Turns out it causes other
> > >>> breakage on other platforms that don't include include/linux/gpio.h.
> > >>> Since I don't have confidence that I'll be able to find all the
> > >>> offenders, I'm dropping it. I recommend making any drivers that are
> > >>
> > >> So, this originally came about because I pushed back on adding random
> > >> dependencies like this for features which are pretty much optional in
> > >> drivers - their use of GPIOs is totally optional and the dependencies
> > >> are just too fragile, leading to noise with all the randconfigs. It
> > >> seems better to get the architectures to keep up with enhancements to
> > >> gpiolib (or convert to it) than to have to worry about this in drivers.
> > >
> > > Fair enough. Randy, if you or someone else can check that all GPIOF_
> > > users have the required #include <linux/gpio.h>, then I'm okay with
> > > this patch.
> >
> > OK, I'll look at that.
>
> Of the 70 files that use GPIOF_ macros:
>
> hdr missing in: ./arch/arm/mach-pxa/spitz_pm.c
> hdr missing in: ./arch/avr32/mach-at32ap/pio.c
> hdr missing in: ./arch/avr32/mach-at32ap/include/mach/portmux.h
> hdr missing in: ./arch/avr32/boards/hammerhead/setup.c
> hdr missing in: ./arch/avr32/boards/hammerhead/flash.c
> hdr missing in: ./arch/avr32/boards/mimc200/setup.c
> hdr missing in: ./arch/avr32/boards/atstk1000/setup.c
> hdr missing in: ./drivers/pcmcia/pxa2xx_vpac270.c
>
>
> > Do you have any examples of builds that failed with this patch?
>
> and would you merge patch(es) that add this header file to those source
> files? If not, I'll need to make 3 separate patches for them.
Yes I would. I'm fine with it all being one patch.
g.
On Tue, 14 Jun 2011 10:13:57 -0600 Grant Likely wrote:
> On Tue, Jun 14, 2011 at 09:12:11AM -0700, Randy Dunlap wrote:
> > On Sun, 05 Jun 2011 20:45:43 -0700 Randy Dunlap wrote:
> >
> > > On 06/03/11 10:42, Grant Likely wrote:
> > > > On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> > > > <[email protected]> wrote:
> > > >> On Fri, Jun 03, 2011 at 11:04:52AM -0600, Grant Likely wrote:
> > > >>
> > > >>> I ended up not pushing this one to Linus. Turns out it causes other
> > > >>> breakage on other platforms that don't include include/linux/gpio.h.
> > > >>> Since I don't have confidence that I'll be able to find all the
> > > >>> offenders, I'm dropping it. I recommend making any drivers that are
> > > >>
> > > >> So, this originally came about because I pushed back on adding random
> > > >> dependencies like this for features which are pretty much optional in
> > > >> drivers - their use of GPIOs is totally optional and the dependencies
> > > >> are just too fragile, leading to noise with all the randconfigs. It
> > > >> seems better to get the architectures to keep up with enhancements to
> > > >> gpiolib (or convert to it) than to have to worry about this in drivers.
> > > >
> > > > Fair enough. Randy, if you or someone else can check that all GPIOF_
> > > > users have the required #include <linux/gpio.h>, then I'm okay with
> > > > this patch.
> > >
> > > OK, I'll look at that.
> >
> > Of the 70 files that use GPIOF_ macros:
> >
> > hdr missing in: ./arch/arm/mach-pxa/spitz_pm.c
> > hdr missing in: ./arch/avr32/mach-at32ap/pio.c
> > hdr missing in: ./arch/avr32/mach-at32ap/include/mach/portmux.h
> > hdr missing in: ./arch/avr32/boards/hammerhead/setup.c
> > hdr missing in: ./arch/avr32/boards/hammerhead/flash.c
> > hdr missing in: ./arch/avr32/boards/mimc200/setup.c
> > hdr missing in: ./arch/avr32/boards/atstk1000/setup.c
> > hdr missing in: ./drivers/pcmcia/pxa2xx_vpac270.c
> >
> >
> > > Do you have any examples of builds that failed with this patch?
> >
> > and would you merge patch(es) that add this header file to those source
> > files? If not, I'll need to make 3 separate patches for them.
That list of files above is incorrect. Bad grep pattern.
Drop all of the avr32 files. Ending patch is small -- sending it soon.
> Yes I would. I'm fine with it all being one patch.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Randy Dunlap <[email protected]>
Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
is enabled by moving them to <linux/gpio.h>.
Fixes these build errors in linux-next:
sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
Signed-off-by: Randy Dunlap <[email protected]>
---
include/asm-generic/gpio.h | 10 ----------
include/linux/gpio.h | 11 +++++++++++
2 files changed, 11 insertions(+), 10 deletions(-)
--- linux-next-20110614.orig/include/asm-generic/gpio.h
+++ linux-next-20110614/include/asm-generic/gpio.h
@@ -170,16 +170,6 @@ extern int __gpio_cansleep(unsigned gpio
extern int __gpio_to_irq(unsigned gpio);
-#define GPIOF_DIR_OUT (0 << 0)
-#define GPIOF_DIR_IN (1 << 0)
-
-#define GPIOF_INIT_LOW (0 << 1)
-#define GPIOF_INIT_HIGH (1 << 1)
-
-#define GPIOF_IN (GPIOF_DIR_IN)
-#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
-#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
-
/**
* struct gpio - a structure describing a GPIO with configuration
* @gpio: the GPIO number
--- linux-next-20110614.orig/include/linux/gpio.h
+++ linux-next-20110614/include/linux/gpio.h
@@ -3,6 +3,17 @@
/* see Documentation/gpio.txt */
+/* make these flag values available regardless of GPIO kconfig options */
+#define GPIOF_DIR_OUT (0 << 0)
+#define GPIOF_DIR_IN (1 << 0)
+
+#define GPIOF_INIT_LOW (0 << 1)
+#define GPIOF_INIT_HIGH (1 << 1)
+
+#define GPIOF_IN (GPIOF_DIR_IN)
+#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
+#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
+
#ifdef CONFIG_GENERIC_GPIO
#include <asm/gpio.h>
From: Randy Dunlap <[email protected]>
Some files use GPIOF_ macros but don't include the header file
for them. These macros are being moved to <linux/gpio.h>, so add
includes for <linux/gpio.h> where needed.
Signed-off-by: Randy Dunlap <[email protected]>
---
arch/arm/mach-pxa/spitz_pm.c | 1 +
drivers/pcmcia/pxa2xx_vpac270.c | 1 +
2 files changed, 2 insertions(+)
--- linux-next-20110614.orig/arch/arm/mach-pxa/spitz_pm.c
+++ linux-next-20110614/arch/arm/mach-pxa/spitz_pm.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/delay.h>
+#include <linux/gpio.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/apm-emulation.h>
--- linux-next-20110614.orig/drivers/pcmcia/pxa2xx_vpac270.c
+++ linux-next-20110614/drivers/pcmcia/pxa2xx_vpac270.c
@@ -11,6 +11,7 @@
*
*/
+#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/platform_device.h>
Hi Randy,
On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <[email protected]> wrote:
>
> From: Randy Dunlap <[email protected]>
>
> Some files use GPIOF_ macros but don't include the header file
> for them. These macros are being moved to <linux/gpio.h>, so add
> includes for <linux/gpio.h> where needed.
Shouldn't these patches be in the other order to avoid bisection problems?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On 06/14/11 17:34, Stephen Rothwell wrote:
> Hi Randy,
>
> On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <[email protected]> wrote:
>>
>> From: Randy Dunlap <[email protected]>
>>
>> Some files use GPIOF_ macros but don't include the header file
>> for them. These macros are being moved to <linux/gpio.h>, so add
>> includes for <linux/gpio.h> where needed.
>
> Shouldn't these patches be in the other order to avoid bisection problems?
Hm, I suppose so.
Grant, can you apply these with patch 2/2 first or do I need to resend
the patches?
thanks,
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Wed, Jun 15, 2011 at 11:59 AM, Randy Dunlap <[email protected]> wrote:
> On 06/14/11 17:34, Stephen Rothwell wrote:
>> Hi Randy,
>>
>> On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <[email protected]> wrote:
>>>
>>> From: Randy Dunlap <[email protected]>
>>>
>>> Some files use GPIOF_ macros but don't include the header file
>>> for them. ?These macros are being moved to <linux/gpio.h>, so add
>>> includes for <linux/gpio.h> where needed.
>>
>> Shouldn't these patches be in the other order to avoid bisection problems?
>
> Hm, I suppose so.
>
> Grant, can you apply these with patch 2/2 first or do I need to resend
> the patches?
You don't need to resend. I'll apply them in the correct order.
g.
On Tue, Jun 14, 2011 at 05:06:02PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Some files use GPIOF_ macros but don't include the header file
> for them. These macros are being moved to <linux/gpio.h>, so add
> includes for <linux/gpio.h> where needed.
>
> Signed-off-by: Randy Dunlap <[email protected]>
Applied, thanks.
g.
> ---
> arch/arm/mach-pxa/spitz_pm.c | 1 +
> drivers/pcmcia/pxa2xx_vpac270.c | 1 +
> 2 files changed, 2 insertions(+)
>
> --- linux-next-20110614.orig/arch/arm/mach-pxa/spitz_pm.c
> +++ linux-next-20110614/arch/arm/mach-pxa/spitz_pm.c
> @@ -14,6 +14,7 @@
> #include <linux/init.h>
> #include <linux/kernel.h>
> #include <linux/delay.h>
> +#include <linux/gpio.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> #include <linux/apm-emulation.h>
> --- linux-next-20110614.orig/drivers/pcmcia/pxa2xx_vpac270.c
> +++ linux-next-20110614/drivers/pcmcia/pxa2xx_vpac270.c
> @@ -11,6 +11,7 @@
> *
> */
>
> +#include <linux/gpio.h>
> #include <linux/module.h>
> #include <linux/platform_device.h>
>
On Tue, Jun 14, 2011 at 05:05:11PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
> is enabled by moving them to <linux/gpio.h>.
>
> Fixes these build errors in linux-next:
> sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
> sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
>
> Signed-off-by: Randy Dunlap <[email protected]>
Applied, thanks.
g.
> ---
> include/asm-generic/gpio.h | 10 ----------
> include/linux/gpio.h | 11 +++++++++++
> 2 files changed, 11 insertions(+), 10 deletions(-)
>
> --- linux-next-20110614.orig/include/asm-generic/gpio.h
> +++ linux-next-20110614/include/asm-generic/gpio.h
> @@ -170,16 +170,6 @@ extern int __gpio_cansleep(unsigned gpio
>
> extern int __gpio_to_irq(unsigned gpio);
>
> -#define GPIOF_DIR_OUT (0 << 0)
> -#define GPIOF_DIR_IN (1 << 0)
> -
> -#define GPIOF_INIT_LOW (0 << 1)
> -#define GPIOF_INIT_HIGH (1 << 1)
> -
> -#define GPIOF_IN (GPIOF_DIR_IN)
> -#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
> -#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
> -
> /**
> * struct gpio - a structure describing a GPIO with configuration
> * @gpio: the GPIO number
> --- linux-next-20110614.orig/include/linux/gpio.h
> +++ linux-next-20110614/include/linux/gpio.h
> @@ -3,6 +3,17 @@
>
> /* see Documentation/gpio.txt */
>
> +/* make these flag values available regardless of GPIO kconfig options */
> +#define GPIOF_DIR_OUT (0 << 0)
> +#define GPIOF_DIR_IN (1 << 0)
> +
> +#define GPIOF_INIT_LOW (0 << 1)
> +#define GPIOF_INIT_HIGH (1 << 1)
> +
> +#define GPIOF_IN (GPIOF_DIR_IN)
> +#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
> +#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
> +
> #ifdef CONFIG_GENERIC_GPIO
> #include <asm/gpio.h>
>
On Mon, 23 May 2011 13:47:24 -0700 Nicholas A. Bellinger wrote:
> On Mon, 2011-05-23 at 11:35 -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <[email protected]>
> >
> > Fix printk format warning:
> >
> > drivers/target/tcm_fc/tfc_io.c:209: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'size_t'
> >
> > Signed-off-by: Randy Dunlap <[email protected]>
> > ---
>
> Hey Randy,
>
> Kiran (CC'ed) was going to include this along with a bugfix patch for
> scsi-misc, but it's probably easier to just change this in linux-next
> now..
Hey Nick,
Is there some way to have this patch merged for linux-next and mainline?
Thanks.
> Signed-off-by: Nicholas A. Bellinger <[email protected]>
>
> > drivers/target/tcm_fc/tfc_io.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > and please put an entry in the MAINTAINERS file for drivers/target/
> >
>
> <nod>, sending out that patch shortly.
>
> Thanks,
>
> --nab
>
> >
> > --- linux-next-20110523.orig/drivers/target/tcm_fc/tfc_io.c
> > +++ linux-next-20110523/drivers/target/tcm_fc/tfc_io.c
> > @@ -203,7 +203,7 @@ int ft_queue_data_in(struct se_cmd *se_c
> > /* XXX For now, initiator will retry */
> > if (printk_ratelimit())
> > printk(KERN_ERR "%s: Failed to send frame %p, "
> > - "xid <0x%x>, remaining <0x%x>, "
> > + "xid <0x%x>, remaining <0x%zx>, "
> > "lso_max <0x%x>\n",
> > __func__, fp, ep->xid,
> > remaining, lport->lso_max);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***