linux-next: manual merge of the rtc tree with the tip tree

linux-next: manual merge of the rtc tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

Hi all,

Today's linux-next merge of the rtc tree got a conflict in:

  include/linux/rtc.h

between commit:

  33e62e832384 ("ntp, rtc: Move rtc_set_ntp_time() to ntp code")

from the tip tree and commit:

  fdcfd854333b ("rtc: rework rtc_register_device() resource management")

from the rtc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/rtc.h
index b829382de6c3,55e7beed066c..000000000000
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@@ -110,43 -110,14 +110,37 @@@ struct rtc_device 
  	/* Some hardware can't support UIE mode */
  	int uie_unsupported;
  
 -	/* Number of nsec it takes to set the RTC clock. This influences when
 -	 * the set ops are called. An offset:
 -	 *   - of 0.5 s will call RTC set for wall clock time 10.0 s at 9.5 s
 -	 *   - of 1.5 s will call RTC set for wall clock time 10.0 s at 8.5 s
 -	 *   - of -0.5 s will call RTC set for wall clock time 10.0 s at 10.5 s
 +	/*
 +	 * This offset specifies the update timing of the RTC.
 +	 *
 +	 * tsched     t1 write(t2.tv_sec - 1sec))  t2 RTC increments seconds
 +	 *
 +	 * The offset defines how tsched is computed so that the write to
 +	 * the RTC (t2.tv_sec - 1sec) is correct versus the time required
 +	 * for the transport of the write and the time which the RTC needs
 +	 * to increment seconds the first time after the write (t2).
 +	 *
 +	 * For direct accessible RTCs tsched ~= t1 because the write time
 +	 * is negligible. For RTCs behind slow busses the transport time is
 +	 * significant and has to be taken into account.
 +	 *
 +	 * The time between the write (t1) and the first increment after
 +	 * the write (t2) is RTC specific. For a MC146818 RTC it's 500ms,
 +	 * for many others it's exactly 1 second. Consult the datasheet.
 +	 *
 +	 * The value of this offset is also used to calculate the to be
 +	 * written value (t2.tv_sec - 1sec) at tsched.
 +	 *
 +	 * The default value for this is NSEC_PER_SEC + 10 msec default
 +	 * transport time. The offset can be adjusted by drivers so the
 +	 * calculation for the to be written value at tsched becomes
 +	 * correct:
 +	 *
 +	 *	newval = tsched + set_offset_nsec - NSEC_PER_SEC
 +	 * and  (tsched + set_offset_nsec) % NSEC_PER_SEC == 0
  	 */
 -	long set_offset_nsec;
 +	unsigned long set_offset_nsec;
  
- 	bool registered;
- 
- 	/* Old ABI support */
- 	bool nvram_old_abi;
- 	struct bin_attribute *nvram;
- 
  	time64_t range_min;
  	timeu64_t range_max;
  	time64_t start_secs;
@@@ -227,8 -199,41 +221,8 @@@ static inline bool is_leap_year(unsigne
  	return (!(year % 4) && (year % 100)) || !(year % 400);
  }
  
- #define rtc_register_device(device) \
- 	__rtc_register_device(THIS_MODULE, device)
 -/* Determine if we can call to driver to set the time. Drivers can only be
 - * called to set a second aligned time value, and the field set_offset_nsec
 - * specifies how far away from the second aligned time to call the driver.
 - *
 - * This also computes 'to_set' which is the time we are trying to set, and has
 - * a zero in tv_nsecs, such that:
 - *    to_set - set_delay_nsec == now +/- FUZZ
 - *
 - */
 -static inline bool rtc_tv_nsec_ok(s64 set_offset_nsec,
 -				  struct timespec64 *to_set,
 -				  const struct timespec64 *now)
 -{
 -	/* Allowed error in tv_nsec, arbitarily set to 5 jiffies in ns. */
 -	const unsigned long TIME_SET_NSEC_FUZZ = TICK_NSEC * 5;
 -	struct timespec64 delay = {.tv_sec = 0,
 -				   .tv_nsec = set_offset_nsec};
 -
 -	*to_set = timespec64_add(*now, delay);
 -
 -	if (to_set->tv_nsec < TIME_SET_NSEC_FUZZ) {
 -		to_set->tv_nsec = 0;
 -		return true;
 -	}
 -
 -	if (to_set->tv_nsec > NSEC_PER_SEC - TIME_SET_NSEC_FUZZ) {
 -		to_set->tv_sec++;
 -		to_set->tv_nsec = 0;
 -		return true;
 -	}
 -	return false;
 -}
 -
+ #define devm_rtc_register_device(device) \
+ 	__devm_rtc_register_device(THIS_MODULE, device)
  
  #ifdef CONFIG_RTC_HCTOSYS_DEVICE
  extern int rtc_hctosys_ret;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rtc tree with the tip tree

[Stephen Rothwell]

Hi Alexandre,

Today's linux-next merge of the rtc tree got a conflict in:

  arch/x86/platform/efi/efi_64.c

between commit:

  cc3ae7b0af27 ("x86/platform: Audit and remove any unnecessary uses of module.h")

from the tip tree and commit:

  5ab788d73832 ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")

from the rtc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/platform/efi/efi_64.c
index 04db6fbce96d,663c282801f3..000000000000
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@@ -24,7 -24,8 +24,8 @@@
  #include <linux/spinlock.h>
  #include <linux/bootmem.h>
  #include <linux/ioport.h>
 -#include <linux/module.h>
 +#include <linux/init.h>
+ #include <linux/mc146818rtc.h>
  #include <linux/efi.h>
  #include <linux/uaccess.h>
  #include <linux/io.h>