From: Finn Thain <fthain@telegraphics.com.au> To: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64 Date: Fri, 4 Jan 2019 19:45:58 +1100 (AEDT) [thread overview] Message-ID: <alpine.LNX.2.21.1901041850170.9@nippy.intranet> (raw) In-Reply-To: <CAK8P3a3OD9ou=y+PaZ03v-ivW4A3fwwzA+aL+CoJDd_L2vTMLA@mail.gmail.com> On Mon, 31 Dec 2018, Arnd Bergmann wrote: > On Sun, Dec 30, 2018 at 4:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > > > On Sat, 29 Dec 2018, Arnd Bergmann wrote: > > > > > With the current method, it does seem odd to have a single > > > per-architecture instance of the exported structure containing > > > function pointers. This doesn't give us the flexibility of having > > > multiple copies in the kernel the way that ppc_md does, but it adds > > > overhead compared to simply exporting the functions directly. > > > > > > > You're right, there is overhead here. > > > > With a bit of auditing, wrappers like the one you quoted (which merely > > checks whether or not a ppc_md method is implemented) could surely be > > avoided. > > > > The arch_nvram_ops methods are supposed to optional (that is, they are > > allowed to be NULL). > > > > We could call exactly the same function pointers though either ppc_md > > or arch_nvram_ops. That would avoid the double indirection. > > I think you can have a 'const' structure in the __ro_after_init section, > so without changing anything else, powerpc could just copy the function > pointers from ppc_md into the arch_nvram_ops at early init time, which > should ideally simplify your implementation as well. > Does this require removing the 'const' from the powerpc arch_nvram_ops definition? That would mean removing the 'const' from the declaration in nvram.h, which means removing 'const' for every other instance of that struct too. That's what happened when I tried removing the ppc_md.nvram_* methods entirely and assigning the same function pointers to arch_nvram_ops methods instead. Apparently all instances of arch_nvram_ops have to be const or none of them. Otherwise gcc says, "error: conflicting type qualifiers for 'arch_nvram_ops'". -- > Arnd >
WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@telegraphics.com.au> To: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, Paul Mackerras <paulus@samba.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64 Date: Fri, 4 Jan 2019 19:45:58 +1100 (AEDT) [thread overview] Message-ID: <alpine.LNX.2.21.1901041850170.9@nippy.intranet> (raw) In-Reply-To: <CAK8P3a3OD9ou=y+PaZ03v-ivW4A3fwwzA+aL+CoJDd_L2vTMLA@mail.gmail.com> On Mon, 31 Dec 2018, Arnd Bergmann wrote: > On Sun, Dec 30, 2018 at 4:29 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > > > On Sat, 29 Dec 2018, Arnd Bergmann wrote: > > > > > With the current method, it does seem odd to have a single > > > per-architecture instance of the exported structure containing > > > function pointers. This doesn't give us the flexibility of having > > > multiple copies in the kernel the way that ppc_md does, but it adds > > > overhead compared to simply exporting the functions directly. > > > > > > > You're right, there is overhead here. > > > > With a bit of auditing, wrappers like the one you quoted (which merely > > checks whether or not a ppc_md method is implemented) could surely be > > avoided. > > > > The arch_nvram_ops methods are supposed to optional (that is, they are > > allowed to be NULL). > > > > We could call exactly the same function pointers though either ppc_md > > or arch_nvram_ops. That would avoid the double indirection. > > I think you can have a 'const' structure in the __ro_after_init section, > so without changing anything else, powerpc could just copy the function > pointers from ppc_md into the arch_nvram_ops at early init time, which > should ideally simplify your implementation as well. > Does this require removing the 'const' from the powerpc arch_nvram_ops definition? That would mean removing the 'const' from the declaration in nvram.h, which means removing 'const' for every other instance of that struct too. That's what happened when I tried removing the ppc_md.nvram_* methods entirely and assigning the same function pointers to arch_nvram_ops methods instead. Apparently all instances of arch_nvram_ops have to be const or none of them. Otherwise gcc says, "error: conflicting type qualifiers for 'arch_nvram_ops'". -- > Arnd >
next prev parent reply other threads:[~2019-01-04 8:45 UTC|newest] Thread overview: 167+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-26 0:37 [PATCH v8 00/25] Re-use nvram module Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64 Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-29 22:36 ` Arnd Bergmann 2018-12-29 22:36 ` Arnd Bergmann 2018-12-30 3:28 ` Finn Thain 2018-12-30 3:28 ` Finn Thain 2018-12-31 12:32 ` Arnd Bergmann 2018-12-31 12:32 ` Arnd Bergmann 2019-01-01 1:38 ` Finn Thain 2019-01-01 1:38 ` Finn Thain 2019-01-04 8:45 ` Finn Thain [this message] 2019-01-04 8:45 ` Finn Thain 2019-01-06 23:36 ` Michael Ellerman 2019-01-06 23:36 ` Michael Ellerman 2019-01-07 4:52 ` Finn Thain 2019-01-07 4:52 ` Finn Thain 2019-01-08 9:27 ` Michael Ellerman 2019-01-08 9:27 ` Michael Ellerman 2019-01-08 22:51 ` Finn Thain 2019-01-08 22:51 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 07/25] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 22/25] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain 2018-12-26 0:37 ` Finn Thain 2019-01-03 8:05 ` Christoph Hellwig 2019-01-03 8:05 ` Christoph Hellwig 2019-01-03 22:11 ` Finn Thain 2019-01-03 22:11 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 16/25] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 03/25] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 11/25] m68k/mac: Use macros for RTC accesses not magic numbers Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 02/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-28 16:51 ` LEROY Christophe 2018-12-28 16:51 ` LEROY Christophe 2018-12-29 1:16 ` Finn Thain 2018-12-29 1:16 ` Finn Thain 2019-01-02 22:29 ` Finn Thain 2019-01-02 22:29 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 21/25] nvram: Drop nvram_* symbol exports and prototypes Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 14/25] char/nvram: Add "devname:nvram" module alias Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 08/25] char/nvram: Implement NVRAM read/write methods Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 15/25] powerpc: Clean up nvram includes Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 05/25] char/nvram: Adopt arch_nvram_ops Finn Thain 2018-12-26 0:37 ` Finn Thain 2019-01-03 8:02 ` Christoph Hellwig 2019-01-03 8:02 ` Christoph Hellwig 2019-01-03 22:08 ` Finn Thain 2019-01-03 22:08 ` Finn Thain 2019-01-04 17:56 ` Christoph Hellwig 2019-01-04 17:56 ` Christoph Hellwig 2019-01-04 22:05 ` Finn Thain 2019-01-04 22:05 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 25/25] powerpc: Remove pmac_xpram_{read,write} functions Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 06/25] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 12/25] m68k/mac: Fix PRAM accessors Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 18/25] powerpc: Implement nvram sync ioctl Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-29 22:19 ` Arnd Bergmann 2018-12-29 22:19 ` Arnd Bergmann 2018-12-30 7:25 ` Finn Thain 2018-12-30 7:25 ` Finn Thain 2018-12-30 23:13 ` Finn Thain 2018-12-30 23:13 ` Finn Thain 2018-12-31 12:17 ` Arnd Bergmann 2018-12-31 12:17 ` Arnd Bergmann 2018-12-31 12:16 ` Arnd Bergmann 2018-12-31 12:16 ` Arnd Bergmann 2019-01-01 1:06 ` Finn Thain 2019-01-01 1:06 ` Finn Thain 2019-01-02 22:25 ` Finn Thain 2019-01-02 22:25 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 23/25] char/generic_nvram: Remove as unused Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 10/25] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 09/25] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 17/25] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 04/25] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 13/25] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-29 22:27 ` Arnd Bergmann 2018-12-29 22:27 ` Arnd Bergmann 2018-12-30 7:26 ` Finn Thain 2018-12-30 7:26 ` Finn Thain 2018-12-30 17:53 ` LEROY Christophe 2018-12-30 17:53 ` LEROY Christophe 2018-12-30 22:12 ` Finn Thain 2018-12-30 22:12 ` Finn Thain 2018-12-31 12:19 ` Arnd Bergmann 2018-12-31 12:19 ` Arnd Bergmann 2018-12-26 0:37 ` [PATCH v8 19/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC && CONFIG_NVRAM Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 19/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC Finn Thain 2018-12-26 0:37 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-26 0:37 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_w Finn Thain 2018-12-29 17:02 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() LEROY Christophe 2018-12-29 17:02 ` LEROY Christophe 2018-12-29 17:02 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvr LEROY Christophe 2018-12-29 23:43 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain 2018-12-29 23:43 ` Finn Thain 2018-12-29 23:43 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvr Finn Thain 2018-12-31 12:29 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Arnd Bergmann 2018-12-31 12:29 ` Arnd Bergmann 2018-12-31 12:29 ` Arnd Bergmann 2018-12-31 12:29 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvr Arnd Bergmann 2019-01-01 1:10 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain 2019-01-01 1:10 ` Finn Thain 2019-01-01 1:10 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvr Finn Thain 2019-01-05 23:06 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain 2019-01-05 23:06 ` Finn Thain 2019-01-05 23:06 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvr Finn Thain 2018-12-26 0:37 ` [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM Finn Thain 2018-12-26 0:37 ` Finn Thain 2018-12-28 16:38 ` LEROY Christophe 2018-12-28 16:38 ` LEROY Christophe 2018-12-29 1:06 ` Finn Thain 2018-12-29 1:06 ` Finn Thain 2018-12-29 1:33 ` Michael Schmitz 2018-12-29 1:33 ` Michael Schmitz 2018-12-29 2:34 ` Finn Thain 2018-12-29 2:34 ` Finn Thain 2018-12-29 2:50 ` Michael Schmitz 2018-12-29 2:50 ` Michael Schmitz 2018-12-29 21:37 ` Arnd Bergmann 2018-12-29 21:37 ` Arnd Bergmann 2018-12-30 17:50 ` LEROY Christophe 2018-12-30 17:50 ` LEROY Christophe 2018-12-30 18:06 ` James Bottomley 2018-12-30 18:06 ` James Bottomley 2018-12-30 21:44 ` Finn Thain 2018-12-30 21:44 ` Finn Thain 2018-12-30 22:45 ` Finn Thain 2018-12-30 22:45 ` Finn Thain 2018-12-29 16:55 ` LEROY Christophe 2018-12-29 16:55 ` LEROY Christophe 2018-12-29 18:54 ` Michael Schmitz 2018-12-29 18:54 ` Michael Schmitz 2018-12-29 2:54 ` Michael Schmitz 2018-12-29 2:54 ` Michael Schmitz 2018-12-29 22:45 ` [PATCH v8 00/25] Re-use nvram module Arnd Bergmann 2018-12-29 22:45 ` Arnd Bergmann 2018-12-30 0:09 ` Finn Thain 2018-12-30 0:09 ` Finn Thain 2018-12-30 4:05 ` Finn Thain 2018-12-30 4:05 ` Finn Thain 2018-12-31 12:22 ` Arnd Bergmann 2018-12-31 12:22 ` Arnd Bergmann 2018-12-31 22:54 ` Finn Thain 2018-12-31 22:54 ` 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=alpine.LNX.2.21.1901041850170.9@nippy.intranet \ --to=fthain@telegraphics.com.au \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.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: linkBe 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.