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
prev 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).