All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: Tree for May 23
@ 2011-05-23  5:45 Stephen Rothwell
  2011-05-23 16:42 ` linux-next: Tree for May 23 (infiniband + netlink) Randy Dunlap
                   ` (5 more replies)
  0 siblings, 6 replies; 83+ messages in thread
From: Stephen Rothwell @ 2011-05-23  5:45 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 10866 bytes --]

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                    sfr@canb.auug.org.au

$ 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"

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (infiniband + netlink)
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
@ 2011-05-23 16:42 ` Randy Dunlap
       [not found]   ` <20110523094205.4a5651d2.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 16:42 UTC (permalink / raw)
  To: Stephen Rothwell, netdev; +Cc: linux-next, LKML, linux-rdma

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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
  2011-05-23 16:42 ` linux-next: Tree for May 23 (infiniband + netlink) Randy Dunlap
@ 2011-05-23 17:43 ` Randy Dunlap
  2011-05-23 17:51   ` Cyrill Gorcunov
  2011-05-23 19:31   ` [tip:x86/apic] x86, apic: Include module.h header in apic_flat_64.c tip-bot for Randy Dunlap
  2011-05-23 17:49   ` [lm-sensors] " Randy Dunlap
                   ` (3 subsequent siblings)
  5 siblings, 2 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 17:43 UTC (permalink / raw)
  To: Stephen Rothwell, x86; +Cc: linux-next, LKML

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (hwmon/coretemp.c)
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
@ 2011-05-23 17:49   ` Randy Dunlap
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 17:49 UTC (permalink / raw)
  To: Stephen Rothwell, Rudolf Marek, lm-sensors; +Cc: linux-next, LKML, Fenghua Yu

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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [lm-sensors] linux-next: Tree for May 23 (hwmon/coretemp.c)
@ 2011-05-23 17:49   ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 17:49 UTC (permalink / raw)
  To: Stephen Rothwell, Rudolf Marek, lm-sensors; +Cc: linux-next, LKML, Fenghua Yu

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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
@ 2011-05-23 17:51   ` Cyrill Gorcunov
  2011-05-23 18:09     ` Cyrill Gorcunov
  2011-05-23 19:31   ` [tip:x86/apic] x86, apic: Include module.h header in apic_flat_64.c tip-bot for Randy Dunlap
  1 sibling, 1 reply; 83+ messages in thread
From: Cyrill Gorcunov @ 2011-05-23 17:51 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, x86, linux-next, LKML, Ingo Molnar, Suresh Siddha

On 05/23/2011 09:43 PM, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>
> ---
>  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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [lm-sensors] linux-next: Tree for May 23 (hwmon/coretemp.c)
  2011-05-23 17:49   ` [lm-sensors] " Randy Dunlap
  (?)
@ 2011-05-23 18:03     ` Guenter Roeck
  -1 siblings, 0 replies; 83+ messages in thread
From: Guenter Roeck @ 2011-05-23 18:03 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Rudolf Marek, lm-sensors, Fenghua Yu, linux-next, LKML

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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (hwmon/coretemp.c)
@ 2011-05-23 18:03     ` Guenter Roeck
  0 siblings, 0 replies; 83+ messages in thread
From: Guenter Roeck @ 2011-05-23 18:03 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Stephen Rothwell, Fenghua Yu, LKML, lm-sensors, linux-next

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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [lm-sensors] linux-next: Tree for May 23 (hwmon/coretemp.c)
@ 2011-05-23 18:03     ` Guenter Roeck
  0 siblings, 0 replies; 83+ messages in thread
From: Guenter Roeck @ 2011-05-23 18:03 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Rudolf Marek, lm-sensors, Fenghua Yu, linux-next, LKML

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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (infiniband + netlink)
  2011-05-23 16:42 ` linux-next: Tree for May 23 (infiniband + netlink) Randy Dunlap
@ 2011-05-23 18:05       ` Roland Dreier
  0 siblings, 0 replies; 83+ messages in thread
From: Roland Dreier @ 2011-05-23 18:05 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, netdev, linux-next-u79uwXL29TY76Z2rM5mHXA,
	LKML, linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Mon, May 23, 2011 at 9:42 AM, Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 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
--
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	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (infiniband + netlink)
@ 2011-05-23 18:05       ` Roland Dreier
  0 siblings, 0 replies; 83+ messages in thread
From: Roland Dreier @ 2011-05-23 18:05 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Stephen Rothwell, netdev, linux-next, LKML, linux-rdma

On Mon, May 23, 2011 at 9:42 AM, Randy Dunlap <randy.dunlap@oracle.com> 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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 17:51   ` Cyrill Gorcunov
@ 2011-05-23 18:09     ` Cyrill Gorcunov
  2011-05-23 18:12       ` Randy Dunlap
  0 siblings, 1 reply; 83+ messages in thread
From: Cyrill Gorcunov @ 2011-05-23 18:09 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, x86, linux-next, LKML, Ingo Molnar, Suresh Siddha

On 05/23/2011 09:51 PM, Cyrill Gorcunov wrote:
> On 05/23/2011 09:43 PM, Randy Dunlap wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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 <randy.dunlap@oracle.com>
>> ---
>>  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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 18:09     ` Cyrill Gorcunov
@ 2011-05-23 18:12       ` Randy Dunlap
  2011-05-23 18:35         ` Cyrill Gorcunov
  2011-05-23 19:10         ` Ingo Molnar
  0 siblings, 2 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 18:12 UTC (permalink / raw)
  To: Cyrill Gorcunov
  Cc: Stephen Rothwell, x86, linux-next, LKML, Ingo Molnar, Suresh Siddha

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

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 <randy.dunlap@oracle.com>
>>>
>>> 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 <randy.dunlap@oracle.com>
>>> ---
>>>  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 ***

