Re: [PATCH] [NET]: Remove PowerPC code from fec.c

On Friday 25 January 2008, Jochen Friedrich wrote: Maybe the wording should be changed to: This driver is now only used on ColdFire (m68knommu) processors. Conditional PowerPC code has been removed. How about adding a pointer to the driver that is now used on powerpc, for the people that

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

On Tuesday 09 December 2008, Geert Uytterhoeven wrote: I have used the following include guard: #ifdef __uClinux__ #include atomic_no.h #else #include atomic_mm.h #endif gcc -E -dM for the two compilers revealed that this was the only symbol that differed. I think you can

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

On Tuesday 09 December 2008, Geert Uytterhoeven wrote: What are the other exported headers that differ? byteorder.h, param.h, ptrace.h, setup.h, sigcontext.h, siginfo.h, signal.h and unistd.h. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

On Thursday 11 December 2008, Andreas Schwab wrote: Geert Uytterhoeven [EMAIL PROTECTED] writes: None of my m68k-linux compilers set __uClinux__, as expected. IIUC, userspace ABI is supposed to be completely identical. The header files are currently different for the definitions of

Re: [PATCH] ata: libata depends on HAS_DMA

On Tuesday 12 May 2009, Alan Cox wrote: Nakked-by: Alan Cox a...@linux.intel.com Almost every PATA adapter can fall back to PIO, many are PIO only. We need a rather cleaner way to sort this. Currently, the only architectures that don't set HAS_DMA are h8300, m32r m68k (except SUN3 and

Re: [PATCH] ata: libata depends on HAS_DMA

On Friday 15 May 2009, Tejun Heo wrote: Don't know much history here but I don't wanna sprinkle ifdefs around in libata so I would much prefer dummy implementation which doesn't fail compile. My original patch did that by adding 'depends on HAS_DMA'. The only architectures that don't have

Re: [PATCH] ata: libata depends on HAS_DMA

On Sunday 17 May 2009, Robert Hancock wrote: Arnd Bergmann wrote: On Friday 15 May 2009, Tejun Heo wrote: Don't know much history here but I don't wanna sprinkle ifdefs around in libata so I would much prefer dummy implementation which doesn't fail compile. My original patch did

[PATCH] asm-generic: add a dma-mapping.h file

h8300 and m32r currently do not provide a DMA mapping API and therefore cannot use the ATA drivers. This adds a generic version of dma-mapping.h for architectures that have none or very minimal actual support for DMA in hardware and makes the two architectures use it. Signed-off-by: Arnd Bergmann

Re: [PATCH] asm-generic: add a dma-mapping.h file

On Monday 18 May 2009, Geert Uytterhoeven wrote: +#ifndef dma_alloc_coherent +static inline void * +dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle, +                  gfp_t flag) +{ +       void *virt = kmalloc(size, flag); kmalloc() may fail. +      

Re: [PATCH] asm-generic: add a dma-mapping.h file

merging frv and m68k, but they have some peculiarities that made it slightly harder. Signed-off-by: Arnd Bergmann a...@arndb.de include/asm-generic/dma-mapping-linear.h | 391 + arch/avr32/include/asm/dma-mapping.h | 408 --- arch

Re: [PATCH] asm-generic: add a dma-mapping.h file

On Tuesday 19 May 2009 17:01:27 Grant Grundler wrote: On Tue, May 19, 2009 at 9:22 AM, Arnd Bergmann a...@arndb.de wrote: I've reviewed the first bit and it looks fine (so far to me). Two related bugs: 1) dma_alloc_coherent() is not respecting the coherent_dma_mask field in device.h:struct

Re: [PATCH] asm-generic: add a dma-mapping.h file

On Friday 22 May 2009, FUJITA Tomonori wrote: I don't think that this works for all architectures because a returned buffer of alloc_pages_node might not be DMA-capable. Needs to use the coherent_dma_mask here. See x86's dma_alloc_coherent and Alpha's pci-noop.c (there might be other

Re: [PATCH] asm-generic: add a dma-mapping.h file

On Friday 22 May 2009, FUJITA Tomonori wrote: I'm not sure. And only mips internally uses CONFIG_DMA_COHERENT. The reason why many architectures need architecture-specific alloc_coherent() is not about coherent or not. I like a new helper header file having only generic functions without

Re: sys_recvmmsg: wire up or not?

On Saturday 26 December 2009, Geert Uytterhoeven wrote: stdin:1523:2: warning: #warning syscall recvmmsg not implemented so I started to wire up sys_recvmmsg. Then I noticed it's already accessible, through sys_socketcall, as m68k defines __ARCH_WANT_SYS_SOCKETCALL. So I guess this is a

Re: [PATCH] zorro: BKL removal

On Saturday 05 June 2010, Geert Uytterhoeven wrote: Remove BKL use from proc_bus_zorro_lseek(), like was done for proc_bus_pci_lseek() a long time ago. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line

[PATCH 07/18] m68k: remove big kernel lock

The cache flush code only locks against itself, so there is no excuse to use the BKL here. This replaces it with a local mutex in order to maintain serialization of flushes. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Roman Zippel zip...@linux

Re: [PATCH v2 02/22] bitops: rename generic little-endian bitops functions

...@oracle.com Cc: rds-de...@oss.oracle.com Cc: David S. Miller da...@davemloft.net Cc: net...@vger.kernel.org Cc: Avi Kivity a...@redhat.com Cc: Marcelo Tosatti mtosa...@redhat.com Cc: k...@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line

Re: merge of m68knommu and m68k arch branches?

On Friday 18 February 2011 13:01:53 Greg Ungerer wrote: Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King sfk...@fdwdc.com for the initial version of this script, and to Sam Ravnborg for the m68k includes

Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table

On Wednesday 13 April 2011, Geert Uytterhoeven wrote: When comparing this to the MMU comments in include/asm-generic/unistd.h, I noticed this: M68knommu does have: - sys_mbind - sys_get_mempolicy - sys_set_mempolicy - sys_migrate_pages - sys_move_pages scripts/checksyscalls.sh

Re: Writable sys_call_table (was: Re: [uClinux-dev] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table)

There is no reason to have sys_call_table writable, and putting it into the rodata section can make it harder for malicious users to overwrite the entry points. Signed-off-by: Arnd Bergmann a...@arndb.de --- diff --git a/arch/score/kernel/sys_call_table.c b/arch/score/kernel/sys_call_table.c index

Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table

On Wednesday 04 May 2011, Geert Uytterhoeven wrote: Impact for nommu: - Store table in .rodata instead of .text, - Let kernel/sys_ni.c handle the stubbing of MMU-only syscalls, - Implement sys_mremap and sys_nfsservct, - Remove unused padding at the end of the table. Impact for

Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile

On Monday 06 June 2011 22:07:53 Geert Uytterhoeven wrote: This fixes a.o. drivers/ide/ide-io.c: In function ‘ide_lock_host’: drivers/ide/ide-io.c:415: warning: passing argument 2 of ‘__constant_test_and_set_bit’ discards qualifiers from pointer target type drivers/ide/ide-io.c:415:

Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile

On Tuesday 07 June 2011, Geert Uytterhoeven wrote: You mean the host_busy variable in the IDE code? That would also apply to context_flag in the DRM code: drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of ‘__constant_test_and_set_bit’ discards qualifiers from pointer target

Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile

On Tuesday 07 June 2011, Ben Hutchings wrote: On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote: I guess what happened is that some variables are traditionally marked as volatile although they shouldn't be, and most architectures have adapted their bitops to make the warnings

Re: patch TTY: remove tty_locked added to tty tree

On Wednesday 24 August 2011, Jiri Slaby wrote: On 08/24/2011 01:20 PM, Arnd Bergmann wrote: It's not clear to me what state-mutex protects in the serial_core, but it has been around forever (used to be called state-sem) It was actually moved in uart_close back in 2003. Formerly (when

Re: [PATCH 0/4] gpio: introduce descriptor-based interface

On Monday 14 January 2013, Alex Courbot wrote: On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h

Re: [PATCH, RFC 02/30] scsi: atari_scsi: fix sleep_on race

On Sunday 12 January 2014, Michael Schmitz wrote: Arnd, your patch breaks the Atari NCR5380 SCSI driver (easily verified using ARAnyM). Last console output: Thanks so much for testing and sorry for your troubles. It seems I got the wrong polarity on at least one of the conditions when

Re: [PATCH, RFC 02/30] scsi: atari_scsi: fix sleep_on race

On Monday 27 January 2014, Michael Schmitz wrote: I will submit patches to the Atari SCSI driver based on Arnd's patch later this week. Has Arnd's initial patch made it into mainline yet? I've been a little occupied with other work recently, so I have never gotten around to post a non-RFC

Re: [PATCH 1/3] m68k/atari - convert atari_scsi falcon_get_lock() to use wait_event()

, but at least prevents falcon_get_lock from going to sleep when no other thread holds the same lock or tries to get it, and we no longer schedule with irqs disabled. MSch: fixed completion conditions missed in Arnds' original RFC patch. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Michael

Re: [PATCH 10/28] PCI: Save sysdata in pci_host_bridge drvdata

On Friday 16 January 2015 09:44:08 Yijing Wang wrote: @@ -2066,11 +2064,11 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, u32 db, { struct pci_host_bridge *host; - host = pci_create_host_bridge(parent, db, resources); + host =

Re: [PATCH 11/28] PCI: Introduce pci_host_bridge_ops to setup host bridge

On Friday 16 January 2015 09:44:09 Yijing Wang wrote: @@ -2064,7 +2073,7 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, u32 db, { struct pci_host_bridge *host; - host = pci_create_host_bridge(parent, db, resources, sysdata); + host =

Re: [PATCH 09/28] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()

On Friday 16 January 2015 09:44:07 Yijing Wang wrote: We want to make a generic pci_host_bridge, then we could place common PCI infos like domain number in it. Ripping out pci_host_bridge creation from pci_create_root_bus() make code more better readability. Further more, we could use the

Re: [PATCH 11/28] PCI: Introduce pci_host_bridge_ops to setup host bridge

On Friday 16 January 2015 10:23:11 Arnd Bergmann wrote: On Friday 16 January 2015 09:44:09 Yijing Wang wrote: @@ -2064,7 +2073,7 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, u32 db, { struct pci_host_bridge *host; - host = pci_create_host_bridge(parent

Re: [PATCH 09/28] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()

On Friday 16 January 2015 09:44:07 Yijing Wang wrote: We want to make a generic pci_host_bridge, then we could place common PCI infos like domain number in it. Ripping out pci_host_bridge creation from pci_create_root_bus() make code more better readability. Further more, we could use the

Re: [PATCH 08/28] PCI: Introduce pci_host_assign_domain_nr() to assign domain

On Friday 16 January 2015 10:08:45 Arnd Bergmann wrote: On Friday 16 January 2015 09:44:06 Yijing Wang wrote: Introduce pci_host_assign_domain_nr() to assign domain number for pci_host_bridge. Later we will remove pci_bus_assign_domain_nr(). Signed-off-by: Yijing Wang wangyij

Re: [PATCH 27/28] PCI: Remove platform specific pci_domain_nr()

On Friday 16 January 2015 09:44:25 Yijing Wang wrote: +int pci_domain_nr(struct pci_bus *bus) +{ + struct pci_host_bridge *host = find_pci_host_bridge(bus); + + return host-domain; +} +EXPORT_SYMBOL_GPL(pci_domain_nr); + Since most of the existing functions are exported as

Re: [PATCH 18/28] PCI/sparc: Use pci_scan_root_bridge() for simplicity

On Friday 16 January 2015 09:44:16 Yijing Wang wrote: +static void pci_host_bridge_probe_mode( + struct pci_host_bridge *host) +{ + host-of_scan = true; +} I probably missed something here, but where does host-of_scan get used? Arnd -- To unsubscribe from this

Re: [PATCH 00/28] Refine PCI scan interfaces and make generic pci host bridge

On Friday 16 January 2015 09:43:58 Yijing Wang wrote: This series is based on Bjorn's pci-next branch. I think this is a very nice series, hope we can get this into 3.20. I've replied with a few specific comments, but I see no show-stoppers and I've already retracted a few comments after seeing

Re: [PATCH 18/28] PCI/sparc: Use pci_scan_root_bridge() for simplicity

On Monday 19 January 2015 11:17:02 Yijing Wang wrote: On 2015/1/16 18:01, Arnd Bergmann wrote: On Friday 16 January 2015 09:44:16 Yijing Wang wrote: +static void pci_host_bridge_probe_mode( + struct pci_host_bridge *host) +{ + host-of_scan = true; +} I

Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()

On Friday 16 January 2015 15:16:28 Yinghai Lu wrote: On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu ying...@kernel.org wrote: On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wangyij...@huawei.com wrote: Pci_bus_add_devices() should not be placed in pci_scan_bus(). Now pci device will be added to

Re: [PATCH 08/28] PCI: Introduce pci_host_assign_domain_nr() to assign domain

On Monday 19 January 2015 10:14:44 Yijing Wang wrote: I'm confused: the same code is already part of the PCI tree, but with Lorenzo Pieralisi listed as the patch author. The code is good, and I acked it in the past, but one of you is (probably by accident) misattributing the patch.

Re: [PATCH 10/28] PCI: Save sysdata in pci_host_bridge drvdata

On Monday 19 January 2015 11:12:50 Yijing Wang wrote: On 2015/1/16 17:18, Arnd Bergmann wrote: On Friday 16 January 2015 09:44:08 Yijing Wang wrote: @@ -2066,11 +2064,11 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, u32 db, { struct pci_host_bridge *host

[PATCH v4 15/16] char/genrtc: remove asm-generic/rtc.h from mips

arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason, and it works fine without that header, so lets remove the inclusion in preparation of deleting the file. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/mips/sni/time.c | 1 - 1 file changed, 1 deletion(-) diff

[PATCH v4 11/16] char/genrtc: remove m68k support

asm/rtc.h are now changed so they include the headers that were used implicitly through asm/rtc.h. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/amiga/config.c| 1 - arch/m68k/apollo/config.c | 1 - arch/m68k/bvme6000/config.c | 1 - arch/m68k/hp300/config.c| 2 +-

[PATCH v4 04/16] rtc: sh: provide rtc_class_ops directly

, skipping one of the abstraction levels. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/sh/include/asm/rtc.h | 11 --- arch/sh/kernel/time.c | 33 - drivers/rtc/rtc-generic.c | 2 +- 3 files changed, 21 insertions(+), 25 deletions(-) diff

[PATCH v4 10/16] rtc: m68k: provide ioctl for q40

it. This adds an ioctl implementation to the m68k generic_rtc_ops in order to let both drivers provide the same API. After this, we should be able to remove support for genrtc from the m68k architecture. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.

[PATCH v4 05/16] char/genrtc: remove alpha support

point it was used to abstract a quirk for the "Marvel" platform, but it does not do this any more after the code was moved into yet another driver in arch/alpha/kernel/rtc.c. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/alpha/include/asm/rtc.h| 1 - arch/alpha/kernel/c

[PATCH v4 01/16] rtc: cmos: remove empty asm/mc146818rtc.h files

Nothing on these architectures ever includes the asm/mc146818rtc.h file, the drivers that used to do this have been fixed long ago, and the remaining users are all PC-specific. This removes the files for good. Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Alexandre B

[PATCH v4 08/16] char/genrtc: remove parisc support

This architecture selects RTC_CLASS unconditionally, so the GEN_RTC has not worked here for a long time. Now we can remove both the asm/rtc.h header and the Kconfig dependency for CONFIG_GEN_RTC. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/parisc/include/asm/rtc.h

[PATCH v4 14/16] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/rtc/rtc-generic.c | 35 +--

[PATCH v4 13/16] char/genrtc: remove powerpc support

instead, for the only reason of not breaking existing defconfig and .config files that users may have. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/powerpc/include/asm/rtc.h| 78 --- arch/powerpc/platforms/Kconfig| 11 ++ arch/p

[PATCH v4 06/16] char/genrtc: remove mn10300 support

-by: Arnd Bergmann <a...@arndb.de> --- arch/mn10300/include/asm/rtc.h | 2 -- arch/mn10300/kernel/rtc.c | 2 +- arch/mn10300/proc-mn103e010/proc-init.c | 1 + arch/mn10300/proc-mn2ws0050/proc-init.c | 1 + drivers/char/Kconfig| 2 +- 5 files chan

[PATCH v4 09/16] rtc: m68k: provide rtc_class_ops directly

. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.c | 23 +-- drivers/rtc/rtc-generic.c | 2 +- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c index 3857737e3958..bd6417d38d5a

[PATCH v4 12/16] rtc: powerpc: provide rtc_class_ops directly

by one. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/powerpc/kernel/time.c | 29 - drivers/rtc/rtc-generic.c | 2 +- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 3ed9a5

[PATCH v4 07/16] rtc: parisc: provide rtc_class_ops directly

, using the normal helper functions, which makes this y2038 safe (on 32-bit) and simplifies the implementation. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/parisc/kernel/time.c | 36 +++- drivers/rtc/rtc-generic.c | 3 +-- 2 files changed, 36 insertions

[PATCH v4 03/16] char/genrtc: x86: remove remnants of asm/rtc.h

MOS driver. This removes x86 from the list for genrtc, and changes all references to the asm/rtc.h header to instead point to the interfaces from linux/mc146818rtc.h. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/x86/include/asm/rtc.h | 1 - arch/x86/kernel/hpet.c | 3 +--

Re: [PATCH 3/6] powerpc: rtc: provide rtc_class_ops directly

; url: > https://github.com/0day-ci/linux/commits/Arnd-Bergmann/rtc-generic-follow-up-for-COMPILE_TEST/20160302-011032 > base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > rtc-next > config: powerpc-allnoconfig (attached as .config) > reproduce: > wget

Re: [PATCH 1/6] rtc: generic: allow building on all architectures

On Wednesday 02 March 2016 09:57:27 Geert Uytterhoeven wrote: > > @@ -33,13 +35,21 @@ static const struct rtc_class_ops generic_rtc_ops = { > > .read_time = generic_get_time, > > .set_time = generic_set_time, > > }; > > +#else > > +#define generic_rtc_ops *(struct

[PATCH 0/6] rtc: generic: follow up for COMPILE_TEST

Today's linux-next kernel allowed building the rtc-generic driver (and most other rtc drivers) on all architectures, but this caused some errors on architectures without asm/rtc.h. This series reworks that driver to avoid the dependency, and simplifies all four implementations. My first approach

[PATCH 1/6] rtc: generic: allow building on all architectures

an alternative use of the driver, allowing architectures to pass a set of rtc_class_ops in platform data. We can convert the four architectures to use this and then remove the original code. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/rtc/rtc-generic.c | 12 +++- 1 file chang

[PATCH 6/6] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/rtc/rtc-generic.c | 36 +---

[PATCH 4/6] parisc: rtc: provide rtc_class_ops directly

, using the normal helper functions, which makes this y2038 safe (on 32-bit) and simplifies the implementation. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/parisc/kernel/time.c | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/

[PATCH 5/6] sh: rtc: provide rtc_class_ops directly

, skipping one of the abstraction levels. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/sh/kernel/time.c | 32 +++- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/arch/sh/kernel/time.c b/arch/sh/kernel/time.c index d6d0a986c6e9..92cd676970d9

[PATCH 2/6] m68k: rtc: provide rtc_class_ops directly

. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c index 3857737e3958..773b2187210d 100644 --- a/arch/m68k/kernel/time.c +++ b/arc

[PATCH 3/6] powerpc: rtc: provide rtc_class_ops directly

by one. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/powerpc/kernel/time.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 81b0900a39ee..84a1228be617 100644 --- a/arch/powerpc/

[PATCH v2 2/6] rtc: m68k: provide ioctl for q40

it. This adds an ioctl implementation to the m68k generic_rtc_ops in order to let both drivers provide the same API. After this, we should be able to remove support for genrtc from the m68k architecture. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.

[PATCH v2 1/6] rtc: m68k: provide rtc_class_ops directly

. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.c | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c index 3857737e3958..fe35890feede 100644 --- a/arch/m68k/kernel/time.c +++

[PATCH v2 6/6] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/rtc/rtc-generic.c | 36 +---

[PATCH v2 0/6] simplify rtc-generic driver

This is a resend of an earlier series, to clean up the rtc-generic driver by avoiding the dependency on the architecture specific include/asm/rtc.h header that after this series is only used for the deprecated "genrtc" driver. As I've shown in another series, only three architectures (m68k,

[PATCH v2 5/6] rtc: sh: provide rtc_class_ops directly

, skipping one of the abstraction levels. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/sh/kernel/time.c | 32 +++- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/arch/sh/kernel/time.c b/arch/sh/kernel/time.c index d6d0a986c6e9..92cd676970d9

Re: [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

On Thursday 28 April 2016 11:08:41 Arnd Bergmann wrote: > I only see two of them anyway (dreamcast and sh03), so that should > be easy enough to do. For instance in arch/sh/boards/mach-sh03/rtc.c, > the sh03_time_init() function should register a platform driver, > whose probe fu

Re: [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

On Wednesday 27 April 2016 19:21:22 Rich Felker wrote: > On Thu, Apr 28, 2016 at 12:34:18AM +0200, Arnd Bergmann wrote: > > The rtc-generic driver provides an architecture specific > > wrapper on top of the generic rtc_class_ops abstraction, > > and on sh, that goes throug

[PATCH v3 03/16] char/genrtc: x86: remove remnants of asm/rtc.h

MOS driver. This removes x86 from the list for genrtc, and changes all references to the asm/rtc.h header to instead point to the interfaces from linux/mc146818rtc.h. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/x86/include/asm/rtc.h | 1 - arch/x86/kernel/hpet.c | 3 +--

[PATCH v3 16/16] char/genrtc: remove the rest of the driver

No architecture uses the genrtc driver any more, so let's kill it off for good. This now also includes asm-generic/rtc.h, which is otherwise completely unused. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/char/Kconfig | 26 --- drivers/char/Makefile | 1 - driver

[PATCH v3 08/16] char/genrtc: remove parisc support

This architecture selects RTC_CLASS unconditionally, so the GEN_RTC has not worked here for a long time. Now we can remove both the asm/rtc.h header and the Kconfig dependency for CONFIG_GEN_RTC. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/parisc/include/asm/rtc.h

[PATCH v3 11/16] char/genrtc: remove m68k support

asm/rtc.h are now changed so they include the headers that were used implicitly through asm/rtc.h. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/amiga/config.c| 1 - arch/m68k/apollo/config.c | 1 - arch/m68k/bvme6000/config.c | 1 - arch/m68k/hp300/config.c| 2 +-

[PATCH v3 12/16] rtc: powerpc: provide rtc_class_ops directly

by one. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/powerpc/kernel/time.c | 29 - drivers/rtc/rtc-generic.c | 2 +- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 3ed9a5

[PATCH v3 07/16] rtc: parisc: provide rtc_class_ops directly

, using the normal helper functions, which makes this y2038 safe (on 32-bit) and simplifies the implementation. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/parisc/kernel/time.c | 36 +++- drivers/rtc/rtc-generic.c | 3 +-- 2 files changed, 36 insertions

[PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly

. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.c | 24 ++-- drivers/rtc/rtc-generic.c | 2 +- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c index 3857737e3958..80e024a10115

[PATCH v3 14/16] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/rtc/rtc-generic.c | 35 +--

[PATCH v3 06/16] char/genrtc: remove mn10300 support

-by: Arnd Bergmann <a...@arndb.de> --- arch/mn10300/include/asm/rtc.h | 2 -- arch/mn10300/kernel/rtc.c | 2 +- drivers/char/Kconfig | 2 +- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/mn10300/include/asm/rtc.h b/arch/mn10300/include/asm/rtc.h

[PATCH v3 05/16] char/genrtc: remove alpha support

point it was used to abstract a quirk for the "Marvel" platform, but it does not do this any more after the code was moved into yet another driver in arch/alpha/kernel/rtc.c. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/alpha/include/asm/rtc.h| 1 - arch/alpha/kernel/c

[PATCH v3 13/16] char/genrtc: remove powerpc support

instead, for the only reason of not breaking existing defconfig and .config files that users may have. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/powerpc/include/asm/rtc.h| 78 --- arch/powerpc/platforms/Kconfig| 11 ++ arch/p

[PATCH v3 01/16] rtc: cmos: remove empty asm/mc146818rtc.h files

Nothing on these architectures ever includes the asm/mc146818rtc.h file, the drivers that used to do this have been fixed long ago, and the remaining users are all PC-specific. This removes the files for good. Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Alexandre B

[PATCH v3 15/16] char/genrtc: remove asm-generic/rtc.h from mips

arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason, and it works fine without that header, so lets remove the inclusion in preparation of deleting the file. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/mips/sni/time.c | 1 - 1 file changed, 1 deletion(-) diff

[PATCH v3 10/16] rtc: m68k: provide ioctl for q40

it. This adds an ioctl implementation to the m68k generic_rtc_ops in order to let both drivers provide the same API. After this, we should be able to remove support for genrtc from the m68k architecture. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/m68k/kernel/time.

[PATCH v3 02/16] rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

to the new naming. Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> --- arch/alpha/kernel/rtc.c| 6 +- arch/x86/include/asm/mc146818rtc.h | 1 - drivers/rtc/rtc-cmos.c | 12 +-- include/asm-g

Re: [PATCH v2 4/6] rtc: parisc: provide rtc_class_ops directly

On Wednesday 27 April 2016 08:22:24 kbuild test robot wrote: > >256 >257 memset(tm, 0, sizeof(*tm)); >258 if (pdc_tod_read(_data) < 0) >259 return -EOPNOTSUPP; >260 >261 /* we treat tod_sec as unsigned, so this can work until

Re: [PATCH v3 00/16] genrtc removal

y small changes in there that I still need to pick up, so hopefully that will be the last version. It would be nice if you could take it through your tree then. Arnd > On 28/04/2016 at 00:34:14 +0200, Arnd Bergmann wrote : > > I ended up stuffing the two patch series into one, as they ar

Re: [PATCH 0/2] m68k RTC fixes

On Tuesday 03 May 2016 15:40:34 Alexandre Belloni wrote: > > Queue strategy: > > 1. These are queued together with Arnd's series, > > 1. I queue them for v4.7 myself, but then the RTC tree must be mergest > > after the m68k tree, > > 2. I queue them for v4.6. > > > > As I currently

Re: [PATCH 1/2] char: PC rtc: replace blacklist with whitelist

On Monday 18 April 2016 09:09:55 Geert Uytterhoeven wrote: > Hi Arnd, > > cc linux-m68k > > On Sun, Apr 17, 2016 at 11:37 PM, Arnd Bergmann <a...@arndb.de> wrote: > > On Wednesday 02 March 2016 11:22:04 Geert Uytterhoeven wrote: > >> On Wed, Mar 2, 2016 at 10

Re: [PATCH v5 12/15] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Sunday, July 24, 2016 4:25:16 PM CEST Nicolas Pitre wrote: > On Sun, 24 Jul 2016, Arnd Bergmann wrote: > > > On Sunday, July 24, 2016 11:30:26 AM CEST Nicolas Pitre wrote: > > > +#else > > > + /* > > > +

Re: [PATCH v5 12/15] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Sunday, July 24, 2016 11:30:26 AM CEST Nicolas Pitre wrote: > +#else > + /* > +* This is used on MMU systems mainly for testing. > +* Let's use a kernel buffer to simplify things. > +*/ > +

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: > Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h > userspace compilation errors like this: > > /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' > size_t ss_size; > > As no uapi header

Re: [PATCH v2 0/7] uapi: export all headers under uapi directories

On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote: > Here is the v2 of this series. The first 5 patches are just cleanup: some > exported headers were still under a non-uapi directory. Since this is meant as a cleanup, I commented on this to point out a cleaner way to do the same.

Re: [PATCH v2 3/7] nios2: put setup.h in uapi

On Friday, January 6, 2017 10:43:55 AM CET Nicolas Dichtel wrote: > diff --git a/arch/nios2/include/uapi/asm/setup.h > b/arch/nios2/include/uapi/asm/setup.h > new file mode 100644 > index ..8d8285997ba8 > --- /dev/null > +++ b/arch/nios2/include/uapi/asm/setup.h > @@ -0,0 +1,6 @@ >

Re: [PATCH v2 1/7] arm: put types.h in uapi

On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote: > > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h > index a53cdb8f068c..c48fee3d7b3b 100644 > --- a/arch/arm/include/asm/types.h > +++ b/arch/arm/include/asm/types.h > @@ -1,40 +1,6 @@ > #ifndef

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger wrote: > > Looks like microblaze can be configured to either little or big endian > formats. How about > adding a choice statement to address this. > Here is my proposed patch. Hi Babu, This part looks fine, but I think we

[PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency

to be relevant in the future any more. We can probably drop some of the other dependencies as well now, e.g. there should generally be no reason to depend on CONFIG_ARM unless the driver uses architecture specific assembly. Reported-by: Randy Dunlap <rdun...@infradead.org> Signed-off-by

[PATCH 1/3] Input: hil_mlc: convert timeval to time64_t

o <pingbo@linaro.org> Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/input/serio/hil_mlc.c | 8 +++- include/linux/hil_mlc.h | 2 +- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/input/serio/hil_mlc.c b/drivers/input/serio/hil_mlc

  1   2   3   >