All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hirokazu Takata <takata@linux-m32r.org>
To: Andrey Panin <pazke@donpac.ru>
Cc: linux-kernel@vger.kernel.org, takata@linux-m32r.org
Subject: Re: [PATCH] m32r - Upgrade to v2.6.6 kernel
Date: Sat, 29 May 2004 11:15:15 +0900	[thread overview]
Message-ID: <swf8yfc6kss.wl@renesas.com> (raw)
In-Reply-To: <20040528141540.GA12400@pazke>

From: Andrey Panin <pazke@donpac.ru>
> On 149, 05 28, 2004 at 09:21:49PM +0900, Hirokazu Takata wrote:
> > > 1)
> > > diff -ruN linux-2.6.6.org/arch/m32r/drivers/8390.c linux-2.6.6/arch/m32r/drivers/8390.c
> >  ...
> > > diff -ruN linux-2.6.6.org/arch/m32r/drivers/8390.h linux-2.6.6/arch/m32r/drivers/8390.h
> >  ...
> > > Is this really needed ?
> > 
> > These files are required for mappi_ne.c.
> > The mappi_ne.c is based on ne.c and modified for an eva board "mappi",
> > I think it is highly dependent on the target platform.
> > 
> > There are two reasons that we placed some m32r specific drivers in 
> > arch/m32r/drivers/:
> > - We think they are highly depends on the target platform, and
> 
> So we should merge m32r core first :)

Yes. I hope so. :)

> > - We can not merge them to drivers/ because the m32r architecture
> >   has not been supported by the mainline linux kernel.
> 
> We have many arch specific drivers in drivers/net already.

I see.

> > > 2) File arch/m32r/drivers/mappi_ne.c contains almost complete copy of drivers/net/ne.c
> > > with lots of code probably useless for your systems (old style ISA probing, ISAPnP 
> > > support etc.)
> > 
> > Yes.
> > 
> > > Also code like this is definetely unacceptable:
> > > 
> > > +#ifdef CONFIG_PLAT_MAPPI
> > > +		outb_p(0x4b, ioaddr + EN0_DCFG);
> > > +#elif CONFIG_PLAT_OAKS32R
> > > +		outb_p(0x48, ioaddr + EN0_DCFG);
> > > +#else
> > > +		outb_p(0x49, ioaddr + EN0_DCFG);
> > > +#endif
> > > 
> > > This fragment can be rewritten this way, with all  #ifdef mess hidden in the some header file:
> > > 
> > > +		outb_p(MY_MAGIC_OFFSET, ioaddr + EN0_DCFG);
> > 
> > Do you mean I should use drivers/net/ne.c instead of mappi_ne.c?
> > I'm not sure how can I merge such target-dependent code fragments to ne.c.
> > But I will try to merge them.
> 
> I didn't mean merging. My point is that general policy for linux kernel
> code is to avoid #ifdef cluttered code as much as possible. It's better
> to hide such code in header files.

OK. I understand.

--
Hirokazu Takata
Linux/M32R Project:  http://www.linux-m32r.org


      reply	other threads:[~2004-05-29  2:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-28  4:16 [PATCH] m32r - Upgrade to v2.6.6 kernel Hirokazu Takata
2004-05-28  7:23 ` Andrey Panin
2004-05-28  7:48   ` Russell King
2004-05-28 13:53     ` Hirokazu Takata
2004-06-02  2:40       ` Miles Bader
2004-05-28 12:21   ` Hirokazu Takata
2004-05-28 14:15     ` Andrey Panin
2004-05-29  2:15       ` Hirokazu Takata [this message]

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=swf8yfc6kss.wl@renesas.com \
    --to=takata@linux-m32r.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pazke@donpac.ru \
    /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.