[-- Attachment #2: config-r7378 --]
[-- Type: text/plain, Size: 39129 bytes --]

#
# Automatically generated make config: don't edit
# Linux/x86_64 2.6.39 Kernel Configuration
# Mon May 23 09:38:23 2011
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
# CONFIG_ZONE_DMA is not set
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_FHANDLE=y
# CONFIG_TASKSTATS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
# CONFIG_TREE_PREEMPT_RCU is not set
CONFIG_TINY_RCU=y
# CONFIG_TINY_PREEMPT_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS=y
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_JUMP_LABEL=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_BLK_DEV_INTEGRITY=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=1
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
# CONFIG_X86_MCE is not set
CONFIG_I8K=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
# CONFIG_X86_PAT is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#

#
# Bus options (PCI etc.)
#
# CONFIG_PCI is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_IA32_EMULATION is not set
# CONFIG_COMPAT_FOR_U64_ALIGNMENT is not set
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
# CONFIG_UNIX is not set
# CONFIG_NET_KEY is not set
# CONFIG_INET is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_ATM=y
CONFIG_ATM_LANE=y
CONFIG_STP=y
CONFIG_GARP=y
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_DECNET=y
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_PHONET is not set
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y
# CONFIG_BATMAN_ADV is not set
CONFIG_HAVE_BPF_JIT=y

#
# Network testing
#
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_WIRELESS is not set
CONFIG_WIMAX=y
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
CONFIG_CAIF=y
CONFIG_CAIF_DEBUG=y
CONFIG_CAIF_NETDEV=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_HAVE_MTD_OTP=y
CONFIG_MTD_BLKDEVS=y
# CONFIG_MTD_BLOCK is not set
CONFIG_MTD_BLOCK_RO=y
CONFIG_FTL=y
# CONFIG_NFTL is not set
CONFIG_INFTL=y
# CONFIG_RFD_FTL is not set
CONFIG_SSFDC=y
CONFIG_MTD_OOPS=y
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MAP_BANK_WIDTH_8=y
CONFIG_MTD_MAP_BANK_WIDTH_16=y
CONFIG_MTD_MAP_BANK_WIDTH_32=y
CONFIG_MTD_CFI_I1=y
# CONFIG_MTD_CFI_I2 is not set
# CONFIG_MTD_CFI_I4 is not set
CONFIG_MTD_CFI_I8=y
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_TS5500 is not set
CONFIG_MTD_SBC_GXX=y
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
CONFIG_MTD_SCB2_FLASH=y
CONFIG_MTD_NETtel=y
CONFIG_MTD_L440GX=y
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=y

#
# Self-contained MTD device drivers
#
CONFIG_MTD_SST25L=y
CONFIG_MTD_SLRAM=y
CONFIG_MTD_PHRAM=y
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCPROBE=y
CONFIG_MTD_DOCECC=y
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
# CONFIG_MTD_NAND is not set
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_ONENAND=y
# CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
# CONFIG_MTD_ONENAND_GENERIC is not set
CONFIG_MTD_ONENAND_OTP=y
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_GLUEBI=y
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_ATAPI=y
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_IDE_GD is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS is not set
CONFIG_BLK_DEV_IDETAPE=y
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEDMA is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
CONFIG_CHR_DEV_OSST=y
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
CONFIG_SCSI_SRP_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_BOOT_SYSFS is not set
CONFIG_LIBFC=y
CONFIG_LIBFCOE=y
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
CONFIG_SCSI_OSD_INITIATOR=y
# CONFIG_SCSI_OSD_ULD is not set
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
CONFIG_PATA_PLATFORM=y

#
# Generic fallback / legacy drivers
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_AUTODETECT is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
CONFIG_MD_MULTIPATH=y
CONFIG_MD_FAULTY=y
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
CONFIG_TARGET_CORE=y
CONFIG_TCM_IBLOCK=y
# CONFIG_TCM_FILEIO is not set
# CONFIG_TCM_PSCSI is not set
# CONFIG_LOOPBACK_TARGET is not set
CONFIG_TCM_FC=y
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_EQUALIZER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
CONFIG_MII=y
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
CONFIG_CICADA_PHY=y
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM63XX_PHY is not set
CONFIG_ICPLUS_PHY=y
# CONFIG_REALTEK_PHY is not set
CONFIG_NATIONAL_PHY=y
CONFIG_STE10XP=y
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
CONFIG_STMMAC_ETH=y
# CONFIG_STMMAC_DA is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_WLAN is not set

#
# WiMAX Wireless Broadband devices
#

#
# Enable USB support to see WiMAX USB drivers
#

#
# Enable MMC support to see WiMAX SDIO drivers
#
# CONFIG_WAN is not set
CONFIG_ATM_DRIVERS=y
CONFIG_ATM_DUMMY=y

#
# CAIF transport drivers
#
CONFIG_CAIF_TTY=y
# CONFIG_CAIF_SPI_SLAVE is not set
# CONFIG_PPP is not set
CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=y
# CONFIG_SLIP_SMART is not set
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_EVDEV is not set
CONFIG_INPUT_EVBUG=y

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=y
CONFIG_SERIAL_MAX3107=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_TIMBERDALE=y
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=y
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_TTY_PRINTK=y
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_R3964=y
CONFIG_MWAVE=y
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=y
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=y

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_DESIGNWARE=y

#
# SPI Protocol Masters
#
CONFIG_SPI_TLE62X0=y

#
# PPS support
#

#
# PPS generators support
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1029=y
# CONFIG_SENSORS_ADM1031 is not set
CONFIG_SENSORS_ADM9240=y
CONFIG_SENSORS_ADT7475=y
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_DS620 is not set
CONFIG_SENSORS_DS1621=y
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=y
CONFIG_SENSORS_F75375S=y
CONFIG_SENSORS_FSCHMD=y
CONFIG_SENSORS_G760A=y
CONFIG_SENSORS_GL518SM=y
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_JC42=y
CONFIG_SENSORS_LM63=y
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=y
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM77 is not set
CONFIG_SENSORS_LM78=y
# CONFIG_SENSORS_LM80 is not set
CONFIG_SENSORS_LM83=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM92=y
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
CONFIG_SENSORS_LM95241=y
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
CONFIG_SENSORS_PC87360=y
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
CONFIG_SENSORS_SHT21=y
# CONFIG_SENSORS_EMC1403 is not set
CONFIG_SENSORS_EMC2103=y
CONFIG_SENSORS_SMSC47M1=y
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SCH5627 is not set
CONFIG_SENSORS_ADS1015=y
CONFIG_SENSORS_ADS7828=y
CONFIG_SENSORS_ADS7871=y
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_WM831X is not set
# CONFIG_SENSORS_WM8350 is not set
# CONFIG_SENSORS_APPLESMC is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_WM831X_WATCHDOG is not set
CONFIG_WM8350_WATCHDOG=y
CONFIG_ACQUIRE_WDT=y
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_SC520_WDT is not set
CONFIG_SBC_FITPC2_WATCHDOG=y
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=y
CONFIG_WAFER_WDT=y
# CONFIG_IT8712F_WDT is not set
CONFIG_HP_WATCHDOG=y
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=y
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83697UG_WDT is not set
CONFIG_W83877F_WDT=y
# CONFIG_W83977F_WDT is not set
CONFIG_MACHZ_WDT=y
CONFIG_SBC_EPX_C3_WATCHDOG=y
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SILENT=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=y
CONFIG_BCMA_DEBUG=y
CONFIG_MFD_SUPPORT=y
CONFIG_MFD_CORE=y
# CONFIG_MFD_88PM860X is not set
CONFIG_MFD_SM501=y
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
CONFIG_MFD_STMPE=y
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_PMIC_ADP5520=y
# CONFIG_MFD_MAX8925 is not set
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
CONFIG_MFD_WM8400=y
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_I2C=y
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
CONFIG_ABX500_CORE=y
CONFIG_AB3100_CORE=y
CONFIG_AB3100_OTP=y
# CONFIG_EZX_PCAP is not set
CONFIG_AB8500_CORE=y
# CONFIG_AB8500_DEBUG is not set
# CONFIG_AB3550_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=y

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_COMMON=y
CONFIG_VIDEO_MEDIA=y

#
# Multimedia drivers
#
# CONFIG_RC_CORE is not set
CONFIG_MEDIA_TUNER=y
CONFIG_MEDIA_TUNER_CUSTOMISE=y

#
# Customize TV tuners
#
# CONFIG_MEDIA_TUNER_SIMPLE is not set
# CONFIG_MEDIA_TUNER_TDA8290 is not set
CONFIG_MEDIA_TUNER_TDA827X=y
CONFIG_MEDIA_TUNER_TDA18271=y
CONFIG_MEDIA_TUNER_TDA9887=y
CONFIG_MEDIA_TUNER_TEA5767=y
CONFIG_MEDIA_TUNER_MT20XX=y
CONFIG_MEDIA_TUNER_MT2060=y
# CONFIG_MEDIA_TUNER_MT2266 is not set
# CONFIG_MEDIA_TUNER_MT2131 is not set
CONFIG_MEDIA_TUNER_QT1010=y
# CONFIG_MEDIA_TUNER_XC2028 is not set
CONFIG_MEDIA_TUNER_XC5000=y
CONFIG_MEDIA_TUNER_MXL5005S=y
CONFIG_MEDIA_TUNER_MXL5007T=y
# CONFIG_MEDIA_TUNER_MC44S803 is not set
# CONFIG_MEDIA_TUNER_MAX2165 is not set
# CONFIG_MEDIA_TUNER_TDA18218 is not set
CONFIG_MEDIA_TUNER_TDA18212=y
CONFIG_VIDEO_V4L2=y
CONFIG_V4L2_MEM2MEM_DEV=y
CONFIG_VIDEOBUF2_CORE=y
CONFIG_VIDEOBUF2_MEMOPS=y
CONFIG_VIDEOBUF2_VMALLOC=y
# CONFIG_VIDEO_CAPTURE_DRIVERS is not set
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_MEM2MEM_TESTDEV=y
# CONFIG_RADIO_ADAPTERS is not set

#
# Graphics support
#
CONFIG_DRM=y
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_FB is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_WM831X is not set
CONFIG_BACKLIGHT_ADP5520=y
CONFIG_BACKLIGHT_ADP8860=y

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y

#
# Display hardware drivers
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
# CONFIG_HID is not set
CONFIG_HID_PID=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y
CONFIG_MSPRO_BLOCK=y

#
# MemoryStick Host Controller Drivers
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_ALIX2=y
# CONFIG_LEDS_LP3944 is not set
CONFIG_LEDS_LP5521=y
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_PCA955X is not set
CONFIG_LEDS_WM831X_STATUS=y
CONFIG_LEDS_WM8350=y
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_ADP5520=y
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_NFC_DEVICES is not set
CONFIG_ACCESSIBILITY=y
CONFIG_EDAC=y

#
# Reporting subsystems
#
CONFIG_EDAC_DEBUG=y
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_DEV is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
CONFIG_RTC_DRV_DS1672=y
CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_MAX6900=y
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
CONFIG_RTC_DRV_ISL12022=y
CONFIG_RTC_DRV_X1205=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_PCF8583=y
# CONFIG_RTC_DRV_M41T80 is not set
CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
CONFIG_RTC_DRV_FM3130=y
CONFIG_RTC_DRV_RX8581=y
# CONFIG_RTC_DRV_RX8025 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T94 is not set
CONFIG_RTC_DRV_DS1305=y
# CONFIG_RTC_DRV_DS1390 is not set
CONFIG_RTC_DRV_MAX6902=y
# CONFIG_RTC_DRV_R9701 is not set
CONFIG_RTC_DRV_RS5C348=y
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
CONFIG_RTC_DRV_DS1553=y
# CONFIG_RTC_DRV_DS1742 is not set
CONFIG_RTC_DRV_STK17TA8=y
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
CONFIG_RTC_DRV_MSM6242=y
CONFIG_RTC_DRV_BQ4802=y
CONFIG_RTC_DRV_RP5C01=y
CONFIG_RTC_DRV_V3020=y
# CONFIG_RTC_DRV_WM831X is not set
# CONFIG_RTC_DRV_WM8350 is not set
# CONFIG_RTC_DRV_AB3100 is not set
CONFIG_RTC_DRV_AB8500=y

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
CONFIG_TIMB_DMA=y
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
CONFIG_ASYNC_TX_DMA=y
CONFIG_DMATEST=y
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
# CONFIG_UIO_PDRV is not set
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_STAGING=y
# CONFIG_STAGING_EXCLUDE_BUILD is not set
CONFIG_ECHO=y
# CONFIG_BRCMUTIL is not set
CONFIG_POHMELFS=y
# CONFIG_POHMELFS_DEBUG is not set
CONFIG_POHMELFS_CRYPTO=y
# CONFIG_IIO is not set
# CONFIG_XVMALLOC is not set
# CONFIG_ZRAM is not set
# CONFIG_ZCACHE is not set
CONFIG_MACH_NO_WESTBRIDGE=y
CONFIG_FT1000=y

#
# Speakup console speech
#
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=y

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_EDD_OFF is not set
# CONFIG_FIRMWARE_MEMMAP is not set
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=y
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
# CONFIG_ISCSI_IBFT_FIND is not set
CONFIG_SIGMA=y
# CONFIG_GOOGLE_FIRMWARE is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
CONFIG_REISERFS_CHECK=y
CONFIG_REISERFS_FS_XATTR=y
# CONFIG_REISERFS_FS_POSIX_ACL is not set
# CONFIG_REISERFS_FS_SECURITY is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_GFS2_FS=y
# CONFIG_OCFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
# CONFIG_QUOTA is not set
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# Caches
#
CONFIG_FSCACHE=y
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_CACHEFILES is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_NTFS_FS=y
CONFIG_NTFS_DEBUG=y
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
# CONFIG_PROC_FS is not set
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_HFSPLUS_FS=y
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_XATTR=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
# CONFIG_UBIFS_FS_ZLIB is not set
CONFIG_UBIFS_FS_DEBUG=y
# CONFIG_CRAMFS is not set
CONFIG_SQUASHFS=y
# CONFIG_SQUASHFS_XATTR is not set
# CONFIG_SQUASHFS_LZO is not set
CONFIG_SQUASHFS_XZ=y
CONFIG_SQUASHFS_EMBEDDED=y
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
CONFIG_VXFS_FS=y
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_SYSV_FS=y
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_EESOX is not set
CONFIG_ACORN_PARTITION_ICS=y
CONFIG_ACORN_PARTITION_ADFS=y
CONFIG_ACORN_PARTITION_POWERTEC=y
# CONFIG_ACORN_PARTITION_RISCIX is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=y
# CONFIG_NLS_CODEPAGE_857 is not set
CONFIG_NLS_CODEPAGE_860=y
# CONFIG_NLS_CODEPAGE_861 is not set
CONFIG_NLS_CODEPAGE_862=y
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=y
# CONFIG_NLS_CODEPAGE_936 is not set
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=y
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
CONFIG_NLS_ISO8859_4=y
# CONFIG_NLS_ISO8859_5 is not set
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_LKDTM is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
# CONFIG_EVENT_POWER_TRACING_DEPRECATED is not set
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_DYNAMIC_FTRACE is not set
# CONFIG_FUNCTION_PROFILER is not set
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
CONFIG_EVENT_TRACE_TEST_SYSCALLS=y
CONFIG_RING_BUFFER_BENCHMARK=y
CONFIG_DYNAMIC_DEBUG=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_ATOMIC64_SELFTEST=y
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_TEST_KSTRTOX=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
CONFIG_IO_DELAY_UDELAY=y
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=2
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_IMA is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
CONFIG_CRYPTO_GCM=y
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_PCBC is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
CONFIG_CRYPTO_GHASH=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
CONFIG_CRYPTO_CAMELLIA=y
# CONFIG_CRYPTO_CAST5 is not set
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=y
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_SEED=y
CONFIG_CRYPTO_SERPENT=y
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
# CONFIG_XZ_DEC_POWERPC is not set
# CONFIG_XZ_DEC_IA64 is not set
CONFIG_XZ_DEC_ARM=y
# CONFIG_XZ_DEC_ARMTHUMB is not set
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
CONFIG_XZ_DEC_TEST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 18:12       ` Randy Dunlap
@ 2011-05-23 18:35         ` Cyrill Gorcunov
  2011-05-23 19:10         ` Ingo Molnar
  1 sibling, 0 replies; 83+ messages in thread
From: Cyrill Gorcunov @ 2011-05-23 18:35 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, x86, linux-next, LKML, Ingo Molnar, Suresh Siddha

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 <randy.dunlap@oracle.com>
>>>>
>>>> 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 <randy.dunlap@oracle.com>
>>>> ---
>>>>  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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH -next] target: fix tfc_io.c printk format warning
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
                   ` (2 preceding siblings ...)
  2011-05-23 17:49   ` [lm-sensors] " Randy Dunlap
@ 2011-05-23 18:35 ` Randy Dunlap
  2011-05-23 20:47   ` Nicholas A. Bellinger
  2011-05-23 18:37   ` Randy Dunlap
  2011-05-23 20:48   ` Randy Dunlap
  5 siblings, 1 reply; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 18:35 UTC (permalink / raw)
  To: Stephen Rothwell, Nicholas A. Bellinger; +Cc: linux-next, LKML

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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);

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH -next] mtd: fix physmap.h warnings
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
@ 2011-05-23 18:37   ` Randy Dunlap
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 18:37 UTC (permalink / raw)
  To: Stephen Rothwell, linux-mtd; +Cc: linux-next, LKML, David Woodhouse

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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;

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-23 18:37   ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 18:37 UTC (permalink / raw)
  To: Stephen Rothwell, linux-mtd; +Cc: linux-next, David Woodhouse, LKML

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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;

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 18:12       ` Randy Dunlap
  2011-05-23 18:35         ` Cyrill Gorcunov
@ 2011-05-23 19:10         ` Ingo Molnar
  2011-05-23 19:26           ` Ingo Molnar
  1 sibling, 1 reply; 83+ messages in thread
From: Ingo Molnar @ 2011-05-23 19:10 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Cyrill Gorcunov, Stephen Rothwell, x86, linux-next, LKML, Suresh Siddha


* Randy Dunlap <randy.dunlap@oracle.com> 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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] x86: apic_flat_64.c needs module.h
  2011-05-23 19:10         ` Ingo Molnar
@ 2011-05-23 19:26           ` Ingo Molnar
  0 siblings, 0 replies; 83+ messages in thread
