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

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

[Stephen Rothwell]

Hi Linus,

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

  include/linux/bitops.h

between commit:

  cbe96375025e ("bitops: Add clear/set_bit32() to linux/bitops.h")

from the tip tree and commit:

  5307e2ad69ab ("bitops: Introduce assign_bit()")

from the gpio 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/bitops.h
index 15a5bcfcd0a2,9a874deee6e2..000000000000
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@@ -227,32 -227,30 +227,56 @@@ static inline unsigned long __ffs64(u6
  	return __ffs((unsigned long)word);
  }
  
 +/*
 + * clear_bit32 - Clear a bit in memory for u32 array
 + * @nr: Bit to clear
 + * @addr: u32 * address of bitmap
 + *
 + * Same as clear_bit, but avoids needing casts for u32 arrays.
 + */
 +
 +static __always_inline void clear_bit32(long nr, volatile u32 *addr)
 +{
 +	clear_bit(nr, (volatile unsigned long *)addr);
 +}
 +
 +/*
 + * set_bit32 - Set a bit in memory for u32 array
 + * @nr: Bit to clear
 + * @addr: u32 * address of bitmap
 + *
 + * Same as set_bit, but avoids needing casts for u32 arrays.
 + */
 +
 +static __always_inline void set_bit32(long nr, volatile u32 *addr)
 +{
 +	set_bit(nr, (volatile unsigned long *)addr);
 +}
 +
+ /**
+  * assign_bit - Assign value to a bit in memory
+  * @nr: the bit to set
+  * @addr: the address to start counting from
+  * @value: the value to assign
+  */
+ static __always_inline void assign_bit(long nr, volatile unsigned long *addr,
+ 				       bool value)
+ {
+ 	if (value)
+ 		set_bit(nr, addr);
+ 	else
+ 		clear_bit(nr, addr);
+ }
+ 
+ static __always_inline void __assign_bit(long nr, volatile unsigned long *addr,
+ 					 bool value)
+ {
+ 	if (value)
+ 		__set_bit(nr, addr);
+ 	else
+ 		__clear_bit(nr, addr);
+ }
+ 
  #ifdef __KERNEL__
  
  #ifndef set_mask_bits

Re: linux-next: manual merge of the gpio tree with the tip tree

[Peter Zijlstra]

On Thu, Nov 02, 2017 at 03:59:52PM +1100, Stephen Rothwell wrote:
> diff --cc include/linux/bitops.h
> index 15a5bcfcd0a2,9a874deee6e2..000000000000
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@@ -227,32 -227,30 +227,56 @@@ static inline unsigned long __ffs64(u6
>   	return __ffs((unsigned long)word);
>   }
>   
>  +/*
>  + * clear_bit32 - Clear a bit in memory for u32 array
>  + * @nr: Bit to clear
>  + * @addr: u32 * address of bitmap
>  + *
>  + * Same as clear_bit, but avoids needing casts for u32 arrays.
>  + */
>  +
>  +static __always_inline void clear_bit32(long nr, volatile u32 *addr)
>  +{
>  +	clear_bit(nr, (volatile unsigned long *)addr);
>  +}
>  +
>  +/*
>  + * set_bit32 - Set a bit in memory for u32 array
>  + * @nr: Bit to clear
>  + * @addr: u32 * address of bitmap
>  + *
>  + * Same as set_bit, but avoids needing casts for u32 arrays.
>  + */
>  +
>  +static __always_inline void set_bit32(long nr, volatile u32 *addr)
>  +{
>  +	set_bit(nr, (volatile unsigned long *)addr);
>  +}

How is that not fundamentally broken for big-endian?

Re: linux-next: manual merge of the gpio tree with the tip tree

[Stephen Rothwell]

Hi Peter,

On Thu, 2 Nov 2017 09:06:27 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Nov 02, 2017 at 03:59:52PM +1100, Stephen Rothwell wrote:
> > diff --cc include/linux/bitops.h
> > index 15a5bcfcd0a2,9a874deee6e2..000000000000
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@@ -227,32 -227,30 +227,56 @@@ static inline unsigned long __ffs64(u6
> >   	return __ffs((unsigned long)word);
> >   }
> >   
> >  +/*
> >  + * clear_bit32 - Clear a bit in memory for u32 array
> >  + * @nr: Bit to clear
> >  + * @addr: u32 * address of bitmap
> >  + *
> >  + * Same as clear_bit, but avoids needing casts for u32 arrays.
> >  + */
> >  +
> >  +static __always_inline void clear_bit32(long nr, volatile u32 *addr)
> >  +{
> >  +	clear_bit(nr, (volatile unsigned long *)addr);
> >  +}
> >  +
> >  +/*
> >  + * set_bit32 - Set a bit in memory for u32 array
> >  + * @nr: Bit to clear
> >  + * @addr: u32 * address of bitmap
> >  + *
> >  + * Same as set_bit, but avoids needing casts for u32 arrays.
> >  + */
> >  +
> >  +static __always_inline void set_bit32(long nr, volatile u32 *addr)
> >  +{
> >  +	set_bit(nr, (volatile unsigned long *)addr);
> >  +}  
> 
> How is that not fundamentally broken for big-endian?

