From: Greg Ungerer <gerg@snapgear.com>
To: Philippe De Muyter <phdm@macqel.be>
Cc: Stany MARCEL <stany.marcel@novasys-ingenierie.com>,
linux-m68k@lists.linux-m68k.org, geert@linux-m68k.org
Subject: Re: [PATCH 3/3] Add support to M54xx DMA FEC Driver
Date: Thu, 6 Sep 2012 08:48:00 +1000 [thread overview]
Message-ID: <5047D6A0.7000005@snapgear.com> (raw)
In-Reply-To: <504758A4.1050607@snapgear.com>
On 09/05/2012 11:50 PM, Greg Ungerer wrote:
[snip]
>> I have checked my patch using a recent version of checkpatch.pl (not the
>> v3.5 version, because v3.5 version of checkpatch.pl fails with :
>> Nested quantifiers in regex; marked by <-- HERE in m/(\((?:[^\(\)]++
>> <-- HERE |(
>> ?-1))*\))/ at scripts/checkpatch.pl line 340.))
>>
>> and I am now at :
>> 464 WARNING: line over 80 characters
>> 90 WARNING: Use of volatile is usually wrong: see
>> Documentation/volatile-considered-harmful.txt
>>
>> Many "volatile" warnings are about such definitions :
>>
>> #define FEC_FECFRST(x) (*(volatile unsigned int *)(x +
>> 0x1C4))
>> which are afterwards used with
>>
>> + FEC_FECFRST(base_addr) |= FEC_SW_RST;
>> + FEC_FECFRST(base_addr) &= ~FEC_SW_RST;
>> + FEC_FECFRST(base_addr) |= FEC_SW_RST;
>> + FEC_FECFRST(base_addr) &= ~FEC_SW_RST;
>> + FEC_FECFRST(base_addr) |= FEC_SW_RST | FEC_RST_CTL;
>> + FEC_FECFRST(base_addr) &= ~FEC_SW_RST;
>>
>> Any advice about those ones ?
>
> I am glad you brought this one up :-)
> I really don't like the macro use for register access like this.
> What I much prefer is use of the standard read/write functions for this.
>
> So we have sane definitions for register offsets, eg:
>
> #define FEC_FECFRST 0x1c4
>
> And then use becomes something like:
>
> frst = __raw_readl(base_addr + FEC_FECFRST);
> __raw_writel(frst | FEC_SW_RST, base_addr + FEC_FECFRST);
> __raw_writel(frst & ~FEC_SW_RST, base_addr + FEC_FECFRST);
> ...
>
> Obviously you need to be careful of requirement to re-read the
> register, I just assumed it wasn't required for this example.
> And we can possibly optimize the address, but you get the idea.
>
> The keeps all the use of volatile hidden away like we want.
I should have been a little more careful here. The use of the
normal versions of the memory access functions is preferred.
So readl() instead of __raw_readl(), etc. Certainly within drivers
we should be using the standard readl/writel/... varients.
There are some situations on some platforms in m68k arch where you
may need to use one of the other variations.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
next prev parent reply other threads:[~2012-09-05 22:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 12:18 [PATCH 1/3] Add support to broadcom 5222 PHY Stany MARCEL
2012-08-21 12:18 ` [PATCH 2/3] Add support to Freescale M54xx Multi Channel DMA engine Stany MARCEL
2012-08-21 12:18 ` [PATCH 3/3] Add support to M54xx DMA FEC Driver Stany MARCEL
2012-08-21 12:18 ` Stany MARCEL
2012-08-28 5:51 ` Greg Ungerer
2012-08-28 5:51 ` Greg Ungerer
2012-09-05 9:14 ` Philippe De Muyter
2012-09-05 9:14 ` Philippe De Muyter
2012-09-05 10:48 ` RE : " Stany MARCEL
2012-09-05 10:48 ` Stany MARCEL
2012-09-05 11:25 ` Geert Uytterhoeven
2012-09-05 11:25 ` Geert Uytterhoeven
2012-09-05 13:50 ` Greg Ungerer
2012-09-05 22:48 ` Greg Ungerer [this message]
2012-08-23 10:47 ` [PATCH 1/3] Add support to broadcom 5222 PHY Geert Uytterhoeven
2012-08-23 12:34 ` Greg Ungerer
2012-08-23 12:34 ` Greg Ungerer
2012-08-23 15:25 ` Stany MARCEL
2012-08-23 15:25 ` Stany MARCEL
2012-08-23 15:21 ` Stany MARCEL
2012-08-23 15:37 ` Geert Uytterhoeven
2012-08-23 15:37 ` Geert Uytterhoeven
2012-08-23 16:02 ` Philippe De Muyter
2012-08-23 16:02 ` Philippe De Muyter
2012-08-23 22:01 ` Stany MARCEL
2012-08-23 22:01 ` Stany MARCEL
2012-08-23 15:21 ` Stany MARCEL
2012-08-23 10:47 ` Geert Uytterhoeven
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=5047D6A0.7000005@snapgear.com \
--to=gerg@snapgear.com \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=phdm@macqel.be \
--cc=stany.marcel@novasys-ingenierie.com \
/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.