Discussion:
linux-next: Tree for Oct 11
Stephen Rothwell
2011-10-11 09:11:27 UTC
Permalink
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 ***@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
Randy Dunlap
2011-10-11 18:26:19 UTC
Permalink
From: Randy Dunlap <***@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 <***@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>
Randy Dunlap
2011-10-11 18:49:39 UTC
Permalink
Post by Stephen Rothwell
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.
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 ***
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrei Warkentin
2011-10-11 19:31:57 UTC
Permalink
Hi Randy,

----- Original Message -----
Sent: Tuesday, October 11, 2011 2:49:39 PM
Subject: Re: linux-next: Tree for Oct 11 (mmc)
Post by Stephen Rothwell
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.
In file included from
'DISK_NAME_LEN' undeclared here (not in a function)
Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
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.
'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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Randy Dunlap
2011-10-11 21:59:34 UTC
Permalink
Post by Andrei Warkentin
Hi Randy,
----- Original Message -----
Sent: Tuesday, October 11, 2011 2:49:39 PM
Subject: Re: linux-next: Tree for Oct 11 (mmc)
Post by Stephen Rothwell
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.
In file included from
'DISK_NAME_LEN' undeclared here (not in a function)
Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c build.
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.
'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 -
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 ***
NamJae Jeon
2011-10-11 23:20:48 UTC
Permalink
Post by Andrei Warkentin
Hi Randy,
----- Original Message -----
Sent: Tuesday, October 11, 2011 2:49:39 PM
Subject: Re: linux-next: Tree for Oct 11 (mmc)
Post by Stephen Rothwell
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)=
=2E
Post by Andrei Warkentin
Post by Stephen Rothwell
=C2=A0The
patch set is still absent, however.
In file included from
'DISK_NAME_LEN' undeclared here (not in a function)
Deleting the #include <linux/mmc/card.h> fixes the sdio_uart.c buil=
d.
Post by Andrei Warkentin
Because linux/genhd is now included, oops. I'm pretty positive this =
is due to the "mmc : general purpose partition support" patch pulled re=
cently. I am adding NamJae, who was the author.
Post by Andrei Warkentin
'DISK_NAME_LEN' undeclared here (not in a function)
Should mmc/core/ depend on BLOCK? =C2=A0or 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 t=
wo suggestions -
Post by Andrei Warkentin
=C2=A0 =C2=A0linux/genhd.h:#define DISK_NAME_LEN =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
Post by Andrei Warkentin
2) Put the MMC physical partition code under an #ifdef CONFIG_BLOCK,=
which is a reasonable
Post by Andrei Warkentin
=C2=A0 =C2=A0proposition, given that there wouldn't be any need to p=
arse physical partition info if
Post by Andrei Warkentin
=C2=A0 =C2=A0it would never be consumed by the MMC block driver.
Thoughts?
Agreed on part 2). =C2=A0Do part 1) if it is required, but it's usual=
ly better
not to duplicate constants or structs etc.
IOW, can DISK_NAME_LEN in linux/genhd.h be exposed even when CONFIG_B=
LOCK
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 c=
ode ***
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrei Warkentin
2011-10-11 23:48:53 UTC
Permalink
----- Original Message -----
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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
NamJae Jeon
2011-10-12 00:16:51 UTC
Permalink
Post by Andrei Warkentin
----- Original Message -----
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.
Post by Andrei Warkentin
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrei Warkentin
2011-10-12 00:50:03 UTC
Permalink
Hi,

----- Original Message -----
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))
Post by Andrei Warkentin
----- Original Message -----
Ball"
Sent: Tuesday, October 11, 2011 7:20:48 PM
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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
NamJae Jeon
2011-10-12 01:55:08 UTC
Permalink
Post by Andrei Warkentin
Hi,
----- Original Message -----
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))
Post by Andrei Warkentin
----- Original Message -----
Ball"
Sent: Tuesday, October 11, 2011 7:20:48 PM
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.
Post by Andrei Warkentin
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Randy Dunlap
2011-10-11 19:15:20 UTC
Permalink
From: Randy Dunlap <***@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 <***@gmail.com>.

