All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org,
	linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] MPC8xx PCMCIA driver
Date: Tue, 30 Aug 2005 00:33:00 -0400	[thread overview]
Message-ID: <4313E17C.4040401@pobox.com> (raw)
In-Reply-To: <20050830035338.GA5755@dmt.cnet>

Marcelo Tosatti wrote:
> On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
> 
>>Marcelo Tosatti wrote:
>>
>>>+static int voltage_set(int slot, int vcc, int vpp)
>>>+{
>>>+	u_int reg = 0;
>>>+
>>>+	switch(vcc) {
>>>+	case 0: break;
>>>+	case 33:
>>>+		reg |= BCSR1_PCVCTL4;
>>>+		break;
>>>+	case 50: 
>>>+		reg |= BCSR1_PCVCTL5;
>>>+		break;
>>>+	default: 
>>>+		return 1;
>>>+	}
>>>+
>>>+	switch(vpp) {
>>>+	case 0: break;
>>>+	case 33: 
>>>+	case 50:
>>>+		if(vcc == vpp)
>>>+			reg |= BCSR1_PCVCTL6;
>>>+		else
>>>+			return 1;
>>>+		break;
>>>+	case 120: 
>>>+		reg |= BCSR1_PCVCTL7;
>>>+	default:
>>>+		return 1;
>>>+	}
>>>+
>>>+	if(!((vcc == 50) || (vcc == 0)))
>>>+		return 1;
>>>+
>>>+	/* first, turn off all power */
>>>+
>>>+	*((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
>>>+				     | BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
>>>+
>>>+	/* enable new powersettings */
>>>+
>>>+	*((uint *)RPX_CSR_ADDR) |= reg;
>>
>>Should use bus read/write functions, such as foo_readl() or iowrite32().
> 
> 
> The memory map structure which contains device configuration/registers
> is _always_ directly mapped with pte's (the 8xx is a chip with builtin
> UART/network/etc functionality).
> 
> I don't think there is a need to use read/write acessors.

There are multiple reasons:

* Easier reviewing.  One cannot easily distinguish between writing to 
normal kernel virtual memory and "magic" memory that produces magicaly 
side effects such as initiating DMA of a net packet.

* Compiler safety.  As the code is written now, you have no guarantees 
that the compiler won't combine two stores to the same location, etc. 
Accessor macros are a convenient place to add compiler barriers or 
'volatile' notations that the MPC8xx code lacks.

* Maintainable.  foo_read[bwl] or foo_read{8,16,32} are preferred 
because that's the way other bus accessors look like -- yes even 
embedded SoC buses benefit from these code patterns.  You want your 
driver to look like other drivers as much as possible.

* Convenience.  The accessors can be a zero overhead memory read/write 
at a minimum.  But they can also be convenient places to use special 
memory read/write instructions that specify uncached memop, compiler 
barriers, memory barriers, etc.

Regards,

	Jeff

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>,
	linux-kernel@vger.kernel.org,
	Russell King <rmk+lkml@arm.linux.org.uk>,
	Dan Malek <dan@embeddededge.com>,
	Pantelis Antoniou <panto@intracom.gr>
Subject: Re: [PATCH] MPC8xx PCMCIA driver
Date: Tue, 30 Aug 2005 00:33:00 -0400	[thread overview]
Message-ID: <4313E17C.4040401@pobox.com> (raw)
In-Reply-To: <20050830035338.GA5755@dmt.cnet>

Marcelo Tosatti wrote:
> On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
> 
>>Marcelo Tosatti wrote:
>>
>>>+static int voltage_set(int slot, int vcc, int vpp)
>>>+{
>>>+	u_int reg = 0;
>>>+
>>>+	switch(vcc) {
>>>+	case 0: break;
>>>+	case 33:
>>>+		reg |= BCSR1_PCVCTL4;
>>>+		break;
>>>+	case 50: 
>>>+		reg |= BCSR1_PCVCTL5;
>>>+		break;
>>>+	default: 
>>>+		return 1;
>>>+	}
>>>+
>>>+	switch(vpp) {
>>>+	case 0: break;
>>>+	case 33: 
>>>+	case 50:
>>>+		if(vcc == vpp)
>>>+			reg |= BCSR1_PCVCTL6;
>>>+		else
>>>+			return 1;
>>>+		break;
>>>+	case 120: 
>>>+		reg |= BCSR1_PCVCTL7;
>>>+	default:
>>>+		return 1;
>>>+	}
>>>+
>>>+	if(!((vcc == 50) || (vcc == 0)))
>>>+		return 1;
>>>+
>>>+	/* first, turn off all power */
>>>+
>>>+	*((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
>>>+				     | BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
>>>+
>>>+	/* enable new powersettings */
>>>+
>>>+	*((uint *)RPX_CSR_ADDR) |= reg;
>>
>>Should use bus read/write functions, such as foo_readl() or iowrite32().
> 
> 
> The memory map structure which contains device configuration/registers
> is _always_ directly mapped with pte's (the 8xx is a chip with builtin
> UART/network/etc functionality).
> 
> I don't think there is a need to use read/write acessors.

There are multiple reasons:

* Easier reviewing.  One cannot easily distinguish between writing to 
normal kernel virtual memory and "magic" memory that produces magicaly 
side effects such as initiating DMA of a net packet.

* Compiler safety.  As the code is written now, you have no guarantees 
that the compiler won't combine two stores to the same location, etc. 
Accessor macros are a convenient place to add compiler barriers or 
'volatile' notations that the MPC8xx code lacks.

* Maintainable.  foo_read[bwl] or foo_read{8,16,32} are preferred 
because that's the way other bus accessors look like -- yes even 
embedded SoC buses benefit from these code patterns.  You want your 
driver to look like other drivers as much as possible.

* Convenience.  The accessors can be a zero overhead memory read/write 
at a minimum.  But they can also be convenient places to use special 
memory read/write instructions that specify uncached memop, compiler 
barriers, memory barriers, etc.

Regards,

	Jeff



  parent reply	other threads:[~2005-08-30  4:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30  2:48 [PATCH] MPC8xx PCMCIA driver Marcelo Tosatti
2005-08-30  2:48 ` Marcelo Tosatti
2005-08-30  3:39 ` Jeff Garzik
2005-08-30  3:39   ` Jeff Garzik
2005-08-30  3:53   ` Marcelo Tosatti
2005-08-30  3:53     ` Marcelo Tosatti
2005-08-30  4:32     ` Paul Mackerras
2005-08-30  4:32       ` Paul Mackerras
2005-08-30 15:07       ` Marcelo Tosatti
2005-08-30 15:07         ` Marcelo Tosatti
2005-08-30  4:33     ` Jeff Garzik [this message]
2005-08-30  4:33       ` Jeff Garzik
2005-08-30  7:06 ` Russell King
2005-08-30  7:06   ` Russell King
2005-09-01  8:53 ` Dominik Brodowski
2005-09-01  8:53   ` Dominik Brodowski
2005-09-01 11:44   ` Magnus Damm
2005-09-01 11:44     ` Magnus Damm
2005-09-01 14:51   ` Marcelo Tosatti
2005-09-14 14:11   ` Marcelo Tosatti
2005-09-14 14:27     ` Dominik Brodowski
2005-09-14 14:27       ` Dominik Brodowski
2005-09-14 18:21       ` Marcelo Tosatti
2005-09-14 18:21         ` Marcelo Tosatti
2005-09-14 18:46         ` Jeff Garzik
2005-09-14 18:46           ` Jeff Garzik

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=4313E17C.4040401@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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.