All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: Tree for Oct 11
@ 2011-10-11  9:11 Stephen Rothwell
  2011-10-11 18:26 ` [PATCH -next] x86: perf_event_intel.c needs export.h Randy Dunlap
                   ` (6 more replies)
  0 siblings, 7 replies; 137+ messages in thread
From: Stephen Rothwell @ 2011-10-11  9:11 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

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

Hi all,

The linux-next tree is now available from
git://github.com/sfrothwell/linux-next.git as a temporary measure while
the kernel.org servers are unavailable.

It may also turn up on git.kernel.org (depending on the mirroring).  The
patch set is still absent, however.

Changes since 20111007:

Removed tree: ide (at the maintainer's request)

Renamed trees:
	sparc -> sparc-next
	sparc-current -> sparc
	net -> next-next
	net-current -> net
	ide-current -> ide
	voltage -> regulator

The arm-lpae tree lost 2 conflicts.

The arm-soc tree lost its build failure.

The i.MX tree lost a conflict.

The s5p tree gained a conflict against the arm tree.

The hid tree gained a conflict agaains Linus' tree.

The infiniband tree gained a build failure so I used th version from
next-20111007.

The net-next tree lost a conflict.

The sound tree gained a conflict against the arm-soc tree.

The sound-asoc tree lost its build failure so.

The device-mapper tree lost its conflict.

The md tree lost its build failure but gained another so I used the
version from next-20111006.

The mfd tree gained a conflict against the amr-soc tree.

The omap_dss2 tree gained a conflict against the arm-soc tree.

The gpio tree still has its build failure so I used the version from
next-20111005.

The hwspinlock tree gained a conflict against the arm-soc tree.

The moduleh tree gained 2 build failures for which I applied a patches.

----------------------------------------------------------------------------

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 201 trees (counting Linus' and 27 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/fixes
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/merge
Merging sparc/master
Merging scsi-rc-fixes/master
Merging net/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/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/page.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable-hwdef.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/kernel/head.S
CONFLICT (content): Merge conflict in arch/arm/kernel/sleep.S
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
CONFLICT (rename/delete): Rename arch/arm/include/asm/sizes.h->arch/arm/mach-picoxcell/include/mach/uncompress.h in arm-soc/for-next and deleted in HEAD
CONFLICT (add/add): Merge conflict in Documentation/devicetree/bindings/arm/l2cc.txt
CONFLICT (content): Merge conflict in arch/arm/boot/compressed/Makefile
CONFLICT (content): Merge conflict in arch/arm/include/asm/hardware/cache-l2x0.h
CONFLICT (content): Merge conflict in arch/arm/kernel/smp.c
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in arm-soc/for-next and modified in HEAD. Version HEAD of arch/arm/mach-at91/board-usb-a9260.c left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-msm/board-msm8x60.c
CONFLICT (content): Merge conflict in arch/arm/mach-mxs/include/mach/gpio.h
CONFLICT (delete/modify): arch/arm/mach-nuc93x/Makefile.boot deleted in arm-soc/for-next and modified in HEAD. Version HEAD of arch/arm/mach-nuc93x/Makefile.boot left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/board-paz00.h
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/board-seaboard.h
CONFLICT (content): Merge conflict in arch/arm/mach-u300/Makefile.boot
CONFLICT (content): Merge conflict in arch/arm/mm/cache-l2x0.c
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/include/mach/gpio.h
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c arch/arm/mach-nuc93x/Makefile.boot
Applying: arm-soc: merge fixup for fixup/reserve being added to MACHINE descriptions
Merging at91/at91-next
CONFLICT (content): Merge conflict in arch/arm/mach-at91/at91sam9g45.c
Merging davinci/davinci-next
Merging i.MX/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-mx5/mm.c
Merging linux-spec/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/mach-exynos4/Kconfig
CONFLICT (content): Merge conflict in drivers/gpio/Makefile
Merging tegra/for-next
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging c6x/for-linux-next
Merging cris/for-next
Merging quilt/hexagon
Merging ia64/next
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
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-next/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
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
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
CONFLICT (content): Merge conflict in fs/xfs/xfs_aops.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_super.c
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-wacom.c
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
Merging kconfig/for-next
Merging libata/NEXT
Merging infiniband/for-next
$ git reset --hard HEAD^
Merging refs/next/20111007/infiniband
Merging acpi/acpi
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 iscsi-target/for-next
Merging slave-dma/next
Merging async_tx/next
Merging net-next/master
CONFLICT (delete/modify): arch/powerpc/configs/40x/hcu4_defconfig deleted in HEAD and modified in net-next/master. Version net-next/master of arch/powerpc/configs/40x/hcu4_defconfig left in tree.
CONFLICT (content): Merge conflict in drivers/s390/cio/qdio_main.c
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Merging wireless/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging bluetooth/master
CONFLICT (content): Merge conflict in net/bluetooth/hci_core.c
CONFLICT (content): Merge conflict in net/bluetooth/l2cap_core.c
CONFLICT (content): Merge conflict in net/bluetooth/mgmt.c
CONFLICT (content): Merge conflict in net/bluetooth/smp.c
Merging mtd/master
Merging l2-mtd/master
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-afeb-9260v1.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-neocore926.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-rm9200dk.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-sam9g20ek.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-sam9m10g45ek.c
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in HEAD and modified in l2-mtd/master. Version l2-mtd/master of arch/arm/mach-at91/board-usb-a9260.c left in tree.
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.c
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c
Merging crypto/master
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/plat-omap/devices.c
CONFLICT (content): Merge conflict in arch/mips/alchemy/devboards/db1x00/platform.c
CONFLICT (content): Merge conflict in sound/mips/Kconfig
Merging sound-asoc/for-next
Merging cpufreq/next
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/core/core.c
CONFLICT (content): Merge conflict in drivers/mmc/core/sd.c
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
CONFLICT (content): Merge conflict in drivers/md/faulty.c
CONFLICT (content): Merge conflict in drivers/md/linear.c
CONFLICT (content): Merge conflict in drivers/md/md.c
CONFLICT (content): Merge conflict in drivers/md/md.h
CONFLICT (content): Merge conflict in drivers/md/multipath.c
CONFLICT (content): Merge conflict in drivers/md/raid0.c
CONFLICT (content): Merge conflict in drivers/md/raid1.c
CONFLICT (content): Merge conflict in drivers/md/raid10.c
CONFLICT (content): Merge conflict in drivers/md/raid5.c
$ git reset --hard HEAD^
Merging refs/next/20111006/md
Merging mfd/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-imx/mach-mx31moboard.c
CONFLICT (content): Merge conflict in arch/arm/mach-u300/include/mach/irqs.h
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/fbdev-next
CONFLICT (content): Merge conflict in drivers/video/Kconfig
Merging viafb/viafb-next
Merging omap_dss2/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-2430sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-4430sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-apollon.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-h4.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-ldp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-rx51.c
CONFLICT (delete/modify): drivers/video/omap/lcd_apollon.c deleted in omap_dss2/for-next and modified in HEAD. Version HEAD of drivers/video/omap/lcd_apollon.c left in tree.
CONFLICT (delete/modify): drivers/video/omap/lcd_ldp.c deleted in omap_dss2/for-next and modified in HEAD. Version HEAD of drivers/video/omap/lcd_ldp.c left in tree.
CONFLICT (delete/modify): drivers/video/omap/lcd_overo.c deleted in omap_dss2/for-next and modified in HEAD. Version HEAD of drivers/video/omap/lcd_overo.c left in tree.
$ git rm -f drivers/video/omap/lcd_apollon.c drivers/video/omap/lcd_ldp.c drivers/video/omap/lcd_overo.c
Merging regulator/for-next
Merging security/next
CONFLICT (content): Merge conflict in fs/ocfs2/xattr.c
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging iommu/next
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in Documentation/PCI/pci.txt
CONFLICT (delete/modify): arch/arm/mach-nuc93x/time.c deleted in HEAD and modified in trivial/for-next. Version trivial/for-next of arch/arm/mach-nuc93x/time.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/Kconfig
$ git rm -f arch/arm/mach-nuc93x/time.c
Merging audit/for-next
Merging pm/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/board-ap4evb.c
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging edac/linux_next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mcheck/mce.c
Merging edac-amd/for-next
Merging devicetree/devicetree/next
Merging spi/spi/next
Merging gpio/gpio/next
$ git reset --hard HEAD^
Merging refs/next/20111005/gpio
Merging tip/auto-latest
CONFLICT (content): Merge conflict in drivers/iommu/Makefile
Applying: llist: add back llist_add_batch and llist_del_first
Merging rcu/rcu/next
Merging kmemleak/kmemleak
Merging kvm/kvm-updates/3.2
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
CONFLICT (content): Merge conflict in arch/x86/xen/Kconfig
Merging xen-pvhvm/linux-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
CONFLICT (content): Merge conflict in drivers/mfd/wm831x-spi.c
Merging driver-core/driver-core-next
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/devices.c
Merging tty/tty-next
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/udbg.h
CONFLICT (content): Merge conflict in arch/powerpc/kernel/udbg.c
CONFLICT (content): Merge conflict in drivers/tty/serial/8250.c
Merging usb/usb-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/Makefile
Merging staging/staging-next
CONFLICT (content): Merge conflict in drivers/misc/altera-stapl/altera.c
CONFLICT (content): Merge conflict in drivers/staging/brcm80211/brcmsmac/mac80211_if.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_labpc.c
CONFLICT (content): Merge conflict in drivers/staging/et131x/et1310_tx.c
CONFLICT (delete/modify): drivers/staging/rtl8192e/r8192E_core.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rtl8192e/r8192E_core.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/xgifb/XGI_main_26.c
CONFLICT (content): Merge conflict in drivers/staging/zram/zram_drv.c
$ git rm -f drivers/staging/rtl8192e/r8192E_core.c
Merging bkl-config/config
Merging tmem/tmem
Merging writeback/writeback-for-next
Merging arm-dt/devicetree/arm-next
Merging hwspinlock/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/hwspinlock.c
Merging pinctrl/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-u300/Kconfig
CONFLICT (content): Merge conflict in arch/arm/mach-u300/core.c
Merging moduleh/for-sfr
CONFLICT (content): Merge conflict in arch/arm/mach-bcmring/mm.c
CONFLICT (content): Merge conflict in drivers/media/dvb/frontends/dibx000_common.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
CONFLICT (content): Merge conflict in drivers/scsi/libfc/fc_lport.c
CONFLICT (delete/modify): drivers/staging/iio/industrialio-ring.c deleted in HEAD and modified in moduleh/for-sfr. Version moduleh/for-sfr of drivers/staging/iio/industrialio-ring.c left in tree.
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
CONFLICT (content): Merge conflict in sound/soc/soc-io.c
$ git rm -f drivers/staging/iio/industrialio-ring.c
Applying: block/bsg-lib.c: change module.h -> export.h in power/common.c
Applying: mmc: using module_param requires the inclusion of moduleparam.h
Applying: NFC: use of module facilities requires the inclusion of module.h
Applying: arm: Add export.h to recently added files for EXPORT_SYMBOL
Applying: powerpc/powernv: include export.h in hvc_opal.h for THIS_MODULE
Applying: PM QoS: include export.h in qos.c for EXPORT_SYMBOL
Applying: net: Add export.h to nfc/nci/core.c
Applying: scsi: Add export.h to drivers/scsi/libsas/sas_host_smp.c
Applying: drivers/md: change module.h -> export.h in persistent-data/dm-*
Applying: drivers/net: Add module.h to wireless/ath/ath6kl/sdio.c
Applying: drivers/net: wireless/ath/ath5k/debug.c does not need module.h
Applying: drivers/bcma: driver_chipcommon_pmu.c needs export.h for EXPORT_SYMBOL
Applying: drivers/base: change module.h -> export.h in power/common.c
Applying: drivers/base: Add export.h to regmap/regcache.c
Applying: pinctrl: EXPORT_SYMBOL needs export.h
Applying: ath6kl: THIS_MODULES needs export.h
Applying: ath6kl: module_param needs the inclusion of moduleparam.h
Applying: rtlwifi: use of module_param requires the inclusion of moduleparam.h
Applying: staging: Add export.h to recently added files for EXPORT_SYMBOL
Applying: regulator: using module related services requires module.h
Applying: x86, nmi: include export.h for EXPORT_SYBBOL
Merging kvmtool/master
CONFLICT (content): Merge conflict in include/net/9p/9p.h
Merging scsi-post-merge/merge-base:master
$ git checkout akpm
Applying: include/linux/dmar.h: forward-declare struct acpi_dmar_header
Applying: drivers/net/ethernet/i825xx/3c505.c: fix build with dynamic debug
Applying: drm: fix kconfig unmet dependency warning
Applying: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
Applying: readlinkat: ensure we return ENOENT for the empty pathname for normal lookups
Applying: x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode
Applying: acerhdf: add support for Aspire 1410 BIOS v1.3314
Applying: arch/x86/platform/iris/iris.c: register a platform device and a platform driver
Applying: hp_accel: Add a new PNP id
Applying: hp_accel: Add axis-mapping for HP ProBook / EliteBook
Applying: x86: fix mmap random address range
Applying: arch/x86/kernel/e820.c: eliminate bubble sort from sanitize_e820_map
Applying: vrtc: change its year offset from 1960 to 1972
Applying: x86: rtc: don't register a platform RTC device for Intel MID platforms
Applying: mrst: battery fixes
Applying: drivers/power/intel_mid_battery.c: fix build
Applying: x86,mrst: add mapping for bma023
Applying: arch/x86/kernel/e820.c: quiet sparse noise about plain integer as NULL pointer
Applying: arch/x86/kernel/ptrace.c: quiet sparse noise
Applying: arch/x86/mm/pageattr.c: quiet sparse noise; local functions should be static
Applying: x86: tlb flush avoid superflous leave_mm()
Applying: arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
Applying: arm, exec: remove redundant set_fs(USER_DS)
Applying: audit: always follow va_copy() with va_end()
Applying: btrfs: don't dereference extent_mapping if NULL
Applying: drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
Applying: drivers/gpu/vga/vgaarb.c: add missing kfree
Applying: ia64, exec: remove redundant set_fs(USER_DS)
Applying: brlocks/lglocks: clean up code
Applying: brlocks-lglocks-clean-up-code-checkpatch-fixes
Applying: ipc/mqueue: cleanup definition names and locations
Applying: ipc/mqueue: switch back to using non-max values on create
Applying: ipc/mqueue: enforce hard limits
Applying: ipc/mqueue: update maximums for the mqueue subsystem
Applying: ipc-mqueue-update-maximums-for-the-mqueue-subsystem-checkpatch-fixes
Applying: unicore32, exec: remove redundant set_fs(USER_DS)
Applying: drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h: remove unused macro pr_fmt()
Applying: debugobjects: extend debugobjects to assert that an object is initialized
Applying: kernel/timer.c: use debugobjects to catch deletion of uninitialized timers
Applying: ext4: use proper little-endian bitops
Applying: ocfs2: avoid unaligned access to dqc_bitmap
Applying: parisc, exec: remove redundant set_fs(USER_DS)
Applying: drivers/firmware/dmi_scan.c: make dmi_name_in_vendors more focused
Applying: scsi: fix a header to include linux/types.h
Applying: drivers/scsi/megaraid.c: fix sparse warnings
Applying: drivers/scsi/aacraid/commctrl.c: fix mem leak in aac_send_raw_srb()
Applying: drivers/scsi/sd.c: use ida_simple_get() and ida_simple_remove() in place of boilerplate code
Applying: drivers/scsi/osd/osd_uld.c: use ida_simple_get() to handle id
Applying: drivers/scsi/sg.c: convert to kstrtoul_from_user()
Applying: drivers/scsi/mpt2sas/mpt2sas_base.c: fix mismatch in mpt2sas_base_hard_reset_handler() mutex lock-unlock
Applying: drivers/message/fusion/mptbase.c: ensure NUL-termination of MptCallbacksName elements
Applying: loop: prevent information leak after failed read
Applying: loop: cleanup set_status interface
Applying: loop-cleanup-set_status-interface-checkpatch-fixes
Applying: cciss: add half second delay to PCI PM reset code
Applying: cciss: auto engage SCSI mid layer at driver load time
Applying: slab: add taint flag outputting to debug paths.
Applying: slub: add taint flag outputting to debug paths
Applying: drivers/tty/serial/pch_uart.c: add console support
Applying: Cross Memory Attach
Applying: cross-memory-attach-update
Applying: cross-memory-attach-v4
Applying: mm: compaction: trivial clean up in acct_isolated()
Applying: mm: change isolate mode from #define to bitwise type
Applying: mm-change-isolate-mode-from-define-to-bitwise-type-fix
Applying: mm: compaction: make isolate_lru_page() filter-aware
Applying: mm-compaction-make-isolate_lru_page-filter-aware-fix
Applying: mm: zone_reclaim: make isolate_lru_page() filter-aware
Applying: mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix
Applying: mm: migration: clean up unmap_and_move()
Applying: radix_tree: clean away saw_unset_tag leftovers
Applying: vmscan: add block plug for page reclaim
Applying: mm/page-writeback.c: make determine_dirtyable_memory static again
Applying: mm/page-writeback.c: document bdi_min_ratio
Applying: oom: avoid killing kthreads if they assume the oom killed thread's mm
Applying: oom: remove oom_disable_count
Applying: oom: fix race while temporarily setting current's oom_score_adj
Applying: tmpfs: add "tmpfs" to the Kconfig prompt to make it obvious.
Applying: mm: output a list of loaded modules when we hit bad_page()
Applying: mm: vmscan: drop nr_force_scan[] from get_scan_count
Applying: mm: distinguish between mlocked and pinned pages
Applying: mm: add comments to explain mm_struct fields
Applying: mm-add-comments-to-explain-mm_struct-fields-fix
Applying: mm: vmscan: do not writeback filesystem pages in direct reclaim
Applying: mm: vmscan: remove dead code related to lumpy reclaim waiting on pages under writeback
Applying: xfs: warn if direct reclaim tries to writeback pages
Applying: ext4: warn if direct reclaim tries to writeback pages
Applying: mm: vmscan: do not writeback filesystem pages in kswapd except in high priority
Applying: mm: vmscan: throttle reclaim if encountering too many dirty pages under writeback
Applying: mm-vmscan-throttle-reclaim-if-encountering-too-many-dirty-pages-under-writeback-update
Applying: mm: vmscan: immediately reclaim end-of-LRU dirty pages when writeback completes
Applying: vmscan: count pages into balanced for zone with good watermark
Applying: mm/debug-pagealloc.c: use plain __ratelimit() instead of printk_ratelimit()
Applying: lib/string.c: introduce memchr_inv()
Applying: lib-stringc-introduce-memchr_inv-fix-kernel-doc-for-memchr_inv
Applying: mm/debug-pagealloc.c: use memchr_inv
Applying: vmscan: fix initial shrinker size handling
Applying: vmscan: use atomic-long for shrinker batching
Applying: vmscan-use-atomic-long-for-shrinker-batching-fix
Applying: mm: avoid null pointer access in vm_struct via /proc/vmallocinfo
Applying: vmscan: promote shared file mapped pages
Applying: vmscan: activate executable pages after first usage
Applying: memblock: add memblock_start_of_DRAM()
Applying: memblock: add NO_BOOTMEM config symbol
Applying: mremap: check for overflow using deltas
Applying: mremap: avoid sending one IPI per page
Applying: thp: mremap support and TLB optimization
Applying: thp-mremap-support-and-tlb-optimization-fix
Applying: thp-mremap-support-and-tlb-optimization-fix-fix
Applying: thp-mremap-support-and-tlb-optimization-fix-fix-fix
Applying: include/asm-generic/page.h: calculate virt_to_page and page_to_virt via predefined macro
Applying: mm: iov_iter: have iov_iter_advance() decrement nr_segs appropriately
Applying: mm: neaten warn_alloc_failed
Applying: mm-neaten-warn_alloc_failed-fix
Applying: debug-pagealloc: add support for highmem pages
Applying: debug-pagealloc-add-support-for-highmem-pages-fix
Applying: kswapd: avoid unnecessary rebalance after an unsuccessful balancing
Applying: mm: add free_hot_cold_page_list() helper
Applying: mm/memblock.c: small function definition fixes
Applying: mm: compaction: compact unevictable pages
Applying: mm-compaction-compact-unevictable-pages-checkpatch-fixes
Applying: mm: compaction: accounting fix
Applying: kswapd: assign new_order and new_classzone_idx after wakeup in sleeping
Applying: mm: fix page-faults detection in swap-token logic
Applying: mm/vmalloc.c: report more vmalloc failures
Applying: mm: add extra free kbytes tunable
Applying: mm-add-extra-free-kbytes-tunable-update
Applying: mm-add-extra-free-kbytes-tunable-update-checkpatch-fixes
Applying: mm: thp: tail page refcounting fix
Applying: thp-tail-page-refcounting-fix-6
Applying: ksm: fix the comment of try_to_unmap_one()
Applying: mm-add-comment-explaining-task-state-setting-in-bdi_forker_thread-fix
Applying: vmscan: fix shrinker callback bug in fs/super.c
Applying: mm/mmap.c: eliminate the ret variable from mm_take_all_locks()
Applying: mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks-fix
Applying: fs/buffer.c: add device information for error output in __find_get_block_slow()
Applying: HWPOISON: convert pr_debug()s to pr_info()s
Applying: mm: compaction: make compact_zone_order() static
Applying: mm: fix kunmap_high() comment
Applying: vmscan.c: fix invalid strict_strtoul() check in write_scan_unevictable_node()
Applying: mm: disable user interface to manually rescue unevictable pages
Applying: mm/memblock.c: quiet sparse noise
Applying: mm/thrash.c: quiet sparse noise
Applying: mm/mempolicy.c: quiet sparse noise
Applying: mm/huge_memory.c: quiet sparse noise
Applying: vmscan: add barrier to prevent evictable page in unevictable list
Applying: selinuxfs: remove custom hex_to_bin()
Applying: include/linux/security.h: fix security_inode_init_security() arg
Applying: hpet: factor timer allocate from open
Applying: alpha: wire up accept4 syscall
Applying: alpha: wire up sendmmsg syscall
Applying: intel_idle: fix API misuse
Applying: intel_idle: disable auto_demotion for hotplugged CPUs
Applying: fs/pipe.c: add ->statfs callback for pipefs
Applying: lib/Kconfig.debug: fix help message for DEFAULT_HUNG_TASK_TIMEOUT
Applying: hwmon: convert idr to ida and use ida_simple interface
Applying: drivers/hwmon/hwmon.c: convert idr to ida and use ida_simple_get()
Applying: lis3lv02d: avoid divide by zero due to unchecked
Applying: lis3: update maintainer information
Applying: lis3: add support for HP EliteBook 2730p
Applying: lis3: add support for HP EliteBook 8540w
Applying: hp_accel: add HP ProBook 655x
Applying: lis3: free regulators if probe() fails
Applying: lis3: use consistent naming of variables
Applying: lis3: change exported function to use passed parameter
Applying: lis3: remove the references to the global variable in core driver
Applying: lis3-remove-the-references-to-the-global-variable-in-core-driver-fix
Applying: lis3lv02d: make regulator API usage unconditional
Applying: driver/misc/fsa9480.c fix potential null-pointer dereference
Applying: stop_machine: make stop_machine safe and efficient to call early
Applying: stop_machine-make-stop_machine-safe-and-efficient-to-call-early-v3.
Applying: watchdog: move watchdog_*_all_cpus under CONFIG_SYSCTL
Applying: dynamic_debug: consolidate repetitive struct _ddebug descriptor definitions
Applying: dynamic_debug: remove num_enabled accounting
Applying: dynamic_debug: use a single printk() to emit messages
Applying: dynamic_debug: fix undefined reference to `__netdev_printk'
Applying: printk: add module parameter ignore_loglevel to control ignore_loglevel
Applying: printk: add ignore_loglevel as module parameter
Applying: printk: add console_suspend module parameter
Applying: printk: fix bounds checking for log_prefix
Applying: printk: remove bounds checking for log_prefix
Applying: treewide: use __printf not __attribute__((format(printf,...)))
Applying: treewide-use-__printf-not-__attribute__formatprintf-fix
Applying: treewide-use-__printf-not-__attribute__formatprintf-checkpatch-fixes
Applying: fs/namei.c: remove unused getname_flags()
Applying: poll: add poll_requested_events() function
Applying: MAINTAINERS: add new entry for ideapad-laptop
Applying: video/backlight: remove obsolete cleanup for clientdata
Applying: backlight: fix broken regulator API usage in l4f00242t03
Applying: drivers/video/backlight/l4f00242t03.c: use gpio_request_one() to simplify error handling
Applying: backlight: rename corgibl_limit_intensity() to genericbl_limit_intensity()
Applying: leds: Renesas TPU LED driver
Applying: leds-renesas-tpu-led-driver-v2-fix
Applying: drivers/leds/led-triggers.c: fix memory leak
Applying: drivers/leds/leds-lm3530.c: remove obsolete cleanup for clientdata
Applying: drivers/leds/leds-renesas-tpu.c: update driver to use workqueue
Applying: drivers/leds/leds-renesas-tpu.c: move Renesas TPU LED driver platform data
Applying: drivers/leds/leds-gpio.c: use gpio_get_value_cansleep() when initializing
Applying: lib/kstrtox: common code between kstrto*() and simple_strto*() functions
Applying: lib/spinlock_debug.c: print owner on spinlock lockup
Applying: lib/bitmap.c: quiet sparse noise about address space
Applying: lib-bitmapc-quiet-sparse-noise-about-address-space-fix
Applying: lib/percpu_counter.c: enclose hotplug only variables in hotplug ifdef
Applying: lib/idr.c: fix comment for ida_get_new_above()
Applying: llist: using in_nmi requires including hardirq.h
Applying: llist-return-whether-list-is-empty-before-adding-in-llist_add-fix
Applying: kernel.h/checkpatch: mark strict_strto<foo> and simple_strto<foo> as obsolete
Applying: lib/crc: add slice by 8 algorithm to crc32.c
Applying: lib-crc-add-slice-by-8-algorithm-to-crc32c-fix
Applying: epoll: fix spurious lockdep warnings
Applying: epoll: limit paths
Applying: binfmt_elf: fix PIE execution with randomization disabled
Applying: init/do_mounts_rd.c: fix ramdisk identification for padded cramfs
Applying: oprofilefs: handle zero-length writes
Applying: drivers/rtc/class.c: convert idr to ida and use ida_simple_get()
Applying: rtc: add initial support for mcp7941x parts
Applying: drivers/rtc/rtc-mc13xxx.c: move probe and remove callbacks to .init.text and .exit.text
Applying: minix: describe usage of different magic numbers
Applying: cgroups: more safe tasklist locking in cgroup_attach_proc
Applying: cgroups: don't attach task to subsystem if migration failed
Applying: cgroup/kmemleak: Annotate alloc_page() for cgroup allocations
Applying: cgroups: add res_counter_write_u64() API
Applying: cgroups: new resource counter inheritance API
Applying: cgroups: add previous cgroup in can_attach_task/attach_task callbacks
Applying: cgroups: new cancel_attach_task() subsystem callback
Applying: cgroups: ability to stop res charge propagation on bounded ancestor
Applying: cgroups: add res counter common ancestor searching
Applying: res_counter: allow charge failure pointer to be null
Applying: cgroups: pull up res counter charge failure interpretation to caller
Applying: cgroups: allow subsystems to cancel a fork
Applying: cgroups: add a task counter subsystem
Applying: memcg: rename mem variable to memcg
Applying: memcg: fix oom schedule_timeout()
Applying: memcg: replace ss->id_lock with a rwlock
Applying: memcg: do not expose uninitialized mem_cgroup_per_node to world
Applying: memcg: skip scanning active lists based on individual size
Applying: memcg-skip-scanning-active-lists-based-on-individual-size-fix
Applying: memcg: close race between charge and putback
Applying: memcg: Fix race condition in memcg_check_events() with this_cpu usage
Applying: cpusets: avoid looping when storing to mems_allowed if one node remains set
Applying: procfs: report EISDIR when reading sysctl dirs in proc
Applying: proc: fix races against execve() of /proc/PID/fd**
Applying: proc-fix-races-against-execve-of-proc-pid-fd-fix
Applying: proc: force dcache drop on unauthorized access
Applying: ipc-introduce-shm_rmid_forced-sysctl-testing
Applying: init: add root=PARTUUID=UUID/PARTNROFF=%d support
Applying: init-add-root=partuuid=uuid-partnroff=%d-support-fix
Applying: drivers/rapidio/rio-scan.c: use discovered bit to test if enumeration is complete
Applying: arch/powerpc/sysdev/fsl_rio.c: release rapidio port I/O region resource if port failed to initialize
Applying: RapidIO: add mport driver for Tsi721 bridge
Applying: RapidIO: Tsi721 driver - fixes for the initial release
Applying: RapidIO: fix potential null deref in rio_setup_device()
Applying: drivers/net/rionet.c: fix ethernet address macros for LE platforms
Applying: sysctl: add support for poll()
Applying: sysctl-add-support-for-poll-fix
Applying: sysctl: make CONFIG_SYSCTL_SYSCALL default to n
Applying: pps: default echo function
Applying: pps: new client driver using GPIO
Applying: pps-new-client-driver-using-gpio-fix
Applying: pps gpio client: add missing dependency
Applying: w1: ds2760 and ds2780, use ida for id and ida_simple_get() to get it
Applying: drivers/power/ds2780_battery.c: create central point for calling w1 interface
Applying: drivers/power/ds2780_battery.c: add a nolock function to w1 interface
Applying: drivers/power/ds2780_battery.c: fix deadlock upon insertion and removal
Applying: drivers/w1/w1_int.c: multiple masters used same init_name
Applying: aio: allocate kiocbs in batches
Applying: fs/direct-io.c: salcuate fs_count correctly in get_more_blocks()
Applying: dio: separate fields only used in the submission path from struct dio
Applying: dio-separate-fields-only-used-in-the-submission-path-from-struct-dio-checkpatch-fixes
Applying: dio: fix a wrong comment
Applying: dio: rearrange fields in dio/dio_submit to avoid holes
Applying: dio: use a slab cache for struct dio
Applying: dio: separate map_bh from dio
Applying: dio: inline the complete submission path
Applying: dio-inline-the-complete-submission-path-v2-checkpatch-fixes
Applying: dio: merge direct_io_walker() into __blockdev_direct_IO()
Applying: dio-merge-direct_io_walker-into-__blockdev_direct_io-checkpatch-fixes
Applying: dio: remove unnecessary dio argument from dio_pages_present()
Applying: dio: remove unused dio parameter from dio_bio_add_page()
Applying: vfs: cache request_queue in struct block_device
Applying: dio: optimize cache misses in the submission path
Applying: dio-optimize-cache-misses-in-the-submission-path-v2-checkpatch-fixes
Applying: dio: using prefetch requires including prefetch.h
Applying: ipc/mqueue: vlammoc requires vmalloc.h
Applying: cgroups: ERR_PTR needs err.h
Applying: include/linux/bio.h: use a static inline function for bio_integrity_clone()
Merging akpm

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

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

* [PATCH -next] x86: perf_event_intel.c needs export.h
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
@ 2011-10-11 18:26 ` Randy Dunlap
  2011-10-11 18:49 ` linux-next: Tree for Oct 11 (mmc) Randy Dunlap
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 18:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, LKML, x86 maintainers, Andrew Morton, Paul Gortmaker

From: Randy Dunlap <rdunlap@xenotime.net>

Add <linux/export.h> to fix build warnings:

arch/x86/kernel/cpu/perf_event_intel.c:1323:1: warning: data definition has no type or storage class
arch/x86/kernel/cpu/perf_event_intel.c:1323:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/x86/kernel/cpu/perf_event_intel.c:1323:1: warning: parameter names (without types) in function declaration

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 arch/x86/kernel/cpu/perf_event_intel.c |    1 +
 1 file changed, 1 insertion(+)

--- next-2011-1011.orig/arch/x86/kernel/cpu/perf_event_intel.c
+++ next-2011-1011/arch/x86/kernel/cpu/perf_event_intel.c
@@ -7,6 +7,7 @@
 
 #include <linux/stddef.h>
 #include <linux/types.h>
+#include <linux/export.h>
 #include <linux/init.h>
 #include <linux/slab.h>
 

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

* Re: linux-next: Tree for Oct 11 (mmc)
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
  2011-10-11 18:26 ` [PATCH -next] x86: perf_event_intel.c needs export.h Randy Dunlap
@ 2011-10-11 18:49 ` Randy Dunlap
  2011-10-11 19:31   ` mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) Andrei Warkentin
  2011-10-11 19:15 ` [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled Randy Dunlap
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 18:49 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, linux-mmc, Chris Ball

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:


When CONFIG_BLOCK is not enabled:

In file included from next-2011-1011/drivers/mmc/card/sdio_uart.c:43:0:
next-2011-1011/include/linux/mmc/card.h:175:12: error: 'DISK_NAME_LEN' undeclared here (not in a function)

Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
However, the same problem occurs in mmc/core/core.c:

In file included from next-2011-1011/drivers/mmc/core/core.c:30:0:
next-2011-1011/include/linux/mmc/card.h:175:12: error: 'DISK_NAME_LEN' undeclared here (not in a function)

Should mmc/core/ depend on BLOCK?  or should it just be made
to build even when BLOCK is not enabled?

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

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

* [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
  2011-10-11 18:26 ` [PATCH -next] x86: perf_event_intel.c needs export.h Randy Dunlap
  2011-10-11 18:49 ` linux-next: Tree for Oct 11 (mmc) Randy Dunlap
@ 2011-10-11 19:15 ` Randy Dunlap
  2011-10-27  8:06   ` Ted Ts'o
  2011-10-11 19:26 ` linux-next: Tree for Oct 11 (mfd/intel_msic.c) Randy Dunlap
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 19:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, LKML, linux-ext4, Theodore Ts'o, Andrew Morton,
	Arnd Bergmann, Arnaud Lacombe

From: Randy Dunlap <rdunlap@xenotime.net>

Fix build error when CONFIG_BUG is not enabled:

fs/jbd2/transaction.c:1175:3: error: implicit declaration of function '__WARN'

by changing __WARN() to WARN_ON(), as suggested by
Arnaud Lacombe <lacombar@gmail.com>.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Arnaud Lacombe <lacombar@gmail.com>
---

Same build error as reported on 31-AUG-2011 for
linux-next 20110830.

 fs/jbd2/transaction.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- next-2011-1011.orig/fs/jbd2/transaction.c
+++ next-2011-1011/fs/jbd2/transaction.c
@@ -27,6 +27,7 @@
 #include <linux/highmem.h>
 #include <linux/hrtimer.h>
 #include <linux/backing-dev.h>
+#include <linux/bug.h>
 #include <linux/module.h>
 
 static void __jbd2_journal_temp_unlink_buffer(struct journal_head *jh);
@@ -1171,8 +1172,7 @@ out_unlock_bh:
 	jbd_unlock_bh_state(bh);
 out:
 	JBUFFER_TRACE(jh, "exit");
-	if (ret)
-		__WARN();	/* All errors are bugs, so dump the stack */
+	WARN_ON(ret);	/* All errors are bugs, so dump the stack */
 	return ret;
 }
 

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

* Re: linux-next: Tree for Oct 11 (mfd/intel_msic.c)
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
                   ` (2 preceding siblings ...)
  2011-10-11 19:15 ` [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled Randy Dunlap
@ 2011-10-11 19:26 ` Randy Dunlap
  2011-10-11 19:32 ` linux-next: Tree for Oct 11 (gpio regulator) Randy Dunlap
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 19:26 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Samuel Ortiz

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

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:

(on i386 randconfig build:)

drivers/mfd/intel_msic.c:303:2: error: implicit declaration of function 'readb'
drivers/mfd/intel_msic.c:433:2: error: implicit declaration of function 'ioremap_nocache'
drivers/mfd/intel_msic.c:433:17: warning: assignment makes pointer from integer without a cast
drivers/mfd/intel_msic.c:455:2: error: implicit declaration of function 'iounmap'

Full randconfig file is attached.

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

[-- Attachment #2: config-r2161 --]
[-- Type: text/plain, Size: 57688 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.1.0-rc9 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_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=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=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 is not set
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 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
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 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
# CONFIG_AUDIT is not set
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 is not set

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
# CONFIG_CGROUP_TASK_COUNTER is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=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
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y

#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=m
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PREEMPT_NOTIFIERS=y
# 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_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
# CONFIG_SMP is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_X86_INTEL_MID=y
CONFIG_X86_MRST=y
CONFIG_X86_RDC321X=y
CONFIG_X86_32_IRIS=m
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
# CONFIG_XEN_PRIVILEGED_GUEST is not set
CONFIG_KVM_CLOCK=y
# CONFIG_KVM_GUEST is not set
# CONFIG_LGUEST_GUEST is not set
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_CMPXCHG_DOUBLE=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_HPET_TIMER=y
CONFIG_APB_TIMER=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER 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_PREEMPT_COUNT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
CONFIG_I8K=m
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_SCHED_HRTICK is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_COMPAT_VDSO=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_CMDLINE_OVERRIDE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
# CONFIG_ACPI_PROC_EVENT is not set
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_SBS=m
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set
# CONFIG_APM 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

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEBUG=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_PCI_STUB=m
# CONFIG_HT_IRQ is not set
CONFIG_PCI_IOV=y
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_ALIX is not set
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
CONFIG_HOTPLUG_PCI_IBM=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
# CONFIG_HOTPLUG_PCI_CPCI_GENERIC is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_HAVE_ATOMIC_IOMAP=y
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 is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
CONFIG_LLC2=m
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
# CONFIG_DEV_APPLETALK is not set
CONFIG_PHONET=m
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
CONFIG_CAN_GW=m

#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
# CONFIG_CAN_SLCAN is not set
# CONFIG_CAN_DEV is not set
CONFIG_CAN_DEBUG_DEVICES=y
CONFIG_IRDA=m

#
# IrDA protocols
#
# CONFIG_IRLAN is not set
# CONFIG_IRCOMM is not set
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
# CONFIG_ESI_DONGLE is not set
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
# CONFIG_TOIM3232_DONGLE is not set
CONFIG_LITELINK_DONGLE=m

#
# FIR device drivers
#
# CONFIG_USB_IRDA is not set
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
CONFIG_TOSHIBA_FIR=m
# CONFIG_VIA_FIR is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=m
# CONFIG_BT_RFCOMM_TTY is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_CMTP is not set

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
# CONFIG_BT_HCIUART_H4 is not set
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_ATH3K is not set
# CONFIG_BT_HCIUART_LL is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=y
CONFIG_RFKILL_REGULATOR=m
CONFIG_NET_9P=m
# CONFIG_NET_9P_VIRTIO is not set
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_CONNECTOR=m
CONFIG_MTD=m
CONFIG_MTD_TESTS=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_AR7_PARTS=m

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

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# 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 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MAP_BANK_WIDTH_8=y
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
CONFIG_MTD_MAP_BANK_WIDTH_32=y
# CONFIG_MTD_CFI_I1 is not set
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
CONFIG_MTD_CFI_I8=y
# CONFIG_MTD_OTP is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
# CONFIG_MTD_ROM is not set
CONFIG_MTD_ABSENT=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_SC520CDP is not set
CONFIG_MTD_NETSC520=m
# CONFIG_MTD_TS5500 is not set
CONFIG_MTD_PCI=m
CONFIG_MTD_INTEL_VR_NOR=m
# CONFIG_MTD_PLATRAM is not set
CONFIG_MTD_LATCH_ADDR=m

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

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND_ECC=m
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_BCH=m
CONFIG_MTD_NAND_ECC_BCH=y
# CONFIG_MTD_SM_COMMON is not set
CONFIG_MTD_NAND_MUSEUM_IDS=y
CONFIG_MTD_NAND_DENALI=m
CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
CONFIG_MTD_NAND_IDS=m
# CONFIG_MTD_NAND_RICOH is not set
# CONFIG_MTD_NAND_CAFE is not set
# CONFIG_MTD_NAND_CS553X is not set
CONFIG_MTD_NAND_NANDSIM=m
CONFIG_MTD_NAND_PLATFORM=m
CONFIG_MTD_ALAUDA=m
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=m
CONFIG_MTD_QINFO_PROBE=m
# CONFIG_MTD_UBI is not set
CONFIG_PARPORT=m
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_OSD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

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

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

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_SCSI_DH=m
CONFIG_SCSI_DH_RDAC=m
# CONFIG_SCSI_DH_HP_SW is not set
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
CONFIG_SCSI_OSD_DEBUG=y
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_ATA_VERBOSE_ERROR is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI is not set
CONFIG_SATA_AHCI_PLATFORM=m
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
# CONFIG_SATA_SIL24 is not set
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_FIREWIRE_NOSY=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_DUMMY is not set
CONFIG_EQUALIZER=m
# CONFIG_NET_FC is not set
CONFIG_MII=m
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#
# CONFIG_ETHERNET is not set
CONFIG_FDDI=m
CONFIG_DEFXX=m
CONFIG_DEFXX_MMIO=y
# CONFIG_SKFP is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
# CONFIG_BROADCOM_PHY is not set
CONFIG_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=m
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=m
CONFIG_PLIP=m
# CONFIG_PPP is not set
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_TR is not set

#
# USB Network Adapters
#
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
CONFIG_USB_CDC_PHONET=m
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# WiMAX Wireless Broadband devices
#
CONFIG_WIMAX_I2400M=m
CONFIG_WIMAX_I2400M_USB=m
# CONFIG_WIMAX_I2400M_SDIO is not set
CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8
CONFIG_WAN=y
CONFIG_LANMEDIA=m
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
CONFIG_HDLC_RAW_ETH=m
CONFIG_HDLC_CISCO=m
# CONFIG_HDLC_FR is not set
# CONFIG_HDLC_PPP is not set

#
# X.25/LAPB support is disabled
#
CONFIG_PCI200SYN=m
CONFIG_WANXL=m
CONFIG_PC300TOO=m
CONFIG_FARSYNC=m
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
# CONFIG_DSCC4_PCI_RST is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
# CONFIG_ISDN_AUDIO is not set

#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set
# CONFIG_ISDN_DIVERSION is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set

#
# Active cards
#
CONFIG_ISDN_CAPI=m
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_MIDDLEWARE=y
# CONFIG_ISDN_CAPI_CAPI20 is not set
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#
# CONFIG_CAPI_AVM is not set
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
# CONFIG_ISDN_DIVAS_USERIDI is not set
# CONFIG_ISDN_DIVAS_MAINT is not set
CONFIG_ISDN_DRV_GIGASET=m
# CONFIG_GIGASET_CAPI is not set
CONFIG_GIGASET_I4L=y
# CONFIG_GIGASET_DUMMYLL is not set
# CONFIG_GIGASET_BASE is not set
CONFIG_GIGASET_M105=m
# CONFIG_GIGASET_M101 is not set
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
# CONFIG_MISDN is not set
CONFIG_PHONE=m
# CONFIG_PHONE_IXJ is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m

#
# 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=m
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ADP5589=m
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_LKKBD=m
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_MAX7359=m
CONFIG_KEYBOARD_MCS=m
# CONFIG_KEYBOARD_MPR121 is not set
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_OPENCORES=m
CONFIG_KEYBOARD_STOWAWAY=m
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_STMPE=m
# CONFIG_KEYBOARD_TC3589X is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
# CONFIG_JOYSTICK_ADI is not set
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
CONFIG_JOYSTICK_WARRIOR=m
# CONFIG_JOYSTICK_MAGELLAN is not set
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_DB9 is not set
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_AS5011=m
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AB8500_PONKEY=m
CONFIG_INPUT_AD714X=m
# CONFIG_INPUT_AD714X_I2C is not set
CONFIG_INPUT_AD714X_SPI=m
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
CONFIG_INPUT_MAX8925_ONKEY=m
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_APANEL is not set
CONFIG_INPUT_WISTRON_BTNS=m
CONFIG_INPUT_ATLAS_BTNS=m
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_WM831X_ON is not set
CONFIG_INPUT_ADXL34X=m
CONFIG_INPUT_ADXL34X_I2C=m
# CONFIG_INPUT_ADXL34X_SPI is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
CONFIG_SERIO_PS2MULT=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_TRACE_ROUTER is not set
CONFIG_TRACE_SINK=m
CONFIG_DEVKMEM=y

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX3107=m
CONFIG_SERIAL_MFD_HSU=m
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=m
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_PRINTER is not set
CONFIG_PPDEV=m
# CONFIG_VIRTIO_CONSOLE is not set
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
# CONFIG_IPMI_WATCHDOG is not set
CONFIG_IPMI_POWEROFF=m
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_HELPER_AUTO is not set
# CONFIG_I2C_SMBUS is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
# CONFIG_I2C_I801 is not set
CONFIG_I2C_ISCH=m
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_SIS5595=m
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

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

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_TINY_USB=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_SCx200_ACB=m
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
CONFIG_SPI_ALTERA=m
CONFIG_SPI_BITBANG=m
CONFIG_SPI_BUTTERFLY=m
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_TOPCLIFF_PCH=m
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_TLE62X0=m

#
# PPS support
#

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
# CONFIG_W1_CON is not set

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS1WM is not set

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
# CONFIG_W1_SLAVE_DS2423 is not set
CONFIG_W1_SLAVE_DS2431=m
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
CONFIG_W1_SLAVE_DS2780=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=m
CONFIG_POWER_SUPPLY_DEBUG=y
# CONFIG_PDA_POWER is not set
# CONFIG_MAX8925_POWER is not set
CONFIG_WM831X_BACKUP=m
CONFIG_WM831X_POWER=m
# CONFIG_WM8350_POWER is not set
CONFIG_TEST_POWER=m
CONFIG_BATTERY_DS2780=m
CONFIG_BATTERY_DS2782=m
# CONFIG_BATTERY_BQ20Z75 is not set
CONFIG_BATTERY_BQ27x00=m
CONFIG_BATTERY_BQ27X00_I2C=y
# CONFIG_BATTERY_BQ27X00_PLATFORM is not set
# CONFIG_BATTERY_DA9030 is not set
CONFIG_BATTERY_MAX17040=m
CONFIG_BATTERY_MAX17042=m
CONFIG_BATTERY_INTEL_MID=m
CONFIG_CHARGER_ISP1704=m
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_MAX8997 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set

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

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_THERMAL=m
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
# CONFIG_SSB_SDIOHOST is not set
CONFIG_SSB_DEBUG=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
CONFIG_HTC_PASIC3=m
CONFIG_TPS6105X=m
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
CONFIG_MFD_STMPE=y
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
CONFIG_PMIC_DA903X=y
# CONFIG_PMIC_ADP5520 is not set
CONFIG_MFD_MAX8925=y
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_WM8400 is not set
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=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
CONFIG_ABX500_CORE=y
CONFIG_AB3100_CORE=y
CONFIG_AB3100_OTP=m
# CONFIG_EZX_PCAP is not set
CONFIG_AB8500_CORE=y
# CONFIG_MFD_CS5535 is not set
CONFIG_LPC_SCH=m
CONFIG_MFD_RDC321X=m
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
CONFIG_MFD_WL1273_CORE=m
CONFIG_MFD_INTEL_MSIC=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=m
CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
CONFIG_REGULATOR_USERSPACE_CONSUMER=m
CONFIG_REGULATOR_GPIO=m
CONFIG_REGULATOR_BQ24022=m
CONFIG_REGULATOR_MAX1586=m
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
CONFIG_REGULATOR_MAX8925=m
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_MAX8997=m
# CONFIG_REGULATOR_WM831X is not set
# CONFIG_REGULATOR_WM8350 is not set
# CONFIG_REGULATOR_WM8994 is not set
CONFIG_REGULATOR_DA903X=m
CONFIG_REGULATOR_LP3971=m
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_AB3100 is not set
# CONFIG_REGULATOR_TPS6105X is not set
CONFIG_REGULATOR_TPS65023=m
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_ISL6271A=m
CONFIG_REGULATOR_AD5398=m
# CONFIG_REGULATOR_AB8500 is not set
CONFIG_REGULATOR_TPS6524X=m
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
# CONFIG_DRM is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB=m
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_MON=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=m
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_ISP1362_HCD=m
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_HCD_ISO=y
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_REALTEK=m
# CONFIG_REALTEK_AUTOPM is not set
CONFIG_USB_STORAGE_DATAFAB=m
# CONFIG_USB_STORAGE_FREECOM is not set
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
# CONFIG_USB_STORAGE_SDDR09 is not set
CONFIG_USB_STORAGE_SDDR55=m
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
CONFIG_USB_STORAGE_ONETOUCH=m
# CONFIG_USB_STORAGE_KARMA is not set
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_USS720=m
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=m
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
CONFIG_USB_RIO500=m
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_IDMOUSE=m
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_LANGWELL_OTG is not set
CONFIG_AB8500_USB=m
CONFIG_MMC=m
CONFIG_MMC_DEBUG=y
CONFIG_MMC_UNSAFE_RESUME=y

#
# MMC/SD/SDIO Card Drivers
#
# CONFIG_MMC_BLOCK is not set
CONFIG_SDIO_UART=m
CONFIG_MMC_TEST=m

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_PLTFM=m
CONFIG_MMC_WBSD=m
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
# CONFIG_MMC_VUB300 is not set
CONFIG_MMC_USHC=m
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=m
CONFIG_LEDS_LP3944=m
CONFIG_LEDS_LP5521=m
# CONFIG_LEDS_LP5523 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_WM831X_STATUS is not set
# CONFIG_LEDS_WM8350 is not set
CONFIG_LEDS_DA903X=m
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_REGULATOR=m
CONFIG_LEDS_BD2802=m
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_TRIGGERS is not set

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

#
# Reporting subsystems
#
CONFIG_EDAC_DEBUG=y
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I82860=m
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
# 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=m
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=m
# CONFIG_RTC_DRV_MAX8925 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_DRV_PCF8563=m
# CONFIG_RTC_DRV_PCF8583 is not set
CONFIG_RTC_DRV_M41T80=m
# CONFIG_RTC_DRV_M41T80_WDT is not set
CONFIG_RTC_DRV_BQ32K=m
CONFIG_RTC_DRV_S35390A=m
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

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

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

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
CONFIG_UIO_NETX=m
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m

#
# Virtio drivers
#
CONFIG_VIRTIO_BALLOON=m
CONFIG_STAGING=y
CONFIG_ECHO=m
# CONFIG_COMEDI is not set
CONFIG_ASUS_OLED=m
CONFIG_PANEL=m
CONFIG_PANEL_PARPORT=0
CONFIG_PANEL_PROFILE=5
CONFIG_PANEL_CHANGE_MESSAGE=y
CONFIG_PANEL_BOOT_MESSAGE=""
CONFIG_RTS_PSTOR=m
# CONFIG_RTS_PSTOR_DEBUG is not set
# CONFIG_RTS5139 is not set
CONFIG_TRANZPORT=m
CONFIG_POHMELFS=m
CONFIG_POHMELFS_DEBUG=y
CONFIG_POHMELFS_CRYPTO=y
CONFIG_SPECTRA=m
CONFIG_SPECTRA_MRST_HW=y
# CONFIG_SPECTRA_MTD is not set
# CONFIG_SPECTRA_EMU is not set
# CONFIG_SPECTRA_MRST_HW_DMA is not set
# CONFIG_HYPERV is not set
CONFIG_VME_BUS=m

#
# VME Bridge Drivers
#
# CONFIG_VME_CA91CX42 is not set
CONFIG_VME_TSI148=m

#
# VME Device Drivers
#
CONFIG_VME_USER=m

#
# VME Board Drivers
#
CONFIG_VMIVME_7805=m
# CONFIG_DX_SEP is not set
CONFIG_IIO=m
CONFIG_IIO_BUFFER=y
CONFIG_IIO_SW_RING=m
CONFIG_IIO_KFIFO_BUF=m
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
# CONFIG_ADIS16201 is not set
# CONFIG_ADIS16203 is not set
CONFIG_ADIS16204=m
# CONFIG_ADIS16209 is not set
# CONFIG_ADIS16220 is not set
CONFIG_ADIS16240=m
# CONFIG_KXSD9 is not set
# CONFIG_LIS3L02DQ is not set
# CONFIG_SCA3000 is not set

#
# Analog to digital convertors
#
CONFIG_AD7150=m
CONFIG_AD7152=m
# CONFIG_AD7291 is not set
CONFIG_AD7298=m
CONFIG_AD799X=m
CONFIG_AD799X_RING_BUFFER=y
CONFIG_AD7476=m
# CONFIG_AD7887 is not set
CONFIG_AD7793=m
CONFIG_AD7746=m
CONFIG_AD7816=m
CONFIG_AD7192=m
# CONFIG_ADT75 is not set
# CONFIG_ADT7310 is not set
# CONFIG_ADT7410 is not set
CONFIG_AD7280=m
CONFIG_MAX1363=m
CONFIG_MAX1363_RING_BUFFER=y

#
# Analog digital bi-direction convertors
#
CONFIG_ADT7316=m
CONFIG_ADT7316_SPI=m
# CONFIG_ADT7316_I2C is not set

#
# Digital to analog convertors
#
CONFIG_AD5624R_SPI=m
# CONFIG_AD5446 is not set
CONFIG_AD5504=m
# CONFIG_AD5791 is not set
# CONFIG_AD5686 is not set

#
# Direct Digital Synthesis
#
CONFIG_AD5930=m
# CONFIG_AD9832 is not set
# CONFIG_AD9834 is not set
CONFIG_AD9850=m
CONFIG_AD9852=m
CONFIG_AD9910=m
# CONFIG_AD9951 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16060 is not set
CONFIG_ADIS16080=m
# CONFIG_ADIS16130 is not set
CONFIG_ADIS16260=m
# CONFIG_ADXRS450 is not set

#
# Network Analyzer, Impedance Converters
#
# CONFIG_AD5933 is not set

#
# Inertial measurement units
#
CONFIG_ADIS16400=m

#
# Light sensors
#
CONFIG_SENSORS_ISL29018=m
CONFIG_SENSORS_TSL2563=m
CONFIG_TSL2583=m

#
# Magnetometer sensors
#
CONFIG_SENSORS_AK8975=m
# CONFIG_SENSORS_HMC5843 is not set

#
# Active energy metering IC
#
CONFIG_ADE7753=m
# CONFIG_ADE7754 is not set
CONFIG_ADE7758=m
CONFIG_ADE7759=m
CONFIG_ADE7854=m
CONFIG_ADE7854_I2C=m
# CONFIG_ADE7854_SPI is not set

#
# Resolver to digital converters
#
CONFIG_AD2S90=m
CONFIG_AD2S1200=m
CONFIG_AD2S1210=m

#
# Triggers - standalone
#
CONFIG_IIO_PERIODIC_RTC_TRIGGER=m
# CONFIG_IIO_SYSFS_TRIGGER is not set
CONFIG_XVMALLOC=y
CONFIG_ZRAM=m
# CONFIG_ZRAM_DEBUG is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_CXT1E1 is not set
# CONFIG_ACPI_QUICKSTART is not set
CONFIG_SBE_2T3E3=m
CONFIG_USB_ENESTORAGE=m
CONFIG_FT1000=m
# CONFIG_FT1000_USB is not set
# CONFIG_SND_INTEL_SST is not set

#
# Speakup console speech
#
CONFIG_SPEAKUP=m
# CONFIG_SPEAKUP_SYNTH_ACNTSA is not set
CONFIG_SPEAKUP_SYNTH_ACNTPC=m
CONFIG_SPEAKUP_SYNTH_APOLLO=m
# CONFIG_SPEAKUP_SYNTH_AUDPTR is not set
# CONFIG_SPEAKUP_SYNTH_BNS is not set
# CONFIG_SPEAKUP_SYNTH_DECTLK is not set
# CONFIG_SPEAKUP_SYNTH_DECEXT is not set
# CONFIG_SPEAKUP_SYNTH_DECPC is not set
# CONFIG_SPEAKUP_SYNTH_DTLK is not set
CONFIG_SPEAKUP_SYNTH_KEYPC=m
# CONFIG_SPEAKUP_SYNTH_LTLK is not set
CONFIG_SPEAKUP_SYNTH_SOFT=m
CONFIG_SPEAKUP_SYNTH_SPKOUT=m
CONFIG_SPEAKUP_SYNTH_TXPRT=m
# CONFIG_SPEAKUP_SYNTH_DUMMY is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
CONFIG_ASUS_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP is not set
CONFIG_HP_ACCEL=m
# CONFIG_MSI_LAPTOP is not set
CONFIG_PANASONIC_LAPTOP=m
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
CONFIG_SENSORS_HDAPS=m
CONFIG_INTEL_MENLOW=m
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=m
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_TOSHIBA_BT_RFKILL is not set
CONFIG_ACPI_CMPC=m
CONFIG_INTEL_SCU_IPC=y
# CONFIG_INTEL_SCU_IPC_UTIL is not set
# CONFIG_INTEL_MID_POWER_BUTTON is not set
CONFIG_INTEL_MFLD_THERMAL=m
CONFIG_RAR_REGISTER=y
CONFIG_INTEL_IPS=m
CONFIG_IBM_RTL=m
# CONFIG_XO15_EBOOK is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_DW_APB_TIMER=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_VIRT_DRIVERS=y

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

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
# 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=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_DEBUG=y
CONFIG_JBD=m
CONFIG_JBD2=m
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
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 is not set
CONFIG_GFS2_FS=m
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY_USER is not set
CONFIG_FANOTIFY=y
# CONFIG_QUOTA is not set
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS 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 is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_HFSPLUS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=m
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_DEBUG=y
# CONFIG_EXOFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
# CONFIG_NLS_CODEPAGE_863 is not set
CONFIG_NLS_CODEPAGE_864=m
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_SLUB_DEBUG_ON=y
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_RCU_TORTURE_TEST=m
# CONFIG_KPROBES_SANITY_TEST is not set
CONFIG_BACKTRACE_SELF_TEST=m
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_USER_STACKTRACE_SUPPORT=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_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
CONFIG_DMA_API_DEBUG=y
# CONFIG_ATOMIC64_SELFTEST is not set
CONFIG_SAMPLES=y
# CONFIG_SAMPLE_KOBJECT is not set
CONFIG_SAMPLE_KPROBES=m
# CONFIG_SAMPLE_KRETPROBES is not set
CONFIG_SAMPLE_HW_BREAKPOINT=m
CONFIG_SAMPLE_KFIFO=m
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_MRST is not set
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
CONFIG_DEBUG_NX_TEST=m
CONFIG_DOUBLEFAULT=y
CONFIG_IOMMU_STRESS=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
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_CPA_DEBUG=y
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=m

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

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

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

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=m

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

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_SEED=m
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

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

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
# CONFIG_KVM_INTEL is not set
CONFIG_KVM_AMD=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_BCH=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y
CONFIG_CORDIC=m

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-11 18:49 ` linux-next: Tree for Oct 11 (mmc) Randy Dunlap
@ 2011-10-11 19:31   ` Andrei Warkentin
  2011-10-11 21:59     ` Randy Dunlap
  0 siblings, 1 reply; 137+ messages in thread
From: Andrei Warkentin @ 2011-10-11 19:31 UTC (permalink / raw)
  To: Randy Dunlap, Namjae Jeon
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell

Hi Randy,

----- Original Message -----
> From: "Randy Dunlap" <rdunlap@xenotime.net>
> To: "Stephen Rothwell" <sfr@canb.auug.org.au>
> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
> <cjb@laptop.org>
> Sent: Tuesday, October 11, 2011 2:49:39 PM
> Subject: Re: linux-next: Tree for Oct 11 (mmc)
> 
> On 10/11/11 02:11, Stephen Rothwell wrote:
> > Hi all,
> > 
> > The linux-next tree is now available from
> > git://github.com/sfrothwell/linux-next.git as a temporary measure
> > while
> > the kernel.org servers are unavailable.
> > 
> > It may also turn up on git.kernel.org (depending on the mirroring).
> >  The
> > patch set is still absent, however.
> > 
> > Changes since 20111007:
> 
> 
> When CONFIG_BLOCK is not enabled:
> 
> In file included from
> next-2011-1011/drivers/mmc/card/sdio_uart.c:43:0:
> next-2011-1011/include/linux/mmc/card.h:175:12: error:
> 'DISK_NAME_LEN' undeclared here (not in a function)
> 
> Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
> However, the same problem occurs in mmc/core/core.c:
> 

Because linux/genhd is now included, oops. I'm pretty positive this is due to the "mmc : general purpose partition support" patch pulled recently. I am adding NamJae, who was the author.

> In file included from next-2011-1011/drivers/mmc/core/core.c:30:0:
> next-2011-1011/include/linux/mmc/card.h:175:12: error:
> 'DISK_NAME_LEN' undeclared here (not in a function)
> 
> Should mmc/core/ depend on BLOCK?  or should it just be made
> to build even when BLOCK is not enabled?
> 

I don't think there should be a direct dependency on BLOCK. I have two suggestions -
1) Have our own define similar to (and in fact smaller):
   linux/genhd.h:#define DISK_NAME_LEN                     32
2) Put the MMC physical partition code under an #ifdef CONFIG_BLOCK, which is a reasonable
   proposition, given that there wouldn't be any need to parse physical partition info if
   it would never be consumed by the MMC block driver.

Thoughts?

A

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

* Re: linux-next: Tree for Oct 11 (gpio regulator)
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
                   ` (3 preceding siblings ...)
  2011-10-11 19:26 ` linux-next: Tree for Oct 11 (mfd/intel_msic.c) Randy Dunlap
@ 2011-10-11 19:32 ` Randy Dunlap
  2011-10-11 20:22   ` Heiko Stübner
  2011-10-11 20:37 ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Randy Dunlap
  2011-10-11 20:45   ` Randy Dunlap
  6 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 19:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, LKML, Heiko Stuebner, Liam Girdwood, Mark Brown

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

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:
> 
> The gpio tree still has its build failure so I used the version from
> next-20111005.

(maybe fixed there?)
(i386 build)

drivers/regulator/gpio-regulator.c:121:3: error: invalid use of undefined type 'struct gpio'
drivers/regulator/gpio-regulator.c:121:29: error: dereferencing pointer to incomplete type
drivers/regulator/gpio-regulator.c:191:32: error: invalid application of 'sizeof' to incomplete type 'struct gpio' 
drivers/regulator/gpio-regulator.c:281:3: error: invalid use of undefined type 'struct gpio'
drivers/regulator/gpio-regulator.c:281:20: error: dereferencing pointer to incomplete type

(GPIOLIB is not enabled.)
Full randconfig file is attached.


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

[-- Attachment #2: config-r2161 --]
[-- Type: text/plain, Size: 57688 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.1.0-rc9 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_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=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=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 is not set
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 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
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 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
# CONFIG_AUDIT is not set
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 is not set

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
# CONFIG_CGROUP_TASK_COUNTER is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=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
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y

#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=m
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PREEMPT_NOTIFIERS=y
# 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_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
# CONFIG_SMP is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_X86_INTEL_MID=y
CONFIG_X86_MRST=y
CONFIG_X86_RDC321X=y
CONFIG_X86_32_IRIS=m
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
# CONFIG_XEN_PRIVILEGED_GUEST is not set
CONFIG_KVM_CLOCK=y
# CONFIG_KVM_GUEST is not set
# CONFIG_LGUEST_GUEST is not set
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_CMPXCHG_DOUBLE=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_HPET_TIMER=y
CONFIG_APB_TIMER=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER 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_PREEMPT_COUNT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
CONFIG_I8K=m
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_SCHED_HRTICK is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_COMPAT_VDSO=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_CMDLINE_OVERRIDE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
# CONFIG_ACPI_PROC_EVENT is not set
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_SBS=m
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set
# CONFIG_APM 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

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEBUG=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_PCI_STUB=m
# CONFIG_HT_IRQ is not set
CONFIG_PCI_IOV=y
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_ALIX is not set
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
CONFIG_HOTPLUG_PCI_IBM=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
# CONFIG_HOTPLUG_PCI_CPCI_GENERIC is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_HAVE_ATOMIC_IOMAP=y
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 is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
CONFIG_LLC2=m
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
# CONFIG_DEV_APPLETALK is not set
CONFIG_PHONET=m
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
CONFIG_CAN_GW=m

#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
# CONFIG_CAN_SLCAN is not set
# CONFIG_CAN_DEV is not set
CONFIG_CAN_DEBUG_DEVICES=y
CONFIG_IRDA=m

#
# IrDA protocols
#
# CONFIG_IRLAN is not set
# CONFIG_IRCOMM is not set
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
# CONFIG_ESI_DONGLE is not set
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
# CONFIG_TOIM3232_DONGLE is not set
CONFIG_LITELINK_DONGLE=m

#
# FIR device drivers
#
# CONFIG_USB_IRDA is not set
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
CONFIG_TOSHIBA_FIR=m
# CONFIG_VIA_FIR is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=m
# CONFIG_BT_RFCOMM_TTY is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_CMTP is not set

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
# CONFIG_BT_HCIUART_H4 is not set
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_ATH3K is not set
# CONFIG_BT_HCIUART_LL is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=y
CONFIG_RFKILL_REGULATOR=m
CONFIG_NET_9P=m
# CONFIG_NET_9P_VIRTIO is not set
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_CONNECTOR=m
CONFIG_MTD=m
CONFIG_MTD_TESTS=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_AR7_PARTS=m

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

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# 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 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MAP_BANK_WIDTH_8=y
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
CONFIG_MTD_MAP_BANK_WIDTH_32=y
# CONFIG_MTD_CFI_I1 is not set
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
CONFIG_MTD_CFI_I8=y
# CONFIG_MTD_OTP is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
# CONFIG_MTD_ROM is not set
CONFIG_MTD_ABSENT=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_SC520CDP is not set
CONFIG_MTD_NETSC520=m
# CONFIG_MTD_TS5500 is not set
CONFIG_MTD_PCI=m
CONFIG_MTD_INTEL_VR_NOR=m
# CONFIG_MTD_PLATRAM is not set
CONFIG_MTD_LATCH_ADDR=m

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

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND_ECC=m
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_BCH=m
CONFIG_MTD_NAND_ECC_BCH=y
# CONFIG_MTD_SM_COMMON is not set
CONFIG_MTD_NAND_MUSEUM_IDS=y
CONFIG_MTD_NAND_DENALI=m
CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
CONFIG_MTD_NAND_IDS=m
# CONFIG_MTD_NAND_RICOH is not set
# CONFIG_MTD_NAND_CAFE is not set
# CONFIG_MTD_NAND_CS553X is not set
CONFIG_MTD_NAND_NANDSIM=m
CONFIG_MTD_NAND_PLATFORM=m
CONFIG_MTD_ALAUDA=m
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=m
CONFIG_MTD_QINFO_PROBE=m
# CONFIG_MTD_UBI is not set
CONFIG_PARPORT=m
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_OSD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

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

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

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_SCSI_DH=m
CONFIG_SCSI_DH_RDAC=m
# CONFIG_SCSI_DH_HP_SW is not set
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
CONFIG_SCSI_OSD_DEBUG=y
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_ATA_VERBOSE_ERROR is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI is not set
CONFIG_SATA_AHCI_PLATFORM=m
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
# CONFIG_SATA_SIL24 is not set
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_FIREWIRE_NOSY=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_DUMMY is not set
CONFIG_EQUALIZER=m
# CONFIG_NET_FC is not set
CONFIG_MII=m
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#
# CONFIG_ETHERNET is not set
CONFIG_FDDI=m
CONFIG_DEFXX=m
CONFIG_DEFXX_MMIO=y
# CONFIG_SKFP is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
# CONFIG_BROADCOM_PHY is not set
CONFIG_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=m
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=m
CONFIG_PLIP=m
# CONFIG_PPP is not set
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_TR is not set

#
# USB Network Adapters
#
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
CONFIG_USB_CDC_PHONET=m
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# WiMAX Wireless Broadband devices
#
CONFIG_WIMAX_I2400M=m
CONFIG_WIMAX_I2400M_USB=m
# CONFIG_WIMAX_I2400M_SDIO is not set
CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8
CONFIG_WAN=y
CONFIG_LANMEDIA=m
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
CONFIG_HDLC_RAW_ETH=m
CONFIG_HDLC_CISCO=m
# CONFIG_HDLC_FR is not set
# CONFIG_HDLC_PPP is not set

#
# X.25/LAPB support is disabled
#
CONFIG_PCI200SYN=m
CONFIG_WANXL=m
CONFIG_PC300TOO=m
CONFIG_FARSYNC=m
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
# CONFIG_DSCC4_PCI_RST is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
# CONFIG_ISDN_AUDIO is not set

#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set
# CONFIG_ISDN_DIVERSION is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set

#
# Active cards
#
CONFIG_ISDN_CAPI=m
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_MIDDLEWARE=y
# CONFIG_ISDN_CAPI_CAPI20 is not set
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#
# CONFIG_CAPI_AVM is not set
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
# CONFIG_ISDN_DIVAS_USERIDI is not set
# CONFIG_ISDN_DIVAS_MAINT is not set
CONFIG_ISDN_DRV_GIGASET=m
# CONFIG_GIGASET_CAPI is not set
CONFIG_GIGASET_I4L=y
# CONFIG_GIGASET_DUMMYLL is not set
# CONFIG_GIGASET_BASE is not set
CONFIG_GIGASET_M105=m
# CONFIG_GIGASET_M101 is not set
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
# CONFIG_MISDN is not set
CONFIG_PHONE=m
# CONFIG_PHONE_IXJ is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m

#
# 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=m
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ADP5589=m
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_LKKBD=m
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_MAX7359=m
CONFIG_KEYBOARD_MCS=m
# CONFIG_KEYBOARD_MPR121 is not set
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_OPENCORES=m
CONFIG_KEYBOARD_STOWAWAY=m
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_STMPE=m
# CONFIG_KEYBOARD_TC3589X is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
# CONFIG_JOYSTICK_ADI is not set
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
CONFIG_JOYSTICK_WARRIOR=m
# CONFIG_JOYSTICK_MAGELLAN is not set
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_DB9 is not set
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_AS5011=m
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AB8500_PONKEY=m
CONFIG_INPUT_AD714X=m
# CONFIG_INPUT_AD714X_I2C is not set
CONFIG_INPUT_AD714X_SPI=m
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
CONFIG_INPUT_MAX8925_ONKEY=m
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_APANEL is not set
CONFIG_INPUT_WISTRON_BTNS=m
CONFIG_INPUT_ATLAS_BTNS=m
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_WM831X_ON is not set
CONFIG_INPUT_ADXL34X=m
CONFIG_INPUT_ADXL34X_I2C=m
# CONFIG_INPUT_ADXL34X_SPI is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
CONFIG_SERIO_PS2MULT=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_TRACE_ROUTER is not set
CONFIG_TRACE_SINK=m
CONFIG_DEVKMEM=y

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX3107=m
CONFIG_SERIAL_MFD_HSU=m
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=m
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_PRINTER is not set
CONFIG_PPDEV=m
# CONFIG_VIRTIO_CONSOLE is not set
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
# CONFIG_IPMI_WATCHDOG is not set
CONFIG_IPMI_POWEROFF=m
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_HELPER_AUTO is not set
# CONFIG_I2C_SMBUS is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
# CONFIG_I2C_I801 is not set
CONFIG_I2C_ISCH=m
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_SIS5595=m
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

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

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_TINY_USB=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_SCx200_ACB=m
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
CONFIG_SPI_ALTERA=m
CONFIG_SPI_BITBANG=m
CONFIG_SPI_BUTTERFLY=m
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_TOPCLIFF_PCH=m
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_TLE62X0=m

#
# PPS support
#

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
# CONFIG_W1_CON is not set

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS1WM is not set

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
# CONFIG_W1_SLAVE_DS2423 is not set
CONFIG_W1_SLAVE_DS2431=m
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
CONFIG_W1_SLAVE_DS2780=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=m
CONFIG_POWER_SUPPLY_DEBUG=y
# CONFIG_PDA_POWER is not set
# CONFIG_MAX8925_POWER is not set
CONFIG_WM831X_BACKUP=m
CONFIG_WM831X_POWER=m
# CONFIG_WM8350_POWER is not set
CONFIG_TEST_POWER=m
CONFIG_BATTERY_DS2780=m
CONFIG_BATTERY_DS2782=m
# CONFIG_BATTERY_BQ20Z75 is not set
CONFIG_BATTERY_BQ27x00=m
CONFIG_BATTERY_BQ27X00_I2C=y
# CONFIG_BATTERY_BQ27X00_PLATFORM is not set
# CONFIG_BATTERY_DA9030 is not set
CONFIG_BATTERY_MAX17040=m
CONFIG_BATTERY_MAX17042=m
CONFIG_BATTERY_INTEL_MID=m
CONFIG_CHARGER_ISP1704=m
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_MAX8997 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set

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

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_THERMAL=m
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
# CONFIG_SSB_SDIOHOST is not set
CONFIG_SSB_DEBUG=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
CONFIG_HTC_PASIC3=m
CONFIG_TPS6105X=m
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
CONFIG_MFD_STMPE=y
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
CONFIG_PMIC_DA903X=y
# CONFIG_PMIC_ADP5520 is not set
CONFIG_MFD_MAX8925=y
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_WM8400 is not set
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=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
CONFIG_ABX500_CORE=y
CONFIG_AB3100_CORE=y
CONFIG_AB3100_OTP=m
# CONFIG_EZX_PCAP is not set
CONFIG_AB8500_CORE=y
# CONFIG_MFD_CS5535 is not set
CONFIG_LPC_SCH=m
CONFIG_MFD_RDC321X=m
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
CONFIG_MFD_WL1273_CORE=m
CONFIG_MFD_INTEL_MSIC=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=m
CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
CONFIG_REGULATOR_USERSPACE_CONSUMER=m
CONFIG_REGULATOR_GPIO=m
CONFIG_REGULATOR_BQ24022=m
CONFIG_REGULATOR_MAX1586=m
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
CONFIG_REGULATOR_MAX8925=m
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_MAX8997=m
# CONFIG_REGULATOR_WM831X is not set
# CONFIG_REGULATOR_WM8350 is not set
# CONFIG_REGULATOR_WM8994 is not set
CONFIG_REGULATOR_DA903X=m
CONFIG_REGULATOR_LP3971=m
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_AB3100 is not set
# CONFIG_REGULATOR_TPS6105X is not set
CONFIG_REGULATOR_TPS65023=m
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_ISL6271A=m
CONFIG_REGULATOR_AD5398=m
# CONFIG_REGULATOR_AB8500 is not set
CONFIG_REGULATOR_TPS6524X=m
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
# CONFIG_DRM is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB=m
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_MON=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=m
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_ISP1362_HCD=m
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_HCD_ISO=y
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_REALTEK=m
# CONFIG_REALTEK_AUTOPM is not set
CONFIG_USB_STORAGE_DATAFAB=m
# CONFIG_USB_STORAGE_FREECOM is not set
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
# CONFIG_USB_STORAGE_SDDR09 is not set
CONFIG_USB_STORAGE_SDDR55=m
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
CONFIG_USB_STORAGE_ONETOUCH=m
# CONFIG_USB_STORAGE_KARMA is not set
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_USS720=m
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=m
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
CONFIG_USB_RIO500=m
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_IDMOUSE=m
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_LANGWELL_OTG is not set
CONFIG_AB8500_USB=m
CONFIG_MMC=m
CONFIG_MMC_DEBUG=y
CONFIG_MMC_UNSAFE_RESUME=y

#
# MMC/SD/SDIO Card Drivers
#
# CONFIG_MMC_BLOCK is not set
CONFIG_SDIO_UART=m
CONFIG_MMC_TEST=m

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_PLTFM=m
CONFIG_MMC_WBSD=m
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
# CONFIG_MMC_VUB300 is not set
CONFIG_MMC_USHC=m
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=m
CONFIG_LEDS_LP3944=m
CONFIG_LEDS_LP5521=m
# CONFIG_LEDS_LP5523 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_WM831X_STATUS is not set
# CONFIG_LEDS_WM8350 is not set
CONFIG_LEDS_DA903X=m
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_REGULATOR=m
CONFIG_LEDS_BD2802=m
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_TRIGGERS is not set

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

#
# Reporting subsystems
#
CONFIG_EDAC_DEBUG=y
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I82860=m
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
# 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=m
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=m
# CONFIG_RTC_DRV_MAX8925 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_DRV_PCF8563=m
# CONFIG_RTC_DRV_PCF8583 is not set
CONFIG_RTC_DRV_M41T80=m
# CONFIG_RTC_DRV_M41T80_WDT is not set
CONFIG_RTC_DRV_BQ32K=m
CONFIG_RTC_DRV_S35390A=m
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

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

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

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
CONFIG_UIO_NETX=m
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m

#
# Virtio drivers
#
CONFIG_VIRTIO_BALLOON=m
CONFIG_STAGING=y
CONFIG_ECHO=m
# CONFIG_COMEDI is not set
CONFIG_ASUS_OLED=m
CONFIG_PANEL=m
CONFIG_PANEL_PARPORT=0
CONFIG_PANEL_PROFILE=5
CONFIG_PANEL_CHANGE_MESSAGE=y
CONFIG_PANEL_BOOT_MESSAGE=""
CONFIG_RTS_PSTOR=m
# CONFIG_RTS_PSTOR_DEBUG is not set
# CONFIG_RTS5139 is not set
CONFIG_TRANZPORT=m
CONFIG_POHMELFS=m
CONFIG_POHMELFS_DEBUG=y
CONFIG_POHMELFS_CRYPTO=y
CONFIG_SPECTRA=m
CONFIG_SPECTRA_MRST_HW=y
# CONFIG_SPECTRA_MTD is not set
# CONFIG_SPECTRA_EMU is not set
# CONFIG_SPECTRA_MRST_HW_DMA is not set
# CONFIG_HYPERV is not set
CONFIG_VME_BUS=m

#
# VME Bridge Drivers
#
# CONFIG_VME_CA91CX42 is not set
CONFIG_VME_TSI148=m

#
# VME Device Drivers
#
CONFIG_VME_USER=m

#
# VME Board Drivers
#
CONFIG_VMIVME_7805=m
# CONFIG_DX_SEP is not set
CONFIG_IIO=m
CONFIG_IIO_BUFFER=y
CONFIG_IIO_SW_RING=m
CONFIG_IIO_KFIFO_BUF=m
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
# CONFIG_ADIS16201 is not set
# CONFIG_ADIS16203 is not set
CONFIG_ADIS16204=m
# CONFIG_ADIS16209 is not set
# CONFIG_ADIS16220 is not set
CONFIG_ADIS16240=m
# CONFIG_KXSD9 is not set
# CONFIG_LIS3L02DQ is not set
# CONFIG_SCA3000 is not set

#
# Analog to digital convertors
#
CONFIG_AD7150=m
CONFIG_AD7152=m
# CONFIG_AD7291 is not set
CONFIG_AD7298=m
CONFIG_AD799X=m
CONFIG_AD799X_RING_BUFFER=y
CONFIG_AD7476=m
# CONFIG_AD7887 is not set
CONFIG_AD7793=m
CONFIG_AD7746=m
CONFIG_AD7816=m
CONFIG_AD7192=m
# CONFIG_ADT75 is not set
# CONFIG_ADT7310 is not set
# CONFIG_ADT7410 is not set
CONFIG_AD7280=m
CONFIG_MAX1363=m
CONFIG_MAX1363_RING_BUFFER=y

#
# Analog digital bi-direction convertors
#
CONFIG_ADT7316=m
CONFIG_ADT7316_SPI=m
# CONFIG_ADT7316_I2C is not set

#
# Digital to analog convertors
#
CONFIG_AD5624R_SPI=m
# CONFIG_AD5446 is not set
CONFIG_AD5504=m
# CONFIG_AD5791 is not set
# CONFIG_AD5686 is not set

#
# Direct Digital Synthesis
#
CONFIG_AD5930=m
# CONFIG_AD9832 is not set
# CONFIG_AD9834 is not set
CONFIG_AD9850=m
CONFIG_AD9852=m
CONFIG_AD9910=m
# CONFIG_AD9951 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16060 is not set
CONFIG_ADIS16080=m
# CONFIG_ADIS16130 is not set
CONFIG_ADIS16260=m
# CONFIG_ADXRS450 is not set

#
# Network Analyzer, Impedance Converters
#
# CONFIG_AD5933 is not set

#
# Inertial measurement units
#
CONFIG_ADIS16400=m

#
# Light sensors
#
CONFIG_SENSORS_ISL29018=m
CONFIG_SENSORS_TSL2563=m
CONFIG_TSL2583=m

#
# Magnetometer sensors
#
CONFIG_SENSORS_AK8975=m
# CONFIG_SENSORS_HMC5843 is not set

#
# Active energy metering IC
#
CONFIG_ADE7753=m
# CONFIG_ADE7754 is not set
CONFIG_ADE7758=m
CONFIG_ADE7759=m
CONFIG_ADE7854=m
CONFIG_ADE7854_I2C=m
# CONFIG_ADE7854_SPI is not set

#
# Resolver to digital converters
#
CONFIG_AD2S90=m
CONFIG_AD2S1200=m
CONFIG_AD2S1210=m

#
# Triggers - standalone
#
CONFIG_IIO_PERIODIC_RTC_TRIGGER=m
# CONFIG_IIO_SYSFS_TRIGGER is not set
CONFIG_XVMALLOC=y
CONFIG_ZRAM=m
# CONFIG_ZRAM_DEBUG is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_CXT1E1 is not set
# CONFIG_ACPI_QUICKSTART is not set
CONFIG_SBE_2T3E3=m
CONFIG_USB_ENESTORAGE=m
CONFIG_FT1000=m
# CONFIG_FT1000_USB is not set
# CONFIG_SND_INTEL_SST is not set

#
# Speakup console speech
#
CONFIG_SPEAKUP=m
# CONFIG_SPEAKUP_SYNTH_ACNTSA is not set
CONFIG_SPEAKUP_SYNTH_ACNTPC=m
CONFIG_SPEAKUP_SYNTH_APOLLO=m
# CONFIG_SPEAKUP_SYNTH_AUDPTR is not set
# CONFIG_SPEAKUP_SYNTH_BNS is not set
# CONFIG_SPEAKUP_SYNTH_DECTLK is not set
# CONFIG_SPEAKUP_SYNTH_DECEXT is not set
# CONFIG_SPEAKUP_SYNTH_DECPC is not set
# CONFIG_SPEAKUP_SYNTH_DTLK is not set
CONFIG_SPEAKUP_SYNTH_KEYPC=m
# CONFIG_SPEAKUP_SYNTH_LTLK is not set
CONFIG_SPEAKUP_SYNTH_SOFT=m
CONFIG_SPEAKUP_SYNTH_SPKOUT=m
CONFIG_SPEAKUP_SYNTH_TXPRT=m
# CONFIG_SPEAKUP_SYNTH_DUMMY is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
CONFIG_ASUS_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP is not set
CONFIG_HP_ACCEL=m
# CONFIG_MSI_LAPTOP is not set
CONFIG_PANASONIC_LAPTOP=m
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
CONFIG_SENSORS_HDAPS=m
CONFIG_INTEL_MENLOW=m
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=m
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_TOSHIBA_BT_RFKILL is not set
CONFIG_ACPI_CMPC=m
CONFIG_INTEL_SCU_IPC=y
# CONFIG_INTEL_SCU_IPC_UTIL is not set
# CONFIG_INTEL_MID_POWER_BUTTON is not set
CONFIG_INTEL_MFLD_THERMAL=m
CONFIG_RAR_REGISTER=y
CONFIG_INTEL_IPS=m
CONFIG_IBM_RTL=m
# CONFIG_XO15_EBOOK is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_DW_APB_TIMER=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_VIRT_DRIVERS=y

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

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
# 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=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_DEBUG=y
CONFIG_JBD=m
CONFIG_JBD2=m
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
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 is not set
CONFIG_GFS2_FS=m
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY_USER is not set
CONFIG_FANOTIFY=y
# CONFIG_QUOTA is not set
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS 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 is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_HFSPLUS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=m
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_DEBUG=y
# CONFIG_EXOFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
# CONFIG_NLS_CODEPAGE_863 is not set
CONFIG_NLS_CODEPAGE_864=m
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_SLUB_DEBUG_ON=y
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_RCU_TORTURE_TEST=m
# CONFIG_KPROBES_SANITY_TEST is not set
CONFIG_BACKTRACE_SELF_TEST=m
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_USER_STACKTRACE_SUPPORT=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_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
CONFIG_DMA_API_DEBUG=y
# CONFIG_ATOMIC64_SELFTEST is not set
CONFIG_SAMPLES=y
# CONFIG_SAMPLE_KOBJECT is not set
CONFIG_SAMPLE_KPROBES=m
# CONFIG_SAMPLE_KRETPROBES is not set
CONFIG_SAMPLE_HW_BREAKPOINT=m
CONFIG_SAMPLE_KFIFO=m
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_MRST is not set
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
CONFIG_DEBUG_NX_TEST=m
CONFIG_DOUBLEFAULT=y
CONFIG_IOMMU_STRESS=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
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_CPA_DEBUG=y
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=m

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

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

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

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=m

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

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_SEED=m
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

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

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
# CONFIG_KVM_INTEL is not set
CONFIG_KVM_AMD=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_BCH=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y
CONFIG_CORDIC=m

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

* Re: linux-next: Tree for Oct 11 (gpio regulator)
  2011-10-11 19:32 ` linux-next: Tree for Oct 11 (gpio regulator) Randy Dunlap
@ 2011-10-11 20:22   ` Heiko Stübner
  0 siblings, 0 replies; 137+ messages in thread
From: Heiko Stübner @ 2011-10-11 20:22 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, Liam Girdwood, Mark Brown

Hi Randy,

Am Dienstag 11 Oktober 2011, 21:32:11 schrieb Randy Dunlap:
> On 10/11/11 02:11, Stephen Rothwell wrote:
> > Hi all,
> > 
> > The linux-next tree is now available from
> > git://github.com/sfrothwell/linux-next.git as a temporary measure while
> > the kernel.org servers are unavailable.
> > 
> > It may also turn up on git.kernel.org (depending on the mirroring).  The
> > patch set is still absent, however.
> > 
> > Changes since 20111007:
> > 
> > The gpio tree still has its build failure so I used the version from
> > next-20111005.
> 
> (maybe fixed there?)
> (i386 build)
> 
> drivers/regulator/gpio-regulator.c:121:3: error: invalid use of undefined
> type 'struct gpio' drivers/regulator/gpio-regulator.c:121:29: error:
> dereferencing pointer to incomplete type
> drivers/regulator/gpio-regulator.c:191:32: error: invalid application of
> 'sizeof' to incomplete type 'struct gpio'
> drivers/regulator/gpio-regulator.c:281:3: error: invalid use of undefined
> type 'struct gpio' drivers/regulator/gpio-regulator.c:281:20: error:
> dereferencing pointer to incomplete type
> 
> (GPIOLIB is not enabled.)
> Full randconfig file is attached.

thanks for catching this.

I would guess the Kconfig entry of the gpio-regulator needs a
		"depends on GENERIC_GPIO"
as it won't be able to function without gpiolib - correct?

Heiko

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

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
  2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
                   ` (4 preceding siblings ...)
  2011-10-11 19:32 ` linux-next: Tree for Oct 11 (gpio regulator) Randy Dunlap
@ 2011-10-11 20:37 ` Randy Dunlap
  2011-10-14 17:58   ` Randy Dunlap
  2011-10-11 20:45   ` Randy Dunlap
  6 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 20:37 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, linux-ide

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

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:
> 
> Removed tree: ide (at the maintainer's request)


drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)

Full randconfig file is attached.


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

[-- Attachment #2: config-r2167 --]
[-- Type: text/plain, Size: 51414 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.1.0-rc9 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_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=y
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_GENERIC_GPIO=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 is not set
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 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_ARCH_CPU_PROBE_RELEASE=y
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_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
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=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_FHANDLE=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
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_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ 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=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# 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_UID16 is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
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_USE_GENERIC_SMP_HELPERS=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
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=1
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=m
# CONFIG_IOSCHED_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=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# 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=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# 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=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# 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=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_BIGSMP=y
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_X86_32_IRIS is not set
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
# CONFIG_XEN_PRIVILEGED_GUEST is not set
# CONFIG_KVM_CLOCK is not set
CONFIG_KVM_GUEST=y
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_CMPXCHG_DOUBLE=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
# CONFIG_X86_PPRO_FENCE is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PROCESSOR_SELECT=y
CONFIG_CPU_SUP_INTEL=y
# CONFIG_CPU_SUP_CYRIX_32 is not set
# CONFIG_CPU_SUP_AMD is not set
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_CPU_SUP_TRANSMETA_32 is not set
# CONFIG_CPU_SUP_UMC_32 is not set
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
CONFIG_NR_CPUS=32
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
CONFIG_X86_MCE_AMD=y
# CONFIG_X86_ANCIENT_MCE is not set
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
# CONFIG_VM86 is not set
CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_HIGHPTE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MATH_EMULATION=y
# CONFIG_MTRR is not set
# CONFIG_ARCH_RANDOM is not set
# CONFIG_SECCOMP is not set
CONFIG_CC_STACKPROTECTOR=y
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_SCHED_HRTICK is not set
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_CMDLINE_OVERRIDE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SFI=y
CONFIG_X86_APM_BOOT=y
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_ALLOW_INTS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=m
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# x86 CPU frequency scaling drivers
#
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_LONGRUN is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# 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
# CONFIG_ISA is not set
CONFIG_MCA=y
# CONFIG_MCA_LEGACY is not set
# CONFIG_SCx200 is not set
CONFIG_OLPC=y
# CONFIG_ALIX is not set
# CONFIG_PCCARD is not set

#
# Executable file formats / Emulations
#
# CONFIG_BINFMT_ELF is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_HAVE_ATOMIC_IOMAP=y
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=y
# CONFIG_NETFILTER is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_DECNET=m
CONFIG_LLC=m
CONFIG_LLC2=m
CONFIG_IPX=m
CONFIG_IPX_INTERN=y
# CONFIG_ATALK is not set
# CONFIG_PHONET is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
CONFIG_NET_SCH_SFQ=m
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_FW=m
# CONFIG_NET_CLS_U32 is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y

#
# Network testing
#
# CONFIG_HAMRADIO is not set
CONFIG_CAN=m
# CONFIG_CAN_RAW is not set
# CONFIG_CAN_BCM is not set
CONFIG_CAN_GW=m

#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
CONFIG_CAN_SLCAN=m
CONFIG_CAN_DEV=m
# CONFIG_CAN_CALC_BITTIMING is not set
CONFIG_CAN_MCP251X=m
# CONFIG_CAN_SJA1000 is not set
CONFIG_CAN_C_CAN=m
CONFIG_CAN_C_CAN_PLATFORM=m
CONFIG_CAN_SOFTING=m
# CONFIG_CAN_DEBUG_DEVICES is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=m
# CONFIG_BT_RFCOMM_TTY is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_CMTP is not set

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_BCSP is not set
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
# CONFIG_BT_MRVL_SDIO is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_LIB80211=m
CONFIG_LIB80211_DEBUG=y

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
CONFIG_CAIF=m
# CONFIG_CAIF_DEBUG is not set
CONFIG_CAIF_NETDEV=m

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_REGMAP_SPI=y
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_OF_PROMTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
CONFIG_OF_I2C=m
CONFIG_OF_NET=y
CONFIG_OF_SPI=y
CONFIG_OF_MDIO=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
# CONFIG_PARIDE_PD is not set
CONFIG_PARIDE_PCD=m
# CONFIG_PARIDE_PF is not set
CONFIG_PARIDE_PT=m
# CONFIG_PARIDE_PG is not set

#
# Parallel IDE protocol modules
#
# CONFIG_PARIDE_ATEN is not set
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
# CONFIG_PARIDE_KTTI is not set
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_XIP=y
# CONFIG_CDROM_PKTCDVD is not set
CONFIG_ATA_OVER_ETH=m
# CONFIG_BLK_DEV_HD is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_MISC_DEVICES=y
# CONFIG_AD525X_DPOT is not set
# CONFIG_ENCLOSURE_SERVICES is not set
CONFIG_APDS9802ALS=m
# CONFIG_ISL29003 is not set
CONFIG_ISL29020=m
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=m
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
CONFIG_TI_DAC7512=m
# CONFIG_VMWARE_BALLOON is not set
CONFIG_BMP085=m
# CONFIG_USB_SWITCH_FSA9480 is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_AT25=m
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_93CX6=m
CONFIG_EEPROM_93XX46=m

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=m

#
# 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=m
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_IDE_TASK_IOCTL is not set

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

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
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=m
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
# CONFIG_SCSI_SAS_HOST_SMP is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_BOOT_SYSFS=m
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_IBMMCA is not set
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
CONFIG_SCSI_IZIP_SLOW_CTR=y
# CONFIG_SCSI_NCR_D700 is not set
CONFIG_SCSI_NCR_Q720=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_DEBUG=m
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# 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=m
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
# CONFIG_SATA_MV is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ARASAN_CF is not set

#
# PIO-only SFF controllers
#
CONFIG_PATA_PLATFORM=m
CONFIG_PATA_OF_PLATFORM=m

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
CONFIG_MII=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_VETH is not set

#
# CAIF transport drivers
#
# CONFIG_CAIF_TTY is not set
# CONFIG_CAIF_SPI_SLAVE is not set
CONFIG_CAIF_HSI=m
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL3=m
# CONFIG_NET_VENDOR_AMD is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DLINK=y
CONFIG_DE600=m
# CONFIG_DE620 is not set
CONFIG_NET_VENDOR_IBM=y
# CONFIG_IBM_EMAC_ZMII is not set
# CONFIG_IBM_EMAC_RGMII is not set
# CONFIG_IBM_EMAC_TAH is not set
# CONFIG_IBM_EMAC_EMAC4 is not set
# CONFIG_IBM_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_VENDOR_MICREL=y
CONFIG_KS8842=m
CONFIG_KS8851=m
CONFIG_KS8851_MLL=m
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_ETHOC=m
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_ATP=m
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
# CONFIG_DAVICOM_PHY is not set
CONFIG_QSEMI_PHY=m
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
# CONFIG_ICPLUS_PHY is not set
CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_MICREL_PHY=m
# CONFIG_FIXED_PHY is not set
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_FILTER is not set
# CONFIG_PPP_ASYNC is not set
CONFIG_PPP_SYNC_TTY=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_TR is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set

#
# WiMAX Wireless Broadband devices
#

#
# Enable USB support to see WiMAX USB drivers
#
# CONFIG_WIMAX_I2400M_SDIO is not set
CONFIG_WAN=y
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
CONFIG_SBNI=m
# CONFIG_SBNI_MULTILINE is not set
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
# CONFIG_ISDN_AUDIO is not set

#
# ISDN feature submodules
#
# CONFIG_ISDN_DIVERSION is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set

#
# Active cards
#
CONFIG_ISDN_CAPI=m
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
CONFIG_CAPI_TRACE=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
# CONFIG_ISDN_CAPI_CAPI20 is not set
# CONFIG_ISDN_CAPI_CAPIDRV is not set

#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_CAPI_EICON=y
# CONFIG_ISDN_DRV_GIGASET is not set
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m

#
# mISDN hardware drivers
#
CONFIG_PHONE=m

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m

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

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=m
CONFIG_KEYBOARD_ADP5589=m
# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=m
CONFIG_KEYBOARD_GPIO_POLLED=m
CONFIG_KEYBOARD_TCA6416=m
CONFIG_KEYBOARD_MATRIX=m
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_MAX7359=m
CONFIG_KEYBOARD_MCS=m
CONFIG_KEYBOARD_MPR121=m
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
CONFIG_KEYBOARD_STOWAWAY=m
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_XTKBD=m
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
# CONFIG_JOYSTICK_GUILLEMOT is not set
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_DB9 is not set
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_AS5011=m
# CONFIG_JOYSTICK_JOYDUMP is not set
CONFIG_INPUT_TABLET=y
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AB8500_PONKEY=m
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
CONFIG_INPUT_MC13783_PWRBUTTON=m
CONFIG_INPUT_MMA8450=m
CONFIG_INPUT_MPU3050=m
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_WISTRON_BTNS=m
CONFIG_INPUT_KXTJ9=m
CONFIG_INPUT_KXTJ9_POLLED_MODE=y
CONFIG_INPUT_UINPUT=m
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
# CONFIG_INPUT_WM831X_ON is not set
# CONFIG_INPUT_PCAP is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=m
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_LIBPS2=m
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
CONFIG_SERIO_PS2MULT=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
# CONFIG_GAMEPORT_L4 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
# CONFIG_VT_CONSOLE is not set
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_UNIX98_PTYS is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_N_HDLC is not set
CONFIG_TRACE_ROUTER=m
CONFIG_TRACE_SINK=m
CONFIG_DEVKMEM=y
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
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 is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_MCA is not set
CONFIG_SERIAL_8250_DW=m

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX3107=m
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_OF_PLATFORM=m
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
CONFIG_SERIAL_XILINX_PS_UART=m
# CONFIG_TTY_PRINTK is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

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

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT=m
# CONFIG_I2C_PARPORT_LIGHT is not set

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

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=m
# CONFIG_SPI_BUTTERFLY is not set
CONFIG_SPI_GPIO=m
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_TLE62X0=m

#
# PPS support
#

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_MAX730X=m

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_IT8761E is not set

#
# I2C GPIO expanders:
#
CONFIG_GPIO_MAX7300=m
CONFIG_GPIO_MAX732X=m
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_WM831X is not set
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
CONFIG_GPIO_MCP23S08=m
# CONFIG_GPIO_MC33880 is not set
CONFIG_GPIO_74X164=m

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
CONFIG_W1=m

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_DS1WM=m
CONFIG_W1_MASTER_GPIO=m

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2408 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
CONFIG_W1_SLAVE_DS2431=m
# CONFIG_W1_SLAVE_DS2433 is not set
CONFIG_W1_SLAVE_DS2760=m
CONFIG_W1_SLAVE_DS2780=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=m
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=m
CONFIG_WM831X_BACKUP=m
# CONFIG_WM831X_POWER is not set
CONFIG_TEST_POWER=m
CONFIG_BATTERY_DS2760=m
CONFIG_BATTERY_DS2780=m
CONFIG_BATTERY_DS2782=m
# CONFIG_BATTERY_OLPC is not set
CONFIG_BATTERY_BQ20Z75=m
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_BATTERY_MAX17042=m
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_GPIO is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_HWMON_DEBUG_CHIP=y

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

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

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SDIOHOST_POSSIBLE=y
# CONFIG_SSB_SDIOHOST is not set
# CONFIG_SSB_SILENT is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
CONFIG_TPS6507X=m
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_SPI=y
# CONFIG_MFD_PCF50633 is not set
CONFIG_MFD_MC13783=m
CONFIG_MFD_MC13XXX=m
CONFIG_ABX500_CORE=y
CONFIG_EZX_PCAP=y
CONFIG_AB8500_CORE=y
# CONFIG_AB8500_DEBUG is not set
CONFIG_AB8500_GPADC=y
# CONFIG_MFD_WL1273_CORE is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_DUMMY=y
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
CONFIG_REGULATOR_GPIO=m
# CONFIG_REGULATOR_BQ24022 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
CONFIG_REGULATOR_MAX8660=m
CONFIG_REGULATOR_MAX8952=m
CONFIG_REGULATOR_WM831X=m
# CONFIG_REGULATOR_LP3971 is not set
CONFIG_REGULATOR_LP3972=m
CONFIG_REGULATOR_PCAP=m
CONFIG_REGULATOR_MC13XXX_CORE=m
CONFIG_REGULATOR_MC13783=m
# CONFIG_REGULATOR_MC13892 is not set
CONFIG_REGULATOR_TPS65023=m
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_ISL6271A=m
CONFIG_REGULATOR_AD5398=m
CONFIG_REGULATOR_AB8500=y
# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y

#
# MMC/SD/SDIO Card Drivers
#
# CONFIG_MMC_BLOCK is not set
# CONFIG_SDIO_UART is not set
CONFIG_MMC_TEST=m

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
CONFIG_LEDS_GPIO=m
# CONFIG_LEDS_LP3944 is not set
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_PCA955X=m
# CONFIG_LEDS_WM831X_STATUS is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_LT3593=m
# CONFIG_LEDS_MC13783 is not set
# CONFIG_LEDS_TRIGGERS is not set

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

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

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

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

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

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

#
# on-CPU RTC drivers
#
CONFIG_RTC_DRV_PCAP=m
CONFIG_RTC_DRV_MC13XXX=m
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
CONFIG_DMADEVICES_VDEBUG=y

#
# DMA Devices
#
CONFIG_TIMB_DMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
CONFIG_DMATEST=m
CONFIG_AUXDISPLAY=y
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
# CONFIG_UIO is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_STAGING=y
CONFIG_ECHO=m
CONFIG_COMEDI=m
CONFIG_COMEDI_DEBUG=y
CONFIG_COMEDI_MISC_DRIVERS=m
CONFIG_COMEDI_KCOMEDILIB=m
# CONFIG_COMEDI_BOND is not set
CONFIG_COMEDI_TEST=m
CONFIG_COMEDI_PARPORT=m
CONFIG_COMEDI_SERIAL2002=m
# CONFIG_COMEDI_SKEL is not set
CONFIG_COMEDI_NI_COMMON=m
CONFIG_COMEDI_8255=m
# CONFIG_COMEDI_DAS08 is not set
CONFIG_COMEDI_FC=m
# CONFIG_PANEL is not set
# CONFIG_POHMELFS is not set
CONFIG_IIO=m
CONFIG_IIO_BUFFER=y
CONFIG_IIO_SW_RING=m
CONFIG_IIO_KFIFO_BUF=m
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
CONFIG_ADIS16201=m
CONFIG_ADIS16203=m
CONFIG_ADIS16204=m
CONFIG_ADIS16209=m
# CONFIG_ADIS16220 is not set
# CONFIG_ADIS16240 is not set
CONFIG_KXSD9=m
# CONFIG_LIS3L02DQ is not set
# CONFIG_SCA3000 is not set

#
# Analog to digital convertors
#
CONFIG_AD7150=m
CONFIG_AD7152=m
# CONFIG_AD7291 is not set
CONFIG_AD7298=m
# CONFIG_AD7606 is not set
# CONFIG_AD799X is not set
CONFIG_AD7476=m
# CONFIG_AD7887 is not set
CONFIG_AD7780=m
# CONFIG_AD7793 is not set
# CONFIG_AD7746 is not set
# CONFIG_AD7816 is not set
CONFIG_AD7192=m
# CONFIG_ADT75 is not set
# CONFIG_ADT7310 is not set
# CONFIG_ADT7410 is not set
# CONFIG_AD7280 is not set
CONFIG_MAX1363=m
CONFIG_MAX1363_RING_BUFFER=y

#
# Analog digital bi-direction convertors
#
# CONFIG_ADT7316 is not set

#
# Digital to analog convertors
#
CONFIG_AD5624R_SPI=m
# CONFIG_AD5446 is not set
CONFIG_AD5504=m
# CONFIG_AD5791 is not set
# CONFIG_AD5686 is not set

#
# Direct Digital Synthesis
#
CONFIG_AD5930=m
# CONFIG_AD9832 is not set
# CONFIG_AD9834 is not set
# CONFIG_AD9850 is not set
CONFIG_AD9852=m
CONFIG_AD9910=m
# CONFIG_AD9951 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16060 is not set
CONFIG_ADIS16080=m
CONFIG_ADIS16130=m
# CONFIG_ADIS16260 is not set
CONFIG_ADXRS450=m

#
# Network Analyzer, Impedance Converters
#
# CONFIG_AD5933 is not set

#
# Inertial measurement units
#
# CONFIG_ADIS16400 is not set

#
# Light sensors
#
# CONFIG_SENSORS_ISL29018 is not set
CONFIG_SENSORS_TSL2563=m
# CONFIG_TSL2583 is not set

#
# Magnetometer sensors
#
CONFIG_SENSORS_AK8975=m
CONFIG_SENSORS_HMC5843=m

#
# Active energy metering IC
#
CONFIG_ADE7753=m
CONFIG_ADE7754=m
CONFIG_ADE7758=m
# CONFIG_ADE7759 is not set
# CONFIG_ADE7854 is not set

#
# Resolver to digital converters
#
# CONFIG_AD2S90 is not set
CONFIG_AD2S1200=m
CONFIG_AD2S1210=m

#
# Triggers - standalone
#
# CONFIG_IIO_PERIODIC_RTC_TRIGGER is not set
# CONFIG_IIO_GPIO_TRIGGER is not set
CONFIG_IIO_SYSFS_TRIGGER=m
# CONFIG_XVMALLOC is not set
# CONFIG_ZRAM is not set
CONFIG_FT1000=m

#
# Speakup console speech
#
CONFIG_SPEAKUP=m
CONFIG_SPEAKUP_SYNTH_ACNTSA=m
CONFIG_SPEAKUP_SYNTH_ACNTPC=m
CONFIG_SPEAKUP_SYNTH_APOLLO=m
# CONFIG_SPEAKUP_SYNTH_AUDPTR is not set
CONFIG_SPEAKUP_SYNTH_BNS=m
CONFIG_SPEAKUP_SYNTH_DECTLK=m
# CONFIG_SPEAKUP_SYNTH_DECEXT is not set
CONFIG_SPEAKUP_SYNTH_DECPC=m
# CONFIG_SPEAKUP_SYNTH_DTLK is not set
# CONFIG_SPEAKUP_SYNTH_KEYPC is not set
# CONFIG_SPEAKUP_SYNTH_LTLK is not set
# CONFIG_SPEAKUP_SYNTH_SOFT is not set
CONFIG_SPEAKUP_SYNTH_SPKOUT=m
CONFIG_SPEAKUP_SYNTH_TXPRT=m
CONFIG_SPEAKUP_SYNTH_DUMMY=m
CONFIG_TOUCHSCREEN_CLEARPAD_TM1217=m
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=m
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_IOMMU_SUPPORT is not set
# CONFIG_VIRT_DRIVERS is not set

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

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=m
# 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=m
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
# CONFIG_EXT4_FS_SECURITY is not set
CONFIG_EXT4_DEBUG=y
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# 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_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=m
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

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

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
# CONFIG_JOLIET is not set
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
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=m
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=m
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=m
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_DEBUG_OBJECTS=y
# CONFIG_DEBUG_OBJECTS_SELFTEST is not set
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_HIGHMEM=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_DEBUG_LIST=y
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_RCU_TORTURE_TEST=m
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=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_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_BUILD_DOCSRC is not set
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_SET_MODULE_RONX is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_DOUBLEFAULT=y
CONFIG_IOMMU_STRESS=y
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 is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=m

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

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

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

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=m

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

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST5=m
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m

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

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

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

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

* Re: linux-next: Tree for Oct 11 (iio/resolver)
@ 2011-10-11 20:45   ` Randy Dunlap
  0 siblings, 0 replies; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 20:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, LKML, Jonathan Cameron, linux-iio, devel, Greg KH

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:

When no GPIO support is enabled:

drivers/staging/iio/resolver/ad2s1210.c:657:14: error: array type has incomplete element type
drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:665:44: error: negative width in bit-field '<anonymous>'
drivers/staging/iio/resolver/ad2s1210.c:671:14: error: array type has incomplete element type
drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:679:34: error: negative width in bit-field '<anonymous>'



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

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

* Re: linux-next: Tree for Oct 11 (iio/resolver)
@ 2011-10-11 20:45   ` Randy Dunlap
  0 siblings, 0 replies; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 20:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next-u79uwXL29TY76Z2rM5mHXA, LKML, Jonathan Cameron,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Greg KH

On 10/11/11 02:11, Stephen Rothwell wrote:
> Hi all,
> 
> The linux-next tree is now available from
> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> the kernel.org servers are unavailable.
> 
> It may also turn up on git.kernel.org (depending on the mirroring).  The
> patch set is still absent, however.
> 
> Changes since 20111007:

When no GPIO support is enabled:

drivers/staging/iio/resolver/ad2s1210.c:657:14: error: array type has incomplete element type
drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:665:44: error: negative width in bit-field '<anonymous>'
drivers/staging/iio/resolver/ad2s1210.c:671:14: error: array type has incomplete element type
drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
drivers/staging/iio/resolver/ad2s1210.c:679:34: error: negative width in bit-field '<anonymous>'



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

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-11 19:31   ` mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) Andrei Warkentin
@ 2011-10-11 21:59     ` Randy Dunlap
  2011-10-11 23:20       ` NamJae Jeon
  0 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-11 21:59 UTC (permalink / raw)
  To: Andrei Warkentin
  Cc: Namjae Jeon, linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell

On 10/11/11 12:31, Andrei Warkentin wrote:
> Hi Randy,
> 
> ----- Original Message -----
>> From: "Randy Dunlap" <rdunlap@xenotime.net>
>> To: "Stephen Rothwell" <sfr@canb.auug.org.au>
>> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
>> <cjb@laptop.org>
>> Sent: Tuesday, October 11, 2011 2:49:39 PM
>> Subject: Re: linux-next: Tree for Oct 11 (mmc)
>>
>> On 10/11/11 02:11, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> The linux-next tree is now available from
>>> git://github.com/sfrothwell/linux-next.git as a temporary measure
>>> while
>>> the kernel.org servers are unavailable.
>>>
>>> It may also turn up on git.kernel.org (depending on the mirroring).
>>>  The
>>> patch set is still absent, however.
>>>
>>> Changes since 20111007:
>>
>>
>> When CONFIG_BLOCK is not enabled:
>>
>> In file included from
>> next-2011-1011/drivers/mmc/card/sdio_uart.c:43:0:
>> next-2011-1011/include/linux/mmc/card.h:175:12: error:
>> 'DISK_NAME_LEN' undeclared here (not in a function)
>>
>> Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
>> However, the same problem occurs in mmc/core/core.c:
>>
> 
> Because linux/genhd is now included, oops. I'm pretty positive this is due to the "mmc : general purpose partition support" patch pulled recently. I am adding NamJae, who was the author.
> 
>> In file included from next-2011-1011/drivers/mmc/core/core.c:30:0:
>> next-2011-1011/include/linux/mmc/card.h:175:12: error:
>> 'DISK_NAME_LEN' undeclared here (not in a function)
>>
>> Should mmc/core/ depend on BLOCK?  or should it just be made
>> to build even when BLOCK is not enabled?
>>
> 
> I don't think there should be a direct dependency on BLOCK. I have two suggestions -
> 1) Have our own define similar to (and in fact smaller):
>    linux/genhd.h:#define DISK_NAME_LEN                     32
> 2) Put the MMC physical partition code under an #ifdef CONFIG_BLOCK, which is a reasonable
>    proposition, given that there wouldn't be any need to parse physical partition info if
>    it would never be consumed by the MMC block driver.
> 
> Thoughts?

Agreed on part 2).  Do part 1) if it is required, but it's usually better
not to duplicate constants or structs etc.
IOW, can DISK_NAME_LEN in linux/genhd.h be exposed even when CONFIG_BLOCK
is not enabled?



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

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-11 21:59     ` Randy Dunlap
@ 2011-10-11 23:20       ` NamJae Jeon
  2011-10-11 23:48         ` Andrei Warkentin
  0 siblings, 1 reply; 137+ messages in thread
From: NamJae Jeon @ 2011-10-11 23:20 UTC (permalink / raw)
  To: Randy Dunlap, Andrei Warkentin
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell

2011/10/12 Randy Dunlap <rdunlap@xenotime.net>:
> On 10/11/11 12:31, Andrei Warkentin wrote:
>> Hi Randy,
>>
>> ----- Original Message -----
>>> From: "Randy Dunlap" <rdunlap@xenotime.net>
>>> To: "Stephen Rothwell" <sfr@canb.auug.org.au>
>>> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
>>> <cjb@laptop.org>
>>> Sent: Tuesday, October 11, 2011 2:49:39 PM
>>> Subject: Re: linux-next: Tree for Oct 11 (mmc)
>>>
>>> On 10/11/11 02:11, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> The linux-next tree is now available from
>>>> git://github.com/sfrothwell/linux-next.git as a temporary measure
>>>> while
>>>> the kernel.org servers are unavailable.
>>>>
>>>> It may also turn up on git.kernel.org (depending on the mirroring).
>>>>  The
>>>> patch set is still absent, however.
>>>>
>>>> Changes since 20111007:
>>>
>>>
>>> When CONFIG_BLOCK is not enabled:
>>>
>>> In file included from
>>> next-2011-1011/drivers/mmc/card/sdio_uart.c:43:0:
>>> next-2011-1011/include/linux/mmc/card.h:175:12: error:
>>> 'DISK_NAME_LEN' undeclared here (not in a function)
>>>
>>> Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
>>> However, the same problem occurs in mmc/core/core.c:
>>>
>>
>> Because linux/genhd is now included, oops. I'm pretty positive this is due to the "mmc : general purpose partition support" patch pulled recently. I am adding NamJae, who was the author.
>>
>>> In file included from next-2011-1011/drivers/mmc/core/core.c:30:0:
>>> next-2011-1011/include/linux/mmc/card.h:175:12: error:
>>> 'DISK_NAME_LEN' undeclared here (not in a function)
>>>
>>> Should mmc/core/ depend on BLOCK?  or should it just be made
>>> to build even when BLOCK is not enabled?
>>>
>>
>> I don't think there should be a direct dependency on BLOCK. I have two suggestions -
>> 1) Have our own define similar to (and in fact smaller):
>>    linux/genhd.h:#define DISK_NAME_LEN                     32
>> 2) Put the MMC physical partition code under an #ifdef CONFIG_BLOCK, which is a reasonable
>>    proposition, given that there wouldn't be any need to parse physical partition info if
>>    it would never be consumed by the MMC block driver.
>>
>> Thoughts?
>
> Agreed on part 2).  Do part 1) if it is required, but it's usually better
> not to duplicate constants or structs etc.
> IOW, can DISK_NAME_LEN in linux/genhd.h be exposed even when CONFIG_BLOCK
> is not enabled?

Hi Randy, Andrei.

I suggest third option for this.
As you know, MMC like ATA Driver and SCSI Driver etc.. can not enable
without CONFIG_BLOCK
So I think that mmc should be depended from CONFIG_BLOCK like other
block device driver.
see the their Kconfig. How do you think ?
--------------------------------------------------------------------------------------------------------------------------------
menuconfig ATA
        tristate "Serial ATA and Parallel ATA drivers"
        depends on HAS_IOMEM
        depends on BLOCK
        depends on !(M32R || M68K) || BROKEN


config SCSI
        tristate "SCSI device support"
        depends on BLOCK
        select SCSI_DMA if HAS_DMA
        ---help---
---------------------------------------------------------------------------------------------------------------------

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

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-11 23:20       ` NamJae Jeon
@ 2011-10-11 23:48         ` Andrei Warkentin
  2011-10-12  0:16           ` NamJae Jeon
  0 siblings, 1 reply; 137+ messages in thread
From: Andrei Warkentin @ 2011-10-11 23:48 UTC (permalink / raw)
  To: NamJae Jeon
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell, Randy Dunlap

----- Original Message -----
> From: "NamJae Jeon" <linkinjeon@gmail.com>
> To: "Randy Dunlap" <rdunlap@xenotime.net>, "Andrei Warkentin" <awarkentin@vmware.com>
> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>
> Sent: Tuesday, October 11, 2011 7:20:48 PM
> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
> 
> Hi Randy, Andrei.
> 
> I suggest third option for this.
> As you know, MMC like ATA Driver and SCSI Driver etc.. can not enable
> without CONFIG_BLOCK
> So I think that mmc should be depended from CONFIG_BLOCK like other
> block device driver.
> see the their Kconfig. How do you think ?

MMC core doesn't not imply MMC_BLOCK. You could well use SDIO devices via MMC without any flash storage whatsoever.
What I want to say is that MMC_BLOCK already depends on BLOCK. MMC, however, has no such functional dependence, as it
just (effectively) provides bus and device enumeration. So I think the better solution is wrapping all MMC partition
code within mmc/core/mmc.c and card.h with CONFIG_BLOCK.

A

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-11 23:48         ` Andrei Warkentin
@ 2011-10-12  0:16           ` NamJae Jeon
  2011-10-12  0:50             ` Andrei Warkentin
  0 siblings, 1 reply; 137+ messages in thread
From: NamJae Jeon @ 2011-10-12  0:16 UTC (permalink / raw)
  To: Andrei Warkentin
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell, Randy Dunlap

2011/10/12 Andrei Warkentin <awarkentin@vmware.com>:
> ----- Original Message -----
>> From: "NamJae Jeon" <linkinjeon@gmail.com>
>> To: "Randy Dunlap" <rdunlap@xenotime.net>, "Andrei Warkentin" <awarkentin@vmware.com>
>> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
>> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>
>> Sent: Tuesday, October 11, 2011 7:20:48 PM
>> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
>>
>> Hi Randy, Andrei.
>>
>> I suggest third option for this.
>> As you know, MMC like ATA Driver and SCSI Driver etc.. can not enable
>> without CONFIG_BLOCK
>> So I think that mmc should be depended from CONFIG_BLOCK like other
>> block device driver.
>> see the their Kconfig. How do you think ?
>
> MMC core doesn't not imply MMC_BLOCK. You could well use SDIO devices via MMC without any flash storage whatsoever.
> What I want to say is that MMC_BLOCK already depends on BLOCK. MMC, however, has no such functional dependence, as it
> just (effectively) provides bus and device enumeration. So I think the better solution is wrapping all MMC partition
> code within mmc/core/mmc.c and card.h with CONFIG_BLOCK.
yes, you're right, I found it after sending mail. If so, should I wrap
CONFIG_MMC_BLOCK instead of CONFIG_MMC ? After I add CONFIG_MMC_BLOCK
in core/mmc.c, card.h, I can see compile is okay.
Thanks.
>
> A
>

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-12  0:16           ` NamJae Jeon
@ 2011-10-12  0:50             ` Andrei Warkentin
  2011-10-12  1:55               ` NamJae Jeon
  0 siblings, 1 reply; 137+ messages in thread
