From: Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
To: Mans Rullgard <mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
Cc: DT <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sebastian Frias
<sebastian_frias-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>,
Thibaud Cornic
<thibaud_cornic-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>,
Mason <slash.tmp-GANU6spQydw@public.gmane.org>
Subject: Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller
Date: Mon, 26 Oct 2015 10:34:12 +0100 [thread overview]
Message-ID: <562DF394.3030500@sigmadesigns.com> (raw)
In-Reply-To: <yw1xio5xg0rq.fsf-OEaqT8BN2ezZK2NkWkPsZwC/G2K4zDHf@public.gmane.org>
On 23/10/2015 15:41, Måns Rullgård wrote:
> Marc Gonzalez wrote:
>
>> On 22/10/2015 16:02, Mans Rullgard wrote:
>>
>>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
>>> using the "aurora,nb8800" compatible string. When used in Sigma
>>> Designs chips a few additional control registers are available.
>>> This variant is indicated by the "sigma,smp8640-ethernet" compatible
>>> string.
>>
>> I've been meaning to ask a noob question to the devicetree group
>> about how names for compatible strings are chosen.
>>
>> Sigma Designs has two active SoC families, Tango3 (which consists of
>> about a dozen MIPS-based SoCs, typically named SMP86xx) and Tango4
>> (a few ARM-based SoCs, typically named SMP87xx). I should note that
>> there is no SMP8640 SoC AFAIK, rather SMP864x is a Tango3 sub-family
>> (I could locate 42,43,44,45,46).
Just to make things a bit more confusing, I learned that Sigma made
one MIPS-based Tango4 SoC...
>> AFAIK, all our SoCs are using the same Aurora NB8800 Ethernet MAC,
>> along with the extra features. I find it odd to use a specific SoC
>> model to refer to this device, instead of a more generic name.
>> (It's weird having to mention smp8640 in the tango4 DT.)
>
> I picked 8640 since all 8640 or higher chips are compatible (863x chips
> (tango2) are not). Some of the later versions have additional extra
> features, but they all work with the basic driver.
According to my branch's FAEs, the first Tango3 was SMP8644. I showed
the DT to a colleague, and his reaction was: "Don't use smp8640, it will
confuse other engineers, Sigma didn't make a 8640 SoC."
http://www.qobuz.com/info/IMG/pdf/SMP8643.pdf
Would you be willing to change the compatible string to
"sigma,smp8644-foo" or "sigma,smp864x-foo" ?
If it's not possible, I suppose I can add comments in the DT, to clear
the potential confusion for Sigma engineers.
> There also appear to be some differences (bug fixes?) between 8643 and
> 8759 (the ones I have) not documented anywhere.
Suppose you identify these differences, and you make the appropriate
changes to the driver. What compatible string would you use to refer
to the new features? I used "sigma,tango4-ethernet" but IIUC it must
be more specific, such as the first Tango4 chip to implement these
changes (I guess that would be the SMP8734).
So I should write something like this in my DT?
eth0: ethernet@26000 {
compatible = "sigma,smp8734-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800";
Hmmm, you mention this below, but you used "sigma,smp8759-ethernet".
What about earlier chips?
>> Would it be possible to have a compatible string which makes it
>> clear that it is an Aurora MAC with vendor-specific tweaks?
>> Something like "sigma,aurora-nb8800-mac" ?
>
> This doesn't indicate which Sigma modifications are present. If the
> driver is at some point modified to take advantage of features/fixes in
> newer chips, it's good to have a naming scheme that can accommodate
> that.
>
> For the SMP8759 devicetree, one could set the compatible list to
> "sigma,smp8759-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800"
> indicating the exact device even if the driver currently doesn't care,
> that it is compatible with the 8640 baseline, and finally the plain
> aurora as a last fallback.
[Preserved for context]
Regards.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
To: Mans Rullgard <mans@mansr.com>
Cc: DT <devicetree@vger.kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
<linux-kernel@vger.kernel.org>,
Sebastian Frias <sebastian_frias@sigmadesigns.com>,
Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
Mason <slash.tmp@free.fr>
Subject: Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller
Date: Mon, 26 Oct 2015 10:34:12 +0100 [thread overview]
Message-ID: <562DF394.3030500@sigmadesigns.com> (raw)
In-Reply-To: <yw1xio5xg0rq.fsf@unicorn.mansr.com>
On 23/10/2015 15:41, Måns Rullgård wrote:
> Marc Gonzalez wrote:
>
>> On 22/10/2015 16:02, Mans Rullgard wrote:
>>
>>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
>>> using the "aurora,nb8800" compatible string. When used in Sigma
>>> Designs chips a few additional control registers are available.
>>> This variant is indicated by the "sigma,smp8640-ethernet" compatible
>>> string.
>>
>> I've been meaning to ask a noob question to the devicetree group
>> about how names for compatible strings are chosen.
>>
>> Sigma Designs has two active SoC families, Tango3 (which consists of
>> about a dozen MIPS-based SoCs, typically named SMP86xx) and Tango4
>> (a few ARM-based SoCs, typically named SMP87xx). I should note that
>> there is no SMP8640 SoC AFAIK, rather SMP864x is a Tango3 sub-family
>> (I could locate 42,43,44,45,46).
Just to make things a bit more confusing, I learned that Sigma made
one MIPS-based Tango4 SoC...
>> AFAIK, all our SoCs are using the same Aurora NB8800 Ethernet MAC,
>> along with the extra features. I find it odd to use a specific SoC
>> model to refer to this device, instead of a more generic name.
>> (It's weird having to mention smp8640 in the tango4 DT.)
>
> I picked 8640 since all 8640 or higher chips are compatible (863x chips
> (tango2) are not). Some of the later versions have additional extra
> features, but they all work with the basic driver.
According to my branch's FAEs, the first Tango3 was SMP8644. I showed
the DT to a colleague, and his reaction was: "Don't use smp8640, it will
confuse other engineers, Sigma didn't make a 8640 SoC."
http://www.qobuz.com/info/IMG/pdf/SMP8643.pdf
Would you be willing to change the compatible string to
"sigma,smp8644-foo" or "sigma,smp864x-foo" ?
If it's not possible, I suppose I can add comments in the DT, to clear
the potential confusion for Sigma engineers.
> There also appear to be some differences (bug fixes?) between 8643 and
> 8759 (the ones I have) not documented anywhere.
Suppose you identify these differences, and you make the appropriate
changes to the driver. What compatible string would you use to refer
to the new features? I used "sigma,tango4-ethernet" but IIUC it must
be more specific, such as the first Tango4 chip to implement these
changes (I guess that would be the SMP8734).
So I should write something like this in my DT?
eth0: ethernet@26000 {
compatible = "sigma,smp8734-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800";
Hmmm, you mention this below, but you used "sigma,smp8759-ethernet".
What about earlier chips?
>> Would it be possible to have a compatible string which makes it
>> clear that it is an Aurora MAC with vendor-specific tweaks?
>> Something like "sigma,aurora-nb8800-mac" ?
>
> This doesn't indicate which Sigma modifications are present. If the
> driver is at some point modified to take advantage of features/fixes in
> newer chips, it's good to have a naming scheme that can accommodate
> that.
>
> For the SMP8759 devicetree, one could set the compatible list to
> "sigma,smp8759-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800"
> indicating the exact device even if the driver currently doesn't care,
> that it is compatible with the 8640 baseline, and finally the plain
> aurora as a last fallback.
[Preserved for context]
Regards.
next prev parent reply other threads:[~2015-10-26 9:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 14:02 [PATCH 1/3] devicetree: add vendor prefix for Aurora VLSI Mans Rullgard
2015-10-22 14:02 ` Mans Rullgard
2015-10-22 14:02 ` [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller Mans Rullgard
[not found] ` <1445522558-5808-2-git-send-email-mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
2015-10-22 14:34 ` Rob Herring
2015-10-22 14:34 ` Rob Herring
2015-10-23 12:10 ` Marc Gonzalez
2015-10-23 12:10 ` Marc Gonzalez
[not found] ` <562A23B9.3090208-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
2015-10-23 13:28 ` Rob Herring
2015-10-23 13:28 ` Rob Herring
2015-10-23 13:41 ` Måns Rullgård
2015-10-23 13:41 ` Måns Rullgård
2015-10-23 13:57 ` Marc Gonzalez
2015-10-23 13:57 ` Marc Gonzalez
[not found] ` <562A3CD2.3050903-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
2015-10-23 14:06 ` Måns Rullgård
2015-10-23 14:06 ` Måns Rullgård
[not found] ` <yw1xio5xg0rq.fsf-OEaqT8BN2ezZK2NkWkPsZwC/G2K4zDHf@public.gmane.org>
2015-10-26 9:34 ` Marc Gonzalez [this message]
2015-10-26 9:34 ` Marc Gonzalez
[not found] ` <562DF394.3030500-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
2015-10-26 12:05 ` Måns Rullgård
2015-10-26 12:05 ` Måns Rullgård
[not found] ` <yw1x1tchg7i6.fsf-OEaqT8BN2ezZK2NkWkPsZwC/G2K4zDHf@public.gmane.org>
2015-10-26 13:28 ` Marc Gonzalez
2015-10-26 13:28 ` Marc Gonzalez
2015-10-26 13:54 ` Måns Rullgård
2015-10-26 13:54 ` Måns Rullgård
2015-10-26 14:05 ` Marc Gonzalez
2015-10-26 14:05 ` Marc Gonzalez
2015-10-26 14:11 ` Måns Rullgård
2015-10-26 14:11 ` Måns Rullgård
2015-10-22 14:02 ` [PATCH 3/3] net: ethernet: add driver " Mans Rullgard
2015-10-22 14:41 ` David Miller
2015-10-22 17:18 ` Måns Rullgård
2015-10-22 14:55 ` kbuild test robot
2015-10-22 22:08 ` kbuild test robot
2015-10-23 0:31 ` Florian Fainelli
2015-10-23 15:20 ` Måns Rullgård
2015-10-23 17:36 ` Florian Fainelli
2015-10-24 15:45 ` Måns Rullgård
2015-10-22 14:35 ` [PATCH 1/3] devicetree: add vendor prefix for Aurora VLSI Rob Herring
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=562DF394.3030500@sigmadesigns.com \
--to=marc_gonzalez-y1yr0z3oicc7zzzrdbgcua@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sebastian_frias-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org \
--cc=slash.tmp-GANU6spQydw@public.gmane.org \
--cc=thibaud_cornic-y1yR0Z3OICC7zZZRDBGcUA@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.