All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] memory: tegra: Introduce Tegra20 EMC driver
Date: Mon, 11 Jun 2018 13:41:33 +0200	[thread overview]
Message-ID: <20180611114133.GD31977@ulmo> (raw)
In-Reply-To: <20180611113503.GC31977@ulmo>

[-- Attachment #1: Type: text/plain, Size: 3151 bytes --]

On Mon, Jun 11, 2018 at 01:35:03PM +0200, Thierry Reding wrote:
> On Wed, Jun 06, 2018 at 04:42:01PM +0300, Dmitry Osipenko wrote:
> > On 06.06.2018 14:02, Thierry Reding wrote:
> > > On Mon, Jun 04, 2018 at 01:36:54AM +0300, Dmitry Osipenko wrote:
[...]
> > >> +	if (!child_count) {
> > >> +		dev_err(emc->dev, "no memory timings in DT node\n");
> > >> +		return -ENOENT;
> > >> +	}
> > >> +
> > >> +	emc->timings = devm_kcalloc(emc->dev, child_count, sizeof(*timing),
> > >> +				    GFP_KERNEL);
> > >> +	if (!emc->timings)
> > >> +		return -ENOMEM;
> > >> +
> > >> +	emc->num_timings = child_count;
> > >> +	timing = emc->timings;
> > >> +
> > >> +	for_each_child_of_node(node, child) {
> > >> +		err = load_one_timing_from_dt(emc, timing++, child);
> > >> +		if (err) {
> > >> +			of_node_put(child);
> > >> +			return err;
> > >> +		}
> > >> +	}
> > >> +
> > >> +	sort(emc->timings, emc->num_timings, sizeof(*timing), cmp_timings,
> > >> +	     NULL);
> > >> +
> > >> +	return 0;
> > >> +}
> > >> +
> > >> +static struct device_node *
> > >> +tegra_emc_find_node_by_ram_code(struct tegra_emc *emc, u32 ram_code)
> > >> +{
> > >> +	struct device_node *np;
> > >> +	int err;
> > >> +
> > >> +	for_each_child_of_node(emc->dev->of_node, np) {
> > >> +		u32 value;
> > >> +
> > >> +		err = of_property_read_u32(np, "nvidia,ram-code", &value);
> > >> +		if (err || value != ram_code)
> > >> +			continue;
> > >> +
> > >> +		return np;
> > >> +	}
> > >> +
> > >> +	dev_info(emc->dev, "no memory timings for RAM code %u found in DT\n",
> > >> +		 ram_code);
> > > 
> > > This seems like it should be dev_warn() or perhaps even dev_err() given
> > > that the result of it is the driver failing to probe. dev_info() may go
> > > unnoticed.
> > > 
> > 
> > Absence of memory timings is a valid case, hence dev_info() suit well here.
> > 
> > I can't see anything wrong with returning a errno if driver has nothing to do
> > and prefer to keep it because in that case managed resources would be free'd by
> > the driver core, though returning '0' also would work.
> 
> I disagree. A driver failing to probe will show up as a kernel log entry
> and is something that people will have to whitelist if they're filtering
> for error messages in the boot log.
> 
> I think it's more user-friendly to just let the driver succeed the probe
> in an expected case, even if that means there's really nothing to do. If
> you're really concerned about the managed resources staying around, I
> think you could probably get rid of them explicitly. By the looks of it
> devres_release_all() isn't an exported symbol, so it can't be called
> from driver code, but perhaps that's something that we can change.

Maybe an easier way to avoid keeping the managed resources around would
be to move the check a little further up. That way, we can abort earlier
if no EMC timings are available, before any resources are even
allocated.

The tegra_emc_find_node_by_ram_code() function would need to take a
struct device * instead of struct tegra_emc *, but otherwise it should
work fine.

Thierry

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

  reply	other threads:[~2018-06-11 11:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-03 22:36 [PATCH v2 0/5] Tegra20 External Memory Controller driver Dmitry Osipenko
2018-06-03 22:36 ` [PATCH v2 1/5] dt: bindings: tegra20-emc: Document interrupt property Dmitry Osipenko
2018-06-11 18:26   ` Rob Herring
2018-06-03 22:36 ` [PATCH v2 2/5] ARM: dts: tegra20: Add interrupt to External Memory Controller Dmitry Osipenko
2018-06-03 22:36 ` [PATCH v2 3/5] clk: tegra20: Turn EMC clock gate into divider Dmitry Osipenko
2018-06-03 22:36 ` [PATCH v2 4/5] clk: tegra20: Check whether direct PLLM sourcing is turned off for EMC Dmitry Osipenko
2018-06-03 22:36 ` [PATCH v2 5/5] memory: tegra: Introduce Tegra20 EMC driver Dmitry Osipenko
2018-06-06 11:02   ` Thierry Reding
2018-06-06 13:42     ` Dmitry Osipenko
2018-06-11 11:35       ` Thierry Reding
2018-06-11 11:41         ` Thierry Reding [this message]
2018-06-11 13:38           ` Dmitry Osipenko
2018-06-11 13:06         ` Dmitry Osipenko
2018-06-11 15:53           ` Thierry Reding
2018-06-11 18:10             ` Dmitry Osipenko
2018-06-05 11:19 ` [PATCH v2 0/5] Tegra20 External Memory Controller driver Peter De Schrijver
2018-06-05 11:19   ` Peter De Schrijver
2018-06-06 10:45 ` Thierry Reding
2018-06-06 12:41   ` Dmitry Osipenko

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=20180611114133.GD31977@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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.