From: Andreas Schwab <schwab@linux-m68k.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux/m68k <linux-m68k@vger.kernel.org>,
"linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-api\@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [RFC v2 23/24] m68k/mac: Fix PRAM accessors
Date: Thu, 18 Jun 2015 18:52:44 +0200 [thread overview]
Message-ID: <87a8vxarhf.fsf@igel.home> (raw)
In-Reply-To: <alpine.LNX.2.00.1506152213340.12762@nippy.intranet> (Finn Thain's message of "Tue, 16 Jun 2015 13:10:29 +1000 (AEST)")
Finn Thain <fthain@telegraphics.com.au> writes:
> When I have reliable documentation I always define macros. So I agree that
> "command" bytes like 0x34 and 0x3800 should have names but what are the
> correct names? Are we constructing an opcode containing RTC register file
> addresses or are we issuing read/write accesses to chip registers?
Any name will do as long as the magic constant is not duplicated. It is
more important to document the relation between two uses than to have a
correct name (which can trivially be updated later).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
next prev parent reply other threads:[~2015-06-18 16:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 7:46 [RFC v2 00/24] Re-use nvram module Finn Thain
2015-06-14 7:46 ` [RFC v2 01/24] macintosh/nvram: Remove as unused Finn Thain
2015-06-15 6:41 ` [RFC,v2,01/24] " Michael Ellerman
2015-06-14 7:46 ` [RFC v2 02/24] scsi/atari_scsi: Dont select CONFIG_NVRAM Finn Thain
2015-06-14 7:46 ` [RFC v2 03/24] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain
2015-06-14 7:46 ` [RFC v2 04/24] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops Finn Thain
2015-06-14 7:46 ` [RFC v2 05/24] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain
2015-06-14 7:46 ` [RFC v2 06/24] char/nvram: Adopt arch_nvram_ops Finn Thain
2015-06-14 7:46 ` [RFC v2 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-06-14 7:46 ` [RFC v2 08/24] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain
2015-06-14 7:46 ` [RFC v2 09/24] char/nvram: Implement NVRAM read/write methods Finn Thain
2015-06-14 7:46 ` [RFC v2 10/24] char/nvram: Use generic fixed_size_llseek() Finn Thain
2015-06-14 7:46 ` [RFC v2 11/24] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-06-14 7:46 ` [RFC v2 12/24] char/nvram: Add "devname:nvram" module alias Finn Thain
2015-06-14 7:46 ` [RFC v2 13/24] powerpc: Cleanup nvram includes Finn Thain
2015-06-14 7:46 ` [RFC v2 14/24] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain
2015-06-14 7:46 ` [RFC v2 15/24] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports Finn Thain
2015-06-14 7:46 ` [RFC v2 16/24] powerpc: Implement nvram sync ioctl Finn Thain
2015-06-14 7:46 ` [RFC v2 17/24] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-06-14 7:46 ` [RFC v2 18/24] nvram: Drop nvram_* symbol exports and prototypes Finn Thain
2015-06-14 7:46 ` [RFC v2 19/24] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-06-14 7:46 ` [RFC v2 20/24] char/generic_nvram: Remove as unused Finn Thain
2015-06-14 7:46 ` [RFC v2 21/24] powerpc: Adopt nvram module for PPC64 Finn Thain
2015-06-14 7:46 ` [RFC v2 22/24] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain
2015-06-14 7:46 ` [RFC v2 23/24] m68k/mac: Fix PRAM accessors Finn Thain
2015-06-15 8:23 ` Geert Uytterhoeven
2015-06-16 3:10 ` Finn Thain
2015-06-18 4:49 ` Finn Thain
2015-06-18 6:59 ` Geert Uytterhoeven
2015-06-18 16:52 ` Andreas Schwab [this message]
2015-06-14 7:46 ` [RFC v2 24/24] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain
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=87a8vxarhf.fsf@igel.home \
--to=schwab@linux-m68k.org \
--cc=fthain@telegraphics.com.au \
--cc=geert@linux-m68k.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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).