[PATCH 0/2] x86: turn off wrongly enabled CONFIG_GENERIC_HWEIGHT

[PATCH 0/2] x86: turn off wrongly enabled CONFIG_GENERIC_HWEIGHT

[Masahiro Yamada]

x86 should not enable CONFIG_GENERIC_HWEIGHT
because lib/hweight.c is not used by x86.

The only user is drivers/net/wireless/mediatek/mt76/mac80211.c

Of course, this driver is wrong since drivers should use the
generic API, hweight8().

After fixing it, x86 does not need to compile lib/hweight.c at all.

The real implementation is located in arch/x86/lib/hweight.S



Masahiro Yamada (2):
  wireless: mt76: call hweight8() instead of __sw_hweight8()
  x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT

 arch/x86/Kconfig                              | 3 ---
 arch/x86/include/asm/arch_hweight.h           | 2 --
 drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
 lib/hweight.c                                 | 4 ----
 4 files changed, 1 insertion(+), 10 deletions(-)

-- 
2.7.4

[PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Masahiro Yamada]

__sw_hweight8() is just internal implementation.

Drivers should use the common API, hweight8().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

This patch should go to x86 tree along with 2/2.

Otherwise, all{yes,mod}config of x86 would be broken.

This patch is trivial enough.
I want ACK from the net/wireless maintainer
so that this can go in via x86 tree.


 drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 7b926df..c42e0d3 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -124,7 +124,7 @@ static void mt76_init_stream_cap(struct mt76_dev *dev,
 				 bool vht)
 {
 	struct ieee80211_sta_ht_cap *ht_cap = &sband->ht_cap;
-	int i, nstream = __sw_hweight8(dev->antenna_mask);
+	int i, nstream = hweight8(dev->antenna_mask);
 	struct ieee80211_sta_vht_cap *vht_cap;
 	u16 mcs_map = 0;
 
-- 
2.7.4

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Kalle Valo]

Masahiro Yamada <yamada.masahiro@socionext.com> writes:

> __sw_hweight8() is just internal implementation.
>
> Drivers should use the common API, hweight8().
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Acked-by: Kalle Valo <kvalo@codeaurora.org>

> This patch should go to x86 tree along with 2/2.
>
> Otherwise, all{yes,mod}config of x86 would be broken.
>
> This patch is trivial enough.
> I want ACK from the net/wireless maintainer
> so that this can go in via x86 tree.

Sounds good to me, feel free to push via the x86 tree.

-- 
Kalle Valo

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Kalle Valo]

Kalle Valo <kvalo@codeaurora.org> writes:

> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>
>> __sw_hweight8() is just internal implementation.
>>
>> Drivers should use the common API, hweight8().
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>
>> This patch should go to x86 tree along with 2/2.
>>
>> Otherwise, all{yes,mod}config of x86 would be broken.
>>
>> This patch is trivial enough.
>> I want ACK from the net/wireless maintainer
>> so that this can go in via x86 tree.
>
> Sounds good to me, feel free to push via the x86 tree.

Actually, can you wait a bit? Felix just reminded me that we have a
similar patch pending from Ben Hutchings:

https://patchwork.kernel.org/patch/10808203/

And it seems there are two instances of __sw_hweight8, at least in my
wireless-drivers-next tree:

drivers/net/wireless/mediatek/mt76/mac80211.c:  int i, nstream = __sw_hweight8(dev->antenna_mask);
drivers/net/wireless/mediatek/mt76/mac80211.c:  int n_chains = __sw_hweight8(dev->antenna_mask);

So we need to think what to do.

-- 
Kalle Valo

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Kalle Valo]

Kalle Valo <kvalo@codeaurora.org> writes:

> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>>
>>> __sw_hweight8() is just internal implementation.
>>>
>>> Drivers should use the common API, hweight8().
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>>
>>> This patch should go to x86 tree along with 2/2.
>>>
>>> Otherwise, all{yes,mod}config of x86 would be broken.
>>>
>>> This patch is trivial enough.
>>> I want ACK from the net/wireless maintainer
>>> so that this can go in via x86 tree.
>>
>> Sounds good to me, feel free to push via the x86 tree.
>
> Actually, can you wait a bit? Felix just reminded me that we have a
> similar patch pending from Ben Hutchings:
>
> https://patchwork.kernel.org/patch/10808203/
>
> And it seems there are two instances of __sw_hweight8, at least in my
> wireless-drivers-next tree:
>
> drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> __sw_hweight8(dev->antenna_mask);
> drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> __sw_hweight8(dev->antenna_mask);
>
> So we need to think what to do.

I think the best would be that Felix applies Ben's patch to the wireless
tree and I'll push it to Linus during the next merge window (via
net-next). Simpler and less conflicts that way.

