linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org
Subject: Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained
Date: Tue, 18 Jul 2017 13:08:34 +0300	[thread overview]
Message-ID: <3294296.B0HR3QnnsQ@avalon> (raw)
In-Reply-To: <20170718100352.GA28481@amd>

Hi Pavel,

On Tuesday 18 Jul 2017 12:03:52 Pavel Machek wrote:
> Hi!
> 
> >> diff --git a/drivers/media/platform/omap3isp/ispccp2.c
> >> b/drivers/media/platform/omap3isp/ispccp2.c index
> >> 4f8fd0c00748..47210b102bcb 100644
> >> --- a/drivers/media/platform/omap3isp/ispccp2.c
> >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> >> @@ -1140,6 +1140,11 @@ int omap3isp_ccp2_init(struct isp_device *isp)
> >>  	if (isp->revision == ISP_REVISION_2_0) {
> >>  		ccp2->vdds_csib = devm_regulator_get(isp->dev, "vdds_csib");
> >>  		if (IS_ERR(ccp2->vdds_csib)) {
> >> +			if (PTR_ERR(ccp2->vdds_csib) == -EPROBE_DEFER) {
> >> +				dev_dbg(isp->dev,
> >> +					"Can't get regulator vdds_csib,
> >> deferring probing\n");
> >> +				return -EPROBE_DEFER;
> >> +			}
> >> 
> >>  			dev_dbg(isp->dev,
> >>  				"Could not get regulator vdds_csib\n");
> > 
> > I would just move this message above the -EPROBE_DEFER check and remove
> > the one inside the check. Probe deferral debug information can be obtained
> > by enabling the debug messages in the driver core.
> 
> Actually, in such case perhaps the message in -EPROBE_DEFER could be
> removed. Deferred probing happens all the time. OTOH "Could not get
> regulator" probably should be dev_err(), as it will make device
> unusable?

Messages along the lines of "I'm deferring probe" are in my opinion not 
valuable, as we can get that from the driver core. Debug messages that tell 
why probe is being deferred can however be useful for debugging. That's why I 
proposed to move the regulator get error debug message above the probe 
deferral check, as it would then always be printed. Turning it into an error 
makes sense, but only when not deferring probe then.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2017-07-18 10:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 22:01 [PATCH 0/7] Omap3isp CCP2 support Sakari Ailus
2017-07-17 22:01 ` [PATCH 1/7] omap3isp: Ignore endpoints with invalid configuration Sakari Ailus
2017-07-17 23:03   ` Sebastian Reichel
2017-07-18 19:37     ` Sakari Ailus
2017-07-18  9:02   ` Laurent Pinchart
2017-07-17 22:01 ` [PATCH 2/7] omap3isp: Parse CSI1 configuration from the device tree Sakari Ailus
2017-07-18  8:57   ` Sebastian Reichel
2017-07-18  9:07   ` Laurent Pinchart
2017-07-17 22:01 ` [PATCH 3/7] omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode Sakari Ailus
2017-07-17 22:01 ` [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained Sakari Ailus
2017-07-18  8:52   ` Sebastian Reichel
2017-07-18  9:09   ` Laurent Pinchart
2017-07-18 10:03     ` Pavel Machek
2017-07-18 10:08       ` Laurent Pinchart [this message]
2017-07-18 10:17       ` Sakari Ailus
2017-07-18 21:02         ` Pavel Machek
2017-07-18 21:16           ` Sakari Ailus
2017-07-18 21:27             ` Pavel Machek
2017-07-18 21:46               ` Sakari Ailus
2017-07-20 12:31                 ` Pavel Machek
2017-07-17 22:01 ` [PATCH 5/7] omap3isp: Always initialise isp and mutex for csiphy1 Sakari Ailus
2017-07-17 22:01 ` [PATCH 6/7] omap3isp: Correctly put the last iterated endpoint fwnode always Sakari Ailus
2017-07-18  8:40   ` Laurent Pinchart
2017-07-18 19:40     ` Sakari Ailus
2017-07-17 22:01 ` [PATCH 7/7] omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration Sakari Ailus
2017-07-18  8:54   ` Laurent Pinchart
2017-07-18 19:41     ` Sakari Ailus
2017-07-18 10:25 ` [PATCH 0/7] Omap3isp CCP2 support Pavel Machek

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=3294296.B0HR3QnnsQ@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sakari.ailus@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).