From: Ingo Molnar @ 2011-05-23 19:26 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Cyrill Gorcunov, Stephen Rothwell, x86, linux-next, LKML, Suresh Siddha


* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Randy Dunlap <randy.dunlap@oracle.com> 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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [tip:x86/apic] x86, apic: Include module.h header in apic_flat_64.c
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
  2011-05-23 17:51   ` Cyrill Gorcunov
@ 2011-05-23 19:31   ` tip-bot for Randy Dunlap
  1 sibling, 0 replies; 83+ messages in thread
From: tip-bot for Randy Dunlap @ 2011-05-23 19:31 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, sfr, tglx, randy.dunlap, mingo

Commit-ID:  b18bf0948e1037e7ed33378c80f1ecb8c77c30e9
Gitweb:     http://git.kernel.org/tip/b18bf0948e1037e7ed33378c80f1ecb8c77c30e9
Author:     Randy Dunlap <randy.dunlap@oracle.com>
AuthorDate: Mon, 23 May 2011 10:43:00 -0700
Committer:  Ingo Molnar <mingo@elte.hu>
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 <randy.dunlap@oracle.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Link: http://lkml.kernel.org/r/20110523104300.dd532a99.randy.dunlap@oracle.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 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>

^ permalink raw reply related	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] target: fix tfc_io.c printk format warning
  2011-05-23 18:35 ` [PATCH -next] target: fix tfc_io.c printk format warning Randy Dunlap
@ 2011-05-23 20:47   ` Nicholas A. Bellinger
  2011-06-16 18:35     ` Randy Dunlap
  0 siblings, 1 reply; 83+ messages in thread
From: Nicholas A. Bellinger @ 2011-05-23 20:47 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, Patil, Kiran, James Bottomley

On Mon, 2011-05-23 at 11:35 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>
> ---

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 <nab@linux-iscsi.org>

>  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);


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
@ 2011-05-23 20:48   ` Randy Dunlap
  2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 20:48 UTC (permalink / raw)
  To: Stephen Rothwell, alsa-devel, Mark Brown; +Cc: linux-next, LKML, Harald Welte

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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
@ 2011-05-23 20:48   ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 20:48 UTC (permalink / raw)
  To: Stephen Rothwell, alsa-devel, Mark Brown; +Cc: linux-next, Harald, LKML, Welte

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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (infiniband + netlink)
       [not found]       ` <BANLkTindDsbE-Fdr5-Db4Kw6ww+ntk2S2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-05-23 21:37         ` Or Gerlitz
       [not found]           ` <BANLkTikaiNZfMV8o_=xmuHrhM_O-tq4cDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 83+ messages in thread
From: Or Gerlitz @ 2011-05-23 21:37 UTC (permalink / raw)
  To: Roland Dreier
  Cc: Randy Dunlap, Stephen Rothwell, linux-rdma-u79uwXL29TY76Z2rM5mHXA

Roland,

Looking on your for-next branch as present on the kernel.org clone, I noted
that "RDMA: Update exported headers list" @
http://git.kernel.org/?p=linux/kernel/git/roland/infiniband.git;a=commitdiff;h=a0415f70272f26227d6e2f5e2cd1feafdf76cc95
has a part which seems borrowed from other part changing cma.c ?

Or.
--
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	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-23 20:48   ` Randy Dunlap
  (?)