Yes, that went through my mind as well :-)

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the gpio tree with the tip tree

[Peter Zijlstra]

On Thu, Nov 02, 2017 at 09:06:27AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 03:59:52PM +1100, Stephen Rothwell wrote:
> > diff --cc include/linux/bitops.h
> > index 15a5bcfcd0a2,9a874deee6e2..000000000000
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@@ -227,32 -227,30 +227,56 @@@ static inline unsigned long __ffs64(u6
> >   	return __ffs((unsigned long)word);
> >   }
> >   
> >  +/*
> >  + * clear_bit32 - Clear a bit in memory for u32 array
> >  + * @nr: Bit to clear
> >  + * @addr: u32 * address of bitmap
> >  + *
> >  + * Same as clear_bit, but avoids needing casts for u32 arrays.
> >  + */
> >  +
> >  +static __always_inline void clear_bit32(long nr, volatile u32 *addr)
> >  +{
> >  +	clear_bit(nr, (volatile unsigned long *)addr);
> >  +}
> >  +
> >  +/*
> >  + * set_bit32 - Set a bit in memory for u32 array
> >  + * @nr: Bit to clear
> >  + * @addr: u32 * address of bitmap
> >  + *
> >  + * Same as set_bit, but avoids needing casts for u32 arrays.
> >  + */
> >  +
> >  +static __always_inline void set_bit32(long nr, volatile u32 *addr)
> >  +{
> >  +	set_bit(nr, (volatile unsigned long *)addr);
> >  +}
> 
> How is that not fundamentally broken for big-endian?

I think its broken in another way as well, {set,clear}_bit() are atomic
ops that expect a naturally aligned 'unsigned long', and that cast can
break the alignment as well.

And I'm fairly sure we have architectures where the atomic ops
misbehave or maybe even trap when you don't feed them properly aligned
data.

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

[Stephen Rothwell]

Hi Linus,

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

  tools/Makefile

between commit:

  442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation")

from the tip tree and commit:

  6d591c46bce0 ("tools/gpio: create GPIO tools")

from the gpio tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc tools/Makefile
index cc2a37d975d6,f41e7c6ea23e..000000000000
--- a/tools/Makefile
+++ b/tools/Makefile
@@@ -54,7 -54,7 +55,7 @@@ acpi: FORC
  cpupower: FORCE
  	$(call descend,power/$@)
  
- cgroup firewire hv guest spi usb virtio vm net iio objtool: FORCE
 -cgroup firewire hv guest spi usb virtio vm net iio gpio: FORCE
++cgroup firewire hv guest spi usb virtio vm net iio objtool gpio: FORCE
  	$(call descend,$@)
  
  liblockdep: FORCE
@@@ -120,7 -120,7 +121,7 @@@ acpi_clean
  cpupower_clean:
  	$(call descend,power/cpupower,clean)
  
- cgroup_clean hv_clean firewire_clean lguest_clean spi_clean usb_clean virtio_clean vm_clean net_clean iio_clean objtool_clean:
 -cgroup_clean hv_clean firewire_clean lguest_clean spi_clean usb_clean virtio_clean vm_clean net_clean iio_clean gpio_clean:
++cgroup_clean hv_clean firewire_clean lguest_clean spi_clean usb_clean virtio_clean vm_clean net_clean iio_clean objtool_clean gpio_clean:
  	$(call descend,$(@:_clean=),clean)
  
  liblockdep_clean:
@@@ -157,6 -157,6 +158,6 @@@ clean: acpi_clean cgroup_clean cpupower
  		perf_clean selftests_clean turbostat_clean spi_clean usb_clean virtio_clean \
  		vm_clean net_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
  		freefall_clean build_clean libbpf_clean libsubcmd_clean liblockdep_clean \
- 		objtool_clean
 -		gpio_clean
++		objtool_clean gpio_clean
  
  .PHONY: FORCE