All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
Date: Thu, 18 Sep 2003 13:22:03 -0400	[thread overview]
Message-ID: <20030918172203.GA23194@nevyn.them.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1030918191604.20533C-100000@delta.ds2.pg.gda.pl>

On Thu, Sep 18, 2003 at 07:19:21PM +0200, Maciej W. Rozycki wrote:
> On Thu, 18 Sep 2003, Daniel Jacobowitz wrote:
> 
> > >  Is it OK for other PCI systems?
> > 
> > Yes, I think so.  Those two functions seem to have migrated in from
> > pci-hplj.c; they can't possibly compile, since they use constants only
> > defined in that file.
> 
>  Then the snippet should probably get removed altogether.
> 
> > >  Why do you want these suffixes?  They don't work for assembly sources.
> > 
> > Because otherwise uses of XKPHYS in a 32-bit kernel generate noisy
> > warnings.  I don't remember where it was offhand.  Wrap it in
> > __ASSEMBLY__ if you like.
> 
>  Hmm, but is there any use for XKPHYS, etc. in a 32-bit kernel at all? 
> The address cannot effectively be used anyway. 

That patch is a total hack/slash job.  You're probably right on both
counts.

Take a look at __ioremap_mode which probably needs some #ifdefs for
32-bit kernels.  It uses cpu_has_64bit_addresses, which means at
runtime it's OK, but we get a lot of warnings.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2003-09-18 17:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-18 16:33 ddb5477 fixes for 2.6 Daniel Jacobowitz
2003-09-18 17:04 ` Maciej W. Rozycki
2003-09-18 17:06   ` Daniel Jacobowitz
2003-09-18 17:19     ` Maciej W. Rozycki
2003-09-18 17:22       ` Daniel Jacobowitz [this message]
2003-09-21  9:21 ` Ralf Baechle

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=20030918172203.GA23194@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@linux-mips.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 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.