@ 2011-05-23 22:47   ` Mark Brown
  2011-05-23 22:53       ` Randy Dunlap
  -1 siblings, 1 reply; 83+ messages in thread
From: Mark Brown @ 2011-05-23 22:47 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, linux-next, LKML, Harald Welte,
	Dmitry Artamonow

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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (infiniband + netlink)
       [not found]           ` <BANLkTikaiNZfMV8o_=xmuHrhM_O-tq4cDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-05-23 22:51             ` Roland Dreier
  0 siblings, 0 replies; 83+ messages in thread
From: Roland Dreier @ 2011-05-23 22:51 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Randy Dunlap, Stephen Rothwell, linux-rdma-u79uwXL29TY76Z2rM5mHXA

On Mon, May 23, 2011 at 2:37 PM, Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Looking on your for-next branch as present on the kernel.org clone, I noted
> that "RDMA: Update exported headers list" @
> http://git.kernel.org/?p=linux/kernel/git/roland/infiniband.git;a=commitdiff;h=a0415f70272f26227d6e2f5e2cd1feafdf76cc95
> has a part which seems borrowed from other part changing cma.c ?


Good catch...wrong rebasing on my part.

Should be OK now.

 - 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	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-23 22:47   ` Mark Brown
@ 2011-05-23 22:53       ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 22:53 UTC (permalink / raw)
  To: Mark Brown, x86
  Cc: Stephen Rothwell, alsa-devel, linux-next, LKML, Harald Welte,
	Dmitry Artamonow

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 x86@kernel.org == 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 <laforge@gnufiish.org>");
  [which bounces]

and wm8915.c says:
MODULE_AUTHOR("Mark Brown <broonie@opensource.wolfsonmicro.com>");


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
@ 2011-05-23 22:53       ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-23 22:53 UTC (permalink / raw)
  To: Mark Brown, x86
  Cc: Stephen Rothwell, alsa-devel, Dmitry Artamonow, LKML, linux-next,
	Harald, Welte

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 x86@kernel.org == 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 <laforge@gnufiish.org>");
  [which bounces]

and wm8915.c says:
MODULE_AUTHOR("Mark Brown <broonie@opensource.wolfsonmicro.com>");


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-23 22:53       ` Randy Dunlap
  (?)
