From: Greg Ungerer <gerg@snapgear.com>
To: Joe Perches <joe@perches.com>
Cc: <netdev@vger.kernel.org>, <linux-m68k@vger.kernel.org>,
Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH 2/2] net: add support for NS8390 based eth controllers on some ColdFire CPU boards
Date: Wed, 4 Jul 2012 16:18:25 +1000 [thread overview]
Message-ID: <4FF3E031.5040703@snapgear.com> (raw)
In-Reply-To: <1341379091.3627.15.camel@joe2Laptop>
Hi Joe,
On 04/07/12 15:18, Joe Perches wrote:
> On Wed, 2012-07-04 at 14:56 +1000, gerg@snapgear.com wrote:
>> From: Greg Ungerer <gerg@uclinux.org>
>>
>> A number of older ColdFire CPU based boards use NS8390 based network
>> controllers. Most use the Davicom 9008F or the UMC 9008F. This driver
>> provides the support code to get these devices working on these platforms.
>
> Hi Greg, just some trivia:
Thanks for the quick feedback!
> []
>
>> diff --git a/drivers/net/ethernet/8390/mcf8390.c b/drivers/net/ethernet/8390/mcf8390.c
>
> []
>
>> +#ifdef NE2000_ODDOFFSET
>> +/*
>> + * A lot of the ColdFire boards use a separate address region for odd offset
>> + * register addresses. The following macros and functions convert and map
>> + * as required. Note that the data port accesses are treated a little
>> + * differently, and always accessed via the insX/outsX functions.
>> + */
>> +#define NE_PTR(a) (((a) & 0x1) ? (NE2000_ODDOFFSET + (a) - 1) : (a))
>
> Maybe use static inlines instead of macros?
>
> static inline void *NE_PTR(void *ptr)
> {
> if ((unsigned long)ptr & 1)
> return ptr - 1 + NE2000_ODDOFFSET;
> return ptr;
> }
Ok, that looks better. Though I might make the arg u32, which matches
the way that the address is passed to the IO functions currently.
> []
>
>> +static void mcf8390_get_8390_hdr(struct net_device *dev,
>> + struct e8390_pkt_hdr *hdr, int ring_page)
>> +{
> []
>> + /*
>> + * This *shouldn't* happen.
>> + * If it does, it's the last thing you'll see
>> + */
>> + if (ei_status.dmaing) {
>> + netdev_err(dev,
>> + "%s: DMAing conflict [DMAstat:%d][irqlock:%d]\n",
>> + __func__, ei_local->dmaing, ei_local->irqlock);
>
> This message seems to get repeated a few times.
> Maybe another function/macro or maybe a BUG?
>
> some_dma_err(dev, __func__, ei_local);
Yep, sure thing. I copied that part "as is", and a few of the other
drivers seem to have it done this way too. No excuses though :-)
>> +static void mcf8390_block_input(struct net_device *dev, int count,
>> + struct sk_buff *skb, int ring_offset)
>> +{
> []
>> + /*
>> + * This *shouldn't* happen.
>> + * If it does, it's the last thing you'll see
>> + */
>> + if (ei_local->dmaing) {
>> + netdev_err(dev,
>> + "%s: DMAing conflict [DMAstat:%d][irqlock:%d]\n",
>> + __func__, ei_local->dmaing, ei_local->irqlock);
>> + return;
>> + }
>
>> +static void mcf8390_block_output(struct net_device *dev, int count,
>> + const unsigned char *buf,
>> + const int start_page)
>> +{
> []
>> + /*
>> + *This *shouldn't* happen.
>> + * If it does, it's the last thing you'll see
>> + */
>> + if (ei_local->dmaing) {
>> + netdev_err(dev,
>> + "%s: DMAing conflict [DMAstat:%d][irqlock:%d]\n",
>> + __func__, ei_local->dmaing, ei_local->irqlock);
>> + return;
>> + }
>
>> +static int mcf8390_init(struct net_device *dev)
>> +{
>> + static u32 offsets[] = {
>> + 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
>> + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
>> + };
>
> const? u8?
That is assigned to the "reg_offset" field of "struct ei_device"
(defined in the existing 8390.h) and that is:
u32 *reg_offset; /* Register mapping table */
So I can't change this.
>> + pr_debug("Found ethernet address: %pM\n", dev->dev_addr);
>
> netdev_dbg ?
Sure, will change it.
Thanks for the quick feedback, much appreciated.
I'll send a revised patch in 24 hours or so.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
next prev parent reply other threads:[~2012-07-04 6:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 4:56 [PATCH 0/2] net: support for NS8390 based ethernet on ColdFire CPU boards gerg
2012-07-04 4:56 ` [PATCH 1/2] m68knommu: move the badly named mcfne.h to a better mcf8390.h gerg
2012-07-04 4:56 ` [PATCH 2/2] net: add support for NS8390 based eth controllers on some ColdFire CPU boards gerg
2012-07-04 5:18 ` Joe Perches
2012-07-04 6:18 ` Greg Ungerer [this message]
2012-07-04 6:39 ` Joe Perches
2012-07-04 7:52 ` Geert Uytterhoeven
2012-07-04 8:06 ` Greg Ungerer
2012-07-04 14:52 ` Joe Perches
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=4FF3E031.5040703@snapgear.com \
--to=gerg@snapgear.com \
--cc=gerg@uclinux.org \
--cc=joe@perches.com \
--cc=linux-m68k@vger.kernel.org \
--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