netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: vapier.adi@gmail.com
Cc: wg@grandegger.com, oe@port.de, netdev@vger.kernel.org,
	socketcan-core@lists.berlios.de,
	uclinux-dist-devel@blackfin.uclinux.org
Subject: Re: [Uclinux-dist-devel] [PATCH v3] add the driver for Analog Devices Blackfin on-chip CAN controllers
Date: Thu, 10 Dec 2009 13:37:29 -0800 (PST)	[thread overview]
Message-ID: <20091210.133729.42872813.davem@davemloft.net> (raw)
In-Reply-To: <8bd0f97a0912100258n6896b21er1d9525bb7dbf6aec@mail.gmail.com>

From: Mike Frysinger <vapier.adi@gmail.com>
Date: Thu, 10 Dec 2009 05:58:58 -0500

> On Thu, Dec 10, 2009 at 05:48, Wolfgang Grandegger wrote:
>> Wolfgang Grandegger wrote:
>>> Mike Frysinger wrote:
>>>> On Thu, Dec 10, 2009 at 04:11, Wolfgang Grandegger wrote:
>>>>> Well, I'm still not a friend of the following inline functions,
>>>>> especially the *one-liners* which are called just *once*. With the usage
>>>>> of structs they seem even more useless.
>>>> seems like it would make more sense to not even use the read/write
>>>> functions either. ^[,A ^[(Bjust declare the regs as volatile and assign/read
>>>> the struct directly.
>>>
>>> Two times no. Don't use volatile and proper accessor functions. See:
>>>
>>> http://lxr.linux.no/#linux+v2.6.32/Documentation/volatile-considered-harmful.txt
>>
>> I was just wondering if bfin_read/write16 would not be the proper
>> accessor functions. readw/writew seems to be implemented differently:
>>
>> http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/include/asm/io.h#L44
>>
>> Puh, they do an cli,nop,nop,sync..sti for the access. This also nicely
>> shows why accessor functions should be used to access device registers.
>>
>> Well, just curious. I don't really know the blackfin arch.
> 
> the common I/O functions need to account for issues surrounding the
> bus that has arbitrary devices memory mapped to it.  on-chip devices
> (like what we're talking about here) do not have these issues and so
> using the common functions is awful overhead.

Then create special accessors (perhaps with the same names as the
existing ones, but with "__" prepended) that lack all of the
interrupt disabling, syncs, etc.

Really it _is_ cleaner and makes your driver look a lot nicer.

  reply	other threads:[~2009-12-10 21:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10  7:27 [PATCH v3] add the driver for Analog Devices Blackfin on-chip CAN controllers Barry Song
     [not found] ` <1260430072-21106-1-git-send-email-21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-12-10  9:11   ` Wolfgang Grandegger
2009-12-10 10:04     ` [Uclinux-dist-devel] " Mike Frysinger
2009-12-10 10:05       ` Barry Song
2009-12-10 10:12         ` Mike Frysinger
     [not found]       ` <8bd0f97a0912100204gd2b09f6r2799d9f951d6b9e1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-10 10:20         ` Wolfgang Grandegger
2009-12-10 10:45           ` Mike Frysinger
     [not found]             ` <8bd0f97a0912100245k9930c90ke4b184da68a9f958-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-10 10:55               ` Wolfgang Grandegger
2009-12-10 11:04                 ` Mike Frysinger
2009-12-10 11:16                   ` Wolfgang Grandegger
2009-12-10 21:38                     ` David Miller
2009-12-10 10:48           ` Wolfgang Grandegger
2009-12-10 10:58             ` Mike Frysinger
2009-12-10 21:37               ` David Miller [this message]
2009-12-11  2:05                 ` Barry Song
2009-12-11  2:17                   ` Mike Frysinger
     [not found]                     ` <8bd0f97a0912101817x79a17d5dje21e2a2b4ad1fc58-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-11  4:00                       ` Barry Song
     [not found]                         ` <3c17e3570912102000vd30d452s2d6b6ae7d24f340f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-11  8:51                           ` Wolfgang Grandegger
     [not found]                 ` <20091210.133729.42872813.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2009-12-17  1:20                   ` Mike Frysinger
2009-12-10 11:06             ` [Uclinux-dist-devel] " Hennerich, Michael
     [not found]               ` <8A42379416420646B9BFAC9682273B6D0EDD9A3C-pcKY8lWzTjquVPpjEGsWsTcYPEmu4y7e@public.gmane.org>
2009-12-10 11:19                 ` Wolfgang Grandegger
     [not found]     ` <4B20BB36.50509-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2009-12-10 10:14       ` Barry Song
     [not found]         ` <3c17e3570912100214k4b3eb038u1108c82bfa346389-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-10 10:21           ` Wolfram Sang
     [not found]             ` <20091210102145.GA3097-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-12-10 10:25               ` Barry Song
2009-12-10 10:35         ` Wolfgang Grandegger

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=20091210.133729.42872813.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=oe@port.de \
    --cc=socketcan-core@lists.berlios.de \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=vapier.adi@gmail.com \
    --cc=wg@grandegger.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 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).