From: Sam Ravnborg <sam@ravnborg.org>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, jeff@garzik.org,
John Rigby <jrigby@freescale.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] [Rev2] MPC5121 FEC support
Date: Tue, 17 Jun 2008 21:46:20 +0200 [thread overview]
Message-ID: <20080617194620.GA13147@uranus.ravnborg.org> (raw)
In-Reply-To: <48581113.4060101@freescale.com>
On Tue, Jun 17, 2008 at 02:31:31PM -0500, Scott Wood wrote:
> Sam Ravnborg wrote:
> >>+ data = of_get_property(ofdev->node, "fsl,align-tx-packets", &len);
> >>+ if (data && len == 4)
> >>+ fpi->align_tx_packets = *data;
> >>+
> >Where did "4" come from. USe a define with a desriptive name.
>
> It's sizeof(u32), i.e. one device tree cell. This is fairly normal.
Not fpr me at least - but I just review the patch out of context.
If it is sizeof(u32) why not write so?
>
> >> fpi->rx_ring = 32;
> >> fpi->tx_ring = 32;
> >Same for "32"
> >> fpi->rx_copybreak = 240;
> >Same for "240".
>
> They're arbitrary tuning parameters. How is a #define any more
> descriptive than the field name?
So it is clear they are tuneing parameters.
>
> Besides, that's pre-existing, and has nothing to do with this patch.
>
OK.
> >>--- a/drivers/net/fs_enet/fs_enet.h
> >>+++ b/drivers/net/fs_enet/fs_enet.h
> >>@@ -10,12 +10,17 @@
> >>
> >> #include <linux/fs_enet_pd.h>
> >> #include <asm/fs_pd.h>
> >>+#ifdef CONFIG_FS_ENET_MPC5121_FEC
> >>+#include "fec_mpc5121.h"
> >>+#endif
> >
> >Which is this include ifdeffed - looks like some wrong concept.
>
> This has already been discussed. There are two similar but different
> ethernet controllers that are being targeted, and the chips they are a
> part of (8xx and 512x) are already mutually exclusive with respect to
> multiplatform kernels due to core differences.
OK - had not seen it (or forgot).
>
> >The amount of ifdef introduced looks bad..
>
> Yes, it's bad -- but it's a matter of which is the lesser evil, a few
> ifdefs or large amounts of mostly duplicated code.
>
> >And try to run the patch through scripts/checkpatch.pl
> >And try to split it up a bit.
>
> Other than the fec_t thing, I don't see any needed splitting...
It was only the fec_t => struct fec change I had in mind.
Sam
next prev parent reply other threads:[~2008-06-17 19:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 19:08 [PATCH] [Rev2] MPC5121 FEC support John Rigby
2008-06-17 19:22 ` Sam Ravnborg
2008-06-17 19:31 ` Scott Wood
2008-06-17 19:46 ` Sam Ravnborg [this message]
2008-06-17 19:43 ` John Rigby
2008-06-17 19:57 ` Sam Ravnborg
2008-06-17 19:33 ` Scott Wood
2008-06-17 19:57 ` Sam Ravnborg
2008-06-17 20:03 ` Scott Wood
2008-06-17 21:00 ` Sam Ravnborg
2008-06-17 21:12 ` Scott Wood
2008-06-17 23:52 ` Trent Piepho
2008-06-18 5:00 ` Sam Ravnborg
2008-06-18 15:43 ` Scott Wood
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=20080617194620.GA13147@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=jeff@garzik.org \
--cc=jrigby@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=scottwood@freescale.com \
/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).