@ 2011-05-24  0:08       ` Mark Brown
  2011-05-24  1:21           ` Randy Dunlap
  -1 siblings, 1 reply; 83+ messages in thread
From: Mark Brown @ 2011-05-24  0:08 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Dmitry Artamonow

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 <broonie@opensource.wolfsonmicro.com>");

You've clearly not looked at MAINTAINERS for this one.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-24  0:08       ` Mark Brown
@ 2011-05-24  1:21           ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24  1:21 UTC (permalink / raw)
  To: Mark Brown
  Cc: x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Dmitry Artamonow

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 <broonie@opensource.wolfsonmicro.com>");
> 
> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
@ 2011-05-24  1:21           ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24  1:21 UTC (permalink / raw)
  To: Mark Brown
  Cc: Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86, LKML,
	linux-next, Harald Welte

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 <broonie@opensource.wolfsonmicro.com>");
> 
> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: linux-next: Tree for May 23 (sound/soc/codecs)
  2011-05-24  1:21           ` Randy Dunlap
  (?)
@ 2011-05-24  1:50           ` Mark Brown
  2011-05-24  4:58               ` Randy Dunlap
  -1 siblings, 1 reply; 83+ messages in thread
From: Mark Brown @ 2011-05-24  1:50 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Dmitry Artamonow

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 <broonie@opensource.wolfsonmicro.com>");

> > 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-24  1:50           ` Mark Brown
@ 2011-05-24  4:58               ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24  4:58 UTC (permalink / raw)
  To: Mark Brown
  Cc: x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Dmitry Artamonow, Grant Likely

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 <broonie@opensource.wolfsonmicro.com>");
> 
>>> 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 <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-05-24  4:58               ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24  4:58 UTC (permalink / raw)
  To: Mark Brown
  Cc: Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86, LKML,
	Grant Likely, linux-next, Harald Welte

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 <broonie@opensource.wolfsonmicro.com>");
> 
>>> 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 <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-24  4:58               ` Randy Dunlap
@ 2011-05-24  5:23                 ` Dmitry Artamonow
  -1 siblings, 0 replies; 83+ messages in thread
From: Dmitry Artamonow @ 2011-05-24  5:23 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Grant Likely

On 21:58 Mon 23 May     , Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-05-24  5:23                 ` Dmitry Artamonow
  0 siblings, 0 replies; 83+ messages in thread
From: Dmitry Artamonow @ 2011-05-24  5:23 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, x86, Mark Brown, LKML,
	Grant Likely, linux-next, Harald Welte

On 21:58 Mon 23 May     , Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-23 18:37   ` Randy Dunlap
@ 2011-05-24  5:53     ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  5:53 UTC (permalink / raw)
  To: Randy Dunlap, Russell King
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier

On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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 (Артём Битюцкий)


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  5:53     ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  5:53 UTC (permalink / raw)
  To: Randy Dunlap, Russell King
  Cc: Stephen Rothwell, Marc Zyngier, LKML, linux-next, linux-mtd,
	David Woodhouse

