From: David Gibson <david@gibson.dropbear.id.au>
To: Dan Malek <dan@mvista.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linuxppc-Embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: status of linuxppc_2_4_devel for ppc405gp
Date: Fri, 24 Aug 2001 16:03:21 +1000 [thread overview]
Message-ID: <20010824160321.B1324@zax> (raw)
In-Reply-To: <3B85E0D2.21BC306E@mvista.com>
On Fri, Aug 24, 2001 at 01:06:26AM -0400, Dan Malek wrote:
>
> David Gibson wrote:
> to break.
> >
> > Ah yes, I ran into that one when I started converting the ppc405_enet
> > driver to use ioremap() and in_beXX() instead of the godawful mess of
> > direct access and explicit eieio()s it uses now.
>
> Umm....what are you doing? Those registers are already mapped via
> ioremap(), so that isn't necessary. What you consider a "godawful mess"
> is a personal preference, and I prefer the programming style that
> currently exists. I don't have any love for the driver, but it
> certainly isn't a patch I would check in.......
>
> The only modification that _should_ be done is moving the generic
> on-board I/O mapping done during board initialization to be a specific
> ioremap() in the driver, and actually looking at the eieio() to ensure
> they are really necessary.
By "use ioremap()" I mean moving the mapping into an explicit
ioremap() in the driver and away from board setup just as you suggest
- in the process removing the assumption that the registers are always
mapped at a fixed virtual address (not particularly problematic, but
not necessary either). (I couldn't find where the mapping was made in
the board setup during a brief search, but I assume it is more-or-less
the equivalent of an io_block_mapping()).
Now, as a general rule registers which are accessed through ioremap()
should be accessed only with {in,out}_*() rather than assuming the
addresses can be dereferenced directly. Obviously the portability
reasons for this don't apply in the case of the ppc405 EMAC, but to my
mind it still makes sense to keep that convention for clarity. I
guess "godawful mess" is a bit of an overstatement in the case of this
driver - but anyone coming from the generic parts of the kernel is
likely to be conditioned to think that way, since in any portable
driver directly dereferencing pointers from ioremap() or equivalent
would be Just Plain Wrong.
Of course using in*() and out*() would generate more eieio()s than
necessary, and I could be convinced that's a problem, but my first
instinct is to suspect that they wouldn't make a significant
difference.
--
David Gibson | Microsoft: Making the easy things hard
david@gibson.dropbear.id.au | and the hard things buggy
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-08-24 6:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-22 10:22 status of linuxppc_2_4_devel for ppc405gp Stefan Roese
2001-08-22 12:30 ` Kenneth Johansson
2001-08-22 16:10 ` Dan Malek
2001-08-22 22:29 ` Phillip Lougher
2001-08-22 22:48 ` Dan Malek
2001-08-22 13:41 ` Benjamin Herrenschmidt
2001-08-22 13:32 ` Physically mapped FLASH David Updegraff
2001-08-22 10:32 ` Matt Porter
2001-08-22 16:06 ` status of linuxppc_2_4_devel for ppc405gp Dan Malek
[not found] ` <3B83E474.5B906F13@mvista.com>
2001-08-22 19:31 ` Dan Malek
2001-08-22 20:04 ` Benjamin Herrenschmidt
2001-08-23 0:40 ` David Gibson
2001-08-23 7:41 ` Benjamin Herrenschmidt
2001-08-23 11:08 ` Benjamin Herrenschmidt
2001-08-24 1:41 ` David Gibson
2001-08-24 5:06 ` Dan Malek
2001-08-24 6:03 ` David Gibson [this message]
2001-08-24 10:28 ` Benjamin Herrenschmidt
2001-08-25 2:53 ` Dan Malek
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=20010824160321.B1324@zax \
--to=david@gibson.dropbear.id.au \
--cc=benh@kernel.crashing.org \
--cc=dan@mvista.com \
--cc=linuxppc-embedded@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).