linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jochen@scram.de (Jochen Friedrich)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: sa1100: Refactor mcp-sa11x0 to use platform resources.
Date: Tue, 17 Jan 2012 10:41:41 +0100	[thread overview]
Message-ID: <4F154255.2020605@scram.de> (raw)
In-Reply-To: <20120114092129.GO1068@n2100.arm.linux.org.uk>

Hi Russell,

On 14.01.2012 10:21, Russell King - ARM Linux wrote:

> I should have spotted this patch earlier.

Sorry for my late response as well.

> This is the obviously wrong approach - if you're having to add the same
> code to almost every board, then you're doing something wrong.

Accessing some random SoC registers and in the assabet case even board
specific registers from device drivers is even worse IMHO. We don't get 
a clean solution until we have a pinmux/pinctrl device driver owning 
these peripheral control registers. At least having the setup in the 
board files avoids a potential race condition accessing PPDR and PPSR 
registers from multiple drivers.

>
> Not only that, but...
>
>>   static struct resource sa11x0mcp_resources[] = {
>>   	[0] = {
>>   		.start	= __PREG(Ser4MCCR0),
>> -		.end	= __PREG(Ser4MCCR0) + 0xffff,
>> +		.end	= __PREG(Ser4MCCR0) + 0x1C - 1,
>
> Please leave this as +0xffff - we treat all devices has having 64K
> resources on sa11x0 platforms.  (It's possible that the registers
> repeat throughout the memory space.)

OK, but...

>>   		.flags	= IORESOURCE_MEM,
>>   	},
>>   	[1] = {
>> +		.start	= __PREG(Ser4MCCR1),
>> +		.end	= __PREG(Ser4MCCR1) + 0x4 - 1,
>> +		.flags	= IORESOURCE_MEM,
>> +	},

How to treat this case then? Here one register is "borrowed" from a 
different 64K block.
The old driver version didn't even register access to this memory space.

> 	void __iomem *
>
> Note the '__iomem'.  That must stay with the cookie.  Check your code
> with sparse.

OK, will do.

>> +	__raw_writel(priv->mccr0, priv->mccr0_base + MCCR0);
>
> writel?  writel_relaxed?

writel_relaxed should be fine. The old version didn't use any barriers, 
so I assume that's OK. I'll check if reorders would cause any problem.

>> +	size0 = res_mem0->end - res_mem0->start + 1;
>
> resource_size() ?

Jamie pointed me to this already. I'll change this.

>> +	priv->mccr0_base = ioremap(res_mem0->start, size0);
>> +	priv->mccr1_base = ioremap(res_mem1->start, size1);
>
> You want to oops the kernel?  Where's the error checking?

Good catch!

Thanks for the review,
Jochen

  reply	other threads:[~2012-01-17  9:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-27 21:00 [PATCH 1/2] ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus Jochen Friedrich
2011-11-27 21:00 ` [PATCH 2/2] ARM: sa1100: Refactor mcp-sa11x0 to use platform resources Jochen Friedrich
2012-01-14  9:21   ` Russell King - ARM Linux
2012-01-17  9:41     ` Jochen Friedrich [this message]
2012-01-17 20:12       ` Russell King - ARM Linux
2012-01-18 11:30         ` Jochen Friedrich
2012-01-18 11:48           ` Russell King - ARM Linux
2011-12-12 17:44 ` [PATCH 1/2] ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus Samuel Ortiz
2012-01-18 15:21 ` Russell King - ARM Linux
2012-01-20 17:11   ` Russell King - ARM Linux

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=4F154255.2020605@scram.de \
    --to=jochen@scram.de \
    --cc=linux-arm-kernel@lists.infradead.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).