All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Linux Netdev List <netdev@vger.kernel.org>,
	devicetree-discuss <devicetree-discuss@ozlabs.org>,
	linuxppc-dev <Linuxppc-dev@ozlabs.org>
Subject: Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Date: Fri, 22 May 2009 09:08:27 -0600	[thread overview]
Message-ID: <fa686aa40905220808kecd06cdqb570b78ca97f0ca6@mail.gmail.com> (raw)
In-Reply-To: <4A16BAAE.3070401@grandegger.com>

Hi Wolfgang, thanks for the quick response.  Comments below...

On Fri, May 22, 2009 at 8:46 AM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> +++ net-next-2.6/Documentation/powerpc/dts-bindings/can/sja1000.txt
> @@ -0,0 +1,37 @@
> +Memory mapped SJA1000 CAN controller from NXP (formerly Philips)
> +
> +Required properties:
> +
> +- compatible : should be "nxp,sja1000".
> +- reg : should specify the chip select, address offset and size used
> + =A0 =A0 =A0 for the chip depending on the bus it is connected to.
> +- interrupts: property with a value describing the interrupt source
> + =A0 =A0 =A0 (number and sensitivity) for that device. The encoding depe=
nds
> + =A0 =A0 =A0 on the type of interrupt controller used.

Hmmm, "reg", "interrupts", and "interrupt-parent" are well understood
properties.  I don't think we need to keep boilerplate defining the
meaning every time a new binding is added.  (general musing; not an
ack or nack of this patch)

However, what should be defined is *what* the register range is (ie.
one tuple; location of device registers), and what the interrupts are
(ie. single tuple for device's irq line).  Granted this is a trivial
case, but in the case of devices with more than one address range or
irq line, the meaning of each tuple is critical information.  I think
it would be a good pattern to establish.

> +Optional properties:
> +
> +- interrupt-parent : the phandle for the interrupt controller that
> + =A0 =A0 =A0 services interrupts for that device.

Thinking further; I wouldn't even mention "interrupt-parent" here.
Anyone working with this stuff must already understand irq routing.

> +- clock-frequency : CAN system clock frequency in Hz, which is normally
> + =A0 =A0 =A0 half of the oscillator clock frequency. If not specified, a
> + =A0 =A0 =A0 default value of 8000000 (8 MHz) is used.

A clock-frequency property typically refers to the bus clock
frequency.  Something like can-frequency would be better.

> +- cdr-reg : value of the SJA1000 clock divider register according to
> + =A0 =A0 =A0 the SJA1000 data sheet. If not specified, a default value o=
f
> + =A0 =A0 =A0 0x48 is used.

Ewh.  The driver should be clueful enough to derive the clock divider
value given both the bus and can frequencies.  I don't like this
property.

> +- ocr-reg : value of the SJA1000 output control register according to
> + =A0 =A0 =A0 the SJA1000 data sheet. If not specified, a default value o=
f
> + =A0 =A0 =A0 0x0a is used.

Ditto here; the binding should describe the usage mode; not the
register settings to get the usage mode.  What sort of settings will
the .dts author be writing here?

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: Linux Netdev List
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	devicetree-discuss
	<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	linuxppc-dev
	<Linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Subject: Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Date: Fri, 22 May 2009 09:08:27 -0600	[thread overview]
Message-ID: <fa686aa40905220808kecd06cdqb570b78ca97f0ca6@mail.gmail.com> (raw)
In-Reply-To: <4A16BAAE.3070401-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>

Hi Wolfgang, thanks for the quick response.  Comments below...

On Fri, May 22, 2009 at 8:46 AM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> wrote:
> +++ net-next-2.6/Documentation/powerpc/dts-bindings/can/sja1000.txt
> @@ -0,0 +1,37 @@
> +Memory mapped SJA1000 CAN controller from NXP (formerly Philips)
> +
> +Required properties:
> +
> +- compatible : should be "nxp,sja1000".
> +- reg : should specify the chip select, address offset and size used
> +       for the chip depending on the bus it is connected to.
> +- interrupts: property with a value describing the interrupt source
> +       (number and sensitivity) for that device. The encoding depends
> +       on the type of interrupt controller used.

Hmmm, "reg", "interrupts", and "interrupt-parent" are well understood
properties.  I don't think we need to keep boilerplate defining the
meaning every time a new binding is added.  (general musing; not an
ack or nack of this patch)

However, what should be defined is *what* the register range is (ie.
one tuple; location of device registers), and what the interrupts are
(ie. single tuple for device's irq line).  Granted this is a trivial
case, but in the case of devices with more than one address range or
irq line, the meaning of each tuple is critical information.  I think
it would be a good pattern to establish.

> +Optional properties:
> +
> +- interrupt-parent : the phandle for the interrupt controller that
> +       services interrupts for that device.

Thinking further; I wouldn't even mention "interrupt-parent" here.
Anyone working with this stuff must already understand irq routing.

> +- clock-frequency : CAN system clock frequency in Hz, which is normally
> +       half of the oscillator clock frequency. If not specified, a
> +       default value of 8000000 (8 MHz) is used.

A clock-frequency property typically refers to the bus clock
frequency.  Something like can-frequency would be better.

> +- cdr-reg : value of the SJA1000 clock divider register according to
> +       the SJA1000 data sheet. If not specified, a default value of
> +       0x48 is used.

Ewh.  The driver should be clueful enough to derive the clock divider
value given both the bus and can frequencies.  I don't like this
property.

> +- ocr-reg : value of the SJA1000 output control register according to
> +       the SJA1000 data sheet. If not specified, a default value of
> +       0x0a is used.

Ditto here; the binding should describe the usage mode; not the
register settings to get the usage mode.  What sort of settings will
the .dts author be writing here?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2009-05-22 15:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22 14:46 [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver Wolfgang Grandegger
2009-05-22 15:08 ` Grant Likely [this message]
2009-05-22 15:08   ` Grant Likely
2009-05-23  6:29   ` Wolfgang Grandegger
2009-05-23  6:29     ` Wolfgang Grandegger
2009-05-23 16:44     ` Wolfgang Grandegger
2009-05-25  6:53       ` Grant Likely
2009-05-25  6:53         ` Grant Likely
2009-05-25  8:15         ` Wolfgang Grandegger
2009-05-23 11:15 ` Arnd Bergmann
2009-05-23 11:15   ` Arnd Bergmann
2009-05-23 16:51   ` Wolfgang Grandegger
2009-05-23 16:51     ` Wolfgang Grandegger
2009-05-24 22:27     ` Arnd Bergmann
2009-05-25  6:58       ` Wolfgang Grandegger
2009-05-25  6:58         ` Wolfgang Grandegger
2009-05-26  9:10         ` Arnd Bergmann
2009-05-26  9:10           ` Arnd Bergmann
2009-05-26  9:25           ` David Miller
2009-05-26  9:25             ` David Miller
2009-05-26  9:42             ` Arnd Bergmann
2009-05-26 11:20               ` Sascha Hauer
2009-05-26 11:20                 ` Sascha Hauer
2009-05-26 14:23             ` Wolfgang Grandegger
2009-05-30 17:59               ` Wolfgang Grandegger
2009-05-26  9:40           ` Benjamin Herrenschmidt
2009-05-26  9:40             ` Benjamin Herrenschmidt

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=fa686aa40905220808kecd06cdqb570b78ca97f0ca6@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=wg@grandegger.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 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.