All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, Rob Herring <robh+dt@kernel.org>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: [PATCH v2 5/6] drm/vc4: Support the case where the DSI device is disabled
Date: Fri, 4 May 2018 15:56:51 +0200	[thread overview]
Message-ID: <20180504135651.GY13459@ulmo> (raw)
In-Reply-To: <20180504154906.2527d92b@bbrezillon>


[-- Attachment #1.1: Type: text/plain, Size: 3424 bytes --]

On Fri, May 04, 2018 at 03:49:06PM +0200, Boris Brezillon wrote:
> On Fri, 4 May 2018 15:29:15 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
> 
> > On Fri, May 04, 2018 at 02:05:25PM +0200, Boris Brezillon wrote:
> > > On Fri, 4 May 2018 12:28:33 +0200
> > > Thierry Reding <thierry.reding@gmail.com> wrote:
> > >   
> > > > On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:  
> > > > > Having a device with a status property != "okay" in the DT is a valid
> > > > > use case, and we should not prevent the registration of the DRM device
> > > > > when the DSI device connected to the DSI controller is disabled.
> > > > > 
> > > > > Consider the ENODEV return code as a valid result and do not expose the
> > > > > DSI encoder/connector when it happens.
> > > > > 
> > > > > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> > > > > ---
> > > > >  drivers/gpu/drm/vc4/vc4_dsi.c | 15 +++++++++++++--
> > > > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> > > > > index 8aa897835118..db2f137f8b7b 100644
> > > > > --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> > > > > +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> > > > > @@ -1606,8 +1606,18 @@ static int vc4_dsi_bind(struct device *dev, struct device *master, void *data)
> > > > >  
> > > > >  	ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> > > > >  					  &panel, &dsi->bridge);
> > > > > -	if (ret)
> > > > > +	if (ret) {
> > > > > +		/* If the bridge or panel pointed by dev->of_node is not
> > > > > +		 * enabled, just return 0 here so that we don't prevent the DRM
> > > > > +		 * dev from being registered. Of course that means the DSI
> > > > > +		 * encoder won't be exposed, but that's not a problem since
> > > > > +		 * nothing is connected to it.
> > > > > +		 */
> > > > > +		if (ret == -ENODEV)
> > > > > +			return 0;
> > > > > +
> > > > >  		return ret;
> > > > > +	}
> > > > >  
> > > > >  	if (panel) {
> > > > >  		dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
> > > > > @@ -1652,7 +1662,8 @@ static void vc4_dsi_unbind(struct device *dev, struct device *master,
> > > > >  	struct vc4_dev *vc4 = to_vc4_dev(drm);
> > > > >  	struct vc4_dsi *dsi = dev_get_drvdata(dev);
> > > > >  
> > > > > -	pm_runtime_disable(dev);
> > > > > +	if (dsi->bridge)
> > > > > +		pm_runtime_disable(dev);    
> > > > 
> > > > Is this safe? This uses component/master, so dsi->bridge is going to
> > > > remain valid until the driver's ->remove() is called. So technically you
> > > > could have a situation where drm_of_find_panel_or_bridge() returned some
> > > > error code that remains stored in dsi->bridge and cause the above
> > > > condition to be incorrectly true.  
> > > 
> > > No, because of_drm_find_bridge() (which is called from
> > > drm_of_find_panel_or_bridge() returns either NULL or a valid bridge
> > > pointer), so dsi->bridge either points to a valid bridge object or is
> > > NULL. Am I missing something?  
> > 
> > The return value of devm_drm_panel_bridge_add() is also assigned to
> > dsi->bridge later on (in the "if (panel)" conditional).
> 
> But then we return an error code if IS_ERR(dsi->bridge) [1], which
> should prevent the unbind function from being called, right?

Right, that should work. Seems safe, then.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-05-04 13:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 16:40 [PATCH v2 0/6] drm/panel: Handle the "panel is missing" case properly Boris Brezillon
2018-05-03 16:40 ` [PATCH v2 1/6] drm/tegra: Fix a device_node leak when the DRM panel is not found Boris Brezillon
2018-05-03 16:40   ` Boris Brezillon
2018-05-04  9:50   ` Thierry Reding
2018-05-04  9:53     ` Thierry Reding
2018-05-04  9:54     ` Boris Brezillon
2018-05-03 16:40 ` [PATCH v2 2/6] drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULL Boris Brezillon
2018-05-04 10:18   ` Thierry Reding
2018-05-04 11:58     ` Boris Brezillon
2018-05-04 12:11       ` Thierry Reding
2018-05-03 16:40 ` [PATCH v2 3/6] drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is disabled Boris Brezillon
2018-05-04 10:20   ` Thierry Reding
2018-05-03 16:40 ` [PATCH v2 4/6] drm/of: Make drm_of_find_panel_or_bridge() fail when the device " Boris Brezillon
2018-05-04 10:20   ` Thierry Reding
2018-05-03 16:40 ` [PATCH v2 5/6] drm/vc4: Support the case where the DSI " Boris Brezillon
2018-05-04 10:28   ` Thierry Reding
2018-05-04 12:05     ` Boris Brezillon
2018-05-04 13:29       ` Thierry Reding
2018-05-04 13:49         ` Boris Brezillon
2018-05-04 13:56           ` Thierry Reding [this message]
2018-05-04 10:30   ` Thierry Reding
2018-05-04 12:00     ` Boris Brezillon
2018-05-03 16:40 ` [PATCH v2 6/6] drm/panel: rpi-touchscreen: Set status to "fail" when ->probe() fails Boris Brezillon
2018-05-03 17:12   ` Rob Herring
2018-05-04  8:06     ` Boris Brezillon
2018-05-04  9:47       ` Thierry Reding
2018-05-04 12:17         ` Boris Brezillon
2018-05-04 14:20           ` Daniel Vetter
2018-05-04 14:24             ` Boris Brezillon
2018-05-04 15:01               ` Boris Brezillon
2018-05-04 19:29             ` Rob Herring
2018-05-07 11:14               ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180504135651.GY13459@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=airlied@linux.ie \
    --cc=boris.brezillon@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.