search for: drm_dp_mst_port

...g refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The inten...

...g refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The inten...

...g refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The inten...

...lpers is really > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme works like this: > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > this refcount hits 0 for either of the two, they're removed from the > topology state, but not immediately freed. Both ports and branch devices > will reinitialize their kref once it's hit 0 before actually destroying > t...

...lain wrong because it's been hacked up many > > > times over the years without anyone actually going over the code and > > > seeing if things could be simplified. > > > > > > To the best of my understanding, the current scheme works like this: > > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > > this refcount hits 0 for either of the two, they're removed from the > > > topology state, but not immediately freed. Both ports and branch devices > > > will reinitialize their kref once it's hit 0 bef...

...using and probably just plain wrong because it's been hacked up many > > times over the years without anyone actually going over the code and > > seeing if things could be simplified. > > > > To the best of my understanding, the current scheme works like this: > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > this refcount hits 0 for either of the two, they're removed from the > > topology state, but not immediately freed. Both ports and branch devices > > will reinitialize their kref once it's hit 0 before actually de...

So we don't ever have to worry about drivers touching drm_dp_mst_port structs without verifying them and crashing again. Lyude Paul (6): drm/dp_mst: Add drm_dp_get_payload_info() drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes() drm/nouveau: Stop reading port->mgr in nv50_ms...

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is a WIP version of the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

...9e6243..6f9b211069a7 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -46,7 +46,7 @@ static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr, char *buf); static int test_calc_pbn_mode(void); -static void drm_dp_put_port(struct drm_dp_mst_port *port); +static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port); static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr, int id, @@ -888,7 +888,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref *kref) */ list_for_each_entry_safe(port,...

On Tue, Sep 03, 2019 at 04:45:58PM -0400, Lyude Paul wrote: > Yes-you read that right. Currently there is literally no locking in > place for any of the drm_dp_mst_port struct members that can be modified > in response to a link address response, or a connection status response. > Which literally means if we're unlucky enough to have any sort of > hotplugging event happen before we're finished with reprobing link > addresses, we'll race and...

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

Yes-you read that right. Currently there is literally no locking in place for any of the drm_dp_mst_port struct members that can be modified in response to a link address response, or a connection status response. Which literally means if we're unlucky enough to have any sort of hotplugging event happen before we're finished with reprobing link addresses, we'll race and the contents of sai...

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

...gt; + * appropriate locks in @mgr. > + * > + * Returns: > + * 0 on success, negative error code if the port is no longer valid or a > + * programmed payload could not be found for @port. > + */ > +int drm_dp_get_payload_info(struct drm_dp_mst_topology_mgr *mgr, > + struct drm_dp_mst_port *port, > + struct drm_dp_vcpi *vcpi_out, > + struct drm_dp_payload *payload_out) > +{ > + struct drm_dp_payload *payload = NULL; > + int i; > + int ret = 0; > + > + port = drm_dp_get_validated_port_ref(mgr, port); > + if (!port) > + return -EINVAL; This i...

...->malloc_kref) - 1); > + DRM_DEBUG("mstb %p/%px (%d)\n", > + mstb, mstb, kref_read(&mstb->malloc_kref) - 1); > kref_put(&mstb->malloc_kref, drm_dp_free_mst_branch_device); > } > > @@ -1379,7 +1381,8 @@ void > drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port) > { > kref_get(&port->malloc_kref); > - DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->malloc_kref)); > + DRM_DEBUG("port %p/%px (%d)\n", > + port, port, kref_read(&port->malloc_kref)); > } > EXPORT_SYMBOL(drm_dp_mst_g...

...p_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1487,24 +1487,6 @@ drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb) > kref_put(&mstb->topology_kref, drm_dp_destroy_mst_branch_device); > } > > -static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int old_pdt) > -{ > - struct drm_dp_mst_branch *mstb; > - > - switch (old_pdt) { > - case DP_PEER_DEVICE_DP_LEGACY_CONV: > - case DP_PEER_DEVICE_SST_SINK: > - /* remove i2c over sideband */ > - drm_dp_mst_unregister_i2c_bus(&port->aux); > - break; > -...