The indirection is unecessary and broken in the current case that assigns the
handlers based on a not up-to-date pdev->msix_enabled value.
Route the handlers directly to the requisite core routines.
Todo: hook up error interrupt handling
Reported-by: Jeff Garzik <jeff@garzik.org>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Edmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This will be replaced by state machine tracepoints and should have been a part
of the logger removal.
Ran across scic_sds_port_decrement_request_count() which is an ugly macro
which silently hides accounting errors. Turn it into a WARN_ONCE to see if it
ever triggers.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Callbacks are already type unsafe, obfuscating things further by casting the
callback routine is less safe because now function argument number changes
will not be caught by the compiler.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Change names from upper to low letters
Signed-off-by: Henryk Dembkowski <henryk.dembkowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Remove duplicated license and header file includes that were leftover
from commit 4c1db2d0 "isci: consolidate core" (in the isci.git historical
branch).
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
scic_sds_stp_remote_device_ready_substate_handler_table[]
scic_sds_smp_remote_device_ready_substate_handler_table[]
c99 the struct initializers:
1/ allows grep to consistently show method name associations. The
naming is mostly consistent (except when it isn't) so this guarantees
coverage of present and future exception cases.
2/ let's the compiler guarantee that the state table array entry
correlates with an actual state name and detect accidental reordering or
deletion of states.
3/ allows default handler's to be identified easily
Signed-off-by: Henryk Dembkowski <henryk.dembkowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Change names from upper to low letters
Signed-off-by: Henryk Dembkowski <henryk.dembkowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
c99 the struct initializers (scic_sds_remote_device_state_handler_table[]):
1/ allows grep to consistently show method name associations. The
naming is mostly consistent (except when it isn't) so this guarantees
coverage of present and future exception cases.
2/ let's the compiler guarantee that the state table array entry
correlates with an actual state name and detect accidental reordering or
deletion of states.
3/ allows default handler's to be identified easily
Change names from upper to low letters
Cleanup empty lines
Signed-off-by: Henryk Dembkowski <henryk.dembkowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We no longer use the loglevel parameter. Remove.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Edmund Nadolski <edmund.nadolski@intel.com>
[rebased after killing SCI_IO_REQUEST_DATA_DIRECTION]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
It's an unnecessary typedef that mirrors the kernel's enum
dma_data_direction.
Also cleanup some long variable names along the way.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Support for the up to 2x4-port 6Gb/s SAS controllers embedded in the
chipset.
This is a snapshot of the first publicly available version of the driver,
commit 4c1db2d0 in the 'historical' branch.
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/isci.git historical
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Edmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:
hwmon: (pmbus) Auto-detect temp2 and temp3 registers/attributes
hwmon: (pmbus) Improve fan detection
hwmon: (adm1275) Free allocated memory if probe function fails
hwmon: (pmbus) Drop check for PMBus revision register in probe function
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
Revert "drm/nvc0: recognise 0xdX chipsets as NV_C0"
drm/radeon/kms: fix typo in cayman reg offset
drm/radeon/kms: use correct reg on fusion when reading back mem config
Commit e1866b33b1 (PM / Runtime: Rework
runtime PM handling during driver removal) forgot to update the
documentation in Documentation/power/runtime_pm.txt to match the new
code in drivers/base/dd.c. Update that documentation to match the
code it describes.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Replace reference to pm_runtime_idle_sync() in the driver core with
pm_runtime_put_sync() which is used in the code.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: apply HWSTAM writes to Ivy Bridge as well
drm/i915: move IRQ function table init to i915_irq.c
drm/i915/overlay: Fix unpinning along init error paths
drm/i915: Don't call describe_obj on NULL pointers
drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state
Additional temperature attribute support is easy to detect, so do it.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Cc: stable.kernel.org # 2.6.39
Some PMBus devices return no error when reading fan speed registers, but don't
really support fans. Strengthen fan detection by also checking if fan
configuration registers exist.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Cc: stable.kernel.org # 2.6.39
Probe function did not free allocated memory if it failed. Fix it.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Some PMBus devices do not support the PMBus revision register, so don't check
if it exists.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Cc: stable.kernel.org # 2.6.39
This patch (as1476) fixes a regression introduced by
fccf4e8620 (USB: Free bandwidth when
usb_disable_device is called). usb_disconnect() grabs the
bandwidth_mutex before calling usb_disable_device(), which calls down
indirectly to usb_set_interface(), which tries to acquire the
bandwidth_mutex.
The fix causes usb_set_interface() to return early when it is called
for an interface that has already been unregistered, which is what
happens in usb_disable_device().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 09ba0def (USB: fsl_udc_core: prepare for SoCs with
BE registers and descriptors) introduced build breakage
on ARM arch. Fix it by setting accessors using a static
inline function which is a nop when compiling the driver
for ARM arch.
Commit 2ea6698 (USB: fsl_udc_core: support device mode of
MPC5121E DR USB Controller) caused another breakage on ARM
by using flush_dcache_range(). Don't use it, convert to the
DMA API usage instead. USB2.0CV Halt Endpoint Test succeeds
on PPC. Tested both on ARM i.MX31 and mpc5121 PPC, also with
CONFIG_DMA_API_DEBUG enabled.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In an attempt to fix 38862 and 38863.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ.
xen/mmu: Fix for linker errors when CONFIG_SMP is not defined.
When 3.0 is released I believe the README should reflect the new
numbering.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Due to commit cdda911c34, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.
For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.
Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).
Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.
input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: Jeff Brown <jeffbrown@android.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While 0xffdc devices have their IR protocol hard-coded into the firmware
of the device, we have no known way of telling what it is if we don't
have the device's config byte already in the driver. Unknown devices
default to the imon native protocol, but might actually be rc6, so we
should set the driver up such that the user can load the rc6 keytable
from userspace and still have a working device ahead of its config byte
being added to the driver.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Another device with the 0xffdc device id, this one with 0x7e in the
config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case.
Reported-by: Filip Streibl <filip@streibl.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The comment says "wait 15ms", but the code says jiffies_to_msecs(15)
instead of msecs_to_jiffies(15). Fix that. Tested, works fine with both
rc5 and rc6 decode, in-kernel and via lirc userspace, with an HVR-1150.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.
To fix this, I've lowered the "send a reset event" logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.
CC: stable@kernel.org
CC: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's really no good reason not to just grab the desired IRQ at driver
init time, instead of every time the lirc device node is accessed. This
also improves the speed and reliability with which a serial transmitter
can operate, as back-to-back transmission attempts (i.e., channel change
to a multi-digit channel) don't have to spend time acquiring and then
releasing the IRQ for every digit, sometimes multiple times, if lircd
has been told to use the min_repeat parameter.
CC: devel@driverdev.osuosl.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...
Acked-by: Andy Walls <awalls@md.metrocast.net>
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.
The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.
This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.
Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mx1_camera_add_device() can return an uninitialized value of ret.
Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
[g.liakhovetski@gmx.de: modified the fix to remove "ret" completely]
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The usecase where, user allocates small size of buffer
through bootargs (video1_bufsize/video2_bufsize) and later from application
tries to set the format which requires larger buffer size, driver doesn't
check for insufficient buffer size and allows application to map extra buffer.
This leads to kernel crash, when user application tries to access memory
beyond the allocation size.
Added check in both mmap and reqbuf call back function,
and return error if the size of the buffer allocated by user through
bootargs is less than the S_FMT size.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With addition of media-controller framework, now we have various
device nodes (/dev/videoX) getting created, so hardcoding
minor number in video_register_device() is not recommended.
So let V4L2 framework choose free minor number for the device.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The omap_vout_new_crop() function has possible bug, uses uninitialized
variable "crop.width/height" which is actually output of the function.
Instead we should be using "try_crop.width/height" to calculate the
resizer value.
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Benjamin S. reported that he was unable to suspend his machine while
it had a cifs share mounted. The freezer caused this to spew when he
tried it:
-----------------------[snip]------------------
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
cifsd S ffff880127f7b1b0 0 1821 2 0x00800000
ffff880127f7b1b0 0000000000000046 ffff88005fe008a8 ffff8800ffffffff
ffff880127cee6b0 0000000000011100 ffff880127737fd8 0000000000004000
ffff880127737fd8 0000000000011100 ffff880127f7b1b0 ffff880127736010
Call Trace:
[<ffffffff811e85dd>] ? sk_reset_timer+0xf/0x19
[<ffffffff8122cf3f>] ? tcp_connect+0x43c/0x445
[<ffffffff8123374e>] ? tcp_v4_connect+0x40d/0x47f
[<ffffffff8126ce41>] ? schedule_timeout+0x21/0x1ad
[<ffffffff8126e358>] ? _raw_spin_lock_bh+0x9/0x1f
[<ffffffff811e81c7>] ? release_sock+0x19/0xef
[<ffffffff8123e8be>] ? inet_stream_connect+0x14c/0x24a
[<ffffffff8104485b>] ? autoremove_wake_function+0x0/0x2a
[<ffffffffa02ccfe2>] ? ipv4_connect+0x39c/0x3b5 [cifs]
[<ffffffffa02cd7b7>] ? cifs_reconnect+0x1fc/0x28a [cifs]
[<ffffffffa02cdbdc>] ? cifs_demultiplex_thread+0x397/0xb9f [cifs]
[<ffffffff81076afc>] ? perf_event_exit_task+0xb9/0x1bf
[<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
[<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
[<ffffffff810444a1>] ? kthread+0x7a/0x82
[<ffffffff81002d14>] ? kernel_thread_helper+0x4/0x10
[<ffffffff81044427>] ? kthread+0x0/0x82
[<ffffffff81002d10>] ? kernel_thread_helper+0x0/0x10
Restarting tasks ... done.
-----------------------[snip]------------------
We do attempt to perform a try_to_freeze in cifs_reconnect, but the
connection attempt itself seems to be taking longer than 20s to time
out. The connect timeout is governed by the socket send and receive
timeouts, so we can shorten that period by setting those timeouts
before attempting the connect instead of after.
Adam Williamson tested the patch and said that it seems to have fixed
suspending on his laptop when a cifs share is mounted.
Reported-by: Benjamin S <da_joind@gmx.net>
Tested-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
When failing to start the camera we should disable the queue again, to
rollback into the same initial state. Otherwise re-trying will always
hit -EBUSY
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When freeing memory for the video buffers also remove them from the
irq & main queues.
This fixes an oops when doing the following:
open ("/dev/video", ..)
VIDIOC_REQBUFS
VIDIOC_QBUF
VIDIOC_REQBUFS
close ()
As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If a streaming interface has no supported format, the driver won't
create a video device for the associated terminal. Fix an oops by
ignoring that terminal when creating links between entities.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Entities associated with video device nodes are unregistered in
video_unregister_device(). This destroys the entity even though it can
still be accessed through open video device nodes.
Move the media_device_unregister_entity() call from
video_unregister_device() to v4l2_device_release() to ensure that the
entity isn't unregistered until the last reference to the video device
is released.
Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those
functions were designed for subdevs, to avoid a parent module from being
removed while still accessible through board code. They're not currently
needed for video device nodes, and will oops when a hotpluggable device
is disconnected during streaming, as media_entity_put() called in
v4l2_device_release() tries to access entity->parent->dev->driver which
is set to NULL when the device is disconnected.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
