need to change irq to int too
Signed-off-by: NIngo Molnar <mingo@elte.hu>

An error return from create_irq_nr() is 0, but an error return from
create_irq() is -1.
Signed-off-by: NDean Nelson <dcn@sgi.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

It is possible that,
instead of PCI endpoint/sub-hierarchy structures, only IO-APIC/HPET
devices may be reported under device scope structures. Fix the devices_cnt
error check, which cares about only PCI structures and removes the
dma-remapping unit structure (dmaru) when the devices_cnt is zero
and include_all flag is not set.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

In dmar_dev_scope_init(), functions called under for_each_drhd_unit()/
for_each_rmrr_units() can delete the list entry under some error conditions.

So we should use list_for_each_entry_safe() for safe traversal.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

initialize the return value in dmar_parse_dev()
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Very early detection of the DMAR tables will setup fixmap mapping. For
parsing these tables later (while enabling dma and/or interrupt remapping),
early fixmap mapping shouldn't be used. Fix it by calling table detection
routines again, which will call generic apci_get_table() for setting up
the correct mapping.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

In irq_2_iommu_alloc() and set_irte_irq(), irq_to_desc or
irq_2_iommu pointers may not be allocated. So use the routines
which will allocate them if they are not already allocated.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

When sparse IRQs are enabled, it is not safe to assume an IRQ descriptor
exists for every possible IRQ.  This patch causes init_evtchn_cpu_bindings
to skip initialisation of IRQ descriptors which don't exist.
Signed-off-by: NAlex Nixon <alex.nixon@citrix.com>
Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

we are using 28bit pci (bus/dev/fn + 12 bits) as irq number, so the
cache for irq number should be 32 bit too.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

also print out irq no in /proc/interrups and /proc/stat in hex, so could
tell bus/dev/func.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

when CONFIG_HAVE_SPARSE_IRQ
preallocate some irq_2_iommu entries, and use get_one_free_irq_2_iomm to
get new one and link to irq_desc if needed.

else will use dyn_array or static array.

v2: <= nr_irqs fix
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

irq_timer_state[] is a NR_IRQS sized array that is a side-by array to
the real irq_desc[] array.

Integrate that field into the (now dynamic) irq_desc dynamic array and
save some RAM.

v2: keep the old way to support arch not support irq_desc
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
Get rid of irq_desc[] array assumptions.

Preallocate 32 irq_desc, and irq_desc() will try to get more.

( No change in functionality is expected anywhere, except the odd build
  failure where we missed a code site or where a crossing commit itroduces
  new irq_desc[] usage. )

v2: according to Eric, change get_irq_desc() to irq_desc()
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

convert them to nr_irqs.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Works on my test box with a quick test.
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

We shouldn't rely on "pnp_platform_devices" to tell us whether there
is a PNP RTC device.

I introduced "pnp_platform_devices", but I think it was a mistake.
All it tells us is whether we found any PNPBIOS or PNPACPI devices.
Many machines have some PNP devices, but do not describe the RTC
via PNP.  On those machines, we need to do the platform driver probe
to find the RTC.

We should just register the PNP driver and see whether it claims anything.
If we don't find a PNP RTC, fall back to the platform driver probe.

This (in conjunction with the arch/x86/kernel/rtc.c patch to add
a platform RTC device when PNP doesn't have one) should resolve
these issues:

    http://bugzilla.kernel.org/show_bug.cgi?id=11580
    https://bugzilla.redhat.com/show_bug.cgi?id=451188Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Reported-by: NRik Theys <rik.theys@esat.kuleuven.be>
Reported-by: shr_msn@yahoo.com.tw
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move rtc_wake_setup() from drivers/acpi/glue.c into the RTC driver
in drivers/rtc/rtc-cmos.c.

This removes the ordering constraint between the module_init(acpi_rtc_init)
and the cmos_do_probe() code that depends on it.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Once kernel configuration has CONFIG_HID turned on, let also all the
specialized drivers for quirky devices to be built (unless CONFIG_EMBEDDED is
specified), as usually users don't care that much which driver
gives them the functionality, but when they want generic support, they
probably want to have support for all the quirky devices as well.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This device is already handled by hid-apple driver, but the blacklist entry
was missing in generic driver.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This keyboard needs to reset the LEDS during probe.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Based on an original patch from Alexey Klimov <klimov.linux@gmail.com>,
against kernel version 2.6.27.

This device is already handled by radio-mr800 driver, and we therefore
want usbhid not to touch it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This keyboard needs to re-sync numlock after probing.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

USB should not be having it's own printk macros, so remove warn() and
use the system-wide standard of dev_warn() wherever possible.  In the
few places that will not work out, use a basic printk().
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

USB should not be having it's own printk macros, so remove info() and
use the system-wide standard of dev_info() wherever possible.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Similar to the existing IRCONTROL4 handling
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 8006479c introduced a spinlock in
input_dev->event_lock, which is locked when handling input events.
However, the hid-pidff driver sleeps when handling events as it waits for
reports being sent to the device before changing the report contents
again.
This causes a system lockup when trying to use force feedback with a PID
device, a regression introduced in 2.6.24 and 2.6.23.15.

Fix it by extracting the raw report data from struct hid_report
immediately when hid_submit_report() is called, therefore allowing
drivers to change the contents of struct hid_report immediately without
affecting the already-queued transfer.

In hid-pidff, re-add the removed usbhid_wait_io() to
pidff_erase_effect() instead, to prevent a full report queue from causing
the submission to fail, thus not freeing up device memory.
pidff_erase_effect() is not called while dev->event_lock is held.
Signed-off-by: NAnssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Since we have a real device bound to a driver, we may use struct
device for printing. Use dev_* functions instead of printks in
4 drivers.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

hid-ff.c now calls only pidff (generic driver), the special ones are now
in separate drivers. Invoke pidff on all non-special directly.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Move the force feedback processing into a separate module.

[jkosina@suse.cz: fix Kconfig texts a little bit]
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>