On Tue, 22 Oct 2019, Geert Uytterhoeven wrote:
> > > Note that sanitization script choked on some mails from the old
> > > phil.uni-sb.de list, so it didn't succeed for me.
> >
> > Was that the "From" bug? I am experimenting with pre-processing of
> > mboxes to substitute the "From" lines in
On Sun, 20 Oct 2019, Geert Uytterhoeven wrote:
> Hi all,
>
> I'm working to add this list to lore.kernel.org.
That's great news because lore.kernel.org is a search engine that actually
works.
> As one of prerequisites they require that we provide full existing
> archives of all list messages
On Thu, 1 Aug 2019, Michael Schmitz wrote:
> >>
> >> It's annoying that we can't unconditionally include atarihw.h but I
> >> don't have a solution for that.
> > The real issue is including , right?
> >
> > At first sight, the only reason for that is:
> >
> > #define atari_readb raw_inb
>
On Wed, 31 Jul 2019, Greg Ungerer wrote:
> >
> > Here's the patch I tested.
> >
> > diff --git a/arch/m68k/include/asm/atarihw.h
> > b/arch/m68k/include/asm/atarihw.h
> > index 533008262b69..ba1889c1a933 100644
> > --- a/arch/m68k/include/asm/atarihw.h
> > +++ b/arch/m68k/include/asm/atarihw.h
On Wed, 31 Jul 2019, Geert Uytterhoeven wrote:
> On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
> > On Wed, 31 Jul 2019, Greg Ungerer wrote:
> > > No, not sufficient. You still get the following warnings after
> > > just moving that include of atarihw.h:
> > &
m_ops calls to Atari or Mac functions") unconditionally included
atarihw.h.
It's annoying that we can't unconditionally include atarihw.h but I don't
have a solution for that.
If the convention is to put #ifdef around code like that then I guess
that's what we should do here too...
Reviewed-by: Finn Thain
--
> Regards
> Greg
>
On Mon, 29 Jul 2019, g...@kernel.org wrote:
> From: Greg Ungerer
>
> Commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari
> or Mac functions") causes a number of compile time warnings
> to be generated if compiling for a ColdFire MMU enabled target:
>
> In file included from
On Sun, 14 Jul 2019, Mike Rapoport wrote:
> > >
> > > Even with those fixes I'm still concerned about the
> > > SECTION_SIZE_BITS and MAX_PHYSMEM_BITS definitions.
> > >
> > > Without implementing vmemmap support we are limited in their maximal
> > > difference by 8 bits. That means that either
On Fri, 12 Jul 2019, Geert Uytterhoeven wrote:
>
> Memory configuration varies wildly among machines.
> IIRC, some Macs can have several discontiguous 1 MiB blocks.
>
Was that in the memory map provided by a bootloader running in MacOS in
24-bit addressing mode? I'm not sure that this
On Sat, 13 Apr 2019, Andreas Schwab wrote:
> On Apr 13 2019, Finn Thain wrote:
>
> > On Sat, 13 Apr 2019, Eero Tamminen wrote:
> >
> >> Unable to handle kernel access at virtual address (ptrval)
> >
> > https://github.com/fthain/linux/commit/457961e8666
On Sat, 13 Apr 2019, Eero Tamminen wrote:
> Unable to handle kernel access at virtual address (ptrval)
https://github.com/fthain/linux/commit/457961e86662a5d9fb42505034deba85fd85370f
--
On Sat, 13 Apr 2019, Eero Tamminen wrote:
> ** 5915 printk messages dropped ** <== WOW
Looks like a recursive fault. To see the first one, you'll need to
increase the printk buffer size. Try adding 'log_buf_len=256k' to the
kernel parameters.
--
On Fri, 12 Apr 2019, Michael Schmitz wrote:
> >
> > => I think the problem is that 'I' kthreads have NULL "current_pwq".
>
> Confirmed by the patch you attached so your analysis seems right.
>
And offset_of(struct poll_workqueue, wq) == 0x0004.
> >
> > Ones with workqueues just have
On Wed, 10 Apr 2019, Michael Schmitz wrote:
>
> What would happen if we just ignore the fault, and let
> print_worker_info() carry on?
>
Unforunately I don't have access to a Motorola '040 or '060 right now, but
if you do, it might provide us with some clues as to how to handle this
On Wed, 10 Apr 2019, Michael Schmitz wrote:
> On 10/04/19 12:58 PM, Finn Thain wrote:
> > On Wed, 10 Apr 2019, Michael Schmitz wrote:
> >
> > > > A potentially good question is why kthread_probe_data() would
On Wed, 10 Apr 2019, Michael Schmitz wrote:
>
> >
> > A potentially good question is why kthread_probe_data() would return
> > NULL on 030:
> >
> > /**
> > * kthread_probe_data - speculative version of kthread_data()
> > * @task: possible kthread task in question
On Tue, 9 Apr 2019, Michael Schmitz wrote:
>
> Seems real enough to me.
>
I agree. I was wondering if you'd seen anything like it before but I see
that the question is redundant. Had anything like it come up before, I
reckon you would have mentioned it when bus_error030() was discussed a
On Mon, 8 Apr 2019, Eero Tamminen wrote:
>
> ...
> >> I also found a 100% reproducible way to trigger the Oops, and surprise,
> >> surprise, that's also related to kernel <-> user-space interface:
> >> --
> >> # echo t > /proc/sysrq-trigger
>
> Does that work OK for
On Tue, 26 Mar 2019, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit cf85d89562f39cc7ae73de54639f1915a9195b7a
> Author: Finn Thain
> Date: Fri May 25 07:34:36 2018 +
>
>m68k/mac: Enable PDMA for PowerBook 500 series
>
Looks like a false pos
On Tue, 12 Mar 2019, I wrote:
> ... I did another experiment with the latter (forced inline) approach,
> to see if some optimizations can still be used with -ffreestanding.
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 7927b875f80c..25b5bf689018 100644
> ---
erhoeven wrote:
> > >> > On Thu, Mar 7, 2019 at 10:42 PM Finn Thain
> > >> > wrote:
> > >> >> No, the link fails because the compiler still emits some references to
> > >> >> strlen().
> > >> >
> > >>
On Thu, 7 Mar 2019, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 3:59 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Andreas Schwab wrote:
> > > On Mar 05 2019, Finn Thain wrote:
> > >
> > > > interesting that the kernel's strlen implementation
On Tue, 5 Mar 2019, Andreas Schwab wrote:
> On Mar 05 2019, Finn Thain wrote:
>
> > interesting that the kernel's strlen implementation in
> > include/linux/string.h can't achieve this.
>
> This implementation is only available if ARCH_HAS_FORTIFY_SOURCE.
>
On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> On Tue, Mar 5, 2019 at 7:13 AM Finn Thain wrote:
> > On Sat, 1 Dec 2018, Finn Thain wrote:
> > > This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
> > > and converts users of arch
On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> On Tue, Mar 5, 2019 at 3:58 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > Looks bogus to me.
> > >
> > > If you change memcpy to __builtin_memcpy, then we avoid the
On Sat, 1 Dec 2018, Finn Thain wrote:
> This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
> and converts users of arch_gettimeoffset to the clocksource API.
> Various bugs are fixed along the way.
Are there any plans to merge this series, Geert?
--
On Tue, 5 Mar 2019, Finn Thain wrote:
>
> Looks bogus to me.
>
> If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> warning changes to,
>
> ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming offset
> [7, 8] is out of the bound
On Mon, 4 Mar 2019, Geert Uytterhoeven wrote:
> On Mon, Mar 4, 2019 at 1:44 PM kbuild test robot wrote:
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git master
> > head: e223cadc191661c67cb419b3a53c7854ecc39e8b
> > commit:
On Sat, 2 Mar 2019, Guenter Roeck wrote:
> On Sat, Mar 02, 2019 at 03:40:48PM +1100, Finn Thain wrote:
> >
> > If we use static analysis and semantic patching for actual program
> > transformation then users of any compiler and architecture can
> > benefit.
On Fri, 1 Mar 2019, Guenter Roeck wrote:
>
> Another possible fix might be to write a 'static inline int strncmp()'
> function for non-coldfire code.
This build failure and some possible fixes have been discussed before...
Don't skip the framebuffer CLUT pointer register initialization when
the first dafb_setpalette() invocation has regno equal to zero.
Cc: linux-m...@lists.linux-m68k.org
Suggested-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
drivers/video/fbdev/macfb.c | 2 +-
1 file changed, 1
On Mon, 18 Feb 2019, Geert Uytterhoeven wrote:
> >
> > I did some more investigation. When I tested macfb in qemu, I found
> > that dafb_setpalette() is actually being called.
> >
> > And with this patch to add the missing call to fb_invert_cmaps(), the
> > dafb_setpalette() parameters change
The 'inverse' parameter has no effect otherwise. Remove set-but-unused
variable.
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: Finn Thain
---
drivers/video/fbdev/macfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/macfb.c b/drivers/video/fbdev
On Wed, 13 Feb 2019, Geert Uytterhoeven wrote:
> On Wed, Feb 13, 2019 at 1:14 AM Finn Thain wrote:
> > On Tue, 12 Feb 2019, Geert Uytterhoeven wrote:
> > > On Tue, Feb 12, 2019 at 6:31 AM Finn Thain
> > > wrote:
> > > > There's an 'invers
phys_addr_t to avoid type casts.
Cc: Laurent Vivier
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
Acked-by: Laurent Vivier
---
arch/m68k/include/asm/macintosh.h | 10 +--
arch/m68k/mac/config.c| 128 +++---
2 files changed, 69 insertions(+), 69 deletions
print_req_error: I/O error, dev fd0, sector 0
Cc: linux-m...@lists.linux-m68k.org
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/block/swim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/swim.c b/drivers/block/swim.c
index 3fa6fcc34790..dd19f422fb0d
get assigned
unconditionally. Remove redundant initializers.
Cc: linux-m...@lists.linux-m68k.org
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/video/fbdev/macfb.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/video/fbdev/macfb.c b/drivers/vi
On Tue, 12 Feb 2019, Geert Uytterhoeven wrote:
> On Tue, Feb 12, 2019 at 6:31 AM Finn Thain wrote:
> > There's an 'inverse' option in amifb, atafb, imstt, macfb, matroxfb,
> > pvr2fb and vesafb. However, it's dead code in atafb, macfb, matroxfb
> > and vesafb. The other
There's an 'inverse' option in amifb, atafb, imstt, macfb, matroxfb,
pvr2fb and vesafb. However, it's dead code in atafb, macfb, matroxfb and
vesafb. The others use fb_invert_cmaps() but this has no effect on the
framebuffer console. Does anyone know what this option is/was used for?
---
On Tue, 22 Jan 2019, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> > The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> > /dev/nvram misc device. This module is used only by 32-bit PowerPC
> > pl
using semantic patches. That way, clang and ICC
builds might benfit too.
Cc: sta...@vger.kernel.org
Reference: https://marc.info/?l=linux-m68k=15451481644=2
Signed-off-by: Finn Thain
---
arch/m68k/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/m68k
On Mon, 14 Jan 2019, Geert Uytterhoeven wrote:
> On Fri, Dec 21, 2018 at 7:21 AM Finn Thain wrote:
> > On Thu, 20 Dec 2018, John Paul Adrian Glaubitz wrote:
> > > On 12/20/18 12:16 AM, Finn Thain wrote:
> > > > Andreas said the error happened
Move the m68k-specific code out of the driver to make the driver generic.
I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the
old file is covered by MODULE_LICENSE("GPL").
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Fixed
r
codes so that a multi-platform kernel binary can do the right thing when
running on hardware without a suitable NVRAM.
Signed-off-by: Finn Thain
---
Changed since v8:
- Renamed nvram_* functions to avoid name collisions.
---
drivers/char/nvram.c | 70 ---
inc
-implemented in subsequent patches.
Replace the sole validate-checksum-and-read-byte sequence with a call to
nvram_read() which will gain the same semantics in subsequent patches.
Remove unused exports.
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
arch/m68k/atari/nvram.c | 39
form.
In this patch and the subsequent fbdev driver patch, the convention is
adopted across all relevant platforms whereby NVRAM functionality gets
enabled in a given device driver when the nvram misc device is built-in
or when both drivers are modules.
Acked-by: Michael Schmitz
Signed-off-by: Finn T
the common wrapper functions, the nvram module and other drivers can
make use of the available NVRAM functionality in a portable way.
Signed-off-by: Finn Thain
---
It might be nice if the NVRAM Kconfig symbol depended only on
HAVE_ARCH_NVRAM_OPS and all the x86 code here were moved to arch/x86
anged the CONFIG_NVRAM default to better approximate the present code.
In particular, the CONFIG_GENERIC_NVRAM default and use of "select NVRAM".
- Added more tested-by tags.
For older change logs, please refer to,
https://lore.kernel.org/lkml/20151101104202.301856...@telegraphics.com.au/
By implementing an arch_nvram_ops struct, a platform can re-use the
drivers/char/nvram.c module without needing any arch-specific code
in that module. Atari does so here.
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Added static inline wrapper functions
-by: Finn Thain
---
Changed since v7:
- Removed some gratuitous function pointers.
---
arch/m68k/mac/misc.c | 61 +---
1 file changed, 23 insertions(+), 38 deletions(-)
diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index 71c4735a31ee..78c807025436
Atari RTC NVRAM uses a checksum so implement the remaining arch_nvram_ops
methods for the set_checksum and initialize ioctls. Enable
CONFIG_HAVE_ARCH_NVRAM_OPS.
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Moved the HAVE_ARCH_NVRAM_OPS symbol to common code
but may be
unavailable so fall back on the latter methods when necessary.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v8:
- Renamed nvram_* functions to avoid name collisions.
- Added nvram_read_bytes() and nvram_write_bytes() helpers for use by
those platforms wh
Switch PPC32 kernels from the generic_nvram module to the nvram module.
Also fix a theoretical bug where CHRP omits the chrp_nvram_init() call
when CONFIG_NVRAM_MODULE=m.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
The change in the name of the module is visible to userspace
Certain Cuda transfers have to be ended by the driver. According
to Apple's open source Cuda driver, as found in mkLinux and XNU, this
applies to any "open ended request such as PRAM read". This fixes an
infinite polling loop in cuda_pram_read_byte().
Tested-by: Stan Johnson
Signed-of
Signed-off-by: Finn Thain
---
Changed since v8:
- Adopted nvram_read_bytes() and nvram_write_bytes() where possible.
---
arch/m68k/Kconfig.machine | 1 +
arch/m68k/atari/nvram.c | 21 ++--
arch/m68k/include/asm/atarihw.h | 6 +++
arch/m68k/include/asm/macintosh.h | 4
Add the powerpc-specific ioctls to the nvram module. This allows the nvram
module to replace the generic_nvram module.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
On PPC32, the IOC_NVRAM_SYNC ioctl call always returns 0, even for those
platforms that don't implement ppc_md.nvram_sync
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index adcc213c331e..c9e295d73dc5 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -503,3 +503,4 @@ module_exit(nvram_module_exit
GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".
** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".
Signed-off-by: Finn Thain
---
Changed since v8:
PMU-based m68k Macs pre-date PowerMac-style NVRAM. Use the appropriate
PMU commands. Also implement the missing XPRAM accessors for VIA-based
Macs.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v7:
- Revised PMU response decoding due to via
Remove the nvram_read_byte() and nvram_write_byte() declarations in
powerpc/include/asm/nvram.h and use the cross-platform static functions
in linux/nvram.h instead.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v8:
- Added nvram_read_byte() and nvram_write_byte
the naming convention used across
powerpc platforms for NVRAM accessor functions.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v8:
- Renamed functions to correspond with ppc_md member names.
---
arch/powerpc/platforms/chrp/nvram.c | 14 ++
arch/powerpc
d be in
an error path for an IOC_NVRAM_GET_OFFSET ioctl syscall.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
BTW, the IOC_NVRAM_SYNC ioctl call returns an error on PPC64. This patch
retains this behaviour though it might be better to actually perform a sync
since both PPC64 and PP
This is intended to improve code style and not affect code behaviour.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/mac/misc.c | 59 ++--
1 file changed, 41 insertions(+), 18 deletions(-)
diff --git a/arch
Also give functions more sensible names: nvram_misc_* for misc device ops,
nvram_proc_* for proc file ops and nvram_module_* for init and exit
functions. This prevents name collisions with nvram.h helper functions
and improves readability.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c
Signed-off-by: Finn Thain
---
drivers/char/Makefile| 6 +-
drivers/char/generic_nvram.c | 160 ---
2 files changed, 1 insertion(+), 165 deletions(-)
delete mode 100644 drivers/char/generic_nvram.c
diff --git a/drivers/char/Makefile b/drivers/char
On Tue, 8 Jan 2019, Michael Ellerman wrote:
> > The reason why that doesn't work boils down to introspection. (This
> > was mentioned elsewhere in this email thread.) For example, we
> > presently have code like this,
> >
> > ssize_t nvram_get_size(void)
> > {
> >if (ppc_md.nvram_size)
On Mon, 7 Jan 2019, Helge Deller wrote:
> On 27.11.18 22:17, Finn Thain wrote:
> > Adding Kars to Cc.
>
> Any chance this can get tested on m68k?
>
Sorry, I don't have any HP9000/300 hardware. I think that Kars does, which
is why I Cc'd him...
--
> Helge
>
> &
On Mon, 7 Jan 2019, Michael Ellerman wrote:
> Arnd Bergmann writes:
> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > wrote:
> >
> >> +static ssize_t ppc_nvram_get_size(void)
> >> +{
> >> + if (ppc_md.nvram_size)
> >> +
On Sun, 30 Dec 2018, I wrote:
> On Sat, 29 Dec 2018, LEROY Christophe wrote:
>
> > Finn Thain a ?crit?:
> >
> > > Make use of arch_nvram_ops in device drivers so that the nvram_* function
> > > exports can be removed.
> > >
> > > Sin
On Thu, 3 Jan 2019, Christoph Hellwig wrote:
> > # All PPC32s use generic nvram driver through ppc_md
> > -config GENERIC_NVRAM
> > +config HAVE_ARCH_NVRAM_OPS
> > bool
> > default y if PPC32
>
> Symbols like this really should be defined in common code, and then
> just selected by the
On Thu, 3 Jan 2019, Christoph Hellwig wrote:
> > +
> > +const struct nvram_ops arch_nvram_ops = {
> > + .read_byte = nvram_read_byte,
> > + .write_byte = nvram_write_byte,
> > + .get_size = nvram_get_size,
> > +};
> > +EXPORT_SYMBOL(arch_nvram_ops);
>
> I think something
On Sat, 29 Dec 2018, I wrote:
> On Fri, 28 Dec 2018, LEROY Christophe wrote:
>
> > > --- a/drivers/char/nvram.c
> > > +++ b/drivers/char/nvram.c
> > > @@ -21,13 +21,6 @@
> > > * ioctl(NVRAM_SETCKS) (doesn't change contents, just makes checksum
> > > valid
> > > * again; use with care!)
> >
On Tue, 1 Jan 2019, I wrote:
>
> There are no [nvram] ioctls common to all architectures. So your example
> becomes,
>
> static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> if (ops->ioctl)
> return
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 4:29 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > > wrote:
> > >
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 12:43 AM Finn Thain
> wrote:
>
> >
> > Is there some benefit, or is that just personal taste?
> >
> > Avoiding changes to call sites avoids code review, but I think 1) the
> > thinkpad_
On Sun, 30 Dec 2018, I wrote:
>
> The rationale for the ops struct was that it offers introspection.
>
> [...] those platforms which need checksum validation always set
> byte-at-a-time methods to NULL.
>
> [...] The NULL methods in the ops struct allow the nvram.c misc device
> to avoid
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: Finn Thain
---
drivers/block/amiflop.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index bf996bd44cfc..0903e0803ec8 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
On Sun, 30 Dec 2018, Finn Thain wrote:
> > > diff --git a/include/linux/nvram.h b/include/linux/nvram.h
> > > index b7bfaec60a43..24a57675dba1 100644
> > > --- a/include/linux/nvram.h
> > > +++ b/include/linux/nvram.h
> > > @@ -18,8 +18,12 @@ s
On Mon, 31 Dec 2018, Finn Thain wrote:
> On Sun, 30 Dec 2018, James Bottomley wrote:
>
> >
> > That said, as has been pointed out, the current #ifdef has a failing
> > corner case when both are modular (because the code should then be
> > included). The runtime
On Sun, 30 Dec 2018, LEROY Christophe wrote:
> > >
> > > Since the operations are almost entirely distinct, why not have two
> > > separate 'nvram_ops' instances here that each refer to just the set
> > > they actually need?
> > >
> >
> > The reason for that is that I am alergic to code
On Sun, 30 Dec 2018, James Bottomley wrote:
>
> That said, as has been pointed out, the current #ifdef has a failing
> corner case when both are modular (because the code should then be
> included). The runtime macro that correctly expresses this is
> IS_REACHABLE(CONFIG_NVRAM).
>
No, in
On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> On Wed, Dec 26, 2018 at 1:43 AM Finn Thain wrote:
>
> > +
> > +static ssize_t m68k_nvram_get_size(void)
> > +{
> > + if (MACH_IS_ATARI)
> > + return atari_nvram_get_size
On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> > --- a/drivers/char/nvram.c
> > +++ b/drivers/char/nvram.c
> > @@ -48,6 +48,10 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_PPC
> > +#include
> > +#include
> > +#endif
> >
> > static DEFINE_MUTEX(nvram_mutex);
> > static
On Sun, 30 Dec 2018, I wrote:
>
> I'm not opposed to exported functions in place of a singleton ops
> struct. Other things being equal I'm inclined toward the ops struct,
> perhaps because I like encapsulation or perhaps because I don't like
> excess generality. (That design decision was made
On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> On Wed, Dec 26, 2018 at 1:43 AM Finn Thain wrote:
>
> > +static ssize_t ppc_nvram_get_size(void)
> > +{
> > + if (ppc_md.nvram_size)
> > + return ppc_md.nvram_size();
> > + return
On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> I had a look at the complete series now, and I think this is a great
> cleanup. I replied with a couple of minor comments that you may or may
> not want to address first.
>
Thanks for reviewing this.
> The one thing I would like to see resolved (I
On Sat, 29 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > Make use of arch_nvram_ops in device drivers so that the nvram_* function
> > exports can be removed.
> >
> > Since they are no longer global symbols, rename the PPC32 nvram_* functions
>
On Sat, 29 Dec 2018, Michael Schmitz wrote:
>
> IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest.
>
> Or (really going out on a limb here):
>
> IS_BUILTIN(CONFIG_NVRAM) ||
> ( IS_MODULE(CONFIG_ATARI_SCSI) && IS_ENABLED(CONFIG_NVRAM) )
>
> Not that I'd advocate
On Fri, 28 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > Move the m68k-specific code out of the driver to make the driver generic.
> >
> > I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the
> > old file is covered by MODULE_
On Fri, 28 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
> > Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
> > enabling NVRAM support in drivers. Settin
Also give functions more sensible names: nvram_misc_* for misc device ops,
nvram_proc_* for proc file ops and nvram_module_* for init and exit
functions. This helps to distinguish them from struct nvram_ops methods.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 167
kernel.org/lkml/20151101104202.301856...@telegraphics.com.au/
Finn Thain (25):
scsi/atari_scsi: Don't select CONFIG_NVRAM
m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops
char/nvram: Re-order functions to rem
l. Replace this
validate-checksum-and-read-byte sequence with the equivalent
rtc_nvram_ops.read() call and remove the now unused functions.
Signed-off-by: Finn Thain
Tested-by: Christian T. Steigies
Acked-by: Geert Uytterhoeven
---
The advantage of the new ops struct over the old global nvram_*
the valkyriefb driver with powerpc, and since that driver uses
NVRAM, it is affected by CONFIG_ATARI_SCSI, because of the use of
"select NVRAM".
Adopt the powerpc convention on m68k to avoid surprises.
Signed-off-by: Finn Thain
Tested-by: Christian T. Steigies
---
This patch temporaril
Move the m68k-specific code out of the driver to make the driver generic.
I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the
old file is covered by MODULE_LICENSE("GPL").
Signed-off-by: Finn Thain
Tested-by: Christian T. Steigies
Acked-by: Geert Uy
and architectures.
Signed-off-by: Finn Thain
---
The procfs code here could be moved to arch/x86 (like the earlier patch
did for m68k code that was here). The nvram_ops struct could be
implemented and exported by the rtc-cmos driver instead, to eliminate
the remaining #ifdefs.
---
drivers/char
Make use of arch_nvram_ops in the thinkpad_acpi driver so that the
nvram_* function exports can be removed.
Signed-off-by: Finn Thain
Acked-by: Henrique de Moraes Holschuh
Reviewed-by: Darren Hart
---
I've tested this on a ThinkPad T43.
---
drivers/platform/x86/thinkpad_acpi.c | 20
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index 889123ddace4..b77c27d68762 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -554,3 +554,4 @@ module_exit(nvram_module_exit
Atari RTC NVRAM has a checksum so implement the remaining arch_nvram_ops
methods for the set_checksum and initialize ioctls. Enable
CONFIG_HAVE_ARCH_NVRAM_OPS.
Signed-off-by: Finn Thain
Acked-by: Geert Uytterhoeven
---
Changed since v7:
- Changed the default for CONFIG_NVRAM, because "s
r
codes so that a multi-platform kernel binary can do the right thing when
running on hardware without suitable NVRAM.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 70 ---
include/linux/nvram.h | 2 ++
2 files changed, 42 insertions(+), 30 deletions(-)
1 - 100 of 1612 matches
Mail list logo
