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
next prev parent 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).