Signed-off-by: Randy Dunlap <***@xenotime.net>
Cc: Arnd Bergmann <***@arndb.de>
Cc: Arnaud Lacombe <***@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;
}
Ted Ts'o
2011-10-27 08:06:11 UTC
Permalink
Post by Randy Dunlap
fs/jbd2/transaction.c:1175:3: error: implicit declaration of function '__WARN'
by changing __WARN() to WARN_ON(), as suggested by
Thanks, applied.

- Ted
Randy Dunlap
2011-10-11 19:26:22 UTC
Permalink
Post by Stephen Rothwell
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.
(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 ***
Randy Dunlap
2011-10-11 19:32:11 UTC
Permalink
Post by Stephen Rothwell
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.
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 ***
Heiko Stübner
2011-10-11 20:22:24 UTC
Permalink
Hi Randy,
Post by Randy Dunlap
Post by Stephen Rothwell
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.
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
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
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
Randy Dunlap
2011-10-11 20:37:52 UTC
Permalink
Post by Stephen Rothwell
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.
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 ***
Randy Dunlap
2011-10-14 17:58:01 UTC
Permalink
Post by Randy Dunlap
Post by Stephen Rothwell
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.
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 ***
Ingo Molnar
2011-11-10 13:57:03 UTC
Permalink
Post by Randy Dunlap
Post by Randy Dunlap
Post by Stephen Rothwell
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.
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
Alan Cox
2011-11-10 14:25:39 UTC
Permalink
O> > > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
Post by Ingo Molnar
Post by Randy Dunlap
[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)

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Anton Vorontsov
2011-11-10 15:18:52 UTC
Permalink
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 <***@gmail.com>
---

On Thu, Nov 10, 2011 at 02:57:03PM +0100, Ingo Molnar wrote:
[...]
Post by Ingo Molnar
Post by Randy Dunlap
Post by Randy Dunlap
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
Anton Vorontsov
2011-11-10 15:25:41 UTC
Permalink
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 <***@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
Rob Herring
2011-12-06 21:22:02 UTC
Permalink
Post by Anton Vorontsov
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.
---
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
@@ -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);
+#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
Post by Anton Vorontsov
+ 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;
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2011-12-06 21:25:07 UTC
Permalink
Post by Rob Herring
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.
Post by Rob Herring
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Anton Vorontsov
2011-12-06 23:16:26 UTC
Permalink
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 <***@linaro.org>
---
Post by Linus Torvalds
Post by Rob Herring
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.
Post by Rob Herring
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
Rob Herring
2011-12-07 03:51:14 UTC
Permalink
Post by Anton Vorontsov
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.
---
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
Post by Anton Vorontsov
Post by Linus Torvalds
Post by Rob Herring
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.
Post by Rob Herring
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
@@ -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;
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Wolfram Sang
2011-12-07 09:52:54 UTC
Permalink
Post by Anton Vorontsov
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.
---
/me likes NO_IRQ removal very much

