Add support to specify platform specific transition_delay_us instead
of using the transition delay derived from PCC.
With commit "3d41386d556d: cpufreq: CPPC: Use transition_delay_us
depending transition_latency" we are setting transition_delay_us
directly and not applying the LATENCY_MULTIPLIER. With this on Qualcomm
Centriq we can end up with a very high rate of frequency change requests
when using schedutil governor (default rate_limit_us=10 compared to an
earlier value of 10000).
The PCC subspace describes the rate at which the platform can accept
commands on the CPPC's PCC channel. This includes read and write
command on the PCC channel that can be used for reasons other than
frequency transitions. Moreover the same PCC subspace can be used by
multiple freq domains and deriving transition_delay_us from it as we do
now can be sub-optimal.
Moreover if a platform does not use PCC for desired_perf register then
there is no way to compute the transition latency or the delay_us.
CPPC does not have a standard defined mechanism to get the transition
rate or the latency at the moment.
Given the above limitations, it is simpler to have a platform specific
transition_delay_us and rely on PCC derived value only if a platform
specific value is not available.
Signed-off-by: Prashanth Prakash <pprakash(a)codeaurora.org>
Cc: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: Rafael J. Wysocki <rjw(a)rjwysocki.net>
Cc: 4.14+ <stable(a)vger.kernel.org>
Fixes: 3d41386d556d ("cpufreq: CPPC: Use transition_delay_us depending
transition_latency)
---
v2:
* Return final delay_us from cppc_cpufreq_get_transition_delay_us (Viresh)
v3 and v4:
* code style changes (Viresh)
---
drivers/cpufreq/cppc_cpufreq.c | 47 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index bc5fc16..1b690f4 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -126,6 +126,50 @@ static void cppc_cpufreq_stop_cpu(struct cpufreq_policy *policy)
cpu->perf_caps.lowest_perf, cpu_num, ret);
}
+/*
+ * The PCC subspace describes the rate at which platform can accept commands
+ * on the shared PCC channel (including READs which do not count towards freq
+ * trasition requests), so ideally we need to use the PCC values as a fallback
+ * if we don't have a platform specific transition_delay_us
+ */
+#ifdef CONFIG_ARM64
+#include <asm/cputype.h>
+
+static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu)
+{
+ unsigned long implementor = read_cpuid_implementor();
+ unsigned long part_num = read_cpuid_part_number();
+ unsigned int delay_us = 0;
+
+ switch (implementor) {
+ case ARM_CPU_IMP_QCOM:
+ switch (part_num) {
+ case QCOM_CPU_PART_FALKOR_V1:
+ case QCOM_CPU_PART_FALKOR:
+ delay_us = 10000;
+ break;
+ default:
+ delay_us = cppc_get_transition_latency(cpu) /
+ NSEC_PER_USEC;
+ break;
+ }
+ break;
+ default:
+ delay_us = cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
+ break;
+ }
+
+ return delay_us;
+}
+
+#else
+
+static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu)
+{
+ return cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
+}
+#endif
+
static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
struct cppc_cpudata *cpu;
@@ -162,8 +206,7 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
cpu->perf_caps.highest_perf;
policy->cpuinfo.max_freq = cppc_dmi_max_khz;
- policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
- NSEC_PER_USEC;
+ policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu_num);
policy->shared_type = cpu->shared_type;
if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
--
Qualcomm Datacenter Technologies on behalf of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
This is a note to let you know that I've just added the patch titled
xhci: Fix use-after-free in xhci_free_virt_device
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 44a182b9d17765514fa2b1cc911e4e65134eef93 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Thu, 3 May 2018 17:30:07 +0300
Subject: xhci: Fix use-after-free in xhci_free_virt_device
KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;
dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.
set dev->udev pointer to NULL in xhci_free_dev()
The original patch went to stable so this fix needs to be applied
there as well.
Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot")
Cc: <stable(a)vger.kernel.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798ecce5..711da3306b14 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3621,6 +3621,7 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
}
xhci_debugfs_remove_slot(xhci, udev->slot_id);
+ virt_dev->udev = NULL;
ret = xhci_disable_slot(xhci, udev->slot_id);
if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
--
2.17.0
Please drop 'drm/sun4i: rgb: Fix potential division by zero' from
4.9.y/4.14.y.
CC [M] drivers/gpu/drm/sun4i/sun4i_rgb.o
../drivers/gpu/drm/sun4i/sun4i_rgb.c: In function ‘sun4i_rgb_mode_valid’:
../drivers/gpu/drm/sun4i/sun4i_rgb.c:96:6: error: ‘struct sun4i_tcon’ has no member named ‘dclk_min_div’
tcon->dclk_min_div = 6;
^~
../drivers/gpu/drm/sun4i/sun4i_rgb.c:97:6: error: ‘struct sun4i_tcon’ has no member named ‘dclk_max_div’
tcon->dclk_max_div = 127;
^~
make[5]: *** [../scripts/Makefile.build:294: drivers/gpu/drm/sun4i/sun4i_rgb.o] Error 1
make[4]: *** [../scripts/Makefile.build:544: drivers/gpu/drm/sun4i] Error 2
make[3]: *** [../scripts/Makefile.build:544: drivers/gpu/drm] Error 2
make[2]: *** [../scripts/Makefile.build:544: drivers/gpu] Error 2
make[1]: *** [/home/drue/src/linux/4.9-rc/Makefile:1006: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.9-rc/build-arm'
make: *** [Makefile:152: sub-make] Error 2
Greg - is there a way that I can tell which build and boot problems
0-day is reporting so that I don't duplicate work on either of our
sides?
Thanks,
Dan
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Clear the old_state and new_state pointers for every object in
drm_atomic_state_default_clear(). Otherwise
drm_atomic_get_{new,old}_*_state() will hand out stale pointers to
anyone who hasn't first confirmed that the object is in fact part of
the current atomic transcation, if they are called after we've done
the ww backoff dance while hanging on to the same drm_atomic_state.
For example, handle_conflicting_encoders() looks like it could hit
this since it iterates the full connector list and just calls
drm_atomic_get_new_connector_state() for each.
And I believe we have now witnessed this happening at least once in
i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915:
Remove last references to drm_atomic_get_existing* macros") changed
the safe drm_atomic_get_existing_connector_state() to the unsafe
drm_atomic_get_new_connector_state(), which opened the doors for
this particular bug there as well.
Cc: stable(a)vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Abhay Kumar <abhay.kumar(a)intel.com>
Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/drm_atomic.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..c825c76edc1d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -155,6 +155,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->connectors[i].state);
state->connectors[i].ptr = NULL;
state->connectors[i].state = NULL;
+ state->connectors[i].old_state = NULL;
+ state->connectors[i].new_state = NULL;
drm_connector_put(connector);
}
@@ -169,6 +171,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->crtcs[i].ptr = NULL;
state->crtcs[i].state = NULL;
+ state->crtcs[i].old_state = NULL;
+ state->crtcs[i].new_state = NULL;
}
for (i = 0; i < config->num_total_plane; i++) {
@@ -181,6 +185,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->planes[i].state);
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
+ state->planes[i].old_state = NULL;
+ state->planes[i].new_state = NULL;
}
for (i = 0; i < state->num_private_objs; i++) {
@@ -190,6 +196,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->private_objs[i].state);
state->private_objs[i].ptr = NULL;
state->private_objs[i].state = NULL;
+ state->private_objs[i].old_state = NULL;
+ state->private_objs[i].new_state = NULL;
}
state->num_private_objs = 0;
--
2.16.1
KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;
dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.
set dev->udev pointer to NULL in xhci_free_dev()
The original patch went to stable so this fix needs to be applied
there as well.
Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot")
Cc: <stable(a)vger.kernel.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..711da33 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3621,6 +3621,7 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
}
xhci_debugfs_remove_slot(xhci, udev->slot_id);
+ virt_dev->udev = NULL;
ret = xhci_disable_slot(xhci, udev->slot_id);
if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
--
2.7.4
From: Hector Martin <marcan(a)marcan.st>
[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]
At least some JMicron controllers issue buggy oversized DMA reads when
fetching context descriptors, always fetching 0x20 bytes at once for
descriptors which are only 0x10 bytes long. This is often harmless, but
can cause page faults on modern systems with IOMMUs:
DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read
This works around the problem by always leaving 0x10 padding bytes at
the end of descriptor buffer pages, which should be harmless to do
unconditionally for controllers in case others have the same behavior.
Signed-off-by: Hector Martin <marcan(a)marcan.st>
Reviewed-by: Clemens Ladisch <clemens(a)ladisch.de>
Signed-off-by: Stefan Richter <stefanr(a)s5r6.in-berlin.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/firewire/ohci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 8bf89267dc25..d731b413cb2c 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -1130,7 +1130,13 @@ static int context_add_buffer(struct context *ctx)
return -ENOMEM;
offset = (void *)&desc->buffer - (void *)desc;
- desc->buffer_size = PAGE_SIZE - offset;
+ /*
+ * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads
+ * for descriptors, even 0x10-byte ones. This can cause page faults when
+ * an IOMMU is in use and the oversized read crosses a page boundary.
+ * Work around this by always leaving at least 0x10 bytes of padding.
+ */
+ desc->buffer_size = PAGE_SIZE - offset - 0x10;
desc->buffer_bus = bus_addr + offset;
desc->used = 0;
--
2.15.1
Hi,
On stable v4.14.40-rc1, commit below breaks kernel boot on ARMv7 board
(Odroid XU3 with Samsung Exynos5422, exynos_defconfig). The kernel
hangs on "Starting kernel ...". Full log:
http://www.krzk.eu/#/builders/1/builds/1897
The board boots from TFTP with NFS root (NFSv4).
commit 449a8040a3b68a58131453b8f3dcfb411e85b1f5
Author: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Date: Mon Jan 8 14:35:52 2018 -0800
rcu: Create RCU-specific workqueues with rescuers
[ Upstream commit ad7c946b35ad455417fdd4bc0e17deda4011841b ]
Bisect log:
git bisect start
# good: [7d6240f0fb85430ae4f490824fdf8d0a078dfcd2] Linux 4.14.39
git bisect good 7d6240f0fb85430ae4f490824fdf8d0a078dfcd2
# bad: [c8cd674cefa12376b3f7f993ddb5b262f9c64dbf] Linux 4.14.40-rc1
git bisect bad c8cd674cefa12376b3f7f993ddb5b262f9c64dbf
# good: [f122a2d150d85721e1c48561ed9073154a9afcc8] bonding: fix the
err path for dev hwaddr sync in bond_enslave
git bisect good f122a2d150d85721e1c48561ed9073154a9afcc8
# good: [e353b1ee991a8aa64103db2b8dba975f1c7f1f0f] usb: dwc2: hcd: Fix
host channel halt flow
git bisect good e353b1ee991a8aa64103db2b8dba975f1c7f1f0f
# good: [95bcea0185094ba218ab24261658993a9af29d9f] serial: xuartps:
Fix out-of-bounds access through DT alias
git bisect good 95bcea0185094ba218ab24261658993a9af29d9f
# good: [58d6d43c0d69602b9325bbc6194188711d1132cd] crypto:
inside-secure - fix the extra cache computation
git bisect good 58d6d43c0d69602b9325bbc6194188711d1132cd
# good: [e1c90fdb0fd515dabb4e56a0cf5ebc276e16c3c7] drm: rcar-du: lvds:
Fix LVDS startup on R-Car Gen3
git bisect good e1c90fdb0fd515dabb4e56a0cf5ebc276e16c3c7
# good: [d3ab1eddcbca4b4eb8ba43451e04df07d2ca5c99] ARM: dts: imx7d:
cl-som-imx7: fix pinctrl_enet
git bisect good d3ab1eddcbca4b4eb8ba43451e04df07d2ca5c99
# good: [6a4469c29bddd0e7c646b2534787d47c77729720] ASoC: samsung: i2s:
Ensure the RCLK rate is properly determined
git bisect good 6a4469c29bddd0e7c646b2534787d47c77729720
# good: [60f7a71df26eca547c542d7d80895257ba10fda6] kdb: make "mdr"
command repeat
git bisect good 60f7a71df26eca547c542d7d80895257ba10fda6
# bad: [449a8040a3b68a58131453b8f3dcfb411e85b1f5] rcu: Create
RCU-specific workqueues with rescuers
git bisect bad 449a8040a3b68a58131453b8f3dcfb411e85b1f5
# good: [b5e56644256a462033f6b52212b9dd135e5fed10] xhci: Show what USB
release number the xHC supports from protocol capablity
git bisect good b5e56644256a462033f6b52212b9dd135e5fed10
# first bad commit: [449a8040a3b68a58131453b8f3dcfb411e85b1f5] rcu:
Create RCU-specific workqueues with rescuers
Let me know if you need any more information.
Best regards,
Krzysztof