From: Wolfgang Grandegger <wg@grandegger.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Wolfgang Denk <wd@denx.de>,
dzu@denx.de, netdev@vger.kernel.org, linuxppc-dev@ozlabs.org,
agust@denx.de, linuxppc-dev@lists.ozlabs.org,
David Miller <davem@davemloft.net>,
kosmo@semihalf.com
Subject: Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
Date: Wed, 27 Jan 2010 09:13:18 +0100 [thread overview]
Message-ID: <4B5FF59E.3090805@grandegger.com> (raw)
In-Reply-To: <201001270306.22089.arnd@arndb.de>
Arnd Bergmann wrote:
> 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.
Yes, I also vote for forking the driver allowing a clean implementation.
I don't think it makes sense to share a driver with the 8xx for the
reasons you already mentioned. And the 8xx is a dying out arch anyway.
Wolfgang.
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg@grandegger.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Wolfgang Denk <wd@denx.de>,
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 09:13:18 +0100 [thread overview]
Message-ID: <4B5FF59E.3090805@grandegger.com> (raw)
In-Reply-To: <201001270306.22089.arnd@arndb.de>
Arnd Bergmann wrote:
> 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.
Yes, I also vote for forking the driver allowing a clean implementation.
I don't think it makes sense to share a driver with the 8xx for the
reasons you already mentioned. And the 8xx is a dying out arch anyway.
Wolfgang.
next prev parent reply other threads:[~2010-01-27 8:14 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
2010-01-27 2:06 ` Arnd Bergmann
2010-01-27 8:13 ` Wolfgang Grandegger [this message]
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=4B5FF59E.3090805@grandegger.com \
--to=wg@grandegger.com \
--cc=agust@denx.de \
--cc=arnd@arndb.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.