Adding processing for HID Sensor usage table as defined by
HID 1.12, Request #: HUTRR39, dated 05 May, 2011.
This driver uses HID driver framework to register, send and
receive events.
This uses MFD framework, so that actual processing for a
specific usage id can be done in a different driver. For
example an accelerometer driver can be a separate driver and
use the interface provided by this driver to register for
events.
Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Adding Intel and STM sensor hub in the list of drivers with
specialized driver.
Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added hysteresis to the list of channel info enumeration, shared
/separate bit defines and to postfix channel info strings.
Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Pull ARM SoC bug fixes from Olof Johansson:
"Mostly Renesas and Atmel bugfixes this time, targeting boot and build
problems. A couple of patches for gemini and kirkwood as well. On a
whole nothing very controversial."
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: gemini: fix the gemini build
ARM: shmobile: armadillo800eva: enable rw rootfs mount
ARM: Kirkwood: Fix 'SZ_1M' undeclared here for db88f6281-bp-setup.c
ARM: shmobile: mackerel: fixup usb module order
ARM: shmobile: armadillo800eva: fixup: sound card detection order
ARM: shmobile: marzen: fixup smsc911x id for regulator
ARM: at91/feature-removal-schedule: delay at91_mci removal
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source
ARM: mach-shmobile: armadillo800eva: Fix GPIO buttons descriptions
ARM: at91/dts: remove partial parameter in at91sam9g25ek.dts
ARM: at91/clock: fix PLLA overclock warning
ARM: at91: fix rtc-at91sam9 irq issue due to sparse irq support
ARM: at91: fix system timer irq issue due to sparse irq support
ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc
Fengguang Wu <fengguang.wu@intel.com> writes:
> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
> goto out;
>
> /* copy keys to file */
> - for (i = 0; i < env->envp_idx; i++)
> + dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
> + for (i = 0; i < env->envp_idx; i++) {
> + printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
> count += sprintf(&buf[count], "%s\n", env->envp[i]);
> + }
>
> Oops message, the env[] is again not properly initilized:
>
> [ 44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [ 44.069552] uevent 0 env[0]: (null)
This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away. I had a
hard time trying to disable it anyway ;-)
The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0. This is not true
if CONFIG_HOTPLUG is unset. So things like this end up overwriting
env->envp_idx because the array index is -1:
if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
len = input_print_modalias(&env->buf[env->buflen - 1],
sizeof(env->buf) - env->buflen,
dev, 0);
Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel. This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.
[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If xfernotready is received and there is no request in request_list then
REQUEST_PENDING flag must be set, so that next request in ep queue is executed.
In case of isoc transfer, if xfernotready is already elapsed and even first
request has not been queued to request_list, then issue END TRANSFER, so that
you can receive xfernotready again and can have notion of current microframe.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Earlier we used to check for ep->ep.desc to figure out if this ep has
already been enabled and if so, abort.
Ido Shayevitz removed the usb_endpoint_descriptor from private udc
structure 5a6506f00 ("usb: gadget: Update at91_udc to use
usb_endpoint_descriptor inside the struct usb_ep") but did not fix up
the ep_enable condition because _now_ the member is always true and we
can't check if this ep is enabled twice.
Cc: Ido Shayevitz <idos@codeaurora.org>
Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt>
Cc: <stable@kernel.org> # v3.5
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The driver was converted to the new start/stop interface in f3d8bf34c2
("usb: gadget: at91_udc: convert to new style start/stop interface").
I overlooked that the driver is overwritting the private data which is
used by the composite framework. The udc driver doesn't read it, it is
only written here.
Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt>
Cc: <stable@kernel.org> # v3.5
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Populate the resources for xhci afresh instead of directly using the
*struct resource* of core. *resource* structure has parent, sibling,
child pointers which should be filled only by resource API's. By
directly using the *resource* pointer of core in xhci, these parent,
sibling, child pointers are already populated even before
*platform_device_add* causing side effects.
Cc: stable@vger.kernel.org # v3.4, v3.5
Reported-by: Ruchika Kharwar <ruchika@ti.com>
Tested-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
dma_controller_create() in this MUSB DMA driver only regards 0 as a wrong IRQ
number, despite platform_get_irq_byname() that it calls returns -ENXIO in that
case. It leads to calling request_irq() with a negative IRQ number, and when it
naturally fails, the following is printed to the console:
request_irq -6 failed!
and the DMA controller is not created.
Fix this function to filter out the error values as well as 0.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On platform_device_add() failure, the TUSB6010 glue layer forgets to call
platform_device_put() -- probably due to a typo...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
when using musb_urb_enqueue to submit three urbs to the same endpoint, when
hep->hcpriv is NULL, qh will be allocated when the first urb is completed.
When the IRQ completes the next two urbs, qh->hep->hcpriv will be set to NULL.
Now the second urb get musb->lock and executes musb_schedule(), but
next_urb(qh) is NULL, so musb_start_urb will Oops.
[ balbi@ti.com : practically rewrote commit log so it makes sense ]
Signed-off-by: mayuzheng <myz147@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Without a reply for USB_DT_BOS the USB3 mode does not work since
448b6eb1 ("USB: Make sure to fetch the BOS desc for roothubs.).
Cc: stable@vger.kernel.org #v3.5
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If USB2 host controller probes fine but USB3 does not then we don't
remove the USB controller properly and lock up the system while the HUB
code will try to enumerate the USB2 controller and access memory which
is no longer available in case the dummy_hcd was compiled as a module.
This is a problem since 448b6eb1 ("USB: Make sure to fetch the BOS desc
for roothubs.) if used in USB3 mode because dummy does not provide this
descriptor and explodes later.
Cc: stable@vger.kernel.org # v3.5
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In case of ep0 out, if length is not aligned to maxpacket size then we use
dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have
alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to
issue cache sync function. In fact, cache sync function will bring wrong data
in request->buf from request->dma in this scenario.
So, cache sync function must not be executed in case of ep0 bounced.
Cc: <stable@vger.kernel.org> # v3.4 v3.5
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If f_fs.c and u_serial.c are combined together using #include, which has
been a common practice so far, the pr_vdebug macro is defined multiple
times. Define it only once.
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Pull a hwmon fix from Guenter Roeck:
"One patch, fixing DIV_ROUND_CLOSEST to support negative dividends.
While the changes are not in the drivers/hwmon directory, the problem
primarily affects hwmon drivers, and it makes sense to push the patch
through the hwmon tree."
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative dividends
Pull kbuild fixes from Michal Marek:
"These are two fixes that should go into 3.6. The link-vmlinux.sh one
is obvious.
The other one fixes make firmware_install with certain configurations,
where a file in the toplevel firmware tree gets installed first, and
$(INSTALL_FW_PATH)/$$(dir <file>) results in /lib/firmware/./, which
confuses make 3.82 for some reason."
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
firmware: fix directory creation rule matching with make 3.82
link-vmlinux.sh: Fix stray "echo" in error message
USB autosuspend suspends vhci_hcd. In this process hcd_bus_suspend gets
executed which puts vhci_hcd in suspend state and calls vhci_hub_status.
vhci_hub_status function checks hub state and if it is in suspend state,
usb_hcd_resume_root_hub gets executed which resumes hub and if hub is
idle, again autosuspend puts it in suspend state and this goes on.
vhci_hub_status should resume hub only when hub port is in suspend state
and hub port status has changed.
Signed-off-by: navin patidar <navinp@cdac.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Almost all of usbip assumes that the_controller->lock is acquired
before vdev->priv_lock. The exception is in
vhci_device_unlink_cleanup(), where locks are acquired in the
reverse order. This leads to occasional deadlocks.
Fixing this is a bit fiddly, as the_controller->lock can't be held
when calling usb_hcd_unlink_urb_from_ep() in the middle of the list
traversal. As I can't rule out concurrent callers to this function
(perhaps it is safe?), the code here becomes slightly uglier - when
locks are dropped in the middle so the list may have emptied itself
(not even list_for_each_entry_safe is safe here).
Signed-off-by: Bernard Blackham <b-linuxgit@largestprime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If "pool_id" is negative then it leads to a read before the start of the
array. If "cli_id" is out of bounds then it leads to a NULL dereference
of "cli". GCC would have warned about that bug except that we
initialized the warning message away.
Also it's better to put the parameter names into the function
declaration in the .h file. It serves as a kind of documentation.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pass the checks made by decode_getacl back to __nfs4_get_acl_uncached
so that it knows if the acl has been truncated.
The current overflow checking is broken, resulting in Oopses on
user-triggered nfs4_getfacl calls, and is opaque to the point
where several attempts at fixing it have failed.
This patch tries to clean up the code in addition to fixing the
Oopses by ensuring that the overflow checks are performed in
a single place (decode_getacl). If the overflow check failed,
we will still be able to report the acl length, but at least
we will no longer attempt to cache the acl or copy the
truncated contents to user space.
Reported-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Sachin Prabhu <sprabhu@redhat.com>
When we do FLR and save PCI config we did it in the wrong order.
The end result was that if a PCI device was unbind from
its driver, then binded to xen-pciback, and then back to its
driver we would get:
> lspci -s 04:00.0
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
13:42:12 # 4 :~/
> echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind
> modprobe e1000e
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:04:00.0: Disabling ASPM L0s L1
e1000e 0000:04:00.0: enabling device (0000 -> 0002)
xen: registering gsi 48 triggering 0 polarity 1
Already setup the GSI :48
e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e: probe of 0000:04:00.0 failed with error -2
This fixes it by first saving the PCI configuration space, then
doing the FLR.
Reported-by: Ren, Yongjie <yongjie.ren@intel.com>
Reported-and-Tested-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: stable@vger.kernel.org
The recent fix for the missing fine delayed time adjustment gives
strange error messages at each start of the playback stream, such as
delay: estimated 0, actual 352
delay: estimated 353, actual 705
These come from the sanity check in retire_playback_urb(). Before the
stream is activated via start_endpoints(), a few silent packets have
been already sent. And at this point the delay account is still in
the state as if the new packets are just queued, so the driver gets
confused and spews the bogus error messages.
For fixing the issue, we just need to check whether the received
packet is valid, whether it's zero sized or not.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: <stable@vger.kernel.org> [v3.5+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
full blown socket.
Since (41063e9 ipv4: Early TCP socket demux), we can have skb->sk
pointing to a timewait socket.
Same fix is needed in nfnetlink_log.
Diagnosed-by: Florian Westphal <fw@strlen.de>
Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The pause and resume operations indicate that the stream can be
un-paused/resumed from the exact location they were paused/suspended.
This is not true for this driver, the pause and suspend triggers share
the same code path with stop, they flush all pending DMA transfers.
This drops all pending samples. The pause_release/resume triggers are
the same as start, except that prepare won't be called beforehand,
nothing will be enqueued to the DMA engine and nothing will happen (no
audio). Removing the pause flag will let apps know that it isn't
supported. Removing the resume flag will cause user space to call
prepare and start instead of resume, so audio will continue playing when
the system wakes up.
Before removing the pause and resume flags, I tested this on an exynos
5250, using 'aplay -i'. Pause/un-pause leads to silence followed by a
write error. Suspend/resume testing led to the same result. Removing
the two flags fixes suspend/resume (since snd_pcm_prepare is called
again). And leads to a proper reporting of pause not supported.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
With the commit [2faa3bf: ALSA: hda - Rewrite the mute-LED hook with
vmaster hook in patch_sigmatel.c], the former Master volume control
was converted to PCM. This was supposed to be covered by the vmaster
control. But due to the lack of "PCM" slave definition, this didn't
happen properly. The patch fixes the missing entry.
Reported-by: Andrew Shadura <bugzilla@tut.by>
Cc: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
