Almost all architectures include it.  Add a ARCH_NO_PREEMPT symbol to
disable preempt support for alpha, hexagon, non-coldfire m68k and
user mode Linux.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Move the source of lib/Kconfig.debug and arch/$(ARCH)/Kconfig.debug to
the top-level Kconfig.  For two architectures that means moving their
arch-specific symbols in that menu into a new arch Kconfig.debug file,
and for a few more creating a dummy file so that we can include it
unconditionally.

Also move the actual 'Kernel hacking' menu to lib/Kconfig.debug, where
it belongs.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Instead of duplicating the source statements in every architecture just
do it once in the toplevel Kconfig file.

Note that with this the inclusion of arch/$(SRCARCH/Kconfig moves out of
the top-level Kconfig into arch/Kconfig so that don't violate ordering
constraits while keeping a sensible menu structure.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea ("mm: mark pages in use for page tables"):

 BUG: Bad page state in process sh  pfn:01ce2
 page:004fefc8 count:0 mapcount:-1024 mapping:00000000 index:0x0
 flags: 0x0()
 raw: 00000000 00000000 00000000 fffffbff 00000000 00000100 00000200 00000000
 raw: 039c4000
 page dumped because: nonzero mapcount
 Modules linked in:
 CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea #13

Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.

Note that I had to change the type of pte_free() to be static from
extern. Otherwise you get a lot of warnings like this:

./arch/m68k/include/asm/mcf_pgalloc.h:80:2: warning: ‘pgtable_page_dtor’ is static but used in inline function ‘pte_free’ which is not static
  pgtable_page_dtor(page);
  ^

And making it static is consistent with our use of this in the other
m68k pgalloc definitions of pte_free().
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
CC: Matthew Wilcox <willy@infradead.org>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>

This avoids a WARNING splat when loading the macsonic or macmace driver.
Please see commit 205e1b7f ("dma-mapping: warn when there is no
coherent_dma_mask").

This implementation of arch_setup_pdev_archdata() differs from the
powerpc one, in that this one avoids clobbering a device dma mask
which has already been initialized.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Acked-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The ColdFire PCI configuration space access functions swap addressing
regions to do their work. Just letting the read/write cycles exit
the CPU core (via the ColdFire "nop" instruction) is not enough to
guarantee that the address region remapping has actually completed.
Insert a read back of the mapping register to be absolutely sure
that the remapping has completed.

This fixes an occasional boot hang during the ColdFire PCI initialization
phase.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

A lot of the ColdFire internal peripherals (clocks, timers, interrupt
controllers, etc) are addressed using constants. The only problem with
that is they are not type clean when used with __raw_read/__raw_write
and read/write - they should be of type "void __iomem". This isn't
a problem currently because the IO access functions are local macros.

To switch to using the asm-generic implementations of these we need to
clean up the types. Otherwise you get warnings like this:

    In file included from ./arch/m68k/include/asm/mcfsim.h:24:0,
                     from arch/m68k/coldfire/intc-simr.c:20:
    arch/m68k/coldfire/intc-simr.c: In function ‘init_IRQ’:
    ./arch/m68k/include/asm/m520xsim.h:40:29: warning: passing argument 2 of ‘__raw_writeb’ makes pointer from integer without a cast [-Wint-conversion]
     #define MCFINTC0_SIMR       (MCFICM_INTC0 + MCFINTC_SIMR)
                                 ^
    arch/m68k/coldfire/intc-simr.c:182:21: note: in expansion of macro ‘MCFINTC0_SIMR’
      __raw_writeb(0xff, MCFINTC0_SIMR);
                         ^
    In file included from ./arch/m68k/include/asm/io_no.h:120:0,
                     from ./arch/m68k/include/asm/io.h:3,
                     from ./include/linux/io.h:25,
                     from ./include/linux/irq.h:25,
                     from ./include/asm-generic/hardirq.h:13,
                     from ./arch/m68k/include/asm/hardirq.h:25,
                     from ./include/linux/hardirq.h:9,
                     from ./include/linux/interrupt.h:13,
                     from arch/m68k/coldfire/intc-simr.c:16:
    ./include/asm-generic/io.h:71:22: note: expected ‘volatile void *’ but argument is of type ‘unsigned int’
     #define __raw_writeb __raw_writeb
                          ^
    ./include/asm-generic/io.h:72:20: note: in expansion of macro ‘__raw_writeb’
     static inline void __raw_writeb(u8 value, volatile void __iomem *addr)
                        ^

To start this clean up process introduce a macro, iomem(), that converts
a constant address to the correct "void __iomem *" type.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Up to now we have only had support for the PCI bus when running the
ColdFire CPU family with the MMU enabled. The only reason for this was
the incomplete state of the IO remapping and access functions when
running with the MMU disabled.

Recent fixes and improvements to the ColdFire IO access code means we
can now support the PCI bus when running non-MMU enabled as well.
So modify the configuration support to allow it to be selected no matter
what choice of MMU mode is used.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

The ColdFire SoC internal peripherals are mapped into virtual address
space using the ACR registers of the cache control unit. This means we
are using a 1:1 physical:virtual mapping for them that does not rely on
page table mappings. We can quickly determine if we are accessing an
internal peripheral device given the physical or vitrual address using
the same range check.

The implications of this mapping is that an ioremap should return the
physical address as the virtual mapping __iomem cookie as well. So fix
ioremap() to deal with this on ColdFire. Of course you need to take
care of this in the iounmap() path as well.
Reported-by: NAngelo Dureghello <angelo@sysam.it>
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

We need to treat built-in peripherals and bus based address ranges
differently. Local built-in peripherals (and the ColdFire SoC parts
have quite a lot of them) are always native endian - which is big
endian on m68k/ColdFire. Bus based address ranges, like the PCI bus,
are accessed little endian - so we need to byte swap those.

So implement readw/writew and readl/writel functions to deal with
memory mapped accesses correctly based on the address range being
accessed.

This fixes readw/writew and readl/writel so that they can be used in
drivers for native SoC hardware modules (many of which are shared with
other architectures (ARM in Freescale SoC parts for example). And also
drivers for PCI devices.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Some ColdFire platforms do have real PCI buses, so we should not be
re-defining or otherwise mangling the IO access functions for them.
So when CONFIG_PCI is true use the real io.h support.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

All the ColdFire IO access support code has been moved to io_no.h.
This means that all ColdFire support is at least now consistent no
matter whether the MMU is enabled or not for them.

Now that io_mm.h has reverted to only support the traditional m68k MMU
enabled processors we can remove the ColdFire specific definitions.

We can also remove the old ColdFire PCI bus IO access functions.
The new io_no.h uses asm-generic/io.h to provide all the basic support.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Use the io_no.h IO access support for all ColdFire systems, no matter
whether configured with MMU enabled or disabled. Previously there was
subtle differences in IO access functions used in both cases, and these
resulted in broken behavior for some drivers.

As observed and reported by Angelo when using MMU enabled systems the
read/write family of functions was using little endian access, while the
non-MMU enabled systems were using native endian. This results in drivers
that are shared across Freescale processors (for some of the common
internal SoC peripherals) not working - since they are wired up for native
endian access.

This problem brings to light issues with PCI bus access and local
peripheral access - but these are not addressed with this fix.
Reported-by: NAngelo Dureghello <angelo@sysam.it>
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Ultimately we want the ColdFire IO access support to be consisent no matter
whether it is configured with MMU enabled or disabled. To acheive that we
need to get all the ColdFire IO access support code together in one place,
in this case io_no.h. The last big piece not in io_no.h is the PCI bus
support functions.

Define the IO mapping addresses required to use the asm-generic IO
access functions. They can provide everything we need - no need for us
to duplicate or have local in/out or read/write access functions.
Note that this support is not active yet, since we haven't done the
full switch over to using the asm-generic functions yet. And also note
that we do not yet remove the old PCI functions from io_mm.h yet.

Consolodating all this IO access support in a single place will make
it easier in the future to enable PCI bus support for non-MMU enabled
ColdFire (which we currently cannot do).
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Create a new header file, kmap.h, that groups all the definitions and
functions associated with the io mapping and remapping.

Currently the functions are spread across raw_io.h and io_mm.h. And in
the future we will want to use these in io_no.h as well. So it makes
sense to move them all together into a single header file.

It is named after the arch/m68k/mm/kmap.c file that actually implements
many of the exported functions.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

The primary and fundamental access macros are really the __raw versions.
So make them the actual implementation for access, and not the read/write
access macros. The read/write macros and functions are built on top of
the raw access (with byte swapping or other actions as required).

This in itself causes no functional change right now. But it will make it
easier to fix and resolve problems with PCI bus access in the future.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

There is nothing really special about the non-MMU m68k IO access functions.
So we can easily switch to using the asm-generic/io.h functions.

The only thing we do need to handle is that historically the m68k IO access
functions for readw/readl/writew/writel use native CPU endian ordering. So
for us on m68k/ColdFire that means they are big-endian. Leave the existing
set of _raw_read/__raw_write and read/write macros in place to deal with
them. (They are ripe for later cleanup, but that is for another patch).
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

The non-MMU and ColdFire IO access functions will be moving to using the
asm-generic/io.h in the near future. To make that possible we need define
guards around the m68k specific virt_to_phys() and phys_to_virt()
functions.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NAngelo Dureghello <angelo@sysam.it>
Tested-by: NAngelo Dureghello <angelo@sysam.it>

If 020/030 support is enabled, get_io_area() leaves an IO_SIZE gap
between mappings which is added to the vm_struct representing the
mapping.  __ioremap() uses the actual requested size (after alignment),
while __iounmap() is passed the size from the vm_struct.

On 020/030, early termination descriptors are used to set up mappings of
extent 'size', which are validated on unmapping. The unmapped gap of
size IO_SIZE defeats the sanity check of the pmd tables, causing
__iounmap() to loop forever on 030.

On 040/060, unmapping of page table entries does not check for a valid
mapping, so the umapping loop always completes there.

Adjust size to be unmapped by the gap that had been added in the
vm_struct prior.

This fixes the hang in atari_platform_init() reported a long time ago,
and a similar one reported by Finn recently (addressed by removing
ioremap() use from the SWIM driver.

Tested on my Falcon in 030 mode - untested but should work the same on
040/060 (the extra page tables cleared there would never have been set
up anyway).
Signed-off-by: NMichael Schmitz <schmitzmic@gmail.com>
[geert: Minor commit description improvements]
[geert: This was fixed in 2.4.23, but not in 2.5.x]
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Revive support for 64-bit get_user(), which was disabled in commit
d94af931 ("[PATCH] m68k: clean up uaccess.h") due to a "broken"
typeof in (then brand new) gcc-4.1.

  - Keep on using u64 for the temporary, as __typeof__() doesn't drop
    the const qualifier,
  - Move it into a union (like mips32 does) to get rid of the cast, as
    using get_user() to fetch a __user pointer would cause a "cast to
    pointer from integer of different size" warning otherwise.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMartijn Coenen <maco@android.com>

ndelay() is supposed to take an unsigned long, but if you define
ndelay() as a macro and the caller pass an unsigned long long instead
of an unsigned long, the unsigned long long to unsigned long cast is
not done and we end up with an "undefined reference to `__udivdi3'"
error at link time.

Fix that by making ndelay() an inline function and then defining dummy
ndelay() macro that redirects to the ndelay() function (it's how most
archs do to implement ndelay()).

Fixes: c8ee038b ("m68k: Implement ndelay() based on the existing udelay() logic")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
[geert: Remove comment now it is no longer a macro]
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

We have two ways of getting the current time from a platform at boot
or during suspend: either using read_persistent_clock() or the rtc
class operation. We never need both, so I'm hiding the
read_persistent_clock variant when the generic RTC is enabled.

Since read_persistent_clock() and mktime() are deprecated because of
the y2038 overflow of time_t, we should use the time64_t based
replacements here.

Finally, the dependency on CONFIG_ARCH_USES_GETTIMEOFFSET looks
completely bogus in this case, so let's remove that. It was
added in commit b13b3f51 ("m68k: fix inclusion of
arch_gettimeoffset for non-MMU 68k classic CPU types") to deal
with arch_gettimeoffset(), which has since been removed from
this file and is unrelated to the RTC functions.

The rtc accessors are only used by classic machines, while
coldfire uses proper RTC drivers, so we can put the old
ifdef back around both functions.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

This fixes a bug in read_persistent_clock() which causes the system
clock to lag the Real Time Clock by one month. The problem was noticed
on a Mac, but theoretically it must also affect Atari, BVME6000 and Q40.

The tm_mon value in the struct rtc_time passed to mach_hwclk() is
zero-based, and atari_mste_hwclk(), atari_tt_hwclk(), bvme6000_hwclk(),
mac_hwclk() and q40_hwclk() all make this adjustment. Unfortunately,
dn_dummy_hwclk(), mvme147_hwclk(), mvme16x_hwclk(), sun3_hwclk() and
sun3x_hwclk() fail to decrement tm_mon.  Also m68328_hwclk() assumes
a one-based tm_mon.

Bring these platforms into line and fix read_persistent_clock() so it
works correctly on all m68k platforms.

The datasheets for the RTC devices found on the affected platforms
all confirm that the year is stored as a value in the range 0-99 and
the month is stored as a value in the range 1-12. Please refer to the
datasheets for MC146818 (Apollo), DS1643 (MVME), ICM7170 (Sun 3)
and M48T02 (Sun 3x).
Reported-by: NStan Johnson <userm57@yahoo.com>
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Fixes: 4be33329 ("m68k: Verify the offsets in struct siginfo never change.")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The resource size is 0x2000 == end - start + 1.
Therefore end == start + 0x2000 - 1.

Cc: Laurent Vivier <lvivier@redhat.com>
Cc: stable@vger.kernel.org # v4.14+
Tested-by: NStan Johnson <userm57@yahoo.com>
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Acked-by: NLaurent Vivier <lvivier@redhat.com>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Variants of proc_create{,_data} that directly take a seq_file show
callback and drastically reduces the boilerplate code in the callers.

All trivial callers converted over.
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This was used by the ide, scsi and networking code in the past to
determine if they should bounce payloads.  Now that the dma mapping
always have to support dma to all physical memory (thanks to swiotlb
for non-iommu systems) there is no need to this crude hack any more.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: Palmer Dabbelt <palmer@sifive.com> (for riscv)
Reviewed-by: NJens Axboe <axboe@kernel.dk>

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Call clear_siginfo to ensure every stack allocated siginfo is properly
initialized before being passed to the signal sending functions.

Note: It is not safe to depend on C initializers to initialize struct
siginfo on the stack because C is allowed to skip holes when
initializing a structure.

The initialization of struct siginfo in tracehook_report_syscall_exit
was moved from the helper user_single_step_siginfo into
tracehook_report_syscall_exit itself, to make it clear that the local
variable siginfo gets fully initialized.

In a few cases the scope of struct siginfo has been reduced to make it
clear that siginfo siginfo is not used on other paths in the function
in which it is declared.

Instances of using memset to initialize siginfo have been replaced
with calls clear_siginfo for clarity.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

We have a couple of files that try to include asm/compat.h on
architectures where this is available. Those should generally use the
higher-level linux/compat.h file, but that in turn fails to include
asm/compat.h when CONFIG_COMPAT is disabled, unless we can provide
that header on all architectures.

This adds the asm/compat.h for all remaining architectures to
simplify the dependencies.

Architectures that are getting removed in linux-4.17 are not changed
here, to avoid needless conflicts with the removal patches. Those
architectures are broken by this patch, but we have already shown
that they have no users.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

A change to the generic struct siginfo accidentally changed the offset
of si_offset.  Add build time checks to ensure the offsets of all known
fields in struct siginfo never change.  This copies the form of similar
changes on x86.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Using this helper allows us to avoid the in-kernel calls to the
sys_mmap_pgoff() syscall. The ksys_ prefix denotes that this function is
meant as a drop-in replacement for the syscall. In particular, it uses the
same calling convention as sys_mmap_pgoff().

This patch is part of a series which removes in-kernel calls to syscalls.
On this basis, the syscall entry path can be streamlined. For details, see
http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.net

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

As of commit 205e1b7f ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
        41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
        400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
        40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
        00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
        7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
        40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
Call Trace:
        [<40025534>] 0x40025534
 [<4004e514>] 0x4004e514
 [<400255de>] 0x400255de
 [<40159e20>] 0x40159e20
 [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.
Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>

This code works fine. The comment is misleading so remove it.
Tested-by: NStan Johnson <userm57@yahoo.com>
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

According to Apple's Developer Notes, all of the early PowerBook models
have their RTC connected to VIA1. Use the VIA clock ops as appropriate.
This was tested on a PowerBook 170.

Don't use the VIA ops when not appropriate. Calling unimplemented clock
or PRAM getter or setter ops can now result in an error instead of
failing silently.
Tested-by: NStan Johnson <userm57@yahoo.com>
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The RTC core is always calling rtc_valid_tm after the read_time callback.
It is not necessary to call it just before returning from the callback.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>