Add inorder iteration function for rbtree usage.
This is a preparation patch for the next patch to
fix the gdb mounts issue.
Fixes: 2eea9ce4310d ("mounts: keep list of mounts in an rbtree")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Kuan-Ying Lee <kuan-ying.lee(a)canonical.com>
---
scripts/gdb/linux/rbtree.py | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/scripts/gdb/linux/rbtree.py b/scripts/gdb/linux/rbtree.py
index fe462855eefd..fcbcc5f4153c 100644
--- a/scripts/gdb/linux/rbtree.py
+++ b/scripts/gdb/linux/rbtree.py
@@ -9,6 +9,18 @@ from linux import utils
rb_root_type = utils.CachedType("struct rb_root")
rb_node_type = utils.CachedType("struct rb_node")
+def rb_inorder_for_each(root):
+ def inorder(node):
+ if node:
+ yield from inorder(node['rb_left'])
+ yield node
+ yield from inorder(node['rb_right'])
+
+ yield from inorder(root['rb_node'])
+
+def rb_inorder_for_each_entry(root, gdbtype, member):
+ for node in rb_inorder_for_each(root):
+ yield utils.container_of(node, gdbtype, member)
def rb_first(root):
if root.type == rb_root_type.get_type():
--
2.34.1
Armada 380 has smilar USB-2.0 PHYs as CP-110 (Armada 8K).
Add support for Armada 380 to cp110 utmi phy driver, and enable it for
armada-388-clearfog boards.
Additionally add a small bugfix for armada-388 clearfog:
Enable Clearfog Base M.2 connector for cellular modems with USB-2.0/3.0
interface.
This is not separated out to avoid future merge conflicts.
Signed-off-by: Josua Mayer <josua(a)solid-run.com>
---
Changes in v3:
- updated bindings with additional comments, tested with dtbs_check:
used anyOf for the newly-added optional regs
- added fix for clearfog base m.2 connector / enable third usb
- dropped unnecessary syscon node using invalid compatible
(Reported-by: Krzysztof Kozlowski <krzk(a)kernel.org>)
- Link to v2: https://lore.kernel.org/r/20240716-a38x-utmi-phy-v2-0-dae3a9c6ca3e@solid-ru…
Changes in v2:
- add support for optional regs / make syscon use optional
- add device-tree changes for armada-388-clearfog
- attempted to fix warning reported by krobot (untested)
- tested on actual hardware
- drafted dt-bindings
- Link to v1: https://lore.kernel.org/r/20240715-a38x-utmi-phy-v1-0-d57250f53cf2@solid-ru…
---
Josua Mayer (6):
arm: dts: marvell: armada-388-clearfog: enable third usb on m.2/mpcie
arm: dts: marvell: armada-388-clearfog-base: add rfkill for m.2
dt-bindings: phy: cp110-utmi-phy: add compatible string for armada-38x
arm: dts: marvell: armada-38x: add description for usb phys
phy: mvebu-cp110-utmi: add support for armada-380 utmi phys
arm: dts: marvell: armada-388-clearfog: add description for usb phys
.../phy/marvell,armada-cp110-utmi-phy.yaml | 34 +++-
.../boot/dts/marvell/armada-388-clearfog-base.dts | 41 ++++
arch/arm/boot/dts/marvell/armada-388-clearfog.dts | 8 +
arch/arm/boot/dts/marvell/armada-388-clearfog.dtsi | 30 ++-
arch/arm/boot/dts/marvell/armada-38x.dtsi | 24 +++
drivers/phy/marvell/phy-mvebu-cp110-utmi.c | 209 ++++++++++++++++-----
6 files changed, 288 insertions(+), 58 deletions(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240715-a38x-utmi-phy-02e8059afe35
Sincerely,
--
Josua Mayer <josua(a)solid-run.com>
UFS link is just put into hibern8 state during the 'freeze' process of the
hibernation. Afterwards, the system may get powered down. But that doesn't
matter during wakeup. Because during wakeup from hibernation, UFS link is
again put into hibern8 state by the restore kernel and then the control is
handed over to the to image kernel.
So in both the places, UFS link is never turned OFF. But
ufshcd_system_restore() just assumes that the link will be in OFF state and
sets the link state accordingly. And this breaks hibernation wakeup:
[ 2445.371335] phy phy-1d87000.phy.3: phy_power_on was called before phy_init
[ 2445.427883] ufshcd-qcom 1d84000.ufshc: Controller enable failed
[ 2445.427890] ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
[ 2445.427906] ufs_device_wlun 0:0:0:49488: ufshcd_wl_resume failed: -5
[ 2445.427918] ufs_device_wlun 0:0:0:49488: PM: dpm_run_callback(): scsi_bus_restore returns -5
[ 2445.427973] ufs_device_wlun 0:0:0:49488: PM: failed to restore async: error -5
So fix the issue by removing the code that sets the link to OFF state.
Cc: Anjana Hari <quic_ahari(a)quicinc.com>
Cc: stable(a)vger.kernel.org # 6.3
Fixes: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/ufs/core/ufshcd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 9f037a40316a..a9dfa82adac9 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -10261,9 +10261,6 @@ int ufshcd_system_restore(struct device *dev)
*/
ufshcd_readl(hba, REG_UTP_TASK_REQ_LIST_BASE_H);
- /* Resuming from hibernate, assume that link was OFF */
- ufshcd_set_link_off(hba);
-
return 0;
}
--
2.25.1
This reverts commit 7a6bbc2829d4ab592c7e440a6f6f5deb3cd95db4.
The offending commit tried to suppress a double "Starting disk" message
for some drivers, but instead started spamming the log with bogus
messages every five seconds:
[ 311.798956] sd 0:0:0:0: [sda] Starting disk
[ 316.919103] sd 0:0:0:0: [sda] Starting disk
[ 322.040775] sd 0:0:0:0: [sda] Starting disk
[ 327.161140] sd 0:0:0:0: [sda] Starting disk
[ 332.281352] sd 0:0:0:0: [sda] Starting disk
[ 337.401878] sd 0:0:0:0: [sda] Starting disk
[ 342.521527] sd 0:0:0:0: [sda] Starting disk
[ 345.850401] sd 0:0:0:0: [sda] Starting disk
[ 350.967132] sd 0:0:0:0: [sda] Starting disk
[ 356.090454] sd 0:0:0:0: [sda] Starting disk
...
on machines that do not actually stop the disk on runtime suspend (e.g.
the Qualcomm sc8280xp CRD with UFS).
Let's just revert for now to address the regression.
Fixes: 7a6bbc2829d4 ("scsi: sd: Do not repeat the starting disk message")
Cc: stable(a)vger.kernel.org
Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org>
---
drivers/scsi/sd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Hi,
I just noticed this regression that snuck into 6.10-final and tracked it
down to 7a6bbc2829d4 ("scsi: sd: Do not repeat the starting disk
message").
I wanted to get this out ASAP to address the immediate regression while
someone who cares enough can work out a proper fix for the double start
message (which seems less annoying).
Note that the offending commit is marked for stable.
Johan
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 1b7561abe05d..6b64af7d4927 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -4119,6 +4119,8 @@ static int sd_resume(struct device *dev)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
+ sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
+
if (opal_unlock_from_suspend(sdkp->opal_dev)) {
sd_printk(KERN_NOTICE, sdkp, "OPAL unlock failed\n");
return -EIO;
@@ -4135,13 +4137,12 @@ static int sd_resume_common(struct device *dev, bool runtime)
if (!sdkp) /* E.g.: runtime resume at the start of sd_probe() */
return 0;
- sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
-
if (!sd_do_start_stop(sdkp->device, runtime)) {
sdkp->suspended = false;
return 0;
}
+ sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
ret = sd_start_stop_device(sdkp, 1);
if (!ret) {
sd_resume(dev);
--
2.44.2
When an i915 PMU counter is enabled and the driver is then unbound, the
PMU will be unregistered via perf_pmu_unregister(), however the event
will still be alive. i915 currently tries to deal with this situation
by:
a) Marking the pmu as "closed" and shortcut the calls from perf
b) Taking a reference from i915, that is put back when the event
is destroyed.
c) Setting event_init to NULL to avoid any further event
(a) is ugly, but may be left as is since it protects not trying to
access the HW that is now gone. Unless a pmu driver can call
perf_pmu_unregister() and not receive any more calls, it's a necessary
ugliness.
(b) doesn't really work: when the event is destroyed and the i915 ref is
put it may free the i915 object, that contains the pmu, not only the
event. After event->destroy() callback, perf still expects the pmu
object to be alive.
Instead of pigging back on the event->destroy() to take and put the
device reference, implement the new get()/put() on the pmu object for
that purpose.
(c) is not entirely correct as from the perf POV it's not an optional
call: perf would just dereference the NULL pointer. However this also
protects other entrypoints in i915_pmu. A new event creation from perf
after the pmu has been unregistered should not be possible anyway:
perf_init_event() bails out when not finding the pmu. This may be
cleaned up later.
Cc: <stable(a)vger.kernel.org> # 5.11+
Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com>
---
drivers/gpu/drm/i915/i915_pmu.c | 34 +++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 21eb0c5b320d..cb5f6471ec6e 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -514,15 +514,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer *hrtimer)
return HRTIMER_RESTART;
}
-static void i915_pmu_event_destroy(struct perf_event *event)
-{
- struct i915_pmu *pmu = event_to_pmu(event);
- struct drm_i915_private *i915 = pmu_to_i915(pmu);
-
- drm_WARN_ON(&i915->drm, event->parent);
-
- drm_dev_put(&i915->drm);
-}
static int
engine_event_status(struct intel_engine_cs *engine,
@@ -628,11 +619,6 @@ static int i915_pmu_event_init(struct perf_event *event)
if (ret)
return ret;
- if (!event->parent) {
- drm_dev_get(&i915->drm);
- event->destroy = i915_pmu_event_destroy;
- }
-
return 0;
}
@@ -872,6 +858,24 @@ static int i915_pmu_event_event_idx(struct perf_event *event)
return 0;
}
+static struct pmu *i915_pmu_get(struct pmu *base)
+{
+ struct i915_pmu *pmu = container_of(base, struct i915_pmu, base);
+ struct drm_i915_private *i915 = pmu_to_i915(pmu);
+
+ drm_dev_get(&i915->drm);
+
+ return base;
+}
+
+static void i915_pmu_put(struct pmu *base)
+{
+ struct i915_pmu *pmu = container_of(base, struct i915_pmu, base);
+ struct drm_i915_private *i915 = pmu_to_i915(pmu);
+
+ drm_dev_put(&i915->drm);
+}
+
struct i915_str_attribute {
struct device_attribute attr;
const char *str;
@@ -1299,6 +1303,8 @@ void i915_pmu_register(struct drm_i915_private *i915)
pmu->base.stop = i915_pmu_event_stop;
pmu->base.read = i915_pmu_event_read;
pmu->base.event_idx = i915_pmu_event_event_idx;
+ pmu->base.get = i915_pmu_get;
+ pmu->base.put = i915_pmu_put;
ret = perf_pmu_register(&pmu->base, pmu->name, -1);
if (ret)
--
2.43.0
Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.
dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.
Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com>
Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2")
Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com>
Cc: dri-devel(a)lists.freedesktop.org
Cc: <stable(a)vger.kernel.org> # v6.2+
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 5efc6a766f64..588d50ababf6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -32,7 +32,6 @@
#define VMW_FENCE_WRAP (1 << 31)
struct vmw_fence_manager {
- int num_fence_objects;
struct vmw_private *dev_priv;
spinlock_t lock;
struct list_head fence_list;
@@ -124,13 +123,13 @@ static void vmw_fence_obj_destroy(struct dma_fence *f)
{
struct vmw_fence_obj *fence =
container_of(f, struct vmw_fence_obj, base);
-
struct vmw_fence_manager *fman = fman_from_fence(fence);
- spin_lock(&fman->lock);
- list_del_init(&fence->head);
- --fman->num_fence_objects;
- spin_unlock(&fman->lock);
+ if (!list_empty(&fence->head)) {
+ spin_lock(&fman->lock);
+ list_del_init(&fence->head);
+ spin_unlock(&fman->lock);
+ }
fence->destroy(fence);
}
@@ -257,7 +256,6 @@ static const struct dma_fence_ops vmw_fence_ops = {
.release = vmw_fence_obj_destroy,
};
-
/*
* Execute signal actions on fences recently signaled.
* This is done from a workqueue so we don't have to execute
@@ -355,7 +353,6 @@ static int vmw_fence_obj_init(struct vmw_fence_manager *fman,
goto out_unlock;
}
list_add_tail(&fence->head, &fman->fence_list);
- ++fman->num_fence_objects;
out_unlock:
spin_unlock(&fman->lock);
@@ -403,7 +400,7 @@ static bool vmw_fence_goal_new_locked(struct vmw_fence_manager *fman,
u32 passed_seqno)
{
u32 goal_seqno;
- struct vmw_fence_obj *fence;
+ struct vmw_fence_obj *fence, *next_fence;
if (likely(!fman->seqno_valid))
return false;
@@ -413,7 +410,7 @@ static bool vmw_fence_goal_new_locked(struct vmw_fence_manager *fman,
return false;
fman->seqno_valid = false;
- list_for_each_entry(fence, &fman->fence_list, head) {
+ list_for_each_entry_safe(fence, next_fence, &fman->fence_list, head) {
if (!list_empty(&fence->seq_passed_actions)) {
fman->seqno_valid = true;
vmw_fence_goal_write(fman->dev_priv,
--
2.43.0
From: Chris Wulff <crwulff(a)gmail.com>
Make sure the descriptor has been set before looking at maxpacket.
This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint
for the current speed, or the gadget descriptors are malformed and
the descriptor for the speed/endpoint are not found.
Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
Cc: stable(a)vger.kernel.org
Signed-off-by: Chris Wulff <crwulff(a)gmail.com>
---
drivers/usb/gadget/udc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 2dfae7a17b3f..36a5d5935889 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -118,7 +118,7 @@ int usb_ep_enable(struct usb_ep *ep)
goto out;
/* UDC drivers can't handle endpoints with maxpacket size 0 */
- if (usb_endpoint_maxp(ep->desc) == 0) {
+ if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
/*
* We should log an error message here, but we can't call
* dev_err() because there's no way to find the gadget
--
2.43.0