Jean Delvare reported bonding on top of 3c59x adapters was not detecting
network cable removal fast enough.
3c59x indeed uses a 60 seconds timer to check link status if carrier is
on, and 5 seconds if carrier is off.
This patch reduces timer period to 5 seconds if device is a bonding
slave.
Reported-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5a698af53f (bond: service netpoll arp queue on master device)
tested IFF_SLAVE flag against dev->priv_flags instead of dev->flags
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: WANG Cong <amwang@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that USB 3.0 hub remote wakeup on port status changes is enabled,
and USB 3.0 device remote wakeup is handled in the USB core properly,
let's turn on auto-suspend for all USB 3.0 hubs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch takes care of the race condition between the Function Wake
Device Notification and the auto-suspend timeout for this situation:
Roothub
| (U3)
hub A
| (U3)
hub B
| (U3)
device C
When device C signals a resume, the xHCI driver will set the wakeup_bits
for the roothub port that hub A is attached to. However, since USB 3.0
hubs do not set a link state change bit on device-initiated resume, hub
A will not indicate a port event when polled. Without this patch, khubd
will notice the wakeup-bits are set for the roothub port, it will resume
hub A, and then it will poll the events bits for hub A and notice that
nothing has changed. Then it will be suspended after 2 seconds.
Change hub_activate() to look at the port link state for each USB 3.0
hub port, and set hub->change_bits if the link state is U0, indicating
the device has finished resume. Change the resume function called by
hub_events(), hub_handle_remote_wakeup(), to check the link status
for resume instead of just the port's wakeup_bits.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Refactor the code to check for a remote wakeup on a port into its own
function. Keep the behavior the same, and set connect_change in
hub_events if the device disconnected on resume. Cleanup references to
hdev->children[i-1] to use a common variable.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs.
USB 2.0 hubs, once they have remote wakeup enabled, will always send
remote wakes when anything changes on a port.
However, USB 3.0 hubs have a per-port remote wake up policy that is off
by default. The Set Feature remote wake mask can be changed for any
port, enabling remote wakeup for a connect, disconnect, or overcurrent
event, much like EHCI and xHCI host controller "wake on" port status
bits. The bits are cleared to zero on the initial hub power on, or
after the hub has been reset.
Without this patch, when a USB 3.0 hub gets suspended, it will not send
a remote wakeup on device connect or disconnect. This would show up to
the user as "dead ports" unless they ran lsusb -v (since newer versions
of lsusb use the sysfs files, rather than sending control transfers).
Change the hub driver's suspend method to enable remote wake up for
disconnect, connect, and overcurrent for all ports on the hub. Modify
the xHCI driver's roothub code to handle that request, and set the "wake
on" bits in the port status registers accordingly.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB 3.0 bus specification introduces a new type of power management
called function suspend. The idea is to be able to suspend different
functions (i.e. a scanner or an SD card reader on a USB printer)
independently. A device can be in U0, but have one or more functions
suspended. Thus, signaling a function resume with the standard device
remote wake signaling was not possible.
Instead, a device will (without prompt from the host) send a "device
notification" for the function remote wake. A new Set Feature Function
Remote Wake was developed to turn remote wake up on and off for each
function.
USB 3.0 devices can still go into device suspend (U3), and signal a
remote wakeup to bring the link back into U1. However, they now use the
function remote wake device notification to allow the host to know which
function woke the device from U3.
The spec is a bit ambiguous about whether a function is allowed to
signal a remote wakeup if the function has been enabled for remote
wakeup, but not placed in function suspend before the device is placed
into U3.
Section 9.2.5.1 says "Suspending a device with more than one function
effectively suspends all the functions within the device." I interpret
that to mean that putting a device in U3 suspends all functions, and
thus if the host has previously enabled remote wake for those functions,
it should be able to signal a remote wake up on port status changes.
However, hub vendors may have a different interpretation, and it can't
hurt to put the function into suspend before putting the device into U3.
I cannot get an answer out of the USB 3.0 spec architects about this
ambiguity, so I'm erring on the safe side and always suspending the
first function before placing the device in U3. Note, this code should
be fixed if we ever find any USB 3.0 devices that have more than one
function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup. In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.
This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe. It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far. FIXME if
that turns out to change later.
After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup. The host can then put any other functions back
into function suspend. Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI roothubs go through slightly different port state machines when
either a device initiates a remote wakeup and signals resume, or when
the host initiates a resume.
According to section 4.19.1.2.13 of the xHCI 1.0 spec, on host-initiated
resume, the xHC port state machine automatically goes through the U3Exit
state into the U0 state, setting the port link state change (PLC) bit in
the process.
When a device initiates resume, the xHCI port state machine goes into
the "Resume" state and sets the PLC bit. Then the xHCI driver writes U0
into the port link state register to transition the port to U0 from the
Resume state.
We can't be sure the device is actually in the U0 state until we receive
the next port status change event with the PLC bit set. We really don't
want khubd to be polling the roothub port status bits until the device
is really in U0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
when commit 3528c58 (OMAP: omap_device: when
building return platform_device instead of
omap_device) started returning a platform_device
instead of a omap_device pointer when building
a device, it failed to convert all users introducing
a compile warning when building
arch/arm/mach-omap2/usb-host.c.
This patch fixes that warning.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arm_memblock_steal() is not suppose to be used outside ->reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of ->reserve callback to fix the it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
'poll' was a debugging option, but turning it on these days leads to
kernel panic. Remove it.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121 -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add unicast steering entries to resource tracker.
Do qp_detach also for these entries when VF doesn't shut down gracefully.
Otherwise there is leakage of these resources, since they are not tracked.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
mlx4_multicast_attach/detach() should use always MLX4_MC_STEER flag
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
mlx4_uc_steer_add/release() should not add MLX4_UC_STEER flag to gid.
It is added in mlx4_unicast_attach/detach().
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
mlx4_qp_attach/detach_common() don't use hash variable, move it to find_entry()
static find_entry() in mcg.c doesn't use steer argument
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove unnecessary field high_prios from mlx4_steer struct and initialization
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
When adding new unicast steer entry, before moving qp to state ready,
actually before calling mlx4_RST2INIT_QP_wrapper(), there were added
a lot of entries with local_qpn=0 into radix tree.
This fact impacted the get_res() function and proper functioning
of resource tracker in addition to adding trash entries into radix tree.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@melllanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
When passing MLX4_UC_STEER=1 it was translated to value 2
after mlx4_QP_ATTACH_wrapper. Therefore in new_steering_entry()
unicast steer entries were added to index 2 of array of size 2.
Fixing this bug by shift right to one position.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.co.il>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
OMAP4 cpuidle driver is reporting the state requested by governor
rather than the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@ti.com>
opp_find_freq_ceil and opp_get_voltage are documented as requiring
rcu_lock to be held. So hold it.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Intel has a PCI USB xhci host controller on a new platform. It doesn't
have a line IRQ definition in BIOS. The Linux driver refuses to
initialize this controller, but Windows works well because it only depends
on MSI.
Actually, Linux also can work for MSI. This patch avoids the line IRQ
checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver
to try to enable MSI or MSI-X first. It will fail the probe if MSI
enabling failed and there's no legacy PCI IRQ.
This patch should be backported to kernels as old as 2.6.32.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
status has to be set to STREAMING before the streaming worker is
queued. hdpvr_transmit_buffers() will exit immediately otherwise.
Reported-by: Joerg Desch <vvd.joede@googlemail.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Basically all small fixes suited as rc4: a few HD-audio regression fixes,
a stable fix for an old Dell laptop with intel8x0, and a simple fix for
ASoC fsi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJPOjNOAAoJEGwxgFQ9KSmkVq4P/j3wXouR03as78Y97WtvO3xw
S6dFyiR12oNVhEFcSZ/nZxVt7NwxeorhTkuM4UsvmrWYZVMRGYbYCKiIBMwzovnF
ln2toFEf19uy2vZ66qOdz3GyCbjNCq2kXEOFgD9z+9ICQzn35nDh833NMJ4thDKQ
QemDy+pU0EChm//O32kuA0OZ0ZR8EDIQhwmPIBEmWzxD0jq95ozbKzxFtXUpnNhJ
N4iubolY2i2c40YlyPWu9m7gyuAC4oxEFa4/GXrBUm1Yxt5odYaVllYru0OZe+vh
1bdobG7SQg8Vs/D8oRwY2gbZV10s6kU98Rgl1q2GVbHEtOC5dI2jA2a6Vx+Utdof
0uwvk7P+FhyW0VFOkQDwMbs1K3bEoQfrtA+pU/IzvLtWoL1PuzLdEfPuN2G7llpV
sxJcnrl2/10A3YkmOTGiIr0aR1C/HcJ4NWK/lbnr3c5hPRxoqmRR7BhWrWFkiMlu
yf2KOVZ3T7MZCHCmFZmSTDvUx/KEI+VDYLLIg1/Edw4v8Wp14glPFziSpMrgz1mE
qLVpvP4uDG2DtFaTMhYjjQLPyWca317fJ4ILxLs6g6Kn7nuM3EXZo4FNNwJ3m6Rd
HQxspsnD8YeE1muUpBKGhgcrx+6e9t3aY3CkWOfqweYP70Clf5yDrkGabaDFmXCT
wqfiGvrrKTWejCAHoyaw
=Dtrw
-----END PGP SIGNATURE-----
Merge tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
sound fixes for 3.3-rc4
Basically all small fixes suited as rc4: a few HD-audio regression fixes,
a stable fix for an old Dell laptop with intel8x0, and a simple fix for
ASoC fsi.
* tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: intel8x0: Fix default inaudible sound on Gateway M520
ALSA: hda - Fix silent speaker output on Acer Aspire 6935
ALSA: hda - Fix initialization of secondary capture source on VT1705
ASoC: fsi: fixup fsi_pointer() calculation method
ALSA: hda - Fix mute-LED VREF value for new HP laptops
Instead of requiring that users of perf_record_opts set
.sample_id_all_avail to true, just invert the logic, using
.sample_id_all_missing, that doesn't need to be explicitely initialized
since gcc will zero members ommitted in a struct initialization.
Just like the newly introduced .exclude_{guest,host} feature test.
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-ab772uzk78cwybihf0vt7kxw@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Just fall back to resetting those fields, if set, warning the user that
that feature is not available.
If guest samples appear they will just be discarded because no struct
machine will be found and thus the event will be accounted as not
handled and dropped, see 0c09571.
Reported-by: Namhyung Kim <namhyung@gmail.com>
Tested-by: Joerg Roedel <joerg.roedel@amd.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-vuwxig36mzprl5n7nzvnxxsh@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The current renesas_usbhs driver triggers
BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102
with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from
an atomic (tasklet) context, which is not supported by the shdma dmaengine
driver. Fix it by switching to a work.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
list.h already provide helpers to find the first entry and to move list
nodes to the tail of another list. This patch simply uses those helpers,
no functional changes.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
- Add missing DFP6 connection state handling
- crtc routing bits not used on DCE4+
Noticed by sylware on phoronix.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Silly bad return path.
Reported-and-Tested-by: Mikko Vinni
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
BugLink: https://bugs.launchpad.net/bugs/930842
The reporter states that audio is inaudible by default without muting
'External Amplifier'. Add a quirk to handle his SSID so that changing
the control is not necessary.
Reported-and-tested-by: Benjamin Carlson <elderbubba0810@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPOZeyAAoJEBus8iNuMP3duOcP/AjGPC2hX+TH0SXYvZnTMUud
gWM8qBKE3DS887G3eX4zqt/1Kkhw8AA47H+28NaqEATVHBmaPXxRw+phnEFcU3ZC
h0LzO5gMtx3RcfwisHtRNTMf4Ps74/vjaYMqViknWMRxU7gtSvtCvmoOJqSvBBAy
J2a3//jWPCGyKQ1lc4diT/vr5f+YNi9VHlMDeauYS86wCslvi+cPgBsrVMz9rYsF
hXKnbMowNr5G50Gnh20tMwkYFmXgbGFkQIoZzWpik5O4fr1lk36ftCOjdLSVSNqb
CY470PUjEEy75wZigQ9gO+Dxc4/iUgMyC5R0qKEYI60cEOrXqurt3i+DqRvJwS9+
nqyJnoX46kzUbYj9+PAdtYudZc4mO0MMqSiF5iTB6uAQna3Cw6pCHjEY0Aw6VhdM
1KrkF0GhPjKl0uDM2ScYlW7965aNpjwlSVEwn7VPmowfMCCRv7tFR1n6dMhgtkhB
TrZBs4IRHeONa/pLmf1GGeOGb8Ij7Iz5b4ggulqmHJrcLpt7WfWvWfT7bhR59yMx
QEjCT1GPu8WUY8BgF37JwhVmI96+3NH5GPJmrA/DPIftmXd+e9iQS3DhdunGpCfu
E0pCs/xKtQZ96CYAtPeb7J2QlzDeS+e/8NcazQeqgyg3KT6NA4wN+k5zSreekzyS
bTuf9uJ6HWy7CURbP58c
=xHrB
-----END PGP SIGNATURE-----
Merge tag 'asoc-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
A simple fix from Morimoto-san for the pointer() operation in the FSI
driver.
* git://git.samba.org/sfrench/cifs-2.6:
cifs: don't return error from standard_receive3 after marking response malformed
cifs: request oplock when doing open on lookup
cifs: fix error handling when cifscreds key payload is an error
This updates the sha512 fix so that it doesn't cause excessive stack
usage on i386. This is done by reverting to the original code, and
avoiding the W duplication by moving its initialisation into the loop.
As the underlying code is in fact the one that we have used for years,
I'm pushing this now instead of postponing to the next cycle.
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: sha512 - Avoid stack bloat on i386
crypto: sha512 - Use binary and instead of modulus
DRIVER_HALT is a driver state that was originally
defined as a #define statement. This patch moves
it to the LedEvents type as an enumerated
value for the purpose of removing a compile time warning:
drivers/staging/bcm/led_control.c: In function ‘LEDControlThread’:
drivers/staging/bcm/led_control.c:817:3: warning: case value ‘255’ not in enumerated type ‘LedEventInfo_t’ [-Wswitch]
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zram accepts number of devices to be created
as a module parameter. This was renamed from
num_devices to zram_num_devices (without updating
the documentation!) since num_devices was declared
as a non-static global variable, polluting the global
namespace. Now, we declare it as a static variable
and revert back the name change.
The documentation (zram.txt) already mentions
num_devices as the module parameter name.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a small evtest like application to monitor events generated by an IIO
device. The application can be used as an example on how to listen for IIO
events and also is usful for testing and debugging device drivers which
generate IIO events.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add macros for extracting whether the event is for a differential channel and
the second channel number from the event code. These were the only two fields
which did not have such an macro yet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We name this field "chan" throughout IIO with the exception of this one macro.
Rename it to be more consistent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 43ba1100 ("staging:iio:events: Use waitqueue lock to protect event
queue") removed the event_list_lock field from the iio_event_interface struct,
but missed to remove the same field from the documentation for that function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Declaration between .h and .c was mismatched. Matched both declara
tions avoiding an sparse check error.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
acpi_size is u32 or u64 depending on architecture. Cast it to
unsigned long and use %lu for printing.
This fix following build warning:
drivers/staging/quickstart/quickstart.c: In function ‘quickstart_acpi_ghid’:
drivers/staging/quickstart/quickstart.c:212:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘acpi_size’ [-Wformat]
Signed-off-by: Szymon Janc <szymon@janc.net.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
