public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Brian Gerst <brgerst@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Why is ARCH m68k hardwired into drivers/net/wan/Makefile?
Date: Mon, 21 Dec 2009 16:54:43 -0600	[thread overview]
Message-ID: <200912211654.43710.rob@landley.net> (raw)
In-Reply-To: <73c1f2160912210648j2a8790b6ue611503ef931a77b@mail.gmail.com>

On Monday 21 December 2009 08:48:31 Brian Gerst wrote:
> On Mon, Dec 21, 2009 at 3:04 AM, Rob Landley <rob@landley.net> wrote:
> > On Monday 21 December 2009 01:06:38 Brian Gerst wrote:
> >> On Mon, Dec 21, 2009 at 12:42 AM, Rob Landley <rob@landley.net> wrote:
> >> > Anyone have an opinion on this?
> >> >
> >> > From drivers/net/wan/Makefile:
> >> >>ifeq ($(ARCH),m68k)
> >> >>  AS68K = $(AS)
> >> >>  LD68K = $(LD)
> >> >>else
> >> >>  AS68K = as68k
> >> >>  LD68K = ld68k
> >> >>endif
> >>
> >> Looks like it's to build firmware to run on the card.
> >
> > Sure, I'm just wondering why such obvious arch-specific code is outside
> > the arch/m68k directory.
> >
> > In theory, when you're building for m68k, you supply appropriate AS and
> > LD values already (or the rest of the kernel won't build).  If you're not
> > building for m68k and this driver only supports m68k, then the config
> > should prevent you from selecting it.  So why is on earth is
> > architecture-specific tool selection being done in drivers/net/wan?
>
> The m68k processor that this firmware is being built for is embedded
> on the device, not the main system cpu.  You can have one of these
> cards on any system, not just m68k.
>
> PS. always CC the list with replies.

Happy to, but your message to me didn't cc the list, and I thought cc-ing 
private mail back to the list was impolite.

Explicitly saying somewhere "this card has an onbaord m68k processor even if 
the host doesn't" might be nice.  I eventually figured it out, but neither the 
makefile nor the firmware source actually said the card had an onboard 
processor, and my first glance at the kconfig help text just went "it's code for 
a QUICC processor, that's one of those freescale SoCs isnt it?  I vaguely 
recall booting Linux on one of those back in 2006..."

(Possibly I've been doing a bit too much embedded development lately. :)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

  reply	other threads:[~2009-12-21 22:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-21  5:42 Why is ARCH m68k hardwired into drivers/net/wan/Makefile? Rob Landley
2009-12-21  9:57 ` Geert Uytterhoeven
2009-12-21 22:46   ` Rob Landley
     [not found] ` <73c1f2160912202306y8e3e394mb3b4ddcf24caacc1@mail.gmail.com>
     [not found]   ` <200912210204.08583.rob@landley.net>
2009-12-21 14:48     ` Brian Gerst
2009-12-21 22:54       ` Rob Landley [this message]
2009-12-22 15:45         ` Krzysztof Halasa

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=200912211654.43710.rob@landley.net \
    --to=rob@landley.net \
    --cc=brgerst@gmail.com \
    --cc=linux-kernel@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