On Mon, 2011-05-23 at 11:37 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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 (Артём Битюцкий)

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-24  5:53     ` Artem Bityutskiy
@ 2011-05-24  5:58       ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  5:58 UTC (permalink / raw)
  To: Russell King
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap

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 <randy.dunlap@oracle.com>
> > 
> > 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 <randy.dunlap@oracle.com>
> 
> 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 (Артём Битюцкий)


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  5:58       ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  5:58 UTC (permalink / raw)
  To: Russell King
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse

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 <randy.dunlap@oracle.com>
> > 
> > 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 <randy.dunlap@oracle.com>
> 
> 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 (Артём Битюцкий)

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-24  5:58       ` Artem Bityutskiy
@ 2011-05-24  7:40         ` Russell King
  -1 siblings, 0 replies; 83+ messages in thread
From: Russell King @ 2011-05-24  7:40 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap

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 <randy.dunlap@oracle.com>
> > > 
> > > 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 <randy.dunlap@oracle.com>
> > 
> > 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:

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  7:40         ` Russell King
  0 siblings, 0 replies; 83+ messages in thread
From: Russell King @ 2011-05-24  7:40 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse

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 <randy.dunlap@oracle.com>
> > > 
> > > 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 <randy.dunlap@oracle.com>
> > 
> > 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:

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-24  7:40         ` Russell King
@ 2011-05-24  7:40           ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:40 UTC (permalink / raw)
  To: Russell King
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap

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 <randy.dunlap@oracle.com>
> > > > 
> > > > 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 <randy.dunlap@oracle.com>
> > > 
> > > 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 (Артём Битюцкий)


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  7:40           ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:40 UTC (permalink / raw)
  To: Russell King
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse

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 <randy.dunlap@oracle.com>
> > > > 
> > > > 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 <randy.dunlap@oracle.com>
> > > 
> > > 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 (Артём Битюцкий)

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-23 18:37   ` Randy Dunlap
@ 2011-05-24  7:41     ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:41 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML

From: Randy Dunlap <randy.dunlap@oracle.com>
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 <randy.dunlap@oracle.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 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


^ permalink raw reply related	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  7:41     ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:41 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, linux-mtd, David Woodhouse, LKML

From: Randy Dunlap <randy.dunlap@oracle.com>
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 <randy.dunlap@oracle.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 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

^ permalink raw reply related	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-24  7:40         ` Russell King
@ 2011-05-24  7:42           ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:42 UTC (permalink / raw)
  To: Russell King
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap

From: Randy Dunlap <randy.dunlap@oracle.com>
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 <randy.dunlap@oracle.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 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


^ permalink raw reply related	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-05-24  7:42           ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-05-24  7:42 UTC (permalink / raw)
  To: Russell King
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse

From: Randy Dunlap <randy.dunlap@oracle.com>
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 <randy.dunlap@oracle.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 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

^ permalink raw reply related	[flat|nested] 83+ messages in thread

* Re: [alsa-devel] [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-24  4:58               ` Randy Dunlap
@ 2011-05-24  7:52                 ` Mark Brown
  -1 siblings, 0 replies; 83+ messages in thread
From: Mark Brown @ 2011-05-24  7:52 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86, LKML,
	Grant Likely, linux-next, Harald Welte

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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-05-24  7:52                 ` Mark Brown
  0 siblings, 0 replies; 83+ messages in thread
From: Mark Brown @ 2011-05-24  7:52 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86, LKML,
	Grant Likely, linux-next, Harald Welte

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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-24  5:23                 ` Dmitry Artamonow
@ 2011-05-24 19:44                   ` Randy Dunlap
  -1 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24 19:44 UTC (permalink / raw)
  To: Dmitry Artamonow
  Cc: Mark Brown, x86, Stephen Rothwell, alsa-devel, linux-next, LKML,
	Harald Welte, Grant Likely

On Tue, 24 May 2011 09:23:42 +0400 Dmitry Artamonow wrote:

> On 21:58 Mon 23 May     , Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > 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 <randy.dunlap@oracle.com>
> 
> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-05-24 19:44                   ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-24 19:44 UTC (permalink / raw)
  To: Dmitry Artamonow
  Cc: Stephen Rothwell, alsa-devel, x86, Mark Brown, LKML,
	Grant Likely, linux-next, Harald, Welte

On Tue, 24 May 2011 09:23:42 +0400 Dmitry Artamonow wrote:

> On 21:58 Mon 23 May     , Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > 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 <randy.dunlap@oracle.com>
> 
> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [alsa-devel] [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-24  7:52                 ` Mark Brown
  (?)
@ 2011-05-27  7:45                 ` Grant Likely
  2011-05-27 17:46                     ` Randy Dunlap
  -1 siblings, 1 reply; 83+ messages in thread
From: Grant Likely @ 2011-05-27  7:45 UTC (permalink / raw)
  To: Mark Brown
  Cc: Randy Dunlap, Stephen Rothwell, alsa-devel, Dmitry Artamonow,
	x86, LKML, linux-next, Harald Welte

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.


^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-27  7:45                 ` [alsa-devel] " Grant Likely
@ 2011-05-27 17:46                     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-27 17:46 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-05-27 17:46                     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-05-27 17:46 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-27 17:46                     ` Randy Dunlap
  (?)
@ 2011-05-27 20:12                     ` Grant Likely
  2011-06-03 17:04                         ` Grant Likely
  -1 siblings, 1 reply; 83+ messages in thread
From: Grant Likely @ 2011-05-27 20:12 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On Fri, May 27, 2011 at 10:46:57AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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>
>  

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-05-24  7:42           ` Artem Bityutskiy
  (?)
@ 2011-06-01  7:45             ` Artem Bityutskiy
  -1 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-06-01  7:45 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap, Russell King

On Tue, 2011-05-24 at 10:42 +0300, Artem Bityutskiy wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 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 <randy.dunlap@oracle.com>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

David, it looks like Russel did not merge this patch and people
complain. Could you please merge it?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-06-01  7:45             ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-06-01  7:45 UTC (permalink / raw)
  Cc: Stephen Rothwell, linux-mtd, linux-next, David Woodhouse, LKML,
	Marc Zyngier, Randy Dunlap, Russell King

On Tue, 2011-05-24 at 10:42 +0300, Artem Bityutskiy wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 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 <randy.dunlap@oracle.com>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

David, it looks like Russel did not merge this patch and people
complain. Could you please merge it?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-06-01  7:45             ` Artem Bityutskiy
  0 siblings, 0 replies; 83+ messages in thread
From: Artem Bityutskiy @ 2011-06-01  7:45 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse, Russell King

On Tue, 2011-05-24 at 10:42 +0300, Artem Bityutskiy wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 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 <randy.dunlap@oracle.com>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

David, it looks like Russel did not merge this patch and people
complain. Could you please merge it?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
  2011-06-01  7:45             ` Artem Bityutskiy
@ 2011-06-01  8:05               ` Russell King
  -1 siblings, 0 replies; 83+ messages in thread
From: Russell King @ 2011-06-01  8:05 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: David Woodhouse, Stephen Rothwell, linux-mtd, linux-next, LKML,
	Marc Zyngier, Randy Dunlap

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 <randy.dunlap@oracle.com>
> > 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 <randy.dunlap@oracle.com>
> > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> 
> 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:

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] mtd: fix physmap.h warnings
@ 2011-06-01  8:05               ` Russell King
  0 siblings, 0 replies; 83+ messages in thread
From: Russell King @ 2011-06-01  8:05 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: Randy Dunlap, Stephen Rothwell, Marc Zyngier, LKML, linux-next,
	linux-mtd, David Woodhouse

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 <randy.dunlap@oracle.com>
> > 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 <randy.dunlap@oracle.com>
> > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> 
> 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:

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-05-27 20:12                     ` Grant Likely
@ 2011-06-03 17:04                         ` Grant Likely
  0 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-03 17:04 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On Fri, May 27, 2011 at 2:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, May 27, 2011 at 10:46:57AM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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 <randy.dunlap@oracle.com>
>
> 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-06-03 17:04                         ` Grant Likely
  0 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-03 17:04 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