Acked-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+***@public.gmane.org>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Anton Vorontsov
2011-11-10 15:26:06 UTC
Permalink
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 <***@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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Cox
2011-11-10 15:38:16 UTC
Permalink
On Thu, 10 Nov 2011 19:26:06 +0400
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
Acked-by: Alan Cox <***@linux.intel.com>

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Anton Vorontsov
2011-11-10 16:28:59 UTC
Permalink
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 <***@gmail.com>
Acked-by: Alan Cox <***@linux.intel.com>
---
Post by Alan Cox
On Thu, 10 Nov 2011 19:26:06 +0400
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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
Jeff Garzik
2011-11-10 20:34:30 UTC
Permalink
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
---
Post by Alan Cox
On Thu, 10 Nov 2011 19:26:06 +0400
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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
Dave Martin
2011-12-02 19:19:17 UTC
Permalink
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
---
Post by Alan Cox
On Thu, 10 Nov 2011 19:26:06 +0400
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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
Post by Anton Vorontsov
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
https://lists.ozlabs.org/listinfo/devicetree-discuss
Anton Vorontsov
2011-12-02 22:34:02 UTC
Permalink
On Fri, Dec 02, 2011 at 07:19:17PM +0000, Dave Martin wrote:
[...]
Post by Dave Martin
Post by Anton Vorontsov
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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: ***@gmail.com
Anton Vorontsov
2011-12-02 22:40:18 UTC
Permalink
Post by Anton Vorontsov
[...]
Post by Dave Martin
Post by Anton Vorontsov
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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?
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: ***@gmail.com
Anton Vorontsov
2011-12-02 22:46:36 UTC
Permalink
Post by Anton Vorontsov
Post by Anton Vorontsov
[...]
Post by Dave Martin
Post by Anton Vorontsov
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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?
http://lkml.org/lkml/2011/11/10/290
"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: ***@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2011-12-02 22:40:37 UTC
Permalink
On Fri, Dec 2, 2011 at 2:34 PM, Anton Vorontsov
Post by Anton Vorontsov
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
Anton Vorontsov
2011-12-02 23:18:33 UTC
Permalink
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 <***@linaro.org>
---
Post by Linus Torvalds
On Fri, Dec 2, 2011 at 2:34 PM, Anton Vorontsov
Post by Anton Vorontsov
http://lkml.org/lkml/2011/11/10/290
That seems broken.
+ ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+ oirq.size);
+#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
Alan Cox
2011-12-02 23:22:43 UTC
Permalink
Post by Dave Martin
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.
Post by Dave Martin
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
Geert Uytterhoeven
2011-12-03 18:56:08 UTC
Permalink
This is now broken on ARM where, for good or bad, NO_IRQ currently i=
s
used and is -1.
Good.
ARM developers have been told to change this for several years. The n=
ice
approach hasn't worked, the patient approach hasn't worked so now fin=
ally
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 physic=
ist
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 thi=
ng
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 =C2=A0 =C2=A0 =C2=A0 ((=
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: =C2=A0 =C2=A0 /* Return an irq, =
or NO_IRQ
to indicate=C2=A0arch/powerpc/include/asm/parport.h: =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 if (virq
=3D=3D NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if=
(cascade_irq !=3D
NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if (casca=
de_irq !=3D
NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if (casca=
de_irq !=3D
NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if (casca=
de_irq !=3D
NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if (casca=
de_irq =3D=3D
NO_IRQ)arch/powerpc/include/asm/qe_ic.h: =C2=A0 =C2=A0 =C2=A0 if (casca=
de_irq !=3D
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_MRSH=
PC0,
ROUTE_VIA_IRQ0 aka IRQ_MB93493_VDC_ROUTE).

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

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert

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

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dave Martin
2011-12-02 19:26:18 UTC
Permalink
[expanding CC -- apologies to anyone who gets this mail twice]
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
---
Post by Alan Cox
On Thu, 10 Nov 2011 19:26:06 +0400
Post by Anton Vorontsov
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
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
Post by Anton Vorontsov
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
https://lists.ozlabs.org/listinfo/devicetree-discuss
Linus Torvalds
2011-12-02 19:28:14 UTC
Permalink
Post by Dave Martin
This is now broken on ARM where, for good or bad, NO_IRQ currently is
used and is -1.
How do we resolve it? =A0If we are ready to eliminate NO_IRQ from
drivers/of/irq.c (or indeed, all code that uses it) and just use 0 fo=
r
Post by Dave Martin
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Benjamin Herrenschmidt
2011-12-02 23:12:53 UTC
Permalink
Post by Linus Torvalds
Post by Dave Martin
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.
Post by Linus Torvalds
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.
Dave Martin
2011-12-05 16:11:57 UTC
Permalink
Post by Benjamin Herrenschmidt
Post by Linus Torvalds
Post by Dave Martin
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.
Post by Linus Torvalds
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
Nicolas Pitre
2011-12-05 17:40:16 UTC
Permalink
Post by Dave Martin
Post by Linus Torvalds
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dave Martin
2011-12-05 18:02:53 UTC
Permalink
Post by Nicolas Pitre
Post by Dave Martin
Post by Linus Torvalds
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven
2011-12-05 18:15:46 UTC
Permalink
Unfortunately, NO_IRQ is often not spelled "NO_IRQ". =C2=A0It looks l=
ike the assumption
"irq < 0 =3D=3D=3D no irq" may be quite a lot more widespread than "N=
O_IRQ =3D=3D=3D 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,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert

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

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Nicolas Pitre
2011-12-05 18:18:30 UTC
Permalink
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
Post by Linus Torvalds
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Cox
2011-12-05 18:45:22 UTC
Permalink
Post by Nicolas Pitre
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.
James Bottomley
2011-12-05 19:19:14 UTC
Permalink
Post by Alan Cox
Post by Nicolas Pitre
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
Jean-Christophe PLAGNIOL-VILLARD
2011-12-06 06:13:21 UTC
Permalink
Post by Alan Cox
Post by Nicolas Pitre
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.
Alan Cox
2011-12-06 11:34:58 UTC
Permalink
Post by Jean-Christophe PLAGNIOL-VILLARD
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
Rob Herring
2011-12-05 19:16:39 UTC
Permalink
Post by Nicolas Pitre
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
Post by Linus Torvalds
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.
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
Anton Vorontsov
2011-12-05 20:21:25 UTC
Permalink
On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
[...]
Post by Rob Herring
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.
Post by Rob Herring
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: ***@gmail.com
Rob Herring
2011-12-05 20:47:29 UTC
Permalink
Post by Anton Vorontsov
[...]
Post by Rob Herring
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.
Post by Anton Vorontsov
Post by Rob Herring
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
Alan Cox
2011-12-05 20:53:44 UTC
Permalink
On Mon, 05 Dec 2011 14:47:29 -0600
Post by Rob Herring
Post by Anton Vorontsov
[...]
Post by Rob Herring
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.
Post by Rob Herring
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
Dave Martin
2011-12-06 09:30:00 UTC
Permalink
Post by Rob Herring
Post by Anton Vorontsov
[...]
Post by Rob Herring
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.
Post by Anton Vorontsov
Post by Rob Herring
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Cox
2011-12-06 10:34:57 UTC
Permalink
Post by Dave Martin
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
Russell King - ARM Linux
2011-12-06 10:55:03 UTC
Permalink
Post by Dave Martin
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.
Dave Martin
2011-12-05 19:26:05 UTC
Permalink
Post by Nicolas Pitre
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
Post by Linus Torvalds
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.
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.
Post by Nicolas Pitre
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Nicolas Pitre
2011-12-05 19:49:01 UTC
Permalink
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
Post by Linus Torvalds
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.
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.
Post by Nicolas Pitre
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
Dave Martin
2011-12-06 09:37:09 UTC
Permalink
On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:

[...]
Post by Nicolas Pitre
Post by Dave Martin
Post by Nicolas Pitre
Post by Dave Martin
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.
Post by Nicolas Pitre
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
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
Russell King - ARM Linux
2011-12-06 10:46:54 UTC
Permalink
Post by Dave Martin
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.
Geert Uytterhoeven
2011-12-06 11:00:12 UTC
Permalink
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
But.. let's make one thing clear: Alan Cox and Linus have been going =
on
about how IRQ0 should not be used. =C2=A0Let's be crystal clear: even=
x86
uses IRQ0. =C2=A0It happens to be the PIC timer, and that gets claime=
d early
on during the x86 boot. =C2=A0So please don't tell me that x86 avoids=
IRQ0.
It doesn't. =C2=A0It just happens that x86 never shows IRQ0 to anythi=
ng 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.

=46rom 46f51a2d42548358868a34df00c2a4e47bbdf691 Mon Sep 17 00:00:00 200=
1
=46rom: 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 =3D=3D 0.

Signed-off-by: Geert Uytterhoeven <***@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 =3D irq_to_desc(i);
--=20
1.7.0.4

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert

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

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
Russell King - ARM Linux
2011-12-06 11:03:28 UTC
Permalink
Post by Geert Uytterhoeven
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
But.. let's make one thing clear: Alan Cox and Linus have been goin=
g on
Post by Geert Uytterhoeven
about how IRQ0 should not be used. =A0Let's be crystal clear: even =
x86
Post by Geert Uytterhoeven
uses IRQ0. =A0It happens to be the PIC timer, and that gets claimed=
early
Post by Geert Uytterhoeven
on during the x86 boot. =A0So please don't tell me that x86 avoids =
IRQ0.
Post by Geert Uytterhoeven
It doesn't. =A0It just happens that x86 never shows IRQ0 to anythin=
g but
Post by Geert Uytterhoeven
the i8253 PIC driver.
=20
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.
Alan Cox
2011-12-06 11:10:43 UTC
Permalink
Post by Geert Uytterhoeven
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.
Alan Cox
2011-12-06 11:05:54 UTC
Permalink
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux
2011-12-06 11:25:45 UTC
Permalink
Post by Alan Cox
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
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.
Alan Cox
2011-12-06 12:11:31 UTC
Permalink
Post by Russell King - ARM Linux
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dave Martin
2011-12-06 11:37:35 UTC
Permalink
Post by Russell King - ARM Linux
Post by Dave Martin
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
Russell King - ARM Linux
2011-12-06 11:49:52 UTC
Permalink
Post by Dave Martin
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dave Martin
2011-12-06 13:25:27 UTC
Permalink
Post by Russell King - ARM Linux
Post by Dave Martin
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
2011-12-06 19:56:00 UTC
Permalink
Post by Russell King - ARM Linux
Post by Dave Martin
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
Linus Torvalds
2011-12-06 19:20:49 UTC
Permalink
On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
But.. let's make one thing clear: Alan Cox and Linus have been going =
on
about how IRQ0 should not be used. =A0Let's be crystal clear: even x8=
6
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
Russell King - ARM Linux
2011-12-06 20:00:52 UTC
Permalink
Post by Linus Torvalds
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Uwe Kleine-König
2011-12-06 20:59:55 UTC
Permalink
Hello Linus,
Post by Linus Torvalds
On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
Post by Russell King - ARM Linux
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.)
Post by Linus Torvalds
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/ |
Nicolas Pitre
2011-12-06 19:11:42 UTC
Permalink
Post by Dave Martin
Post by Nicolas Pitre
No need to convert everything.
First move is to make irq=0 meaning no IRQ. That means making things
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.
Post by Dave Martin
(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.
Post by Dave Martin
That could make sense as an approach.
You might notice that a true IRQ #0 passed to generic drivers is not
really frequent.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Cox
2011-12-05 17:41:32 UTC
Permalink
Post by Dave Martin
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')
Post by Dave Martin
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
Post by Dave Martin
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.
Post by Dave Martin
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
Alan Cox
2011-11-10 15:35:50 UTC
Permalink
Post by Anton Vorontsov
The proper fix (stop OF code from returning NO_IRQ values) is pending.
Please just apply the proper fix.
Post by Anton Vorontsov
- 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.
Post by Anton Vorontsov
+/* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Garzik
2011-11-10 18:18:58 UTC
Permalink
Post by Ingo Molnar
Post by Randy Dunlap
Post by Randy Dunlap
Post by Stephen Rothwell
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.
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
Randy Dunlap
2011-10-11 20:45:14 UTC
Permalink
Post by Stephen Rothwell
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.
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 ***
Jonathan Cameron
2011-10-12 08:58:10 UTC
Permalink
Post by Randy Dunlap
Post by Stephen Rothwell
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.
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
Post by Randy Dunlap
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>'
Continue reading on narkive:
Loading...