From: Andrei Warkentin @ 2011-10-12  0:50 UTC (permalink / raw)
  To: NamJae Jeon
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell, Randy Dunlap

Hi,

----- Original Message -----
> From: "NamJae Jeon" <linkinjeon@gmail.com>
> To: "Andrei Warkentin" <awarkentin@vmware.com>
> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Randy Dunlap" <rdunlap@xenotime.net>
> Sent: Tuesday, October 11, 2011 8:16:51 PM
> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
> 
> 2011/10/12 Andrei Warkentin <awarkentin@vmware.com>:
> > ----- Original Message -----
> >> From: "NamJae Jeon" <linkinjeon@gmail.com>
> >> To: "Randy Dunlap" <rdunlap@xenotime.net>, "Andrei Warkentin"
> >> <awarkentin@vmware.com>
> >> Cc: linux-next@vger.kernel.org, "LKML"
> >> <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris
> >> Ball"
> >> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>
> >> Sent: Tuesday, October 11, 2011 7:20:48 PM
> >> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was:
> >> linux-next: Tree for Oct 11 (mmc))
> >>
> >> Hi Randy, Andrei.
> >>
> >> I suggest third option for this.
> >> As you know, MMC like ATA Driver and SCSI Driver etc.. can not
> >> enable
> >> without CONFIG_BLOCK
> >> So I think that mmc should be depended from CONFIG_BLOCK like
> >> other
> >> block device driver.
> >> see the their Kconfig. How do you think ?
> >
> > MMC core doesn't not imply MMC_BLOCK. You could well use SDIO
> > devices via MMC without any flash storage whatsoever.
> > What I want to say is that MMC_BLOCK already depends on BLOCK. MMC,
> > however, has no such functional dependence, as it
> > just (effectively) provides bus and device enumeration. So I think
> > the better solution is wrapping all MMC partition
> > code within mmc/core/mmc.c and card.h with CONFIG_BLOCK.
> yes, you're right, I found it after sending mail. If so, should I
> wrap
> CONFIG_MMC_BLOCK instead of CONFIG_MMC ? After I add CONFIG_MMC_BLOCK
> in core/mmc.c, card.h, I can see compile is okay.
> Thanks.
> >

I am not sure if it should be CONFIG_MMC_BLOCK or CONFIG_BLOCK. After all, the
code you're wrapping doesn't really depend on CONFIG_MMC_BLOCK, it gets consumed by it, and
it depends (in using that one define) only on CONFIG_BLOCK. Maybe I'm overthinking it
and the code should just define it's own MAX_MMC_PART_NAME to be like 10 or something.

A

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

* Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
  2011-10-12  0:50             ` Andrei Warkentin
@ 2011-10-12  1:55               ` NamJae Jeon
  0 siblings, 0 replies; 137+ messages in thread
From: NamJae Jeon @ 2011-10-12  1:55 UTC (permalink / raw)
  To: Andrei Warkentin
  Cc: linux-next, LKML, linux-mmc, Chris Ball, Stephen Rothwell, Randy Dunlap

2011/10/12 Andrei Warkentin <awarkentin@vmware.com>:
> Hi,
>
> ----- Original Message -----
>> From: "NamJae Jeon" <linkinjeon@gmail.com>
>> To: "Andrei Warkentin" <awarkentin@vmware.com>
>> Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris Ball"
>> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Randy Dunlap" <rdunlap@xenotime.net>
>> Sent: Tuesday, October 11, 2011 8:16:51 PM
>> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
>>
>> 2011/10/12 Andrei Warkentin <awarkentin@vmware.com>:
>> > ----- Original Message -----
>> >> From: "NamJae Jeon" <linkinjeon@gmail.com>
>> >> To: "Randy Dunlap" <rdunlap@xenotime.net>, "Andrei Warkentin"
>> >> <awarkentin@vmware.com>
>> >> Cc: linux-next@vger.kernel.org, "LKML"
>> >> <linux-kernel@vger.kernel.org>, linux-mmc@vger.kernel.org, "Chris
>> >> Ball"
>> >> <cjb@laptop.org>, "Stephen Rothwell" <sfr@canb.auug.org.au>
>> >> Sent: Tuesday, October 11, 2011 7:20:48 PM
>> >> Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was:
>> >> linux-next: Tree for Oct 11 (mmc))
>> >>
>> >> Hi Randy, Andrei.
>> >>
>> >> I suggest third option for this.
>> >> As you know, MMC like ATA Driver and SCSI Driver etc.. can not
>> >> enable
>> >> without CONFIG_BLOCK
>> >> So I think that mmc should be depended from CONFIG_BLOCK like
>> >> other
>> >> block device driver.
>> >> see the their Kconfig. How do you think ?
>> >
>> > MMC core doesn't not imply MMC_BLOCK. You could well use SDIO
>> > devices via MMC without any flash storage whatsoever.
>> > What I want to say is that MMC_BLOCK already depends on BLOCK. MMC,
>> > however, has no such functional dependence, as it
>> > just (effectively) provides bus and device enumeration. So I think
>> > the better solution is wrapping all MMC partition
>> > code within mmc/core/mmc.c and card.h with CONFIG_BLOCK.
>> yes, you're right, I found it after sending mail. If so, should I
>> wrap
>> CONFIG_MMC_BLOCK instead of CONFIG_MMC ? After I add CONFIG_MMC_BLOCK
>> in core/mmc.c, card.h, I can see compile is okay.
>> Thanks.
>> >
>
> I am not sure if it should be CONFIG_MMC_BLOCK or CONFIG_BLOCK. After all, the
> code you're wrapping doesn't really depend on CONFIG_MMC_BLOCK, it gets consumed by it, and
> it depends (in using that one define) only on CONFIG_BLOCK. Maybe I'm overthinking it
> and the code should just define it's own MAX_MMC_PART_NAME to be like 10 or something.
yes, I agree your opinion,  If we define it is easy to solve.
I will send new patch for it today.
Thanks.
>
> A
>

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

* Re: linux-next: Tree for Oct 11 (iio/resolver)
@ 2011-10-12  8:58     ` Jonathan Cameron
  0 siblings, 0 replies; 137+ messages in thread
From: Jonathan Cameron @ 2011-10-12  8:58 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, linux-iio, devel, Greg KH

On 10/11/11 21:45, Randy Dunlap wrote:
> On 10/11/11 02:11, Stephen Rothwell wrote:
>> Hi all,
>>
>> The linux-next tree is now available from
>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>> the kernel.org servers are unavailable.
>>
>> It may also turn up on git.kernel.org (depending on the mirroring).  The
>> patch set is still absent, however.
>>
>> Changes since 20111007:
> 
> When no GPIO support is enabled:
Thanks Randy. Fix is clearly to add the GENERIC_GPIO dependence which should always
have been there for this driver.  Previously it was building a non working driver
as the stubs covered everything being used.  I'll sort a patch shortly and chase down
if we have any others missing GENERIC_GPIO dependencies.

Jonathan
> 
> drivers/staging/iio/resolver/ad2s1210.c:657:14: error: array type has incomplete element type
> drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:665:44: error: negative width in bit-field '<anonymous>'
> drivers/staging/iio/resolver/ad2s1210.c:671:14: error: array type has incomplete element type
> drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:679:34: error: negative width in bit-field '<anonymous>'


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

* Re: linux-next: Tree for Oct 11 (iio/resolver)
@ 2011-10-12  8:58     ` Jonathan Cameron
  0 siblings, 0 replies; 137+ messages in thread
From: Jonathan Cameron @ 2011-10-12  8:58 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next-u79uwXL29TY76Z2rM5mHXA, LKML,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Greg KH

On 10/11/11 21:45, Randy Dunlap wrote:
> On 10/11/11 02:11, Stephen Rothwell wrote:
>> Hi all,
>>
>> The linux-next tree is now available from
>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>> the kernel.org servers are unavailable.
>>
>> It may also turn up on git.kernel.org (depending on the mirroring).  The
>> patch set is still absent, however.
>>
>> Changes since 20111007:
> 
> When no GPIO support is enabled:
Thanks Randy. Fix is clearly to add the GENERIC_GPIO dependence which should always
have been there for this driver.  Previously it was building a non working driver
as the stubs covered everything being used.  I'll sort a patch shortly and chase down
if we have any others missing GENERIC_GPIO dependencies.

Jonathan
> 
> drivers/staging/iio/resolver/ad2s1210.c:657:14: error: array type has incomplete element type
> drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:665:44: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:665:44: error: negative width in bit-field '<anonymous>'
> drivers/staging/iio/resolver/ad2s1210.c:671:14: error: array type has incomplete element type
> drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:679:34: warning: type defaults to 'int' in type name
> drivers/staging/iio/resolver/ad2s1210.c:679:34: error: negative width in bit-field '<anonymous>'

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

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
  2011-10-11 20:37 ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Randy Dunlap
@ 2011-10-14 17:58   ` Randy Dunlap
  2011-11-10 13:57     ` Ingo Molnar
  0 siblings, 1 reply; 137+ messages in thread
From: Randy Dunlap @ 2011-10-14 17:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, linux-ide, Anton Vorontsov

On 10/11/2011 01:37 PM, Randy Dunlap wrote:
> On 10/11/11 02:11, Stephen Rothwell wrote:
>> Hi all,
>>
>> The linux-next tree is now available from
>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>> the kernel.org servers are unavailable.
>>
>> It may also turn up on git.kernel.org (depending on the mirroring).  The
>> patch set is still absent, however.
>>
>> Changes since 20111007:
>>
>> Removed tree: ide (at the maintainer's request)
> 
> 
> drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)


[adding Author: Anton]

Build error still present in linux-next of 20111014.


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

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

* Re: [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled
  2011-10-11 19:15 ` [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled Randy Dunlap
@ 2011-10-27  8:06   ` Ted Ts'o
  0 siblings, 0 replies; 137+ messages in thread
From: Ted Ts'o @ 2011-10-27  8:06 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, linux-ext4, Andrew Morton,
	Arnd Bergmann, Arnaud Lacombe

On Tue, Oct 11, 2011 at 12:15:20PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Fix build error when CONFIG_BUG is not enabled:
> 
> fs/jbd2/transaction.c:1175:3: error: implicit declaration of function '__WARN'
> 
> by changing __WARN() to WARN_ON(), as suggested by
> Arnaud Lacombe <lacombar@gmail.com>.
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Arnaud Lacombe <lacombar@gmail.com>

Thanks, applied.

					- Ted

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

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
  2011-10-14 17:58   ` Randy Dunlap
@ 2011-11-10 13:57     ` Ingo Molnar
  2011-11-10 14:25       ` Alan Cox
                         ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Ingo Molnar @ 2011-11-10 13:57 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, linux-ide, Anton Vorontsov,
	Linus Torvalds, Andrew Morton, Jeff Garzik


* Randy Dunlap <rdunlap@xenotime.net> wrote:

> On 10/11/2011 01:37 PM, Randy Dunlap wrote:
> > On 10/11/11 02:11, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The linux-next tree is now available from
> >> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> >> the kernel.org servers are unavailable.
> >>
> >> It may also turn up on git.kernel.org (depending on the mirroring).  The
> >> patch set is still absent, however.
> >>
> >> Changes since 20111007:
> >>
> >> Removed tree: ide (at the maintainer's request)
> > 
> > 
> > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
> 
> 
> [adding Author: Anton]
> 
> Build error still present in linux-next of 20111014.

This build failure regression report was ignored twice and then 
pushed upstream and is still unfixed a month after the initial 
report. Upstream now fails to build on like 25% of x86 configs.

What's going on with this bug guys?

Thanks,

	Ingo

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

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
  2011-11-10 13:57     ` Ingo Molnar
@ 2011-11-10 14:25       ` Alan Cox
  2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
  2011-11-10 18:18       ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Jeff Garzik
  2 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-11-10 14:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
	Anton Vorontsov, Linus Torvalds, Andrew Morton, Jeff Garzik

O> > > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
> > 
> > 
> > [adding Author: Anton]
> > 
> > Build error still present in linux-next of 20111014.
> 
> This build failure regression report was ignored twice and then 
> pushed upstream and is still unfixed a month after the initial 
> report. Upstream now fails to build on like 25% of x86 configs.
> 
> What's going on with this bug guys?

As I've said before the driver shouldn't be trying to use "NO_IRQ", Not
having an irq is 0 as in if (!dev->irq)


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

* [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage)
  2011-11-10 13:57     ` Ingo Molnar
  2011-11-10 14:25       ` Alan Cox
@ 2011-11-10 15:18       ` Anton Vorontsov
  2011-11-10 15:25         ` [PATCH 1/2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
                           ` (2 more replies)
  2011-11-10 18:18       ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Jeff Garzik
  2 siblings, 3 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-11-10 15:18 UTC (permalink / raw)
  To: Ingo Molnar, Jeff Garzik, Grant Likely
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
	Linus Torvalds, Andrew Morton, devicetree-discuss

This patch makes a band-aid fix the following build failure:

  CC      drivers/ata/pata_of_platform.o
drivers/ata/pata_of_platform.c: In function 'pata_of_platform_probe':
drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
drivers/ata/pata_of_platform.c:55:13: note: each undeclared identifier is reported only once for each function it appears in

The proper fix (stop OF code from returning NO_IRQ values) is pending.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---

On Thu, Nov 10, 2011 at 02:57:03PM +0100, Ingo Molnar wrote:
[...]
> > > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
> > 
> > [adding Author: Anton]
> > 
> > Build error still present in linux-next of 20111014.
> 
> This build failure regression report was ignored twice and then 
> pushed upstream and is still unfixed a month after the initial 
> report. Upstream now fails to build on like 25% of x86 configs.
> 
> What's going on with this bug guys?

Here is the story:

- NO_IRQ is evil[1], AFAIR the trend is to remove its usage completely;
- Sane arches (x86) don't use it at all, or have it defined to 0
  (PPC32/64).
- On another arches it is either -1 or whatever random value;
- The NO_IRQ disease spreads despite our willingness, even within
  the new OF code.

The new irq domain stuff (that is used on ARM) always returns 0
in 'no irq' case, so we may easily remove it.

So the proper fix would be two-fold: for OF and for that driver.
But this is for 3.3 kernels. I'll send the two patches as follow-ups.

In the meantime, the band-aid (for 3.2) is down below.

[1]
http://lkml.org/lkml/2005/11/22/159
http://lkml.org/lkml/2005/11/22/227

 drivers/ata/pata_of_platform.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index a72ab0d..f99e17b 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -16,6 +16,11 @@
 #include <linux/of_platform.h>
 #include <linux/ata_platform.h>
 
+/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
+#ifndef NO_IRQ
+#define NO_IRQ 0
+#endif
+
 static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
 {
 	int ret;
-- 
1.7.5.3

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

* [PATCH 1/2] of/irq: Get rid of NO_IRQ usage
  2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
@ 2011-11-10 15:25         ` Anton Vorontsov
  2011-12-06 21:22           ` Rob Herring
  2011-11-10 15:26         ` [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver Anton Vorontsov
  2011-11-10 15:35         ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Alan Cox
  2 siblings, 1 reply; 137+ messages in thread
From: Anton Vorontsov @ 2011-11-10 15:25 UTC (permalink / raw)
  To: Ingo Molnar, Jeff Garzik, Grant Likely
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
	Linus Torvalds, Andrew Morton, devicetree-discuss, Alan Cox

PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.

Other arches might break if some of their OF drivers rely on NO_IRQ
being not 0. If so, the drivers must be fixed, finally.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
 drivers/of/irq.c |   30 ++++++++++++++++++------------
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6d3dd39..2dd4937 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -26,11 +26,6 @@
 #include <linux/string.h>
 #include <linux/slab.h>
 
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
 /**
  * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
  * @device: Device node of the device whose interrupt is to be mapped
@@ -42,12 +37,23 @@
 unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
 {
 	struct of_irq oirq;
+	int ret = 0;
 
 	if (of_irq_map_one(dev, index, &oirq))
-		return NO_IRQ;
-
-	return irq_create_of_mapping(oirq.controller, oirq.specifier,
-				     oirq.size);
+		goto no_irq;
+
+	ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+				    oirq.size);
+no_irq:
+#ifdef NO_IRQ
+#if NO_IRQ != 0
+	if (ret == NO_IRQ)
+		pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
+			"NO_IRQ, but we return 0. If anything breaks, driver "
+			"have to be fixed.\n");
+#endif
+#endif
+	return ret;
 }
 EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
 
@@ -345,7 +351,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 
 	/* Only dereference the resource if both the
 	 * resource and the irq are valid. */
-	if (r && irq != NO_IRQ) {
+	if (r && irq) {
 		r->start = r->end = irq;
 		r->flags = IORESOURCE_IRQ;
 		r->name = dev->full_name;
@@ -363,7 +369,7 @@ int of_irq_count(struct device_node *dev)
 {
 	int nr = 0;
 
-	while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
+	while (of_irq_to_resource(dev, nr, NULL))
 		nr++;
 
 	return nr;
@@ -383,7 +389,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 	int i;
 
 	for (i = 0; i < nr_irqs; i++, res++)
-		if (of_irq_to_resource(dev, i, res) == NO_IRQ)
+		if (!of_irq_to_resource(dev, i, res))
 			break;
 
 	return i;
-- 
1.7.5.3

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

* [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
  2011-11-10 15:25         ` [PATCH 1/2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
@ 2011-11-10 15:26         ` Anton Vorontsov
  2011-11-10 15:38           ` Alan Cox
  2011-11-10 15:35         ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Alan Cox
  2 siblings, 1 reply; 137+ messages in thread
From: Anton Vorontsov @ 2011-11-10 15:26 UTC (permalink / raw)
  To: Ingo Molnar, Jeff Garzik, Grant Likely
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
	Linus Torvalds, Andrew Morton, devicetree-discuss, Alan Cox

Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
 drivers/ata/pata_of_platform.c |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index f99e17b..2a472c5 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -16,11 +16,6 @@
 #include <linux/of_platform.h>
 #include <linux/ata_platform.h>
 
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
 static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
 {
 	int ret;
@@ -57,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
 	}
 
 	ret = of_irq_to_resource(dn, 0, &irq_res);
-	if (ret == NO_IRQ)
+	if (!ret)
 		irq_res.start = irq_res.end = 0;
 	else
 		irq_res.flags = 0;
-- 
1.7.5.3

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

* Re: [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage)
  2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
  2011-11-10 15:25         ` [PATCH 1/2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
  2011-11-10 15:26         ` [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver Anton Vorontsov
@ 2011-11-10 15:35         ` Alan Cox
  2 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-11-10 15:35 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
	Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
	Andrew Morton, devicetree-discuss

> The proper fix (stop OF code from returning NO_IRQ values) is pending.

Please just apply the proper fix.

> - The NO_IRQ disease spreads despite our willingness, even within
>   the new OF code.

Then it can stop right here, because if the arch people don't fix their
code to use zero their ATA port won't work.

> +/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
> +#ifndef NO_IRQ
> +#define NO_IRQ 0
> +#endif

NAK - just test against zero. They've been complained at about this for
over two years. Enough is enough.

Alan

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

* Re: [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 15:26         ` [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver Anton Vorontsov
@ 2011-11-10 15:38           ` Alan Cox
  2011-11-10 16:28             ` [PATCH] " Anton Vorontsov
  0 siblings, 1 reply; 137+ messages in thread
From: Alan Cox @ 2011-11-10 15:38 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
	Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
	Andrew Morton, devicetree-discuss

On Thu, 10 Nov 2011 19:26:06 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:

> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
> 
> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>

Acked-by: Alan Cox <alan@linux.intel.com>

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 15:38           ` Alan Cox
@ 2011-11-10 16:28             ` Anton Vorontsov
  2011-11-10 20:34               ` Jeff Garzik
                                 ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-11-10 16:28 UTC (permalink / raw)
  To: Alan Cox
  Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
	Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
	Andrew Morton, devicetree-discuss

Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
---

On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
> On Thu, 10 Nov 2011 19:26:06 +0400
> Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> 
> > Drivers should not use NO_IRQ; moreover, some architectures don't
> > have it nowadays. '0' is the 'no irq' case.
> > 
> > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> 
> Acked-by: Alan Cox <alan@linux.intel.com>

In case if we don't want a "band-aid fix" for 3.2, here is the patch
that just does the proper fix (w/ a risk to break minor architectures).

 drivers/ata/pata_of_platform.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index a72ab0d..2a472c5 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
 	}
 
 	ret = of_irq_to_resource(dn, 0, &irq_res);
-	if (ret == NO_IRQ)
+	if (!ret)
 		irq_res.start = irq_res.end = 0;
 	else
 		irq_res.flags = 0;
-- 
1.7.5.3

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

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
  2011-11-10 13:57     ` Ingo Molnar
  2011-11-10 14:25       ` Alan Cox
  2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
@ 2011-11-10 18:18       ` Jeff Garzik
  2 siblings, 0 replies; 137+ messages in thread
From: Jeff Garzik @ 2011-11-10 18:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
	Anton Vorontsov, Linus Torvalds, Andrew Morton

On 11/10/2011 08:57 AM, Ingo Molnar wrote:
>
> * Randy Dunlap<rdunlap@xenotime.net>  wrote:
>
>> On 10/11/2011 01:37 PM, Randy Dunlap wrote:
>>> On 10/11/11 02:11, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> The linux-next tree is now available from
>>>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>>>> the kernel.org servers are unavailable.
>>>>
>>>> It may also turn up on git.kernel.org (depending on the mirroring).  The
>>>> patch set is still absent, however.
>>>>
>>>> Changes since 20111007:
>>>>
>>>> Removed tree: ide (at the maintainer's request)
>>>
>>>
>>> drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
>>
>>
>> [adding Author: Anton]
>>
>> Build error still present in linux-next of 20111014.
>
> This build failure regression report was ignored twice and then
> pushed upstream and is still unfixed a month after the initial
> report. Upstream now fails to build on like 25% of x86 configs.
>
> What's going on with this bug guys?


Hum, I missed it in my LKML scans, and never got a CC.

Will merge Anton's patch immediately...

	Jeff

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 16:28             ` [PATCH] " Anton Vorontsov
@ 2011-11-10 20:34               ` Jeff Garzik
  2011-12-02 19:19               ` Dave Martin
  2011-12-02 19:26               ` Dave Martin
  2 siblings, 0 replies; 137+ messages in thread
From: Jeff Garzik @ 2011-11-10 20:34 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Alan Cox, Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
	Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
	Andrew Morton, devicetree-discuss

On 11/10/2011 11:28 AM, Anton Vorontsov wrote:
> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
>
> Signed-off-by: Anton Vorontsov<cbouatmailru@gmail.com>
> Acked-by: Alan Cox<alan@linux.intel.com>
> ---
>
> On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
>> On Thu, 10 Nov 2011 19:26:06 +0400
>> Anton Vorontsov<cbouatmailru@gmail.com>  wrote:
>>
>>> Drivers should not use NO_IRQ; moreover, some architectures don't
>>> have it nowadays. '0' is the 'no irq' case.
>>>
>>> Signed-off-by: Anton Vorontsov<cbouatmailru@gmail.com>
>>
>> Acked-by: Alan Cox<alan@linux.intel.com>
>
> In case if we don't want a "band-aid fix" for 3.2, here is the patch
> that just does the proper fix (w/ a risk to break minor architectures).
>
>   drivers/ata/pata_of_platform.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
> index a72ab0d..2a472c5 100644
> --- a/drivers/ata/pata_of_platform.c
> +++ b/drivers/ata/pata_of_platform.c
> @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
>   	}
>
>   	ret = of_irq_to_resource(dn, 0,&irq_res);
> -	if (ret == NO_IRQ)
> +	if (!ret)
>   		irq_res.start = irq_res.end = 0;
>   	else
>   		irq_res.flags = 0;

Unless someone screams, that is what I'll push upstream.

	Jeff

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 16:28             ` [PATCH] " Anton Vorontsov
  2011-11-10 20:34               ` Jeff Garzik
@ 2011-12-02 19:19               ` Dave Martin
  2011-12-02 22:34                 ` Anton Vorontsov
  2011-12-02 23:22                 ` [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver Alan Cox
  2011-12-02 19:26               ` Dave Martin
  2 siblings, 2 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-02 19:19 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Linus Torvalds, Jeff Garzik

On Thu, Nov 10, 2011 at 08:28:59PM +0400, Anton Vorontsov wrote:
> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
> 
> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> Acked-by: Alan Cox <alan@linux.intel.com>
> ---
> 
> On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
> > On Thu, 10 Nov 2011 19:26:06 +0400
> > Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > 
> > > Drivers should not use NO_IRQ; moreover, some architectures don't
> > > have it nowadays. '0' is the 'no irq' case.
> > > 
> > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > 
> > Acked-by: Alan Cox <alan@linux.intel.com>
> 
> In case if we don't want a "band-aid fix" for 3.2, here is the patch
> that just does the proper fix (w/ a risk to break minor architectures).

This is now broken on ARM where, for good or bad, NO_IRQ currently is
used and is -1.

How do we resolve it?  If we are ready to eliminate NO_IRQ from
drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
that case, we should surely just do it... but I'm not confident I can
judge on that.

Half-removing NO_IRQ is going to be problematic, though...
I really don't care whether the "no irq" value is 0 or -1, but it is
abundantly clear that choosing different values to mean the same thing
on opposite sides of an interface does not work.

Cheers
---Dave

> 
>  drivers/ata/pata_of_platform.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
> index a72ab0d..2a472c5 100644
> --- a/drivers/ata/pata_of_platform.c
> +++ b/drivers/ata/pata_of_platform.c
> @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
>  	}
>  
>  	ret = of_irq_to_resource(dn, 0, &irq_res);
> -	if (ret == NO_IRQ)
> +	if (!ret)
>  		irq_res.start = irq_res.end = 0;
>  	else
>  		irq_res.flags = 0;
> -- 
> 1.7.5.3
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-11-10 16:28             ` [PATCH] " Anton Vorontsov
  2011-11-10 20:34               ` Jeff Garzik
  2011-12-02 19:19               ` Dave Martin
@ 2011-12-02 19:26               ` Dave Martin
  2011-12-02 19:28                   ` Linus Torvalds
  2 siblings, 1 reply; 137+ messages in thread
From: Dave Martin @ 2011-12-02 19:26 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Linus Torvalds, Jeff Garzik, Pawel Moll, linux-arm-kernel

[expanding CC -- apologies to anyone who gets this mail twice]

On Thu, Nov 10, 2011 at 08:28:59PM +0400, Anton Vorontsov wrote:
> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
> 
> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> Acked-by: Alan Cox <alan@linux.intel.com>
> ---
> 
> On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
> > On Thu, 10 Nov 2011 19:26:06 +0400
> > Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > 
> > > Drivers should not use NO_IRQ; moreover, some architectures don't
> > > have it nowadays. '0' is the 'no irq' case.
> > > 
> > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > 
> > Acked-by: Alan Cox <alan@linux.intel.com>
> 
> In case if we don't want a "band-aid fix" for 3.2, here is the patch
> that just does the proper fix (w/ a risk to break minor architectures).

This is now broken on ARM where, for good or bad, NO_IRQ currently is
used and is -1.

How do we resolve it?  If we are ready to eliminate NO_IRQ from
drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
that case, we should surely just do it... but I'm not confident I can
judge on that.

Half-removing NO_IRQ is going to be problematic, though...
I really don't care whether the "no irq" value is 0 or -1, but it is
abundantly clear that choosing different values to mean the same thing
on opposite sides of an interface does not work.

Cheers
---Dave

> 
>  drivers/ata/pata_of_platform.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
> index a72ab0d..2a472c5 100644
> --- a/drivers/ata/pata_of_platform.c
> +++ b/drivers/ata/pata_of_platform.c
> @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
>  	}
>  
>  	ret = of_irq_to_resource(dn, 0, &irq_res);
> -	if (ret == NO_IRQ)
> +	if (!ret)
>  		irq_res.start = irq_res.end = 0;
>  	else
>  		irq_res.flags = 0;
> -- 
> 1.7.5.3
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 19:26               ` Dave Martin
@ 2011-12-02 19:28                   ` Linus Torvalds
  0 siblings, 0 replies; 137+ messages in thread
From: Linus Torvalds @ 2011-12-02 19:28 UTC (permalink / raw)
  To: Dave Martin
  Cc: Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
>
> This is now broken on ARM where, for good or bad, NO_IRQ currently is
> used and is -1.
>
> How do we resolve it?  If we are ready to eliminate NO_IRQ from
> drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> that case, we should surely just do it... but I'm not confident I can
> judge on that.

Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
as you notice breakage.

Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
around as a marker of brokenness), just start removing it from all the
ARM drivers that use the OF infrastructure. Which is presumably not
all that many yet.

So whenever you find breakage, the fix now is to just remove NO_IRQ
tests, and replace them with "!irq".

                       Linus

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-02 19:28                   ` Linus Torvalds
  0 siblings, 0 replies; 137+ messages in thread
From: Linus Torvalds @ 2011-12-02 19:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
>
> This is now broken on ARM where, for good or bad, NO_IRQ currently is
> used and is -1.
>
> How do we resolve it? ?If we are ready to eliminate NO_IRQ from
> drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> that case, we should surely just do it... but I'm not confident I can
> judge on that.

Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
as you notice breakage.

Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
around as a marker of brokenness), just start removing it from all the
ARM drivers that use the OF infrastructure. Which is presumably not
all that many yet.

So whenever you find breakage, the fix now is to just remove NO_IRQ
tests, and replace them with "!irq".

                       Linus

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 19:19               ` Dave Martin
@ 2011-12-02 22:34                 ` Anton Vorontsov
  2011-12-02 22:40                   ` Anton Vorontsov
  2011-12-02 22:40                   ` Linus Torvalds
  2011-12-02 23:22                 ` [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver Alan Cox
  1 sibling, 2 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-02 22:34 UTC (permalink / raw)
  To: Dave Martin
  Cc: Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Linus Torvalds, Jeff Garzik

On Fri, Dec 02, 2011 at 07:19:17PM +0000, Dave Martin wrote:
[...]
> > > > Drivers should not use NO_IRQ; moreover, some architectures don't
> > > > have it nowadays. '0' is the 'no irq' case.
> > > > 
> > > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > > 
> > > Acked-by: Alan Cox <alan@linux.intel.com>
> > 
> > In case if we don't want a "band-aid fix" for 3.2, here is the patch
> > that just does the proper fix (w/ a risk to break minor architectures).
> 
> This is now broken on ARM where, for good or bad, NO_IRQ currently is
> used and is -1.
> 
> How do we resolve it?

One option is to test this patch on a board that is now broken:

http://lkml.org/lkml/2011/11/10/290

So that someone provide Tested-by tag. With the tag we probably can
push the patch for 3.2, and thus fix the issue once and forever.


The other option is to revert the correct fix, and push the bogus
one, i.e. this:

http://lkml.org/lkml/2011/11/10/287

But that last option is less likely, as this was NAKed by Alan Cox.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 22:34                 ` Anton Vorontsov
@ 2011-12-02 22:40                   ` Anton Vorontsov
  2011-12-02 22:46                     ` Anton Vorontsov
  2011-12-02 22:40                   ` Linus Torvalds
  1 sibling, 1 reply; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-02 22:40 UTC (permalink / raw)
  To: Dave Martin
  Cc: Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Linus Torvalds, Jeff Garzik, Pawel Moll

On Sat, Dec 03, 2011 at 02:34:02AM +0400, Anton Vorontsov wrote:
> On Fri, Dec 02, 2011 at 07:19:17PM +0000, Dave Martin wrote:
> [...]
> > > > > Drivers should not use NO_IRQ; moreover, some architectures don't
> > > > > have it nowadays. '0' is the 'no irq' case.
> > > > > 
> > > > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > > > 
> > > > Acked-by: Alan Cox <alan@linux.intel.com>
> > > 
> > > In case if we don't want a "band-aid fix" for 3.2, here is the patch
> > > that just does the proper fix (w/ a risk to break minor architectures).
> > 
> > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > used and is -1.
> > 
> > How do we resolve it?
> 
> One option is to test this patch on a board that is now broken:
> 
> http://lkml.org/lkml/2011/11/10/290

Oh, actually, reading my own patch:

"ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
 which returns correct ('0') value in 'no irq' case. So everything
 should be fine."


I forgot that on ARM we use IRQ domains, so ARM should be OK.

Do you really see any breakage, and if so, what board?

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 22:34                 ` Anton Vorontsov
  2011-12-02 22:40                   ` Anton Vorontsov
@ 2011-12-02 22:40                   ` Linus Torvalds
  2011-12-02 23:18                     ` [PATCH v2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
  1 sibling, 1 reply; 137+ messages in thread
From: Linus Torvalds @ 2011-12-02 22:40 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Dave Martin, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik

On Fri, Dec 2, 2011 at 2:34 PM, Anton Vorontsov
<anton.vorontsov@linaro.org> wrote:
>
> One option is to test this patch on a board that is now broken:
>
> http://lkml.org/lkml/2011/11/10/290

That seems broken.

Spot the trouble:

  +	ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
  +				    oirq.size);
  +no_irq:
  +#ifdef NO_IRQ
  +#if NO_IRQ != 0
  +	if (ret == NO_IRQ)
  +		pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
  +			"NO_IRQ, but we return 0. If anything breaks, driver "
  +			"have to be fixed.\n");
  +#endif
  +#endif
  +	return ret;

It claims "we return 0", but then doesn't return zero.. Hmm?

                  Linus

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 22:40                   ` Anton Vorontsov
@ 2011-12-02 22:46                     ` Anton Vorontsov
  0 siblings, 0 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-02 22:46 UTC (permalink / raw)
  To: Dave Martin
  Cc: Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Linus Torvalds, Jeff Garzik, Pawel Moll

On Sat, Dec 03, 2011 at 02:40:18AM +0400, Anton Vorontsov wrote:
> On Sat, Dec 03, 2011 at 02:34:02AM +0400, Anton Vorontsov wrote:
> > On Fri, Dec 02, 2011 at 07:19:17PM +0000, Dave Martin wrote:
> > [...]
> > > > > > Drivers should not use NO_IRQ; moreover, some architectures don't
> > > > > > have it nowadays. '0' is the 'no irq' case.
> > > > > > 
> > > > > > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> > > > > 
> > > > > Acked-by: Alan Cox <alan@linux.intel.com>
> > > > 
> > > > In case if we don't want a "band-aid fix" for 3.2, here is the patch
> > > > that just does the proper fix (w/ a risk to break minor architectures).
> > > 
> > > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > > used and is -1.
> > > 
> > > How do we resolve it?
> > 
> > One option is to test this patch on a board that is now broken:
> > 
> > http://lkml.org/lkml/2011/11/10/290
> 
> Oh, actually, reading my own patch:
> 
> "ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
>  which returns correct ('0') value in 'no irq' case. So everything
>  should be fine."

Ahh. Forget it, the remark was for the of/irq.c fix itself.

So, we need the http://lkml.org/lkml/2011/11/10/290 fix. Otherwise
the driver is indeed broken for ARM. Would be great if somebody could
test it.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 19:28                   ` Linus Torvalds
@ 2011-12-02 23:12                     ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 137+ messages in thread
From: Benjamin Herrenschmidt @ 2011-12-02 23:12 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Dave Martin, Anton Vorontsov, Alan Cox, Stephen Rothwell,
	Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
	linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
	linux-arm-kernel

On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> >
> > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > used and is -1.
> >
> > How do we resolve it?  If we are ready to eliminate NO_IRQ from
> > drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> > that case, we should surely just do it... but I'm not confident I can
> > judge on that.
> 
> Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
> as you notice breakage.

Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
which still uses -1, powerpc changed to 0 a long time ago.

Now that we have a generic remapper between HW and "linux" IRQ numbers,
there is no reason to stick to -1 even on ARM.

> Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> around as a marker of brokenness), just start removing it from all the
> ARM drivers that use the OF infrastructure. Which is presumably not
> all that many yet.
> 
> So whenever you find breakage, the fix now is to just remove NO_IRQ
> tests, and replace them with "!irq".

Cheers,
Ben.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-02 23:12                     ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 137+ messages in thread
From: Benjamin Herrenschmidt @ 2011-12-02 23:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> >
> > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > used and is -1.
> >
> > How do we resolve it?  If we are ready to eliminate NO_IRQ from
> > drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> > that case, we should surely just do it... but I'm not confident I can
> > judge on that.
> 
> Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
> as you notice breakage.

Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
which still uses -1, powerpc changed to 0 a long time ago.

Now that we have a generic remapper between HW and "linux" IRQ numbers,
there is no reason to stick to -1 even on ARM.

> Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> around as a marker of brokenness), just start removing it from all the
> ARM drivers that use the OF infrastructure. Which is presumably not
> all that many yet.
> 
> So whenever you find breakage, the fix now is to just remove NO_IRQ
> tests, and replace them with "!irq".

Cheers,
Ben.

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

* [PATCH v2] of/irq: Get rid of NO_IRQ usage
  2011-12-02 22:40                   ` Linus Torvalds
@ 2011-12-02 23:18                     ` Anton Vorontsov
  0 siblings, 0 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-02 23:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Dave Martin, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Benjamin Herrenschmidt

PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.

Other arches might break if some of their OF drivers rely on NO_IRQ
being not 0. If so, the drivers must be fixed, finally.

Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
---

On Fri, Dec 02, 2011 at 02:40:37PM -0800, Linus Torvalds wrote:
> On Fri, Dec 2, 2011 at 2:34 PM, Anton Vorontsov
> <anton.vorontsov@linaro.org> wrote:
> >
> > One option is to test this patch on a board that is now broken:
> >
> > http://lkml.org/lkml/2011/11/10/290
> 
> That seems broken.
> 
> Spot the trouble:
> 
>   +	ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
>   +				    oirq.size);
>   +no_irq:
>   +#ifdef NO_IRQ
>   +#if NO_IRQ != 0
>   +	if (ret == NO_IRQ)
>   +		pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
>   +			"NO_IRQ, but we return 0. If anything breaks, driver "
>   +			"have to be fixed.\n");
>   +#endif
>   +#endif
>   +	return ret;
> 
> It claims "we return 0", but then doesn't return zero.. Hmm?
> 
>                   Linus

