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/ |
WARNING: multiple messages have this Message-ID (diff)
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [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/ |
next prev parent reply other threads:[~2014-03-13 23:19 UTC|newest]
Thread overview: 14+ 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
2014-02-10 10:19 ` 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-02-17 8:27 ` Uwe Kleine-König
2014-03-03 11:20 ` Uwe Kleine-König
2014-03-03 11:20 ` Uwe Kleine-König
2014-03-10 7:55 ` Wolfram Sang
2014-03-10 7:55 ` Wolfram Sang
2014-03-13 21:26 ` Uwe Kleine-König
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 22:14 ` Wolfram Sang
2014-03-13 23:19 ` Uwe Kleine-König [this message]
2014-03-13 23:19 ` Uwe Kleine-König
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 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.