- Add workqueue forward declaration (for new work, but a nice clean up)
- seftest fixes for the new histogram code
- Print output fix for hwlat tracer
- Fix missing system call events - due to change in x86 syscall naming
- Fix kprobe address being used by perf being hashed
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCWuIMShQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qkrdAQDRrgIGcm4pRGrvPiGhp4FeQKUx3woM
LY10qMYo3St7zwEAn5oor/e/7KQaQSdKQ7QkL690QU2bTO6FXz4VwE1OcgM=
=OHJk
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
- Add workqueue forward declaration (for new work, but a nice clean up)
- seftest fixes for the new histogram code
- Print output fix for hwlat tracer
- Fix missing system call events - due to change in x86 syscall naming
- Fix kprobe address being used by perf being hashed
* tag 'trace-v4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix missing tab for hwlat_detector print format
selftests: ftrace: Add a testcase for multiple actions on trigger
selftests: ftrace: Fix trigger extended error testcase
kprobes: Fix random address output of blacklist file
tracing: Fix kernel crash while using empty filter with perf
tracing/x86: Update syscall trace events to handle new prefixed syscall func names
tracing: Add missing forward declaration
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So not setting it.
BSpec: 7713
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-4-jose.souza@intel.com
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
v3:
Reading i915_edp_psr_status was causing PSR to exit but now with
'drm/i915/psr: Prevent PSR exit when a non-pipe related register is
written' it is fixed.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-3-jose.souza@intel.com
This will be helpful to debug what hardware is actually tracking
and causing PSR to exit.
BSpec: 7721
v4:
- Using _MMIO_TRANS2() in PSR_EVENT
- Cleaning events before printing
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-2-jose.souza@intel.com
Any write in any display register was causing HW to exit PSR,
masking it to allow more power savings. Writes to pipe related
registers will still cause HW to exit PSR.
This is already masked for PSR2.
It also do not break the Display WA #0884, writes to CURSURFLIVE
are still causing hardware to exit PSR. This was tested in CNL machine
by triggering a write to CURSURFLIVE when a debugfs was read by user.
Bspec: 7721 and 8042
v4: Checked that it do not breaks WA #0884 and added this information
to the commit message.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-1-jose.souza@intel.com
Make kernel print the correct number of TLB entries on Intel Xeon Phi 7210
(and others)
Before:
[ 0.320005] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
After:
[ 0.320005] Last level dTLB entries: 4KB 256, 2MB 128, 4MB 128, 1GB 16
The entries do exist in the official Intel SMD but the type column there is
incorrect (states "Cache" where it should read "TLB"), but the entries for
the values 0x6B, 0x6C and 0x6D are correctly described as 'Data TLB'.
Signed-off-by: Jacek Tomaka <jacek.tomaka@poczta.fm>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20180423161425.24366-1-jacekt@dugeo.com
- Change the ACPI subsystem initialization ordering to initialize
the WDAT watchodg before reserving PNP motherboard resources so
as to allow the watchdog to allocate its resources before the PNP
code gets to them and prevents it from working correctly (Mika
Westerberg).
- Add a quirk for Lenovo Z50-70 to use the iTCO watchdog instead of
the WDAT one which conflicts with the RTC on that platform (Mika
Westerberg).
- Avoid breaking backlight handling on Dell XPS 13 2013 model by
allowing laptops to use the ACPI backlight by default even if they
are Windows 8-ready in principle (Hans de Goede).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJa4diFAAoJEILEb/54YlRx3FoP/jfycW8kv8RxIVdgbkGs6QlY
cy/mCDzTSke0W5pZGQT3uo+rvUPcnaw+cgYGQUZRECZhwaW6DAxp6TxDfeuvJQUr
iwNTmAwToIoSUF9OG91O1+xHDupNDjTVf/SovufMXh5u7xqzfmE1cqOHHzQ0vmNT
N35J5Uk9oXIIIIKp96VDbLSDBHIyGj8dt+0CIYbypq43G5WaFCCLCfDAdrmPMOzZ
rJ9K59syptyrclOsC7LURjThgnwAB279kquB8hSnusfgpbb3qKmXXYOsSqUhpEb9
m0OaDezfiah0rOi8ClYvUAzEy35lGwflbaR8EcHw1QdDcaQWa9L+CnwxvdoaOgol
uYIkXKPMSBUCrBGxMQvK+sw+YF0DQq1qb5lua82vI+vYD/UHCpvmir+elRNXlzcO
bL7Nn/039nkunWkwMVqT4MZ8hLphN8SDU4q+/j8C4zQVKumz/BWOAACfWIsL42H3
RfMA+jnwhVdGbegDGAoIt6bI25wjBDnuSDs+cwpP26htHQy2TbSiMuFMOHjv7mjd
c970W2ZC5aolLphe9yfRgGnQjMNAIx9TZo7J+TkpCGt+ahPW4U4lPDd58ovHOfjL
PDI+FyVLozlugX+AzdSVFrj2T+ynbdGoICdBFSAFwrMbFOvSiLhj46w07Ul2qyrU
vScBf9ucYarT+fPi2OIf
=yaXB
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These are two watchdog-related fixes, fix for a backlight regression
from the 4.16 cycle that unfortunately was propagated to -stable and a
button module modification to prevent graphics driver modules from
failing to load due to unmet dependencies if ACPI is disabled from the
kernel command line.
Specifics:
- Change the ACPI subsystem initialization ordering to initialize the
WDAT watchodg before reserving PNP motherboard resources so as to
allow the watchdog to allocate its resources before the PNP code
gets to them and prevents it from working correctly (Mika
Westerberg).
- Add a quirk for Lenovo Z50-70 to use the iTCO watchdog instead of
the WDAT one which conflicts with the RTC on that platform (Mika
Westerberg).
- Avoid breaking backlight handling on Dell XPS 13 2013 model by
allowing laptops to use the ACPI backlight by default even if they
are Windows 8-ready in principle (Hans de Goede)"
* tag 'acpi-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: Only default only_lcd to true on Win8-ready _desktops_
ACPI / button: make module loadable when booted in non-ACPI mode
ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70
ACPI / scan: Initialize watchdog before PNP
- Blacklist the Low Power S0 Idle _DSM on ThinkPad X1 Tablet(2016)
where it causes issues and make it use ACPI S3 which works instead
of the non-working suspend-to-idle by default (Chen Yu).
- Fix the handling of hibernation in the PCI core for devices with
the DPM_FLAG_SMART_SUSPEND flag set to fix a regression affecting
intel-lpss I2C devices (Mika Westerberg).
- Drop development debug code from the brcmstb-avs-cpufreq driver
(Markus Mayer).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJa4dfZAAoJEILEb/54YlRxJLgP/A4L7JVJq9QmwkJwd5fckukp
v3DC+QZkUxfxmCWtE1Dkfje5zS0bgwfXH7/yddvYVBcm+E3rdE0cISBFBCUwOMfE
4uwOfeXJlHB2gofVehCQpEaZVrjqYOpK6Va59g+L6b2+fpxvtyf5KuEjb3+Q9sab
cpTH4KK44Q9pFVE7xznn3XzeAqainrOKwJqoLpcuNKFEYZoL00+A7i+HyZh5JPGg
cPw8c1QMdrjNWfdEYnqk57ilWKZ46/XH01GKTlePW8HrPVobhIrMQ/n+yoqrIWbl
LuXSml+ame2E7DjWEwu6WkYa3j3tj4A4ec7jCvzSnChIPJqDqDlrZ56Tzespjirk
HeLeKpb3f5IpFmsrm8fkJHTFrT9Dc6AedWHeQEk9XZlSMWpd+9X6BdhD7HLQWnmU
8nBO35FFDNnUpDE+27St1i4vgPRMqsfGMjhcjb/hzbw326SNWdJdfB224r83qfpb
SIRnugjh9yeoVEocOLIS+MyHFaP5x6kmykV0CyIhW9pCk7d0E/TdN8ZOkQSTrl+f
FCE5JySoiiYnlMtLZYTRLJ17l52GvUzo1zgnaTtBmDvFCAUBS2rJ2iTPdu/wpvFX
w0kLggz/OEu0kMJBLMZQkVd+zw2cgTU+QnxNlE8GpIUiJERTd9akZ/Qcjj9T+s6a
ZuX6tjp9Uv/6JCECZbK8
=OP1o
-----END PGP SIGNATURE-----
Merge tag 'pm-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These are a Low Power S0 Idle quirk, a hibernation handling fix for
the PCI bus type and a brcmstb-avs-cpufreq driver fixup removing
development debug code from it.
Specifics:
- Blacklist the Low Power S0 Idle _DSM on ThinkPad X1 Tablet(2016)
where it causes issues and make it use ACPI S3 which works instead
of the non-working suspend-to-idle by default (Chen Yu).
- Fix the handling of hibernation in the PCI core for devices with
the DPM_FLAG_SMART_SUSPEND flag set to fix a regression affecting
intel-lpss I2C devices (Mika Westerberg).
- Drop development debug code from the brcmstb-avs-cpufreq driver
(Markus Mayer)"
* tag 'pm-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: brcmstb-avs-cpufreq: remove development debug support
PCI / PM: Do not clear state_saved in pci_pm_freeze() when smart suspend is set
ACPI / PM: Blacklist Low Power S0 Idle _DSM for ThinkPad X1 Tablet(2016)
pool warnings.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEK2m5VNv+CHkogTfJ8vlZVpUNgaMFAlrhbTwACgkQ8vlZVpUN
gaOOvAf+LQDMcBVYIXqBWTQyHWWLdBURDSCfCk7vnl0oKWPC7btYdyr6WAy1eM8k
HWQNzx0Qn7n7mVasHdwclKxGJbUfYicApnoghbHE+tHMqnvJxynr8/1sheuGLyUc
IAqILrVI3rtU9HY34zAv5l2zu1C/OrgLckm5BaVOXlkTqwi1CLwnVcb0ifVEq/7Y
WxvzIalxpoWivBeFH69T6CgVkosnuUQhkweROpYWPLAaGs2Gnyazvsjfazahkl62
jXcVcnKLCTooXv01dQiyasw97kjv5lLG1KMhdqpdLtjQxl0saZ70hmIQ/jNvxenb
BS8klUEdOyHfzOER10fShe75fLvQJA==
=0eun
-----END PGP SIGNATURE-----
Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random
Pull /dev/random fixes from Ted Ts'o:
"Fix a regression on NUMA kernels and suppress excess unseeded entropy
pool warnings"
* tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
random: rate limit unseeded randomness warnings
random: fix possible sleeping allocation from irq context
Pull s390 fixes from Martin Schwidefsky:
"A couple of bug fixes:
- correct some CPU-MF counter names for z13 and z14
- correct locking in the vfio-ccw fsm_io_helper function
- provide arch_uretprobe_is_alive to avoid sigsegv with uretprobes
- fix a corner case with CPU-MF sampling in regard to execve
- fix expoline code revert for loadable modules
- update chpid descriptor for resource accessibility events
- fix dasd I/O errors due to outdated device alias infomation"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: correct module section names for expoline code revert
vfio: ccw: process ssch with interrupts disabled
s390: update sampling tag after task pid change
s390/cpum_cf: rename IBM z13/z14 counter names
s390/dasd: fix IO error for newly defined devices
s390/uprobes: implement arch_uretprobe_is_alive()
s390/cio: update chpid descriptor after resource accessibility event
Here are a few device ids for -rc3, including a new "simple driver".
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEHszNKQClByu0A+9RQQ3kT97htJUFAlrh/IARHGpvaGFuQGtl
cm5lbC5vcmcACgkQQQ3kT97htJW24BAAh2znk+Yj/GCxGe4Le0x0kua1c0bDeUsJ
XsTCF/HZbb5wzUVyl1JZhm7C11NcPH/sBPi524k5+ztFSETCDaHMFDtF9QEtYw7K
zWHSqdLwqgIaksqxMpSXfCAJsZO0K/SfUxvZfp7ETzXC2RP0wANzVV4ylDOV+cjd
cSfPfPORC6SSkm2cYcN/WXGk4l4sDA6LAW9aMDfLg4ZUJuFn3WQmYtM+p5dbw5E3
lkyELkd6vZdMJxkQTuV7MxNmv6Kt0DD9vQTvSpJ10WTaZ7mx0UzezJ5dm8ZJg4v7
k8iFXzzJeybmuv8oGFaXWZTfbwIx6bcZFhzoo4xQDAIUY1RhvU8OVAMH9QiM+sle
/kvVrY5z4qbKqj+8fZQsA64/OVrXyuU9QOQCUFF3oqcilflhmvaqRZgewmOE9FVm
T6a5xTko+4nr9oVcdusAfsKQ5JcdFTuQ+t/bKV7ygGAlKBYShMxI/8BadTXOUSlf
PahwAm6Wlzn/uFM+0tYIBmOkoNlLnaK39f/g0WrwYnaSaRPKwDIW90FUK/w73e6g
KqeXDTNWRsCUPJ4DwjUg95XVBwbEvDBq7po8OAfsDc9Cz/fSibKco6fGFTBR7OBN
XUhEomqdXaHdxqSe1Y5FbU6vMnqH9Fqd5svqLr7ReCEPwRcDDbaMU+s1Mf3Gck8D
dQ2Rd517nnc=
=5u11
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.17-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.17-rc3
Here are a few device ids for -rc3, including a new "simple driver".
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
The block responsible of parsing the DT for the number of chip-select
lines uses an 'if/else if/else if' block. The content of the second and
third 'else if' conditions are:
1/ the actual condition to enter the sub-block and
2/ the operation to do in this sub-block.
[...]
else if (condition1_to_enter && action1() == failed)
raise_error();
else if (condition2_to_enter && action2() == failed)
raise_error();
[...]
In case of failure, the sub-block is entered and an error raised.
Otherwise, in case of success, the code would continue erroneously in
the next 'else if' statement because it did not failed (and did not
enter the first 'else if' sub-block).
The first 'else if' refers to legacy bindings while the second 'else if'
refers to new bindings. The second 'else if', which is entered
erroneously, checks for the 'reg' property, which, for old bindings,
does not mean anything because it would not be the number of CS
available, but the regular register map of almost any DT node. This
being said, the content of the 'reg' property being the register map
offset and length, it has '2' values, so the number of CS in this
situation is assumed to be '2'.
When running nand_scan_ident() with 2 CS, the core will check for an
array of chips. It will first issue a RESET and then a READ_ID. Of
course this will trigger two timeouts because there is no chip in front
of the second CS:
[ 1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080)
[ 1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280)
Indeed, this is harmless and the core will then assume there is only one
valid CS.
Fix the logic in the whole block by entering each sub-block just on the
'is legacy' condition, doing the action inside the sub-block. This way,
when the action succeeds, the whole block is left.
Furthermore, for both the old bindings and the new bindings the same
logic was applied to retrieve the number of CS lines:
using of_get_property() to get a size in bytes, converted in the actual
number of lines by dividing it per sizeof(u32) (4 bytes).
This is fine for the 'reg' property which is a list of the CS IDs but
not for the 'num-cs' property which is directly the value of the number
of CS.
Anyway, no existing DT uses another value than 'num-cs = <1>' and no
other value has ever been supported by the old driver (pxa3xx_nand.c).
Remove this condition and apply a number of 1 CS anyway, as already
described in the bindings.
Finally, the 'reg' property of a 'nand' node (with the new bindings)
gives the IDs of each CS line in use. marvell_nand.c driver first look
at the number of CS lines that are present in this property.
Better use of_property_count_elems_of_size() than dividing by 4 the size
of the number of bytes returned by of_get_property().
Fixes: 02f26ecf8c ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Even though we weren't injecting guilty requests to be reset, we could
still fall over the issue of resetting the same request too fast -- where
the GPU refuses to start again. (Although it is interesting to note that
reloading the driver is sufficient, suggesting that we could recover if
we delayed the setup after reset?) Continue to paper over the problem by
adding a small delay by waiting for the engine to idle between tests,
and ensure that the engines are idle before starting the idle tests.
v2: Replace single instance of 50 with a magic macro.
References: 028666793a ("drm/i915/selftests: Avoid repeatedly harming the same innocent context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
It's possible for userspace to control n. Sanitize n when using it as an
array index.
Note that while it appears that n must be bound to the interval [0,3]
due to the way it is extracted from addr, we cannot guarantee that
compiler transformations (and/or future refactoring) will ensure this is
the case, and given this is a slow path it's better to always perform
the masking.
Found by smatch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
It's possible for userspace to control intid. Sanitize intid when using
it as an array index.
At the same time, sort the includes when adding <linux/nospec.h>.
Found by smatch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
It's possible for userspace to control idx. Sanitize idx when using it
as an array index.
Found by smatch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ceph_con_workfn() validates con->state before calling try_read() and
then try_write(). However, try_read() temporarily releases con->mutex,
notably in process_message() and ceph_con_in_msg_alloc(), opening the
window for ceph_con_close() to sneak in, close the connection and
release con->sock. When try_write() is called on the assumption that
con->state is still valid (i.e. not STANDBY or CLOSED), a NULL sock
gets passed to the networking stack:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: selinux_socket_sendmsg+0x5/0x20
Make sure con->state is valid at the top of try_write() and add an
explicit BUG_ON for this, similar to try_read().
Cc: stable@vger.kernel.org
Link: https://tracker.ceph.com/issues/23706
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
For now, there's just the one link config selection, optimizing for slow
and wide link. No functional changes.
Keep the debug logging in the caller, to avoid duplication later on if
alternative link confing selection gets added.
v2: Improved commit message
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/64848b76bf90d6ceecd7ec6b5add28531e0b1a41.1524730974.git.jani.nikula@intel.com
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be
able to debug log the link_bw and rate_select parameters; we don't use
the parameters here for anything else. We call intel_dp_compute_rate()
again during link training where we actually need and use the
parameters.
Move the debug logging of link_bw and rate_select to
intel_dp_link_training_clock_recovery(), and clean up the extra
intel_dp_compute_rate() call and extra clutter from the already
overcrowded intel_dp_compute_config().
v2: Rewrote commit message (Rodrigo, Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c5cf6a179e2d244eceb6bb80a792765d9efbee4f.1524730974.git.jani.nikula@intel.com
This updates the Gemini defconfig with a config that will bring
up most of the recently merged and updated devices to some
functional level:
- We enable high resolution timers (the right thing to do)
- Enable CMA for the framebuffer, and the new TVE200
framebuffer driver and the Ilitek ILI9322 driver for
graphics on the D-Link DIR-685. HIGHMEM support comes in
as part of this.
- Enable networking and the new Cortina Gemini ethernet
driver.
- Enable MDIO over GPIO and the Realtek PHY devices used on
several of these systems.
- Enable I2C over GPIO and SPI over GPIO which is used on
several of these devices.
- Enable the Thermal framework, GPIO fan control and LM75 sensor
adding cooling on the D-Link DNS-313 with no userspace
involved even if only the kernel is working, rock solid
thermal for this platform.
- Enable JEDEC flash probing to support the Eon flash chip in
D-Link DNS-313.
- Enable LED disk triggers for the NAS type devices.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
One of the bitbanged SPI hosts had wrongly named GPIO lines due to
sloppiness by yours truly.
Cc: arm@kernel.org
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fix a build regression with split object directories reported by Russell
and fix range sizes for omap4 cm2 and prm modules.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAlraJXYRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXNV5g//Y7bnLVOPGTu73EiB4erJr6OHlZjtzBE/
O/QQ0UwHZvmugzztPAfEvJg+s2O9IT6nloxupJHtmGpE43b7Bz47z7PAqSaI10vT
9CJ9xwmRyobkAPnYc9deQpQwmsg4pOYFjtsFTzWB/88AgadhqjRDzIjwGIM1SDvN
EKxcS+LA33erebbpgiLAIf+4IGvu+meENEHxBYIA/5KLdcYUTw0dVXSkpR301iV6
R4wW5a1nrqac8HORu+CBmehs0VI3YMJw9tMcIrWDm//ZsPVoXGP61kM6lZxlCB0S
FbOMVGO7GmcdrdhY0BaAKa7/KqSXEVBjPtZjZdOlnCDq1YNoUvrpIGn+k5x2jt1d
NI03+FaCVqAVGWQ11UywnM55aAmLDYMkY3kUG6HySJL8zKw8m0xGHVFN8JgLI1JU
ag3JlCbd7WNkAffLgUO+fobta6P0ASaxBXQ+88aOh9Yp6evuHBLVd/maC1+qNp7I
YEVw5HupVpCukPlNmSVpypH9+vfVdRcmrxGZiCoskmwoW+8JnmvPWjsvulFc1nqh
89lnz0XAMzHOTOmaK93s+kiJlZDoKJgrDs9B20Jtunur6El7oChR+f5z/AVmNfMr
zessucoRlQ2u4kYMqw/oDKoyE6bkWXhwFB5vjZaz8kXE5HGWF0HCVTnmBF79H/9B
C8Nx3K9FNyA=
=5SNP
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.17/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Pull "Two fixes for v4.17-rc cycle" from Tony Lindgren:
Fix a build regression with split object directories reported by Russell
and fix range sizes for omap4 cm2 and prm modules.
* tag 'omap-for-v4.17/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Fix build when using split object directories
ARM: dts: Fix cm2 and prm sizes for omap4
For ACPI support of the HiSilicon LPC driver we depend
on MFD_CORE config.
Currently the HiSi LPC Kconfig entry does not define this
dependency, so add it.
The reason for depending on MFD_CORE in the driver is
that we model the LPC host as an MFD, in that a platform
device will be created for each device on the bus.
We do this as we need to modify the resources of these
derived platform devices, something which we should not
do to the original devices created in the ACPI scan.
Details in e0aa1563f8 ("HISI LPC: Add ACPI support").
Fixes: e0aa1563f8 ("HISI LPC: Add ACPI support")
Reported-and-tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- add / enable USB host support for GX boards
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEe4dGDhaSf6n1v/EMWTcYmtP7xmUFAlrXwgkACgkQWTcYmtP7
xmVMZhAAn6vx6OPPjI6TZaGFmgA+LL7vHij2TfHtxbtbf3REa8ef3cxuoaiRAL4L
CxJ3IUM8oNJ/r1wj5i1P+lHkO9cHn6z9mNvShMTn6+0KoyxKP8hxeTECV/8QOGpg
LhUMCtymiHWgO+4nCS6Ch4CwVQUC/LzDt+T9InKAaeMyRp8zpIc6UIF0fTdTUA0M
/kAv9VfLlybUzt9BaBwlS4w0uDc19ewl9h8ZpnUhtkFmLGq6M6netMiT7lDyixc4
VP5VMYd5MkopOZaDgm55P2OvfJ5KiVrRz7Pu8AAbu/7VE9NxyJHAmkmi9DFXIQe1
AYiOQDdbtw0JniM0KULvVlqp3biQD4XbAoGdsVFfnLmu7uUbvXA49O5bnsQQbxrC
alid56TedNnCCMbTRFV4eLGn7M22wq4SlblxLqFziDyQIOMbw0cON2xhryLumXXQ
xOTtaC272H/7viwCcV7NzNLPL6ygPVkWyi6zPrS28wr6BUR5hMDr9sJ7Q7xgbwQp
r1OnoSc6+NTKiwGAUy3cOxgNAJzNWTiAEvut/o6crfE49ZAfcNX9ivtv2rtxhWrn
yG4GF5WpZYCb3+/KlMXjZkaZKd0S2PXjh5TVHSwuBgZeCLC5zVk66iLmL8ScWI2S
NRglrzEw4yqKPpw3pBhrIbfYatc3/On1xoV+ek3QeM/jnyT6RxQ=
=dXD+
-----END PGP SIGNATURE-----
Merge tag 'amlogic-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into fixes
Pull "Amlogic fixes for v4.17-rc1" from Kevin Hilman:
- add / enable USB host support for GX boards
* tag 'amlogic-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
ARM64: dts: meson-gxm-khadas-vim2: enable the USB controller
ARM64: dts: meson-gxl-nexbox-a95x: enable the USB controller
ARM64: dts: meson-gxl-s905x-libretech-cc: enable the USB controller
ARM64: dts: meson-gx-p23x-q20x: enable the USB controller
ARM64: dts: meson-gxl-s905x-p212: enable the USB controller
ARM64: dts: meson-gxm: add GXM specific USB host configuration
ARM64: dts: meson-gxl: add USB host support
The DTS file for the NAS4220B had the pin config for the
ethernet interface set to the pins in the SL3512 SoC while
this system is using SL3516. Fix it by referencing the
right SL3516 pins instead of the SL3512 pins.
Cc: stable@vger.kernel.org
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Reported-by: Andreas Fiedler <andreas.fiedler@gmx.net>
Reported-by: Roman Yeryomin <roman@advem.lv>
Tested-by: Roman Yeryomin <roman@advem.lv>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I am leaving Axis, so this address will bounce in the not too
distant future.
Fortunately, I will still be working with the community.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A single patch eliminating the redundant null pointer check detected
by CoverityScan("Array compared against 0")
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJa1L8VAAoJEABBurwxfuKYvb8P/igP+0zO88LYyOt0zXupks7Z
gNhqPEmhIC7VsHvzM2WlGxf8z3L/kPtWJAW8/3LB51ZHVPX72XE6lVgEsBOaPZ7x
atpnWN4t/xaE799hzbeqjtBGrEoMw8p/rLkGCcvNOgs/pnggfYqwhUyTncM4cn/K
5wICUUfY9ah9V0pDE6DM00xYqCdXS71SR/9xTnnn5U49aO5TNnZUd9oviKTQpABV
bhc7s6LykA40u9GQbwzQThMzozc2kg448vr0Hgs3h6Q4aMQoliE2VisIb1DDBUzx
ioD/8x8d5BxpFbkGCNXbhlp7Me6tWIanJZI+SXnBqDJh8kUbvT+UEljhW6FhACMB
XEJteIDiVReGveVtHjEtvozkdGgSj+cZIwPc91coAb8LaNAOIHbT+a+DyRgS5MGk
40wqQPV94JxtqSHGczZDR10zxWZYubh1W/chx49VdXJXFD+khpcdQnqraeEOQotM
G47efwtZWyutMhyHLa3XhSs0Wtc0NTzlNCd3TSvcCUVElJQ8sunV7S1GTeYQNYUo
M6mHeL3WoRj10uT+DvvpkvYgKuobH1otCd6u6srK6r8p36+3A6xWOuoW5WBvD8TH
WkDoEmHU44KIrUDrqGeFI+RSknU785a1CbWSRgDsjhSRW+jDbQF2XcakJsUb40ta
Jf7mymZHeBPPLaCa5IDd
=Qt7n
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into fixes
SCMI fix for v4.17
A single patch eliminating the redundant null pointer check detected
by CoverityScan("Array compared against 0")
* tag 'scmi-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: remove redundant null check on array
A single patch to fix the new DTC warnings probably enabled during
v4.17 merge window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJa1L5XAAoJEABBurwxfuKYgccP/A1hZt9r2ScgiOSreq7+cdvH
MIjT2sdu6/XtIS+A0yXaLeICHsXi3VBIP7K/Lo7eJt0lo3RR7t+F0Wtht6Thr3Z2
Lax2v7I1UkimSWHSptjKNWO6H1CbAcbwLG5mn5vC2zFxMhfOkaNqz6nI8BNJybXH
Pt5RhFhW/GbQq6rCpp2Beoa4ZTfFRMNXEvtkV+DK874Gh3KDMNUeJWql66YArh9i
c2Ie8yxtrMGpHC2lVTbYlSYYk65XnpNk3Xs0lsG9LjSXLePuru4l7cD+BXL9rCyz
8KReymPLwSqbpWKA40hFk8o3vOK8VdCeU4hOgYckvWYuCpE907x/28RnqT9FJYm0
cHTWugtXGPEPfYgrM1zn/Z0Q9kyeun0iYBFAUZDAP+HNagAtd1isEV9ioqshd59t
BFOR1ueH1z6Kiymg73l9H7/wv8O40R1gPlzfB0xcP1VbggpVI7s8bafj++OaSHDY
1kJ6v+f+qjfITh1nDzLwTf8d94S/bX3QRksdNmEMy3fi1c3m7j+ajlmCgkdu+0Vg
IjpsFrjZ1ptS7W4wJqB9EMIDBghj/E1YaKR41yByfIuvDASm7nwjb9+HAG3sDxAz
+Unx48FZUyv4AqOhTevNh4u8aSCnOu2SULV5srav1vvmyHLDz5NjSpV3YY7/uTqz
kH9zHPpprsNstH2EM8Jl
=fm2S
-----END PGP SIGNATURE-----
Merge tag 'juno-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into fixes
Pull "ARMv8 Juno DT fix for v4.17" from Sudeep Holla:
A single patch to fix the new DTC warnings probably enabled during
v4.17 merge window.
* tag 'juno-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm64: dts: juno: drop unnecessary address-cells and size-cells properties
following:
- Geert makes the Raspberry Pi firmwware return -ENOSYS (similar to
other subsystems) when CONFIG_RASPBERRYPI_FIRMWARE is off.
- Florian fixes an incorrect annotation in the Raspberry Pi power domain
driver, spotted by sparse
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJa1SPiAAoJEIfQlpxEBwcEzbAQAIgdfOK7nGwlvWF9NdKMHVCE
lTFOfbTSdfsN5Tfa34AoaUSv7hTIH7c/HH0SLVF5s4k/3Gtr6YUeYI09N3FkhwxM
suyk75qk5a5Z3+JaHKS+G39MNj46i0FELXgw3ITLlhrtIMOGZrDR5dBQqhbgHeWd
QUpLmNC7mqSgUu9KSLjawKCKSo2LJkXc9kJDZFnNgWjpH05pckpb+jnOJjzVvWBT
e4uSa5tb3RJvfVA9v8jBv8qqsY/CuV29VzpumDJxPjoyp8QGH8z49I8GPOJwnOvK
VvJRiAatAHjgiGEHyHnFzoUG2d5Wt2wc2/3qPjzrG/CHtTT/Jy9xMTTh9Fz5KlOS
k+rKxgImLB1AMLwQhSyMU8Ep6FooraJiu7yKWt/Cy84ds6lEZ1IB0cgbrqgC3z9V
fXKhJ446tZfY2ghnScuK9RQdvRRnGVo/7hhVfcnBLKhX2WBON4d59QJbdTGhD42H
Gtln/Ud9wj/BCEWX2+jdc0680tFhR+UzoB7se4M0p/5yNmDNXF3sU7PbP6DbalVk
r5/NsSAO1nqijT6RvqO7Lxjj4FYv2OhrNGwq72bzS+1bwjhy1ANW2v3ah6oDXVNw
tmnmTuQbEz8/x2/cg4SRmneIDX0Wmjj2k9wwlp+vSeAcAT//YWQwUEoF0CvozwJ1
Ozz3s4ZWpkkYktGPwy+I
=TuZA
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-4.17/drivers-fixes' of https://github.com/Broadcom/stblinux into fixes
This pull request contains Broadcom SoCs drivers fixes, please pull the
following:
- Geert makes the Raspberry Pi firmwware return -ENOSYS (similar to
other subsystems) when CONFIG_RASPBERRYPI_FIRMWARE is off.
- Florian fixes an incorrect annotation in the Raspberry Pi power domain
driver, spotted by sparse
* tag 'arm-soc/for-4.17/drivers-fixes' of https://github.com/Broadcom/stblinux:
soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure
soc: bcm: raspberrypi-power: Fix use of __packed
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426103219.22181-1-chris@chris-wilson.co.uk
Recent AMD systems support using MWAIT for C1 state. However, MWAIT will
not allow deeper cstates than C1 on current systems.
play_dead() expects to use the deepest state available. The deepest state
available on AMD systems is reached through SystemIO or HALT. If MWAIT is
available, it is preferred over the other methods, so the CPU never reaches
the deepest possible state.
Don't try to use MWAIT to play_dead() on AMD systems. Instead, use CPUIDLE
to enter the deepest state advertised by firmware. If CPUIDLE is not
available then fallback to HALT.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org
Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
Link: https://lkml.kernel.org/r/20180403140228.58540-1-Yazen.Ghannam@amd.com
In error path of snd_dice_stream_init_duplex(), stream data for incoming
packet can be left to be initialized.
This commit fixes it.
Fixes: 436b5abe22 ('ALSA: dice: handle whole available isochronous streams')
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and
a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost the
type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5,
__VMEMMAP_BASE_L4 and __VMEMMAP_BASE_L5 constants.
Declare them explicitly unsigned long again.
Fixes: 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time")
Fixes: a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1804121437350.28129@cbobk.fhfr.pm
Revert commits
92af4dcb4e ("tracing: Unify the "boot" and "mono" tracing clocks")
127bfa5f43 ("hrtimer: Unify MONOTONIC and BOOTTIME clock behavior")
7250a4047a ("posix-timers: Unify MONOTONIC and BOOTTIME clock behavior")
d6c7270e91 ("timekeeping: Remove boot time specific code")
f2d6fdbfd2 ("Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior")
d6ed449afd ("timekeeping: Make the MONOTONIC clock behave like the BOOTTIME clock")
72199320d4 ("timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock")
As stated in the pull request for the unification of CLOCK_MONOTONIC and
CLOCK_BOOTTIME, it was clear that we might have to revert the change.
As reported by several folks systemd and other applications rely on the
documented behaviour of CLOCK_MONOTONIC on Linux and break with the above
changes. After resume daemons time out and other timeout related issues are
observed. Rafael compiled this list:
* systemd kills daemons on resume, after >WatchdogSec seconds
of suspending (Genki Sky). [Verified that that's because systemd uses
CLOCK_MONOTONIC and expects it to not include the suspend time.]
* systemd-journald misbehaves after resume:
systemd-journald[7266]: File /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal
corrupted or uncleanly shut down, renaming and replacing.
(Mike Galbraith).
* NetworkManager reports "networking disabled" and networking is broken
after resume 50% of the time (Pavel). [May be because of systemd.]
* MATE desktop dims the display and starts the screensaver right after
system resume (Pavel).
* Full system hang during resume (me). [May be due to systemd or NM or both.]
That happens on debian and open suse systems.
It's sad, that these problems were neither catched in -next nor by those
folks who expressed interest in this change.
Reported-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Reported-by: Genki Sky <sky@genki.is>,
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kevin Easton <kevin@guarana.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Kaike reported that in tests rdma hrtimers occasionaly stopped working. He
did great debugging, which provided enough context to decode the problem.
CPU 3 CPU 2
idle
start sched_timer expires = 712171000000
queue->next = sched_timer
start rdmavt timer. expires = 712172915662
lock(baseof(CPU3))
tick_nohz_stop_tick()
tick = 716767000000 timerqueue_add(tmr)
hrtimer_set_expires(sched_timer, tick);
sched_timer->expires = 716767000000 <---- FAIL
if (tmr->expires < queue->next->expires)
hrtimer_start(sched_timer) queue->next = tmr;
lock(baseof(CPU3))
unlock(baseof(CPU3))
timerqueue_remove()
timerqueue_add()
ts->sched_timer is queued and queue->next is pointing to it, but then
ts->sched_timer.expires is modified.
This not only corrupts the ordering of the timerqueue RB tree, it also
makes CPU2 see the new expiry time of timerqueue->next->expires when
checking whether timerqueue->next needs to be updated. So CPU2 sees that
the rdma timer is earlier than timerqueue->next and sets the rdma timer as
new next.
Depending on whether it had also seen the new time at RB tree enqueue, it
might have queued the rdma timer at the wrong place and then after removing
the sched_timer the RB tree is completely hosed.
The problem was introduced with a commit which tried to solve inconsistency
between the hrtimer in the tick_sched data and the underlying hardware
clockevent. It split out hrtimer_set_expires() to store the new tick time
in both the NOHZ and the NOHZ + HIGHRES case, but missed the fact that in
the NOHZ + HIGHRES case the hrtimer might still be queued.
Use hrtimer_start(timer, tick...) for the NOHZ + HIGHRES case which sets
timer->expires after canceling the timer and move the hrtimer_set_expires()
invocation into the NOHZ only code path which is not affected as it merily
uses the hrtimer as next event storage so code pathes can be shared with
the NOHZ + HIGHRES case.
Fixes: d4af6d933c ("nohz: Fix spurious warning when hrtimer and clockevent get out of sync")
Reported-by: "Wan Kaike" <kaike.wan@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Frederic Weisbecker <frederic@kernel.org>
Cc: "Marciniszyn Mike" <mike.marciniszyn@intel.com>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: linux-rdma@vger.kernel.org
Cc: "Dalessandro Dennis" <dennis.dalessandro@intel.com>
Cc: "Fleck John" <john.fleck@intel.com>
Cc: stable@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: "Weiny Ira" <ira.weiny@intel.com>
Cc: "linux-rdma@vger.kernel.org"
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804241637390.1679@nanos.tec.linutronix.de
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804242119210.1597@nanos.tec.linutronix.de
We can convert engine stats from a spinlock to seqlock to ensure interrupt
processing is never even a tiny bit delayed by parallel readers.
There is a smidgen bit more cost on the write lock side, and an extremely
unlikely chance that readers will have to retry a few times in face of
heavy interrupt load. But it should be extremely unlikely given how
lightweight read side section is compared to the interrupt processing
side, and also compared to the rest of the code paths which can lead into
it. Furthermore, writer is the ones doing the real, latency sensitive
work, while readers are only informative.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426074716.7352-1-tvrtko.ursulin@linux.intel.com
The driver_override implementation is susceptible to a race condition
when different threads are reading vs storing a different driver
override. Add locking to avoid this race condition.
Cfr. commits 6265539776 ("driver core: platform: fix race
condition with driver_override") and 9561475db6 ("PCI: Fix race
condition with driver_override").
Fixes: 3cf3857134 ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For AMBA devices with unconfigured driver override, the
"driver_override" sysfs virtual file is empty, while it contains
"(null)" for platform and PCI devices.
Make AMBA consistent with other buses by dropping the test for a NULL
pointer.
Note that contrary to popular belief, sprintf() handles NULL pointers
fine; they are printed as "(null)".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "adjusted_mode" clock value (ie the real pixel clock) is more
accurate than "mode" clock value (ie the panel/bridge requested
clock value). It offers a better preciseness for timing
computations and allows to reduce the extra dsi bandwidth in
burst mode (from ~20% to ~10-12%, hw platform dependent).
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Yannick Fertré <yannick.fertre@st.com>
Tested-by: Yannick Fertré <yannick.fertre@st.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125155504.8611-1-philippe.cornu@st.com