Hehe, I never claimed that I tested the patch on any OF platform. :-D

But, the patch would work for ARM anyway. irq_create_of_mapping()
always return 0 in case of 'no irq'. So, in ARM case the problem was
in the hunk that you snipped:

         if (of_irq_map_one(dev, index, &oirq))
 -               return NO_IRQ;
 -

For the arches that don't use IRQ domains and have NO_IRQ != 0 (e.g.
microblaze), you spot the real trouble indeed. Thanks.

Here is the amended fix. I hope it works, and somebody could test it.

p.s.

Initially I proposed a very simple band-aid fix for 3.2, and wanted
the real fix postponed for 3.3 (since nowadays I don't have any OF
machines to test, but this will change soon).

I hope it's a good excuse. ;-)

 drivers/of/irq.c |   32 ++++++++++++++++++++------------
 1 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 791270b..97ee3bd 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -26,11 +26,6 @@
 #include <linux/string.h>
 #include <linux/slab.h>
 
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
 /**
  * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
  * @device: Device node of the device whose interrupt is to be mapped
@@ -42,12 +37,25 @@
 unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
 {
 	struct of_irq oirq;
+	int ret = 0;
 
 	if (of_irq_map_one(dev, index, &oirq))
-		return NO_IRQ;
-
-	return irq_create_of_mapping(oirq.controller, oirq.specifier,
-				     oirq.size);
+		goto no_irq;
+
+	ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+				    oirq.size);
+no_irq:
+#ifdef NO_IRQ
+#if NO_IRQ != 0
+	if (ret == NO_IRQ) {
+		pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
+			"NO_IRQ, but we return 0. If anything breaks, driver "
+			"have to be fixed.\n");
+		ret = 0;
+	}
+#endif
+#endif
+	return ret;
 }
 EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
 
@@ -345,7 +353,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 
 	/* Only dereference the resource if both the
 	 * resource and the irq are valid. */
