From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
netdev@vger.kernel.org
Subject: Re: ixp4xx_hss modifications for 2x4 HDLC
Date: Wed, 25 Feb 2009 00:38:42 +0100 [thread overview]
Message-ID: <m33ae3h0cd.fsf@intrepid.localdomain> (raw)
In-Reply-To: <b0438a630902240447y7afe5510u7465804f94c0e22b@mail.gmail.com> ("Miguel Ángel Álvarez"'s message of "Tue\, 24 Feb 2009 13\:47\:27 +0100")
Hi,
Miguel Ángel Álvarez <gotzoncabanes@gmail.com> writes:
> I would appreciate your comments very much, because I think this
> functionallity is quite usefull and I would like to add it to the main
> kernel stream.
Well, I guess it's a bit like a proof of concept rather than
an applicable patch? :-)
And it's based on "chan" branch. This isn't good, the "chan" isn't yet
ready to go upstream, the interface isn't yet stable. It's really
experimental, based on undocumented behaviour etc. Do you need the
"channelized" feature? If not, perhaps you should stick to HDLC-only
David's net-next?
Ok. The following doesn't IMHO make sense:
> @@ -349,12 +294,58 @@
> .set_clock = hss_set_clock,
> .open = hss_open,
> .close = hss_close,
> - .txreadyq = 2,
> + .txreadyq = 32,
> + .hss = 0,
> + .hdlc = 0,
> }, {
> .set_clock = hss_set_clock,
> .open = hss_open,
> .close = hss_close,
> - .txreadyq = 19,
> + .txreadyq = 36,
> + .hss = 1,
> + .hdlc = 0,
> + }, {
> + .set_clock = hss_set_clock,
> + .open = hss_open,
> + .close = hss_close,
There are only two HSS devices on the chip. Not 8 :-)
> @@ -367,6 +358,30 @@
> .name = "ixp4xx_hss",
> .id = 1,
> .dev.platform_data = hss_plat + 1,
> + }, {
> + .name = "ixp4xx_hss",
> + .id = 2,
> + .dev.platform_data = hss_plat + 2,
> + }, {
> + .name = "ixp4xx_hss",
> + .id = 3,
> + .dev.platform_data = hss_plat + 3,
Same here.
This only needs a tiny change, increasing the number of HDLC devices
to 2 or 4 (for each HSS), adding the extra queue numbers etc.
This is completely orthogonal to:
a) clocks
b) channelized "services"
c) sync options (excluding 1024-bit max length).
The clock generator is a different thing and needs to be investigated.
Copying Intel's table doesn't make sense here (especially given the
internal clocks are rarely used). Do you need internal clocks?
Channelized thing needs a stable userspace interface first, it really
have to be discussed on netdev.
Sync options are simply independent.
I know I promised you I'll look at this stuff soon. Unfortunately, that
"soon" is a bit less "soon" than I though. Will look when able,
currently I'm really overwhelmed.
--
Krzysztof Halasa
next prev parent reply other threads:[~2009-02-24 23:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 12:47 ixp4xx_hss modifications for 2x4 HDLC Miguel Ángel Álvarez
2009-02-24 23:38 ` Krzysztof Halasa [this message]
2009-02-25 8:43 ` Miguel Ángel Álvarez
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=m33ae3h0cd.fsf@intrepid.localdomain \
--to=khc@pm.waw.pl \
--cc=gotzoncabanes@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox