On Sun, 1 Feb 2015, Geert Uytterhoeven wrote: > On Sun, Feb 1, 2015 at 4:39 AM, Finn Thain wrote: > > On Sun, 4 Jan 2015, Geert Uytterhoeven wrote: > > > On Sun, Jan 4, 2015 at 8:21 AM, Finn Thain wrote: > > > > On Thu, 1 Jan 2015, Rickard Strandqvist wrote: > > > > > Removes some functions that are not used anywhere: > > > > > mac_pram_write() mac_pram_read() > > > > > > > > ... I'd rather not remove all of this code. Better to finish the > > > > implementation. > > > > > > Indeed. > > > > > > > Would it be acceptable to utilize drivers/char/generic_nvram.c and > > > > CONFIG_GENERIC_NVRAM? This is the PowerMac PRAM driver but looks > > > > generic enough that it may not need any modification for 68k Macs. > > > > > > Yes, that would be great. > > > > > > > Unfortunately, it seems to be unworkable. > > An alternative could be to just provide an nvram attribute file in > sysfs, like many RTC drivers do. >
Are attribute files seekable? Even if userspace could use "/dev/nvram" and "/sys/whatever/nvram" interchangably, wouldn't it be better if PPC Macs and 68k Macs offered a consistent API to userspace? And your suggestion doesn't solve the problem, that is, to be able to build a multi-platform kernel binary in which drivers can access NVRAM. The __nvram_read_byte(), nvram_read_byte() etc functions defined in drivers/char/nvram.c, if allowed to proliferate because random architectures might like to use a generic /dev/nvram API, would further uglify that file. If the m68k Mac kernel doesn't define the nvram_read_byte() routine then valkyriefb can't use it. (fbdev drivers are apparently the reason why powerpc defines them.) drivers/char/nvram.c has two sets of these routines for PC RTC NVRAM; one for m68k (Atari) and one for arm/x86. We don't want to introduce more code into drivers/char/nvram.c to support all four configurations: 1) arm/x86 2) atari 3) atari + mac 4) mac So we'd end up having to move m68k-specific code out of drivers/char/nvram.c, to make it generic. And that then begs all of the questions in my previous message. BTW, my experimental patches replaced all of those __nvram_* and nvram_* functions with an ops struct. E.g. $ cat include/linux/nvram.h #ifndef _LINUX_NVRAM_H #define _LINUX_NVRAM_H #include <uapi/linux/nvram.h> struct nvram_ops { ssize_t (*read)(char *, size_t, loff_t *); ssize_t (*write)(char *, size_t, loff_t *); unsigned char (*read_byte)(int); void (*write_byte)(unsigned char, int); ssize_t (*get_size)(void); #ifdef CONFIG_PPC void (*sync)(void); #else long (*set_checksum)(void); long (*initialize)(void); #endif }; extern const struct nvram_ops arch_nvram_ops; extern const struct nvram_ops rtc_nvram_ops; #endif /* _LINUX_NVRAM_H */ This experiment has m68k implement arch_nvram_ops that dispatch to Atari or Mac methods (at compile-time for a single-platform kernel, or at run-time for a multi-platform kernel binary). But this implies modifications to fbdev drivers, PPC32 and PPC64, nvram and generic_nvram modules. And any work at all done on generic_nvram seems to be misguided, unless it is removal. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/