Re: [PATCH] net: wireless: mediatek: fix mt76 LEDS build error

2018-09-19 Thread Randy Dunlap
On 9/19/18 9:07 AM, Kalle Valo wrote:
> Kalle Valo  writes:
> 
>> Lorenzo Bianconi  writes:
>>
>>>> From: Randy Dunlap 
>>>>
>>>> All of the mt76 driver options use its mac80211.o component,
>>>> which uses led interfaces, so each of them should depend on
>>>> LEDS_CLASS.
>>>>
>>>> Fixes this build error:
>>>>
>>>> drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_led_init':
>>>> drivers/net/wireless/mediatek/mt76/mac80211.c:119: undefined
>>>> reference to `devm_of_led_classdev_register'
>>>>
>>>> Fixes: 17f1de56df05 ("mt76: add common code shared between multiple 
>>>> chipsets")
>>>>
>>>
>>> Hi Randy,
>>>
>>> a fix for it has been already proposed by Arnd here:
>>> https://marc.info/?l=linux-wireless=151628136830540=2
>>> but it has not been applied yet
>>
>> Yet? Arnd's patch is not on my queue as it's from last January and Felix
>> had a comment for it:
>>
>> https://patchwork.kernel.org/patch/10173197/
> 
> So what should we do? Arnd hasn't submitted a new patch so should we
> take this one instead?

No.  Arnd, can you resend your patch?

thanks,
-- 
~Randy


Re: [PATCH v1] PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry

2018-07-28 Thread Randy Dunlap
On 07/28/2018 05:29 PM, Joe Perches wrote:
> On Fri, 2018-07-27 at 23:39 +0300, Andy Shevchenko wrote:
>> There are a lot of examples in the kernel where PCI_VDEVICE() is used and 
>> still
>> looks not so convenient due to additional driver_data field attached.
>>
>> Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in 
>> shortest
>> possible form. For example,
>>
>>   before:
>>
>> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD),
>>   (kernel_ulong_t) _pci_mrfld_properties, },
>>
>>   after:
>>
>> { PCI_VDEVICE(INTEL, INTEL_MRFLD, _pci_mrfld_properties },
> 
> PCI_DEVICE_DATA(...)
> 

see v2 and v3 :)


-- 
~Randy


Re: [PATCH v2] PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry

2018-07-27 Thread Randy Dunlap
On 07/27/2018 01:43 PM, Andy Shevchenko wrote:
> There are a lot of examples in the kernel where PCI_VDEVICE() is used and 
> still
> looks not so convenient due to additional driver_data field attached.
> 
> Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in 
> shortest
> possible form. For example,
> 
>   before:
> 
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD),
>   (kernel_ulong_t) _pci_mrfld_properties, },
> 
>   after:
> 
> { PCI_VDEVICE(INTEL, INTEL_MRFLD, _pci_mrfld_properties },

  { PCI_DEVICE_DATA(   ies) },

I guess.  or what?

> 
> Drivers can be converted later on in independent way.
> 
> While here, remove the unused macro with the same name
> from Ralink wireless driver.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2x00pci.h |  6 --
>  include/linux/pci.h| 15 +++
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h 
> b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> index bc0ca5f58f38..283e2e607bba 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> @@ -27,12 +27,6 @@
>  #include 
>  #include 
>  
> -/*
> - * This variable should be used with the
> - * pci_driver structure initialization.
> - */
> -#define PCI_DEVICE_DATA(__ops)   .driver_data = (kernel_ulong_t)(__ops)
> -
>  /*
>   * PCI driver handlers.
>   */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d0961aefdbae..754da6f9adb3 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -825,6 +825,21 @@ struct pci_driver {
>   .vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
>   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0
>  
> +/**
> + * PCI_DEVICE_DATA - macro used to describe a specific PCI device in very 
> short form
> + * @vend: the vendor name (without PCI_VENDOR_ID_ prefix)
> + * @dev: the device name (without PCI_DEVICE_ID_ prefix)
> + * @data: the driver data to be filled
> + *
> + * This macro is used to create a struct pci_device_id that matches a
> + * specific PCI device.  The subvendor, and subdevice fields will be set
> + * to PCI_ANY_ID.
> + */
> +#define PCI_DEVICE_DATA(vend, dev, data) \
> + .vendor = PCI_VENDOR_ID_##vend, .device = PCI_DEVICE_ID_##dev, \
> + .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
> + .driver_data = (kernel_ulong_t)(data)
> +
>  enum {
>   PCI_REASSIGN_ALL_RSRC   = 0x0001,   /* Ignore firmware setup */
>   PCI_REASSIGN_ALL_BUS= 0x0002,   /* Reassign all bus numbers */
> 


-- 
~Randy


Re: [PATCH v1] PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry

2018-07-27 Thread Randy Dunlap
On 07/27/2018 01:41 PM, Andy Shevchenko wrote:
> On Fri, 2018-07-27 at 23:39 +0300, Andy Shevchenko wrote:
>> There are a lot of examples in the kernel where PCI_VDEVICE() is used
>> and still
>> looks not so convenient due to additional driver_data field attached.
>>
>> Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in
>> shortest
>> possible form. For example,
>>
>>   before:
>>
>> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD),
>>   (kernel_ulong_t) _pci_mrfld_properties, },
>>
>>   after:
>>
>> { PCI_VDEVICE(INTEL, INTEL_MRFLD, _pci_mrfld_properties },
>>
>> Drivers can be converted later on in independent way.
>>
>> While here, remove the unused macro with the same name
>> from Ralink wireless driver.
> 
> Skip this, it missed one comma.

s/comma/right paren/ ??

> Will send v2 soon.
> 
>>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  drivers/net/wireless/ralink/rt2x00/rt2x00pci.h |  6 --
>>  include/linux/pci.h| 15 +++
>>  2 files changed, 15 insertions(+), 6 deletions(-)

-- 
~Randy


[PATCH] mac80211: fix kernel-doc "bad line" warning

2018-04-26 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Fix 88 instances of a kernel-doc warning:
  ../include/net/mac80211.h:2083: warning: bad line:  >

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johan...@sipsolutions.net>
---
 include/net/mac80211.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180426.orig/include/net/mac80211.h
+++ linux-next-20180426/include/net/mac80211.h
@@ -2080,7 +2080,7 @@ struct ieee80211_txq {
  * virtual interface might not be given air time for the transmission of
  * the frame, as it is not synced with the AP/P2P GO yet, and thus the
  * deauthentication frame might not be transmitted.
- >
+ *
  * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
  * support QoS NDP for AP probing - that's most likely a driver bug.
  *




[PATCH] net/wireless: fix spaces and grammar copy/paste in vendor Kconfig help text

2018-03-02 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Lots of the wireless driver vendor Kconfig symol help text says
"questions about  cards." (2 spaces between "about" and "cards")

Besides dropping one of those spaces, it also needs some other word
inserted there. Instead of putting each vendor's name there, I chose
to say "these" cards in all of the Kconfig help text.

Cc: Kalle Valo <kv...@codeaurora.org>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 drivers/net/wireless/admtek/Kconfig|4 ++--
 drivers/net/wireless/ath/Kconfig   |4 ++--
 drivers/net/wireless/atmel/Kconfig |4 ++--
 drivers/net/wireless/broadcom/Kconfig  |4 ++--
 drivers/net/wireless/cisco/Kconfig |4 ++--
 drivers/net/wireless/intel/Kconfig |4 ++--
 drivers/net/wireless/intersil/Kconfig  |4 ++--
 drivers/net/wireless/marvell/Kconfig   |4 ++--
 drivers/net/wireless/mediatek/Kconfig  |4 ++--
 drivers/net/wireless/quantenna/Kconfig |4 ++--
 drivers/net/wireless/ralink/Kconfig|4 ++--
 drivers/net/wireless/realtek/Kconfig   |4 ++--
 drivers/net/wireless/rsi/Kconfig   |4 ++--
 drivers/net/wireless/st/Kconfig|4 ++--
 drivers/net/wireless/ti/Kconfig|4 ++--
 drivers/net/wireless/zydas/Kconfig |4 ++--
 16 files changed, 32 insertions(+), 32 deletions(-)

--- linux-next-20180302.orig/drivers/net/wireless/admtek/Kconfig
+++ linux-next-20180302/drivers/net/wireless/admtek/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_ADMTEK
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_ADMTEK
--- linux-next-20180302.orig/drivers/net/wireless/ath/Kconfig
+++ linux-next-20180302/drivers/net/wireless/ath/Kconfig
@@ -8,8 +8,8 @@ config WLAN_VENDOR_ATH
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
  For more information and documentation on this module you can visit:
--- linux-next-20180302.orig/drivers/net/wireless/atmel/Kconfig
+++ linux-next-20180302/drivers/net/wireless/atmel/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_ATMEL
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_ATMEL
--- linux-next-20180302.orig/drivers/net/wireless/broadcom/Kconfig
+++ linux-next-20180302/drivers/net/wireless/broadcom/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_BROADCOM
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_BROADCOM
--- linux-next-20180302.orig/drivers/net/wireless/cisco/Kconfig
+++ linux-next-20180302/drivers/net/wireless/cisco/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_CISCO
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_CISCO
--- linux-next-20180302.orig/drivers/net/wireless/intel/Kconfig
+++ linux-nex

Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-13 Thread Randy Dunlap
On 02/11/2018 11:27 PM, Ingo Molnar wrote:
> 
> * Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> Nice find:
> 
> Reviewed-by: Ingo Molnar <mi...@kernel.org>
> 
> I agree that it needs to go through 0-day to find any hidden dependencies we 
> might 
> have grown due to this.

Andrew,

This patch has mostly survived both 0day and ozlabs multi-arch testing with
2 build errors being reported by both of them.  I have posted patches for
those separately. (and are attached here)

other-patch-1:
lkml.kernel.org/r/5664ced1-a0cd-7e4e-71b6-9c3a97d68...@infradead.org
"lib/test_firmware: add header file to prevent build errors"

other-patch-2:
lkml.kernel.org/r/b3b7eebb-0e9f-f175-94a8-379c5ddca...@infradead.org
"integrity/security: fix digsig.c build error"

Will you see that these are merged or do you want me to repost them?

thanks,
-- 
~Randy
From: Randy Dunlap <rdun...@infradead.org>

security/integrity/digsig.c has build errors on some $ARCH due to a
missing header file, so add it.

  security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Mimi Zohar <zo...@linux.vnet.ibm.com>
Cc: linux-integr...@vger.kernel.org
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 security/integrity/digsig.c |    1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/security/integrity/digsig.c
+++ lnx-416-rc1/security/integrity/digsig.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 



From: Randy Dunlap <rdun...@infradead.org>

lib/test_firmware.c has build errors on some $ARCH due to a
missing header file, so add it.

  lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 lib/test_firmware.c |1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/lib/test_firmware.c
+++ lnx-416-rc1/lib/test_firmware.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TEST_FIRMWARE_NAME	"test-firmware.bin"
 #define TEST_FIRMWARE_NUM_REQS	4





Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-13 Thread Randy Dunlap
On 02/13/2018 02:09 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>>> Randy Dunlap <rdun...@infradead.org> writes:
>>>
>>>> From: Randy Dunlap <rdun...@infradead.org>
>>>>
>>>> Currently  #includes  for no obvious
>>>> reason. It looks like it's only a convenience, so remove kmemleak.h
>>>> from slab.h and add  to any users of kmemleak_*
>>>> that don't already #include it.
>>>> Also remove  from source files that do not use it.
>>>>
>>>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>>>> would be good to run it through the 0day bot for other $ARCHes.
>>>> I have neither the horsepower nor the storage space for the other
>>>> $ARCHes.
>>>>
>>>> [slab.h is the second most used header file after module.h; kernel.h
>>>> is right there with slab.h. There could be some minor error in the
>>>> counting due to some #includes having comments after them and I
>>>> didn't combine all of those.]
>>>>
>>>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>>>> header files).
>>>>
>>>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
>>>
>>> I threw it at a random selection of configs and so far the only failures
>>> I'm seeing are:
>>>
>>>   lib/test_firmware.c:134:2: error: implicit declaration of function 
>>> 'vfree' [-Werror=implicit-function-declaration] 
>>> 
>>>  
>>>   lib/test_firmware.c:620:25: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   lib/test_firmware.c:620:2: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   security/integrity/digsig.c:146:2: error: implicit declaration of 
>>> function 'vfree' [-Werror=implicit-function-declaration]
>>
>> Both of those source files need to #include .
> 
> Yep, I added those and rebuilt. I don't see any more failures that look
> related to your patch.

Great, thanks.

I also sent patches for both of those.

>   http://kisskb.ellerman.id.au/kisskb/head/13399/
> 
> 
> I haven't gone through the defconfigs I have enabled for a while, so
> it's possible I have some missing but it's still a reasonable cross
> section.


-- 
~Randy


Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Randy Dunlap
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/

That's very useful, thanks.

I'll send a few patches for those.

-- 
~Randy


Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Randy Dunlap
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 

Both of those source files need to #include .

> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/
> 
> cheers

:)

-- 
~Randy


[PATCH] headers: untangle kmemleak.h from mm.h

2018-02-11 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Currently  #includes  for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.h
from slab.h and add  to any users of kmemleak_*
that don't already #include it.
Also remove  from source files that do not use it.

This is tested on i386 allmodconfig and x86_64 allmodconfig. It
would be good to run it through the 0day bot for other $ARCHes.
I have neither the horsepower nor the storage space for the other
$ARCHes.

[slab.h is the second most used header file after module.h; kernel.h
is right there with slab.h. There could be some minor error in the
counting due to some #includes having comments after them and I
didn't combine all of those.]

This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
header files).

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---

Fengguang, can you have this patch run thru 0day builds, please?

 arch/powerpc/sysdev/dart_iommu.c  |1 +
 arch/powerpc/sysdev/msi_bitmap.c  |1 +
 arch/s390/kernel/nmi.c|2 +-
 arch/s390/kernel/smp.c|1 -
 arch/sparc/kernel/irq_64.c|1 -
 arch/x86/kernel/pci-dma.c |1 -
 drivers/iommu/exynos-iommu.c  |1 +
 drivers/iommu/mtk_iommu_v1.c  |1 -
 drivers/net/ethernet/ti/cpsw.c|1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c|1 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c |1 -
 drivers/staging/rtl8188eu/hal/fw.c|2 +-
 drivers/staging/rtlwifi/pci.c |1 -
 drivers/virtio/virtio_ring.c  |1 -
 include/linux/slab.h  |1 -
 kernel/ucount.c   |1 +
 mm/cma.c  |1 +
 mm/memblock.c |1 +
 net/core/sysctl_net_core.c|1 -
 net/ipv4/route.c  |1 -
 security/apparmor/lsm.c   |1 -
 21 files changed, 9 insertions(+), 14 deletions(-)

--- lnx-416-rc1.orig/include/linux/slab.h
+++ lnx-416-rc1/include/linux/slab.h
@@ -125,7 +125,6 @@
 #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
 
-#include 
 #include 
 
 struct mem_cgroup;
--- lnx-416-rc1.orig/kernel/ucount.c
+++ lnx-416-rc1/kernel/ucount.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define UCOUNTS_HASHTABLE_BITS 10
--- lnx-416-rc1.orig/mm/memblock.c
+++ lnx-416-rc1/mm/memblock.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/mm/cma.c
+++ lnx-416-rc1/mm/cma.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cma.h"
--- lnx-416-rc1.orig/drivers/staging/rtl8188eu/hal/fw.c
+++ lnx-416-rc1/drivers/staging/rtl8188eu/hal/fw.c
@@ -30,7 +30,7 @@
 #include "rtl8188e_hal.h"
 
 #include 
-#include 
+#include 
 
 static void _rtl88e_enable_fw_download(struct adapter *adapt, bool enable)
 {
--- lnx-416-rc1.orig/drivers/iommu/exynos-iommu.c
+++ lnx-416-rc1/drivers/iommu/exynos-iommu.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/s390/kernel/nmi.c
+++ lnx-416-rc1/arch/s390/kernel/nmi.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/dart_iommu.c
+++ lnx-416-rc1/arch/powerpc/sysdev/dart_iommu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/msi_bitmap.c
+++ lnx-416-rc1/arch/powerpc/sysdev/msi_bitmap.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/net/ethernet/ti/cpsw.c
+++ lnx-416-rc1/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
--- lnx-416-rc1.orig/drivers/virtio/virtio_ring.c
+++ lnx-416-rc1/drivers/virtio/virtio_ring.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/security/apparmor/lsm.c
+++ lnx-416-rc1/security/apparmor/lsm.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "include/apparmor.h"
--- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c
+++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/

Re: [PATCH] cfg80211: stop demanding lots of new stuff

2018-01-18 Thread Randy Dunlap
On 01/18/2018 01:07 PM, Hugh Dickins wrote:
> On Thu, 18 Jan 2018, Johannes Berg wrote:
>> On Wed, 2018-01-17 at 14:55 -0800, Hugh Dickins wrote:
>>> "make oldconfig" from 4.14 (when CONFIG_CFG80211_CERTIFICATION_ONUS
>>> is not set) to 4.15-rc, gets into asking lots of new questions, and
>>> configuring in unwanted stuff: I'm unsure of my Kconfig skills, but
>>> it looks like CFG80211_REQUIRE_SIGNED_REGDB's "default y" needs to
>>> be toned down when we don't even have CFG80211_CERTIFICATION_ONUS.
>>
>> No, this is wrong - we want default configurations to be able to load a
>> signed regulatory database and validate the signature.
> 
> Great to enable that, but not so great to force new stuff on everyone.
> It doesn't surprise me at all if the patch here is the wrong one,
> but something needs to be done differently in this configuration.
> 
> Perhaps you did not try on a system without SYSTEM_DATA_VERIFICATION
> already enabled - that "select SYSTEM_DATA_VERIFICATION" seems to be
> taking effect even when CFG80211_REQUIRE_SIGNED_REGDB is not enabled,
> and pulls in a boatload.  I agree that seems strange: perhaps the
> Kconfig problem is somewhere else entirely.
> 
> Attached my old 4.14 config, so you can see for yourself - thanks.

NOT attached.


> In fact, I cannot even build the resulting config, without scurrying
> around to update userspace with stuff I never needed before:
> 
>   HOSTCC  scripts/extract-cert
> scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or 
> directory
> 
> Hugh
> 
>>
>> johannes
>>
>>>
>>> Signed-off-by: Hugh Dickins 
>>> ---
>>>
>>>  net/wireless/Kconfig |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> --- 4.15-rc8/net/wireless/Kconfig   2017-12-03 10:22:51.928845056 -0800
>>> +++ linux/net/wireless/Kconfig  2018-01-14 19:20:22.595472965 -0800
>>> @@ -89,7 +89,7 @@ config CFG80211_CERTIFICATION_ONUS
>>>  
>>>  config CFG80211_REQUIRE_SIGNED_REGDB
>>> bool "require regdb signature" if CFG80211_CERTIFICATION_ONUS
>>> -   default y
>>> +   default CFG80211_CERTIFICATION_ONUS
>>> select SYSTEM_DATA_VERIFICATION
>>> help
>>>   Require that in addition to the "regulatory.db" file a


-- 
~Randy


Re: mmotm 2017-12-12-16-32 uploaded (net/wireless certs)

2017-12-12 Thread Randy Dunlap
On 12/12/2017 04:32 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2017-12-12-16-32 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series

on i386:

  GEN net/wireless/shipped-certs.c
  CC  net/wireless/extra-certs.o
../net/wireless/Makefile:27: recipe for target 'net/wireless/shipped-certs.c' 
failed
make[3]: *** [net/wireless/shipped-certs.c] Error 1
make[3]: *** Waiting for unfinished jobs
../scripts/Makefile.build:569: recipe for target 'net/wireless' failed
make[2]: *** [net/wireless] Error 2



CFG80211 is set but MAC80211 is not.

Full randconfig file is attached.
-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.15.0-rc3-mm1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
CONFIG_TASKS_RCU=y
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_RCU_NEED_SEGCBLIST is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_RDMA=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
CONFIG_CGROUP_DEBUG=y
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y

Re: [PATCH] bcma: keep *config menu together

2017-10-07 Thread Randy Dunlap
On 09/27/17 13:01, Randy Dunlap wrote:
> From: Randy Dunlap <rdun...@infradead.org>
> 
> Use "if BCMA"/"endif" around all Kconfig symbols so that they are
> kept together in *config menus instead of showing up in unexpected
> places. Also remove "depends on BCMA" since this is handled by the
> "if BCMA" addition.
> 
> Tested with ARCH={x86_64,MIPS} using make {n,menu,g,x}config.
> 
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> Cc: Rafał Miłecki <zaj...@gmail.com>

Rafał -- ping?

> ---
>  drivers/bcma/Kconfig |   18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> --- lnx-414-rc2.orig/drivers/bcma/Kconfig
> +++ lnx-414-rc2/drivers/bcma/Kconfig
> @@ -10,14 +10,15 @@ menuconfig BCMA
> Bus driver for Broadcom specific Advanced Microcontroller Bus
> Architecture.
>  
> +if BCMA
> +
>  # Support for Block-I/O. SELECT this from the driver that needs it.
>  config BCMA_BLOCKIO
>   bool
> - depends on BCMA
>  
>  config BCMA_HOST_PCI_POSSIBLE
>   bool
> - depends on BCMA && PCI = y
> + depends on PCI = y
>   default y
>  
>  config BCMA_HOST_PCI
> @@ -28,7 +29,6 @@ config BCMA_HOST_PCI
>  
>  config BCMA_HOST_SOC
>   bool "Support for BCMA in a SoC"
> - depends on BCMA
>   help
> Host interface for a Broadcom AIX bus directly mapped into
> the memory. This only works with the Broadcom SoCs from the
> @@ -38,7 +38,7 @@ config BCMA_HOST_SOC
>  
>  config BCMA_DRIVER_PCI
>   bool "BCMA Broadcom PCI core driver"
> - depends on BCMA && PCI
> + depends on PCI
>   default y
>   help
> BCMA bus may have many versions of PCIe core. This driver
> @@ -54,13 +54,13 @@ config BCMA_DRIVER_PCI
>  
>  config BCMA_DRIVER_PCI_HOSTMODE
>   bool "Driver for PCI core working in hostmode"
> - depends on BCMA && MIPS && BCMA_DRIVER_PCI
> + depends on MIPS && BCMA_DRIVER_PCI
>   help
> PCI core hostmode operation (external PCI bus).
>  
>  config BCMA_DRIVER_MIPS
>   bool "BCMA Broadcom MIPS core driver"
> - depends on BCMA && MIPS
> + depends on MIPS
>   help
> Driver for the Broadcom MIPS core attached to Broadcom specific
> Advanced Microcontroller Bus.
> @@ -91,7 +91,6 @@ config BCMA_NFLASH
>  
>  config BCMA_DRIVER_GMAC_CMN
>   bool "BCMA Broadcom GBIT MAC COMMON core driver"
> - depends on BCMA
>   help
> Driver for the Broadcom GBIT MAC COMMON core attached to Broadcom
> specific Advanced Microcontroller Bus.
> @@ -100,7 +99,7 @@ config BCMA_DRIVER_GMAC_CMN
>  
>  config BCMA_DRIVER_GPIO
>   bool "BCMA GPIO driver"
> - depends on BCMA && GPIOLIB
> + depends on GPIOLIB
>   select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
>   help
> Driver to provide access to the GPIO pins of the bcma bus.
> @@ -109,8 +108,9 @@ config BCMA_DRIVER_GPIO
>  
>  config BCMA_DEBUG
>   bool "BCMA debugging"
> - depends on BCMA
>   help
> This turns on additional debugging messages.
>  
> If unsure, say N
> +
> +endif # BCMA
> 
> 
> 


-- 
~Randy


[PATCH] bcma: keep *config menu together

2017-09-27 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Use "if BCMA"/"endif" around all Kconfig symbols so that they are
kept together in *config menus instead of showing up in unexpected
places. Also remove "depends on BCMA" since this is handled by the
"if BCMA" addition.

Tested with ARCH={x86_64,MIPS} using make {n,menu,g,x}config.

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Rafał Miłecki <zaj...@gmail.com>
---
 drivers/bcma/Kconfig |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- lnx-414-rc2.orig/drivers/bcma/Kconfig
+++ lnx-414-rc2/drivers/bcma/Kconfig
@@ -10,14 +10,15 @@ menuconfig BCMA
  Bus driver for Broadcom specific Advanced Microcontroller Bus
  Architecture.
 
+if BCMA
+
 # Support for Block-I/O. SELECT this from the driver that needs it.
 config BCMA_BLOCKIO
bool
-   depends on BCMA
 
 config BCMA_HOST_PCI_POSSIBLE
bool
-   depends on BCMA && PCI = y
+   depends on PCI = y
default y
 
 config BCMA_HOST_PCI
@@ -28,7 +29,6 @@ config BCMA_HOST_PCI
 
 config BCMA_HOST_SOC
bool "Support for BCMA in a SoC"
-   depends on BCMA
help
  Host interface for a Broadcom AIX bus directly mapped into
  the memory. This only works with the Broadcom SoCs from the
@@ -38,7 +38,7 @@ config BCMA_HOST_SOC
 
 config BCMA_DRIVER_PCI
bool "BCMA Broadcom PCI core driver"
-   depends on BCMA && PCI
+   depends on PCI
default y
help
  BCMA bus may have many versions of PCIe core. This driver
@@ -54,13 +54,13 @@ config BCMA_DRIVER_PCI
 
 config BCMA_DRIVER_PCI_HOSTMODE
bool "Driver for PCI core working in hostmode"
-   depends on BCMA && MIPS && BCMA_DRIVER_PCI
+   depends on MIPS && BCMA_DRIVER_PCI
help
  PCI core hostmode operation (external PCI bus).
 
 config BCMA_DRIVER_MIPS
bool "BCMA Broadcom MIPS core driver"
-   depends on BCMA && MIPS
+   depends on MIPS
help
  Driver for the Broadcom MIPS core attached to Broadcom specific
  Advanced Microcontroller Bus.
@@ -91,7 +91,6 @@ config BCMA_NFLASH
 
 config BCMA_DRIVER_GMAC_CMN
bool "BCMA Broadcom GBIT MAC COMMON core driver"
-   depends on BCMA
help
  Driver for the Broadcom GBIT MAC COMMON core attached to Broadcom
  specific Advanced Microcontroller Bus.
@@ -100,7 +99,7 @@ config BCMA_DRIVER_GMAC_CMN
 
 config BCMA_DRIVER_GPIO
bool "BCMA GPIO driver"
-   depends on BCMA && GPIOLIB
+   depends on GPIOLIB
select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
help
  Driver to provide access to the GPIO pins of the bcma bus.
@@ -109,8 +108,9 @@ config BCMA_DRIVER_GPIO
 
 config BCMA_DEBUG
bool "BCMA debugging"
-   depends on BCMA
help
  This turns on additional debugging messages.
 
  If unsure, say N
+
+endif # BCMA




Re: [PATCH 2/4] staging: wilc1000: Fix typo in host_interface.c

2015-11-23 Thread Randy Dunlap
On 11/23/15 05:41, Masanari Iida wrote:
> This patch fix spelling typo in host_interface.c
> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/staging/wilc1000/host_interface.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index d5b7725..b9f9541 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -844,7 +844,7 @@ static s32 Handle_Scan(struct host_if_drv *hif_drv,
>   }
>  
>   if (g_obtainingIP || connecting) {
> - PRINT_D(GENERIC_DBG, "[handle_scan]: Don't do obss scan until 
> IP adresss is obtained\n");
> + PRINT_D(GENERIC_DBG, "[handle_scan]: Don't do obss scan until 
> IP addresses is obtained\n");


 address

>   PRINT_ER("Don't do obss scan\n");
>   result = -EBUSY;
>   goto ERRORHANDLER;

> @@ -2518,7 +2518,7 @@ static int Handle_RemainOnChan(struct host_if_drv 
> *hif_drv,
>   }
>  
>   if (g_obtainingIP || connecting) {
> - PRINT_D(GENERIC_DBG, "[handle_scan]: Don't do obss scan until 
> IP adresss is obtained\n");
> + PRINT_D(GENERIC_DBG, "[handle_scan]: Don't do obss scan until 
> IP addresses is obtained\n");


 address

>   result = -EBUSY;
>   goto ERRORHANDLER;
>   }


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] staging: wilc1000: Fix typo in wilc_wfi_cfgoperations.c

2015-11-23 Thread Randy Dunlap
On 11/23/15 05:41, Masanari Iida wrote:
> This patch fix some spelling typo in wilc_wfi_cfgoperations.c
> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 34 
> +++
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 6f40522..ee09d56 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -1923,7 +1923,7 @@ void WILC_WFI_p2p_rx (struct net_device *dev, u8 *buff, 
> u32 size)
>   /* Get WILC header */
>   memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
>  
> - /* The packet offset field conain info about what type of managment 
> frame */
> + /* The packet offset field contain info about what type of management 
> frame */

   contains

>   /* we are dealing with and ack status */
>   pkt_offset = GET_PKT_OFFSET(header);
>  
> @@ -2283,7 +2283,7 @@ static int mgmt_tx(struct wiphy *wiphy,
>   if (u8P2Plocalrandom > 
> u8P2Precvrandom) {
>   
> PRINT_D(GENERIC_DBG, "LOCAL WILL BE GO LocaRand=%02x RecvRand %02x\n", 
> u8P2Plocalrandom, u8P2Precvrandom);
>  
> - /*Search for 
> the p2p information information element , after the Public action subtype 
> theres a byte for teh dialog token, skip that*/
> + /*Search for 
> the p2p information information element , after the Public action subtype 
> theres a byte for the dialog token, skip that*/

Please change "theres" to "there's" or "there is".

>   for (i = 
> P2P_PUB_ACTION_SUBTYPE + 2; i < len; i++) {
>   if 
> (buf[i] == P2PELEM_ATTR_ID && !(memcmp(u8P2P_oui, [i + 2], 4))) {
>   
> if (buf[P2P_PUB_ACTION_SUBTYPE] == P2P_INV_REQ || buf[P2P_PUB_ACTION_SUBTYPE] 
> == P2P_INV_RSP)


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] staging: wilc1000: Fix typo in wilc_msgqueue.h

2015-11-23 Thread Randy Dunlap
On 11/23/15 05:41, Masanari Iida wrote:
> This patch fix some spelling typo in wilc_msgqueue.h
> 
> Signed-off-by: Masanari Iida <standby2...@gmail.com>

Acked-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  drivers/staging/wilc1000/wilc_msgqueue.h | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_msgqueue.h 
> b/drivers/staging/wilc1000/wilc_msgqueue.h
> index d231c33..d7e0328 100644
> --- a/drivers/staging/wilc1000/wilc_msgqueue.h
> +++ b/drivers/staging/wilc1000/wilc_msgqueue.h


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: linux-4.2-rc1/drivers/staging/wilc1000/linux_wlan.c:1874: bad test ?

2015-07-07 Thread Randy Dunlap
On 07/07/15 04:19, David Binderman wrote:
 Hello there,
 
 [linux-4.2-rc1/drivers/staging/wilc1000/linux_wlan.c:1874]: (style) A pointer 
 can not be negative so it is either pointless or an error to check if it is.
 
 Source code is
 
  if (wilc_mac_thread  0) {
 
 but
 
 struct task_struct *wilc_mac_thread;


#include linux/err.h


if (IS_ERR(wilc_mac_thread)) {


-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mac80211: fix kernel-doc comments in mac80211.h

2015-05-31 Thread Randy Dunlap
On 05/28/15 05:36, Johannes Berg wrote:
 On Thu, 2015-05-28 at 13:34 +0100, Ben Hutchings wrote:
 
 It's a build failure so it should go upstream now.
 
 Ok, I was under the impression it's a warning.
 
 I guess I'll just have to send a copy of the commit to 4.1 then - git
 will sort out getting it twice I suppose.
 
 johannes
 
 --

Still getting this build failure.  Please get the fix merged soon.


-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] mac80211: fix 90 kernel-doc warnings

2015-04-26 Thread Randy Dunlap
From: Randy Dunlap rdun...@infradead.org

Eliminate 90 of these warnings:

Warning(..//include/net/mac80211.h:1682): No description found for parameter 
'drv_priv[0]'

Signed-off-by: Randy Dunlap rdun...@infradead.org
---
 include/net/mac80211.h |2 ++
 1 file changed, 2 insertions(+)

--- lnx-41-rc1.orig/include/net/mac80211.h
+++ lnx-41-rc1/include/net/mac80211.h
@@ -1667,6 +1667,8 @@ struct ieee80211_tx_control {
  * @sta: station table entry, %NULL for per-vif queue
  * @tid: the TID for this queue (unused for per-vif queue)
  * @ac: the AC for this queue
+ * @drv_priv: data area for driver use, will always be aligned to
+ * sizeof(void *).
  *
  * The driver can obtain packets from this queue by calling
  * ieee80211_tx_dequeue().
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: linux-next: Tree for Mar 5 (iwlwifi/mvm)

2015-03-05 Thread Randy Dunlap
On 03/04/15 19:34, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20150304:
 

on i386, when IWLWIFI_DEBUGFS is not enabled:


../drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c:179:38: error: 'struct iwl_mvm' 
has no member named 'dbgfs_rx_phyinfo'
../drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c:1378:30: error: 'struct 
iwl_mvm_vif' has no member named 'mvm'


-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html