From: Arnd Bergmann <arnd@arndb.de>
To: Wolfgang Denk <wd@denx.de>
Cc: kosmo@semihalf.com, dzu@denx.de, netdev@vger.kernel.org,
linuxppc-dev@ozlabs.org, agust@denx.de,
linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>
Subject: Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
Date: Wed, 27 Jan 2010 03:06:21 +0100 [thread overview]
Message-ID: <201001270306.22089.arnd@arndb.de> (raw)
In-Reply-To: <20100124164117.DCB483F6C0@gemini.denx.de>
On Sunday 24 January 2010, Wolfgang Denk wrote:
> In message <4B5C5BDF.6020001@grandegger.com> you wrote:
> >
> > You are probably right and your proposal would likely result in more
> > transparent (less ugly) code. There has been some discussion about
> > unifying FEC drivers when the patches (with the same subject) have been
> > submitted for the first time in May last year, but it was not about 512x
> > and 8xx, IIRC.
>
> You can re-read this discussion here:
>
> http://patchwork.ozlabs.org/patch/26927/
>
> ee especiall Grant's note of 2009-05-21 15:36:11: "If it looks too
> ugly, then just fork the driver."
Ok. I fully agree with what Grant said in that thread, especially the
way the files could be split. Forking the entire driver would work
as an easy way to get it running at first, and we still have the option
of reorganizing the duplicate parts later in a saner way if that's seen
as helpful. I'd assume that at least some parts of it could become a
lib_fs_enet module that can be shared by all of them.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Wolfgang Denk <wd@denx.de>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>,
dzu@denx.de, netdev@vger.kernel.org, linuxppc-dev@ozlabs.org,
agust@denx.de, kosmo@semihalf.com,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
Date: Wed, 27 Jan 2010 03:06:21 +0100 [thread overview]
Message-ID: <201001270306.22089.arnd@arndb.de> (raw)
In-Reply-To: <20100124164117.DCB483F6C0@gemini.denx.de>
On Sunday 24 January 2010, Wolfgang Denk wrote:
> In message <4B5C5BDF.6020001@grandegger.com> you wrote:
> >
> > You are probably right and your proposal would likely result in more
> > transparent (less ugly) code. There has been some discussion about
> > unifying FEC drivers when the patches (with the same subject) have been
> > submitted for the first time in May last year, but it was not about 512x
> > and 8xx, IIRC.
>
> You can re-read this discussion here:
>
> http://patchwork.ozlabs.org/patch/26927/
>
> ee especiall Grant's note of 2009-05-21 15:36:11: "If it looks too
> ugly, then just fork the driver."
Ok. I fully agree with what Grant said in that thread, especially the
way the files could be split. Forking the entire driver would work
as an easy way to get it running at first, and we still have the option
of reorganizing the duplicate parts later in a saner way if that's seen
as helpful. I'd assume that at least some parts of it could become a
lib_fs_enet module that can be shared by all of them.
Arnd
next prev parent reply other threads:[~2010-01-27 2:06 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 2:13 [net-next-2.6 PATCH 0/3] Support for MPC512x FEC Anatolij Gustschin
2010-01-21 2:13 ` Anatolij Gustschin
2010-01-21 2:13 ` [net-next-2.6 PATCH 1/3] fs_enet: use dev_xxx instead of printk Anatolij Gustschin
2010-01-21 2:13 ` Anatolij Gustschin
2010-01-21 16:43 ` Grant Likely
2010-01-21 16:43 ` Grant Likely
2010-01-21 2:13 ` [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver Anatolij Gustschin
2010-01-21 2:13 ` Anatolij Gustschin
2010-01-21 9:22 ` David Miller
2010-01-21 9:22 ` David Miller
2010-01-21 9:33 ` Anatolij Gustschin
2010-01-21 9:33 ` Anatolij Gustschin
2010-01-21 15:25 ` Wolfgang Grandegger
2010-01-21 15:25 ` Wolfgang Grandegger
2010-01-22 2:03 ` David Miller
2010-01-22 2:03 ` David Miller
2010-01-22 9:35 ` Wolfgang Grandegger
2010-01-22 9:35 ` Wolfgang Grandegger
2010-02-09 14:23 ` Anatolij Gustschin
2010-02-09 14:23 ` Anatolij Gustschin
2010-02-09 20:13 ` David Miller
2010-02-09 20:13 ` David Miller
2010-02-10 9:15 ` Wolfgang Grandegger
2010-02-10 9:15 ` Wolfgang Grandegger
2010-02-10 10:20 ` Wolfgang Grandegger
2010-02-10 10:20 ` Wolfgang Grandegger
2010-02-10 14:28 ` Grant Likely
2010-02-10 14:28 ` Grant Likely
2010-01-23 9:23 ` Arnd Bergmann
2010-01-23 9:23 ` Arnd Bergmann
2010-01-24 14:40 ` Wolfgang Grandegger
2010-01-24 14:40 ` Wolfgang Grandegger
2010-01-24 16:41 ` Wolfgang Denk
2010-01-24 16:41 ` Wolfgang Denk
2010-01-27 2:06 ` Arnd Bergmann [this message]
2010-01-27 2:06 ` Arnd Bergmann
2010-01-27 8:13 ` Wolfgang Grandegger
2010-01-27 8:13 ` Wolfgang Grandegger
2010-01-21 20:15 ` Wolfgang Grandegger
2010-01-21 20:15 ` Wolfgang Grandegger
2010-01-21 2:13 ` [net-next-2.6 PATCH 3/3] fs_enet: Add FEC TX Alignment workaround for MPC5121 Anatolij Gustschin
2010-01-21 2:13 ` Anatolij Gustschin
2010-01-21 16:49 ` Grant Likely
2010-01-21 16:49 ` Grant Likely
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=201001270306.22089.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=agust@denx.de \
--cc=davem@davemloft.net \
--cc=dzu@denx.de \
--cc=kosmo@semihalf.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=wd@denx.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 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.