From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfgang Denk <wd@denx.de>
Cc: linuxppc-dev@lists.ozlabs.org, Roman Fietze <roman.fietze@telemotive.de>
Subject: Re: [PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure
Date: Mon, 11 Jan 2010 14:20:46 -0700 [thread overview]
Message-ID: <fa686aa41001111320x53835478ie56d85a18e221631@mail.gmail.com> (raw)
In-Reply-To: <20100111204302.B42B23F6DA@gemini.denx.de>
On Mon, Jan 11, 2010 at 1:43 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
> In message <fa686aa41001111115g3451c9b9h4d6c551afd5698e1@mail.gmail.com> =
you wrote:
>>
>> Please don't. =A0I know that a lot of other 5200 code uses register map
>> structures in this way, but I consider it bad practice. =A0I coded this
>
> May I ask _why_ you consider this bad practice?
Many reasons. First off, while C structures somewhat represent the
layout of a hardware register set, I still find them a poor fit.
Registers do not data structures, and trying to describe them as such
causes problems. Not all devices get mapped onto the bus in the same
way. ie. a single device can get wired up with 8-bit wide addressing
on one system and 32 wide on another. A struct cannot encode this. I
also find I often need to access registers at "none-native" widths due
to implementation details of the device which is made messy when the
layout is encoded in a C struct. Finally, we're talking about a
hardware interface here. Driver authors must understand exactly what
they are doing when writing to registers and it is my opinion (though
others may disagree with me) that using structs to describe register
maps encourages a glosses over details that are best left explicit.
I used to prefer C structs for register definitions, but my opinion
changed as I gained more experience.
> Is a structure not the most natural way to encode the specifics of a
> hardware interface (address offet, bus width, etc.) in C?
>
> What do you recommend instead? =A0Using lists of register offsets
> (without any type information) as for example ARM is doing?
Yes, that is what I prefer. That and, when needed, device-specific
accessor functions that can be adapted for different bus attachements.
>> driver without a structure for a reason. =A0The reason I haven't removed
>
> Could you please explain this reason?
As described above.
> I'm trying to understand if this is a MPC52xx specific reasoning, or
> if you apply this to all of PowerPC, or generally to all kernel code?
I've stated what I prefer. I don't think I've rejected any code that
uses structs over register offsets, but I do apply friction on any
patch that changes a current driver from one to the other without
need.
> And: is this just your personal preferences, or generally agreed on?
Others will need to answer that.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2010-01-11 21:21 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 12:39 [PATCH] PowerPC: const intspec pointers Roman Fietze
2009-12-09 2:45 ` Benjamin Herrenschmidt
2009-12-11 6:07 ` Grant Likely
2009-12-11 6:13 ` Grant Likely
2009-12-15 10:59 ` Roman Fietze
2009-12-15 19:50 ` Grant Likely
2009-12-17 12:55 ` Roman Fietze
2009-12-22 0:11 ` Grant Likely
2009-12-22 6:55 ` [PATCH 0/13] MPC5200B LocalPlus Platform Driver Changes Roman Fietze
2009-12-22 6:57 ` [PATCH 01/13] powerpc/5200: LocalPlus driver: fix indentation and white space Roman Fietze
2010-01-11 19:06 ` Grant Likely
2009-12-22 6:59 ` [PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure Roman Fietze
2010-01-11 19:15 ` Grant Likely
2010-01-11 19:42 ` Scott Wood
2010-01-11 19:59 ` Grant Likely
2010-01-11 20:43 ` Wolfgang Denk
2010-01-11 21:20 ` Grant Likely [this message]
2010-01-12 7:06 ` Roman Fietze
2010-01-12 14:33 ` Grant Likely
2009-12-22 7:00 ` [PATCH 03/13] mpc52xx: add SCLPC register bit definitions Roman Fietze
2010-01-11 19:21 ` Grant Likely
2010-01-11 20:50 ` Wolfgang Denk
2010-01-12 7:55 ` Roman Fietze
2010-01-12 14:07 ` Grant Likely
2010-01-12 14:29 ` Grant Likely
2009-12-22 7:01 ` [PATCH 04/13] mpc52xx: LocalPlus driver: rewrite interrupt routines, fix errors Roman Fietze
2010-01-11 19:44 ` Grant Likely
2009-12-22 7:02 ` [PATCH 05/13] powerpc/5200: LocalPlus driver: fix DMA TX interrupt request Roman Fietze
2009-12-22 7:20 ` Grant Likely
2009-12-22 7:42 ` Roman Fietze
2009-12-22 7:04 ` [PATCH 06/13] powerpc/5200: LocalPlus driver: map and unmap DMA areas Roman Fietze
2010-01-11 19:57 ` Grant Likely
2009-12-22 7:05 ` [PATCH 07/13] powerpc/5200: LocalPlus driver: reset BestComm when committing new request Roman Fietze
2010-01-11 20:00 ` Grant Likely
2009-12-22 7:06 ` [PATCH 08/13] powerpc/5200: LocalPlus driver: smart flush of receive FIFO Roman Fietze
2010-01-11 20:06 ` Grant Likely
2009-12-22 7:08 ` [PATCH 09/13] powerpc/5200: LocalPlus driver: smarter calculation of BPT, bytes per transfer Roman Fietze
2010-01-11 20:15 ` Grant Likely
2009-12-22 7:09 ` [PATCH 10/13] powerpc/5200: LocalPlus driver: fix problem caused by unpredictable IRQ order Roman Fietze
2010-01-11 20:19 ` Grant Likely
2010-01-12 7:43 ` Roman Fietze
2009-12-22 7:10 ` [PATCH 11/13] powerpc/5200: LocalPlus driver: move RAM DMA address from request to driver Roman Fietze
2010-01-11 20:20 ` Grant Likely
2009-12-22 7:12 ` [PATCH 12/13] mpc52xx: add mpc5200-localplus-test LocalPlus test driver Roman Fietze
2009-12-22 7:13 ` [PATCH 13/13] powerpc/5200: LocalPlus driver: clean up comments Roman Fietze
2010-01-11 20:24 ` Grant Likely
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=fa686aa41001111320x53835478ie56d85a18e221631@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=roman.fietze@telemotive.de \
--cc=wd@denx.de \
/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).