devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] i2c: new bus driver for efm32
Date: Fri, 14 Mar 2014 00:19:25 +0100	[thread overview]
Message-ID: <20140313231925.GC15674@pengutronix.de> (raw)
In-Reply-To: <20140313221433.GI2696@katana>

Hi Wolfram,

On Thu, Mar 13, 2014 at 11:14:33PM +0100, Wolfram Sang wrote:
> > > Huh? Is this an accepted binding? Doesn't look like it because of a
> > > generic name and IMO a specific use-case. BTW the binding documentation
> > > for this driver is missing.
> > Regarding the generic name: I don't care much, but I don't have a
> > problem with it. IMHO it's implicitly name-spaced by the compatible
> > string which starts with "efm32," and so is fine. I'd like to have the
> > same property name for all efm32 device drivers and "location" matches
> > the hardware reference manual (apart from capitalization).
> 
> I would in deed have expected a binding like "efm32,location" to
> emphasize this is an efm32 specific thing. I know vendor-specific
> "setup" bindings from elsewhere. Since it has been accepted already in
> other places, we should keep it likes this.
Assuming you know the dt stuff better than me (and noone objects) I'd
fix the intree drivers to use efm32,location, too.

> > > > +	if (resource_size(res) < 0x42) {
> > > > +		dev_err(&pdev->dev, "memory resource too small\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > 
> > > I'd drop this check since, but I won't force you to.
> > I'd understand your sentence with s/since//, not sure about it as is.
> > Anyhow, I like this check.
> 
> A leftover. I was about to write "since the check is somewhat heuristic
> and does not proof much". But then I decided it is not worth spending
> too much discussion on it :)
I'd say it's heuristic to *not* check the boundary. It doesn't apply
here, but consider a driver using a register space > PAGE_SIZE on an MMU
platform. It accesses base + PAGE_SIZE + 0x42 even if dt only gave a
register range of PAGE_SIZE / 2. It's like gets(3).

> > > > +	clkdiv = DIV_ROUND_UP(rate, 8 * ddata->pdata.frequency) - 1;
> > > > +	if (clkdiv >= 0x200) {
> > > > +		dev_err(&pdev->dev,
> > > > +				"input clock too fast (%lu) to divide down to bus freq (%lu)",
> > > > +				rate, ddata->pdata.frequency);
> > > > +		ret = -EIO;
> > > > +		goto err_disable_clk;
> > > > +	}
> > > 
> > > -EIO for clocks errors? Is this common?
> > Changed to ENODEV. Ok?
> 
> Nope, then the driver core will silent drop the error. -EINVAL?
agreed

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

      reply	other threads:[~2014-03-13 23:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 10:19 [RFC PATCH] i2c: new bus driver for efm32 Uwe Kleine-König
     [not found] ` <1392027598-29015-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-02-17  8:27   ` Uwe Kleine-König
2014-03-03 11:20   ` Uwe Kleine-König
2014-03-10  7:55   ` Wolfram Sang
2014-03-13 21:26     ` Uwe Kleine-König
     [not found]       ` <20140313212613.GB15674-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-03-13 22:14         ` Wolfram Sang
2014-03-13 23:19           ` Uwe Kleine-König [this message]

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=20140313231925.GC15674@pengutronix.de \
    --to=u.kleine-koenig-bicnvbalz9megne8c9+irq@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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 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).