linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: netdev@vger.kernel.org, U Bhaskar-B22300 <B22300@freescale.com>,
	socketcan-core@lists.berlios.de, Robin Holt <holt@sgi.com>,
	PPC list <linuxppc-dev@lists.ozlabs.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
Date: Tue, 25 Oct 2011 16:37:16 -0500	[thread overview]
Message-ID: <4EA72C0C.3000908@freescale.com> (raw)
In-Reply-To: <D79CB818-C14E-4C8D-9A8D-42B39ADE20B2@kernel.crashing.org>

On 10/18/2011 06:43 AM, Kumar Gala wrote:
> 
>>> Robin,
>>>
>>> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible?  Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
>>
>> The decision was due to the fact there is no true "generic" fsl.flexcan
>> chip free of any SOC implementation and therefore not something which
>> could be separately defined.  That decision was made by Grant Likely.
>> I will inline that email below.
>>
>> Robin
> 
> 
> Thanks, I'll look into this internally at FSL.  I think its confusing as hell to have "fsl,p1010-flexcan" in an ARM .dts

It's confusing to have devices labelled in vague ways that we can't tie
back to any real piece of hardware, or even a public architectural spec.
 If you're talking to our hardware people, ask them to put public names
and versions, guaranteed unique throughout FSL, on all of our logic
blocks -- with public block manuals that have any SW-relevant
integration parameters clearly itemized.

Why is putting "fsl,p1010-flexcan" an an ARM device any more confusing
than putting it on some PowerPC chip that is not a p1010?  Think of it
like a PCI ID, the actual value not being meaningful for much other than
its uniqueness and the ability to find a manual for the hardware.

This has been the recommended practice for quite some time.

> and don't think any reasonable ARM customer of FSL would know to put
> a PPC SOC name in their .dts.  

If an ARM device tree comes along that just has
"fsl,some-arm-chip-flexcan", so what?  Let the same driver bind against
both, again like PCI IDs.  Additional compatibles are mainly a
convenience to give things a chance to work before the driver is updated
(a frequent irritant with PCI IDs and new hardware).

Ideally we would be publishing a sample device tree for our ARM chips
and their peripherals, though. :-P

> I'll ask the HW guys what's going on
> so we can come up with a bit more generic name so we don't have to
> constantly change this.  Even if its just:
> 
> fsl,ppc-flexcan & fsl,arm-flexcan.

Why is CPU instruction set relevant?

Would a QorIQ customer think to check for an existing compatible in
mpc5xxx, or even mpc83xx or mpc86xx?

-Scott

      parent reply	other threads:[~2011-10-25 21:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-17  3:32 [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010) Robin Holt
2011-08-17  3:32 ` [PATCH v13 1/6] flexcan: Remove #include <mach/clock.h> Robin Holt
2011-08-17  3:32 ` [PATCH v13 2/6] flexcan: Abstract off read/write for big/little endian Robin Holt
2011-08-17  3:32 ` [PATCH v13 3/6] flexcan: Fix up fsl-flexcan device tree binding Robin Holt
2011-08-17  3:32 ` [PATCH v13 4/6] flexcan: Add of_match to platform_device definition Robin Holt
2011-08-17  3:32 ` [PATCH v13 5/6] flexcan: Prefer device tree clock frequency if available Robin Holt
2011-08-17  3:32 ` [PATCH v13 6/6] flexcan: Add flexcan device support for p1010rdb Robin Holt
2011-08-18  3:36 ` [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010) David Miller
2011-10-18  5:44 ` Kumar Gala
2011-10-18  7:13   ` Wolfgang Grandegger
2011-10-18  9:43   ` Robin Holt
2011-10-18 11:43     ` Kumar Gala
2011-10-18 11:48       ` Marc Kleine-Budde
2011-10-18 12:30       ` Robin Holt
2011-10-25 21:37       ` Scott Wood [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=4EA72C0C.3000908@freescale.com \
    --to=scottwood@freescale.com \
    --cc=B22300@freescale.com \
    --cc=davem@davemloft.net \
    --cc=galak@kernel.crashing.org \
    --cc=holt@sgi.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan-core@lists.berlios.de \
    /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).