Instead of checking if we are associated when suspending with wowlan
enabled in the interface iterator, allow it to return an unassociated
vif and move the check to the main suspend function. This will be
needed by netdetect, since it should also work when we are not
associated but the vif is active.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Take the WoWLAN handling code out of the main suspend function,
dividing it into three parts: get_config (which is used before the
firmware is switched), switch_to_d3 (which handles the rebooting of
the hardware with the D3 firmware) and config (which configures the D3
firmware for WoWLAN operation). This is necessary to prepare for the
net-detect implementation, which will use only the switch_to_d3 part
of this flow.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
mac80211 will never call rate_control_tx_status with a NULL
pointer for sta. Remove the superfluous check. This check
misled smatch.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The current TLC isn't optimized for low latency and some devices
have issues with MIMO. This kind of combo creates latency issues.
Allow to temporarily disable MIMO for tests in order to solve
the latency issues without the added complexity of MIMO.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
These patches:
86a349a28b ("perf/x86/intel: Add Broadwell core support")
c46e665f03 ("perf/x86: Add INST_RETIRED.ALL workarounds")
fdda3c4aac ("perf/x86/intel: Use Broadwell cache event list for Haswell")
introduced magic constants and unexplained changes:
https://lkml.org/lkml/2014/10/28/1128https://lkml.org/lkml/2014/10/27/325https://lkml.org/lkml/2014/8/27/546https://lkml.org/lkml/2014/10/28/546
Peter Zijlstra has attempted to help out, to clean up the mess:
https://lkml.org/lkml/2014/10/28/543
But has not received helpful and constructive replies which makes
me doubt wether it can all be finished in time until v3.18 is
released.
Despite various review feedback the author (Andi Kleen) has answered
only few of the review questions and has generally been uncooperative,
only giving replies when prompted repeatedly, and only giving minimal
answers instead of constructively explaining and helping along the effort.
That kind of behavior is not acceptable.
There's also a boot crash on Intel E5-1630 v3 CPUs reported for another
commit from Andi Kleen:
e735b9db12 ("perf/x86/intel/uncore: Add Haswell-EP uncore support")
https://lkml.org/lkml/2014/10/22/730
Which is not yet resolved. The uncore driver is independent in theory,
but the crash makes me worry about how well all these patches were
tested and makes me uneasy about the level of interminging that the
Broadwell and Haswell code has received by the commits above.
As a first step to resolve the mess revert the Broadwell client commits
back to the v3.17 version, before we run out of time and problematic
code hits a stable upstream kernel.
( If the Haswell-EP crash is not resolved via a simple fix then we'll have
to revert the Haswell-EP uncore driver as well. )
The Broadwell client series has to be submitted in a clean fashion, with
single, well documented changes per patch. If they are submitted in time
and are accepted during review then they can possibly go into v3.19 but
will need additional scrutiny due to the rocky history of this patch set.
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1409683455-29168-3-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When events occurs while no one is listening to the node (hid->open == 0
and usb_kill_urb() called) some events are still stacked somewhere in
the USB (kernel or device?) stack. When the node gets reopened, these
events are drained, and this results in spurious touch down/up, or mouse
button clicks.
The problem was spotted with touchscreens in fdo bug #81781 [1], but it
actually occurs with any mouse using hid-generic or touchscreen.
A way to reproduce it is to call:
$ xinput disable 9 ; sleep 5 ; xinput enable 9
With 9 being the device ID for the touchscreen/mouse. During the "sleep",
produce some touch events or click events. When "xinput enable" is called,
at least one click is generated.
This patch tries to fix this by draining the queue for 50 msec and
during this time frame, not forwarding these old events to the hid layer.
Hans completed the explanation:
"""
Devices like mice (basically any hid device) will have a fifo
on the device side, when we stop submitting urbs to get hid reports from
it, that fifo will fill up, and when we resume we will get whatever
is there in that fifo.
"""
[1] https://bugs.freedesktop.org/show_bug.cgi?id=81781
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The commit which introduced TransducerSerialNumber (368c966) is missing
two crucial implementation details. Firstly, the commit does not set the
type/code/bit/max fields as expected later down the code which can cause
the driver to crash when a tablet with this usage is connected. Secondly,
the call to 'set_bit' causes MSC_PULSELED to be sent instead of the
expected MSC_SERIAL. This commit addreses both issues.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The TK820 presents both a keyboard and a touchpad on the same
physical (and logical device). Use the generic hid-input
processing for the keyboard part. The keyboard input device is created
when the receiver is plugged in, so no events are missed on connect.
When the device actaully connects, we can set it to use the raw
multitouch reporting to have a consistent user experience accross
all Logitech touchpads.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This touchpad differs from the T650 in several ways:
- the resolution is not correctly returned by the device
- it presents physical buttons, so the button flag in the raw touch report
is not filled.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
All the bits are now in place to add the support of the
Touchpad T650.
The creation/population of the input device is delayed until
the device is ready.
The T650 uses the special HID++ reporting protocol, so activate
this on connect.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that the receiver forwards the connect/disconnect events, we can
know when the device is available to communicate with us.
When it is ready, we can for instance retrieve its full name, which
guarantee that we always have the same name for the DJ device (the DJ
name is somewhat shorter than the HID++ name).
This mechanism is mandatory for the touchpads line, which has the
min/max information stored in the device. This information can only
be retrieved when the device is connected. So we can not populate
the input device until we are sure that the device is connected.
This patch creates a new input device for such devices. However,
this input is not bound to hid directly, so the various drivers
which wants to use it are required to process completely the
incoming reports in .raw_event().
Note that the patch in itself just adds the bits for the next
ones, and this feature is disabled by default.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The receiver can send HID++ notifications to the DJ devices when the
physical devices are connected/disconnected.
Enable this feature by default.
This command uses a HID++ command instead of a DJ one, so use a direct
call to usbhid instead of using logi_dj_recv_send_report()
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The names of the DJ devices are stored in the receiver. These names
can be retrieved through a HID++ command. However, the protocol says
that you have to ask the receiver for that, not the device iteself.
Introduce a special case in the DJ handling where a device can request
its unifying name, and when such a name is given, forward it also to
the corresponding device.
On the HID++ side, the receiver talks only HID++ 1.0, so we need to
implement this part of the protocol in the module.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID++ is a Logitech-specific protocol for communicating with HID
devices. DJ devices implement HID++, and so we can add the HID++
collection in the report descriptor and forward the incoming
reports from the receiver to the appropriate DJ device.
The same can be done in the other way, if someone calls a
.raw_request(), we can forward it to the correct dj device
by overriding the device_index in the HID++ report.
Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Devices connected through the Logitech Wireless Receiver are HID++ devices.
We can handle them here to benefit from this new module and activate
enhaced support of the various wireless touchpad or mice with touch
sensors on them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Logitech devices use a vendor protocol to communicate various
information with the device. This protocol is called HID++,
and an exerpt can be found here:
https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=shar
The main difficulty which is related to this protocol is that
it is a synchronous protocol using the input reports.
So when we want to get some information from the device, we need
to wait for a matching input report.
This driver introduce this capabilities to be able to support
the multitouch mode of the Logitech Wireless Touchpad T651
(the bluetooth one). The multitouch data is available directly
from the mouse input reports, and we just need to query the device
on connect about its caracteristics.
HID++ and the touchpad features has a specific reporting mode
which uses pure HID++ reports, but Logitech told us not to use
it for this specific device. During QA, they detected that
some bluetooth input reports where lost, and so the only supported
mode is the pointer mode.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no point in keeping the header in a separate file, nobody
but hid-logitech-dj should have access to its content.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Several benefits here:
- we can drop the macro is_dj_device: I never been really conviced by
this macro as we could fall into a null pointer anytime. Anyway time
showed that this never happened.
- we can simplify the hid driver logitech-djdevice, and make it aware
of any new receiver VID/PID.
- we can use the Wireless PID of the DJ device as the product id of the
hid device, this way the sysfs will differentiate between different
DJ devices.
Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This allows the transport layer (I have in mind hid-logitech-dj and uhid)
to set the group before it is added to the hid bus. This way, it can
bypass the hid_scan_report() call, and choose in advance which driver
will handle the newly created hid device.
Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
While merging wacom from the input to the hid tree, some
comments have been duplicated. We can also integrate the
test for Synaptics devices in the switch case below, so
it is clear that there will be only one place for such
quirks.
No functional changes are expected in this commit.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch fixes the following errors and warnings
identified by checkpatch.pl:
WARNING: please, no spaces at the start of a line
814: FILE: ft1000_hw.c:814:
tempword = ft1000_read_reg(dev, FT1000_REG_DOORBELL);$
WARNING: please, no spaces at the start of a line
815: FILE: ft1000_hw.c:815:
i=0;$
ERROR: spaces required around that '=' (ctx:VxV)
815: FILE: ft1000_hw.c:815:
i=0;
WARNING: please, no spaces at the start of a line
816: FILE: ft1000_hw.c:816:
while (tempword & FT1000_DB_DPRAM_TX) {$
ERROR: code indent should use tabs where possible
817: FILE: ft1000_hw.c:817:
mdelay(10);$
WARNING: please, no spaces at the start of a line
817: FILE: ft1000_hw.c:817:
mdelay(10);$
ERROR: code indent should use tabs where possible
818: FILE: ft1000_hw.c:818:
i++;$
WARNING: please, no spaces at the start of a line
818: FILE: ft1000_hw.c:818:
i++;$
ERROR: code indent should use tabs where possible
819: FILE: ft1000_hw.c:819:
if (i==10) {$
WARNING: please, no spaces at the start of a line
819: FILE: ft1000_hw.c:819:
if (i==10) {$
WARNING: suspect code indent for conditional statements (8, 12)
819: FILE: ft1000_hw.c:819:
if (i==10) {
spin_unlock_irqrestore(&info->dpram_lock, flags);
ERROR: spaces required around that '==' (ctx:VxV)
819: FILE: ft1000_hw.c:819:
if (i==10) {
ERROR: code indent should use tabs where possible
820: FILE: ft1000_hw.c:820:
spin_unlock_irqrestore(&info->dpram_lock, flags);$
WARNING: please, no spaces at the start of a line
820: FILE: ft1000_hw.c:820:
spin_unlock_irqrestore(&info->dpram_lock, flags);$
ERROR: code indent should use tabs where possible
821: FILE: ft1000_hw.c:821:
return;$
WARNING: please, no spaces at the start of a line
821: FILE: ft1000_hw.c:821:
return;$
ERROR: code indent should use tabs where possible
822: FILE: ft1000_hw.c:822:
}$
WARNING: please, no spaces at the start of a line
822: FILE: ft1000_hw.c:822:
}$
ERROR: code indent should use tabs where possible
823: FILE: ft1000_hw.c:823:
tempword = ft1000_read_reg(dev, FT1000_REG_DOORBELL);$
WARNING: please, no spaces at the start of a line
823: FILE: ft1000_hw.c:823:
tempword = ft1000_read_reg(dev, FT1000_REG_DOORBELL);$
WARNING: please, no spaces at the start of a line
824: FILE: ft1000_hw.c:824:
}$
Signed-off-by: Nicky Chorley <ndchorley@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The below warning is fixed:
drivers/staging/gs_fpgaboot/gs_fpgaboot.c: In function ‘gs_load_image’:
drivers/staging/gs_fpgaboot/gs_fpgaboot.c:196:58: warning: declaration of ‘file’ shadows a global declaration [-Wshadow]
drivers/staging/gs_fpgaboot/gs_fpgaboot.c:45:14: warning: shadowed declaration is here [-Wshadow]
by renaming file function argument of gs_load_image with fw_file.
Signed-off-by: Devendra Naga <devendranaga4@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
the following compiler warning has been fixed:
drivers/staging/gs_fpgaboot/gs_fpgaboot.c: In function ‘gs_read_bitstream’:
drivers/staging/gs_fpgaboot/gs_fpgaboot.c:160:6: warning: variable ‘size’ set but not used [-Wunused-but-set-variable]
CC drivers/staging/gs_fpgaboot/io.o
LD drivers/staging/gs_fpgaboot/gs_fpga.o
LD drivers/staging/gs_fpgaboot/built-in.o
by removing the size variable.
Signed-off-by: Devendra Naga <devendranaga4@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
unused variables are removed. These variables were only assigned some
values and after that they were never being used. So they are safe to
be removed , and it has been build tested.
I left a call to r8712_read32(padapter, TCR) and
r8712_read8(padapter, SDIO_HCPWM) .
r8712_read32() and r8712_read8() is ultimately calling usb_read32()
and usb_read8() respectively. and they are again calling
r8712_usbctrl_vendorreq().
this r8712_usbctrl_vendorreq() is communicating through the usb bus
and is sending and receiving the control msg.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We are going to have more pinctrl drivers for Intel hardware so separate
all our pin controller drivers to own directory.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
struct firmware::data has type const u8*, as does *ppmappedfw, so the
cast to u8* is unnecessary and slightly confusing.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes the 2 checkpatch.pl warnings:
WARNING: line over 80 characters
Signed-off-by: Brian Vandre <bvandre@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Define the helper function rtsx_enable_pcie_intr to shorten the
rtsx_reset_chip code and get rid of the LONG_LINE checkpatch warnings.
Signed-off-by: Fabio Falzoi <fabio.falzoi84@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpente@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Define the helper function rtsx_reset_aspm to shorten the
rtsx_reset_chip code and get rid of the LONG_LINE checkpatch warnings.
Signed-off-by: Fabio Falzoi <fabio.falzoi84@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpente@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove following checkpatch.pl error from ft1000/ft1000-usb/ft1000_debug.c
ERROR: do not initialise statics to 0 or NULL
Signed-off-by: Chen Weixiang <weixiang.chen@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A macro doing some arithmetic to calculate a register offset, did not
contain an argument to the macro in parentheses, potentially leading to
unexpected results when using that macro with arithmetic expressions as
argument.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the following errors identified by
checkpatch.pl:
ERROR: do not use C99 // comments
36: FILE: card.h:36:
//
ERROR: do not use C99 // comments
37: FILE: card.h:37:
// Loopback mode
ERROR: do not use C99 // comments
38: FILE: card.h:38:
//
ERROR: do not use C99 // comments
39: FILE: card.h:39:
// LOBYTE is MAC LB mode, HIBYTE is MII LB mode
ERROR: do not use C99 // comments
41: FILE: card.h:41:
#define CARD_LB_MAC MAKEWORD(MAC_LB_INTERNAL, 0) // PHY must ISO, avoid MAC loopback packet go out
ERROR: do not use C99 // comments
44: FILE: card.h:44:
#define DEFAULT_MSDU_LIFETIME 512 // ms
ERROR: do not use C99 // comments
45: FILE: card.h:45:
#define DEFAULT_MSDU_LIFETIME_RES_64us 8000 // 64us
ERROR: do not use C99 // comments
47: FILE: card.h:47:
#define DEFAULT_MGN_LIFETIME 8 // ms
ERROR: do not use C99 // comments
48: FILE: card.h:48:
#define DEFAULT_MGN_LIFETIME_RES_64us 125 // 64us
ERROR: do not use C99 // comments
175: FILE: card.h:175:
#endif // __CARD_H__
Signed-off-by: Nicky Chorley <ndchorley@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both sides have type const struct iw_handler_def*, so the cast is
unnecessary and confusing.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch.pl "space prohibited after that open parenthesis '('" errors
Signed-off-by: Greg Donald <gdonald@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes "line over 80 characters" warnings found in the first patch by breaking u4bAcParam's calculation down into a few steps.
Signed-off-by: Koray Gulcu <koray.gulcu@ozu.edu.tr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the following endianness warnings found by sparse running with CF=-D__CHECK_ENDIAN__:
drivers/staging/rtl8192u/r8192U_core.c:1794:10: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1794:10: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1794:10: got int
drivers/staging/rtl8192u/r8192U_core.c:1794:13: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1794:13: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1794:13: got int
drivers/staging/rtl8192u/r8192U_core.c:1794:16: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1794:16: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1794:16: got int
drivers/staging/rtl8192u/r8192U_core.c:1794:19: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1794:19: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1794:19: got int
drivers/staging/rtl8192u/r8192U_core.c:1795:10: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1795:10: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1795:10: got int
drivers/staging/rtl8192u/r8192U_core.c:1795:13: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1795:13: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1795:13: got int
drivers/staging/rtl8192u/r8192U_core.c:1795:16: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1795:16: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1795:16: got int
drivers/staging/rtl8192u/r8192U_core.c:1795:19: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8192u/r8192U_core.c:1795:19: expected restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1795:19: got int
drivers/staging/rtl8192u/r8192U_core.c:1838:34: warning: cast from restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1839:34: warning: cast from restricted __le16
drivers/staging/rtl8192u/r8192U_core.c:1840:34: warning: cast from restricted __le16
Signed-off-by: Koray Gulcu <koray.gulcu@ozu.edu.tr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