-	if (r && irq != NO_IRQ) {
+	if (r && irq) {
 		r->start = r->end = irq;
 		r->flags = IORESOURCE_IRQ;
 		r->name = dev->full_name;
@@ -363,7 +371,7 @@ int of_irq_count(struct device_node *dev)
 {
 	int nr = 0;
 
-	while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
+	while (of_irq_to_resource(dev, nr, NULL))
 		nr++;
 
 	return nr;
@@ -383,7 +391,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 	int i;
 
 	for (i = 0; i < nr_irqs; i++, res++)
-		if (of_irq_to_resource(dev, i, res) == NO_IRQ)
+		if (!of_irq_to_resource(dev, i, res))
 			break;
 
 	return i;
-- 
1.7.5.3

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 19:19               ` Dave Martin
  2011-12-02 22:34                 ` Anton Vorontsov
@ 2011-12-02 23:22                 ` Alan Cox
  2011-12-03 18:56                   ` Geert Uytterhoeven
  1 sibling, 1 reply; 137+ messages in thread
From: Alan Cox @ 2011-12-02 23:22 UTC (permalink / raw)
  To: Dave Martin
  Cc: Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Linus Torvalds, Jeff Garzik

> This is now broken on ARM where, for good or bad, NO_IRQ currently is
> used and is -1.

Good.

ARM developers have been told to change this for several years. The nice
approach hasn't worked, the patient approach hasn't worked so now finally
ARM is going to be dragged kicking and screaming into doing the work
everyone else did several years ago.

I have so little sympathy over this that you'll need a quantum physicist
to measure it.

> Half-removing NO_IRQ is going to be problematic, though...
> I really don't care whether the "no irq" value is 0 or -1, but it is
> abundantly clear that choosing different values to mean the same thing
> on opposite sides of an interface does not work.

You've had years to fix it. If I were you I'd delete NO_IRQ from your
tree, type make and get it done. It's not even a big job to clean it out.

At that point various other drivers will also start working properly on
ARM because they use 0 for polled mode.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 23:22                 ` [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver Alan Cox
@ 2011-12-03 18:56                   ` Geert Uytterhoeven
  0 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-03 18:56 UTC (permalink / raw)
  To: Alan Cox
  Cc: Dave Martin, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Linus Torvalds, Jeff Garzik, linux-arch

On Sat, Dec 3, 2011 at 00:22, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> This is now broken on ARM where, for good or bad, NO_IRQ currently is
>> used and is -1.
>
> Good.
>
> ARM developers have been told to change this for several years. The nice
> approach hasn't worked, the patient approach hasn't worked so now finally
> ARM is going to be dragged kicking and screaming into doing the work
> everyone else did several years ago.
>
> I have so little sympathy over this that you'll need a quantum physicist
> to measure it.
>
>> Half-removing NO_IRQ is going to be problematic, though...
>> I really don't care whether the "no irq" value is 0 or -1, but it is
>> abundantly clear that choosing different values to mean the same thing
>> on opposite sides of an interface does not work.
>
> You've had years to fix it. If I were you I'd delete NO_IRQ from your
> tree, type make and get it done. It's not even a big job to clean it out.
>
> At that point various other drivers will also start working properly on
> ARM because they use 0 for polled mode.

Not just ARM:

arch/arm/include/asm/irq.h:#ifndef
NO_IRQarch/arm/include/asm/irq.h:#define NO_IRQ       ((unsigned
int)(-1))arch/microblaze/include/asm/irq.h:#define NO_IRQ
(-1)arch/mn10300/include/asm/irq.h:#define NO_IRQ
INT_MAXarch/openrisc/include/asm/irq.h:#define NO_IRQ
(-1)arch/parisc/include/asm/irq.h:#define NO_IRQ
(-1)arch/powerpc/include/asm/irq.h:#define NO_IRQ
(0)arch/powerpc/include/asm/machdep.h:     /* Return an irq, or NO_IRQ
to indicate arch/powerpc/include/asm/parport.h:             if (virq
== NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq !=
NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq !=
NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq !=
NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq !=
NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq ==
NO_IRQ)arch/powerpc/include/asm/qe_ic.h:       if (cascade_irq !=
NO_IRQ)arch/sparc/include/asm/irq_32.h:#define NO_IRQ
0xffffffffarch/sparc/include/asm/irq_64.h:#define NO_IRQ
0xffffffff

And it's not just definitions of NO_IRQ. These are easy to find.
On some archs (notably ARM) zero still seems to be a valid IRQ number,
e.g. IRQ_LOCOMO_KEY and IRQ_DMA0C0.

Also, UML has TIMER_IRQ being zero.

A quick grep found many more IRQ definitions being zero, but
surprisingly the few
I looked into were definitions without users (e.g. SE7343_FPGA_IRQ_MRSHPC0,
ROUTE_VIA_IRQ0 aka IRQ_MB93493_VDC_ROUTE).

Perhaps request_irq() should just reject zero to find all of them?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-02 23:12                     ` Benjamin Herrenschmidt
@ 2011-12-05 16:11                       ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 16:11 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Benjamin Herrenschmidt, Linus Torvalds, Anton Vorontsov,
	Alan Cox, Stephen Rothwell, Andrew Morton, devicetree-discuss,
	LKML, linux-ide, Randy Dunlap, linux-next, Ingo Molnar,
	Jeff Garzik, Pawel Moll, linux-arm-kernel

On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > >
> > > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > > used and is -1.
> > >
> > > How do we resolve it?  If we are ready to eliminate NO_IRQ from
> > > drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> > > that case, we should surely just do it... but I'm not confident I can
> > > judge on that.
> > 
> > Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
> > as you notice breakage.
> 
> Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
> which still uses -1, powerpc changed to 0 a long time ago.
> 
> Now that we have a generic remapper between HW and "linux" IRQ numbers,
> there is no reason to stick to -1 even on ARM.
> 
> > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > around as a marker of brokenness), just start removing it from all the
> > ARM drivers that use the OF infrastructure. Which is presumably not
> > all that many yet.
> > 
> > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > tests, and replace them with "!irq".
> 

Russell, do you know whether it would make sense to set a timeline for 
removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
case?  I'm assuming that this mainly involves migrating existing hard-wired
code that deals with interrupt numbers to use irq domains.

I worry that if we just change the convention for the OF case, we'll end
up with OF-ised platform drivers which have to deal with a different no-
irq convention depending on whether they are probed as platform drivers
or through the OF framework ... and these ported or semi-ported drivers
will be intermixed with unported drivers, confusing maintainers.
 
If board code starts initialising platform data for non-OF-ised platform
drivers based on IRQ numbers fetched via the OF code, things will get
even more confused...

Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 16:11                       ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 16:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > >
> > > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > > used and is -1.
> > >
> > > How do we resolve it?  If we are ready to eliminate NO_IRQ from
> > > drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> > > that case, we should surely just do it... but I'm not confident I can
> > > judge on that.
> > 
> > Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
> > as you notice breakage.
> 
> Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
> which still uses -1, powerpc changed to 0 a long time ago.
> 
> Now that we have a generic remapper between HW and "linux" IRQ numbers,
> there is no reason to stick to -1 even on ARM.
> 
> > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > around as a marker of brokenness), just start removing it from all the
> > ARM drivers that use the OF infrastructure. Which is presumably not
> > all that many yet.
> > 
> > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > tests, and replace them with "!irq".
> 

Russell, do you know whether it would make sense to set a timeline for 
removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
case?  I'm assuming that this mainly involves migrating existing hard-wired
code that deals with interrupt numbers to use irq domains.

I worry that if we just change the convention for the OF case, we'll end
up with OF-ised platform drivers which have to deal with a different no-
irq convention depending on whether they are probed as platform drivers
or through the OF framework ... and these ported or semi-ported drivers
will be intermixed with unported drivers, confusing maintainers.
 
If board code starts initialising platform data for non-OF-ised platform
drivers based on IRQ numbers fetched via the OF code, things will get
even more confused...

Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 16:11                       ` Dave Martin
@ 2011-12-05 17:40                         ` Nicolas Pitre
  -1 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 17:40 UTC (permalink / raw)
  To: Dave Martin
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:
> On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > around as a marker of brokenness), just start removing it from all the
> > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > all that many yet.
> > > 
> > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > tests, and replace them with "!irq".
> > 
> 
> Russell, do you know whether it would make sense to set a timeline for 
> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> case?  I'm assuming that this mainly involves migrating existing hard-wired
> code that deals with interrupt numbers to use irq domains.

How many drivers do use IRQ #0 to start with?  We might discover that in 
practice there is only a very few cases where this is an issue if 0 
would mean no IRQ.


Nicolas

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 17:40                         ` Nicolas Pitre
  0 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 17:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:
> On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > around as a marker of brokenness), just start removing it from all the
> > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > all that many yet.
> > > 
> > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > tests, and replace them with "!irq".
> > 
> 
> Russell, do you know whether it would make sense to set a timeline for 
> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> case?  I'm assuming that this mainly involves migrating existing hard-wired
> code that deals with interrupt numbers to use irq domains.

How many drivers do use IRQ #0 to start with?  We might discover that in 
practice there is only a very few cases where this is an issue if 0 
would mean no IRQ.


Nicolas

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 16:11                       ` Dave Martin
  (?)
@ 2011-12-05 17:41                           ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 17:41 UTC (permalink / raw)
  To: Dave Martin
  Cc: Stephen Rothwell, Russell King - ARM Linux, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Ingo Molnar,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

> Russell, do you know whether it would make sense to set a timeline for 
> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> case?  I'm assuming that this mainly involves migrating existing hard-wired
> code that deals with interrupt numbers to use irq domains.

The timelime was several years ago. Several years of complete inaction
later the chickens have come home to roost.

I refer you to Linus mail of 26 Sept 2006 to linux-kernel ('restore
libata build on frv')

Quoting Linus email:

>> That's fine -- but don't use zero to mean none. We have NO_IRQ for
>> that, and zero isn't an appropriate choice.
>
> Zero _is_ an appropriate choice, dammit!
>
> That NO_IRQ thing should be zero, and any architecture that thinks that
>zero is a valid IRQ just needs to fix its own irq mapping so that the
> "cookie" doesn't work.
>
> The thing is, it's zero. Get over it. It can't be "-1" or some other
> random value like people have indicated, because that thing is often read
> from places where "-1" simply isn't a possible value (eg it gets its
> default value initialized from a "unsigned char" in MMIO space on x86).
>
> So instead of making everybody and their dog to silly things with some
> NO_IRQ define that they haven't historically done, the rule is simple: "0"
> means "no irq", so that you can test for it with obvious code like
>
>	if (!dev->irq)
>		..
>
> and then, if your actual _hardware_ things that the bit-pattern with all
> bits clear is a valid irq that can be used for normal devices, then what
> you do is you add a irq number translation layer (WHICH WE NEED AND HAVE
> _ANYWAY_) and make sure that nobody sees that on a _software_ level.

----------

On 15th October 2008 Linus said the following to linux-next

> Grr. Can we please just get rid of that IDIOTIC thing instead?
> 
> NO_IRQ was a bad idea to begin with. Let's not add more.
> 
> I assume that broken driver is some ARM-specific thing. I certainly don't 
> want to see NO_IRQ in any general drivers. So instead of having that 
> NO_IRQ insanity spread any more, I'd much rather see the driver either 
> fixed to not use it, or just marked ARM-only.
>
> The proper way to test for whether an interrupt is valid or not is to do
>
> 	if (dev->irq) {
>		...
> and no other. There is no spoon. That NO_IRQ was insane. And
> architectures or drivers that still think otherwise should fix themselves.

------------

So there we are.. ARM spent years ignoring clear direction. If ARM breaks
for a release now so be it. You've had *YEARS* to get off your collective
backsides and sort it out.

> I worry that if we just change the convention for the OF case, we'll end
> up with OF-ised platform drivers which have to deal with a different no-
> irq convention depending on whether they are probed as platform drivers
> or through the OF framework ... and these ported or semi-ported drivers
> will be intermixed with unported drivers, confusing maintainers

All drivers should assume that  if (!dev->irq) works. Zero is not an IRQ
except in certain buried internal invisible cases in arch code (legacy PC
timer being the obvious one).

Come to think about it we had a prior discussion about NO_IRQ in 2005
even!

The core kernel generic IRQ code knows about zero being special, many
common driver layer components such as serial and network phylib do, so
if anything it's going to fix bugs sorting the mess out on ARM.

Jut fix it. Other platforms have done so without problem.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 17:41                           ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 17:41 UTC (permalink / raw)
  To: Dave Martin
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

> Russell, do you know whether it would make sense to set a timeline for 
> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> case?  I'm assuming that this mainly involves migrating existing hard-wired
> code that deals with interrupt numbers to use irq domains.

The timelime was several years ago. Several years of complete inaction
later the chickens have come home to roost.

I refer you to Linus mail of 26 Sept 2006 to linux-kernel ('restore
libata build on frv')

Quoting Linus email:

>> That's fine -- but don't use zero to mean none. We have NO_IRQ for
>> that, and zero isn't an appropriate choice.
>
> Zero _is_ an appropriate choice, dammit!
>
> That NO_IRQ thing should be zero, and any architecture that thinks that
>zero is a valid IRQ just needs to fix its own irq mapping so that the
> "cookie" doesn't work.
>
> The thing is, it's zero. Get over it. It can't be "-1" or some other
> random value like people have indicated, because that thing is often read
> from places where "-1" simply isn't a possible value (eg it gets its
> default value initialized from a "unsigned char" in MMIO space on x86).
>
> So instead of making everybody and their dog to silly things with some
> NO_IRQ define that they haven't historically done, the rule is simple: "0"
> means "no irq", so that you can test for it with obvious code like
>
>	if (!dev->irq)
>		..
>
> and then, if your actual _hardware_ things that the bit-pattern with all
> bits clear is a valid irq that can be used for normal devices, then what
> you do is you add a irq number translation layer (WHICH WE NEED AND HAVE
> _ANYWAY_) and make sure that nobody sees that on a _software_ level.

----------

On 15th October 2008 Linus said the following to linux-next

> Grr. Can we please just get rid of that IDIOTIC thing instead?
> 
> NO_IRQ was a bad idea to begin with. Let's not add more.
> 
> I assume that broken driver is some ARM-specific thing. I certainly don't 
> want to see NO_IRQ in any general drivers. So instead of having that 
> NO_IRQ insanity spread any more, I'd much rather see the driver either 
> fixed to not use it, or just marked ARM-only.
>
> The proper way to test for whether an interrupt is valid or not is to do
>
> 	if (dev->irq) {
>		...
> and no other. There is no spoon. That NO_IRQ was insane. And
> architectures or drivers that still think otherwise should fix themselves.

------------

So there we are.. ARM spent years ignoring clear direction. If ARM breaks
for a release now so be it. You've had *YEARS* to get off your collective
backsides and sort it out.

> I worry that if we just change the convention for the OF case, we'll end
> up with OF-ised platform drivers which have to deal with a different no-
> irq convention depending on whether they are probed as platform drivers
> or through the OF framework ... and these ported or semi-ported drivers
> will be intermixed with unported drivers, confusing maintainers

All drivers should assume that  if (!dev->irq) works. Zero is not an IRQ
except in certain buried internal invisible cases in arch code (legacy PC
timer being the obvious one).

Come to think about it we had a prior discussion about NO_IRQ in 2005
even!

The core kernel generic IRQ code knows about zero being special, many
common driver layer components such as serial and network phylib do, so
if anything it's going to fix bugs sorting the mess out on ARM.

Jut fix it. Other platforms have done so without problem.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 17:41                           ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 17:41 UTC (permalink / raw)
  To: linux-arm-kernel

> Russell, do you know whether it would make sense to set a timeline for 
> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> case?  I'm assuming that this mainly involves migrating existing hard-wired
> code that deals with interrupt numbers to use irq domains.

The timelime was several years ago. Several years of complete inaction
later the chickens have come home to roost.

I refer you to Linus mail of 26 Sept 2006 to linux-kernel ('restore
libata build on frv')

Quoting Linus email:

>> That's fine -- but don't use zero to mean none. We have NO_IRQ for
>> that, and zero isn't an appropriate choice.
>
> Zero _is_ an appropriate choice, dammit!
>
> That NO_IRQ thing should be zero, and any architecture that thinks that
>zero is a valid IRQ just needs to fix its own irq mapping so that the
> "cookie" doesn't work.
>
> The thing is, it's zero. Get over it. It can't be "-1" or some other
> random value like people have indicated, because that thing is often read
> from places where "-1" simply isn't a possible value (eg it gets its
> default value initialized from a "unsigned char" in MMIO space on x86).
>
> So instead of making everybody and their dog to silly things with some
> NO_IRQ define that they haven't historically done, the rule is simple: "0"
> means "no irq", so that you can test for it with obvious code like
>
>	if (!dev->irq)
>		..
>
> and then, if your actual _hardware_ things that the bit-pattern with all
> bits clear is a valid irq that can be used for normal devices, then what
> you do is you add a irq number translation layer (WHICH WE NEED AND HAVE
> _ANYWAY_) and make sure that nobody sees that on a _software_ level.

----------

On 15th October 2008 Linus said the following to linux-next

> Grr. Can we please just get rid of that IDIOTIC thing instead?
> 
> NO_IRQ was a bad idea to begin with. Let's not add more.
> 
> I assume that broken driver is some ARM-specific thing. I certainly don't 
> want to see NO_IRQ in any general drivers. So instead of having that 
> NO_IRQ insanity spread any more, I'd much rather see the driver either 
> fixed to not use it, or just marked ARM-only.
>
> The proper way to test for whether an interrupt is valid or not is to do
>
> 	if (dev->irq) {
>		...
> and no other. There is no spoon. That NO_IRQ was insane. And
> architectures or drivers that still think otherwise should fix themselves.

------------

So there we are.. ARM spent years ignoring clear direction. If ARM breaks
for a release now so be it. You've had *YEARS* to get off your collective
backsides and sort it out.

> I worry that if we just change the convention for the OF case, we'll end
> up with OF-ised platform drivers which have to deal with a different no-
> irq convention depending on whether they are probed as platform drivers
> or through the OF framework ... and these ported or semi-ported drivers
> will be intermixed with unported drivers, confusing maintainers

All drivers should assume that  if (!dev->irq) works. Zero is not an IRQ
except in certain buried internal invisible cases in arch code (legacy PC
timer being the obvious one).

Come to think about it we had a prior discussion about NO_IRQ in 2005
even!

The core kernel generic IRQ code knows about zero being special, many
common driver layer components such as serial and network phylib do, so
if anything it's going to fix bugs sorting the mess out on ARM.

Jut fix it. Other platforms have done so without problem.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 17:40                         ` Nicolas Pitre
@ 2011-12-05 18:02                           ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 18:02 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > around as a marker of brokenness), just start removing it from all the
> > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > all that many yet.
> > > > 
> > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > tests, and replace them with "!irq".
> > > 
> > 
> > Russell, do you know whether it would make sense to set a timeline for 
> > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > code that deals with interrupt numbers to use irq domains.
> 
> How many drivers do use IRQ #0 to start with?  We might discover that in 
> practice there is only a very few cases where this is an issue if 0 
> would mean no IRQ.

The total number of files referring to NO_IRQ is not that huge:

arch/arm/	188 matches in 39 files
drivers/	174 matches in 84 files

Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
"irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
Since there's no specific thing we can grep for (and simply due to volume)
finding all such instances may be quite a bit harder.

For example, git grep 'irq.*\(>=\|<[^=]\) *0' gives

drivers/	435 matches in 314 files
arch/arm/	18 matches in 15 files

A few examples:
drivers/input/mouse/pxa930_trkball.c:   if (irq < 0) {
drivers/input/keyboard/tegra-kbc.c:     if (irq < 0) {
drivers/crypto/omap-sham.c:     if (dd->irq >= 0)

...etc., etc., although there are probably a fair number of false positives here.


whereas git grep 'irq.*\(<\|>\|<=\|>=\|==\|!=\) \+-1' gives

drivers/	68 matches in 28 files
arch/arm/	18 matches in 15 files

Examples: 


...and that's just the code which is C and is also kind enough to put
irq numbers in variables with names containing "irq".

It also doesn't catch people initialising variables or struct/array
members to -1, unadorned "-1" arguments to functions and so on... though
those are likely to appear in mostly the same files matching the above
expressions, it won't be an exact 1:1 correspondence.


Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 18:02                           ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 18:02 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > around as a marker of brokenness), just start removing it from all the
> > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > all that many yet.
> > > > 
> > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > tests, and replace them with "!irq".
> > > 
> > 
> > Russell, do you know whether it would make sense to set a timeline for 
> > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > code that deals with interrupt numbers to use irq domains.
> 
> How many drivers do use IRQ #0 to start with?  We might discover that in 
> practice there is only a very few cases where this is an issue if 0 
> would mean no IRQ.

The total number of files referring to NO_IRQ is not that huge:

arch/arm/	188 matches in 39 files
drivers/	174 matches in 84 files

Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
"irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
Since there's no specific thing we can grep for (and simply due to volume)
finding all such instances may be quite a bit harder.

For example, git grep 'irq.*\(>=\|<[^=]\) *0' gives

drivers/	435 matches in 314 files
arch/arm/	18 matches in 15 files

A few examples:
drivers/input/mouse/pxa930_trkball.c:   if (irq < 0) {
drivers/input/keyboard/tegra-kbc.c:     if (irq < 0) {
drivers/crypto/omap-sham.c:     if (dd->irq >= 0)

...etc., etc., although there are probably a fair number of false positives here.


whereas git grep 'irq.*\(<\|>\|<=\|>=\|==\|!=\) \+-1' gives

drivers/	68 matches in 28 files
arch/arm/	18 matches in 15 files

Examples: 


...and that's just the code which is C and is also kind enough to put
irq numbers in variables with names containing "irq".

It also doesn't catch people initialising variables or struct/array
members to -1, unadorned "-1" arguments to functions and so on... though
those are likely to appear in mostly the same files matching the above
expressions, it won't be an exact 1:1 correspondence.


Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:02                           ` Dave Martin
@ 2011-12-05 18:15                             ` Geert Uytterhoeven
  -1 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-05 18:15 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Russell King - ARM Linux, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
	Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
	linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
	linux-arm-kernel

On Mon, Dec 5, 2011 at 19:02, Dave Martin <dave.martin@linaro.org> wrote:
> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".

Can we make irq unsigned, and hope the compiler catches all of them
(comparison always
false blah blah blah)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 18:15                             ` Geert Uytterhoeven
  0 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-05 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 5, 2011 at 19:02, Dave Martin <dave.martin@linaro.org> wrote:
> Unfortunately, NO_IRQ is often not spelled "NO_IRQ". ?It looks like the assumption
> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".

Can we make irq unsigned, and hope the compiler catches all of them
(comparison always
false blah blah blah)?

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:02                           ` Dave Martin
@ 2011-12-05 18:18                             ` Nicolas Pitre
  -1 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 18:18 UTC (permalink / raw)
  To: Dave Martin
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > around as a marker of brokenness), just start removing it from all the
> > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > all that many yet.
> > > > > 
> > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > tests, and replace them with "!irq".
> > > > 
> > > 
> > > Russell, do you know whether it would make sense to set a timeline for 
> > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > code that deals with interrupt numbers to use irq domains.
> > 
> > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > practice there is only a very few cases where this is an issue if 0 
> > would mean no IRQ.
> 
> The total number of files referring to NO_IRQ is not that huge:
> 
> arch/arm/	188 matches in 39 files
> drivers/	174 matches in 84 files
> 
> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> Since there's no specific thing we can grep for (and simply due to volume)
> finding all such instances may be quite a bit harder.
[...]

ARgh.

My point was about current actual usage of the IRQ numbered 0 which 
probably prompted the introduction of NO_IRQ in the first place.  What I 
was saying is that the number of occurrences where IRQ #0 is currently 
used into drivers that would get confused if 0 would mean no IRQ is 
probably quite small.

But as you illustrated, there is a large number of drivers that already 
assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
That is a much bigger problem to fix.


Nicolas

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 18:18                             ` Nicolas Pitre
  0 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 18:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > around as a marker of brokenness), just start removing it from all the
> > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > all that many yet.
> > > > > 
> > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > tests, and replace them with "!irq".
> > > > 
> > > 
> > > Russell, do you know whether it would make sense to set a timeline for 
> > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > code that deals with interrupt numbers to use irq domains.
> > 
> > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > practice there is only a very few cases where this is an issue if 0 
> > would mean no IRQ.
> 
> The total number of files referring to NO_IRQ is not that huge:
> 
> arch/arm/	188 matches in 39 files
> drivers/	174 matches in 84 files
> 
> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> Since there's no specific thing we can grep for (and simply due to volume)
> finding all such instances may be quite a bit harder.
[...]

ARgh.

My point was about current actual usage of the IRQ numbered 0 which 
probably prompted the introduction of NO_IRQ in the first place.  What I 
was saying is that the number of occurrences where IRQ #0 is currently 
used into drivers that would get confused if 0 would mean no IRQ is 
probably quite small.

But as you illustrated, there is a large number of drivers that already 
assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
That is a much bigger problem to fix.


Nicolas

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:18                             ` Nicolas Pitre
  (?)
@ 2011-12-05 18:45                                 ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 18:45 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Stephen Rothwell, Russell King - ARM Linux, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Ingo Molnar,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.

And a much larger number assuming the reverse is true which are hiding
potential bugs on ARM.

Looking at the serial stuff the best checks appear to be looking at
"irq", "-1" and NO_IRQ.

For migration stuff that's doing broken things like

	if (irq < 0)

can be changed to

	if (irq <= 0)

and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 18:45                                 ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 18:45 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Dave Martin, Russell King - ARM Linux, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.

And a much larger number assuming the reverse is true which are hiding
potential bugs on ARM.

Looking at the serial stuff the best checks appear to be looking at
"irq", "-1" and NO_IRQ.

For migration stuff that's doing broken things like

	if (irq < 0)

can be changed to

	if (irq <= 0)

and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 18:45                                 ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 18:45 UTC (permalink / raw)
  To: linux-arm-kernel

> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.

And a much larger number assuming the reverse is true which are hiding
potential bugs on ARM.

Looking at the serial stuff the best checks appear to be looking at
"irq", "-1" and NO_IRQ.

For migration stuff that's doing broken things like

	if (irq < 0)

can be changed to

	if (irq <= 0)

and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:18                             ` Nicolas Pitre
  (?)
@ 2011-12-05 19:16                                 ` Rob Herring
  -1 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-05 19:16 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Stephen Rothwell, Russell King - ARM Linux, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Ingo Molnar, LKML,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Alan Cox, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On 12/05/2011 12:18 PM, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> 
>> On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
>>> On Mon, 5 Dec 2011, Dave Martin wrote:
>>>> On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
>>>>> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
>>>>>> Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
>>>>>> around as a marker of brokenness), just start removing it from all the
>>>>>> ARM drivers that use the OF infrastructure. Which is presumably not
>>>>>> all that many yet.
>>>>>>
>>>>>> So whenever you find breakage, the fix now is to just remove NO_IRQ
>>>>>> tests, and replace them with "!irq".
>>>>>
>>>>
>>>> Russell, do you know whether it would make sense to set a timeline for 
>>>> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
>>>> case?  I'm assuming that this mainly involves migrating existing hard-wired
>>>> code that deals with interrupt numbers to use irq domains.
>>>
>>> How many drivers do use IRQ #0 to start with?  We might discover that in 
>>> practice there is only a very few cases where this is an issue if 0 
>>> would mean no IRQ.
>>
>> The total number of files referring to NO_IRQ is not that huge:
>>
>> arch/arm/	188 matches in 39 files
>> drivers/	174 matches in 84 files
>>
>> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
>> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
>> Since there's no specific thing we can grep for (and simply due to volume)
>> finding all such instances may be quite a bit harder.
> [...]
> 
> ARgh.
> 
> My point was about current actual usage of the IRQ numbered 0 which 
> probably prompted the introduction of NO_IRQ in the first place.  What I 
> was saying is that the number of occurrences where IRQ #0 is currently 
> used into drivers that would get confused if 0 would mean no IRQ is 
> probably quite small.
> 
> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.
> 

At least for DT enabled platforms, we could force "no irq" to be 0 in
the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
should be fine currently as it doesn't use the of_irq_* functions to get
the timer irq, but that is an issue as it skips any translation.
VersatileAB should be okay with the VIC irqdomain support.

Changing it would also affect microblaze and openrisc which have NO_IRQ
set to -1. From what I can tell, they would both be fine at least in
terms of not using IRQ0.

Also, there's roughly 50 irq_chips that need irq_domain support under
arch/arm. So that's not a simple solution either.

Rob

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 19:16                                 ` Rob Herring
  0 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-05 19:16 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Dave Martin, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss, LKML, Jeff Garzik, linux-ide,
	Randy Dunlap, linux-next, linux-arm-kernel, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Ingo Molnar, Alan Cox, Jonas Bonn,
	Michal Simek, Grant Likely

On 12/05/2011 12:18 PM, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> 
>> On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
>>> On Mon, 5 Dec 2011, Dave Martin wrote:
>>>> On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
>>>>> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
>>>>>> Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
>>>>>> around as a marker of brokenness), just start removing it from all the
>>>>>> ARM drivers that use the OF infrastructure. Which is presumably not
>>>>>> all that many yet.
>>>>>>
>>>>>> So whenever you find breakage, the fix now is to just remove NO_IRQ
>>>>>> tests, and replace them with "!irq".
>>>>>
>>>>
>>>> Russell, do you know whether it would make sense to set a timeline for 
>>>> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
>>>> case?  I'm assuming that this mainly involves migrating existing hard-wired
>>>> code that deals with interrupt numbers to use irq domains.
>>>
>>> How many drivers do use IRQ #0 to start with?  We might discover that in 
>>> practice there is only a very few cases where this is an issue if 0 
>>> would mean no IRQ.
>>
>> The total number of files referring to NO_IRQ is not that huge:
>>
>> arch/arm/	188 matches in 39 files
>> drivers/	174 matches in 84 files
>>
>> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
>> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
>> Since there's no specific thing we can grep for (and simply due to volume)
>> finding all such instances may be quite a bit harder.
> [...]
> 
> ARgh.
> 
> My point was about current actual usage of the IRQ numbered 0 which 
> probably prompted the introduction of NO_IRQ in the first place.  What I 
> was saying is that the number of occurrences where IRQ #0 is currently 
> used into drivers that would get confused if 0 would mean no IRQ is 
> probably quite small.
> 
> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.
> 

At least for DT enabled platforms, we could force "no irq" to be 0 in
the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
should be fine currently as it doesn't use the of_irq_* functions to get
the timer irq, but that is an issue as it skips any translation.
VersatileAB should be okay with the VIC irqdomain support.

Changing it would also affect microblaze and openrisc which have NO_IRQ
set to -1. From what I can tell, they would both be fine at least in
terms of not using IRQ0.

Also, there's roughly 50 irq_chips that need irq_domain support under
arch/arm. So that's not a simple solution either.

Rob

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 19:16                                 ` Rob Herring
  0 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-05 19:16 UTC (permalink / raw)
  To: linux-arm-kernel

On 12/05/2011 12:18 PM, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> 
>> On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
>>> On Mon, 5 Dec 2011, Dave Martin wrote:
>>>> On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
>>>>> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
>>>>>> Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
>>>>>> around as a marker of brokenness), just start removing it from all the
>>>>>> ARM drivers that use the OF infrastructure. Which is presumably not
>>>>>> all that many yet.
>>>>>>
>>>>>> So whenever you find breakage, the fix now is to just remove NO_IRQ
>>>>>> tests, and replace them with "!irq".
>>>>>
>>>>
>>>> Russell, do you know whether it would make sense to set a timeline for 
>>>> removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
>>>> case?  I'm assuming that this mainly involves migrating existing hard-wired
>>>> code that deals with interrupt numbers to use irq domains.
>>>
>>> How many drivers do use IRQ #0 to start with?  We might discover that in 
>>> practice there is only a very few cases where this is an issue if 0 
>>> would mean no IRQ.
>>
>> The total number of files referring to NO_IRQ is not that huge:
>>
>> arch/arm/	188 matches in 39 files
>> drivers/	174 matches in 84 files
>>
>> Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
>> "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
>> Since there's no specific thing we can grep for (and simply due to volume)
>> finding all such instances may be quite a bit harder.
> [...]
> 
> ARgh.
> 
> My point was about current actual usage of the IRQ numbered 0 which 
> probably prompted the introduction of NO_IRQ in the first place.  What I 
> was saying is that the number of occurrences where IRQ #0 is currently 
> used into drivers that would get confused if 0 would mean no IRQ is 
> probably quite small.
> 
> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.
> 

At least for DT enabled platforms, we could force "no irq" to be 0 in
the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
should be fine currently as it doesn't use the of_irq_* functions to get
the timer irq, but that is an issue as it skips any translation.
VersatileAB should be okay with the VIC irqdomain support.

Changing it would also affect microblaze and openrisc which have NO_IRQ
set to -1. From what I can tell, they would both be fine at least in
terms of not using IRQ0.

Also, there's roughly 50 irq_chips that need irq_domain support under
arch/arm. So that's not a simple solution either.

Rob

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:45                                 ` Alan Cox
@ 2011-12-05 19:19                                   ` James Bottomley
  -1 siblings, 0 replies; 137+ messages in thread
From: James Bottomley @ 2011-12-05 19:19 UTC (permalink / raw)
  To: Alan Cox
  Cc: Nicolas Pitre, Dave Martin, Russell King - ARM Linux,
	Benjamin Herrenschmidt, Linus Torvalds, Anton Vorontsov,
	Stephen Rothwell, Andrew Morton, devicetree-discuss, LKML,
	linux-ide, Randy Dunlap, linux-next, Ingo Molnar, Jeff Garzik,
	Pawel Moll, linux-arm-kernel

On Mon, 2011-12-05 at 18:45 +0000, Alan Cox wrote:
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> And a much larger number assuming the reverse is true which are hiding
> potential bugs on ARM.
> 
> Looking at the serial stuff the best checks appear to be looking at
> "irq", "-1" and NO_IRQ.
> 
> For migration stuff that's doing broken things like
> 
> 	if (irq < 0)
> 
> can be changed to
> 
> 	if (irq <= 0)
> 
> and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.

To be honest, we don't care very much.  Parisc interrupts are cascading
and mostly software assigned (except our EIEM which we keep internal).
We use a base offset at 16 or 64 (depending on GSC presence or not) so
IRQs 0-15 aren't legal on parisc either (we frob some of the hard coded
ISA interrupts on the WAX eisa bus).

We use NO_IRQ as an IRQ assignment error return and that's about it (and
that error shouldn't ever really occur).

James

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 19:19                                   ` James Bottomley
  0 siblings, 0 replies; 137+ messages in thread
From: James Bottomley @ 2011-12-05 19:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 2011-12-05 at 18:45 +0000, Alan Cox wrote:
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> And a much larger number assuming the reverse is true which are hiding
> potential bugs on ARM.
> 
> Looking at the serial stuff the best checks appear to be looking at
> "irq", "-1" and NO_IRQ.
> 
> For migration stuff that's doing broken things like
> 
> 	if (irq < 0)
> 
> can be changed to
> 
> 	if (irq <= 0)
> 
> and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.

To be honest, we don't care very much.  Parisc interrupts are cascading
and mostly software assigned (except our EIEM which we keep internal).
We use a base offset at 16 or 64 (depending on GSC presence or not) so
IRQs 0-15 aren't legal on parisc either (we frob some of the hard coded
ISA interrupts on the WAX eisa bus).

We use NO_IRQ as an IRQ assignment error return and that's about it (and
that error shouldn't ever really occur).

James

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:18                             ` Nicolas Pitre
@ 2011-12-05 19:26                               ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 19:26 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, Dec 05, 2011 at 01:18:30PM -0500, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> 
> > On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > > around as a marker of brokenness), just start removing it from all the
> > > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > > all that many yet.
> > > > > > 
> > > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > > tests, and replace them with "!irq".
> > > > > 
> > > > 
> > > > Russell, do you know whether it would make sense to set a timeline for 
> > > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > > code that deals with interrupt numbers to use irq domains.
> > > 
> > > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > > practice there is only a very few cases where this is an issue if 0 
> > > would mean no IRQ.
> > 
> > The total number of files referring to NO_IRQ is not that huge:
> > 
> > arch/arm/	188 matches in 39 files
> > drivers/	174 matches in 84 files
> > 
> > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > Since there's no specific thing we can grep for (and simply due to volume)
> > finding all such instances may be quite a bit harder.
> [...]
> 
> ARgh.
> 
> My point was about current actual usage of the IRQ numbered 0 which 
> probably prompted the introduction of NO_IRQ in the first place.  What I 
> was saying is that the number of occurrences where IRQ #0 is currently 
> used into drivers that would get confused if 0 would mean no IRQ is 
> probably quite small.

Ah, I misunderstood -- that's a separate issue, but also an important one.
I guess this applies to a fair number of older boards.  One way of fixing
this would be to migrate those boards to use irq domains -- but those boards
may be sporadically maintained.
 
> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.

My concern is that as soon as we start to change this in significant
volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
is passed from one piece of code to another, there is a potential
interface mismatch -- there seems to be no single place where we can
apply a conversion and fix everything.


Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 19:26                               ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-05 19:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 05, 2011 at 01:18:30PM -0500, Nicolas Pitre wrote:
> On Mon, 5 Dec 2011, Dave Martin wrote:
> 
> > On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > > around as a marker of brokenness), just start removing it from all the
> > > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > > all that many yet.
> > > > > > 
> > > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > > tests, and replace them with "!irq".
> > > > > 
> > > > 
> > > > Russell, do you know whether it would make sense to set a timeline for 
> > > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > > code that deals with interrupt numbers to use irq domains.
> > > 
> > > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > > practice there is only a very few cases where this is an issue if 0 
> > > would mean no IRQ.
> > 
> > The total number of files referring to NO_IRQ is not that huge:
> > 
> > arch/arm/	188 matches in 39 files
> > drivers/	174 matches in 84 files
> > 
> > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > Since there's no specific thing we can grep for (and simply due to volume)
> > finding all such instances may be quite a bit harder.
> [...]
> 
> ARgh.
> 
> My point was about current actual usage of the IRQ numbered 0 which 
> probably prompted the introduction of NO_IRQ in the first place.  What I 
> was saying is that the number of occurrences where IRQ #0 is currently 
> used into drivers that would get confused if 0 would mean no IRQ is 
> probably quite small.

Ah, I misunderstood -- that's a separate issue, but also an important one.
I guess this applies to a fair number of older boards.  One way of fixing
this would be to migrate those boards to use irq domains -- but those boards
may be sporadically maintained.
 
> But as you illustrated, there is a large number of drivers that already 
> assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> That is a much bigger problem to fix.

My concern is that as soon as we start to change this in significant
volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
is passed from one piece of code to another, there is a potential
interface mismatch -- there seems to be no single place where we can
apply a conversion and fix everything.


Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 19:26                               ` Dave Martin
@ 2011-12-05 19:49                                 ` Nicolas Pitre
  -1 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 19:49 UTC (permalink / raw)
  To: Dave Martin
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 01:18:30PM -0500, Nicolas Pitre wrote:
> > On Mon, 5 Dec 2011, Dave Martin wrote:
> > 
> > > On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > > > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > > > around as a marker of brokenness), just start removing it from all the
> > > > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > > > all that many yet.
> > > > > > > 
> > > > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > > > tests, and replace them with "!irq".
> > > > > > 
> > > > > 
> > > > > Russell, do you know whether it would make sense to set a timeline for 
> > > > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > > > code that deals with interrupt numbers to use irq domains.
> > > > 
> > > > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > > > practice there is only a very few cases where this is an issue if 0 
> > > > would mean no IRQ.
> > > 
> > > The total number of files referring to NO_IRQ is not that huge:
> > > 
> > > arch/arm/	188 matches in 39 files
> > > drivers/	174 matches in 84 files
> > > 
> > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > Since there's no specific thing we can grep for (and simply due to volume)
> > > finding all such instances may be quite a bit harder.
> > [...]
> > 
> > ARgh.
> > 
> > My point was about current actual usage of the IRQ numbered 0 which 
> > probably prompted the introduction of NO_IRQ in the first place.  What I 
> > was saying is that the number of occurrences where IRQ #0 is currently 
> > used into drivers that would get confused if 0 would mean no IRQ is 
> > probably quite small.
> 
> Ah, I misunderstood -- that's a separate issue, but also an important one.
> I guess this applies to a fair number of older boards.  One way of fixing
> this would be to migrate those boards to use irq domains -- but those boards
> may be sporadically maintained.
>  
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> My concern is that as soon as we start to change this in significant
> volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
> is passed from one piece of code to another, there is a potential
> interface mismatch -- there seems to be no single place where we can
> apply a conversion and fix everything.

No need to convert everything.

First move is to make irq=0 meaning no IRQ.  That means making things 
like:

	if (irq < 0)
	if (irq >= 0)

into

	if (irq <= 0)
	if (irq > 0)

And replace NO_IRQ with 0.

That change shouldn't break anything, except those drivers which are 1) 
being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
those conditions aren't very common together.


Nicolas

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 19:49                                 ` Nicolas Pitre
  0 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-05 19:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 5 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 01:18:30PM -0500, Nicolas Pitre wrote:
> > On Mon, 5 Dec 2011, Dave Martin wrote:
> > 
> > > On Mon, Dec 05, 2011 at 12:40:16PM -0500, Nicolas Pitre wrote:
> > > > On Mon, 5 Dec 2011, Dave Martin wrote:
> > > > > On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> > > > > > On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > > > > > > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > > > > > > around as a marker of brokenness), just start removing it from all the
> > > > > > > ARM drivers that use the OF infrastructure. Which is presumably not
> > > > > > > all that many yet.
> > > > > > > 
> > > > > > > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > > > > > > tests, and replace them with "!irq".
> > > > > > 
> > > > > 
> > > > > Russell, do you know whether it would make sense to set a timeline for 
> > > > > removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
> > > > > case?  I'm assuming that this mainly involves migrating existing hard-wired
> > > > > code that deals with interrupt numbers to use irq domains.
> > > > 
> > > > How many drivers do use IRQ #0 to start with?  We might discover that in 
> > > > practice there is only a very few cases where this is an issue if 0 
> > > > would mean no IRQ.
> > > 
> > > The total number of files referring to NO_IRQ is not that huge:
> > > 
> > > arch/arm/	188 matches in 39 files
> > > drivers/	174 matches in 84 files
> > > 
> > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > Since there's no specific thing we can grep for (and simply due to volume)
> > > finding all such instances may be quite a bit harder.
> > [...]
> > 
> > ARgh.
> > 
> > My point was about current actual usage of the IRQ numbered 0 which 
> > probably prompted the introduction of NO_IRQ in the first place.  What I 
> > was saying is that the number of occurrences where IRQ #0 is currently 
> > used into drivers that would get confused if 0 would mean no IRQ is 
> > probably quite small.
> 
> Ah, I misunderstood -- that's a separate issue, but also an important one.
> I guess this applies to a fair number of older boards.  One way of fixing
> this would be to migrate those boards to use irq domains -- but those boards
> may be sporadically maintained.
>  
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> My concern is that as soon as we start to change this in significant
> volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
> is passed from one piece of code to another, there is a potential
> interface mismatch -- there seems to be no single place where we can
> apply a conversion and fix everything.

No need to convert everything.

First move is to make irq=0 meaning no IRQ.  That means making things 
like:

	if (irq < 0)
	if (irq >= 0)

into

	if (irq <= 0)
	if (irq > 0)

And replace NO_IRQ with 0.

That change shouldn't break anything, except those drivers which are 1) 
being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
those conditions aren't very common together.


Nicolas

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 19:16                                 ` Rob Herring
@ 2011-12-05 20:21                                   ` Anton Vorontsov
  -1 siblings, 0 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-05 20:21 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Pitre, Dave Martin, Stephen Rothwell,
	Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
	Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
	linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox, Jonas Bonn, Michal Simek, Grant Likely

On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
[...]
> At least for DT enabled platforms, we could force "no irq" to be 0 in
> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.

Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
dev->irq and thus the thing that we pass into request_irq() is a
virtual IRQ thing, a "cookie".

While in device tree you see real HW IRQ numbers.

Legal VIRQ is always > 0, while HW IRQ could be >= 0.

> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> should be fine currently as it doesn't use the of_irq_* functions to get
> the timer irq, but that is an issue as it skips any translation.
> VersatileAB should be okay with the VIC irqdomain support.

It shouldn't be an issue to use of_irq_*() functions for these IRQs.
of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
this currently, then it's a bug and should be fixed.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 20:21                                   ` Anton Vorontsov
  0 siblings, 0 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-05 20:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
[...]
> At least for DT enabled platforms, we could force "no irq" to be 0 in
> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.

Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
dev->irq and thus the thing that we pass into request_irq() is a
virtual IRQ thing, a "cookie".

While in device tree you see real HW IRQ numbers.

Legal VIRQ is always > 0, while HW IRQ could be >= 0.

> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> should be fine currently as it doesn't use the of_irq_* functions to get
> the timer irq, but that is an issue as it skips any translation.
> VersatileAB should be okay with the VIC irqdomain support.

It shouldn't be an issue to use of_irq_*() functions for these IRQs.
of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
this currently, then it's a bug and should be fixed.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru at gmail.com

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 20:21                                   ` Anton Vorontsov
@ 2011-12-05 20:47                                     ` Rob Herring
  -1 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-05 20:47 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Nicolas Pitre, Dave Martin, Stephen Rothwell,
	Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
	Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
	linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox, Jonas Bonn, Michal Simek, Grant Likely

On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> [...]
>> At least for DT enabled platforms, we could force "no irq" to be 0 in
>> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> 
> Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> dev->irq and thus the thing that we pass into request_irq() is a
> virtual IRQ thing, a "cookie".
> 
> While in device tree you see real HW IRQ numbers.
> 
> Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> 

If this was all true, then there would be no discussion.

This is what we are working towards, but irq_chips all over the arm tree
do not support any translation or have base fixed at compile time. Only
a few have been converted. And some ARM platforms may never get
converted to DT.

>> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
>> should be fine currently as it doesn't use the of_irq_* functions to get
>> the timer irq, but that is an issue as it skips any translation.
>> VersatileAB should be okay with the VIC irqdomain support.
> 
> It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> this currently, then it's a bug and should be fixed.

I think that's what I'm saying. It's either a bug or incomplete DT
conversion for the platform. Either way, those should get fixed first.

Rob

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 20:47                                     ` Rob Herring
  0 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-05 20:47 UTC (permalink / raw)
  To: linux-arm-kernel

On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> [...]
>> At least for DT enabled platforms, we could force "no irq" to be 0 in
>> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> 
> Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> dev->irq and thus the thing that we pass into request_irq() is a
> virtual IRQ thing, a "cookie".
> 
> While in device tree you see real HW IRQ numbers.
> 
> Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> 

If this was all true, then there would be no discussion.

This is what we are working towards, but irq_chips all over the arm tree
do not support any translation or have base fixed at compile time. Only
a few have been converted. And some ARM platforms may never get
converted to DT.

>> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
>> should be fine currently as it doesn't use the of_irq_* functions to get
>> the timer irq, but that is an issue as it skips any translation.
>> VersatileAB should be okay with the VIC irqdomain support.
> 
> It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> this currently, then it's a bug and should be fixed.

I think that's what I'm saying. It's either a bug or incomplete DT
conversion for the platform. Either way, those should get fixed first.

Rob

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 20:47                                     ` Rob Herring
  (?)
@ 2011-12-05 20:53                                         ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 20:53 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA,
	Randy Dunlap, linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon, 05 Dec 2011 14:47:29 -0600
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.

Or more to the point. If the ARM people concerned had listened in 2005,
2006 or 2008 there would be no discussion.

> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.

You've had six years. Let them break, it'll motivate any users to fix
them.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 20:53                                         ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 20:53 UTC (permalink / raw)
  To: Rob Herring
  Cc: Anton Vorontsov, Nicolas Pitre, Dave Martin, Stephen Rothwell,
	Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
	Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
	linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Jonas Bonn, Michal Simek, Grant Likely

On Mon, 05 Dec 2011 14:47:29 -0600
Rob Herring <robherring2@gmail.com> wrote:

> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.

Or more to the point. If the ARM people concerned had listened in 2005,
2006 or 2008 there would be no discussion.

> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.

You've had six years. Let them break, it'll motivate any users to fix
them.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-05 20:53                                         ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-05 20:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 05 Dec 2011 14:47:29 -0600
Rob Herring <robherring2@gmail.com> wrote:

> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.

Or more to the point. If the ARM people concerned had listened in 2005,
2006 or 2008 there would be no discussion.

> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.

You've had six years. Let them break, it'll motivate any users to fix
them.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 18:45                                 ` Alan Cox
@ 2011-12-06  6:13                                   ` Jean-Christophe PLAGNIOL-VILLARD
  -1 siblings, 0 replies; 137+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-12-06  6:13 UTC (permalink / raw)
  To: Alan Cox
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss, LKML, Jeff Garzik, linux-ide,
	Randy Dunlap, linux-next, Anton Vorontsov, Andrew Morton,
	Linus Torvalds, Ingo Molnar, linux-arm-kernel

On 18:45 Mon 05 Dec     , Alan Cox wrote:
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> And a much larger number assuming the reverse is true which are hiding
> potential bugs on ARM.
> 
> Looking at the serial stuff the best checks appear to be looking at
> "irq", "-1" and NO_IRQ.
> 
> For migration stuff that's doing broken things like
> 
> 	if (irq < 0)
> 
> can be changed to
> 
> 	if (irq <= 0)
> 
> and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.
can we sinply introduce a macro irq_is_valid

and make it chip dependant as gpio_is_valid
and then move away from irq 0 valid

so we do not need to brake anthing first and then easly convert them

Best Regards,
J.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06  6:13                                   ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 0 replies; 137+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-12-06  6:13 UTC (permalink / raw)
  To: linux-arm-kernel

On 18:45 Mon 05 Dec     , Alan Cox wrote:
> > But as you illustrated, there is a large number of drivers that already 
> > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > That is a much bigger problem to fix.
> 
> And a much larger number assuming the reverse is true which are hiding
> potential bugs on ARM.
> 
> Looking at the serial stuff the best checks appear to be looking at
> "irq", "-1" and NO_IRQ.
> 
> For migration stuff that's doing broken things like
> 
> 	if (irq < 0)
> 
> can be changed to
> 
> 	if (irq <= 0)
> 
> and that can be done before NO_IRQ itself is nailed on ARM and PA-RISC.
can we sinply introduce a macro irq_is_valid

and make it chip dependant as gpio_is_valid
and then move away from irq 0 valid

so we do not need to brake anthing first and then easly convert them

Best Regards,
J.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 20:47                                     ` Rob Herring
@ 2011-12-06  9:30                                       ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06  9:30 UTC (permalink / raw)
  To: Rob Herring
  Cc: Anton Vorontsov, Nicolas Pitre, Stephen Rothwell,
	Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
	Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
	linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox, Jonas Bonn, Michal Simek, Grant Likely

On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote:
> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.
> 
> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.
> 
> >> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> >> should be fine currently as it doesn't use the of_irq_* functions to get
> >> the timer irq, but that is an issue as it skips any translation.
> >> VersatileAB should be okay with the VIC irqdomain support.
> > 
> > It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> > of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> > this currently, then it's a bug and should be fixed.
> 
> I think that's what I'm saying. It's either a bug or incomplete DT
> conversion for the platform. Either way, those should get fixed first.

Do we expect there to be any platform drivers which are shared between
legacy platforms and newer DT-ised platforms?

Those drivers would be pain points since they would need to understand
both conventions.

So far as I can see, only boards which are not DT-ised, which do not use
DT-ised drivers and which do not use drivers which use interrupts and
are either used by DT-ised boards or by arches with a non-zero NO_IRQ
could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
which boards and drivers this applies to could be hard.  We could have a
CONFIG_NO_IRQ and make them depend on it, but we still have to find that
list of boards and drivers in the first place.


Otherwise, it feels like we might need a strategy for migrating pretty
much everything if we don't want to end up in a mess.

Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06  9:30                                       ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06  9:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote:
> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.
> 
> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.
> 
> >> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> >> should be fine currently as it doesn't use the of_irq_* functions to get
> >> the timer irq, but that is an issue as it skips any translation.
> >> VersatileAB should be okay with the VIC irqdomain support.
> > 
> > It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> > of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> > this currently, then it's a bug and should be fixed.
> 
> I think that's what I'm saying. It's either a bug or incomplete DT
> conversion for the platform. Either way, those should get fixed first.

Do we expect there to be any platform drivers which are shared between
legacy platforms and newer DT-ised platforms?

Those drivers would be pain points since they would need to understand
both conventions.

So far as I can see, only boards which are not DT-ised, which do not use
DT-ised drivers and which do not use drivers which use interrupts and
are either used by DT-ised boards or by arches with a non-zero NO_IRQ
could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
which boards and drivers this applies to could be hard.  We could have a
CONFIG_NO_IRQ and make them depend on it, but we still have to find that
list of boards and drivers in the first place.


Otherwise, it feels like we might need a strategy for migrating pretty
much everything if we don't want to end up in a mess.

Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-05 19:49                                 ` Nicolas Pitre
@ 2011-12-06  9:37                                   ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06  9:37 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:

[...]

> > > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > > Since there's no specific thing we can grep for (and simply due to volume)
> > > > finding all such instances may be quite a bit harder.
> > > [...]
> > > 
> > > ARgh.
> > > 
> > > My point was about current actual usage of the IRQ numbered 0 which 
> > > probably prompted the introduction of NO_IRQ in the first place.  What I 
> > > was saying is that the number of occurrences where IRQ #0 is currently 
> > > used into drivers that would get confused if 0 would mean no IRQ is 
> > > probably quite small.
> > 
> > Ah, I misunderstood -- that's a separate issue, but also an important one.
> > I guess this applies to a fair number of older boards.  One way of fixing
> > this would be to migrate those boards to use irq domains -- but those boards
> > may be sporadically maintained.
> >  
> > > But as you illustrated, there is a large number of drivers that already 
> > > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > > That is a much bigger problem to fix.
> > 
> > My concern is that as soon as we start to change this in significant
> > volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
> > is passed from one piece of code to another, there is a potential
> > interface mismatch -- there seems to be no single place where we can
> > apply a conversion and fix everything.
> 
> No need to convert everything.
> 
> First move is to make irq=0 meaning no IRQ.  That means making things 
> like:
> 
> 	if (irq < 0)
> 	if (irq >= 0)
> 
> into
> 
> 	if (irq <= 0)
> 	if (irq > 0)
> 
> And replace NO_IRQ with 0.
>
> That change shouldn't break anything, except those drivers which are 1) 
> being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
> those conditions aren't very common together.

To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially?  (i.e., we remap HW irq 0, if there is one,
to some other random number but have a 1:1 mapping for everything else).


That could make sense as an approach.

Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06  9:37                                   ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06  9:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:

[...]

> > > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ".  It looks like the assumption
> > > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > > Since there's no specific thing we can grep for (and simply due to volume)
> > > > finding all such instances may be quite a bit harder.
> > > [...]
> > > 
> > > ARgh.
> > > 
> > > My point was about current actual usage of the IRQ numbered 0 which 
> > > probably prompted the introduction of NO_IRQ in the first place.  What I 
> > > was saying is that the number of occurrences where IRQ #0 is currently 
> > > used into drivers that would get confused if 0 would mean no IRQ is 
> > > probably quite small.
> > 
> > Ah, I misunderstood -- that's a separate issue, but also an important one.
> > I guess this applies to a fair number of older boards.  One way of fixing
> > this would be to migrate those boards to use irq domains -- but those boards
> > may be sporadically maintained.
> >  
> > > But as you illustrated, there is a large number of drivers that already 
> > > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.  
> > > That is a much bigger problem to fix.
> > 
> > My concern is that as soon as we start to change this in significant
> > volume, a _lot_ of stuff is going to break.  Everywhere that an irq value
> > is passed from one piece of code to another, there is a potential
> > interface mismatch -- there seems to be no single place where we can
> > apply a conversion and fix everything.
> 
> No need to convert everything.
> 
> First move is to make irq=0 meaning no IRQ.  That means making things 
> like:
> 
> 	if (irq < 0)
> 	if (irq >= 0)
> 
> into
> 
> 	if (irq <= 0)
> 	if (irq > 0)
> 
> And replace NO_IRQ with 0.
>
> That change shouldn't break anything, except those drivers which are 1) 
> being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
> those conditions aren't very common together.

To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially?  (i.e., we remap HW irq 0, if there is one,
to some other random number but have a 1:1 mapping for everything else).


That could make sense as an approach.

Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06  9:30                                       ` Dave Martin
  (?)
@ 2011-12-06 10:34                                           ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 10:34 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA,
	Randy Dunlap, linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

> Otherwise, it feels like we might need a strategy for migrating pretty
> much everything if we don't want to end up in a mess.

You really do anyway - lots of generic driver code knows !dev->irq is a
valid test. That covers things like 8250 based UART hardware, network phy
layer code and vast amounts more.

The bugs will already be there because ARM isn't using 0, they just
aren't getting seen or aren't getting hit.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:34                                           ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 10:34 UTC (permalink / raw)
  To: Dave Martin
  Cc: Rob Herring, Anton Vorontsov, Nicolas Pitre, Stephen Rothwell,
	Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
	Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
	linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Jonas Bonn, Michal Simek, Grant Likely

> Otherwise, it feels like we might need a strategy for migrating pretty
> much everything if we don't want to end up in a mess.

You really do anyway - lots of generic driver code knows !dev->irq is a
valid test. That covers things like 8250 based UART hardware, network phy
layer code and vast amounts more.

The bugs will already be there because ARM isn't using 0, they just
aren't getting seen or aren't getting hit.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:34                                           ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 10:34 UTC (permalink / raw)
  To: linux-arm-kernel

> Otherwise, it feels like we might need a strategy for migrating pretty
> much everything if we don't want to end up in a mess.

You really do anyway - lots of generic driver code knows !dev->irq is a
valid test. That covers things like 8250 based UART hardware, network phy
layer code and vast amounts more.

The bugs will already be there because ARM isn't using 0, they just
aren't getting seen or aren't getting hit.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06  9:37                                   ` Dave Martin
  (?)
@ 2011-12-06 10:46                                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:46 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox

On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?  (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).

Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.

We already do that with the GIC, partly because of the hardware design.
We do that on Footbridge based systems, because they may or may not have
a real ISA IRQ controller.

But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used.  Let's be crystal clear: even x86
uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
It doesn't.  It just happens that x86 never shows IRQ0 to anything but
the i8253 PIC driver.

So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
I bet that there'd be absolute fury at such a suggestion.

When x86 sorts this out, there _might_ be some more motivation to take
such comments seriously.  Until then it's more like a joke.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:46                                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:46 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?  (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).

Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.

We already do that with the GIC, partly because of the hardware design.
We do that on Footbridge based systems, because they may or may not have
a real ISA IRQ controller.

But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used.  Let's be crystal clear: even x86
uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
It doesn't.  It just happens that x86 never shows IRQ0 to anything but
the i8253 PIC driver.

So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
I bet that there'd be absolute fury at such a suggestion.

When x86 sorts this out, there _might_ be some more motivation to take
such comments seriously.  Until then it's more like a joke.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:46                                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?  (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).

Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.

We already do that with the GIC, partly because of the hardware design.
We do that on Footbridge based systems, because they may or may not have
a real ISA IRQ controller.

But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used.  Let's be crystal clear: even x86
uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
It doesn't.  It just happens that x86 never shows IRQ0 to anything but
the i8253 PIC driver.

So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
I bet that there'd be absolute fury at such a suggestion.

When x86 sorts this out, there _might_ be some more motivation to take
such comments seriously.  Until then it's more like a joke.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06  9:30                                       ` Dave Martin
  (?)
@ 2011-12-06 10:55                                           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:55 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Ingo Molnar, LKML,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Alan Cox, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
> 
> Those drivers would be pain points since they would need to understand
> both conventions.
> 
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
> which boards and drivers this applies to could be hard.  We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.

You're digging too deeply into this.

Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'.  These are the drivers which have problems because of the -1 vs
0 thing.

That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().

So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't.  We just need to make sure that we're not passing a zero IRQ
number to any driver.

On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.

So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer.  Everything else should
not pass IRQ0 outside core platform code.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:55                                           ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:55 UTC (permalink / raw)
  To: Dave Martin
  Cc: Rob Herring, Anton Vorontsov, Nicolas Pitre, Stephen Rothwell,
	Pawel Moll, devicetree-discuss, LKML, Jeff Garzik, linux-ide,
	Randy Dunlap, linux-next, linux-arm-kernel, Andrew Morton,
	Linus Torvalds, Ingo Molnar, Alan Cox, Jonas Bonn, Michal Simek,
	Grant Likely

On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
> 
> Those drivers would be pain points since they would need to understand
> both conventions.
> 
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
> which boards and drivers this applies to could be hard.  We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.

You're digging too deeply into this.

Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'.  These are the drivers which have problems because of the -1 vs
0 thing.

That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().

So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't.  We just need to make sure that we're not passing a zero IRQ
number to any driver.

On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.

So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer.  Everything else should
not pass IRQ0 outside core platform code.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 10:55                                           ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 10:55 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
> 
> Those drivers would be pain points since they would need to understand
> both conventions.
> 
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
> which boards and drivers this applies to could be hard.  We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.

You're digging too deeply into this.

Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'.  These are the drivers which have problems because of the -1 vs
0 thing.

That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().

So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't.  We just need to make sure that we're not passing a zero IRQ
number to any driver.

On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.

So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer.  Everything else should
not pass IRQ0 outside core platform code.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 10:46                                       ` Russell King - ARM Linux
  (?)
@ 2011-12-06 11:00                                         ` Geert Uytterhoeven
  -1 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-06 11:00 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
	Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
	linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
	linux-arm-kernel

On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.

It's shown in /proc/interrupts due to a "bug" in show_interrupts().
The (gmail damaged) patch below fixes this bug.

From 46f51a2d42548358868a34df00c2a4e47bbdf691 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <Geert.Uytterhoeven@eu.sony.com>
Date: Tue, 6 Dec 2011 11:55:05 +0100
Subject: [PATCH] /proc/interrupts: irq zero is invalid

As zero is an invalid irq number, show_interrupts() should not try to
print it. Just return after printing the header for i == 0.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 kernel/irq/proc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 4bd4faa..5b8bbf0 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -439,6 +439,7 @@ int show_interrupts(struct seq_file *p, void *v)
 		for_each_online_cpu(j)
 			seq_printf(p, "CPU%-8d", j);
 		seq_putc(p, '\n');
+		return 0;
 	}

 	desc = irq_to_desc(i);
-- 
1.7.0.4

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:00                                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-06 11:00 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
	Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
	linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
	linux-arm-kernel

On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.

It's shown in /proc/interrupts due to a "bug" in show_interrupts().
The (gmail damaged) patch below fixes this bug.

>From 46f51a2d42548358868a34df00c2a4e47bbdf691 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <Geert.Uytterhoeven@eu.sony.com>
Date: Tue, 6 Dec 2011 11:55:05 +0100
Subject: [PATCH] /proc/interrupts: irq zero is invalid

As zero is an invalid irq number, show_interrupts() should not try to
print it. Just return after printing the header for i == 0.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 kernel/irq/proc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 4bd4faa..5b8bbf0 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -439,6 +439,7 @@ int show_interrupts(struct seq_file *p, void *v)
 		for_each_online_cpu(j)
 			seq_printf(p, "CPU%-8d", j);
 		seq_putc(p, '\n');
+		return 0;
 	}

 	desc = irq_to_desc(i);
-- 
1.7.0.4

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:00                                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 137+ messages in thread
From: Geert Uytterhoeven @ 2011-12-06 11:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. ?Let's be crystal clear: even x86
> uses IRQ0. ?It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot. ?So please don't tell me that x86 avoids IRQ0.
> It doesn't. ?It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.

It's shown in /proc/interrupts due to a "bug" in show_interrupts().
The (gmail damaged) patch below fixes this bug.

>From 46f51a2d42548358868a34df00c2a4e47bbdf691 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <Geert.Uytterhoeven@eu.sony.com>
Date: Tue, 6 Dec 2011 11:55:05 +0100
Subject: [PATCH] /proc/interrupts: irq zero is invalid

As zero is an invalid irq number, show_interrupts() should not try to
print it. Just return after printing the header for i == 0.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 kernel/irq/proc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 4bd4faa..5b8bbf0 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -439,6 +439,7 @@ int show_interrupts(struct seq_file *p, void *v)
 		for_each_online_cpu(j)
 			seq_printf(p, "CPU%-8d", j);
 		seq_putc(p, '\n');
+		return 0;
 	}

 	desc = irq_to_desc(i);
-- 
1.7.0.4

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:00                                         ` Geert Uytterhoeven
@ 2011-12-06 11:03                                           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
	Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
	linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
	linux-arm-kernel

On Tue, Dec 06, 2011 at 12:00:12PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> > It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
> 
> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.

So we now try to hide the fact that there _is_ an interrupt called 0
on x86 systems?  Sorry, I can't that that seriously in any way.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:03                                           ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 12:00:12PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used. ?Let's be crystal clear: even x86
> > uses IRQ0. ?It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot. ?So please don't tell me that x86 avoids IRQ0.
> > It doesn't. ?It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
> 
> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.

So we now try to hide the fact that there _is_ an interrupt called 0
on x86 systems?  Sorry, I can't that that seriously in any way.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 10:46                                       ` Russell King - ARM Linux
@ 2011-12-06 11:05                                         ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:05 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

> Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.

The ISA bus space is non-discoverable so that doesn't make any sense.

> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.

x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
beyond the arch code.

> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.

Actually it would be about ten minutes work to remap it to some other
number that isn't used. It never goes via request_irq or via any core or
driver layer code however.

In the ARM case the same is going to be true. If you have IRQ 0 plumbing
that only goes internally in the arch/arm code - eg an ARM with IRQ 0
wired to something totally arch specific and non-driver then it's not
going to break and like the internals of x86 doesn't matter.

> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously.  Until then it's more like a joke.

Pity you feel that way, but if ARM wants to continue to break more and
more as we clean up NO_IRQ for everything else that's your privilege, but
don't expect any sympathy.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:05                                         ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:05 UTC (permalink / raw)
  To: linux-arm-kernel

> Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.

The ISA bus space is non-discoverable so that doesn't make any sense.

> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.

x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
beyond the arch code.

> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.

Actually it would be about ten minutes work to remap it to some other
number that isn't used. It never goes via request_irq or via any core or
driver layer code however.

In the ARM case the same is going to be true. If you have IRQ 0 plumbing
that only goes internally in the arch/arm code - eg an ARM with IRQ 0
wired to something totally arch specific and non-driver then it's not
going to break and like the internals of x86 doesn't matter.

> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously.  Until then it's more like a joke.

Pity you feel that way, but if ARM wants to continue to break more and
more as we clean up NO_IRQ for everything else that's your privilege, but
don't expect any sympathy.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:00                                         ` Geert Uytterhoeven
@ 2011-12-06 11:10                                           ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:10 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Russell King - ARM Linux, Dave Martin, Nicolas Pitre,
	Benjamin Herrenschmidt, Linus Torvalds, Anton Vorontsov,
	Stephen Rothwell, Andrew Morton, devicetree-discuss, LKML,
	linux-ide, Randy Dunlap, linux-next, Ingo Molnar, Jeff Garzik,
	Pawel Moll, linux-arm-kernel

> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.

We get API breakage then. Which is a pain of course because debug tools
and the like which think IRQ 0 is "timer ticks" are somewhat broken.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:10                                           ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:10 UTC (permalink / raw)
  To: linux-arm-kernel

> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.

We get API breakage then. Which is a pain of course because debug tools
and the like which think IRQ 0 is "timer ticks" are somewhat broken.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:05                                         ` Alan Cox
  (?)
@ 2011-12-06 11:25                                             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:25 UTC (permalink / raw)
  To: Alan Cox
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Ingo Molnar,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
> > Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> > drivers which have these numbers hard-encoded in them will see failures
> > if they're expecting standard ISA IRQ numbering.
> 
> The ISA bus space is non-discoverable so that doesn't make any sense.
> 
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> > It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
> 
> x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
> beyond the arch code.
> 
> > So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> > I bet that there'd be absolute fury at such a suggestion.
> 
> Actually it would be about ten minutes work to remap it to some other
> number that isn't used. It never goes via request_irq or via any core or
> driver layer code however.
> 
> In the ARM case the same is going to be true. If you have IRQ 0 plumbing
> that only goes internally in the arch/arm code - eg an ARM with IRQ 0
> wired to something totally arch specific and non-driver then it's not
> going to break and like the internals of x86 doesn't matter.
> 
> > When x86 sorts this out, there _might_ be some more motivation to take
> > such comments seriously.  Until then it's more like a joke.
> 
> Pity you feel that way, but if ARM wants to continue to break more and
> more as we clean up NO_IRQ for everything else that's your privilege, but
> don't expect any sympathy.

For the platforms I care about, it probably won't break.  For those which
do break, it's a matter of fixing their include/mach/irqs.h and the code
in their irqchips to convert the IRQ number to the correct bitmask for
the register.

However, I have suggested in the past that new platforms _should_ avoid
not just IRQ0 but IRQ0-15 (for a completely different reason to that of
'IRQ0 means no IRQ'.)  But such comments just get ignored, so I just
don't see the point in doing anything about this.  If people experience
breakage, so be it.  I too will have little sympathy but not for the same
reason.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:25                                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:25 UTC (permalink / raw)
  To: Alan Cox
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
> > Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> > drivers which have these numbers hard-encoded in them will see failures
> > if they're expecting standard ISA IRQ numbering.
> 
> The ISA bus space is non-discoverable so that doesn't make any sense.
> 
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> > It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
> 
> x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
> beyond the arch code.
> 
> > So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> > I bet that there'd be absolute fury at such a suggestion.
> 
> Actually it would be about ten minutes work to remap it to some other
> number that isn't used. It never goes via request_irq or via any core or
> driver layer code however.
> 
> In the ARM case the same is going to be true. If you have IRQ 0 plumbing
> that only goes internally in the arch/arm code - eg an ARM with IRQ 0
> wired to something totally arch specific and non-driver then it's not
> going to break and like the internals of x86 doesn't matter.
> 
> > When x86 sorts this out, there _might_ be some more motivation to take
> > such comments seriously.  Until then it's more like a joke.
> 
> Pity you feel that way, but if ARM wants to continue to break more and
> more as we clean up NO_IRQ for everything else that's your privilege, but
> don't expect any sympathy.

For the platforms I care about, it probably won't break.  For those which
do break, it's a matter of fixing their include/mach/irqs.h and the code
in their irqchips to convert the IRQ number to the correct bitmask for
the register.

However, I have suggested in the past that new platforms _should_ avoid
not just IRQ0 but IRQ0-15 (for a completely different reason to that of
'IRQ0 means no IRQ'.)  But such comments just get ignored, so I just
don't see the point in doing anything about this.  If people experience
breakage, so be it.  I too will have little sympathy but not for the same
reason.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:25                                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
> > Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> > drivers which have these numbers hard-encoded in them will see failures
> > if they're expecting standard ISA IRQ numbering.
> 
> The ISA bus space is non-discoverable so that doesn't make any sense.
> 
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> > It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
> 
> x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
> beyond the arch code.
> 
> > So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> > I bet that there'd be absolute fury at such a suggestion.
> 
> Actually it would be about ten minutes work to remap it to some other
> number that isn't used. It never goes via request_irq or via any core or
> driver layer code however.
> 
> In the ARM case the same is going to be true. If you have IRQ 0 plumbing
> that only goes internally in the arch/arm code - eg an ARM with IRQ 0
> wired to something totally arch specific and non-driver then it's not
> going to break and like the internals of x86 doesn't matter.
> 
> > When x86 sorts this out, there _might_ be some more motivation to take
> > such comments seriously.  Until then it's more like a joke.
> 
> Pity you feel that way, but if ARM wants to continue to break more and
> more as we clean up NO_IRQ for everything else that's your privilege, but
> don't expect any sympathy.

For the platforms I care about, it probably won't break.  For those which
do break, it's a matter of fixing their include/mach/irqs.h and the code
in their irqchips to convert the IRQ number to the correct bitmask for
the register.

However, I have suggested in the past that new platforms _should_ avoid
not just IRQ0 but IRQ0-15 (for a completely different reason to that of
'IRQ0 means no IRQ'.)  But such comments just get ignored, so I just
don't see the point in doing anything about this.  If people experience
breakage, so be it.  I too will have little sympathy but not for the same
reason.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06  6:13                                   ` Jean-Christophe PLAGNIOL-VILLARD
  (?)
@ 2011-12-06 11:34                                       ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:34 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA,
	Randy Dunlap, linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

> can we sinply introduce a macro irq_is_valid

See the 2005, 2006 and 2008 discussion.

    if (!dev->irq)

is the proper test.

The <= is just a temporary thing while ARM gets its publically visible
house in order so it can be done without breakage.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:34                                       ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:34 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss, LKML, Jeff Garzik, linux-ide,
	Randy Dunlap, linux-next, Anton Vorontsov, Andrew Morton,
	Linus Torvalds, Ingo Molnar, linux-arm-kernel

> can we sinply introduce a macro irq_is_valid

See the 2005, 2006 and 2008 discussion.

    if (!dev->irq)

is the proper test.

The <= is just a temporary thing while ARM gets its publically visible
house in order so it can be done without breakage.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:34                                       ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 11:34 UTC (permalink / raw)
  To: linux-arm-kernel

> can we sinply introduce a macro irq_is_valid

See the 2005, 2006 and 2008 discussion.

    if (!dev->irq)

is the proper test.

The <= is just a temporary thing while ARM gets its publically visible
house in order so it can be done without breakage.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 10:46                                       ` Russell King - ARM Linux
@ 2011-12-06 11:37                                         ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06 11:37 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
	linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
	Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox

On Tue, Dec 06, 2011 at 10:46:54AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> > To clarify, you're suggesting that the meanings of all other IRQ values
> > would not change initially?  (i.e., we remap HW irq 0, if there is one,
> > to some other random number but have a 1:1 mapping for everything else).
> 
> Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.
> 
> We already do that with the GIC, partly because of the hardware design.
> We do that on Footbridge based systems, because they may or may not have
> a real ISA IRQ controller.
> 
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.
> 
> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.
> 
> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously.  Until then it's more like a joke.

OK -- but the situation is breaking OF-based drivers on ARM platforms
today.

Based on what you've suggested, does the following policy sound
reasonable for resolving that deadlock?


1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
   for the no-interrupt case.  Code which receives irq numbers directly
   from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
   needs to be fixed.

2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
   0-15 to different software values.  (This could be done using irq
   domains, or not)


I'm still not sure what the correct approach is for drivers which get
irq numbers from OF indirectly -- this particularly applies to platform
and AMBA devices.

If we expect board code to start populating platform data based on 
information from the OF code, we need to fix the board not to use linux
irq 0 to describe a real HW interrupt, if it matters (as in (2)).

AMBA devices registered via of_platform_populate() already get their
irq numbers from OF.  So long as OF used to explicitly return NO_IRQ
there was no problem -- but if OF is moving to return 0 instead, we have
a potential problem for each AMBA driver which may be used by a board
which can boot without DT... if we have any scenarios where that driver
is given real irq 0.

Maybe we can fix these breakages as they occur -- I don't really know
the scale of the impact.


What are your thoughts on this?

Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:37                                         ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06 11:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 10:46:54AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> > To clarify, you're suggesting that the meanings of all other IRQ values
> > would not change initially?  (i.e., we remap HW irq 0, if there is one,
> > to some other random number but have a 1:1 mapping for everything else).
> 
> Even better.  Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.
> 
> We already do that with the GIC, partly because of the hardware design.
> We do that on Footbridge based systems, because they may or may not have
> a real ISA IRQ controller.
> 
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.  It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot.  So please don't tell me that x86 avoids IRQ0.
> It doesn't.  It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.
> 
> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.
> 
> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously.  Until then it's more like a joke.

OK -- but the situation is breaking OF-based drivers on ARM platforms
today.

Based on what you've suggested, does the following policy sound
reasonable for resolving that deadlock?


1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
   for the no-interrupt case.  Code which receives irq numbers directly
   from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
   needs to be fixed.

2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
   0-15 to different software values.  (This could be done using irq
   domains, or not)


I'm still not sure what the correct approach is for drivers which get
irq numbers from OF indirectly -- this particularly applies to platform
and AMBA devices.

If we expect board code to start populating platform data based on 
information from the OF code, we need to fix the board not to use linux
irq 0 to describe a real HW interrupt, if it matters (as in (2)).

AMBA devices registered via of_platform_populate() already get their
irq numbers from OF.  So long as OF used to explicitly return NO_IRQ
there was no problem -- but if OF is moving to return 0 instead, we have
a potential problem for each AMBA driver which may be used by a board
which can boot without DT... if we have any scenarios where that driver
is given real irq 0.

Maybe we can fix these breakages as they occur -- I don't really know
the scale of the impact.


What are your thoughts on this?

Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:37                                         ` Dave Martin
@ 2011-12-06 11:49                                           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:49 UTC (permalink / raw)
  To: Dave Martin
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
	linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
	Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox

On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
>    for the no-interrupt case.  Code which receives irq numbers directly
>    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
>    needs to be fixed.
> 
> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
>    0-15 to different software values.  (This could be done using irq
>    domains, or not)

No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
an IRQ number.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 11:49                                           ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 11:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
>    for the no-interrupt case.  Code which receives irq numbers directly
>    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
>    needs to be fixed.
> 
> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
>    0-15 to different software values.  (This could be done using irq
>    domains, or not)

No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
an IRQ number.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:25                                             ` Russell King - ARM Linux
@ 2011-12-06 12:11                                               ` Alan Cox
  -1 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 12:11 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

> However, I have suggested in the past that new platforms _should_ avoid
> not just IRQ0 but IRQ0-15 (for a completely different reason to that of
> 'IRQ0 means no IRQ'.)  But such comments just get ignored, so I just
> don't see the point in doing anything about this.  If people experience
> breakage, so be it.  I too will have little sympathy but not for the same
> reason.

The one I can think of that is capable of taking EISA/ISA cards but has
differently IRQ plumbing arrangements is PA-RISC, and they do exactly
this.

Beyond that it probably doesn't come up except in the weird world of PCI
legacy compatibility for legacy IDE and VGA vertical interrupt routing.
In those cases we fix up the PCI config space so the platform in turn can
do proper IRQ plumbing.

Alan

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 12:11                                               ` Alan Cox
  0 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2011-12-06 12:11 UTC (permalink / raw)
  To: linux-arm-kernel

> However, I have suggested in the past that new platforms _should_ avoid
> not just IRQ0 but IRQ0-15 (for a completely different reason to that of
> 'IRQ0 means no IRQ'.)  But such comments just get ignored, so I just
> don't see the point in doing anything about this.  If people experience
> breakage, so be it.  I too will have little sympathy but not for the same
> reason.

The one I can think of that is capable of taking EISA/ISA cards but has
differently IRQ plumbing arrangements is PA-RISC, and they do exactly
this.

Beyond that it probably doesn't come up except in the weird world of PCI
legacy compatibility for legacy IDE and VGA vertical interrupt routing.
In those cases we fix up the PCI config space so the platform in turn can
do proper IRQ plumbing.

Alan

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:49                                           ` Russell King - ARM Linux
@ 2011-12-06 13:25                                             ` Dave Martin
  -1 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06 13:25 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
	linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
	Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
	Alan Cox

On Tue, Dec 06, 2011 at 11:49:52AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> > 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
> >    for the no-interrupt case.  Code which receives irq numbers directly
> >    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
> >    needs to be fixed.
> > 
> > 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
> >    0-15 to different software values.  (This could be done using irq
> >    domains, or not)
> 
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.

OK, hopefully we can safely ignore that case, then.

But other than that, you're in agreement?

Cheers
---Dave

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 13:25                                             ` Dave Martin
  0 siblings, 0 replies; 137+ messages in thread
From: Dave Martin @ 2011-12-06 13:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 11:49:52AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> > 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
> >    for the no-interrupt case.  Code which receives irq numbers directly
> >    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
> >    needs to be fixed.
> > 
> > 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
> >    0-15 to different software values.  (This could be done using irq
> >    domains, or not)
> 
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.

OK, hopefully we can safely ignore that case, then.

But other than that, you're in agreement?

Cheers
---Dave

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06  9:37                                   ` Dave Martin
@ 2011-12-06 19:11                                     ` Nicolas Pitre
  -1 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-06 19:11 UTC (permalink / raw)
  To: Dave Martin
  Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Tue, 6 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
> 
> > No need to convert everything.
> > 
> > First move is to make irq=0 meaning no IRQ.  That means making things 
> > like:
> > 
> > 	if (irq < 0)
> > 	if (irq >= 0)
> > 
> > into
> > 
> > 	if (irq <= 0)
> > 	if (irq > 0)
> > 
> > And replace NO_IRQ with 0.
> >
> > That change shouldn't break anything, except those drivers which are 1) 
> > being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
> > those conditions aren't very common together.
> 
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?

Initially, or even ever.

> (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).

Exact.

> That could make sense as an approach.

You might notice that a true IRQ #0 passed to generic drivers is not 
really frequent.


Nicolas

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 19:11                                     ` Nicolas Pitre
  0 siblings, 0 replies; 137+ messages in thread
From: Nicolas Pitre @ 2011-12-06 19:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 6 Dec 2011, Dave Martin wrote:

> On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
> 
> > No need to convert everything.
> > 
> > First move is to make irq=0 meaning no IRQ.  That means making things 
> > like:
> > 
> > 	if (irq < 0)
> > 	if (irq >= 0)
> > 
> > into
> > 
> > 	if (irq <= 0)
> > 	if (irq > 0)
> > 
> > And replace NO_IRQ with 0.
> >
> > That change shouldn't break anything, except those drivers which are 1) 
> > being passed an actual IRQ #0 and 2) testing for no IRQ.  I suspect that 
> > those conditions aren't very common together.
> 
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?

Initially, or even ever.

> (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).

Exact.

> That could make sense as an approach.

You might notice that a true IRQ #0 passed to generic drivers is not 
really frequent.


Nicolas

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 10:46                                       ` Russell King - ARM Linux
@ 2011-12-06 19:20                                         ` Linus Torvalds
  -1 siblings, 0 replies; 137+ messages in thread
From: Linus Torvalds @ 2011-12-06 19:20 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used.  Let's be crystal clear: even x86
> uses IRQ0.

Not for any device driver, though.

It's used entirely internally, and it doesn't even use
"request_irq()". It uses the magic internal "setup_irq()" and never
*ever* exposes irq0 as anything that a driver can see.

That's what matters. You can use irq0 in ARM land all you like, AS
LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
ever uses that absolutely *idiotic* NO_IRQ crap.

In fact, you may be *forced* to use what is "physically" irq0 - it's
just that you should never expose it as such to drivers. And x86
doesn't.

So Russell, if you think this has anything to do with NO_IRQ, and how
x86 isn't doing things right, you're wrong. It's just like the
internal exception thing, or the magical "cascade interrupt", or the
"x87 exception mapped through the PIC". They are magic hidden
interrupts that are set up in one place (well, one place *each*), and
are never exposed anywhere else.

The problem with NO_IRQ is that stupid "we expose our mind-numbingly
stupid interfaces across the whole kernel".

x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

                Linus

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 19:20                                         ` Linus Torvalds
  0 siblings, 0 replies; 137+ messages in thread
From: Linus Torvalds @ 2011-12-06 19:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. ?Let's be crystal clear: even x86
> uses IRQ0.

Not for any device driver, though.

It's used entirely internally, and it doesn't even use
"request_irq()". It uses the magic internal "setup_irq()" and never
*ever* exposes irq0 as anything that a driver can see.

That's what matters. You can use irq0 in ARM land all you like, AS
LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
ever uses that absolutely *idiotic* NO_IRQ crap.

In fact, you may be *forced* to use what is "physically" irq0 - it's
just that you should never expose it as such to drivers. And x86
doesn't.

So Russell, if you think this has anything to do with NO_IRQ, and how
x86 isn't doing things right, you're wrong. It's just like the
internal exception thing, or the magical "cascade interrupt", or the
"x87 exception mapped through the PIC". They are magic hidden
interrupts that are set up in one place (well, one place *each*), and
are never exposed anywhere else.

The problem with NO_IRQ is that stupid "we expose our mind-numbingly
stupid interfaces across the whole kernel".

x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

                Linus

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 11:49                                           ` Russell King - ARM Linux
@ 2011-12-06 19:56                                             ` Rob Herring
  -1 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-06 19:56 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, Stephen Rothwell, Pawel Moll,
	Benjamin Herrenschmidt, devicetree-discuss, Ingo Molnar, LKML,
	linux-ide, Randy Dunlap, linux-next, Alan Cox, Anton Vorontsov,
	Andrew Morton, Linus Torvalds, Jeff Garzik, linux-arm-kernel

On 12/06/2011 05:49 AM, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
>> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
>>    for the no-interrupt case.  Code which receives irq numbers directly
>>    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
>>    needs to be fixed.
>>
>> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
>>    0-15 to different software values.  (This could be done using irq
>>    domains, or not)
> 
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.

The watchdog on VersatileAB is on Linux IRQ0. This is easily fixed with
VIC irqdomain patches which are queued up.

Rob

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 19:56                                             ` Rob Herring
  0 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-06 19:56 UTC (permalink / raw)
  To: linux-arm-kernel

On 12/06/2011 05:49 AM, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
>> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
>>    for the no-interrupt case.  Code which receives irq numbers directly
>>    from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
>>    needs to be fixed.
>>
>> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
>>    0-15 to different software values.  (This could be done using irq
>>    domains, or not)
> 
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.

The watchdog on VersatileAB is on Linux IRQ0. This is easily fixed with
VIC irqdomain patches which are queued up.

Rob

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 19:20                                         ` Linus Torvalds
@ 2011-12-06 20:00                                           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 20:00 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
	Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel

On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> Not for any device driver, though.
> 
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
> 
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
> 
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
> 
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
> 
> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
> 
> x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

Remember you said that I shouldn't take things personally?  Well,
this is one issue I really don't care about.  I don't think any
platform I _actually_ have will be impacted by any change in this
area.  Other platform maintainers may have their own issues but
that's not _my_ problem.

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 20:00                                           ` Russell King - ARM Linux
  0 siblings, 0 replies; 137+ messages in thread
From: Russell King - ARM Linux @ 2011-12-06 20:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> Not for any device driver, though.
> 
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
> 
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
> 
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
> 
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
> 
> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
> 
> x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

Remember you said that I shouldn't take things personally?  Well,
this is one issue I really don't care about.  I don't think any
platform I _actually_ have will be impacted by any change in this
area.  Other platform maintainers may have their own issues but
that's not _my_ problem.

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
  2011-12-06 19:20                                         ` Linus Torvalds
  (?)
@ 2011-12-06 20:59                                             ` Uwe Kleine-König
  -1 siblings, 0 replies; 137+ messages in thread
From: Uwe Kleine-König @ 2011-12-06 20:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
	Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA,
	Randy Dunlap, linux-next-u79uwXL29TY76Z2rM5mHXA, Alan Cox,
	Anton Vorontsov, Andrew Morton, Jeff Garzik,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hello Linus,

On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> >
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.
> 
> Not for any device driver, though.
> 
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
> 
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
> 
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
> 
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
Well there is try_misrouted_irq in kernel/irq/spurious.c that assumes
irq0 to be something that it never is on ARM (and maybe all other
platforms apart from x86). So at least it's not internal to a single
(x86 specific) place.

I tried to patch that two years ago, but that only ended in people
saying "don't use irq0". I don't know if try_misrouted_irq sees hardware
irqs, but if it does it's a bug even on archs != X86 that use virtual
irqs.

(Note that this doesn't oppose to your statement that using NO_IRQ is
crap.)

> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
> 
> x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 20:59                                             ` Uwe Kleine-König
  0 siblings, 0 replies; 137+ messages in thread
From: Uwe Kleine-König @ 2011-12-06 20:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Russell King - ARM Linux, Nicolas Pitre, Stephen Rothwell,
	Dave Martin, Pawel Moll, Benjamin Herrenschmidt,
	devicetree-discuss, LKML, Jeff Garzik, linux-ide, Randy Dunlap,
	linux-next, linux-arm-kernel, Anton Vorontsov, Andrew Morton,
	Ingo Molnar, Alan Cox

Hello Linus,

On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used.  Let's be crystal clear: even x86
> > uses IRQ0.
> 
> Not for any device driver, though.
> 
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
> 
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
> 
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
> 
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
Well there is try_misrouted_irq in kernel/irq/spurious.c that assumes
irq0 to be something that it never is on ARM (and maybe all other
platforms apart from x86). So at least it's not internal to a single
(x86 specific) place.

I tried to patch that two years ago, but that only ended in people
saying "don't use irq0". I don't know if try_misrouted_irq sees hardware
irqs, but if it does it's a bug even on archs != X86 that use virtual
irqs.

(Note that this doesn't oppose to your statement that using NO_IRQ is
crap.)

> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
> 
> x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
@ 2011-12-06 20:59                                             ` Uwe Kleine-König
  0 siblings, 0 replies; 137+ messages in thread
From: Uwe Kleine-König @ 2011-12-06 20:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Linus,

On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used. ?Let's be crystal clear: even x86
> > uses IRQ0.
> 
> Not for any device driver, though.
> 
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
> 
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
> 
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
> 
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
Well there is try_misrouted_irq in kernel/irq/spurious.c that assumes
irq0 to be something that it never is on ARM (and maybe all other
platforms apart from x86). So at least it's not internal to a single
(x86 specific) place.

I tried to patch that two years ago, but that only ended in people
saying "don't use irq0". I don't know if try_misrouted_irq sees hardware
irqs, but if it does it's a bug even on archs != X86 that use virtual
irqs.

(Note that this doesn't oppose to your statement that using NO_IRQ is
crap.)

> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
> 
> x86 never did that.  ARM still does. x86 doesn't have to fix anything. ARM does.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

* Re: [PATCH 1/2] of/irq: Get rid of NO_IRQ usage
  2011-11-10 15:25         ` [PATCH 1/2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
@ 2011-12-06 21:22           ` Rob Herring
  2011-12-06 21:25             ` Linus Torvalds
  0 siblings, 1 reply; 137+ messages in thread
From: Rob Herring @ 2011-12-06 21:22 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Stephen Rothwell,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Andrew Morton, Linus Torvalds, Alan Cox

On 11/10/2011 09:25 AM, Anton Vorontsov wrote:
> PPC32/64 defines NO_IRQ to zero, so no problems expected.
> ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
> which returns correct ('0') value in 'no irq' case. So everything
> should be fine.
> 
> Other arches might break if some of their OF drivers rely on NO_IRQ
> being not 0. If so, the drivers must be fixed, finally.
> 
> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> ---
>  drivers/of/irq.c |   30 ++++++++++++++++++------------
>  1 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 6d3dd39..2dd4937 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -26,11 +26,6 @@
>  #include <linux/string.h>
>  #include <linux/slab.h>
>  
> -/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
> -#ifndef NO_IRQ
> -#define NO_IRQ 0
> -#endif
> -
>  /**
>   * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
>   * @device: Device node of the device whose interrupt is to be mapped
> @@ -42,12 +37,23 @@
>  unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
>  {
>  	struct of_irq oirq;
> +	int ret = 0;
>  
>  	if (of_irq_map_one(dev, index, &oirq))
> -		return NO_IRQ;
> -
> -	return irq_create_of_mapping(oirq.controller, oirq.specifier,
> -				     oirq.size);
> +		goto no_irq;
> +
> +	ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
> +				    oirq.size);
> +no_irq:
> +#ifdef NO_IRQ
> +#if NO_IRQ != 0
> +	if (ret == NO_IRQ)
> +		pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
> +			"NO_IRQ, but we return 0. If anything breaks, driver "
> +			"have to be fixed.\n");
> +#endif
> +#endif

This warning code is really ugly. Can we just drop it? In my searching
of in kernel dts files, there's only 1 instance I have found (Versatile
AB watchdog) that would hit this.

If not, you don't need to handle irq_create_of_mapping return as that is
already always 0 for no irq or error.

Otherwise, looks fine.

Rob

> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
>  
> @@ -345,7 +351,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
>  
>  	/* Only dereference the resource if both the
>  	 * resource and the irq are valid. */
> -	if (r && irq != NO_IRQ) {
> +	if (r && irq) {
>  		r->start = r->end = irq;
>  		r->flags = IORESOURCE_IRQ;
>  		r->name = dev->full_name;
> @@ -363,7 +369,7 @@ int of_irq_count(struct device_node *dev)
>  {
>  	int nr = 0;
>  
> -	while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
> +	while (of_irq_to_resource(dev, nr, NULL))
>  		nr++;
>  
>  	return nr;
> @@ -383,7 +389,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>  	int i;
>  
>  	for (i = 0; i < nr_irqs; i++, res++)
> -		if (of_irq_to_resource(dev, i, res) == NO_IRQ)
> +		if (!of_irq_to_resource(dev, i, res))
>  			break;
>  
>  	return i;


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

* Re: [PATCH 1/2] of/irq: Get rid of NO_IRQ usage
  2011-12-06 21:22           ` Rob Herring
@ 2011-12-06 21:25             ` Linus Torvalds
  2011-12-06 23:16               ` [PATCH v3] " Anton Vorontsov
  0 siblings, 1 reply; 137+ messages in thread
From: Linus Torvalds @ 2011-12-06 21:25 UTC (permalink / raw)
  To: Rob Herring
  Cc: Anton Vorontsov, Ingo Molnar, Jeff Garzik, Grant Likely,
	Stephen Rothwell, devicetree-discuss, LKML, linux-ide,
	Randy Dunlap, linux-next, Andrew Morton, Alan Cox

On Tue, Dec 6, 2011 at 1:22 PM, Rob Herring <robherring2@gmail.com> wrote:
>
> This warning code is really ugly. Can we just drop it? In my searching
> of in kernel dts files, there's only 1 instance I have found (Versatile
> AB watchdog) that would hit this.

I do agree. Especially since we never got any input on whether it works or not.

> If not, you don't need to handle irq_create_of_mapping return as that is
> already always 0 for no irq or error.

Yeah, I'd like to just remove NO_IRQ from the OF paths. Afaik, it
hasn't worked as NO_IRQ before anyway, so even if the rest of the
drivers end up continuing using NO_IRQ, the OF-enabled ones on ARM
should just stop. There can't be many of those yet.

                          Linus

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

* [PATCH v3] of/irq: Get rid of NO_IRQ usage
  2011-12-06 21:25             ` Linus Torvalds
@ 2011-12-06 23:16               ` Anton Vorontsov
  2011-12-07  3:51                 ` Rob Herring
       [not found]                 ` <20111206231626.GA31683-wnGakbxT3iijyJ0x5qLZdcN33GVbZNy3@public.gmane.org>
  0 siblings, 2 replies; 137+ messages in thread
From: Anton Vorontsov @ 2011-12-06 23:16 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rob Herring, Ingo Molnar, Jeff Garzik, Grant Likely,
	Stephen Rothwell, devicetree-discuss, LKML, linux-ide,
	Randy Dunlap, linux-next, Andrew Morton, Alan Cox

PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.

Other arches might break if some of their OF drivers rely on NO_IRQ
being not 0. If so, the drivers must be fixed, finally.

Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
---

On Tue, Dec 06, 2011 at 01:25:07PM -0800, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 1:22 PM, Rob Herring <robherring2@gmail.com> wrote:
> >
> > This warning code is really ugly. Can we just drop it? In my searching
> > of in kernel dts files, there's only 1 instance I have found (Versatile
> > AB watchdog) that would hit this.
> 
> I do agree. Especially since we never got any input on whether it works or not.
> 
> > If not, you don't need to handle irq_create_of_mapping return as that is
> > already always 0 for no irq or error.
> 
> Yeah, I'd like to just remove NO_IRQ from the OF paths. Afaik, it
> hasn't worked as NO_IRQ before anyway, so even if the rest of the
> drivers end up continuing using NO_IRQ, the OF-enabled ones on ARM
> should just stop. There can't be many of those yet.

Okay, here it goes.

 drivers/of/irq.c |   13 ++++---------
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 791270b..ac6da0d 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -26,11 +26,6 @@
 #include <linux/string.h>
 #include <linux/slab.h>
 
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
 /**
  * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
  * @device: Device node of the device whose interrupt is to be mapped
@@ -44,7 +39,7 @@ unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
 	struct of_irq oirq;
 
 	if (of_irq_map_one(dev, index, &oirq))
-		return NO_IRQ;
+		return 0;
 
 	return irq_create_of_mapping(oirq.controller, oirq.specifier,
 				     oirq.size);
@@ -345,7 +340,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 
 	/* Only dereference the resource if both the
 	 * resource and the irq are valid. */
-	if (r && irq != NO_IRQ) {
+	if (r && irq) {
 		r->start = r->end = irq;
 		r->flags = IORESOURCE_IRQ;
 		r->name = dev->full_name;
@@ -363,7 +358,7 @@ int of_irq_count(struct device_node *dev)
 {
 	int nr = 0;
 
-	while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
+	while (of_irq_to_resource(dev, nr, NULL))
 		nr++;
 
 	return nr;
@@ -383,7 +378,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 	int i;
 
 	for (i = 0; i < nr_irqs; i++, res++)
-		if (of_irq_to_resource(dev, i, res) == NO_IRQ)
+		if (!of_irq_to_resource(dev, i, res))
 			break;
 
 	return i;
-- 
1.7.5.3

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

* Re: [PATCH v3] of/irq: Get rid of NO_IRQ usage
  2011-12-06 23:16               ` [PATCH v3] " Anton Vorontsov
@ 2011-12-07  3:51                 ` Rob Herring
       [not found]                   ` <1323268911-6104-1-git-send-email-robherring2@gmail.com>
       [not found]                 ` <20111206231626.GA31683-wnGakbxT3iijyJ0x5qLZdcN33GVbZNy3@public.gmane.org>
  1 sibling, 1 reply; 137+ messages in thread
From: Rob Herring @ 2011-12-07  3:51 UTC (permalink / raw)
  To: Anton Vorontsov, Linus Torvalds
  Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Stephen Rothwell,
	devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
	Andrew Morton, Alan Cox, Michal Simek, John Linn

On 12/06/2011 05:16 PM, Anton Vorontsov wrote:
> PPC32/64 defines NO_IRQ to zero, so no problems expected.
> ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
> which returns correct ('0') value in 'no irq' case. So everything
> should be fine.
> 
> Other arches might break if some of their OF drivers rely on NO_IRQ
> being not 0. If so, the drivers must be fixed, finally.
> 
> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
> ---

Looks fine, but I think we have to wait for microblaze to be fixed or
some confirmation from microblaze folks that no driver would use IRQ0.
There was a patch posted by Grant in back in Feb, but nothing has
happened since:

http://article.gmane.org/gmane.linux.uclinux.microblaze/10121/

Rob

> 
> On Tue, Dec 06, 2011 at 01:25:07PM -0800, Linus Torvalds wrote:
>> On Tue, Dec 6, 2011 at 1:22 PM, Rob Herring <robherring2@gmail.com> wrote:
>>>
>>> This warning code is really ugly. Can we just drop it? In my searching
>>> of in kernel dts files, there's only 1 instance I have found (Versatile
>>> AB watchdog) that would hit this.
>>
>> I do agree. Especially since we never got any input on whether it works or not.
>>
>>> If not, you don't need to handle irq_create_of_mapping return as that is
>>> already always 0 for no irq or error.
>>
>> Yeah, I'd like to just remove NO_IRQ from the OF paths. Afaik, it
>> hasn't worked as NO_IRQ before anyway, so even if the rest of the
>> drivers end up continuing using NO_IRQ, the OF-enabled ones on ARM
>> should just stop. There can't be many of those yet.
> 
> Okay, here it goes.
> 
>  drivers/of/irq.c |   13 ++++---------
>  1 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 791270b..ac6da0d 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -26,11 +26,6 @@
>  #include <linux/string.h>
>  #include <linux/slab.h>
>  
> -/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
> -#ifndef NO_IRQ
> -#define NO_IRQ 0
> -#endif
> -
>  /**
>   * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
>   * @device: Device node of the device whose interrupt is to be mapped
> @@ -44,7 +39,7 @@ unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
>  	struct of_irq oirq;
>  
>  	if (of_irq_map_one(dev, index, &oirq))
> -		return NO_IRQ;
> +		return 0;
>  
>  	return irq_create_of_mapping(oirq.controller, oirq.specifier,
>  				     oirq.size);
> @@ -345,7 +340,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
>  
>  	/* Only dereference the resource if both the
>  	 * resource and the irq are valid. */
> -	if (r && irq != NO_IRQ) {
> +	if (r && irq) {
>  		r->start = r->end = irq;
>  		r->flags = IORESOURCE_IRQ;
>  		r->name = dev->full_name;
> @@ -363,7 +358,7 @@ int of_irq_count(struct device_node *dev)
>  {
>  	int nr = 0;
>  
> -	while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
> +	while (of_irq_to_resource(dev, nr, NULL))
>  		nr++;
>  
>  	return nr;
> @@ -383,7 +378,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>  	int i;
>  
>  	for (i = 0; i < nr_irqs; i++, res++)
> -		if (of_irq_to_resource(dev, i, res) == NO_IRQ)
> +		if (!of_irq_to_resource(dev, i, res))
>  			break;
>  
>  	return i;


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

* Re: [PATCH v3] of/irq: Get rid of NO_IRQ usage
  2011-12-06 23:16               ` [PATCH v3] " Anton Vorontsov
@ 2011-12-07  9:52                     ` Wolfram Sang
       [not found]                 ` <20111206231626.GA31683-wnGakbxT3iijyJ0x5qLZdcN33GVbZNy3@public.gmane.org>
  1 sibling, 0 replies; 137+ messages in thread
From: Wolfram Sang @ 2011-12-07  9:52 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Stephen Rothwell, Andrew Morton,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML,
	linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Linus Torvalds,
	Jeff Garzik, Alan Cox


[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]

On Wed, Dec 07, 2011 at 03:16:26AM +0400, Anton Vorontsov wrote:
> PPC32/64 defines NO_IRQ to zero, so no problems expected.
> ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
> which returns correct ('0') value in 'no irq' case. So everything
> should be fine.
> 
> Other arches might break if some of their OF drivers rely on NO_IRQ
> being not 0. If so, the drivers must be fixed, finally.
> 
> Signed-off-by: Anton Vorontsov <anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---

/me likes NO_IRQ removal very much

Acked-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

* Re: [PATCH v3] of/irq: Get rid of NO_IRQ usage
@ 2011-12-07  9:52                     ` Wolfram Sang
  0 siblings, 0 replies; 137+ messages in thread
From: Wolfram Sang @ 2011-12-07  9:52 UTC (permalink / raw)
  To: Anton Vorontsov
  Cc: Linus Torvalds, Rob Herring, Ingo Molnar, Jeff Garzik,
	Grant Likely, Stephen Rothwell, devicetree-discuss, LKML,
	linux-ide, Randy Dunlap, linux-next, Andrew Morton, Alan Cox

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

On Wed, Dec 07, 2011 at 03:16:26AM +0400, Anton Vorontsov wrote:
> PPC32/64 defines NO_IRQ to zero, so no problems expected.
> ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
> which returns correct ('0') value in 'no irq' case. So everything
> should be fine.
> 
> Other arches might break if some of their OF drivers rely on NO_IRQ
> being not 0. If so, the drivers must be fixed, finally.
> 
> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
> ---

/me likes NO_IRQ removal very much

Acked-by: Wolfram Sang <w.sang@pengutronix.de>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
@ 2011-12-07 15:02                       ` Grant Likely
  0 siblings, 0 replies; 137+ messages in thread
From: Grant Likely @ 2011-12-07 15:02 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michal Simek, John Linn, Linus Torvalds, Rob Herring,
	Ingo Molnar, Jeff Garzik, Stephen Rothwell, devicetree-discuss,
	LKML, Randy Dunlap, Andrew Morton, Alan Cox, Anton Vorontsov

On Wed, Dec 7, 2011 at 7:41 AM, Rob Herring <robherring2@gmail.com> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> As has been discussed many times[1], Using NO_IRQ set to anything other
> than 0 is bug waiting to happen since many drivers follow the pattern
> "if (!irq)" for testing whether or not an irq has been set.
>
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.
>
> At this point, Microblaze interrupt handling only supports only one
> instance of one kind of interrupt controller (xilinx_intc).  This change
> shouldn't affect any architecture code outside of the interrupt
> controller driver and the irq_of mapping.
>
> Updated to 3.2 and to use irq_data.hwirq by Rob Herring.
>
> Completely untested.
>
> [1] http://lkml.org/lkml/2005/11/21/221
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>

Brilliant!  Thanks for updating this Rob.

g.

> ---
>
> The main complaint with the prior version was Michal's complaint about the
> +1 / -1 conversion in every function. This is now solved with the use of
> irq_data.hwirq to store the h/w irq numbers.
>
> I also fixed some errors around nr_irq.
>
> Rob
>
>  arch/microblaze/include/asm/irq.h |    4 ++--
>  arch/microblaze/kernel/intc.c     |   18 ++++++++++--------
>  arch/microblaze/kernel/irq.c      |   10 ++++++----
>  3 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index cc54187..b07c179 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -9,7 +9,7 @@
>  #ifndef _ASM_MICROBLAZE_IRQ_H
>  #define _ASM_MICROBLAZE_IRQ_H
>
> -#define NR_IRQS 32
> +#define NR_IRQS (32 + 1)       /* Add 1 to skip over IRQ0 */
>  #include <asm-generic/irq.h>
>
>  /* This type is the placeholder for a hardware interrupt number. It has to
> @@ -20,7 +20,7 @@ typedef unsigned long irq_hw_number_t;
>
>  extern unsigned int nr_irq;
>
> -#define NO_IRQ (-1)
> +#define NO_IRQ 0
>
>  struct pt_regs;
>  extern void do_IRQ(struct pt_regs *regs);
> diff --git a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
> index eb41441..ed65aac 100644
> --- a/arch/microblaze/kernel/intc.c
> +++ b/arch/microblaze/kernel/intc.c
> @@ -42,7 +42,7 @@ unsigned int nr_irq;
>
>  static void intc_enable_or_unmask(struct irq_data *d)
>  {
> -       unsigned long mask = 1 << d->irq;
> +       unsigned long mask = 1 << d->hwirq;
>        pr_debug("enable_or_unmask: %d\n", d->irq);
>        out_be32(INTC_BASE + SIE, mask);
>
> @@ -57,18 +57,18 @@ static void intc_enable_or_unmask(struct irq_data *d)
>  static void intc_disable_or_mask(struct irq_data *d)
>  {
>        pr_debug("disable: %d\n", d->irq);
> -       out_be32(INTC_BASE + CIE, 1 << d->irq);
> +       out_be32(INTC_BASE + CIE, 1 << d->hwirq);
>  }
>
>  static void intc_ack(struct irq_data *d)
>  {
>        pr_debug("ack: %d\n", d->irq);
> -       out_be32(INTC_BASE + IAR, 1 << d->irq);
> +       out_be32(INTC_BASE + IAR, 1 << d->hwirq);
>  }
>
>  static void intc_mask_ack(struct irq_data *d)
>  {
> -       unsigned long mask = 1 << d->irq;
> +       unsigned long mask = 1 << d->hwirq;
>        pr_debug("disable_and_ack: %d\n", d->irq);
>        out_be32(INTC_BASE + CIE, mask);
>        out_be32(INTC_BASE + IAR, mask);
> @@ -90,8 +90,11 @@ unsigned int get_irq(struct pt_regs *regs)
>         * NOTE: This function is the one that needs to be improved in
>         * order to handle multiple interrupt controllers. It currently
>         * is hardcoded to check for interrupts only on the first INTC.
> +        *
> +        * Linux IRQ# is currently offset by one to map to the hardware
> +        * irq number.  So hardware IRQ0 maps to Linux irq 1.
>         */
> -       irq = in_be32(INTC_BASE + IVR);
> +       irq = in_be32(INTC_BASE + IVR) + 1;
>        pr_debug("get_irq: %d\n", irq);
>
>        return irq;
> @@ -134,8 +137,6 @@ void __init init_IRQ(void)
>        intr_type =
>                be32_to_cpup(of_get_property(intc,
>                                                "xlnx,kind-of-intr", NULL));
> -       if (intr_type > (u32)((1ULL << nr_irq) - 1))
> -               printk(KERN_INFO " ERROR: Mismatch in kind-of-intr param\n");
>
>  #ifdef CONFIG_SELFMOD_INTC
>        selfmod_function((int *) arr_func, intc_baseaddr);
> @@ -155,7 +156,7 @@ void __init init_IRQ(void)
>        /* Turn on the Master Enable. */
>        out_be32(intc_baseaddr + MER, MER_HIE | MER_ME);
>
> -       for (i = 0; i < nr_irq; ++i) {
> +       for (i = 1; i < nr_irq; ++i) {
>                if (intr_type & (0x00000001 << i)) {
>                        irq_set_chip_and_handler_name(i, &intc_dev,
>                                handle_edge_irq, "edge");
> @@ -165,5 +166,6 @@ void __init init_IRQ(void)
>                                handle_level_irq, "level");
>                        irq_set_status_flags(i, IRQ_LEVEL);
>                }
> +               irq_get_irq_data(i)->hwirq = i - 1;
>        }
>  }
> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
> index e5d63a8..ac1b463 100644
> --- a/arch/microblaze/kernel/irq.c
> +++ b/arch/microblaze/kernel/irq.c
> @@ -33,11 +33,11 @@ void __irq_entry do_IRQ(struct pt_regs *regs)
>        irq_enter();
>        irq = get_irq(regs);
>  next_irq:
> -       BUG_ON(irq == -1U);
> +       BUG_ON(!irq);
>        generic_handle_irq(irq);
>
>        irq = get_irq(regs);
> -       if (irq != -1U) {
> +       if (irq) {
>                pr_debug("next irq: %d\n", irq);
>                ++concurrent_irq;
>                goto next_irq;
> @@ -52,13 +52,15 @@ next_irq:
>   intc without any cascades or any connection that's why mapping is 1:1 */
>  unsigned int irq_create_mapping(struct irq_host *host, irq_hw_number_t hwirq)
>  {
> -       return hwirq;
> +       return hwirq + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_mapping);
>
>  unsigned int irq_create_of_mapping(struct device_node *controller,
>                                   const u32 *intspec, unsigned int intsize)
>  {
> -       return intspec[0];
> +       /* Hardware irq is mapped to Linux IRQ# by a 1 offset. Linux irq
> +        * 0 means no IRQ. */
> +       return intspec[0] + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> --
> 1.7.5.4
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
@ 2011-12-07 15:02                       ` Grant Likely
  0 siblings, 0 replies; 137+ messages in thread
From: Grant Likely @ 2011-12-07 15:02 UTC (permalink / raw)
  To: Rob Herring
  Cc: Stephen Rothwell, Andrew Morton,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Rob Herring,
	Jeff Garzik, Anton Vorontsov, Randy Dunlap, Ingo Molnar,
	Linus Torvalds, Alan Cox

On Wed, Dec 7, 2011 at 7:41 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>
> As has been discussed many times[1], Using NO_IRQ set to anything other
> than 0 is bug waiting to happen since many drivers follow the pattern
> "if (!irq)" for testing whether or not an irq has been set.
>
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.
>
> At this point, Microblaze interrupt handling only supports only one
> instance of one kind of interrupt controller (xilinx_intc).  This change
> shouldn't affect any architecture code outside of the interrupt
> controller driver and the irq_of mapping.
>
> Updated to 3.2 and to use irq_data.hwirq by Rob Herring.
>
> Completely untested.
>
> [1] http://lkml.org/lkml/2005/11/21/221
>
> Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

Brilliant!  Thanks for updating this Rob.

g.

> ---
>
> The main complaint with the prior version was Michal's complaint about the
> +1 / -1 conversion in every function. This is now solved with the use of
> irq_data.hwirq to store the h/w irq numbers.
>
> I also fixed some errors around nr_irq.
>
> Rob
>
>  arch/microblaze/include/asm/irq.h |    4 ++--
>  arch/microblaze/kernel/intc.c     |   18 ++++++++++--------
>  arch/microblaze/kernel/irq.c      |   10 ++++++----
>  3 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index cc54187..b07c179 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -9,7 +9,7 @@
>  #ifndef _ASM_MICROBLAZE_IRQ_H
>  #define _ASM_MICROBLAZE_IRQ_H
>
> -#define NR_IRQS 32
> +#define NR_IRQS (32 + 1)       /* Add 1 to skip over IRQ0 */
>  #include <asm-generic/irq.h>
>
>  /* This type is the placeholder for a hardware interrupt number. It has to
> @@ -20,7 +20,7 @@ typedef unsigned long irq_hw_number_t;
>
>  extern unsigned int nr_irq;
>
> -#define NO_IRQ (-1)
> +#define NO_IRQ 0
>
>  struct pt_regs;
>  extern void do_IRQ(struct pt_regs *regs);
> diff --git a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
> index eb41441..ed65aac 100644
> --- a/arch/microblaze/kernel/intc.c
> +++ b/arch/microblaze/kernel/intc.c
> @@ -42,7 +42,7 @@ unsigned int nr_irq;
>
>  static void intc_enable_or_unmask(struct irq_data *d)
>  {
> -       unsigned long mask = 1 << d->irq;
> +       unsigned long mask = 1 << d->hwirq;
>        pr_debug("enable_or_unmask: %d\n", d->irq);
>        out_be32(INTC_BASE + SIE, mask);
>
> @@ -57,18 +57,18 @@ static void intc_enable_or_unmask(struct irq_data *d)
>  static void intc_disable_or_mask(struct irq_data *d)
>  {
>        pr_debug("disable: %d\n", d->irq);
> -       out_be32(INTC_BASE + CIE, 1 << d->irq);
> +       out_be32(INTC_BASE + CIE, 1 << d->hwirq);
>  }
>
>  static void intc_ack(struct irq_data *d)
>  {
>        pr_debug("ack: %d\n", d->irq);
> -       out_be32(INTC_BASE + IAR, 1 << d->irq);
> +       out_be32(INTC_BASE + IAR, 1 << d->hwirq);
>  }
>
>  static void intc_mask_ack(struct irq_data *d)
>  {
> -       unsigned long mask = 1 << d->irq;
> +       unsigned long mask = 1 << d->hwirq;
>        pr_debug("disable_and_ack: %d\n", d->irq);
>        out_be32(INTC_BASE + CIE, mask);
>        out_be32(INTC_BASE + IAR, mask);
> @@ -90,8 +90,11 @@ unsigned int get_irq(struct pt_regs *regs)
>         * NOTE: This function is the one that needs to be improved in
>         * order to handle multiple interrupt controllers. It currently
>         * is hardcoded to check for interrupts only on the first INTC.
> +        *
> +        * Linux IRQ# is currently offset by one to map to the hardware
> +        * irq number.  So hardware IRQ0 maps to Linux irq 1.
>         */
> -       irq = in_be32(INTC_BASE + IVR);
> +       irq = in_be32(INTC_BASE + IVR) + 1;
>        pr_debug("get_irq: %d\n", irq);
>
>        return irq;
> @@ -134,8 +137,6 @@ void __init init_IRQ(void)
>        intr_type =
>                be32_to_cpup(of_get_property(intc,
>                                                "xlnx,kind-of-intr", NULL));
> -       if (intr_type > (u32)((1ULL << nr_irq) - 1))
> -               printk(KERN_INFO " ERROR: Mismatch in kind-of-intr param\n");
>
>  #ifdef CONFIG_SELFMOD_INTC
>        selfmod_function((int *) arr_func, intc_baseaddr);
> @@ -155,7 +156,7 @@ void __init init_IRQ(void)
>        /* Turn on the Master Enable. */
>        out_be32(intc_baseaddr + MER, MER_HIE | MER_ME);
>
> -       for (i = 0; i < nr_irq; ++i) {
> +       for (i = 1; i < nr_irq; ++i) {
>                if (intr_type & (0x00000001 << i)) {
>                        irq_set_chip_and_handler_name(i, &intc_dev,
>                                handle_edge_irq, "edge");
> @@ -165,5 +166,6 @@ void __init init_IRQ(void)
>                                handle_level_irq, "level");
>                        irq_set_status_flags(i, IRQ_LEVEL);
>                }
> +               irq_get_irq_data(i)->hwirq = i - 1;
>        }
>  }
> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
> index e5d63a8..ac1b463 100644
> --- a/arch/microblaze/kernel/irq.c
> +++ b/arch/microblaze/kernel/irq.c
> @@ -33,11 +33,11 @@ void __irq_entry do_IRQ(struct pt_regs *regs)
>        irq_enter();
>        irq = get_irq(regs);
>  next_irq:
> -       BUG_ON(irq == -1U);
> +       BUG_ON(!irq);
>        generic_handle_irq(irq);
>
>        irq = get_irq(regs);
> -       if (irq != -1U) {
> +       if (irq) {
>                pr_debug("next irq: %d\n", irq);
>                ++concurrent_irq;
>                goto next_irq;
> @@ -52,13 +52,15 @@ next_irq:
>   intc without any cascades or any connection that's why mapping is 1:1 */
>  unsigned int irq_create_mapping(struct irq_host *host, irq_hw_number_t hwirq)
>  {
> -       return hwirq;
> +       return hwirq + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_mapping);
>
>  unsigned int irq_create_of_mapping(struct device_node *controller,
>                                   const u32 *intspec, unsigned int intsize)
>  {
> -       return intspec[0];
> +       /* Hardware irq is mapped to Linux IRQ# by a 1 offset. Linux irq
> +        * 0 means no IRQ. */
> +       return intspec[0] + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> --
> 1.7.5.4
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
       [not found]                   ` <1323268911-6104-1-git-send-email-robherring2@gmail.com>
  2011-12-07 15:02                       ` Grant Likely
@ 2011-12-07 16:05                     ` Linus Torvalds
  2011-12-07 16:39                       ` Rob Herring
  2011-12-09 11:45                       ` Michal Simek
  2 siblings, 1 reply; 137+ messages in thread
From: Linus Torvalds @ 2011-12-07 16:05 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michal Simek, John Linn, Grant Likely, Rob Herring, Ingo Molnar,
	Jeff Garzik, Stephen Rothwell, devicetree-discuss, LKML,
	Randy Dunlap, Andrew Morton, Alan Cox, Anton Vorontsov

On Wed, Dec 7, 2011 at 6:41 AM, Rob Herring <robherring2@gmail.com> wrote:
>
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.

This looks really nice and would probably be a great example for other
architectures with the same issue.

My only (small) nit is that just from a debuggability standpoint I'd
actually suggest keeping the "translated" and "hardware" interrupt
numbers totally disjoint, which would seem to be trivial - make the
offset be 32 instead of 1. Sure, some NR_IRQ arrays would end up being
a bit bigger that way, but it would allow for trivially seeing whether
anybody reports the raw or translated irq numbers by just looking at
the number. That could reduce lots of confusion if somebody ends up
having the old non-translated number hardcoded etc.

It would also potentially allow for actual debug checks - having code
like "WARN_ON_ONCE(irq < 32)" in some arch-specific irq controller
registration path etc, which is much harder to do with the overlapping
numbers.

But it's nice to see how small the patch *can* be.

               Linus

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
  2011-12-07 16:05                     ` Linus Torvalds
@ 2011-12-07 16:39                       ` Rob Herring
  0 siblings, 0 replies; 137+ messages in thread
From: Rob Herring @ 2011-12-07 16:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Michal Simek, John Linn, Grant Likely, Rob Herring, Ingo Molnar,
	Jeff Garzik, Stephen Rothwell, devicetree-discuss, LKML,
	Randy Dunlap, Andrew Morton, Alan Cox, Anton Vorontsov

Linus,

On 12/07/2011 10:05 AM, Linus Torvalds wrote:
> On Wed, Dec 7, 2011 at 6:41 AM, Rob Herring <robherring2@gmail.com> wrote:
>>
>> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
>> it in line with most of the rest of the kernel.  It also prepares for
>> Microblaze eventually supporting multiple interrupt controllers by
>> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
>> number is just a cookie with no guarantee of a direct relationship
>> with the hardware irq arrangement.
> 
> This looks really nice and would probably be a great example for other
> architectures with the same issue.
> 
> My only (small) nit is that just from a debuggability standpoint I'd
> actually suggest keeping the "translated" and "hardware" interrupt
> numbers totally disjoint, which would seem to be trivial - make the
> offset be 32 instead of 1. Sure, some NR_IRQ arrays would end up being
> a bit bigger that way, but it would allow for trivially seeing whether
> anybody reports the raw or translated irq numbers by just looking at
> the number. That could reduce lots of confusion if somebody ends up
> having the old non-translated number hardcoded etc.
> 
> It would also potentially allow for actual debug checks - having code
> like "WARN_ON_ONCE(irq < 32)" in some arch-specific irq controller
> registration path etc, which is much harder to do with the overlapping
> numbers.

Agreed. I debated making it 16 just to skip the legacy interrupts as
we're doing on ARM. So there's 2 benefits to skipping to 32.

Anyway, I'll leave it to someone that can actually build and test this.

> But it's nice to see how small the patch *can* be.

If only ARM was this easy...

Rob

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
@ 2011-12-09 11:45                       ` Michal Simek
  0 siblings, 0 replies; 137+ messages in thread
From: Michal Simek @ 2011-12-09 11:45 UTC (permalink / raw)
  To: Rob Herring
  Cc: John Linn, Linus Torvalds, Grant Likely, Rob Herring,
	Ingo Molnar, Jeff Garzik, Stephen Rothwell, devicetree-discuss,
	LKML, Randy Dunlap, Andrew Morton, Alan Cox, Anton Vorontsov

Rob Herring wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> 
> As has been discussed many times[1], Using NO_IRQ set to anything other
> than 0 is bug waiting to happen since many drivers follow the pattern
> "if (!irq)" for testing whether or not an irq has been set.
> 
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.
> 
> At this point, Microblaze interrupt handling only supports only one
> instance of one kind of interrupt controller (xilinx_intc).  This change
> shouldn't affect any architecture code outside of the interrupt
> controller driver and the irq_of mapping.
> 
> Updated to 3.2 and to use irq_data.hwirq by Rob Herring.
> 
> Completely untested.
> 
> [1] http://lkml.org/lkml/2005/11/21/221
> 
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> 
> The main complaint with the prior version was Michal's complaint about the
> +1 / -1 conversion in every function. This is now solved with the use of
> irq_data.hwirq to store the h/w irq numbers.
> 
> I also fixed some errors around nr_irq.

I have looked at your patch and fix some things.

> 
> Rob
> 
>  arch/microblaze/include/asm/irq.h |    4 ++--
>  arch/microblaze/kernel/intc.c     |   18 ++++++++++--------
>  arch/microblaze/kernel/irq.c      |   10 ++++++----
>  3 files changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index cc54187..b07c179 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -9,7 +9,7 @@
>  #ifndef _ASM_MICROBLAZE_IRQ_H
>  #define _ASM_MICROBLAZE_IRQ_H
>  
> -#define NR_IRQS 32
> +#define NR_IRQS (32 + 1)	/* Add 1 to skip over IRQ0 */
>  #include <asm-generic/irq.h>
>  
>  /* This type is the placeholder for a hardware interrupt number. It has to
> @@ -20,7 +20,7 @@ typedef unsigned long irq_hw_number_t;
>  
>  extern unsigned int nr_irq;
>  
> -#define NO_IRQ (-1)
> +#define NO_IRQ 0
>  
>  struct pt_regs;
>  extern void do_IRQ(struct pt_regs *regs);
> diff --git a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
> index eb41441..ed65aac 100644
> --- a/arch/microblaze/kernel/intc.c
> +++ b/arch/microblaze/kernel/intc.c
> @@ -42,7 +42,7 @@ unsigned int nr_irq;
>  
>  static void intc_enable_or_unmask(struct irq_data *d)
>  {
> -	unsigned long mask = 1 << d->irq;
> +	unsigned long mask = 1 << d->hwirq;
>  	pr_debug("enable_or_unmask: %d\n", d->irq);
>  	out_be32(INTC_BASE + SIE, mask);
>  
> @@ -57,18 +57,18 @@ static void intc_enable_or_unmask(struct irq_data *d)
>  static void intc_disable_or_mask(struct irq_data *d)
>  {
>  	pr_debug("disable: %d\n", d->irq);
> -	out_be32(INTC_BASE + CIE, 1 << d->irq);
> +	out_be32(INTC_BASE + CIE, 1 << d->hwirq);
>  }
>  
>  static void intc_ack(struct irq_data *d)
>  {
>  	pr_debug("ack: %d\n", d->irq);
> -	out_be32(INTC_BASE + IAR, 1 << d->irq);
> +	out_be32(INTC_BASE + IAR, 1 << d->hwirq);
>  }
>  
>  static void intc_mask_ack(struct irq_data *d)
>  {
> -	unsigned long mask = 1 << d->irq;
> +	unsigned long mask = 1 << d->hwirq;
>  	pr_debug("disable_and_ack: %d\n", d->irq);
>  	out_be32(INTC_BASE + CIE, mask);
>  	out_be32(INTC_BASE + IAR, mask);
> @@ -90,8 +90,11 @@ unsigned int get_irq(struct pt_regs *regs)
>  	 * NOTE: This function is the one that needs to be improved in
>  	 * order to handle multiple interrupt controllers. It currently
>  	 * is hardcoded to check for interrupts only on the first INTC.
> +	 *
> +	 * Linux IRQ# is currently offset by one to map to the hardware
> +	 * irq number.  So hardware IRQ0 maps to Linux irq 1.
>  	 */
> -	irq = in_be32(INTC_BASE + IVR);
> +	irq = in_be32(INTC_BASE + IVR) + 1;
>  	pr_debug("get_irq: %d\n", irq);
>  
>  	return irq;
> @@ -134,8 +137,6 @@ void __init init_IRQ(void)
>  	intr_type =
>  		be32_to_cpup(of_get_property(intc,
>  						"xlnx,kind-of-intr", NULL));
> -	if (intr_type > (u32)((1ULL << nr_irq) - 1))
> -		printk(KERN_INFO " ERROR: Mismatch in kind-of-intr param\n");

This is necessary to keep it because some older versions had a bug.
It is just checking mechanism and not NO_IRQ related change.

>  
>  #ifdef CONFIG_SELFMOD_INTC
>  	selfmod_function((int *) arr_func, intc_baseaddr);
> @@ -155,7 +156,7 @@ void __init init_IRQ(void)
>  	/* Turn on the Master Enable. */
>  	out_be32(intc_baseaddr + MER, MER_HIE | MER_ME);
>  
> -	for (i = 0; i < nr_irq; ++i) {
> +	for (i = 1; i < nr_irq; ++i) {
>  		if (intr_type & (0x00000001 << i)) {

intr_type should be called intr_mask because it is used as mask.
Which means that this should be (i - 1) because of shift.

>  			irq_set_chip_and_handler_name(i, &intc_dev,
>  				handle_edge_irq, "edge");
> @@ -165,5 +166,6 @@ void __init init_IRQ(void)
>  				handle_level_irq, "level");
>  			irq_set_status_flags(i, IRQ_LEVEL);
>  		}
> +		irq_get_irq_data(i)->hwirq = i - 1;
>  	}
>  }
> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
> index e5d63a8..ac1b463 100644
> --- a/arch/microblaze/kernel/irq.c
> +++ b/arch/microblaze/kernel/irq.c
> @@ -33,11 +33,11 @@ void __irq_entry do_IRQ(struct pt_regs *regs)
>  	irq_enter();
>  	irq = get_irq(regs);
>  next_irq:
> -	BUG_ON(irq == -1U);
> +	BUG_ON(!irq);
>  	generic_handle_irq(irq);
>  
>  	irq = get_irq(regs);
> -	if (irq != -1U) {
> +	if (irq) {
>  		pr_debug("next irq: %d\n", irq);
>  		++concurrent_irq;
>  		goto next_irq;
> @@ -52,13 +52,15 @@ next_irq:
>    intc without any cascades or any connection that's why mapping is 1:1 */
>  unsigned int irq_create_mapping(struct irq_host *host, irq_hw_number_t hwirq)
>  {
> -	return hwirq;
> +	return hwirq + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_mapping);
>  
>  unsigned int irq_create_of_mapping(struct device_node *controller,
>  				   const u32 *intspec, unsigned int intsize)
>  {
> -	return intspec[0];
> +	/* Hardware irq is mapped to Linux IRQ# by a 1 offset. Linux irq
> +	 * 0 means no IRQ. */
> +	return intspec[0] + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_of_mapping);

I have created 5 patches to fix interrupt and timer code with changes to get NO_IRQ
to work.
I don't like one thing which is magic + 1 offset on some places with the same comment
which explain that it is because of NO_IRQ. I have created macros to solve this
(IRQ_SW_OFFSET and IRQ_OFFSET). Please comment it.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

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

* Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0
@ 2011-12-09 11:45                       ` Michal Simek
  0 siblings, 0 replies; 137+ messages in thread
From: Michal Simek @ 2011-12-09 11:45 UTC (permalink / raw)
  To: Rob Herring
  Cc: Stephen Rothwell, Andrew Morton,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Rob Herring,
	Jeff Garzik, Anton Vorontsov, Randy Dunlap, Ingo Molnar,
	Linus Torvalds, Alan Cox

Rob Herring wrote:
> From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> 
> As has been discussed many times[1], Using NO_IRQ set to anything other
> than 0 is bug waiting to happen since many drivers follow the pattern
> "if (!irq)" for testing whether or not an irq has been set.
> 
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.
> 
> At this point, Microblaze interrupt handling only supports only one
> instance of one kind of interrupt controller (xilinx_intc).  This change
> shouldn't affect any architecture code outside of the interrupt
> controller driver and the irq_of mapping.
> 
> Updated to 3.2 and to use irq_data.hwirq by Rob Herring.
> 
> Completely untested.
> 
> [1] http://lkml.org/lkml/2005/11/21/221
> 
> Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> ---
> 
> The main complaint with the prior version was Michal's complaint about the
> +1 / -1 conversion in every function. This is now solved with the use of
> irq_data.hwirq to store the h/w irq numbers.
> 
> I also fixed some errors around nr_irq.

I have looked at your patch and fix some things.

> 
> Rob
> 
>  arch/microblaze/include/asm/irq.h |    4 ++--
>  arch/microblaze/kernel/intc.c     |   18 ++++++++++--------
>  arch/microblaze/kernel/irq.c      |   10 ++++++----
>  3 files changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index cc54187..b07c179 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -9,7 +9,7 @@
>  #ifndef _ASM_MICROBLAZE_IRQ_H
>  #define _ASM_MICROBLAZE_IRQ_H
>  
> -#define NR_IRQS 32
> +#define NR_IRQS (32 + 1)	/* Add 1 to skip over IRQ0 */
>  #include <asm-generic/irq.h>
>  
>  /* This type is the placeholder for a hardware interrupt number. It has to
> @@ -20,7 +20,7 @@ typedef unsigned long irq_hw_number_t;
>  
>  extern unsigned int nr_irq;
>  
> -#define NO_IRQ (-1)
> +#define NO_IRQ 0
>  
>  struct pt_regs;
>  extern void do_IRQ(struct pt_regs *regs);
> diff --git a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
> index eb41441..ed65aac 100644
> --- a/arch/microblaze/kernel/intc.c
> +++ b/arch/microblaze/kernel/intc.c
> @@ -42,7 +42,7 @@ unsigned int nr_irq;
>  
>  static void intc_enable_or_unmask(struct irq_data *d)
>  {
> -	unsigned long mask = 1 << d->irq;
> +	unsigned long mask = 1 << d->hwirq;
>  	pr_debug("enable_or_unmask: %d\n", d->irq);
>  	out_be32(INTC_BASE + SIE, mask);
>  
> @@ -57,18 +57,18 @@ static void intc_enable_or_unmask(struct irq_data *d)
>  static void intc_disable_or_mask(struct irq_data *d)
>  {
>  	pr_debug("disable: %d\n", d->irq);
> -	out_be32(INTC_BASE + CIE, 1 << d->irq);
> +	out_be32(INTC_BASE + CIE, 1 << d->hwirq);
>  }
>  
>  static void intc_ack(struct irq_data *d)
>  {
>  	pr_debug("ack: %d\n", d->irq);
> -	out_be32(INTC_BASE + IAR, 1 << d->irq);
> +	out_be32(INTC_BASE + IAR, 1 << d->hwirq);
>  }
>  
>  static void intc_mask_ack(struct irq_data *d)
>  {
> -	unsigned long mask = 1 << d->irq;
> +	unsigned long mask = 1 << d->hwirq;
>  	pr_debug("disable_and_ack: %d\n", d->irq);
>  	out_be32(INTC_BASE + CIE, mask);
>  	out_be32(INTC_BASE + IAR, mask);
> @@ -90,8 +90,11 @@ unsigned int get_irq(struct pt_regs *regs)
>  	 * NOTE: This function is the one that needs to be improved in
>  	 * order to handle multiple interrupt controllers. It currently
>  	 * is hardcoded to check for interrupts only on the first INTC.
> +	 *
> +	 * Linux IRQ# is currently offset by one to map to the hardware
> +	 * irq number.  So hardware IRQ0 maps to Linux irq 1.
>  	 */
> -	irq = in_be32(INTC_BASE + IVR);
> +	irq = in_be32(INTC_BASE + IVR) + 1;
>  	pr_debug("get_irq: %d\n", irq);
>  
>  	return irq;
> @@ -134,8 +137,6 @@ void __init init_IRQ(void)
>  	intr_type =
>  		be32_to_cpup(of_get_property(intc,
>  						"xlnx,kind-of-intr", NULL));
> -	if (intr_type > (u32)((1ULL << nr_irq) - 1))
> -		printk(KERN_INFO " ERROR: Mismatch in kind-of-intr param\n");

This is necessary to keep it because some older versions had a bug.
It is just checking mechanism and not NO_IRQ related change.

>  
>  #ifdef CONFIG_SELFMOD_INTC
>  	selfmod_function((int *) arr_func, intc_baseaddr);
> @@ -155,7 +156,7 @@ void __init init_IRQ(void)
>  	/* Turn on the Master Enable. */
>  	out_be32(intc_baseaddr + MER, MER_HIE | MER_ME);
>  
> -	for (i = 0; i < nr_irq; ++i) {
> +	for (i = 1; i < nr_irq; ++i) {
>  		if (intr_type & (0x00000001 << i)) {

intr_type should be called intr_mask because it is used as mask.
Which means that this should be (i - 1) because of shift.

>  			irq_set_chip_and_handler_name(i, &intc_dev,
>  				handle_edge_irq, "edge");
> @@ -165,5 +166,6 @@ void __init init_IRQ(void)
>  				handle_level_irq, "level");
>  			irq_set_status_flags(i, IRQ_LEVEL);
>  		}
> +		irq_get_irq_data(i)->hwirq = i - 1;
>  	}
>  }
> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
> index e5d63a8..ac1b463 100644
> --- a/arch/microblaze/kernel/irq.c
> +++ b/arch/microblaze/kernel/irq.c
> @@ -33,11 +33,11 @@ void __irq_entry do_IRQ(struct pt_regs *regs)
>  	irq_enter();
>  	irq = get_irq(regs);
>  next_irq:
> -	BUG_ON(irq == -1U);
> +	BUG_ON(!irq);
>  	generic_handle_irq(irq);
>  
>  	irq = get_irq(regs);
> -	if (irq != -1U) {
> +	if (irq) {
>  		pr_debug("next irq: %d\n", irq);
>  		++concurrent_irq;
>  		goto next_irq;
> @@ -52,13 +52,15 @@ next_irq:
>    intc without any cascades or any connection that's why mapping is 1:1 */
>  unsigned int irq_create_mapping(struct irq_host *host, irq_hw_number_t hwirq)
>  {
> -	return hwirq;
> +	return hwirq + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_mapping);
>  
>  unsigned int irq_create_of_mapping(struct device_node *controller,
>  				   const u32 *intspec, unsigned int intsize)
>  {
> -	return intspec[0];
> +	/* Hardware irq is mapped to Linux IRQ# by a 1 offset. Linux irq
> +	 * 0 means no IRQ. */
> +	return intspec[0] + 1;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_of_mapping);

I have created 5 patches to fix interrupt and timer code with changes to get NO_IRQ
to work.
I don't like one thing which is magic + 1 offset on some places with the same comment
which explain that it is because of NO_IRQ. I have created macros to solve this
(IRQ_SW_OFFSET and IRQ_OFFSET). Please comment it.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

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

end of thread, other threads:[~2011-12-09 11:45 UTC | newest]

Thread overview: 137+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-11  9:11 linux-next: Tree for Oct 11 Stephen Rothwell
2011-10-11 18:26 ` [PATCH -next] x86: perf_event_intel.c needs export.h Randy Dunlap
2011-10-11 18:49 ` linux-next: Tree for Oct 11 (mmc) Randy Dunlap
2011-10-11 19:31   ` mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) Andrei Warkentin
2011-10-11 21:59     ` Randy Dunlap
2011-10-11 23:20       ` NamJae Jeon
2011-10-11 23:48         ` Andrei Warkentin
2011-10-12  0:16           ` NamJae Jeon
2011-10-12  0:50             ` Andrei Warkentin
2011-10-12  1:55               ` NamJae Jeon
2011-10-11 19:15 ` [PATCH -next] jbd2: fix build when CONFIG_BUG is not enabled Randy Dunlap
2011-10-27  8:06   ` Ted Ts'o
2011-10-11 19:26 ` linux-next: Tree for Oct 11 (mfd/intel_msic.c) Randy Dunlap
2011-10-11 19:32 ` linux-next: Tree for Oct 11 (gpio regulator) Randy Dunlap
2011-10-11 20:22   ` Heiko Stübner
2011-10-11 20:37 ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Randy Dunlap
2011-10-14 17:58   ` Randy Dunlap
2011-11-10 13:57     ` Ingo Molnar
2011-11-10 14:25       ` Alan Cox
2011-11-10 15:18       ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Anton Vorontsov
2011-11-10 15:25         ` [PATCH 1/2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
2011-12-06 21:22           ` Rob Herring
2011-12-06 21:25             ` Linus Torvalds
2011-12-06 23:16               ` [PATCH v3] " Anton Vorontsov
2011-12-07  3:51                 ` Rob Herring
     [not found]                   ` <1323268911-6104-1-git-send-email-robherring2@gmail.com>
2011-12-07 15:02                     ` [RFC PATCH] microblaze/irq: Change NO_IRQ to 0 Grant Likely
2011-12-07 15:02                       ` Grant Likely
2011-12-07 16:05                     ` Linus Torvalds
2011-12-07 16:39                       ` Rob Herring
2011-12-09 11:45                     ` Michal Simek
2011-12-09 11:45                       ` Michal Simek
     [not found]                 ` <20111206231626.GA31683-wnGakbxT3iijyJ0x5qLZdcN33GVbZNy3@public.gmane.org>
2011-12-07  9:52                   ` [PATCH v3] of/irq: Get rid of NO_IRQ usage Wolfram Sang
2011-12-07  9:52                     ` Wolfram Sang
2011-11-10 15:26         ` [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver Anton Vorontsov
2011-11-10 15:38           ` Alan Cox
2011-11-10 16:28             ` [PATCH] " Anton Vorontsov
2011-11-10 20:34               ` Jeff Garzik
2011-12-02 19:19               ` Dave Martin
2011-12-02 22:34                 ` Anton Vorontsov
2011-12-02 22:40                   ` Anton Vorontsov
2011-12-02 22:46                     ` Anton Vorontsov
2011-12-02 22:40                   ` Linus Torvalds
2011-12-02 23:18                     ` [PATCH v2] of/irq: Get rid of NO_IRQ usage Anton Vorontsov
2011-12-02 23:22                 ` [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver Alan Cox
2011-12-03 18:56                   ` Geert Uytterhoeven
2011-12-02 19:26               ` Dave Martin
2011-12-02 19:28                 ` Linus Torvalds
2011-12-02 19:28                   ` Linus Torvalds
2011-12-02 23:12                   ` Benjamin Herrenschmidt
2011-12-02 23:12                     ` Benjamin Herrenschmidt
2011-12-05 16:11                     ` Dave Martin
2011-12-05 16:11                       ` Dave Martin
2011-12-05 17:40                       ` Nicolas Pitre
2011-12-05 17:40                         ` Nicolas Pitre
2011-12-05 18:02                         ` Dave Martin
2011-12-05 18:02                           ` Dave Martin
2011-12-05 18:15                           ` Geert Uytterhoeven
2011-12-05 18:15                             ` Geert Uytterhoeven
2011-12-05 18:18                           ` Nicolas Pitre
2011-12-05 18:18                             ` Nicolas Pitre
     [not found]                             ` <alpine.LFD.2.02.1112051310150.2357-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-12-05 18:45                               ` Alan Cox
2011-12-05 18:45                                 ` Alan Cox
2011-12-05 18:45                                 ` Alan Cox
2011-12-05 19:19                                 ` James Bottomley
2011-12-05 19:19                                   ` James Bottomley
2011-12-06  6:13                                 ` Jean-Christophe PLAGNIOL-VILLARD
2011-12-06  6:13                                   ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]                                   ` <20111206061321.GH9192-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2011-12-06 11:34                                     ` Alan Cox
2011-12-06 11:34                                       ` Alan Cox
2011-12-06 11:34                                       ` Alan Cox
2011-12-05 19:16                               ` Rob Herring
2011-12-05 19:16                                 ` Rob Herring
2011-12-05 19:16                                 ` Rob Herring
2011-12-05 20:21                                 ` Anton Vorontsov
2011-12-05 20:21                                   ` Anton Vorontsov
2011-12-05 20:47                                   ` Rob Herring
2011-12-05 20:47                                     ` Rob Herring
     [not found]                                     ` <4EDD2DE1.1050606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-05 20:53                                       ` Alan Cox
2011-12-05 20:53                                         ` Alan Cox
2011-12-05 20:53                                         ` Alan Cox
2011-12-06  9:30                                     ` Dave Martin
2011-12-06  9:30                                       ` Dave Martin
     [not found]                                       ` <20111206093000.GA2274-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-06 10:34                                         ` Alan Cox
2011-12-06 10:34                                           ` Alan Cox
2011-12-06 10:34                                           ` Alan Cox
2011-12-06 10:55                                         ` Russell King - ARM Linux
2011-12-06 10:55                                           ` Russell King - ARM Linux
2011-12-06 10:55                                           ` Russell King - ARM Linux
2011-12-05 19:26                             ` Dave Martin
2011-12-05 19:26                               ` Dave Martin
2011-12-05 19:49                               ` Nicolas Pitre
2011-12-05 19:49                                 ` Nicolas Pitre
2011-12-06  9:37                                 ` Dave Martin
2011-12-06  9:37                                   ` Dave Martin
     [not found]                                   ` <20111206093709.GB2274-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-06 10:46                                     ` Russell King - ARM Linux
2011-12-06 10:46                                       ` Russell King - ARM Linux
2011-12-06 10:46                                       ` Russell King - ARM Linux
2011-12-06 11:00                                       ` Geert Uytterhoeven
2011-12-06 11:00                                         ` Geert Uytterhoeven
2011-12-06 11:00                                         ` Geert Uytterhoeven
2011-12-06 11:03                                         ` Russell King - ARM Linux
2011-12-06 11:03                                           ` Russell King - ARM Linux
2011-12-06 11:10                                         ` Alan Cox
2011-12-06 11:10                                           ` Alan Cox
2011-12-06 11:05                                       ` Alan Cox
2011-12-06 11:05                                         ` Alan Cox
     [not found]                                         ` <20111206110554.53bddd14-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2011-12-06 11:25                                           ` Russell King - ARM Linux
2011-12-06 11:25                                             ` Russell King - ARM Linux
2011-12-06 11:25                                             ` Russell King - ARM Linux
2011-12-06 12:11                                             ` Alan Cox
2011-12-06 12:11                                               ` Alan Cox
2011-12-06 11:37                                       ` Dave Martin
2011-12-06 11:37                                         ` Dave Martin
2011-12-06 11:49                                         ` Russell King - ARM Linux
2011-12-06 11:49                                           ` Russell King - ARM Linux
2011-12-06 13:25                                           ` Dave Martin
2011-12-06 13:25                                             ` Dave Martin
2011-12-06 19:56                                           ` Rob Herring
2011-12-06 19:56                                             ` Rob Herring
2011-12-06 19:20                                       ` Linus Torvalds
2011-12-06 19:20                                         ` Linus Torvalds
2011-12-06 20:00                                         ` Russell King - ARM Linux
2011-12-06 20:00                                           ` Russell King - ARM Linux
     [not found]                                         ` <CA+55aFwZBr+3_S9kU-+m8zN8iwOvn2miuuAy-zt7sUjW_+abBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-06 20:59                                           ` Uwe Kleine-König
2011-12-06 20:59                                             ` Uwe Kleine-König
2011-12-06 20:59                                             ` Uwe Kleine-König
2011-12-06 19:11                                   ` Nicolas Pitre
2011-12-06 19:11                                     ` Nicolas Pitre
     [not found]                       ` <20111205161157.GA27550-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2011-12-05 17:41                         ` Alan Cox
2011-12-05 17:41                           ` Alan Cox
2011-12-05 17:41                           ` Alan Cox
2011-11-10 15:35         ` [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage) Alan Cox
2011-11-10 18:18       ` linux-next: Tree for Oct 11 (ata/pata_of_platform.c) Jeff Garzik
2011-10-11 20:45 ` linux-next: Tree for Oct 11 (iio/resolver) Randy Dunlap
2011-10-11 20:45   ` Randy Dunlap
2011-10-12  8:58   ` Jonathan Cameron
2011-10-12  8:58     ` Jonathan Cameron

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.