public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Abramo Bagnara <abramo@alsa-project.org>
To: "David S. Miller" <davem@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: unsigned long ioremap()?
Date: Fri, 04 May 2001 09:15:12 +0200	[thread overview]
Message-ID: <3AF25700.19889930@alsa-project.org> (raw)
In-Reply-To: <3AF10E80.63727970@alsa-project.org> <Pine.LNX.4.05.10105030852330.9438-100000@callisto.of.borg> <15089.979.650927.634060@pizda.ninka.net> <11718.988883128@redhat.com> <3AF12B94.60083603@alsa-project.org> <15089.63036.52229.489681@pizda.ninka.net>

"David S. Miller" wrote:
> 
> Abramo Bagnara writes:
>  > IMO this is a far less effective debugging strategy.
> 
> I agree with you.
> 
> But guess what driver authors are going to do?  They are going to cast
> the thing left and right.  And sure you can then search for that, but
> it isn't likely to make people fix this from the start.

We can easily find now the current misuses (I've already posted a
complete list some time ago) and ensure that authors will do the right
thing.

True benefits will come in future from to have a correct API (the only
point to remember is that ioremap returned value and readl arguments is
*not* a pointer, this is not questionable).

> 
> I suppose the point is that there is a fine line wrt. using APIs to
> influence people to "do the right thing", and this has been
> exemplified in several threads I've been involved in wrt. PCI dma
> and other topics. :-)
> 
> One final point, I want to reiterate that I believe:
> 
>         foo = readl(&regs->bar);
> 
> is perfectly legal and should not be discouraged and in particular,
> not made painful to do.

I disagree: regs it's not a dereferenceable thing and I think it's an
abuse of pointer type. You're keeping a pointer that need a big sign on
it saying "Don't dereference me", it's a mess.

However you might like to substitute this with:

#define fld_readl(cookie, str, fld) readl(cookie + (unsigned
long)&((struct str *) 0)->fld)

or without that, it's perfectly fine to have:

regs = (struct reg *) ioremap(addr, size);
foo = readl((unsigned long)&regs->bar);

It's a driver author matter of preference, that don't touch the fact
that API is correct.

However I've verified that often this lead to unexpected errors due to
different alignment on different architecture and this is why I
personally prefer constant offsets over structures fields.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

  reply	other threads:[~2001-05-04  7:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-03  6:55 unsigned long ioremap()? Geert Uytterhoeven
2001-05-03  7:08 ` David S. Miller
2001-05-03  7:18   ` Jeff Garzik
2001-05-03  7:29     ` C.Praveen
2001-05-03  7:46     ` Jonathan Lundell
2001-05-03  7:57       ` Geert Uytterhoeven
2001-05-03  7:53   ` Abramo Bagnara
2001-05-03  8:08     ` Jeff Garzik
2001-05-03  8:26       ` Geert Uytterhoeven
2001-05-03  8:39       ` Abramo Bagnara
2001-05-03  8:44         ` Jeff Garzik
2001-05-03  8:53           ` Abramo Bagnara
2001-05-03  9:45   ` David Woodhouse
2001-05-03  9:57     ` Abramo Bagnara
2001-05-04  0:22       ` David S. Miller
2001-05-04  7:15         ` Abramo Bagnara [this message]
2001-05-04  7:30           ` David S. Miller
2001-05-04 11:07             ` Abramo Bagnara
2001-05-04 13:53             ` Jonathan Lundell
2001-05-13 14:00           ` Jes Sorensen
2001-05-13 14:38             ` Abramo Bagnara
2001-05-03 10:02     ` David Woodhouse
2001-05-03  7:33 ` Jonathan Lundell

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=3AF25700.19889930@alsa-project.org \
    --to=abramo@alsa-project.org \
    --cc=davem@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=geert@linux-m68k.org \
    --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