So Masahiro, could you hold your x86 patch for a while until the mt76
patch will be in Linus' tree? That should not take more than two weeks,
I think.

-- 
Kalle Valo

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Borislav Petkov]

On Mon, Feb 18, 2019 at 09:20:46PM +0200, Kalle Valo wrote:
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.

No hurry - I won't take it into the x86 now and queue it for 5.1 because
it is not something urgent or fixing a bug or so. It is a cleanup and as
such it can surely wait for 5.2, I'd say. Unless there are other aspects
which I'm not thinking of right now...

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Masahiro Yamada]

On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Kalle Valo <kvalo@codeaurora.org> writes:
> >
> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> >>
> >>> __sw_hweight8() is just internal implementation.
> >>>
> >>> Drivers should use the common API, hweight8().
> >>>
> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >>
> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> >>
> >>> This patch should go to x86 tree along with 2/2.
> >>>
> >>> Otherwise, all{yes,mod}config of x86 would be broken.
> >>>
> >>> This patch is trivial enough.
> >>> I want ACK from the net/wireless maintainer
> >>> so that this can go in via x86 tree.
> >>
> >> Sounds good to me, feel free to push via the x86 tree.
> >
> > Actually, can you wait a bit? Felix just reminded me that we have a
> > similar patch pending from Ben Hutchings:
> >
> > https://patchwork.kernel.org/patch/10808203/
> >
> > And it seems there are two instances of __sw_hweight8, at least in my
> > wireless-drivers-next tree:
> >
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> > __sw_hweight8(dev->antenna_mask);
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> > __sw_hweight8(dev->antenna_mask);
> >
> > So we need to think what to do.
>
> I think the best would be that Felix applies Ben's patch to the wireless
> tree and I'll push it to Linus during the next merge window (via
> net-next). Simpler and less conflicts that way.
>
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.

Sure.
I will resend 2/2 later.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()

[Kalle Valo]

Masahiro Yamada <yamada.masahiro@socionext.com> writes:

> On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>> > Kalle Valo <kvalo@codeaurora.org> writes:
>> >
>> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>> >>
>> >>> __sw_hweight8() is just internal implementation.
>> >>>
>> >>> Drivers should use the common API, hweight8().
>> >>>
>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >>
>> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>> >>
>> >>> This patch should go to x86 tree along with 2/2.
>> >>>
>> >>> Otherwise, all{yes,mod}config of x86 would be broken.
>> >>>
>> >>> This patch is trivial enough.
>> >>> I want ACK from the net/wireless maintainer
>> >>> so that this can go in via x86 tree.
>> >>
>> >> Sounds good to me, feel free to push via the x86 tree.
>> >
>> > Actually, can you wait a bit? Felix just reminded me that we have a
>> > similar patch pending from Ben Hutchings:
>> >
>> > https://patchwork.kernel.org/patch/10808203/
>> >
>> > And it seems there are two instances of __sw_hweight8, at least in my
>> > wireless-drivers-next tree:
>> >
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
>> > __sw_hweight8(dev->antenna_mask);
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
>> > __sw_hweight8(dev->antenna_mask);
>> >
>> > So we need to think what to do.
>>
>> I think the best would be that Felix applies Ben's patch to the wireless
>> tree and I'll push it to Linus during the next merge window (via
>> net-next). Simpler and less conflicts that way.
>>
>> So Masahiro, could you hold your x86 patch for a while until the mt76
>> patch will be in Linus' tree? That should not take more than two weeks,
>> I think.
>
> Sure.
> I will resend 2/2 later.

Great, thanks!

-- 
Kalle Valo

[PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT

[Masahiro Yamada]

arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
alternatives, but they are implemented in arch/x86/lib/hweight.S

x86 does not rely on the generic C implementation lib/hweight.c
at all, so CONFIG_GENERIC_HWEIGHT should be disabled.

__HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/x86/Kconfig                    | 3 ---
 arch/x86/include/asm/arch_hweight.h | 2 --
 lib/hweight.c                       | 4 ----
 3 files changed, 9 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6826143..c2813af 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -262,9 +262,6 @@ config GENERIC_BUG
 config GENERIC_BUG_RELATIVE_POINTERS
 	bool
 
-config GENERIC_HWEIGHT
-	def_bool y
-
 config ARCH_MAY_HAVE_PC_FDC
 	def_bool y
 	depends on ISA_DMA_API
diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
index fc06935..ba88edd 100644
--- a/arch/x86/include/asm/arch_hweight.h
+++ b/arch/x86/include/asm/arch_hweight.h
@@ -12,8 +12,6 @@
 #define REG_OUT "a"
 #endif
 
-#define __HAVE_ARCH_SW_HWEIGHT
-
 static __always_inline unsigned int __arch_hweight32(unsigned int w)
 {
 	unsigned int res;
diff --git a/lib/hweight.c b/lib/hweight.c
index 7660d88..c94586b 100644
--- a/lib/hweight.c
+++ b/lib/hweight.c
@@ -10,7 +10,6 @@
  * The Hamming Weight of a number is the total number of bits set in it.
  */
 
-#ifndef __HAVE_ARCH_SW_HWEIGHT
 unsigned int __sw_hweight32(unsigned int w)
 {
 #ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
@@ -27,7 +26,6 @@ unsigned int __sw_hweight32(unsigned int w)
 #endif
 }
 EXPORT_SYMBOL(__sw_hweight32);
-#endif
 
 unsigned int __sw_hweight16(unsigned int w)
 {
@@ -46,7 +44,6 @@ unsigned int __sw_hweight8(unsigned int w)
 }
 EXPORT_SYMBOL(__sw_hweight8);
 
-#ifndef __HAVE_ARCH_SW_HWEIGHT
 unsigned long __sw_hweight64(__u64 w)
 {
 #if BITS_PER_LONG == 32
@@ -69,4 +66,3 @@ unsigned long __sw_hweight64(__u64 w)
 #endif
 }
 EXPORT_SYMBOL(__sw_hweight64);
-#endif
-- 
2.7.4

Re: [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT

[Borislav Petkov]

On Mon, Feb 18, 2019 at 02:59:31PM +0900, Masahiro Yamada wrote:
> arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
> alternatives, but they are implemented in arch/x86/lib/hweight.S
> 
> x86 does not rely on the generic C implementation lib/hweight.c
> at all, so CONFIG_GENERIC_HWEIGHT should be disabled.
> 
> __HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.

Well, it was needed because I didn't think of removing the selection of
GENERIC_HWEIGHT in arch/x86/ at the time:

ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:27: multiple definition of `__ksymtab___sw_hweight32'; arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:47: first defined here
ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:67: multiple definition of `__ksymtab___sw_hweight64'; arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:48: first defined here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight32':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:12: multiple definition of `__sw_hweight32'; lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:15: first defined here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight64':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:38: multiple definition of `__sw_hweight64'; lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:53: first defined here
make: *** [vmlinux] Error 1

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT

[Masahiro Yamada]

On Mon, Feb 18, 2019 at 3:09 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
> alternatives, but they are implemented in arch/x86/lib/hweight.S
>
> x86 does not rely on the generic C implementation lib/hweight.c
> at all, so CONFIG_GENERIC_HWEIGHT should be disabled.
>
> __HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


Maintainers,

As I replied to 1/2,
please ignore this for now.


I will resend this later,
hopefully in the next development cycle.


> ---
>
>  arch/x86/Kconfig                    | 3 ---
>  arch/x86/include/asm/arch_hweight.h | 2 --
>  lib/hweight.c                       | 4 ----
>  3 files changed, 9 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6826143..c2813af 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -262,9 +262,6 @@ config GENERIC_BUG
>  config GENERIC_BUG_RELATIVE_POINTERS
>         bool
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config ARCH_MAY_HAVE_PC_FDC
>         def_bool y
>         depends on ISA_DMA_API
> diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
> index fc06935..ba88edd 100644
> --- a/arch/x86/include/asm/arch_hweight.h
> +++ b/arch/x86/include/asm/arch_hweight.h
> @@ -12,8 +12,6 @@
>  #define REG_OUT "a"
>  #endif
>
> -#define __HAVE_ARCH_SW_HWEIGHT
> -
>  static __always_inline unsigned int __arch_hweight32(unsigned int w)
>  {
>         unsigned int res;
> diff --git a/lib/hweight.c b/lib/hweight.c
> index 7660d88..c94586b 100644
> --- a/lib/hweight.c
> +++ b/lib/hweight.c
> @@ -10,7 +10,6 @@
>   * The Hamming Weight of a number is the total number of bits set in it.
>   */
>
> -#ifndef __HAVE_ARCH_SW_HWEIGHT
>  unsigned int __sw_hweight32(unsigned int w)
>  {
>  #ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
> @@ -27,7 +26,6 @@ unsigned int __sw_hweight32(unsigned int w)
>  #endif
>  }
>  EXPORT_SYMBOL(__sw_hweight32);
> -#endif
>
>  unsigned int __sw_hweight16(unsigned int w)
>  {
> @@ -46,7 +44,6 @@ unsigned int __sw_hweight8(unsigned int w)
>  }
>  EXPORT_SYMBOL(__sw_hweight8);
>
> -#ifndef __HAVE_ARCH_SW_HWEIGHT
>  unsigned long __sw_hweight64(__u64 w)
>  {
>  #if BITS_PER_LONG == 32
> @@ -69,4 +66,3 @@ unsigned long __sw_hweight64(__u64 w)
>  #endif
>  }
>  EXPORT_SYMBOL(__sw_hweight64);
> -#endif
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada