For boards without a reset GPIO we skip the delay between enabling the
pcie_ref_clk and touching the RC registers for configuration. This hangs
the system if there isn't a proper delay to ensure the clocks are settled
in the DW PCIe core.
Also iMX6Q always needs an additional 10us delay to make sure the reset is
propagated through the core, as we don't have an explicitly controlled
reset input on this SoC.
This fixes a problem with 3fce0e882f ("PCI: imx6: Delay enabling
reference clock for SS until it stabilizes"): the kernel doesn't boot on
systems that don't pass the PCI GPIO reset in the DTB. This regression
affects mx6 nitrogen boards.
[bhelgaas: add regression info in changelog]
Fixes: 3fce0e882f ("PCI: imx6: Delay enabling reference clock for SS until it stabilizes")
Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Richard Zhu <richard.zhu@freescale.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
It is reported that Samsung laptops that need to poll events are broken by
the following commit:
Commit 3afcf2ece4
Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
The behaviors of the 2 vendor firmwares are conflict:
1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
automatically sets SCI_EVT as long as there is event queued up.
2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
returns 0 when there is no event queued up.
This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.
Fixes: 3afcf2ece4 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is reported that the following commit breaks Samsung hardware:
Commit: 558e4736f2.
Subject: ACPI / EC: Add support to disallow QR_EC to be issued before
completing previous QR_EC
Which means the Samsung behavior conflicts with the Acer behavior.
1. Samsung may behave like:
[ +event 1 ] SCI_EVT set
[ +event 2 ] SCI_EVT set
write QR_EC
read event
[ -event 1 ] SCI_EVT clear
Without the above commit, Samsung can work:
[ +event 1 ] SCI_EVT set
[ +event 2 ] SCI_EVT set
write QR_EC
CAN prepare next QR_EC as SCI_EVT=1
read event
[ -event 1 ] SCI_EVT clear
write QR_EC
read event
[ -event 2 ] SCI_EVT clear
With the above commit, Samsung cannot work:
[ +event 1 ] SCI_EVT set
[ +event 2 ] SCI_EVT set
write QR_EC
read event
[ -event 1 ] SCI_EVT clear
CANNOT prepare next QR_EC as SCI_EVT=0
2. Acer may behave like:
[ +event 1 ] SCI_EVT set
[ +event 2 ]
write QR_EC
read event
[ -event 1 ] SCI_EVT clear
[ +event 2 ] SCI_EVT set
Without the above commit, Acer cannot work when there is only 1 event:
[ +event 1 ] SCI_EVT set
write QR_EC
can prepared next QR_EC as SCI_EVT=1
read event
[ -event 1 ] SCI_EVT clear
CANNOT write QR_EC as SCI_EVT=0
With the above commit, Acer can work:
[ +event 1 ] SCI_EVT set
[ +event 2 ]
write QR_EC
read event
[ -event 1 ] SCI_EVT set
can prepare next QR_EC because SCI_EVT=0
CAN write QR_EC as SCI_EVT=1
Since Acer can also work with only the following commit applied:
Commit: 3afcf2ece4
Subject: ACPI / EC: Add support to disallow QR_EC to be issued when
SCI_EVT isn't set
commit 558e4736f2 can be reverted.
Fixes: 558e4736f2 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CMI8888 shows the stuttering playback when the snooping is disabled
on the audio buffer. Meanwhile, we've got reports that CORB/RIRB
doesn't work in the snooped mode. So, as a compromise, disable the
snoop only for CORB/RIRB and enable the snoop for the stream buffers.
The resultant patch became a bit ugly, unfortunately, but we still can
live with it.
Reported-and-tested-by: Geoffrey McRae <geoff@spacevs.com>
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The reported-by text says you have to ask for permission, but that
should only be if the bug was reported in private. These days the
standard is to always give reported-by credit or it's considered a bit
rude.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
After kernel 3.7 (commit b4b8f770eb),
/proc/cpuinfo replaces 'Processor' to 'model name'.
This patch makes CPUINFO_PROC to an array and provides two choices for
ARM, makes it compatible for different kernel version.
v1 -> v2: minor changes as suggested by Namhyung Kim:
- Doesn't pass @h and @evlist to __write_cpudesc;
- Coding style fix.
v2 -> v3:
- Rebase:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1414115126-7479-1-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Emulation of code that is 14 bytes to the segment limit or closer
(e.g. RIP = 0xFFFFFFF2 after reset) is broken because we try to read as
many as 15 bytes from the beginning of the instruction, and __linearize
fails when the passed (address, size) pair reaches out of the segment.
To fix this, let __linearize return the maximum accessible size (clamped
to 2^32-1) for usage in __do_insn_fetch_bytes, and avoid the limit check
by passing zero for the desired size.
For expand-down segments, __linearize is performing a redundant check.
(u32)(addr.ea + size - 1) <= lim can only happen if addr.ea is close
to 4GB; in this case, addr.ea + size - 1 will also fail the check against
the upper bound of the segment (which is provided by the D/B bit).
After eliminating the redundant check, it is simple to compute
the *max_size for expand-down segments too.
Now that the limit check is done in __do_insn_fetch_bytes, we want
to inject a general protection fault there if size < op_size (like
__linearize would have done), instead of just aborting.
This fixes booting Tiano Core from emulated flash with EPT disabled.
Cc: stable@vger.kernel.org
Fixes: 719d5a9b24
Reported-by: Borislav Petkov <bp@suse.de>
Tested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The error code for #GP and #SS is zero when the segment is used to
access an operand or an instruction. It is only non-zero when
a segment register is being loaded; for limit checks this means
cases such as:
* for #GP, when RIP is beyond the limit on a far call (before the first
instruction is executed). We do not implement this check, but it
would be in em_jmp_far/em_call_far.
* for #SS, if the new stack overflows during an inter-privilege-level
call to a non-conforming code segment. We do not implement stack
switching at all.
So use an error code of zero.
Reviewed-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since commit f3354ab674 ("ARM: 8169/1: l2c: parse cache properties from
ePAPR definitions") the following error is seen on imx6q:
[ 0.000000] PL310 OF: cache setting yield illegal associativity
[ 0.000000] PL310 OF: -2147097556 calculated, only 8 and 16 legal
As imx6q does not pass the "cache-size" and "cache-sets" properties in DT, the function l2x0_cache_size_of_parse() returns early and keep the 'associativity' pointer uninitialized.
To fix this problem, return error codes inside l2x0_cache_size_of_parse() and only use the 'associativity' pointer result if l2x0_cache_size_of_parse() succeeds.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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>
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>
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>
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>
Apply __init marker to module's init function and __exit to module's
exit function as they both have no other usage.
Signed-off-by: Mariusz Gorski <marius.gorski@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