On Fri, May 27, 2011 at 2:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, May 27, 2011 at 10:46:57AM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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 <randy.dunlap@oracle.com>
>
> 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-03 17:04                         ` Grant Likely
  (?)
@ 2011-06-03 17:18                         ` Mark Brown
  2011-06-03 17:42                           ` Grant Likely
  -1 siblings, 1 reply; 83+ messages in thread
From: Mark Brown @ 2011-06-03 17:18 UTC (permalink / raw)
  To: Grant Likely
  Cc: Randy Dunlap, Stephen Rothwell, alsa-devel, Dmitry Artamonow,
	x86, LKML, linux-next, Harald Welte

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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-03 17:18                         ` Mark Brown
@ 2011-06-03 17:42                           ` Grant Likely
  2011-06-06  3:45                               ` Randy Dunlap
  0 siblings, 1 reply; 83+ messages in thread
From: Grant Likely @ 2011-06-03 17:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: Randy Dunlap, Stephen Rothwell, alsa-devel, Dmitry Artamonow,
	x86, LKML, linux-next, Harald Welte

On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-03 17:42                           ` Grant Likely
@ 2011-06-06  3:45                               ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-06  3:45 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On 06/03/11 10:42, Grant Likely wrote:
> On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-06-06  3:45                               ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-06  3:45 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

On 06/03/11 10:42, Grant Likely wrote:
> On Fri, Jun 3, 2011 at 11:18 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-06  3:45                               ` Randy Dunlap
@ 2011-06-14 16:12                                 ` Randy Dunlap
  -1 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-14 16:12 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

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
> > <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-06-14 16:12                                 ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-14 16:12 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

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
> > <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-14 16:12                                 ` Randy Dunlap
  (?)
@ 2011-06-14 16:13                                 ` Grant Likely
  2011-06-15  0:03                                     ` Randy Dunlap
                                                     ` (2 more replies)
  -1 siblings, 3 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-14 16:13 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

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
> > > <broonie@opensource.wolfsonmicro.com> 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.


^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-14 16:13                                 ` Grant Likely
@ 2011-06-15  0:03                                     ` Randy Dunlap
  2011-06-15  0:05                                     ` Randy Dunlap
  2011-06-15  0:06                                     ` Randy Dunlap
  2 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:03 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

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
> > > > <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-06-15  0:03                                     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:03 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

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
> > > > <broonie@opensource.wolfsonmicro.com> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH 1/2] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-14 16:13                                 ` Grant Likely
@ 2011-06-15  0:05                                     ` Randy Dunlap
  2011-06-15  0:05                                     ` Randy Dunlap
  2011-06-15  0:06                                     ` Randy Dunlap
  2 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:05 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH 1/2] gpio: add GPIOF_ values regardless on kconfig settings
@ 2011-06-15  0:05                                     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:05 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH 2/2] gpio: include linux/gpio.h where needed
  2011-06-14 16:13                                 ` Grant Likely
@ 2011-06-15  0:06                                     ` Randy Dunlap
  2011-06-15  0:05                                     ` Randy Dunlap
  2011-06-15  0:06                                     ` Randy Dunlap
  2 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:06 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* [PATCH 2/2] gpio: include linux/gpio.h where needed
@ 2011-06-15  0:06                                     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15  0:06 UTC (permalink / raw)
  To: Grant Likely
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 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>
 

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 2/2] gpio: include linux/gpio.h where needed
  2011-06-15  0:06                                     ` Randy Dunlap
  (?)
@ 2011-06-15  0:34                                     ` Stephen Rothwell
  2011-06-15 17:59                                       ` Randy Dunlap
  -1 siblings, 1 reply; 83+ messages in thread
From: Stephen Rothwell @ 2011-06-15  0:34 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Grant Likely, Mark Brown, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Hi Randy,

On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 2/2] gpio: include linux/gpio.h where needed
  2011-06-15  0:34                                     ` Stephen Rothwell
@ 2011-06-15 17:59                                       ` Randy Dunlap
  2011-06-15 19:21                                           ` Grant Likely
  0 siblings, 1 reply; 83+ messages in thread
From: Randy Dunlap @ 2011-06-15 17:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Grant Likely, Mark Brown, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On 06/14/11 17:34, Stephen Rothwell wrote:
> Hi Randy,
> 
> On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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 ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 2/2] gpio: include linux/gpio.h where needed
  2011-06-15 17:59                                       ` Randy Dunlap
@ 2011-06-15 19:21                                           ` Grant Likely
  0 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-15 19:21 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Mark Brown, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On Wed, Jun 15, 2011 at 11:59 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On 06/14/11 17:34, Stephen Rothwell wrote:
>> Hi Randy,
>>
>> On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>>
>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>>
>>> 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 2/2] gpio: include linux/gpio.h where needed
@ 2011-06-15 19:21                                           ` Grant Likely
  0 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-15 19:21 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, alsa-devel, x86, Dmitry Artamonow, Mark Brown,
	LKML, linux-next, Harald Welte

On Wed, Jun 15, 2011 at 11:59 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On 06/14/11 17:34, Stephen Rothwell wrote:
>> Hi Randy,
>>
>> On Tue, 14 Jun 2011 17:06:02 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>>
>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>>
>>> 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.

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 2/2] gpio: include linux/gpio.h where needed
  2011-06-15  0:06                                     ` Randy Dunlap
  (?)
  (?)
@ 2011-06-16 14:37                                     ` Grant Likely
  -1 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-16 14:37 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On Tue, Jun 14, 2011 at 05:06:02PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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>
>  

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH 1/2] gpio: add GPIOF_ values regardless on kconfig settings
  2011-06-15  0:05                                     ` Randy Dunlap
  (?)
@ 2011-06-16 14:37                                     ` Grant Likely
  -1 siblings, 0 replies; 83+ messages in thread
