similar to: [PATCH] drm/nouveau/dispnv50: fix runtime pm imbalance on error

While we currently grab a runtime PM ref in nouveau's normal connector detection code, we apparently don't do this for MST. This means if we're in a scenario where the GPU is suspended and userspace attempts to do a connector probe on an MSTC connector, the probe will fail entirely due to the DP aux channel and GPU not being woken up: [ 316.633489] nouveau 0000:01:00.0: i2c: aux

This is a complicated one. Essentially, there's currently a problem in the MST core that hasn't really caused any issues that we're aware of (emphasis on "that we're aware of"): locking. When we go through and probe the link addresses and path resources in a topology, we hold no locks when updating ports with said information. The members I'm referring to in

pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

This adds support for querying the maximum clock rate of a downstream port on a DisplayPort connection. Generally, downstream ports refer to active dongles which can have their own pixel clock limits. Note as well, we also start marking the connector as disconnected if we can't read the DPCD, since we wouldn't be able to do anything without DPCD access anyway. Signed-off-by: Lyude Paul

When gk20a_clk_ctor() returns an error code, pointer "clk" should be released. It's the same when gm20b_clk_new() returns from elsewhere following this call. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Same as we did for i915, but for nouveau this time. Additionally, we grab a malloc reference to the port that lasts for the entire lifetime of nv50_mstc, which gives us the guarantee that mstc->port will always point to valid memory for as long as the mstc stays around. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +++++------------- 1

Hi Ben, > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > should be released. It's the same when gm20b_clk_new() > > returns from elsewhere following this call. > This shouldn't be necessary. If a subdev constructor fails, and > returns a pointer, the core will call the destructor to clean things > up. > I'm not familiar with

On Mon, 1 Jun 2020 at 13:37, Ben Skeggs <skeggsb at gmail.com> wrote: > > On Mon, 1 Jun 2020 at 13:27, <dinghao.liu at zju.edu.cn> wrote: > > > > > > Hi Ben, > > > > > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > > > should be released. It's the same when gm20b_clk_new() > > > > returns

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_mstc_detect() drm/dp_mst:

> > > It's the same when gm20b_clk_new() returns from elsewhere following this call. > > I suggest to reconsider the interpretation of the software situation once more. > Can it be that the allocated clock object should be kept usable even after > a successful return from this function? > It's possible that we expect an usable clk pointer, though I could not

> > > For security, I will release this pointer only on error paths in this function. > > Do you tend to release objects (which are referenced by pointers)? > I just found that clk is referenced by pclk in this function. When clk is freed, pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk in this function and there is no bug here. Thank you

> > I just found that clk is referenced by pclk in this function. When clk is freed, > > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk > > in this function and there is no bug here. > > Can there be a need to release a clock object after a failed gk20a_clk_ctor() call? > I think this mainly depends on pclk pointer. It seems that the

Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent

On Sat, 30 May 2020 at 19:42, Dinghao Liu <dinghao.liu at zju.edu.cn> wrote: > > When gk20a_clk_ctor() returns an error code, pointer "clk" > should be released. It's the same when gm20b_clk_new() > returns from elsewhere following this call. This shouldn't be necessary. If a subdev constructor fails, and returns a pointer, the core will call the destructor to

On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul <lyude at redhat.com> wrote: > > When drm_connector_helper_funcs->atomic_best_encoder is defined, > ->best_encoder is ignored both by the atomic modesetting helpers. That By both the atomic modesetting helpers and ... (usually "both" implies 2 things) > being said, this hook is completely broken anyway - it always

s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming scheme, and will make even more sense once we redesign how the current refcounting scheme here works.

Hello... I just installed R version 1.4.0 on my laptop running Redhat Linux 7.1. I downloaded the RPM from CRAN and when I try to use a function I have used on other Redhat systems, I get the following error message. -------- > library(qtl) > gastritis <- read.cross(format="csv",dir="/home/sen/qtl/data/gastritis", +

Hi all, I just failed in loading a saved wordspace (13MB of size), and received these errors: Warning: stack imbalance in 'missing', 52 then 51 Warning: stack imbalance in 'if', 50 then 53 Warning: stack imbalance in 'as.environment', 57 then 59 Warning: stack imbalance in 'ls', 54 then 53 Warning: stack imbalance in '.Internal', 54 then 53 Warning: stack