From: Grant Likely @ 2011-06-16 14:37 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mark Brown, Stephen Rothwell, alsa-devel, Dmitry Artamonow, x86,
	LKML, linux-next, Harald Welte

On Tue, Jun 14, 2011 at 05:05:11PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> 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 <randy.dunlap@oracle.com>

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>
>  

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [PATCH -next] target: fix tfc_io.c printk format warning
  2011-05-23 20:47   ` Nicholas A. Bellinger
@ 2011-06-16 18:35     ` Randy Dunlap
  0 siblings, 0 replies; 83+ messages in thread
From: Randy Dunlap @ 2011-06-16 18:35 UTC (permalink / raw)
  To: Nicholas A. Bellinger
  Cc: Stephen Rothwell, linux-next, LKML, Patil, Kiran, James Bottomley

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 <randy.dunlap@oracle.com>
> > 
> > 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 <randy.dunlap@oracle.com>
> > ---
> 
> 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 <nab@linux-iscsi.org>
> 
> >  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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 83+ messages in thread

end of thread, other threads:[~2011-06-16 18:36 UTC | newest]

Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-23  5:45 linux-next: Tree for May 23 Stephen Rothwell
2011-05-23 16:42 ` linux-next: Tree for May 23 (infiniband + netlink) Randy Dunlap
     [not found]   ` <20110523094205.4a5651d2.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2011-05-23 18:05     ` Roland Dreier
2011-05-23 18:05       ` Roland Dreier
     [not found]       ` <BANLkTindDsbE-Fdr5-Db4Kw6ww+ntk2S2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-23 21:37         ` Or Gerlitz
     [not found]           ` <BANLkTikaiNZfMV8o_=xmuHrhM_O-tq4cDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-23 22:51             ` Roland Dreier
2011-05-23 17:43 ` [PATCH -next] x86: apic_flat_64.c needs module.h Randy Dunlap
2011-05-23 17:51   ` Cyrill Gorcunov
2011-05-23 18:09     ` Cyrill Gorcunov
2011-05-23 18:12       ` Randy Dunlap
2011-05-23 18:35         ` Cyrill Gorcunov
2011-05-23 19:10         ` Ingo Molnar
2011-05-23 19:26           ` Ingo Molnar
2011-05-23 19:31   ` [tip:x86/apic] x86, apic: Include module.h header in apic_flat_64.c tip-bot for Randy Dunlap
2011-05-23 17:49 ` linux-next: Tree for May 23 (hwmon/coretemp.c) Randy Dunlap
2011-05-23 17:49   ` [lm-sensors] " Randy Dunlap
2011-05-23 18:03   ` Guenter Roeck
2011-05-23 18:03     ` Guenter Roeck
2011-05-23 18:03     ` Guenter Roeck
2011-05-23 18:35 ` [PATCH -next] target: fix tfc_io.c printk format warning Randy Dunlap
2011-05-23 20:47   ` Nicholas A. Bellinger
2011-06-16 18:35     ` Randy Dunlap
2011-05-23 18:37 ` [PATCH -next] mtd: fix physmap.h warnings Randy Dunlap
2011-05-23 18:37   ` Randy Dunlap
2011-05-24  5:53   ` Artem Bityutskiy
2011-05-24  5:53     ` Artem Bityutskiy
2011-05-24  5:58     ` Artem Bityutskiy
2011-05-24  5:58       ` Artem Bityutskiy
2011-05-24  7:40       ` Russell King
2011-05-24  7:40         ` Russell King
2011-05-24  7:40         ` Artem Bityutskiy
2011-05-24  7:40           ` Artem Bityutskiy
2011-05-24  7:42         ` Artem Bityutskiy
2011-05-24  7:42           ` Artem Bityutskiy
2011-06-01  7:45           ` Artem Bityutskiy
2011-06-01  7:45             ` Artem Bityutskiy
2011-06-01  7:45             ` Artem Bityutskiy
2011-06-01  8:05             ` Russell King
2011-06-01  8:05               ` Russell King
2011-05-24  7:41   ` Artem Bityutskiy
2011-05-24  7:41     ` Artem Bityutskiy
2011-05-23 20:48 ` linux-next: Tree for May 23 (sound/soc/codecs) Randy Dunlap
2011-05-23 20:48   ` Randy Dunlap
2011-05-23 22:47   ` Mark Brown
2011-05-23 22:53     ` Randy Dunlap
2011-05-23 22:53       ` Randy Dunlap
2011-05-24  0:08       ` Mark Brown
2011-05-24  1:21         ` Randy Dunlap
2011-05-24  1:21           ` Randy Dunlap
2011-05-24  1:50           ` Mark Brown
2011-05-24  4:58             ` [PATCH/RFC] gpio: add GPIOF_ values regardless on kconfig settings Randy Dunlap
2011-05-24  4:58               ` Randy Dunlap
2011-05-24  5:23               ` Dmitry Artamonow
2011-05-24  5:23                 ` Dmitry Artamonow
2011-05-24 19:44                 ` Randy Dunlap
2011-05-24 19:44                   ` Randy Dunlap
2011-05-24  7:52               ` [alsa-devel] " Mark Brown
2011-05-24  7:52                 ` Mark Brown
2011-05-27  7:45                 ` [alsa-devel] " Grant Likely
2011-05-27 17:46                   ` [PATCH] " Randy Dunlap
2011-05-27 17:46                     ` Randy Dunlap
2011-05-27 20:12                     ` Grant Likely
2011-06-03 17:04                       ` Grant Likely
2011-06-03 17:04                         ` Grant Likely
2011-06-03 17:18                         ` Mark Brown
2011-06-03 17:42                           ` Grant Likely
2011-06-06  3:45                             ` Randy Dunlap
2011-06-06  3:45                               ` Randy Dunlap
2011-06-14 16:12                               ` Randy Dunlap
2011-06-14 16:12                                 ` Randy Dunlap
2011-06-14 16:13                                 ` Grant Likely
2011-06-15  0:03                                   ` Randy Dunlap
2011-06-15  0:03                                     ` Randy Dunlap
2011-06-15  0:05                                   ` [PATCH 1/2] " Randy Dunlap
2011-06-15  0:05                                     ` Randy Dunlap
2011-06-16 14:37                                     ` Grant Likely
2011-06-15  0:06                                   ` [PATCH 2/2] gpio: include linux/gpio.h where needed Randy Dunlap
2011-06-15  0:06                                     ` Randy Dunlap
2011-06-15  0:34                                     ` Stephen Rothwell
2011-06-15 17:59                                       ` Randy Dunlap
2011-06-15 19:21                                         ` Grant Likely
2011-06-15 19:21                                           ` Grant Likely
2011-06-16 14:37                                     ` Grant Likely

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.