Re: [PATCH 1/3] kretprobes: ensure probe location is at function entry

[Naveen N. Rao]

On 2017/02/16 08:39AM, Masami Hiramatsu wrote:
> On Wed, 15 Feb 2017 23:47:52 +0530
> "Naveen N. Rao"  wrote:
> 
> > kretprobes can be registered by specifying an absolute address or by
> > specifying offset to a symbol. However, we need to ensure this falls at
> > function entry so as to be able to determine the return address.
> > 
> > Validate the same during kretprobe registration. By default, there
> > should not be any offset from a function entry, as determined through a
> > kallsyms_lookup(). Introduce arch_function_offset_within_entry() as a
> > way for architectures to override this.
> > 
> 
> Looks good to me.
> 
> Acked-by: Masami Hiramatsu 

Thanks, Masami! I am cc'ing linux-arch in case any other architectures 
need to override the arch-specific helper with a custom offset.

- Naveen

> 
> Thanks!
> 
> > Signed-off-by: Naveen N. Rao 
> > ---
> > powerpc64 ABIv2 will need to use the over-ride as we want to use the
> > local entry point which will be at an offset of 8 bytes from the
> > (global) entry point. I have a patch that I will post separately.
> > 
> > Thanks,
> > Naveen
> > 
> >  include/linux/kprobes.h |  1 +
> >  kernel/kprobes.c| 13 +
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> > index 8f6849084248..0c2489435117 100644
> > --- a/include/linux/kprobes.h
> > +++ b/include/linux/kprobes.h
> > @@ -266,6 +266,7 @@ extern int arch_init_kprobes(void);
> >  extern void show_registers(struct pt_regs *regs);
> >  extern void kprobes_inc_nmissed_count(struct kprobe *p);
> >  extern bool arch_within_kprobe_blacklist(unsigned long addr);
> > +extern bool arch_function_offset_within_entry(unsigned long offset);
> >  
> >  extern bool within_kprobe_blacklist(unsigned long addr);
> >  
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 43460104f119..72ecbf5a6312 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1834,12 +1834,25 @@ static int pre_handler_kretprobe(struct kprobe *p, 
> > struct pt_regs *regs)
> >  }
> >  NOKPROBE_SYMBOL(pre_handler_kretprobe);
> >  
> > +bool __weak arch_function_offset_within_entry(unsigned long offset)
> > +{
> > +   return !offset;
> > +}
> > +
> >  int register_kretprobe(struct kretprobe *rp)
> >  {
> > int ret = 0;
> > struct kretprobe_instance *inst;
> > int i;
> > void *addr;
> > +   unsigned long offset;
> > +
> > +   addr = kprobe_addr(>kp);
> > +   if (!kallsyms_lookup_size_offset((unsigned long)addr, NULL, ))
> > +   return -EINVAL;
> > +
> > +   if (!arch_function_offset_within_entry(offset))
> > +   return -EINVAL;
> >  
> > if (kretprobe_blacklist_size) {
> > addr = kprobe_addr(>kp);
> > -- 
> > 2.11.0
> > 
> 
> 
> -- 
> Masami Hiramatsu 
> 

Re: [PATCH 1/3] kretprobes: ensure probe location is at function entry

[Naveen N. Rao]

On 2017/02/16 08:39AM, Masami Hiramatsu wrote:
> On Wed, 15 Feb 2017 23:47:52 +0530
> "Naveen N. Rao"  wrote:
> 
> > kretprobes can be registered by specifying an absolute address or by
> > specifying offset to a symbol. However, we need to ensure this falls at
> > function entry so as to be able to determine the return address.
> > 
> > Validate the same during kretprobe registration. By default, there
> > should not be any offset from a function entry, as determined through a
> > kallsyms_lookup(). Introduce arch_function_offset_within_entry() as a
> > way for architectures to override this.
> > 
> 
> Looks good to me.
> 
> Acked-by: Masami Hiramatsu 

Thanks, Masami! I am cc'ing linux-arch in case any other architectures 
need to override the arch-specific helper with a custom offset.

- Naveen

> 
> Thanks!
> 
> > Signed-off-by: Naveen N. Rao 
> > ---
> > powerpc64 ABIv2 will need to use the over-ride as we want to use the
> > local entry point which will be at an offset of 8 bytes from the
> > (global) entry point. I have a patch that I will post separately.
> > 
> > Thanks,
> > Naveen
> > 
> >  include/linux/kprobes.h |  1 +
> >  kernel/kprobes.c| 13 +
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> > index 8f6849084248..0c2489435117 100644
> > --- a/include/linux/kprobes.h
> > +++ b/include/linux/kprobes.h
> > @@ -266,6 +266,7 @@ extern int arch_init_kprobes(void);
> >  extern void show_registers(struct pt_regs *regs);
> >  extern void kprobes_inc_nmissed_count(struct kprobe *p);
> >  extern bool arch_within_kprobe_blacklist(unsigned long addr);
> > +extern bool arch_function_offset_within_entry(unsigned long offset);
> >  
> >  extern bool within_kprobe_blacklist(unsigned long addr);
> >  
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 43460104f119..72ecbf5a6312 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1834,12 +1834,25 @@ static int pre_handler_kretprobe(struct kprobe *p, 
> > struct pt_regs *regs)
> >  }
> >  NOKPROBE_SYMBOL(pre_handler_kretprobe);
> >  
> > +bool __weak arch_function_offset_within_entry(unsigned long offset)
> > +{
> > +   return !offset;
> > +}
> > +
> >  int register_kretprobe(struct kretprobe *rp)
> >  {
> > int ret = 0;
> > struct kretprobe_instance *inst;
> > int i;
> > void *addr;
> > +   unsigned long offset;
> > +
> > +   addr = kprobe_addr(>kp);
> > +   if (!kallsyms_lookup_size_offset((unsigned long)addr, NULL, ))
> > +   return -EINVAL;
> > +
> > +   if (!arch_function_offset_within_entry(offset))
> > +   return -EINVAL;
> >  
> > if (kretprobe_blacklist_size) {
> > addr = kprobe_addr(>kp);
> > -- 
> > 2.11.0
> > 
> 
> 
> -- 
> Masami Hiramatsu 
> 

Re: [PATCH 3.16 149/306] batman-adv: fix splat on disabling an interface

[Sven Eckelmann]

On Mittwoch, 15. Februar 2017 22:41:40 CET Ben Hutchings wrote:
> 3.16.40-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Linus Lüssing 
> 
> commit 9799c50372b23ed774791bdb87d700f1286ee8a9 upstream.

Same objections as Linus had for the 3.2 patch:

> Hi Ben,
> 
> This commit was reverted in
> 27915aa61060fd8954a68a86657784705955088a
> ('batman-adv: Revert "fix splat on disabling an interface"').
> 
> Greg dropped this patch from his stable queue back then, too [0].
> 
> Regards, Linus
> 
> [0]: https://marc.info/?l=linux-kernel=147938417410032

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 3.16 149/306] batman-adv: fix splat on disabling an interface

[Sven Eckelmann]

On Mittwoch, 15. Februar 2017 22:41:40 CET Ben Hutchings wrote:
> 3.16.40-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Linus Lüssing 
> 
> commit 9799c50372b23ed774791bdb87d700f1286ee8a9 upstream.

Same objections as Linus had for the 3.2 patch:

> Hi Ben,
> 
> This commit was reverted in
> 27915aa61060fd8954a68a86657784705955088a
> ('batman-adv: Revert "fix splat on disabling an interface"').
> 
> Greg dropped this patch from his stable queue back then, too [0].
> 
> Regards, Linus
> 
> [0]: https://marc.info/?l=linux-kernel=147938417410032

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] brcmfmac: don't warn user if loading firmware file with NVRAM fails

[Rafał Miłecki]

On 2017-02-16 02:19, Andy Shevchenko wrote:
On Thu, Feb 16, 2017 at 12:29 AM, Rafał Miłecki  
wrote:

From: Rafał Miłecki 

This isn't critical as we use platform NVRAM as fallback and it's very
common case of all Broadcom home routers. Thanks for the new firmware
loading function we can achieve this by simply passing FW_OPT_NO_WARN.



What kind of warning you are talking about?

On Intel Edison brcmfmac isn't backed up by NVRAM (there no such) and
the platform is not ACPI-based. The warning might be crucial for
debugging Wi-Fi issues on such platforms.


Sorry, I should have tried better with that commit message. V2 in a 
second.

Re: [PATCH 2/2] brcmfmac: don't warn user if loading firmware file with NVRAM fails

[Rafał Miłecki]

On 2017-02-16 02:19, Andy Shevchenko wrote:
On Thu, Feb 16, 2017 at 12:29 AM, Rafał Miłecki  
wrote:

From: Rafał Miłecki 

This isn't critical as we use platform NVRAM as fallback and it's very
common case of all Broadcom home routers. Thanks for the new firmware
loading function we can achieve this by simply passing FW_OPT_NO_WARN.



What kind of warning you are talking about?

On Intel Edison brcmfmac isn't backed up by NVRAM (there no such) and
the platform is not ACPI-based. The warning might be crucial for
debugging Wi-Fi issues on such platforms.


Sorry, I should have tried better with that commit message. V2 in a 
second.

Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

[Laurent Pinchart]

Hi Rob,

On Wednesday 15 Feb 2017 16:08:22 Rob Herring wrote:
> On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
> > This makes the example more or less correspond with the da850-evm
> > hardware setup.
> > 
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> > 
> >  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 +
> >  1 file changed, 29 insertions(+), 6 deletions(-)
> 
> Spoke too soon...
> 
> > diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt index
> > 9c7510b..543f6f3 100644
> > --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > @@ -28,19 +28,27 @@ I2C-connected TVP5147 decoder:
> > reg = <0x217000 0x1000>;
> > interrupts = <92>;
> > 
> > -   port {
> > -   vpif_ch0: endpoint@0 {
> > +   port@0 {
> > +   vpif_input_ch0: endpoint@0 {
> > reg = <0>;
> > bus-width = <8>;
> > -   remote-endpoint = <>;
> > +   remote-endpoint = <_in>;
> > };
> > 
> > -   vpif_ch1: endpoint@1 {
> > +   vpif_input_ch1: endpoint@1 {
> > reg = <1>;
> > bus-width = <8>;
> > data-shift = <8>;
> > };
> > };
> > +
> > +   port@1 {
> 
> The binding doc says nothing about supporting a 2nd port.
> 
> > +   vpif_output_ch0: endpoint@0 {
> > +   reg = <0>;
> 
> Don't need reg here.

And the node should then be named endpoint, not endpoint@0.

> > +   bus-width = <8>;
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

[Laurent Pinchart]

Hi Rob,

On Wednesday 15 Feb 2017 16:08:22 Rob Herring wrote:
> On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
> > This makes the example more or less correspond with the da850-evm
> > hardware setup.
> > 
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> > 
> >  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 +
> >  1 file changed, 29 insertions(+), 6 deletions(-)
> 
> Spoke too soon...
> 
> > diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt index
> > 9c7510b..543f6f3 100644
> > --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > @@ -28,19 +28,27 @@ I2C-connected TVP5147 decoder:
> > reg = <0x217000 0x1000>;
> > interrupts = <92>;
> > 
> > -   port {
> > -   vpif_ch0: endpoint@0 {
> > +   port@0 {
> > +   vpif_input_ch0: endpoint@0 {
> > reg = <0>;
> > bus-width = <8>;
> > -   remote-endpoint = <>;
> > +   remote-endpoint = <_in>;
> > };
> > 
> > -   vpif_ch1: endpoint@1 {
> > +   vpif_input_ch1: endpoint@1 {
> > reg = <1>;
> > bus-width = <8>;
> > data-shift = <8>;
> > };
> > };
> > +
> > +   port@1 {
> 
> The binding doc says nothing about supporting a 2nd port.
> 
> > +   vpif_output_ch0: endpoint@0 {
> > +   reg = <0>;
> 
> Don't need reg here.

And the node should then be named endpoint, not endpoint@0.

> > +   bus-width = <8>;
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Jan Kiszka]

On 2017-02-16 04:00, Kweh, Hock Leong wrote:
>> -Original Message-
>> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>> Sent: Thursday, February 16, 2017 3:00 AM
>> To: Andy Shevchenko 
>> Cc: Matt Fleming ; Ard Biesheuvel
>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List ; Borislav Petkov ; Kweh,
>> Hock Leong ; Bryan O'Donoghue
>> 
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>> On 2017-02-15 19:50, Jan Kiszka wrote:
>>> On 2017-02-15 19:46, Andy Shevchenko wrote:
 On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka 
>> wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions,
> with a firmware.cap without security header and the SIMATIC IOT2040
> which requires the header because of its mandatory secure boot.

 Briefly looking to the code it looks like a real hack.
 Sorry, but it would be carefully (re-)designed.
>>>
>>> The interface that the firmware provides us? That should have been
>>> done differently, I agree, but I'm not too much into those firmware
>>> details, specifically when it comes to signatures.
>>>
>>> The Linux code was designed around that suboptimal situation. If there
>>> are better ideas, I'm all ears.
>>>
>>
>> Expanding CC's as requested by Andy.
>>
>> Jan
>>
> 
> Hi Jan,
> 
> While I upstreaming the capsule loader patches, I did work with maintainer
> Matt and look into this security header created for Quark. Eventually both
> of us agreed that this will not be upstream to mainline as it is really a 
> Quark
> specific implementation.

This is ... [swallowing down a lengthy rant about Quark upstreaming]
unfortunate given that Intel hands out firmware and BSPs to their
customers without further explanations on this "minor detail".

I have no idea what other integrators of the X102x did with that, but my
customer has now thousands and thousands of devices in the field with
firmware that works exactly this way. Only for that feature, we will now
have to provide a non-upstream kernel in order to keep the installed
devices updatable. Or create and maintain a different mechanism. Beautiful.

> 
> The proper implementation may require to work with UEFI community
> to expand its capsule spec to support signed binary. 
> 

Are you working on this? How is this solved on other platforms that
require signatures? No one tried that yet? In any case, this sounds like
a lengthy, way too late considered process that will not solve our issue
in the foreseeable future.

Don't get me wrong, I'm not intending to push this into the kernel
because "What the heck?!" was my first reaction as well once I found out
how this update interface is actually working. But maybe you can bring
this topic up on your side as well so that we come to an upstreamable
solution in all affected projects.

Thanks,
Jan

PS: @Daniel, another example for your presentation. ;)

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Jan Kiszka]

On 2017-02-16 04:00, Kweh, Hock Leong wrote:
>> -Original Message-
>> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>> Sent: Thursday, February 16, 2017 3:00 AM
>> To: Andy Shevchenko 
>> Cc: Matt Fleming ; Ard Biesheuvel
>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List ; Borislav Petkov ; Kweh,
>> Hock Leong ; Bryan O'Donoghue
>> 
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>> On 2017-02-15 19:50, Jan Kiszka wrote:
>>> On 2017-02-15 19:46, Andy Shevchenko wrote:
 On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka 
>> wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions,
> with a firmware.cap without security header and the SIMATIC IOT2040
> which requires the header because of its mandatory secure boot.

 Briefly looking to the code it looks like a real hack.
 Sorry, but it would be carefully (re-)designed.
>>>
>>> The interface that the firmware provides us? That should have been
>>> done differently, I agree, but I'm not too much into those firmware
>>> details, specifically when it comes to signatures.
>>>
>>> The Linux code was designed around that suboptimal situation. If there
>>> are better ideas, I'm all ears.
>>>
>>
>> Expanding CC's as requested by Andy.
>>
>> Jan
>>
> 
> Hi Jan,
> 
> While I upstreaming the capsule loader patches, I did work with maintainer
> Matt and look into this security header created for Quark. Eventually both
> of us agreed that this will not be upstream to mainline as it is really a 
> Quark
> specific implementation.

This is ... [swallowing down a lengthy rant about Quark upstreaming]
unfortunate given that Intel hands out firmware and BSPs to their
customers without further explanations on this "minor detail".

I have no idea what other integrators of the X102x did with that, but my
customer has now thousands and thousands of devices in the field with
firmware that works exactly this way. Only for that feature, we will now
have to provide a non-upstream kernel in order to keep the installed
devices updatable. Or create and maintain a different mechanism. Beautiful.

> 
> The proper implementation may require to work with UEFI community
> to expand its capsule spec to support signed binary. 
> 

Are you working on this? How is this solved on other platforms that
require signatures? No one tried that yet? In any case, this sounds like
a lengthy, way too late considered process that will not solve our issue
in the foreseeable future.

Don't get me wrong, I'm not intending to push this into the kernel
because "What the heck?!" was my first reaction as well once I found out
how this update interface is actually working. But maybe you can bring
this topic up on your side as well so that we come to an upstreamable
solution in all affected projects.

Thanks,
Jan

PS: @Daniel, another example for your presentation. ;)

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH V2 1/2] firmware: add more flexible request_firmware_async function

[Rafał Miłecki]

From: Rafał Miłecki 

So far we got only one function for loading firmware asynchronously:
request_firmware_nowait. It didn't allow much customization of firmware
loading process - there is only one bool uevent argument. Moreover this
bool also controls user helper in an unclear way.

Resolve this problem by adding a one flexible function and making old
request_firmware_nowait a simple inline using new solution. This
implementation:
1) Modifies only single bits on existing code
2) Doesn't require adjusting / rewriting current drivers
3) Adds new function for drivers that need more control over loading a
   firmware. Thanks to using flags more features can be added later.

Signed-off-by: Rafał Miłecki 
---
This patch is based on top of
[PATCH V2 RESEND] firmware: simplify defining and handling FW_OPT_FALLBACK
applied on top of Linux 4.10-rc8.

Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick
this patchset? Second patch modifies brcmfmac, I'll try to get a proper Ack for
that one.
Unless you want this to go through wireless tree, then let me know please.
---
 drivers/base/firmware_class.c | 25 ++---
 include/linux/firmware.h  | 34 +-
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index d05be1732c8b..7b3f0a018dc3 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -182,18 +182,6 @@ static int __fw_state_check(struct fw_state *fw_st, enum 
fw_status status)
 
 #endif /* CONFIG_FW_LOADER_USER_HELPER */
 
-/* firmware behavior options */
-#define FW_OPT_UEVENT  (1U << 0)
-#define FW_OPT_NOWAIT  (1U << 1)
-#ifdef CONFIG_FW_LOADER_USER_HELPER
-#define FW_OPT_USERHELPER  (1U << 2)
-#else
-#define FW_OPT_USERHELPER  0
-#endif
-#define FW_OPT_NO_WARN (1U << 3)
-#define FW_OPT_NOCACHE (1U << 4)
-#define FW_OPT_FALLBACK(1U << 5)
-
 struct firmware_cache {
/* firmware_buf instance will be added into the below list */
spinlock_t lock;
@@ -1356,7 +1344,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
_request_firmware(, fw_work->name, fw_work->device, NULL, 0,
  fw_work->opt_flags);
fw_work->cont(fw, fw_work->context);
-   put_device(fw_work->device); /* taken in request_firmware_nowait() */
+   put_device(fw_work->device); /* taken in request_firmware_async() */
 
module_put(fw_work->module);
kfree_const(fw_work->name);
@@ -1364,7 +1352,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
 }
 
 /**
- * request_firmware_nowait - asynchronous version of request_firmware
+ * request_firmware_async - asynchronous version of request_firmware
  * @module: module requesting the firmware
  * @uevent: sends uevent to copy the firmware image if this flag
  * is non-zero else the firmware copy must be done manually.
@@ -1387,8 +1375,8 @@ static void request_firmware_work_func(struct work_struct 
*work)
  * - can't sleep at all if @gfp is GFP_ATOMIC.
  **/
 int
-request_firmware_nowait(
-   struct module *module, bool uevent,
+request_firmware_async(
+   struct module *module, unsigned int opt_flags,
const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
 {
@@ -1407,8 +1395,7 @@ request_firmware_nowait(
fw_work->device = device;
fw_work->context = context;
fw_work->cont = cont;
-   fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+   fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;
 
if (!try_module_get(module)) {
kfree_const(fw_work->name);
@@ -1421,7 +1408,7 @@ request_firmware_nowait(
schedule_work(_work->work);
return 0;
 }
-EXPORT_SYMBOL(request_firmware_nowait);
+EXPORT_SYMBOL(request_firmware_async);
 
 #ifdef CONFIG_PM_SLEEP
 static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index b1f9f0ccb8ac..1f2bf14aa441 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -8,6 +8,18 @@
 #define FW_ACTION_NOHOTPLUG 0
 #define FW_ACTION_HOTPLUG 1
 
+/* firmware behavior options */
+#define FW_OPT_UEVENT  (1U << 0)
+#define FW_OPT_NOWAIT  (1U << 1)
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+#define FW_OPT_USERHELPER  (1U << 2)
+#else
+#define FW_OPT_USERHELPER  0
+#endif
+#define FW_OPT_NO_WARN (1U << 3)
+#define FW_OPT_NOCACHE (1U << 4)
+#define FW_OPT_FALLBACK(1U << 5)
+
 struct firmware {
size_t size;
const u8 *data;
@@ -41,8 +53,8 @@ struct builtin_fw {
 #if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && 
defined(MODULE))
 int request_firmware(const struct firmware **fw, const char *name,
 

[PATCH V2 1/2] firmware: add more flexible request_firmware_async function

[Rafał Miłecki]

From: Rafał Miłecki 

So far we got only one function for loading firmware asynchronously:
request_firmware_nowait. It didn't allow much customization of firmware
loading process - there is only one bool uevent argument. Moreover this
bool also controls user helper in an unclear way.

Resolve this problem by adding a one flexible function and making old
request_firmware_nowait a simple inline using new solution. This
implementation:
1) Modifies only single bits on existing code
2) Doesn't require adjusting / rewriting current drivers
3) Adds new function for drivers that need more control over loading a
   firmware. Thanks to using flags more features can be added later.

Signed-off-by: Rafał Miłecki 
---
This patch is based on top of
[PATCH V2 RESEND] firmware: simplify defining and handling FW_OPT_FALLBACK
applied on top of Linux 4.10-rc8.

Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick
this patchset? Second patch modifies brcmfmac, I'll try to get a proper Ack for
that one.
Unless you want this to go through wireless tree, then let me know please.
---
 drivers/base/firmware_class.c | 25 ++---
 include/linux/firmware.h  | 34 +-
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index d05be1732c8b..7b3f0a018dc3 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -182,18 +182,6 @@ static int __fw_state_check(struct fw_state *fw_st, enum 
fw_status status)
 
 #endif /* CONFIG_FW_LOADER_USER_HELPER */
 
-/* firmware behavior options */
-#define FW_OPT_UEVENT  (1U << 0)
-#define FW_OPT_NOWAIT  (1U << 1)
-#ifdef CONFIG_FW_LOADER_USER_HELPER
-#define FW_OPT_USERHELPER  (1U << 2)
-#else
-#define FW_OPT_USERHELPER  0
-#endif
-#define FW_OPT_NO_WARN (1U << 3)
-#define FW_OPT_NOCACHE (1U << 4)
-#define FW_OPT_FALLBACK(1U << 5)
-
 struct firmware_cache {
/* firmware_buf instance will be added into the below list */
spinlock_t lock;
@@ -1356,7 +1344,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
_request_firmware(, fw_work->name, fw_work->device, NULL, 0,
  fw_work->opt_flags);
fw_work->cont(fw, fw_work->context);
-   put_device(fw_work->device); /* taken in request_firmware_nowait() */
+   put_device(fw_work->device); /* taken in request_firmware_async() */
 
module_put(fw_work->module);
kfree_const(fw_work->name);
@@ -1364,7 +1352,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
 }
 
 /**
- * request_firmware_nowait - asynchronous version of request_firmware
+ * request_firmware_async - asynchronous version of request_firmware
  * @module: module requesting the firmware
  * @uevent: sends uevent to copy the firmware image if this flag
  * is non-zero else the firmware copy must be done manually.
@@ -1387,8 +1375,8 @@ static void request_firmware_work_func(struct work_struct 
*work)
  * - can't sleep at all if @gfp is GFP_ATOMIC.
  **/
 int
-request_firmware_nowait(
-   struct module *module, bool uevent,
+request_firmware_async(
+   struct module *module, unsigned int opt_flags,
const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
 {
@@ -1407,8 +1395,7 @@ request_firmware_nowait(
fw_work->device = device;
fw_work->context = context;
fw_work->cont = cont;
-   fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+   fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;
 
if (!try_module_get(module)) {
kfree_const(fw_work->name);
@@ -1421,7 +1408,7 @@ request_firmware_nowait(
schedule_work(_work->work);
return 0;
 }
-EXPORT_SYMBOL(request_firmware_nowait);
+EXPORT_SYMBOL(request_firmware_async);
 
 #ifdef CONFIG_PM_SLEEP
 static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index b1f9f0ccb8ac..1f2bf14aa441 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -8,6 +8,18 @@
 #define FW_ACTION_NOHOTPLUG 0
 #define FW_ACTION_HOTPLUG 1
 
+/* firmware behavior options */
+#define FW_OPT_UEVENT  (1U << 0)
+#define FW_OPT_NOWAIT  (1U << 1)
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+#define FW_OPT_USERHELPER  (1U << 2)
+#else
+#define FW_OPT_USERHELPER  0
+#endif
+#define FW_OPT_NO_WARN (1U << 3)
+#define FW_OPT_NOCACHE (1U << 4)
+#define FW_OPT_FALLBACK(1U << 5)
+
 struct firmware {
size_t size;
const u8 *data;
@@ -41,8 +53,8 @@ struct builtin_fw {
 #if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && 
defined(MODULE))
 int request_firmware(const struct firmware **fw, const char *name,
 struct device *device);
-int 

[PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Rafał Miłecki]

From: Rafał Miłecki 

Failing to load NVRAM file isn't critical if we manage to get platform
one in the fallback path. It means warnings like:
[   10.801506] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac43602-pcie.txt failed with error -2
are unnecessary & disturbing for people with platform NVRAM. This is
very common case for Broadcom home routers.

So instead of printing warning immediately with the firmware subsystem
let's first try our fallback code. If that fails as well, then it's a
right moment to print an error.

This should reduce amount of false reports from users seeing this
warning while having wireless working perfectly fine.

Signed-off-by: Rafał Miłecki 
---
V2: Update commit message as it wasn't clear enough (thanks Andy) & add extra
messages to the firmware.c.

Kalle, Arend: this patch is strictly related to the bigger 1/2. Could you ack
this change as I expect this patchset to be picked by Ming, Luis or Greg?
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index c7c1e9906500..510a76d99eee 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
raw_nvram = false;
} else {
data = bcm47xx_nvram_get_contents(_len);
-   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
+   if (!data) {
+   brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
+   if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
+   brcmf_err("Loading NVRAM from %s and using 
platform one both failed\n",
+ fwctx->nvram_name);
+   goto fail;
+   }
+   }
raw_nvram = true;
}
 
@@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const struct 
firmware *fw, void *ctx)
return;
}
fwctx->code = fw;
-   ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
- fwctx->dev, GFP_KERNEL, fwctx,
- brcmf_fw_request_nvram_done);
+   ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
+fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
+fwctx, brcmf_fw_request_nvram_done);
 
if (!ret)
return;
-- 
2.11.0

[PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Rafał Miłecki]

From: Rafał Miłecki 

Failing to load NVRAM file isn't critical if we manage to get platform
one in the fallback path. It means warnings like:
[   10.801506] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac43602-pcie.txt failed with error -2
are unnecessary & disturbing for people with platform NVRAM. This is
very common case for Broadcom home routers.

So instead of printing warning immediately with the firmware subsystem
let's first try our fallback code. If that fails as well, then it's a
right moment to print an error.

This should reduce amount of false reports from users seeing this
warning while having wireless working perfectly fine.

Signed-off-by: Rafał Miłecki 
---
V2: Update commit message as it wasn't clear enough (thanks Andy) & add extra
messages to the firmware.c.

Kalle, Arend: this patch is strictly related to the bigger 1/2. Could you ack
this change as I expect this patchset to be picked by Ming, Luis or Greg?
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index c7c1e9906500..510a76d99eee 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
raw_nvram = false;
} else {
data = bcm47xx_nvram_get_contents(_len);
-   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
+   if (!data) {
+   brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
+   if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
+   brcmf_err("Loading NVRAM from %s and using 
platform one both failed\n",
+ fwctx->nvram_name);
+   goto fail;
+   }
+   }
raw_nvram = true;
}
 
@@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const struct 
firmware *fw, void *ctx)
return;
}
fwctx->code = fw;
-   ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
- fwctx->dev, GFP_KERNEL, fwctx,
- brcmf_fw_request_nvram_done);
+   ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
+fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
+fwctx, brcmf_fw_request_nvram_done);
 
if (!ret)
return;
-- 
2.11.0

RE: [PATCH v3 2/2] sched/rt: Remove unnecessary condition in push_rt_task()

[byungchul.park]

> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Thursday, February 16, 2017 11:46 AM
> To: Byungchul Park
> Cc: pet...@infradead.org; mi...@kernel.org; linux-kernel@vger.kernel.org;
> juri.le...@gmail.com; kernel-t...@lge.com
> Subject: Re: [PATCH v3 2/2] sched/rt: Remove unnecessary condition in
> push_rt_task()
> 
> On Thu, 16 Feb 2017 11:34:17 +0900
> Byungchul Park  wrote:
> 
> > pick_next_pushable_task(rq) has BUG_ON(rq_cpu != task_cpu(task)) when
> > it returns a task other than NULL, which means that task_cpu(task) must
> > be rq->cpu. So if task == next_task, then task_cpu(next_task) must be
> > rq->cpu as well. Remove the redundant condition and make code simpler.
> >
> > By this patch, unnecessary one branch and two LOAD operations in 'if'
> > statement can be avoided.
> >
> > Signed-off-by: Byungchul Park 
> > Reviewed-by: Steven Rostedt (VMware) 
> > Reviewed-by: Juri Lelli 
> > ---
> 
> This is a different patch, I don't believe Juri reviewed it yet.

Hello juri,

I should have asked you first and been more careful before I added
'reviewed-by'. Can I ask you for your opinion about the additional one?

RE: [PATCH v3 2/2] sched/rt: Remove unnecessary condition in push_rt_task()

[byungchul.park]

> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Thursday, February 16, 2017 11:46 AM
> To: Byungchul Park
> Cc: pet...@infradead.org; mi...@kernel.org; linux-kernel@vger.kernel.org;
> juri.le...@gmail.com; kernel-t...@lge.com
> Subject: Re: [PATCH v3 2/2] sched/rt: Remove unnecessary condition in
> push_rt_task()
> 
> On Thu, 16 Feb 2017 11:34:17 +0900
> Byungchul Park  wrote:
> 
> > pick_next_pushable_task(rq) has BUG_ON(rq_cpu != task_cpu(task)) when
> > it returns a task other than NULL, which means that task_cpu(task) must
> > be rq->cpu. So if task == next_task, then task_cpu(next_task) must be
> > rq->cpu as well. Remove the redundant condition and make code simpler.
> >
> > By this patch, unnecessary one branch and two LOAD operations in 'if'
> > statement can be avoided.
> >
> > Signed-off-by: Byungchul Park 
> > Reviewed-by: Steven Rostedt (VMware) 
> > Reviewed-by: Juri Lelli 
> > ---
> 
> This is a different patch, I don't believe Juri reviewed it yet.

Hello juri,

I should have asked you first and been more careful before I added
'reviewed-by'. Can I ask you for your opinion about the additional one?

Re: swap_cluster_info lockdep splat

[Huang, Ying]

Hi, Minchan,

Minchan Kim  writes:

> Hi Huang,
>
> With changing from bit lock to spinlock of swap_cluster_info, my zram
> test failed with below message. It seems nested lock problem so need to
> play with lockdep.

Thanks a lot for your testing and report.  There is at least one nested
locking in cluster_list_add_tail(), and there are comments to describe
why it is safe.  I will try to reproduce this and fix it.

Best Regards,
Huang, Ying

> Thanks.
>
> =
> [ INFO: possible recursive locking detected ]
> 4.10.0-rc8-next-20170214-zram #24 Not tainted
> -
> as/6557 is trying to acquire lock:
>  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: [] 
> cluster_list_add_tail.part.31+0x33/0x70
>
> but task is already holding lock:
>  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: [] 
> swapcache_free_entries+0x9b/0x330
>
> other info that might help us debug this:
>  Possible unsafe locking scenario:
>
>CPU0
>
>   lock(&(&((cluster_info + ci)->lock))->rlock);
>   lock(&(&((cluster_info + ci)->lock))->rlock);
>
>  *** DEADLOCK ***
>
>  May be due to missing lock nesting notation
>
> 3 locks held by as/6557:
>  #0:  (&(>free_lock)->rlock){..}, at: [] 
> free_swap_slot+0x8b/0x110
>  #1:  (&(>lock)->rlock){+.+.-.}, at: [] 
> swapcache_free_entries+0x75/0x330
>  #2:  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: 
> [] swapcache_free_entries+0x9b/0x330
>
> stack backtrace:
> CPU: 3 PID: 6557 Comm: as Not tainted 4.10.0-rc8-next-20170214-zram #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> Call Trace:
>  dump_stack+0x85/0xc2
>  __lock_acquire+0x15ea/0x1640
>  lock_acquire+0x100/0x1f0
>  ? cluster_list_add_tail.part.31+0x33/0x70
>  _raw_spin_lock+0x38/0x50
>  ? cluster_list_add_tail.part.31+0x33/0x70
>  cluster_list_add_tail.part.31+0x33/0x70
>  swapcache_free_entries+0x2f9/0x330
>  free_swap_slot+0xf8/0x110
>  swapcache_free+0x36/0x40
>  delete_from_swap_cache+0x5f/0xa0
>  try_to_free_swap+0x6e/0xa0
>  free_pages_and_swap_cache+0x7d/0xb0
>  tlb_flush_mmu_free+0x36/0x60
>  tlb_finish_mmu+0x1c/0x50
>  exit_mmap+0xc7/0x150
>  mmput+0x51/0x110
>  do_exit+0x2b2/0xc30
>  ? trace_hardirqs_on_caller+0x129/0x1b0
>  do_group_exit+0x50/0xd0
>  SyS_exit_group+0x14/0x20
>  entry_SYSCALL_64_fastpath+0x23/0xc6
> RIP: 0033:0x2b9a2dbdf309
> RSP: 002b:7ffe71887528 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX:  RCX: 2b9a2dbdf309
> RDX:  RSI:  RDI: 
> RBP: 2b9a2ded8858 R08: 003c R09: 00e7
> R10: ff60 R11: 0246 R12: 2b9a2ded8858
> R13: 2b9a2dedde80 R14: 0255f770 R15: 0001

Re: swap_cluster_info lockdep splat

[Huang, Ying]

Hi, Minchan,

Minchan Kim  writes:

> Hi Huang,
>
> With changing from bit lock to spinlock of swap_cluster_info, my zram
> test failed with below message. It seems nested lock problem so need to
> play with lockdep.

Thanks a lot for your testing and report.  There is at least one nested
locking in cluster_list_add_tail(), and there are comments to describe
why it is safe.  I will try to reproduce this and fix it.

Best Regards,
Huang, Ying

> Thanks.
>
> =
> [ INFO: possible recursive locking detected ]
> 4.10.0-rc8-next-20170214-zram #24 Not tainted
> -
> as/6557 is trying to acquire lock:
>  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: [] 
> cluster_list_add_tail.part.31+0x33/0x70
>
> but task is already holding lock:
>  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: [] 
> swapcache_free_entries+0x9b/0x330
>
> other info that might help us debug this:
>  Possible unsafe locking scenario:
>
>CPU0
>
>   lock(&(&((cluster_info + ci)->lock))->rlock);
>   lock(&(&((cluster_info + ci)->lock))->rlock);
>
>  *** DEADLOCK ***
>
>  May be due to missing lock nesting notation
>
> 3 locks held by as/6557:
>  #0:  (&(>free_lock)->rlock){..}, at: [] 
> free_swap_slot+0x8b/0x110
>  #1:  (&(>lock)->rlock){+.+.-.}, at: [] 
> swapcache_free_entries+0x75/0x330
>  #2:  (&(&((cluster_info + ci)->lock))->rlock){+.+.-.}, at: 
> [] swapcache_free_entries+0x9b/0x330
>
> stack backtrace:
> CPU: 3 PID: 6557 Comm: as Not tainted 4.10.0-rc8-next-20170214-zram #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> Call Trace:
>  dump_stack+0x85/0xc2
>  __lock_acquire+0x15ea/0x1640
>  lock_acquire+0x100/0x1f0
>  ? cluster_list_add_tail.part.31+0x33/0x70
>  _raw_spin_lock+0x38/0x50
>  ? cluster_list_add_tail.part.31+0x33/0x70
>  cluster_list_add_tail.part.31+0x33/0x70
>  swapcache_free_entries+0x2f9/0x330
>  free_swap_slot+0xf8/0x110
>  swapcache_free+0x36/0x40
>  delete_from_swap_cache+0x5f/0xa0
>  try_to_free_swap+0x6e/0xa0
>  free_pages_and_swap_cache+0x7d/0xb0
>  tlb_flush_mmu_free+0x36/0x60
>  tlb_finish_mmu+0x1c/0x50
>  exit_mmap+0xc7/0x150
>  mmput+0x51/0x110
>  do_exit+0x2b2/0xc30
>  ? trace_hardirqs_on_caller+0x129/0x1b0
>  do_group_exit+0x50/0xd0
>  SyS_exit_group+0x14/0x20
>  entry_SYSCALL_64_fastpath+0x23/0xc6
> RIP: 0033:0x2b9a2dbdf309
> RSP: 002b:7ffe71887528 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX:  RCX: 2b9a2dbdf309
> RDX:  RSI:  RDI: 
> RBP: 2b9a2ded8858 R08: 003c R09: 00e7
> R10: ff60 R11: 0246 R12: 2b9a2ded8858
> R13: 2b9a2dedde80 R14: 0255f770 R15: 0001

Re: [of/unittest] 815d74b35e: BUG: unable to handle kernel NULL pointer dereference at 00000012

[Fengguang Wu]

On Tue, Jan 31, 2017 at 11:41:09AM +0100, Peter Zijlstra wrote:

On Mon, Jan 30, 2017 at 01:42:11PM -0500, Steven Rostedt wrote:


I think you wanted to Cc Peter Zijlstra on this. He's the kernel
maintainer for perf. I do the more generic tracing.



> > [   18.811069] CPU: 0 PID: 12140 Comm: trinity-main Not tainted 
4.5.0-rc1-00010-g815d74b #1


What does a recent kernel do?


I just checked 4.10-rc8 and don't find that BUG any more.

There are 2 "NULL pointer dereference" bugs, however their call traces
are both related to BPF:

16 BUG: kernel reboot-without-warning in test stage
 3 Oops:  [#1]
 2 Oops: 0002 [#1]
 2 BUG: unable to handle kernel NULL pointer dereference at 001c
 1 INFO: Slab 0xd55cb200 objects=16 used=16 fp=0x  (null) flags=0x15000101
 1 INFO: Slab 0xcfacd560 objects=16 used=4 fp=0xcd82bab0 flags=0xd000101
 1 INFO: Slab 0xcfaa1a40 objects=18 used=18 fp=0x  (null) flags=0xd000100
 1 INFO: Object 0xcd82b008 @offset=8 fp=0x42c9f478
 1 INFO: Object 0xcc2525f0 @offset=1520 fp=0x71a0718e
 1 INFO: Freed in 0x88 age=4294882663 cpu=0 pid=-1861259411
 1 INFO: Freed in 0x6a age=2649007364 cpu=0 pid=139
 1 INFO: Allocated in 0xb8 age=4294882663 cpu=1658843968 pid=140
 1 INFO: Allocated in 0x8c age=4294881566 cpu=2118475169 pid=56
 1 INFO: 0xcd82b000-0xcd82b007. First byte 0x61 instead of 0xcc
 1 INFO: 0xcc2525e8-0xcc2525ef. First byte 0x5d instead of 0xbb
 1 BUG: unable to handle kernel paging request at f024
 1 BUG: unable to handle kernel paging request at e24e
 1 BUG: unable to handle kernel NULL pointer dereference at 0009
 1 BUG kmalloc-64 (Not tainted): Redzone overwritten
 1 BUG kmalloc-64 (Not tainted): Padding overwritten. 0xd6010f80-0xd6010fff
 1 BUG kmalloc-32 (Not tainted): Redzone overwritten

dmesg-quantal-vp-9:20170216143544:i386-randconfig-b0-01241049:4.10.0-rc8:1

[   14.584469] sock: process `trinity-main' is using obsolete setsockopt 
SO_BSDCOMPAT
[   15.041479] BUG: unable to handle kernel NULL pointer dereference at 0009
[   15.043102] IP: __purge_vmap_area_lazy+0x39/0xd8
[   15.044359] *pde = 
[   15.044360]
[   15.045911] Oops:  [#1]
[   15.046782] Modules linked in:
[   15.047700] CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 4.10.0-rc8 #1
[   15.049592] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   15.052005] Workqueue: events bpf_prog_free_deferred
[   15.053211] task: d6eb91c0 task.stack: d6fe
[   15.054348] EIP: __purge_vmap_area_lazy+0x39/0xd8
[   15.055602] EFLAGS: 00010206 CPU: 0
[   15.056582] EAX: ffe9 EBX: d7c196d0 ECX: 0001 EDX: 0001
[   15.057993] ESI: c348376c EDI: d9792000 EBP: d6fe1e90 ESP: d6fe1e84
[   15.059409]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[   15.060683] CR0: 80050033 CR2: 0009 CR3: 18538000 CR4: 0610
[   15.062095] Call Trace:
[   15.062915]  vm_unmap_aliases+0xb7/0xe7
[   15.063956]  change_page_attr_set_clr+0xe6/0x2e5
[   15.065116]  ? __lock_acquire+0x199/0x699
[   15.066277]  set_memory_rw+0x21/0x23
[   15.067270]  bpf_prog_free_deferred+0x16/0x20
[   15.068387]  process_one_work+0x20b/0x3de
[   15.069588]  worker_thread+0x242/0x317
[   15.070818]  kthread+0xf7/0xfc
[   15.071940]  ? rescuer_thread+0x294/0x294
[   15.073214]  ? kthread_worker_fn+0xf5/0xf5
[   15.074491]  ret_from_fork+0x21/0x2c
[   15.075683] Code: cd 49 c3 00 74 11 83 ca ff b8 f8 37 48 c3 e8 34 71 f7 ff 85 c0 
74 35 31 db 87 1d 20 17 b8 c3 83 eb 20 31 d2 89 d8 83 f8 e0 74 0a <8b> 40 20 b2 
01 83 e8 20 eb f1 31 c0 84 d2 0f 84 86 00 00 00 ff
[   15.080810] EIP: __purge_vmap_area_lazy+0x39/0xd8 SS:ESP: 0068:d6fe1e84
[   15.083222] CR2: 0009
[   15.084439] ---[ end trace 8bff6d527d7169ed ]---
[   15.085799] Kernel panic - not syncing: Fatal exception
[   15.087250] Kernel Offset: 0x1c0 from 0xc100 (relocation range: 
0xc000-0xd96d1fff)

dmesg-yocto-vp-82:20170216143302:i386-randconfig-b0-01241049:4.10.0-rc8:1

[   18.090535] sock: process `trinity-main' is using obsolete setsockopt 
SO_BSDCOMPAT
[   20.255582] BUG: unable to handle kernel NULL pointer dereference at 001c
[   20.257320] IP: bpf_prog_free+0x21/0x5e
[   20.258528] *pde = 
[   20.258529]
[   20.260441] Oops: 0002 [#1]
[   20.261554] Modules linked in:
[   20.262655] CPU: 0 PID: 479 Comm: trinity-main Not tainted 4.10.0-rc8 #1
[   20.264261] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   20.266974] task: d01825c0 task.stack: d076a000
[   20.268284] EIP: bpf_prog_free+0x21/0x5e
[   20.269514] EFLAGS: 00010286 CPU: 0
[   20.270656] EAX: 002c EBX:  ECX: cb17a8a4 EDX: 9c3ce834
[   20.272210] ESI: 001c EDI: 0001 EBP: d076be90 ESP: d076be88
[   20.273779]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[   20.275201] CR0: 80050033 CR2: 001c CR3: 100a CR4: 00040610
[   20.276766] Call Trace:
[  

Re: [of/unittest] 815d74b35e: BUG: unable to handle kernel NULL pointer dereference at 00000012

[Fengguang Wu]

On Tue, Jan 31, 2017 at 11:41:09AM +0100, Peter Zijlstra wrote:

On Mon, Jan 30, 2017 at 01:42:11PM -0500, Steven Rostedt wrote:


I think you wanted to Cc Peter Zijlstra on this. He's the kernel
maintainer for perf. I do the more generic tracing.



> > [   18.811069] CPU: 0 PID: 12140 Comm: trinity-main Not tainted 
4.5.0-rc1-00010-g815d74b #1


What does a recent kernel do?


I just checked 4.10-rc8 and don't find that BUG any more.

There are 2 "NULL pointer dereference" bugs, however their call traces
are both related to BPF:

16 BUG: kernel reboot-without-warning in test stage
 3 Oops:  [#1]
 2 Oops: 0002 [#1]
 2 BUG: unable to handle kernel NULL pointer dereference at 001c
 1 INFO: Slab 0xd55cb200 objects=16 used=16 fp=0x  (null) flags=0x15000101
 1 INFO: Slab 0xcfacd560 objects=16 used=4 fp=0xcd82bab0 flags=0xd000101
 1 INFO: Slab 0xcfaa1a40 objects=18 used=18 fp=0x  (null) flags=0xd000100
 1 INFO: Object 0xcd82b008 @offset=8 fp=0x42c9f478
 1 INFO: Object 0xcc2525f0 @offset=1520 fp=0x71a0718e
 1 INFO: Freed in 0x88 age=4294882663 cpu=0 pid=-1861259411
 1 INFO: Freed in 0x6a age=2649007364 cpu=0 pid=139
 1 INFO: Allocated in 0xb8 age=4294882663 cpu=1658843968 pid=140
 1 INFO: Allocated in 0x8c age=4294881566 cpu=2118475169 pid=56
 1 INFO: 0xcd82b000-0xcd82b007. First byte 0x61 instead of 0xcc
 1 INFO: 0xcc2525e8-0xcc2525ef. First byte 0x5d instead of 0xbb
 1 BUG: unable to handle kernel paging request at f024
 1 BUG: unable to handle kernel paging request at e24e
 1 BUG: unable to handle kernel NULL pointer dereference at 0009
 1 BUG kmalloc-64 (Not tainted): Redzone overwritten
 1 BUG kmalloc-64 (Not tainted): Padding overwritten. 0xd6010f80-0xd6010fff
 1 BUG kmalloc-32 (Not tainted): Redzone overwritten

dmesg-quantal-vp-9:20170216143544:i386-randconfig-b0-01241049:4.10.0-rc8:1

[   14.584469] sock: process `trinity-main' is using obsolete setsockopt 
SO_BSDCOMPAT
[   15.041479] BUG: unable to handle kernel NULL pointer dereference at 0009
[   15.043102] IP: __purge_vmap_area_lazy+0x39/0xd8
[   15.044359] *pde = 
[   15.044360]
[   15.045911] Oops:  [#1]
[   15.046782] Modules linked in:
[   15.047700] CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 4.10.0-rc8 #1
[   15.049592] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   15.052005] Workqueue: events bpf_prog_free_deferred
[   15.053211] task: d6eb91c0 task.stack: d6fe
[   15.054348] EIP: __purge_vmap_area_lazy+0x39/0xd8
[   15.055602] EFLAGS: 00010206 CPU: 0
[   15.056582] EAX: ffe9 EBX: d7c196d0 ECX: 0001 EDX: 0001
[   15.057993] ESI: c348376c EDI: d9792000 EBP: d6fe1e90 ESP: d6fe1e84
[   15.059409]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[   15.060683] CR0: 80050033 CR2: 0009 CR3: 18538000 CR4: 0610
[   15.062095] Call Trace:
[   15.062915]  vm_unmap_aliases+0xb7/0xe7
[   15.063956]  change_page_attr_set_clr+0xe6/0x2e5
[   15.065116]  ? __lock_acquire+0x199/0x699
[   15.066277]  set_memory_rw+0x21/0x23
[   15.067270]  bpf_prog_free_deferred+0x16/0x20
[   15.068387]  process_one_work+0x20b/0x3de
[   15.069588]  worker_thread+0x242/0x317
[   15.070818]  kthread+0xf7/0xfc
[   15.071940]  ? rescuer_thread+0x294/0x294
[   15.073214]  ? kthread_worker_fn+0xf5/0xf5
[   15.074491]  ret_from_fork+0x21/0x2c
[   15.075683] Code: cd 49 c3 00 74 11 83 ca ff b8 f8 37 48 c3 e8 34 71 f7 ff 85 c0 
74 35 31 db 87 1d 20 17 b8 c3 83 eb 20 31 d2 89 d8 83 f8 e0 74 0a <8b> 40 20 b2 
01 83 e8 20 eb f1 31 c0 84 d2 0f 84 86 00 00 00 ff
[   15.080810] EIP: __purge_vmap_area_lazy+0x39/0xd8 SS:ESP: 0068:d6fe1e84
[   15.083222] CR2: 0009
[   15.084439] ---[ end trace 8bff6d527d7169ed ]---
[   15.085799] Kernel panic - not syncing: Fatal exception
[   15.087250] Kernel Offset: 0x1c0 from 0xc100 (relocation range: 
0xc000-0xd96d1fff)

dmesg-yocto-vp-82:20170216143302:i386-randconfig-b0-01241049:4.10.0-rc8:1

[   18.090535] sock: process `trinity-main' is using obsolete setsockopt 
SO_BSDCOMPAT
[   20.255582] BUG: unable to handle kernel NULL pointer dereference at 001c
[   20.257320] IP: bpf_prog_free+0x21/0x5e
[   20.258528] *pde = 
[   20.258529]
[   20.260441] Oops: 0002 [#1]
[   20.261554] Modules linked in:
[   20.262655] CPU: 0 PID: 479 Comm: trinity-main Not tainted 4.10.0-rc8 #1
[   20.264261] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   20.266974] task: d01825c0 task.stack: d076a000
[   20.268284] EIP: bpf_prog_free+0x21/0x5e
[   20.269514] EFLAGS: 00010286 CPU: 0
[   20.270656] EAX: 002c EBX:  ECX: cb17a8a4 EDX: 9c3ce834
[   20.272210] ESI: 001c EDI: 0001 EBP: d076be90 ESP: d076be88
[   20.273779]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[   20.275201] CR0: 80050033 CR2: 001c CR3: 100a CR4: 00040610
[   20.276766] Call Trace:
[  

Re: [PATCH 3.2 049/126] batman-adv: fix splat on disabling an interface

[Linus Lüssing]

On Wed, Feb 15, 2017 at 10:41:34PM +, Ben Hutchings wrote:
> 3.2.85-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Linus Lüssing 
> 
> commit 9799c50372b23ed774791bdb87d700f1286ee8a9 upstream.

Hi Ben,

This commit was reverted in
27915aa61060fd8954a68a86657784705955088a
('batman-adv: Revert "fix splat on disabling an interface"').

Greg dropped this patch from his stable queue back then, too [0].

Regards, Linus

[0]: https://marc.info/?l=linux-kernel=147938417410032

Re: [PATCH 3.2 049/126] batman-adv: fix splat on disabling an interface

[Linus Lüssing]

On Wed, Feb 15, 2017 at 10:41:34PM +, Ben Hutchings wrote:
> 3.2.85-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Linus Lüssing 
> 
> commit 9799c50372b23ed774791bdb87d700f1286ee8a9 upstream.

Hi Ben,

This commit was reverted in
27915aa61060fd8954a68a86657784705955088a
('batman-adv: Revert "fix splat on disabling an interface"').

Greg dropped this patch from his stable queue back then, too [0].

Regards, Linus

[0]: https://marc.info/?l=linux-kernel=147938417410032

[PATCH v5 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v5 3/4] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..3d23597 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a4fa336..ba96bdd 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   GENMASK(7, 0)
+#define SBA_C_MDATA_MS_SHIFT 

[PATCH v5 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v5 3/4] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..3d23597 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a4fa336..ba96bdd 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   GENMASK(7, 0)
+#define SBA_C_MDATA_MS_SHIFT   18
+#define SBA_C_MDATA_MS_MASK  

[PATCH v5 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH v5 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH v5 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH v5 0/4] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.10-rc2 and depends on patchset
"[PATCH v4 0/2] Broadcom FlexRM ring manager support"

It is also available at sba-raid-v5 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH v5 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH v5 0/4] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.10-rc2 and depends on patchset
"[PATCH v4 0/2] Broadcom FlexRM ring manager support"

It is also available at sba-raid-v5 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

Re: [PATCH] uio: add UIO_MEM_CUSTOM support

[Xiubo Li]

buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.

Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring
buffer
area(about 1.5G).

The following code is in uio_mmap() in uio.c:

if (idev->info->mmap) {
ret = idev->info->mmap(idev->info, vma);
return ret;
}

switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
return uio_mmap_physical(vma);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
default:
return -EINVAL;
}

We already have the equivalent of a CUSTOM memtype because TCMU sets the
info->mmap fn, overriding uio's default handling choices in favor of its
own.

For the driver like TCMU, the UIO_MEM_NONE could be used with
implementing its own ->mmap() magic, instead of adding new
UIO_MEM_CUSTOM. But will the semantic be clearer by using
_CUSTOM instead of _NONE  ?

Thanks,

BRs
Xiubo

HTH -- Regards -- Andy

Re: [PATCH] uio: add UIO_MEM_CUSTOM support

[Xiubo Li]

buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.

Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring
buffer
area(about 1.5G).

The following code is in uio_mmap() in uio.c:

if (idev->info->mmap) {
ret = idev->info->mmap(idev->info, vma);
return ret;
}

switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
return uio_mmap_physical(vma);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
default:
return -EINVAL;
}

We already have the equivalent of a CUSTOM memtype because TCMU sets the
info->mmap fn, overriding uio's default handling choices in favor of its
own.

For the driver like TCMU, the UIO_MEM_NONE could be used with
implementing its own ->mmap() magic, instead of adding new
UIO_MEM_CUSTOM. But will the semantic be clearer by using
_CUSTOM instead of _NONE  ?

Thanks,

BRs
Xiubo

HTH -- Regards -- Andy

Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver

[Richard Leitner]

On 02/16/2017 03:30 AM, Rob Herring wrote:

On Fri, Feb 10, 2017 at 09:19:27AM +0100, Richard Leitner wrote:

This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.

Furthermore add myself as a maintainer for this driver.

The datasheet can be found at the manufacturers website, see [1]. All
device-tree exposed configuration features have been tested on a i.MX6
platform with a USB2512B hub.

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/1692C.pdf

Signed-off-by: Richard Leitner 
---
CHANGES v5:


V5 and the first I see it?


Just double-checked it, you (robh...@kernel.org) were on CC since v1.

@greg-kh: I got the notification that v5 was already applied to your usb 
tree. So how should I proceed here? Send a v6 or send a separate patch 
fixing the dt issues mentioned by robh?





- Put includes in alphabetical order
- Fix some indentations
- Replace {set,clr}_bit_in_byte with BIT() macros
- Fix multiline comments
- Use of_property_read_u32() instead of of_get_property() where possible
- Use min_t() instead of by-hand implemented if's
- Use strlcpy and ternary operator instead of strncpy in if/else
- Remove useless & improve some other outputs
- Omit i2c remove function
- Use module_i2c_driver() instead of module_{init,exit}()
CHANGES v4:
- use utf8s_to_utf16s() instead of ascii2utf16le()
- remove ascii2utf16le() in lib/string.c again
- remove changes in drivers/usb/core/hcd.c again
  (I will post a separate patch for using utf8s_to_utf16s()
  in there too)

CHANGES v3:
- move ascii2utf16le() to lib/string.c and also use it also for
ascii2desc in drivers/usb/core/hcd.c
- remove platform data support from usb251xb driver

CHANGES v2:
- fix max-{b,s}p-current property name
- add descriptor string handling from platform_data
- fix non-dt handling
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  83 +++
 MAINTAINERS|   8 +
 drivers/usb/misc/Kconfig   |   9 +
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/usb251xb.c| 605 +
 5 files changed, 706 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb251xb.txt
 create mode 100644 drivers/usb/misc/usb251xb.c

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
new file mode 100644
index 000..0c065f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -0,0 +1,83 @@
+Microchip USB 2.0 Hi-Speed Hub Controller
+
+The device node for the configuration of a Microchip USB251xB/xBi USB 2.0
+Hi-Speed Controller.
+
+Required properties :
+ - compatible : Should be "microchip,usb251xb" or one of the specific types:
+   "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
+   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
+ - hub-reset-gpios : Should specify the gpio for hub reset


Just "reset-gpios". And you need to define the active state.


OK.




+
+Optional properties :
+ - reg : I2C address on the selected bus (default is <0x2C>)


Why is this optional?


Due to the fact the address is hardcoded insinde the chip I thought we 
could set it to 0x2C by default if reg is not given.


Should it be required?




+ - skip-config : Skip Hub configuration, but only send the USB-Attach command
+ - vendor-id : USB Vendor ID of the hub (16 bit, default is 0x0424)
+ - product-id : USB Product ID of the hub (16 bit, default depends on type)


These are to set the ids or need to match what they are set too?


These are to set the VID/PID of the Hub.




+ - device-id : USB Device ID of the hub (16 bit, default is 0x0bb3)
+ - language-id : USB Language ID (16 bit, default is 0x)
+ - manufacturer : USB Manufacturer string (max 31 characters long)
+ - product : USB Product string (max 31 characters long)
+ - serial : USB Serial string (max 31 characters long)
+ - {bus,self}-powered : selects between self- and bus-powered operation 
(default
+   is self-powered)
+ - disable-hi-speed : disable USB Hi-Speed support
+ - {multi,single}-tt : selects between multi- and single-transaction-translator
+   (default is multi-tt)
+ - disable-eop : disable End of Packet generation in full-speed mode
+ - {ganged,individual}-sensing : select over-current sense type in self-powered
+   mode (default is individual)
+ - {ganged,individual}-port-switching : select port power switching mode
+   (default is individual)
+ - dynamic-power-switching : enable auto-switching from self- to bus-powered
+   operation if the 

Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver

[Richard Leitner]

On 02/16/2017 03:30 AM, Rob Herring wrote:

On Fri, Feb 10, 2017 at 09:19:27AM +0100, Richard Leitner wrote:

This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.

Furthermore add myself as a maintainer for this driver.

The datasheet can be found at the manufacturers website, see [1]. All
device-tree exposed configuration features have been tested on a i.MX6
platform with a USB2512B hub.

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/1692C.pdf

Signed-off-by: Richard Leitner 
---
CHANGES v5:


V5 and the first I see it?


Just double-checked it, you (robh...@kernel.org) were on CC since v1.

@greg-kh: I got the notification that v5 was already applied to your usb 
tree. So how should I proceed here? Send a v6 or send a separate patch 
fixing the dt issues mentioned by robh?





- Put includes in alphabetical order
- Fix some indentations
- Replace {set,clr}_bit_in_byte with BIT() macros
- Fix multiline comments
- Use of_property_read_u32() instead of of_get_property() where possible
- Use min_t() instead of by-hand implemented if's
- Use strlcpy and ternary operator instead of strncpy in if/else
- Remove useless & improve some other outputs
- Omit i2c remove function
- Use module_i2c_driver() instead of module_{init,exit}()
CHANGES v4:
- use utf8s_to_utf16s() instead of ascii2utf16le()
- remove ascii2utf16le() in lib/string.c again
- remove changes in drivers/usb/core/hcd.c again
  (I will post a separate patch for using utf8s_to_utf16s()
  in there too)

CHANGES v3:
- move ascii2utf16le() to lib/string.c and also use it also for
ascii2desc in drivers/usb/core/hcd.c
- remove platform data support from usb251xb driver

CHANGES v2:
- fix max-{b,s}p-current property name
- add descriptor string handling from platform_data
- fix non-dt handling
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  83 +++
 MAINTAINERS|   8 +
 drivers/usb/misc/Kconfig   |   9 +
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/usb251xb.c| 605 +
 5 files changed, 706 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb251xb.txt
 create mode 100644 drivers/usb/misc/usb251xb.c

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
new file mode 100644
index 000..0c065f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -0,0 +1,83 @@
+Microchip USB 2.0 Hi-Speed Hub Controller
+
+The device node for the configuration of a Microchip USB251xB/xBi USB 2.0
+Hi-Speed Controller.
+
+Required properties :
+ - compatible : Should be "microchip,usb251xb" or one of the specific types:
+   "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
+   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
+ - hub-reset-gpios : Should specify the gpio for hub reset


Just "reset-gpios". And you need to define the active state.


OK.




+
+Optional properties :
+ - reg : I2C address on the selected bus (default is <0x2C>)


Why is this optional?


Due to the fact the address is hardcoded insinde the chip I thought we 
could set it to 0x2C by default if reg is not given.


Should it be required?




+ - skip-config : Skip Hub configuration, but only send the USB-Attach command
+ - vendor-id : USB Vendor ID of the hub (16 bit, default is 0x0424)
+ - product-id : USB Product ID of the hub (16 bit, default depends on type)


These are to set the ids or need to match what they are set too?


These are to set the VID/PID of the Hub.




+ - device-id : USB Device ID of the hub (16 bit, default is 0x0bb3)
+ - language-id : USB Language ID (16 bit, default is 0x)
+ - manufacturer : USB Manufacturer string (max 31 characters long)
+ - product : USB Product string (max 31 characters long)
+ - serial : USB Serial string (max 31 characters long)
+ - {bus,self}-powered : selects between self- and bus-powered operation 
(default
+   is self-powered)
+ - disable-hi-speed : disable USB Hi-Speed support
+ - {multi,single}-tt : selects between multi- and single-transaction-translator
+   (default is multi-tt)
+ - disable-eop : disable End of Packet generation in full-speed mode
+ - {ganged,individual}-sensing : select over-current sense type in self-powered
+   mode (default is individual)
+ - {ganged,individual}-port-switching : select port power switching mode
+   (default is individual)
+ - dynamic-power-switching : enable auto-switching from self- to bus-powered
+   operation if the local power source is removed or 

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Chen-Yu Tsai]

On Thu, Feb 16, 2017 at 2:17 PM, Rask Ingemann Lambertsen
 wrote:
> On Fri, Feb 10, 2017 at 09:59:20AM +0100, Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Feb 09, 2017 at 12:34:06AM +0100, Rask Ingemann Lambertsen wrote:
>> > The Suncip CX-A99 board is found in at least four brands of media players.
>> > It features an Allwinner A80 ARM SoC and is found in two models:
>> >
>> > 1) 2 GiB DDR3 DRAM and 16 GB eMMC
>> > 2) 4 GiB DDR3 DRAM and 32 GB eMMC
>> >
>> > For details of the board, see the linux-sunxi page
>> > .
>>
>> Please don't put URLs in commit logs (and the DT).
>
> OK.
>
>> > Supported features (+ means tested):
>> > + One Cortex-A7 CPU core (or four with experimental U-Boot PSCI patches)
>> > + AXP808 power management chip
>> > + OZ80120 voltage regulator
>> > + Serial console port (internal)
>> > + eMMC and SD card slot
>> > + USB 2.0 host ports on on-board USB hub
>> > + SATA port on on-board SATA-to-USB bridge *
>> > + IEEE 802.11 a/b/g/n/ac SDIO Wifi
>> > + Real-time clock
>> > + LEDs
>> > - IR receiver for remote control
>> >
>> > * Only shows up when a SATA device is connected. Also, if a power source
>> >   is connected to the USB 3.0 connector across power cycles (e.g. FEL
>> >   boot), the bridge may not properly reset and not show up on the USB bus.
>> >   The vendor U-Boot performs some unknown magic which resets the bridge.
>>
>> Is that magic at the USB level, or specific to the bridge itself?
>
> I don't know, but since the other USB port connected to the hub comes up
> fine, I'm assuming it's something to do with the SATA-to-USB bridge.
>
>> > diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
>> > b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
>> > new file mode 100644
>> > index 000..f5496d2
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> [...]
>> > +   /* USB 3.0 standard-A receptacle. For now, only Vbus is supported. */
>>
>> I'm not sure what you mean by "only VBUS is supported"? Is there any
>> other signal?
>
> I'm just trying to say that at the moment, all the connector will do is to
> supply power to a connected device (for charging batteries or whatever).
>
>> > +   reg_usb0_vbus: regulator-usb0-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb0-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = < 7 15 GPIO_ACTIVE_HIGH>;/* PH15 */
>> > +   enable-active-high;
>>
>> This is redundant with the GPIO flag
>
> No. I have now tested without "enable-active-high" and then Vbus stays off.
> This is also in line with the binding documentation:
>
> "- enable-active-high: Polarity of GPIO is Active high
>  If this property is missing, the default assumed is Active low."
>
> It also seems to me that the way this is implemented in Linux, the GPIO
> polarity flag is ignored.
>
>> > +   regulator-always-on;
>>
>> And it shouldn't be always on. The USB driver will enable it if needs
>> be.
>
> Yes, we just don't have a driver for the A80 USB 3.0 port yet.
>
>> > +   /*
>> > +* A GL850G hub with two external USB connectors is connected
>> > +* to ehci0. Each has a Vbus regulator controlled by a GPIO:
>> > +* PL7 for port 1, closest to the 12 V power connector, and
>> > +* PL8 for port 2, next to the SD card slot.
>> > +* Because regulator-fixed doesn't support a GPIO list, and
>> > +* allwinner,sun9i-a80-usb-phy doesn't support more than one
>> > +* supply, we have to use regulator-always-on on usb1-2-vbus.
>> > +* Note that the GPIO pins also need cldo1 to be enabled.
>> > +*/
>>
>> What is the source of those regulators connected then? Some PMIC
>> regulator? AC-IN?
>
> These two regulators are supplied from a fixed 12 V to 5 V DC-DC converter
> which can't be controlled in any way.
>
>> > +   reg_usb1_1_vbus: regulator-usb1-1-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb1-1-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
>> > +   enable-active-high;
>> > +   };
>> > +
>> > +   reg_usb1_2_vbus: regulator-usb1-2-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb1-2-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = <_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
>> > +   enable-active-high;
>> > +   regulator-always-on;
>>
>> Same comment about always on. If the driver needs fixing to grab an
>> additional regulator, fix it, but this shouldn't be left that way.
>
> I agree, but a lot of work is missing to get to that point. To get the USB
> ports up and running, you need to enable quite a few 

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Chen-Yu Tsai]

On Thu, Feb 16, 2017 at 2:17 PM, Rask Ingemann Lambertsen
 wrote:
> On Fri, Feb 10, 2017 at 09:59:20AM +0100, Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Feb 09, 2017 at 12:34:06AM +0100, Rask Ingemann Lambertsen wrote:
>> > The Suncip CX-A99 board is found in at least four brands of media players.
>> > It features an Allwinner A80 ARM SoC and is found in two models:
>> >
>> > 1) 2 GiB DDR3 DRAM and 16 GB eMMC
>> > 2) 4 GiB DDR3 DRAM and 32 GB eMMC
>> >
>> > For details of the board, see the linux-sunxi page
>> > https://linux-sunxi.org/Sunchip_CX-A99>.
>>
>> Please don't put URLs in commit logs (and the DT).
>
> OK.
>
>> > Supported features (+ means tested):
>> > + One Cortex-A7 CPU core (or four with experimental U-Boot PSCI patches)
>> > + AXP808 power management chip
>> > + OZ80120 voltage regulator
>> > + Serial console port (internal)
>> > + eMMC and SD card slot
>> > + USB 2.0 host ports on on-board USB hub
>> > + SATA port on on-board SATA-to-USB bridge *
>> > + IEEE 802.11 a/b/g/n/ac SDIO Wifi
>> > + Real-time clock
>> > + LEDs
>> > - IR receiver for remote control
>> >
>> > * Only shows up when a SATA device is connected. Also, if a power source
>> >   is connected to the USB 3.0 connector across power cycles (e.g. FEL
>> >   boot), the bridge may not properly reset and not show up on the USB bus.
>> >   The vendor U-Boot performs some unknown magic which resets the bridge.
>>
>> Is that magic at the USB level, or specific to the bridge itself?
>
> I don't know, but since the other USB port connected to the hub comes up
> fine, I'm assuming it's something to do with the SATA-to-USB bridge.
>
>> > diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
>> > b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
>> > new file mode 100644
>> > index 000..f5496d2
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> [...]
>> > +   /* USB 3.0 standard-A receptacle. For now, only Vbus is supported. */
>>
>> I'm not sure what you mean by "only VBUS is supported"? Is there any
>> other signal?
>
> I'm just trying to say that at the moment, all the connector will do is to
> supply power to a connected device (for charging batteries or whatever).
>
>> > +   reg_usb0_vbus: regulator-usb0-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb0-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = < 7 15 GPIO_ACTIVE_HIGH>;/* PH15 */
>> > +   enable-active-high;
>>
>> This is redundant with the GPIO flag
>
> No. I have now tested without "enable-active-high" and then Vbus stays off.
> This is also in line with the binding documentation:
>
> "- enable-active-high: Polarity of GPIO is Active high
>  If this property is missing, the default assumed is Active low."
>
> It also seems to me that the way this is implemented in Linux, the GPIO
> polarity flag is ignored.
>
>> > +   regulator-always-on;
>>
>> And it shouldn't be always on. The USB driver will enable it if needs
>> be.
>
> Yes, we just don't have a driver for the A80 USB 3.0 port yet.
>
>> > +   /*
>> > +* A GL850G hub with two external USB connectors is connected
>> > +* to ehci0. Each has a Vbus regulator controlled by a GPIO:
>> > +* PL7 for port 1, closest to the 12 V power connector, and
>> > +* PL8 for port 2, next to the SD card slot.
>> > +* Because regulator-fixed doesn't support a GPIO list, and
>> > +* allwinner,sun9i-a80-usb-phy doesn't support more than one
>> > +* supply, we have to use regulator-always-on on usb1-2-vbus.
>> > +* Note that the GPIO pins also need cldo1 to be enabled.
>> > +*/
>>
>> What is the source of those regulators connected then? Some PMIC
>> regulator? AC-IN?
>
> These two regulators are supplied from a fixed 12 V to 5 V DC-DC converter
> which can't be controlled in any way.
>
>> > +   reg_usb1_1_vbus: regulator-usb1-1-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb1-1-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
>> > +   enable-active-high;
>> > +   };
>> > +
>> > +   reg_usb1_2_vbus: regulator-usb1-2-vbus {
>> > +   compatible = "regulator-fixed";
>> > +   regulator-name = "usb1-2-vbus";
>> > +   regulator-min-microvolt = <500>;
>> > +   regulator-max-microvolt = <500>;
>> > +   gpio = <_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
>> > +   enable-active-high;
>> > +   regulator-always-on;
>>
>> Same comment about always on. If the driver needs fixing to grab an
>> additional regulator, fix it, but this shouldn't be left that way.
>
> I agree, but a lot of work is missing to get to that point. To get the USB
> ports up and running, you need to enable quite a few regulators:
> 1. VDD09-USB 

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

[Viresh Kumar]

On 15-02-17, 23:35, Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
> 
> First of all, [RFC] pretty please on things like this.

Sure.

> > Normally, the time it takes to reevaluate the frequency is negligible
> > compared to the time it takes to change the frequency.
> 
> This should be "the time it takes to reevaluate the load is negligible
> relative to the time it takes to change the frequency" I suppose?
> 
> Specifically, the "to reevaluate the frequency" phrase is ambiguous.

Actually we reevaluate both load and frequency, but I am fine with what you have
suggested here.

> > And considering
> > that in the above scenario, as we haven't updated the frequency for over
> > 10ms, we should have changed the frequency as soon as the load changed.
> 
> Why should we?

I will modify above as:

... we should have changed the frequency as soon as the load changed in order to
be more responsive to the load on the CPUs.

Is that the missing part you are pointing at ?

> > Its difficult to create a test case (tried rt-app as well) where this
> > patch will show a lot of improvements as the target of this patch is a
> > real corner case. I.e. Current load is X (resulting in freq change),
> > load after rate_limit_us is also X, but right after that load becomes Y.
> > Undoubtedly this patch would improve the responsiveness in such cases.
> 
> But can that be demonstrated somehow?

I hope you are talking about demonstrating performance enhancement here? I am
not sure if we can actually have a testcase to show that. Can you or others give
some testcases where we can hit similar situation again and again ?

Though I can surely try to get some traces which show that such cases do exist
and we are able to change the frequency before waiting for another 10ms. But
such an outcome is quite obvious here.

> Otherwise it is rather not "undoubtedly", but "theoretically".

Do you want to see the traces to confirm that we actually changed the frequency
earlier due to this change ?

-- 
viresh

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

[Viresh Kumar]

On 15-02-17, 23:35, Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
> 
> First of all, [RFC] pretty please on things like this.

Sure.

> > Normally, the time it takes to reevaluate the frequency is negligible
> > compared to the time it takes to change the frequency.
> 
> This should be "the time it takes to reevaluate the load is negligible
> relative to the time it takes to change the frequency" I suppose?
> 
> Specifically, the "to reevaluate the frequency" phrase is ambiguous.

Actually we reevaluate both load and frequency, but I am fine with what you have
suggested here.

> > And considering
> > that in the above scenario, as we haven't updated the frequency for over
> > 10ms, we should have changed the frequency as soon as the load changed.
> 
> Why should we?

I will modify above as:

... we should have changed the frequency as soon as the load changed in order to
be more responsive to the load on the CPUs.

Is that the missing part you are pointing at ?

> > Its difficult to create a test case (tried rt-app as well) where this
> > patch will show a lot of improvements as the target of this patch is a
> > real corner case. I.e. Current load is X (resulting in freq change),
> > load after rate_limit_us is also X, but right after that load becomes Y.
> > Undoubtedly this patch would improve the responsiveness in such cases.
> 
> But can that be demonstrated somehow?

I hope you are talking about demonstrating performance enhancement here? I am
not sure if we can actually have a testcase to show that. Can you or others give
some testcases where we can hit similar situation again and again ?

Though I can surely try to get some traces which show that such cases do exist
and we are able to change the frequency before waiting for another 10ms. But
such an outcome is quite obvious here.

> Otherwise it is rather not "undoubtedly", but "theoretically".

Do you want to see the traces to confirm that we actually changed the frequency
earlier due to this change ?

-- 
viresh

Re: [PATCH v6 0/3] perf: add support for analyzing events for containers

[Eric W. Biederman]

Hari Bathini  writes:

> Currently, there is no trivial mechanism to analyze events based on
> containers. perf -G can be used, but it will not filter events for the
> containers created after perf is invoked, making it difficult to assess/
> analyze performance issues of multiple containers at once.
>
> This patch-set is aimed at addressing this limitation by introducing a
> new PERF_RECORD_NAMESPACES event that records namespaces related info.
> As containers are created with namespaces, the new data can be used to
> in assessment/analysis of multiple containers.
>
> The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
> second patch makes the corresponding changes in perf tool to read this
> PERF_RECORD_NAMESPACES events. The third patch demonstrates analysis
> of containers with this data by adding a cgroup identifier column in
> perf report, which contains the cgroup namespace's device and inode
> numbers. This is based on the assumption that each container is created
> with it's own cgroup namespace. The third patch has scope for improvement
> based on the conventions a container is attributed with, going
> forward.

Ack for the namespace interface bits.
Everything I asked for is in there.

Eric


>
> Changes from v5:
> * Updated changelogs of patches 1 & 3
> * Rebased the patches on perf/core in tip
>
> ---
>
> Hari Bathini (3):
>   perf: add PERF_RECORD_NAMESPACES to include namespaces related info
>   perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info
>   perf tool: add cgroup identifier entry in perf report
>
>
>  include/linux/perf_event.h|2 
>  include/uapi/linux/perf_event.h   |   38 +
>  kernel/events/core.c  |  142 
> +
>  kernel/fork.c |3 +
>  kernel/nsproxy.c  |5 +
>  tools/include/uapi/linux/perf_event.h |   38 +
>  tools/perf/builtin-annotate.c |1 
>  tools/perf/builtin-diff.c |1 
>  tools/perf/builtin-inject.c   |   14 +++
>  tools/perf/builtin-kmem.c |1 
>  tools/perf/builtin-kvm.c  |2 
>  tools/perf/builtin-lock.c |1 
>  tools/perf/builtin-mem.c  |1 
>  tools/perf/builtin-record.c   |   33 +++-
>  tools/perf/builtin-report.c   |1 
>  tools/perf/builtin-sched.c|1 
>  tools/perf/builtin-script.c   |   41 +
>  tools/perf/builtin-trace.c|3 -
>  tools/perf/perf.h |1 
>  tools/perf/util/Build |1 
>  tools/perf/util/data-convert-bt.c |2 
>  tools/perf/util/event.c   |  143 
> -
>  tools/perf/util/event.h   |   19 
>  tools/perf/util/evsel.c   |3 +
>  tools/perf/util/hist.c|7 ++
>  tools/perf/util/hist.h|1 
>  tools/perf/util/machine.c |   34 
>  tools/perf/util/machine.h |3 +
>  tools/perf/util/namespaces.c  |   35 
>  tools/perf/util/namespaces.h  |   26 ++
>  tools/perf/util/session.c |7 ++
>  tools/perf/util/sort.c|   41 +
>  tools/perf/util/sort.h|7 ++
>  tools/perf/util/thread.c  |   44 ++
>  tools/perf/util/thread.h  |6 +
>  tools/perf/util/tool.h|2 
>  36 files changed, 695 insertions(+), 15 deletions(-)
>  create mode 100644 tools/perf/util/namespaces.c
>  create mode 100644 tools/perf/util/namespaces.h
>
> --

Re: [PATCH v6 0/3] perf: add support for analyzing events for containers

[Eric W. Biederman]

Hari Bathini  writes:

> Currently, there is no trivial mechanism to analyze events based on
> containers. perf -G can be used, but it will not filter events for the
> containers created after perf is invoked, making it difficult to assess/
> analyze performance issues of multiple containers at once.
>
> This patch-set is aimed at addressing this limitation by introducing a
> new PERF_RECORD_NAMESPACES event that records namespaces related info.
> As containers are created with namespaces, the new data can be used to
> in assessment/analysis of multiple containers.
>
> The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
> second patch makes the corresponding changes in perf tool to read this
> PERF_RECORD_NAMESPACES events. The third patch demonstrates analysis
> of containers with this data by adding a cgroup identifier column in
> perf report, which contains the cgroup namespace's device and inode
> numbers. This is based on the assumption that each container is created
> with it's own cgroup namespace. The third patch has scope for improvement
> based on the conventions a container is attributed with, going
> forward.

Ack for the namespace interface bits.
Everything I asked for is in there.

Eric


>
> Changes from v5:
> * Updated changelogs of patches 1 & 3
> * Rebased the patches on perf/core in tip
>
> ---
>
> Hari Bathini (3):
>   perf: add PERF_RECORD_NAMESPACES to include namespaces related info
>   perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info
>   perf tool: add cgroup identifier entry in perf report
>
>
>  include/linux/perf_event.h|2 
>  include/uapi/linux/perf_event.h   |   38 +
>  kernel/events/core.c  |  142 
> +
>  kernel/fork.c |3 +
>  kernel/nsproxy.c  |5 +
>  tools/include/uapi/linux/perf_event.h |   38 +
>  tools/perf/builtin-annotate.c |1 
>  tools/perf/builtin-diff.c |1 
>  tools/perf/builtin-inject.c   |   14 +++
>  tools/perf/builtin-kmem.c |1 
>  tools/perf/builtin-kvm.c  |2 
>  tools/perf/builtin-lock.c |1 
>  tools/perf/builtin-mem.c  |1 
>  tools/perf/builtin-record.c   |   33 +++-
>  tools/perf/builtin-report.c   |1 
>  tools/perf/builtin-sched.c|1 
>  tools/perf/builtin-script.c   |   41 +
>  tools/perf/builtin-trace.c|3 -
>  tools/perf/perf.h |1 
>  tools/perf/util/Build |1 
>  tools/perf/util/data-convert-bt.c |2 
>  tools/perf/util/event.c   |  143 
> -
>  tools/perf/util/event.h   |   19 
>  tools/perf/util/evsel.c   |3 +
>  tools/perf/util/hist.c|7 ++
>  tools/perf/util/hist.h|1 
>  tools/perf/util/machine.c |   34 
>  tools/perf/util/machine.h |3 +
>  tools/perf/util/namespaces.c  |   35 
>  tools/perf/util/namespaces.h  |   26 ++
>  tools/perf/util/session.c |7 ++
>  tools/perf/util/sort.c|   41 +
>  tools/perf/util/sort.h|7 ++
>  tools/perf/util/thread.c  |   44 ++
>  tools/perf/util/thread.h  |6 +
>  tools/perf/util/tool.h|2 
>  36 files changed, 695 insertions(+), 15 deletions(-)
>  create mode 100644 tools/perf/util/namespaces.c
>  create mode 100644 tools/perf/util/namespaces.h
>
> --

Re: [PATCH 3/3] mm, vmscan: Prevent kswapd sleeping prematurely due to mismatched classzone_idx

[Hillf Danton]

On February 15, 2017 5:23 PM Mel Gorman wrote: 
>   */
>  static int kswapd(void *p)
>  {
> - unsigned int alloc_order, reclaim_order, classzone_idx;
> + unsigned int alloc_order, reclaim_order;
> + unsigned int classzone_idx = MAX_NR_ZONES - 1;
>   pg_data_t *pgdat = (pg_data_t*)p;
>   struct task_struct *tsk = current;
> 
> @@ -3447,20 +3466,23 @@ static int kswapd(void *p)
>   tsk->flags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
>   set_freezable();
> 
> - pgdat->kswapd_order = alloc_order = reclaim_order = 0;
> - pgdat->kswapd_classzone_idx = classzone_idx = 0;
> + pgdat->kswapd_order = 0;
> + pgdat->kswapd_classzone_idx = MAX_NR_ZONES;
>   for ( ; ; ) {
>   bool ret;
> 
> + alloc_order = reclaim_order = pgdat->kswapd_order;
> + classzone_idx = kswapd_classzone_idx(pgdat, classzone_idx);
> +
>  kswapd_try_sleep:
>   kswapd_try_to_sleep(pgdat, alloc_order, reclaim_order,
>   classzone_idx);
> 
>   /* Read the new order and classzone_idx */
>   alloc_order = reclaim_order = pgdat->kswapd_order;
> - classzone_idx = pgdat->kswapd_classzone_idx;
> + classzone_idx = kswapd_classzone_idx(pgdat, 0);
>   pgdat->kswapd_order = 0;
> - pgdat->kswapd_classzone_idx = 0;
> + pgdat->kswapd_classzone_idx = MAX_NR_ZONES;
> 
>   ret = try_to_freeze();
>   if (kthread_should_stop())
> @@ -3486,9 +3508,6 @@ static int kswapd(void *p)
>   reclaim_order = balance_pgdat(pgdat, alloc_order, 
> classzone_idx);
>   if (reclaim_order < alloc_order)
>   goto kswapd_try_sleep;

If we fail order-5 request,  can we then give up order-5, and
try order-3 if requested, after napping?

> -
> - alloc_order = reclaim_order = pgdat->kswapd_order;
> - classzone_idx = pgdat->kswapd_classzone_idx;
>   }
> 

Re: [PATCH 3/3] mm, vmscan: Prevent kswapd sleeping prematurely due to mismatched classzone_idx

[Hillf Danton]

On February 15, 2017 5:23 PM Mel Gorman wrote: 
>   */
>  static int kswapd(void *p)
>  {
> - unsigned int alloc_order, reclaim_order, classzone_idx;
> + unsigned int alloc_order, reclaim_order;
> + unsigned int classzone_idx = MAX_NR_ZONES - 1;
>   pg_data_t *pgdat = (pg_data_t*)p;
>   struct task_struct *tsk = current;
> 
> @@ -3447,20 +3466,23 @@ static int kswapd(void *p)
>   tsk->flags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
>   set_freezable();
> 
> - pgdat->kswapd_order = alloc_order = reclaim_order = 0;
> - pgdat->kswapd_classzone_idx = classzone_idx = 0;
> + pgdat->kswapd_order = 0;
> + pgdat->kswapd_classzone_idx = MAX_NR_ZONES;
>   for ( ; ; ) {
>   bool ret;
> 
> + alloc_order = reclaim_order = pgdat->kswapd_order;
> + classzone_idx = kswapd_classzone_idx(pgdat, classzone_idx);
> +
>  kswapd_try_sleep:
>   kswapd_try_to_sleep(pgdat, alloc_order, reclaim_order,
>   classzone_idx);
> 
>   /* Read the new order and classzone_idx */
>   alloc_order = reclaim_order = pgdat->kswapd_order;
> - classzone_idx = pgdat->kswapd_classzone_idx;
> + classzone_idx = kswapd_classzone_idx(pgdat, 0);
>   pgdat->kswapd_order = 0;
> - pgdat->kswapd_classzone_idx = 0;
> + pgdat->kswapd_classzone_idx = MAX_NR_ZONES;
> 
>   ret = try_to_freeze();
>   if (kthread_should_stop())
> @@ -3486,9 +3508,6 @@ static int kswapd(void *p)
>   reclaim_order = balance_pgdat(pgdat, alloc_order, 
> classzone_idx);
>   if (reclaim_order < alloc_order)
>   goto kswapd_try_sleep;

If we fail order-5 request,  can we then give up order-5, and
try order-3 if requested, after napping?

> -
> - alloc_order = reclaim_order = pgdat->kswapd_order;
> - classzone_idx = pgdat->kswapd_classzone_idx;
>   }
> 

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Rask Ingemann Lambertsen]

On Fri, Feb 10, 2017 at 09:59:20AM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Feb 09, 2017 at 12:34:06AM +0100, Rask Ingemann Lambertsen wrote:
> > The Suncip CX-A99 board is found in at least four brands of media players.
> > It features an Allwinner A80 ARM SoC and is found in two models:
> > 
> > 1) 2 GiB DDR3 DRAM and 16 GB eMMC
> > 2) 4 GiB DDR3 DRAM and 32 GB eMMC
> > 
> > For details of the board, see the linux-sunxi page
> > .
> 
> Please don't put URLs in commit logs (and the DT).

OK.

> > Supported features (+ means tested):
> > + One Cortex-A7 CPU core (or four with experimental U-Boot PSCI patches)
> > + AXP808 power management chip
> > + OZ80120 voltage regulator
> > + Serial console port (internal)
> > + eMMC and SD card slot
> > + USB 2.0 host ports on on-board USB hub
> > + SATA port on on-board SATA-to-USB bridge *
> > + IEEE 802.11 a/b/g/n/ac SDIO Wifi
> > + Real-time clock
> > + LEDs
> > - IR receiver for remote control
> > 
> > * Only shows up when a SATA device is connected. Also, if a power source
> >   is connected to the USB 3.0 connector across power cycles (e.g. FEL
> >   boot), the bridge may not properly reset and not show up on the USB bus.
> >   The vendor U-Boot performs some unknown magic which resets the bridge.
> 
> Is that magic at the USB level, or specific to the bridge itself?

I don't know, but since the other USB port connected to the hub comes up
fine, I'm assuming it's something to do with the SATA-to-USB bridge.

> > diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> > b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> > new file mode 100644
> > index 000..f5496d2
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
[...]
> > +   /* USB 3.0 standard-A receptacle. For now, only Vbus is supported. */
> 
> I'm not sure what you mean by "only VBUS is supported"? Is there any
> other signal?

I'm just trying to say that at the moment, all the connector will do is to
supply power to a connected device (for charging batteries or whatever).

> > +   reg_usb0_vbus: regulator-usb0-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb0-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = < 7 15 GPIO_ACTIVE_HIGH>;/* PH15 */
> > +   enable-active-high;
> 
> This is redundant with the GPIO flag

No. I have now tested without "enable-active-high" and then Vbus stays off.
This is also in line with the binding documentation:

"- enable-active-high: Polarity of GPIO is Active high
 If this property is missing, the default assumed is Active low."

It also seems to me that the way this is implemented in Linux, the GPIO
polarity flag is ignored.

> > +   regulator-always-on;
> 
> And it shouldn't be always on. The USB driver will enable it if needs
> be.

Yes, we just don't have a driver for the A80 USB 3.0 port yet.

> > +   /*
> > +* A GL850G hub with two external USB connectors is connected
> > +* to ehci0. Each has a Vbus regulator controlled by a GPIO:
> > +* PL7 for port 1, closest to the 12 V power connector, and
> > +* PL8 for port 2, next to the SD card slot.
> > +* Because regulator-fixed doesn't support a GPIO list, and
> > +* allwinner,sun9i-a80-usb-phy doesn't support more than one
> > +* supply, we have to use regulator-always-on on usb1-2-vbus.
> > +* Note that the GPIO pins also need cldo1 to be enabled.
> > +*/
> 
> What is the source of those regulators connected then? Some PMIC
> regulator? AC-IN?

These two regulators are supplied from a fixed 12 V to 5 V DC-DC converter
which can't be controlled in any way.

> > +   reg_usb1_1_vbus: regulator-usb1-1-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb1-1-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
> > +   enable-active-high;
> > +   };
> > +
> > +   reg_usb1_2_vbus: regulator-usb1-2-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb1-2-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
> > +   enable-active-high;
> > +   regulator-always-on;
> 
> Same comment about always on. If the driver needs fixing to grab an
> additional regulator, fix it, but this shouldn't be left that way.

I agree, but a lot of work is missing to get to that point. To get the USB
ports up and running, you need to enable quite a few regulators:
1. VDD09-USB for the controller internals.
2. VCC33-USB for the PHY.
3. Vbus for each connector belonging to the controller.
4. Pin group supply for the GPIO pins controlling each of the Vbus supplies.

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Rask Ingemann Lambertsen]

On Fri, Feb 10, 2017 at 09:59:20AM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Feb 09, 2017 at 12:34:06AM +0100, Rask Ingemann Lambertsen wrote:
> > The Suncip CX-A99 board is found in at least four brands of media players.
> > It features an Allwinner A80 ARM SoC and is found in two models:
> > 
> > 1) 2 GiB DDR3 DRAM and 16 GB eMMC
> > 2) 4 GiB DDR3 DRAM and 32 GB eMMC
> > 
> > For details of the board, see the linux-sunxi page
> > https://linux-sunxi.org/Sunchip_CX-A99>.
> 
> Please don't put URLs in commit logs (and the DT).

OK.

> > Supported features (+ means tested):
> > + One Cortex-A7 CPU core (or four with experimental U-Boot PSCI patches)
> > + AXP808 power management chip
> > + OZ80120 voltage regulator
> > + Serial console port (internal)
> > + eMMC and SD card slot
> > + USB 2.0 host ports on on-board USB hub
> > + SATA port on on-board SATA-to-USB bridge *
> > + IEEE 802.11 a/b/g/n/ac SDIO Wifi
> > + Real-time clock
> > + LEDs
> > - IR receiver for remote control
> > 
> > * Only shows up when a SATA device is connected. Also, if a power source
> >   is connected to the USB 3.0 connector across power cycles (e.g. FEL
> >   boot), the bridge may not properly reset and not show up on the USB bus.
> >   The vendor U-Boot performs some unknown magic which resets the bridge.
> 
> Is that magic at the USB level, or specific to the bridge itself?

I don't know, but since the other USB port connected to the hub comes up
fine, I'm assuming it's something to do with the SATA-to-USB bridge.

> > diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> > b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> > new file mode 100644
> > index 000..f5496d2
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
[...]
> > +   /* USB 3.0 standard-A receptacle. For now, only Vbus is supported. */
> 
> I'm not sure what you mean by "only VBUS is supported"? Is there any
> other signal?

I'm just trying to say that at the moment, all the connector will do is to
supply power to a connected device (for charging batteries or whatever).

> > +   reg_usb0_vbus: regulator-usb0-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb0-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = < 7 15 GPIO_ACTIVE_HIGH>;/* PH15 */
> > +   enable-active-high;
> 
> This is redundant with the GPIO flag

No. I have now tested without "enable-active-high" and then Vbus stays off.
This is also in line with the binding documentation:

"- enable-active-high: Polarity of GPIO is Active high
 If this property is missing, the default assumed is Active low."

It also seems to me that the way this is implemented in Linux, the GPIO
polarity flag is ignored.

> > +   regulator-always-on;
> 
> And it shouldn't be always on. The USB driver will enable it if needs
> be.

Yes, we just don't have a driver for the A80 USB 3.0 port yet.

> > +   /*
> > +* A GL850G hub with two external USB connectors is connected
> > +* to ehci0. Each has a Vbus regulator controlled by a GPIO:
> > +* PL7 for port 1, closest to the 12 V power connector, and
> > +* PL8 for port 2, next to the SD card slot.
> > +* Because regulator-fixed doesn't support a GPIO list, and
> > +* allwinner,sun9i-a80-usb-phy doesn't support more than one
> > +* supply, we have to use regulator-always-on on usb1-2-vbus.
> > +* Note that the GPIO pins also need cldo1 to be enabled.
> > +*/
> 
> What is the source of those regulators connected then? Some PMIC
> regulator? AC-IN?

These two regulators are supplied from a fixed 12 V to 5 V DC-DC converter
which can't be controlled in any way.

> > +   reg_usb1_1_vbus: regulator-usb1-1-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb1-1-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
> > +   enable-active-high;
> > +   };
> > +
> > +   reg_usb1_2_vbus: regulator-usb1-2-vbus {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb1-2-vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
> > +   enable-active-high;
> > +   regulator-always-on;
> 
> Same comment about always on. If the driver needs fixing to grab an
> additional regulator, fix it, but this shouldn't be left that way.

I agree, but a lot of work is missing to get to that point. To get the USB
ports up and running, you need to enable quite a few regulators:
1. VDD09-USB for the controller internals.
2. VCC33-USB for the PHY.
3. Vbus for each connector belonging to the controller.
4. Pin group supply for the GPIO pins controlling each of the Vbus supplies.

Re: [PATCH v4 3/3] PCI: imx6: Add code to support i.MX7D

[Andrey Smirnov]

On Wed, Feb 15, 2017 at 9:17 AM, Rob Herring  wrote:
> On Tue, Feb 07, 2017 at 07:50:27AM -0800, Andrey Smirnov wrote:
>> Add various bits of code needed to support i.MX7D variant of the IP.
>>
>> Cc: yurov...@gmail.com
>> Cc: Lucas Stach 
>> Cc: Bjorn Helgaas 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: Lee Jones 
>> Cc: Fabio Estevam 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt |  13 ++-
>>  drivers/pci/host/pci-imx6.c| 121 
>> -
>>  include/linux/mfd/syscon/imx7-iomuxc-gpr.h |   4 +
>>  3 files changed, 112 insertions(+), 26 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> index 83aeb1f..11db2ab 100644
>> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> @@ -4,7 +4,11 @@ This PCIe host controller is based on the Synopsis 
>> Designware PCIe IP
>>  and thus inherits all the common properties defined in designware-pcie.txt.
>>
>>  Required properties:
>> -- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
>> +- compatible:
>> + - "fsl,imx6q-pcie"
>> + - "fsl,imx6sx-pcie",
>> + - "fsl,imx6qp-pcie"
>> + - "fsl,imx7d-pcie"
>>  - reg: base address and length of the PCIe controller
>>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>>entry for each entry in the interrupt-names property.
>> @@ -34,6 +38,13 @@ Additional required properties for imx6sx-pcie:
>>  - clock names: Must include the following additional entries:
>>   - "pcie_inbound_axi"
>>
>> +Additional required properties for imx7d-pcie:
>> +- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
>
> This domain is just the PHY? Seems like this needs a separate PHY
> driver.

PCIE_PHY is the name of the power domain corresponding to PGC_PCIE
(which is what that property is expected to point to) as per
Frescale/NXP datasheet (p. 822 in v0.1 of i.MX7 Application Processors
Manual). I was never able to find any clear language indicating what
parts of DesignWare's IP core and Freescale's/NXP's PCIE PHY it powers
in the manual. However, experiments with hardware show that when that
domain remains non-powered any attempt to access registers of DW's IP
block result in system hanging, so it seemed to me that the two are
not independent of each other enough to be represented as individual
DT nodes.

>
>> +- resets: Must contain phandles to PCIE related reset lines exposed by SRC 
>> IP block
>> +- reset-names: Must contain the following entires:
>> +- "pciephy"
>
> And for this too.
>
>> +- "apps"
>> +
>>  Example:
>>
>>   pcie@0x0100 {
>
> [...]
>
>> @@ -251,6 +261,10 @@ static void imx6_pcie_assert_core_reset(struct 
>> imx6_pcie *imx6_pcie)
>>   u32 val, gpr1, gpr12;
>>
>>   switch (imx6_pcie->variant) {
>> + case IMX7D:
>> + reset_control_assert(imx6_pcie->pciephy_reset);
>> + reset_control_assert(imx6_pcie->apps_reset);
>> + break;
>>   case IMX6SX:
>>   regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
>>  IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
>
> So the difference with i.MX7D is not really that it has a reset or not,
> but some platforms use a reset driver and some do not. The latter should
> be fixed.

That depends on what variant of the SoC you are comparing it to. 6QP,
6SX do have reset and helper signals wire to bits in registers in
IOMUX, 6Q howerver doesn't have a reset line wire and have to do some
trickery as per comment in the driver several lines below:

"... As there is no dedicated reset signal wired up for MX6QDL, we
need to manually force LTSSM into "detect" state before completely
disabling LTSSM, which is a prerequisite for core configuration..."

If memory serves me well part of that 6Q trickery code is the reason
for driver using hook_fault_code().

That is not to say that all of this code could not be encapsulated as
a reset controller, and I agree, doing so might make the driver
better. At the same time I don't have the hardware to test all of
those platforms and I am hoping we can agree this kind of change to be
out of scope of this series.

Thanks,
Andrey Smironv

Re: [PATCH v4 3/3] PCI: imx6: Add code to support i.MX7D

[Andrey Smirnov]

On Wed, Feb 15, 2017 at 9:17 AM, Rob Herring  wrote:
> On Tue, Feb 07, 2017 at 07:50:27AM -0800, Andrey Smirnov wrote:
>> Add various bits of code needed to support i.MX7D variant of the IP.
>>
>> Cc: yurov...@gmail.com
>> Cc: Lucas Stach 
>> Cc: Bjorn Helgaas 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: Lee Jones 
>> Cc: Fabio Estevam 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt |  13 ++-
>>  drivers/pci/host/pci-imx6.c| 121 
>> -
>>  include/linux/mfd/syscon/imx7-iomuxc-gpr.h |   4 +
>>  3 files changed, 112 insertions(+), 26 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> index 83aeb1f..11db2ab 100644
>> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> @@ -4,7 +4,11 @@ This PCIe host controller is based on the Synopsis 
>> Designware PCIe IP
>>  and thus inherits all the common properties defined in designware-pcie.txt.
>>
>>  Required properties:
>> -- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
>> +- compatible:
>> + - "fsl,imx6q-pcie"
>> + - "fsl,imx6sx-pcie",
>> + - "fsl,imx6qp-pcie"
>> + - "fsl,imx7d-pcie"
>>  - reg: base address and length of the PCIe controller
>>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>>entry for each entry in the interrupt-names property.
>> @@ -34,6 +38,13 @@ Additional required properties for imx6sx-pcie:
>>  - clock names: Must include the following additional entries:
>>   - "pcie_inbound_axi"
>>
>> +Additional required properties for imx7d-pcie:
>> +- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
>
> This domain is just the PHY? Seems like this needs a separate PHY
> driver.

PCIE_PHY is the name of the power domain corresponding to PGC_PCIE
(which is what that property is expected to point to) as per
Frescale/NXP datasheet (p. 822 in v0.1 of i.MX7 Application Processors
Manual). I was never able to find any clear language indicating what
parts of DesignWare's IP core and Freescale's/NXP's PCIE PHY it powers
in the manual. However, experiments with hardware show that when that
domain remains non-powered any attempt to access registers of DW's IP
block result in system hanging, so it seemed to me that the two are
not independent of each other enough to be represented as individual
DT nodes.

>
>> +- resets: Must contain phandles to PCIE related reset lines exposed by SRC 
>> IP block
>> +- reset-names: Must contain the following entires:
>> +- "pciephy"
>
> And for this too.
>
>> +- "apps"
>> +
>>  Example:
>>
>>   pcie@0x0100 {
>
> [...]
>
>> @@ -251,6 +261,10 @@ static void imx6_pcie_assert_core_reset(struct 
>> imx6_pcie *imx6_pcie)
>>   u32 val, gpr1, gpr12;
>>
>>   switch (imx6_pcie->variant) {
>> + case IMX7D:
>> + reset_control_assert(imx6_pcie->pciephy_reset);
>> + reset_control_assert(imx6_pcie->apps_reset);
>> + break;
>>   case IMX6SX:
>>   regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
>>  IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
>
> So the difference with i.MX7D is not really that it has a reset or not,
> but some platforms use a reset driver and some do not. The latter should
> be fixed.

That depends on what variant of the SoC you are comparing it to. 6QP,
6SX do have reset and helper signals wire to bits in registers in
IOMUX, 6Q howerver doesn't have a reset line wire and have to do some
trickery as per comment in the driver several lines below:

"... As there is no dedicated reset signal wired up for MX6QDL, we
need to manually force LTSSM into "detect" state before completely
disabling LTSSM, which is a prerequisite for core configuration..."

If memory serves me well part of that 6Q trickery code is the reason
for driver using hook_fault_code().

That is not to say that all of this code could not be encapsulated as
a reset controller, and I agree, doing so might make the driver
better. At the same time I don't have the hardware to test all of
those platforms and I am hoping we can agree this kind of change to be
out of scope of this series.

Thanks,
Andrey Smironv

[RT] lockdep munching nr_list_entries like popcorn

[Mike Galbraith]

4.9.10-rt6-virgin on 72 core +SMT box.

Below is 1 line per minute, box idling along daintily nibbling, I fire
up a parallel kbuild loop at 40465, and box gobbles greedily.

I have entries bumped to 128k, and chain bits to 18 so box will get
booted and run for a while before lockdep says "I quit".  With stock
settings, this box will barely get booted.  Seems the bigger the box,
the sooner you're gonna run out.  A NOPREEMPT kernel seems to nibble
entries too, but nowhere remotely near as greedily as RT.

   <...>-100309 [064] d13  2885.873312: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40129
   <...>-104320 [116] dN..211  2959.633630: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40155
 btrfs-transacti-1955  [043] d...111  3021.073949: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40183
   <...>-118865 [120] d13  3086.146794: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40209
  systemd-logind-4763  [068] d11  3146.953001: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40239
   <...>-123725 [032] dN..2..  3215.735774: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40285
   <...>-33968 [031] d...1..  3347.919001: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40409
   <...>-130886 [143] d12  3412.586643: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40465
   <...>-138291 [037] d11  3477.816405: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 42825
   <...>-67678 [137] d...112  3551.648282: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 47899
ksoftirqd/45-421   [045] d13  3617.926394: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 48751
 ihex2fw-24635 [035] d11  3686.899690: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49345
   <...>-76041 [047] d...111  3758.230009: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49757
stty-10772 [118] d...1..  3825.626815: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 50115
  kworker/u289:4-13376 [075] d12  3896.432428: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51189
   <...>-92785 [047] d12  3905.137578: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51287

With stacktrace on, buffer contains 1010 __lru_cache_add+0x4f...

(gdb) list *__lru_cache_add+0x4f
0x811dca9f is in __lru_cache_add (./include/linux/locallock.h:59).
54
55  static inline void __local_lock(struct local_irq_lock *lv)
56  {
57  if (lv->owner != current) {
58  spin_lock_local(>lock);
59  LL_WARN(lv->owner);
60  LL_WARN(lv->nestcnt);
61  lv->owner = current;
62  }
63  lv->nestcnt++;

...which seems to be this.

0x811dca80 is in __lru_cache_add (mm/swap.c:397).
392 }
393 EXPORT_SYMBOL(mark_page_accessed);
394
395 static void __lru_cache_add(struct page *page)
396 {
397 struct pagevec *pvec = _locked_var(swapvec_lock, 
lru_add_pvec);
398
399 get_page(page);
400 if (!pagevec_add(pvec, page) || PageCompound(page))
401 __pagevec_lru_add(pvec);

swapvec_lock?  Oodles of 'em?  Nope.

-Mike

[RT] lockdep munching nr_list_entries like popcorn

[Mike Galbraith]

4.9.10-rt6-virgin on 72 core +SMT box.

Below is 1 line per minute, box idling along daintily nibbling, I fire
up a parallel kbuild loop at 40465, and box gobbles greedily.

I have entries bumped to 128k, and chain bits to 18 so box will get
booted and run for a while before lockdep says "I quit".  With stock
settings, this box will barely get booted.  Seems the bigger the box,
the sooner you're gonna run out.  A NOPREEMPT kernel seems to nibble
entries too, but nowhere remotely near as greedily as RT.

   <...>-100309 [064] d13  2885.873312: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40129
   <...>-104320 [116] dN..211  2959.633630: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40155
 btrfs-transacti-1955  [043] d...111  3021.073949: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40183
   <...>-118865 [120] d13  3086.146794: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40209
  systemd-logind-4763  [068] d11  3146.953001: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40239
   <...>-123725 [032] dN..2..  3215.735774: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40285
   <...>-33968 [031] d...1..  3347.919001: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40409
   <...>-130886 [143] d12  3412.586643: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40465
   <...>-138291 [037] d11  3477.816405: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 42825
   <...>-67678 [137] d...112  3551.648282: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 47899
ksoftirqd/45-421   [045] d13  3617.926394: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 48751
 ihex2fw-24635 [035] d11  3686.899690: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49345
   <...>-76041 [047] d...111  3758.230009: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49757
stty-10772 [118] d...1..  3825.626815: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 50115
  kworker/u289:4-13376 [075] d12  3896.432428: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51189
   <...>-92785 [047] d12  3905.137578: 
add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51287

With stacktrace on, buffer contains 1010 __lru_cache_add+0x4f...

(gdb) list *__lru_cache_add+0x4f
0x811dca9f is in __lru_cache_add (./include/linux/locallock.h:59).
54
55  static inline void __local_lock(struct local_irq_lock *lv)
56  {
57  if (lv->owner != current) {
58  spin_lock_local(>lock);
59  LL_WARN(lv->owner);
60  LL_WARN(lv->nestcnt);
61  lv->owner = current;
62  }
63  lv->nestcnt++;

...which seems to be this.

0x811dca80 is in __lru_cache_add (mm/swap.c:397).
392 }
393 EXPORT_SYMBOL(mark_page_accessed);
394
395 static void __lru_cache_add(struct page *page)
396 {
397 struct pagevec *pvec = _locked_var(swapvec_lock, 
lru_add_pvec);
398
399 get_page(page);
400 if (!pagevec_add(pvec, page) || PageCompound(page))
401 __pagevec_lru_add(pvec);

swapvec_lock?  Oodles of 'em?  Nope.

-Mike

Re: [PATCH 3/5] remoteproc: qcom: mdt_loader: Refactor MDT loader

[Bjorn Andersson]

On Wed 08 Feb 02:33 PST 2017, Stanimir Varbanov wrote:

> Hi Bjorn,
> 
> On 01/30/2017 06:55 PM, Bjorn Andersson wrote:
[..]
> > +int qcom_mdt_load(struct device *dev, const struct firmware *fw,
[..]
> > +   size_t offset;
[..]
> > +   for (i = 0; i < ehdr->e_phnum; i++) {
> > +   phdr = [i];
> > +
> > +   if (!mdt_phdr_valid(phdr))
> > continue;
> >  
> > -   ptr = rproc_da_to_va(rproc, phdr->p_paddr, phdr->p_memsz);
> > -   if (!ptr) {
> > -   dev_err(>dev, "segment outside memory range\n");
> > +   offset = phdr->p_paddr - mem_reloc;
> 
> Shouldn't 'offset' variable be of signed type i.e. ssize_t?

It should, as a small "negative" value will wrap back into the
acceptable range of the second part of the check below. I got another
report of this as well yesterday, so I will prepare a patch for this.

> Also p_paddr is of type Elf32_Addr and mem_reloc is of type
> phys_addr_t which on 64bit systems is 64bit long, I think it should be
> better to make mem_reloc of the same type as p_paddr.
> 

If I remember what the C standard says, mem_reloc would in the 64-bit
case have higher "rank" and the type of p_paddr would therefor be
converted to the type of mem_reloc (i.e.  u64) and the result would be
stored in a 64 bit type. But it's been a while and I can't find my C
reference manual right now...

Casting mem_reloc to the type of p_paddr would cause invalid results in
the event that the system is configured to actually load a relocatable
blob into memory above 4GB.

> > +   if (offset < 0 || offset + phdr->p_memsz > mem_size) {
> > +   dev_err(dev, "segment outside memory range\n");
> > ret = -EINVAL;
> > break;
> > }
> >  
> > +   ptr = mem_region + offset;
> > +
> > if (phdr->p_filesz) {
> > sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> > -   ret = request_firmware(_fw, fw_name, >dev);
> > +   ret = request_firmware(_fw, fw_name, dev);
> > if (ret) {
> > -   dev_err(>dev, "failed to load %s\n",
> > -   fw_name);
> > +   dev_err(dev, "failed to load %s\n", fw_name);
> > break;
> > }
> >  
> 

Regards,
Bjorn

Re: [PATCH 3/5] remoteproc: qcom: mdt_loader: Refactor MDT loader

[Bjorn Andersson]

On Wed 08 Feb 02:33 PST 2017, Stanimir Varbanov wrote:

> Hi Bjorn,
> 
> On 01/30/2017 06:55 PM, Bjorn Andersson wrote:
[..]
> > +int qcom_mdt_load(struct device *dev, const struct firmware *fw,
[..]
> > +   size_t offset;
[..]
> > +   for (i = 0; i < ehdr->e_phnum; i++) {
> > +   phdr = [i];
> > +
> > +   if (!mdt_phdr_valid(phdr))
> > continue;
> >  
> > -   ptr = rproc_da_to_va(rproc, phdr->p_paddr, phdr->p_memsz);
> > -   if (!ptr) {
> > -   dev_err(>dev, "segment outside memory range\n");
> > +   offset = phdr->p_paddr - mem_reloc;
> 
> Shouldn't 'offset' variable be of signed type i.e. ssize_t?

It should, as a small "negative" value will wrap back into the
acceptable range of the second part of the check below. I got another
report of this as well yesterday, so I will prepare a patch for this.

> Also p_paddr is of type Elf32_Addr and mem_reloc is of type
> phys_addr_t which on 64bit systems is 64bit long, I think it should be
> better to make mem_reloc of the same type as p_paddr.
> 

If I remember what the C standard says, mem_reloc would in the 64-bit
case have higher "rank" and the type of p_paddr would therefor be
converted to the type of mem_reloc (i.e.  u64) and the result would be
stored in a 64 bit type. But it's been a while and I can't find my C
reference manual right now...

Casting mem_reloc to the type of p_paddr would cause invalid results in
the event that the system is configured to actually load a relocatable
blob into memory above 4GB.

> > +   if (offset < 0 || offset + phdr->p_memsz > mem_size) {
> > +   dev_err(dev, "segment outside memory range\n");
> > ret = -EINVAL;
> > break;
> > }
> >  
> > +   ptr = mem_region + offset;
> > +
> > if (phdr->p_filesz) {
> > sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> > -   ret = request_firmware(_fw, fw_name, >dev);
> > +   ret = request_firmware(_fw, fw_name, dev);
> > if (ret) {
> > -   dev_err(>dev, "failed to load %s\n",
> > -   fw_name);
> > +   dev_err(dev, "failed to load %s\n", fw_name);
> > break;
> > }
> >  
> 

Regards,
Bjorn

[PATCH v7 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

[Baoyou Xie]

This patch adds i2c controller driver for ZTE's zx2967 family.

Signed-off-by: Baoyou Xie 
Reviewed-by: Shawn Guo 
Reviewed-by: Andy Shevchenko 
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-zx2967.c | 667 
 3 files changed, 677 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-zx2967.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e4a603e..d983e36 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1246,4 +1246,13 @@ config I2C_OPAL
  This driver can also be built as a module. If so, the module will be
  called as i2c-opal.
 
+config I2C_ZX2967
+   tristate "ZTE zx2967 I2C support"
+   depends on ARCH_ZX
+   default y
+   help
+ Selecting this option will add ZX2967 I2C driver.
+ This driver can also be built as a module. If so, the module will be
+ called i2c-zx2967.
+
 endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index beb4809..16b2901 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_I2C_XILINX)+= i2c-xiic.o
 obj-$(CONFIG_I2C_XLR)  += i2c-xlr.o
 obj-$(CONFIG_I2C_XLP9XX)   += i2c-xlp9xx.o
 obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_ZX2967)   += i2c-zx2967.o
 
 # External I2C/SMBus adapter drivers
 obj-$(CONFIG_I2C_DIOLAN_U2C)   += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
new file mode 100644
index 000..f136aee
--- /dev/null
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -0,0 +1,667 @@
+/*
+ * ZTE's zx2967 family i2c bus controller driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie 
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_CMD0x04
+#define REG_DEVADDR_H  0x0C
+#define REG_DEVADDR_L  0x10
+#define REG_CLK_DIV_FS 0x14
+#define REG_CLK_DIV_HS 0x18
+#define REG_WRCONF 0x1C
+#define REG_RDCONF 0x20
+#define REG_DATA   0x24
+#define REG_STAT   0x28
+
+#define I2C_STOP   0
+#define I2C_MASTER BIT(0)
+#define I2C_ADDR_MODE_TEN  BIT(1)
+#define I2C_IRQ_MSK_ENABLE BIT(3)
+#define I2C_RW_READBIT(4)
+#define I2C_CMB_RW_EN  BIT(5)
+#define I2C_START  BIT(6)
+
+#define I2C_ADDR_LOW_MASK  GENMASK(6, 0)
+#define I2C_ADDR_LOW_SHIFT 0
+#define I2C_ADDR_HI_MASK   GENMASK(2, 0)
+#define I2C_ADDR_HI_SHIFT  7
+
+#define I2C_WFIFO_RESETBIT(7)
+#define I2C_RFIFO_RESETBIT(7)
+
+#define I2C_IRQ_ACK_CLEAR  BIT(7)
+#define I2C_INT_MASK   GENMASK(6, 0)
+
+#define I2C_TRANS_DONE BIT(0)
+#define I2C_ERROR_DEVICE   BIT(1)
+#define I2C_ERROR_DATA BIT(2)
+#define I2C_ERROR_MASK GENMASK(2, 1)
+
+#define I2C_SR_BUSYBIT(6)
+
+#define I2C_SR_EDEVICE BIT(1)
+#define I2C_SR_EDATA   BIT(2)
+
+#define I2C_FIFO_MAX   16
+
+#define I2C_TIMEOUTmsecs_to_jiffies(1000)
+
+#define DEV(i2c)   (>adap.dev)
+
+struct zx2967_i2c_info {
+   struct i2c_adapter  adap;
+   struct clk  *clk;
+   struct completion   complete;
+   u32 clk_freq;
+   void __iomem*reg_base;
+   size_t  residue;
+   int irq;
+   int msg_rd;
+   u8  *cur_trans;
+   u8  access_cnt;
+   boolis_suspended;
+};
+
+static void zx2967_i2c_writel(struct zx2967_i2c_info *zx_i2c,
+ u32 val, unsigned long reg)
+{
+   writel_relaxed(val, zx_i2c->reg_base + reg);
+}
+
+static u32 zx2967_i2c_readl(struct zx2967_i2c_info *zx_i2c, unsigned long reg)
+{
+   return readl_relaxed(zx_i2c->reg_base + reg);
+}
+
+static void zx2967_i2c_writesb(struct zx2967_i2c_info *zx_i2c,
+  void *data, unsigned long reg, int len)
+{
+   writesb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_readsb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+   readsb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_start_ctrl(struct zx2967_i2c_info *zx_i2c)
+{
+ 

[PATCH v7 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

[Baoyou Xie]

This patch adds i2c controller driver for ZTE's zx2967 family.

Signed-off-by: Baoyou Xie 
Reviewed-by: Shawn Guo 
Reviewed-by: Andy Shevchenko 
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-zx2967.c | 667 
 3 files changed, 677 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-zx2967.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e4a603e..d983e36 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1246,4 +1246,13 @@ config I2C_OPAL
  This driver can also be built as a module. If so, the module will be
  called as i2c-opal.
 
+config I2C_ZX2967
+   tristate "ZTE zx2967 I2C support"
+   depends on ARCH_ZX
+   default y
+   help
+ Selecting this option will add ZX2967 I2C driver.
+ This driver can also be built as a module. If so, the module will be
+ called i2c-zx2967.
+
 endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index beb4809..16b2901 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_I2C_XILINX)+= i2c-xiic.o
 obj-$(CONFIG_I2C_XLR)  += i2c-xlr.o
 obj-$(CONFIG_I2C_XLP9XX)   += i2c-xlp9xx.o
 obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_ZX2967)   += i2c-zx2967.o
 
 # External I2C/SMBus adapter drivers
 obj-$(CONFIG_I2C_DIOLAN_U2C)   += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
new file mode 100644
index 000..f136aee
--- /dev/null
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -0,0 +1,667 @@
+/*
+ * ZTE's zx2967 family i2c bus controller driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie 
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_CMD0x04
+#define REG_DEVADDR_H  0x0C
+#define REG_DEVADDR_L  0x10
+#define REG_CLK_DIV_FS 0x14
+#define REG_CLK_DIV_HS 0x18
+#define REG_WRCONF 0x1C
+#define REG_RDCONF 0x20
+#define REG_DATA   0x24
+#define REG_STAT   0x28
+
+#define I2C_STOP   0
+#define I2C_MASTER BIT(0)
+#define I2C_ADDR_MODE_TEN  BIT(1)
+#define I2C_IRQ_MSK_ENABLE BIT(3)
+#define I2C_RW_READBIT(4)
+#define I2C_CMB_RW_EN  BIT(5)
+#define I2C_START  BIT(6)
+
+#define I2C_ADDR_LOW_MASK  GENMASK(6, 0)
+#define I2C_ADDR_LOW_SHIFT 0
+#define I2C_ADDR_HI_MASK   GENMASK(2, 0)
+#define I2C_ADDR_HI_SHIFT  7
+
+#define I2C_WFIFO_RESETBIT(7)
+#define I2C_RFIFO_RESETBIT(7)
+
+#define I2C_IRQ_ACK_CLEAR  BIT(7)
+#define I2C_INT_MASK   GENMASK(6, 0)
+
+#define I2C_TRANS_DONE BIT(0)
+#define I2C_ERROR_DEVICE   BIT(1)
+#define I2C_ERROR_DATA BIT(2)
+#define I2C_ERROR_MASK GENMASK(2, 1)
+
+#define I2C_SR_BUSYBIT(6)
+
+#define I2C_SR_EDEVICE BIT(1)
+#define I2C_SR_EDATA   BIT(2)
+
+#define I2C_FIFO_MAX   16
+
+#define I2C_TIMEOUTmsecs_to_jiffies(1000)
+
+#define DEV(i2c)   (>adap.dev)
+
+struct zx2967_i2c_info {
+   struct i2c_adapter  adap;
+   struct clk  *clk;
+   struct completion   complete;
+   u32 clk_freq;
+   void __iomem*reg_base;
+   size_t  residue;
+   int irq;
+   int msg_rd;
+   u8  *cur_trans;
+   u8  access_cnt;
+   boolis_suspended;
+};
+
+static void zx2967_i2c_writel(struct zx2967_i2c_info *zx_i2c,
+ u32 val, unsigned long reg)
+{
+   writel_relaxed(val, zx_i2c->reg_base + reg);
+}
+
+static u32 zx2967_i2c_readl(struct zx2967_i2c_info *zx_i2c, unsigned long reg)
+{
+   return readl_relaxed(zx_i2c->reg_base + reg);
+}
+
+static void zx2967_i2c_writesb(struct zx2967_i2c_info *zx_i2c,
+  void *data, unsigned long reg, int len)
+{
+   writesb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_readsb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+   readsb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_start_ctrl(struct zx2967_i2c_info *zx_i2c)
+{
+   u32 status;
+   u32 ctl;
+
+   status = zx2967_i2c_readl(zx_i2c, REG_STAT);
+   

[PATCH v7 2/3] MAINTAINERS: add zx2967 i2c controller driver to ARM ZTE architecture

[Baoyou Xie]

Add the zx2967 i2c controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.

Signed-off-by: Baoyou Xie 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e63063b..313fab5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1987,9 +1987,11 @@ L:   linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: arch/arm/mach-zx/
 F: drivers/clk/zte/
+F: drivers/i2c/busses/i2c-zx2967.c
 F: drivers/soc/zte/
 F: Documentation/devicetree/bindings/arm/zte.txt
 F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
 F: Documentation/devicetree/bindings/soc/zte/
 F: include/dt-bindings/soc/zx*.h
 
-- 
2.7.4

[PATCH v7 2/3] MAINTAINERS: add zx2967 i2c controller driver to ARM ZTE architecture

[Baoyou Xie]

Add the zx2967 i2c controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.

Signed-off-by: Baoyou Xie 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e63063b..313fab5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1987,9 +1987,11 @@ L:   linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: arch/arm/mach-zx/
 F: drivers/clk/zte/
+F: drivers/i2c/busses/i2c-zx2967.c
 F: drivers/soc/zte/
 F: Documentation/devicetree/bindings/arm/zte.txt
 F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
 F: Documentation/devicetree/bindings/soc/zte/
 F: include/dt-bindings/soc/zx*.h
 
-- 
2.7.4

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

[Anton Blanchard]

From: Anton Blanchard 

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently
use the plurals.

Signed-off-by: Anton Blanchard 
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index e0097536..53d7cbb 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2cf8734..e77f0dc 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index d00e368..0732a7f 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y
 CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
 CONFIG_KPROBES_SANITY_TEST=y
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index d503800..d4a06e7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -429,7 +429,7 @@ config BLK_DEV_IO_TRACE
 
  If unsure, say N.
 
-config KPROBE_EVENT
+config KPROBE_EVENTS
depends on KPROBES
depends on HAVE_REGS_AND_STACK_ACCESS_API
bool "Enable kprobes-based dynamic events"
@@ -447,7 +447,7 @@ config KPROBE_EVENT
  This option is also required by perf-probe subcommand of perf tools.
  If you want to use perf tools, this option is strongly recommended.
 
-config UPROBE_EVENT
+config UPROBE_EVENTS
   

[PATCH v7 1/3] dt: bindings: add documentation for zx2967 family i2c controller

[Baoyou Xie]

This patch adds dt-binding documentation for zx2967 family
i2c controller.

Signed-off-by: Baoyou Xie 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-zx2967.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-zx2967.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt 
b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
new file mode 100644
index 000..a528374
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
@@ -0,0 +1,24 @@
+ZTE zx2967 I2C controller
+
+Required properties:
+ - compatible: must be "zte,zx296718-i2c"
+ - reg: physical address and length of the device registers
+ - interrupts: a single interrupt specifier
+ - clocks: clock for the device
+ - #address-cells: should be <1>
+ - #size-cells: should be <0>
+ - clock-frequency: the desired I2C bus clock frequency.
+
+Examples:
+
+   i2c@112000 {
+   compatible = "zte,zx296718-i2c";
+   reg = <0x00112000 0x1000>;
+   interrupts = ;
+   clocks = <>;
+   #address-cells = <1>
+   #size-cells = <0>;
+   clock-frequency = <160>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_global_pin>;
+   };
-- 
2.7.4

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

[Anton Blanchard]

From: Anton Blanchard 

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently
use the plurals.

Signed-off-by: Anton Blanchard 
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index e0097536..53d7cbb 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2cf8734..e77f0dc 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index d00e368..0732a7f 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y
 CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
 CONFIG_KPROBES_SANITY_TEST=y
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index d503800..d4a06e7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -429,7 +429,7 @@ config BLK_DEV_IO_TRACE
 
  If unsure, say N.
 
-config KPROBE_EVENT
+config KPROBE_EVENTS
depends on KPROBES
depends on HAVE_REGS_AND_STACK_ACCESS_API
bool "Enable kprobes-based dynamic events"
@@ -447,7 +447,7 @@ config KPROBE_EVENT
  This option is also required by perf-probe subcommand of perf tools.
  If you want to use perf tools, this option is strongly recommended.
 
-config UPROBE_EVENT
+config UPROBE_EVENTS
bool "Enable uprobes-based 

[PATCH v7 1/3] dt: bindings: add documentation for zx2967 family i2c controller

[Baoyou Xie]

This patch adds dt-binding documentation for zx2967 family
i2c controller.

Signed-off-by: Baoyou Xie 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-zx2967.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-zx2967.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt 
b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
new file mode 100644
index 000..a528374
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
@@ -0,0 +1,24 @@
+ZTE zx2967 I2C controller
+
+Required properties:
+ - compatible: must be "zte,zx296718-i2c"
+ - reg: physical address and length of the device registers
+ - interrupts: a single interrupt specifier
+ - clocks: clock for the device
+ - #address-cells: should be <1>
+ - #size-cells: should be <0>
+ - clock-frequency: the desired I2C bus clock frequency.
+
+Examples:
+
+   i2c@112000 {
+   compatible = "zte,zx296718-i2c";
+   reg = <0x00112000 0x1000>;
+   interrupts = ;
+   clocks = <>;
+   #address-cells = <1>
+   #size-cells = <0>;
+   clock-frequency = <160>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_global_pin>;
+   };
-- 
2.7.4

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

[Anton Blanchard]

Hi Ingo,

> So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
> CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
> CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all
> plural.
> 
> I didn't notice the misnomer when merging these bits.

Ok, patch to follow.

Anton

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

[Anton Blanchard]

Hi Ingo,

> So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
> CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
> CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all
> plural.
> 
> I didn't notice the misnomer when merging these bits.

Ok, patch to follow.

Anton

Re: powerpc/xmon: Fix data-breakpoint

[Michael Ellerman]

On Tue, 2016-11-22 at 09:25:59 UTC, Ravi Bangoria wrote:
> Xmon data-breakpoint feature is broken.
> 
> Whenever there is a watchpoint match occurs, hw_breakpoint_handler will
> be called by do_break via notifier chains mechanism. If watchpoint is
> registered by xmon, hw_breakpoint_handler won't find any associated
> perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break
> also returns without notifying to xmon.
> 
> Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not
> find any perf_event associated with matched watchpoint.
> 
> Signed-off-by: Ravi Bangoria 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c21a493a2b44650707d06741601894

cheers

Re: powerpc/xmon: Fix data-breakpoint

[Michael Ellerman]

On Tue, 2016-11-22 at 09:25:59 UTC, Ravi Bangoria wrote:
> Xmon data-breakpoint feature is broken.
> 
> Whenever there is a watchpoint match occurs, hw_breakpoint_handler will
> be called by do_break via notifier chains mechanism. If watchpoint is
> registered by xmon, hw_breakpoint_handler won't find any associated
> perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break
> also returns without notifying to xmon.
> 
> Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not
> find any perf_event associated with matched watchpoint.
> 
> Signed-off-by: Ravi Bangoria 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c21a493a2b44650707d06741601894

cheers

Re: [PATCH 3.2 000/126] 3.2.85-rc1 review

[Guenter Roeck]

On 02/15/2017 02:41 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.85 release.
There are 126 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb 23 00:00:00 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 89 pass: 89 fail: 0
Qemu test results:
total: 69 pass: 69 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.2 000/126] 3.2.85-rc1 review

[Guenter Roeck]

On 02/15/2017 02:41 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.85 release.
There are 126 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb 23 00:00:00 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 89 pass: 89 fail: 0
Qemu test results:
total: 69 pass: 69 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[PATCH] remoteproc: qcom: mdt_loader: Use signed type for offset

[Bjorn Andersson]

In the transition from using rproc_da_to_va(), the type of the load
offset became unsigned. This causes the subsequent check to let negative
values less than p_memsz + mem_size through and we write outside of the
buffer.

Change the type back to a signed value to catch this.

Fixes: 7f0dd07a9b29 ("remoteproc: qcom: mdt_loader: Refactor MDT loader")
Fixes: e7fd25226295 ("remoteproc: qcom: q6v5: Decouple driver from MDT loader")
Reported-by: Dan Carpenter 
Reported-by: Stanimir Varbanov 
Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/qcom_q6v5_pil.c | 2 +-
 drivers/soc/qcom/mdt_loader.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 26446eb08bd8..8fd697a3cf8f 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -502,7 +502,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
phys_addr_t max_addr = 0;
bool relocate = false;
char seg_name[10];
-   size_t offset;
+   ssize_t offset;
size_t size;
void *ptr;
int ret;
diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 98b2373c3a97..bd63df0d14e0 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -98,7 +98,7 @@ int qcom_mdt_load(struct device *dev, const struct firmware 
*fw,
phys_addr_t min_addr = (phys_addr_t)ULLONG_MAX;
phys_addr_t max_addr = 0;
size_t fw_name_len;
-   size_t offset;
+   ssize_t offset;
char *fw_name;
bool relocate = false;
void *ptr;
-- 
2.11.0

[PATCH] remoteproc: qcom: mdt_loader: Use signed type for offset

[Bjorn Andersson]

In the transition from using rproc_da_to_va(), the type of the load
offset became unsigned. This causes the subsequent check to let negative
values less than p_memsz + mem_size through and we write outside of the
buffer.

Change the type back to a signed value to catch this.

Fixes: 7f0dd07a9b29 ("remoteproc: qcom: mdt_loader: Refactor MDT loader")
Fixes: e7fd25226295 ("remoteproc: qcom: q6v5: Decouple driver from MDT loader")
Reported-by: Dan Carpenter 
Reported-by: Stanimir Varbanov 
Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/qcom_q6v5_pil.c | 2 +-
 drivers/soc/qcom/mdt_loader.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 26446eb08bd8..8fd697a3cf8f 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -502,7 +502,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
phys_addr_t max_addr = 0;
bool relocate = false;
char seg_name[10];
-   size_t offset;
+   ssize_t offset;
size_t size;
void *ptr;
int ret;
diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 98b2373c3a97..bd63df0d14e0 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -98,7 +98,7 @@ int qcom_mdt_load(struct device *dev, const struct firmware 
*fw,
phys_addr_t min_addr = (phys_addr_t)ULLONG_MAX;
phys_addr_t max_addr = 0;
size_t fw_name_len;
-   size_t offset;
+   ssize_t offset;
char *fw_name;
bool relocate = false;
void *ptr;
-- 
2.11.0

[PATCH 15/15] Staging: rtl8192u: ieee80211: ieee80211.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211.h | 61 +++---
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 1bba5170e25a..0d247058bce4 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -329,12 +329,13 @@ typedef struct ieee_param {
 // linux under 2.6.9 release may not support it, so modify it for common use
 #define IEEE80211_DATA_LEN 2304
 /* Maximum size for the MA-UNITDATA primitive, 802.11 standard section
-   6.2.1.1.2.
-
-   The figure in section 7.1.2 suggests a body size of up to 2312
-   bytes is allowed, which is a bit confusing, I suspect this
-   represents the 2304 bytes of real data, plus a possible 8 bytes of
-   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */
+ *   6.2.1.1.2.
+ *
+ *   The figure in section 7.1.2 suggests a body size of up to 2312
+ *   bytes is allowed, which is a bit confusing, I suspect this
+ *   represents the 2304 bytes of real data, plus a possible 8 bytes of
+ *   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro)
+ */
 #define IEEE80211_1ADDR_LEN 10
 #define IEEE80211_2ADDR_LEN 16
 #define IEEE80211_3ADDR_LEN 24
@@ -685,7 +686,8 @@ struct ieee_ibss_seq {
 
 /* NOTE: This data is for statistical purposes; not all hardware provides this
  *   information for frames received.  Not setting these will not cause
- *   any adverse affects. */
+ *   any adverse affects.
+ */
 struct ieee80211_rx_stats {
u32 mac_time[2];
s8 rssi;
@@ -754,7 +756,8 @@ struct ieee80211_rx_stats {
 /* IEEE 802.11 requires that STA supports concurrent reception of at least
  * three fragmented frames. This define can be increased to support more
  * concurrent frames, but it should be noted that each entry can consume about
- * 2 kB of RAM and increasing cache size will slow down frame reassembly. */
+ * 2 kB of RAM and increasing cache size will slow down frame reassembly.
+ */
 #define IEEE80211_FRAG_CACHE_LEN 4
 
 struct ieee80211_frag_entry {
@@ -836,15 +839,15 @@ struct ieee80211_security {
 
 
 /*
- 802.11 data frame from AP
-  ,---.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `---'
-Total: 28-2340 bytes
-*/
+ *  802.11 data frame from AP
+ *   ,---.
+ * Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
+ *   |--|--|-|-|-|--|-|--|
+ * Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
+ *   |  | tion | (BSSID) | | | ence |  data   |  |
+ *   `---'
+ *  Total: 28-2340 bytes
+ */
 
 /* Management Frame Information Element Types */
 enum ieee80211_mfie {
@@ -882,7 +885,8 @@ enum ieee80211_mfie {
 
 /* Minimal header; can be used for passing 802.11 frames with sufficient
  * information to determine what type of underlying data type is actually
- * stored in the data. */
+ * stored in the data.
+ */
 struct rtl_80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
@@ -980,7 +984,8 @@ struct ieee80211_probe_response {
__le16 beacon_interval;
__le16 capability;
/* SSID, supported rates, FH params, DS params,
-* CF params, IBSS params, TIM (if beacon), RSN */
+* CF params, IBSS params, TIM (if beacon), RSN
+*/
struct ieee80211_info_element info_element[0];
 } __packed;
 
@@ -1055,7 +1060,8 @@ typedef union _frameqos {
 /* MAX_RATES_LENGTH needs to be 12.  The spec says 8, and many APs
  * only use 8, and then use extended rates for the remaining supported
  * rates.  Other APs, however, stick all of their supported rates on the
- * main rates information element... */
+ * main rates information element...
+ */
 #define MAX_RATES_LENGTH  ((u8)12)
 #define MAX_RATES_EX_LENGTH   ((u8)16)
 #define MAX_NETWORK_COUNT  128
@@ -1677,14 +1683,16 @@ struct ieee80211_device {
spinlock_t wpax_suitlist_lock;
 
int tx_headroom; /* Set to size of any additional room needed at front
- * of allocated Tx SKBs */
+ * of allocated Tx SKBs
+ */
u32 config;
 
/* 

[PATCH 15/15] Staging: rtl8192u: ieee80211: ieee80211.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211.h | 61 +++---
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 1bba5170e25a..0d247058bce4 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -329,12 +329,13 @@ typedef struct ieee_param {
 // linux under 2.6.9 release may not support it, so modify it for common use
 #define IEEE80211_DATA_LEN 2304
 /* Maximum size for the MA-UNITDATA primitive, 802.11 standard section
-   6.2.1.1.2.
-
-   The figure in section 7.1.2 suggests a body size of up to 2312
-   bytes is allowed, which is a bit confusing, I suspect this
-   represents the 2304 bytes of real data, plus a possible 8 bytes of
-   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */
+ *   6.2.1.1.2.
+ *
+ *   The figure in section 7.1.2 suggests a body size of up to 2312
+ *   bytes is allowed, which is a bit confusing, I suspect this
+ *   represents the 2304 bytes of real data, plus a possible 8 bytes of
+ *   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro)
+ */
 #define IEEE80211_1ADDR_LEN 10
 #define IEEE80211_2ADDR_LEN 16
 #define IEEE80211_3ADDR_LEN 24
@@ -685,7 +686,8 @@ struct ieee_ibss_seq {
 
 /* NOTE: This data is for statistical purposes; not all hardware provides this
  *   information for frames received.  Not setting these will not cause
- *   any adverse affects. */
+ *   any adverse affects.
+ */
 struct ieee80211_rx_stats {
u32 mac_time[2];
s8 rssi;
@@ -754,7 +756,8 @@ struct ieee80211_rx_stats {
 /* IEEE 802.11 requires that STA supports concurrent reception of at least
  * three fragmented frames. This define can be increased to support more
  * concurrent frames, but it should be noted that each entry can consume about
- * 2 kB of RAM and increasing cache size will slow down frame reassembly. */
+ * 2 kB of RAM and increasing cache size will slow down frame reassembly.
+ */
 #define IEEE80211_FRAG_CACHE_LEN 4
 
 struct ieee80211_frag_entry {
@@ -836,15 +839,15 @@ struct ieee80211_security {
 
 
 /*
- 802.11 data frame from AP
-  ,---.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `---'
-Total: 28-2340 bytes
-*/
+ *  802.11 data frame from AP
+ *   ,---.
+ * Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
+ *   |--|--|-|-|-|--|-|--|
+ * Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
+ *   |  | tion | (BSSID) | | | ence |  data   |  |
+ *   `---'
+ *  Total: 28-2340 bytes
+ */
 
 /* Management Frame Information Element Types */
 enum ieee80211_mfie {
@@ -882,7 +885,8 @@ enum ieee80211_mfie {
 
 /* Minimal header; can be used for passing 802.11 frames with sufficient
  * information to determine what type of underlying data type is actually
- * stored in the data. */
+ * stored in the data.
+ */
 struct rtl_80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
@@ -980,7 +984,8 @@ struct ieee80211_probe_response {
__le16 beacon_interval;
__le16 capability;
/* SSID, supported rates, FH params, DS params,
-* CF params, IBSS params, TIM (if beacon), RSN */
+* CF params, IBSS params, TIM (if beacon), RSN
+*/
struct ieee80211_info_element info_element[0];
 } __packed;
 
@@ -1055,7 +1060,8 @@ typedef union _frameqos {
 /* MAX_RATES_LENGTH needs to be 12.  The spec says 8, and many APs
  * only use 8, and then use extended rates for the remaining supported
  * rates.  Other APs, however, stick all of their supported rates on the
- * main rates information element... */
+ * main rates information element...
+ */
 #define MAX_RATES_LENGTH  ((u8)12)
 #define MAX_RATES_EX_LENGTH   ((u8)16)
 #define MAX_NETWORK_COUNT  128
@@ -1677,14 +1683,16 @@ struct ieee80211_device {
spinlock_t wpax_suitlist_lock;
 
int tx_headroom; /* Set to size of any additional room needed at front
- * of allocated Tx SKBs */
+ * of allocated Tx SKBs
+ */
u32 config;
 
/* WEP and other 

[PATCH 14/15] Staging: rtl8192u: ieee80211: ieee80211_rx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 91 +++
 1 file changed, 58 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index d1057b13549d..6bf362b21a27 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -148,7 +148,8 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN);
} else {
/* received a fragment of a frame for which the head fragment
-* should have already been received */
+* should have already been received
+*/
entry = ieee80211_frag_cache_find(ieee, seq, frag, 
tid,hdr->addr2,
  hdr->addr1);
if (entry != NULL) {
@@ -207,7 +208,8 @@ static int ieee80211_frag_cache_invalidate(struct 
ieee80211_device *ieee,
  *
  * Responsible for handling management control frames
  *
- * Called by ieee80211_rx */
+ * Called by ieee80211_rx
+ */
 static inline int
 ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb,
struct ieee80211_rx_stats *rx_stats, u16 type,
@@ -240,8 +242,9 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
   ieee->dev->name);
return 0;
 /*
-  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
-  skb->data);*/
+ *  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
+ *  skb->data);
+ */
}
 
if (ieee->hostapd && type == IEEE80211_TYPE_MGMT) {
@@ -249,14 +252,16 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
ieee->iw_mode == IW_MODE_MASTER) {
struct sk_buff *skb2;
/* Process beacon frames also in kernel driver to
-* update STA(AP) table statistics */
+* update STA(AP) table statistics
+*/
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2)
hostap_rx(skb2->dev, skb2, rx_stats);
}
 
/* send management frames to the user space daemon for
-* processing */
+* processing
+*/
ieee->apdevstats.rx_packets++;
ieee->apdevstats.rx_bytes += skb->len;
prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT);
@@ -554,7 +559,8 @@ void ieee80211_indicate_packets(struct ieee80211_device 
*ieee, struct ieee80211_
  ethertype != ETH_P_AARP && ethertype != 
ETH_P_IPX) ||
 memcmp(sub_skb->data, bridge_tunnel_header, 
SNAP_SIZE) == 0)) {
/* remove RFC1042 or Bridge-Tunnel encapsulation and
-* replace EtherType */
+* replace EtherType
+*/
skb_pull(sub_skb, SNAP_SIZE);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->src, 
ETH_ALEN);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->dst, 
ETH_ALEN);
@@ -885,7 +891,8 @@ static u8 parse_subframe(struct sk_buff *skb,
 
 /* All received frames are sent to this function. @skb contains the frame in
  * IEEE 802.11 format, i.e., in the format it was sent over air.
- * This function is called only as a tasklet (software IRQ). */
+ * This function is called only as a tasklet (software IRQ).
+ */
 int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb,
 struct ieee80211_rx_stats *rx_stats)
 {
@@ -949,7 +956,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
//IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA, skb->data, skb->len);
 #ifdef NOT_YET
/* Put this code here so that we avoid duplicating it in all
-* Rx paths. - Jean II */
+* Rx paths. - Jean II
+*/
 #ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */
/* If spy monitoring on */
if (iface->spy_data.spy_number > 0) {
@@ -984,7 +992,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 * bcrx_sta_key parameter is set, station specific key is used
 * even with broad/multicast targets (this is against IEEE
 * 802.11, but makes it easier to use different keys with
-* stations that do not support WEP key mapping). */
+* stations that do not support WEP key mapping).
+*/
 
if (!(hdr->addr1[0] & 0x01) || 

[PATCH 12/15] Staging: rtl8192u: ieee80211: rtl819x_BA.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
index 2c398ca9a8ac..e61f608718b1 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
@@ -19,12 +19,12 @@
 #defineDELBA_REASON_UNKNOWN_BA 38
 #defineDELBA_REASON_TIMEOUT39
 /*  whether need define BA Action frames here?
-struct ieee80211_ADDBA_Req{
-   struct ieee80211_header_data header;
-   u8  category;
-   u8
-} __attribute__ ((packed));
-*/
+ *struct ieee80211_ADDBA_Req{
+ * struct ieee80211_header_data header;
+ * u8  category;
+ * u8
+ *} __attribute__ ((packed));
+ */
 //Is this need?I put here just to make it easier to define structure BA_RECORD 
//WB
 typedef union _SEQUENCE_CONTROL{
u16 ShortData;
-- 
2.11.1

[PATCH 12/15] Staging: rtl8192u: ieee80211: rtl819x_BA.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
index 2c398ca9a8ac..e61f608718b1 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
@@ -19,12 +19,12 @@
 #defineDELBA_REASON_UNKNOWN_BA 38
 #defineDELBA_REASON_TIMEOUT39
 /*  whether need define BA Action frames here?
-struct ieee80211_ADDBA_Req{
-   struct ieee80211_header_data header;
-   u8  category;
-   u8
-} __attribute__ ((packed));
-*/
+ *struct ieee80211_ADDBA_Req{
+ * struct ieee80211_header_data header;
+ * u8  category;
+ * u8
+ *} __attribute__ ((packed));
+ */
 //Is this need?I put here just to make it easier to define structure BA_RECORD 
//WB
 typedef union _SEQUENCE_CONTROL{
u16 ShortData;
-- 
2.11.1

[PATCH 14/15] Staging: rtl8192u: ieee80211: ieee80211_rx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 91 +++
 1 file changed, 58 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index d1057b13549d..6bf362b21a27 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -148,7 +148,8 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN);
} else {
/* received a fragment of a frame for which the head fragment
-* should have already been received */
+* should have already been received
+*/
entry = ieee80211_frag_cache_find(ieee, seq, frag, 
tid,hdr->addr2,
  hdr->addr1);
if (entry != NULL) {
@@ -207,7 +208,8 @@ static int ieee80211_frag_cache_invalidate(struct 
ieee80211_device *ieee,
  *
  * Responsible for handling management control frames
  *
- * Called by ieee80211_rx */
+ * Called by ieee80211_rx
+ */
 static inline int
 ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb,
struct ieee80211_rx_stats *rx_stats, u16 type,
@@ -240,8 +242,9 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
   ieee->dev->name);
return 0;
 /*
-  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
-  skb->data);*/
+ *  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
+ *  skb->data);
+ */
}
 
if (ieee->hostapd && type == IEEE80211_TYPE_MGMT) {
@@ -249,14 +252,16 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
ieee->iw_mode == IW_MODE_MASTER) {
struct sk_buff *skb2;
/* Process beacon frames also in kernel driver to
-* update STA(AP) table statistics */
+* update STA(AP) table statistics
+*/
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2)
hostap_rx(skb2->dev, skb2, rx_stats);
}
 
/* send management frames to the user space daemon for
-* processing */
+* processing
+*/
ieee->apdevstats.rx_packets++;
ieee->apdevstats.rx_bytes += skb->len;
prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT);
@@ -554,7 +559,8 @@ void ieee80211_indicate_packets(struct ieee80211_device 
*ieee, struct ieee80211_
  ethertype != ETH_P_AARP && ethertype != 
ETH_P_IPX) ||
 memcmp(sub_skb->data, bridge_tunnel_header, 
SNAP_SIZE) == 0)) {
/* remove RFC1042 or Bridge-Tunnel encapsulation and
-* replace EtherType */
+* replace EtherType
+*/
skb_pull(sub_skb, SNAP_SIZE);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->src, 
ETH_ALEN);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->dst, 
ETH_ALEN);
@@ -885,7 +891,8 @@ static u8 parse_subframe(struct sk_buff *skb,
 
 /* All received frames are sent to this function. @skb contains the frame in
  * IEEE 802.11 format, i.e., in the format it was sent over air.
- * This function is called only as a tasklet (software IRQ). */
+ * This function is called only as a tasklet (software IRQ).
+ */
 int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb,
 struct ieee80211_rx_stats *rx_stats)
 {
@@ -949,7 +956,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
//IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA, skb->data, skb->len);
 #ifdef NOT_YET
/* Put this code here so that we avoid duplicating it in all
-* Rx paths. - Jean II */
+* Rx paths. - Jean II
+*/
 #ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */
/* If spy monitoring on */
if (iface->spy_data.spy_number > 0) {
@@ -984,7 +992,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 * bcrx_sta_key parameter is set, station specific key is used
 * even with broad/multicast targets (this is against IEEE
 * 802.11, but makes it easier to use different keys with
-* stations that do not support WEP key mapping). */
+* stations that do not support WEP key mapping).
+*/
 
if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key)
  

[PATCH 13/15] Staging: rtl8192u: ieee80211: ieee80211_tx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 290 +++---
 1 file changed, 150 insertions(+), 140 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index 949c496084fd..5704e4d7aa68 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -1,35 +1,34 @@
 /**
-
-  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License as
-  published by the Free Software Foundation.
-
-  This program is distributed in the hope that it will be useful, but WITHOUT
-  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-  more details.
-
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-**
-
-  Few modifications for Realtek's Wi-Fi drivers by
-  Andrea Merello 
-
-  A special thanks goes to Realtek for their support !
-
-**/
+ *
+ *  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ *  more details.
+ *
+ *  You should have received a copy of the GNU General Public License along 
with
+ *  this program; if not, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ *
+ *  Few modifications for Realtek's Wi-Fi drivers by
+ *  Andrea Merello 
+ *
+ *  A special thanks goes to Realtek for their support !
+ *
+ 
**/
 
 #include 
 #include 
@@ -55,101 +54,101 @@
 
 
 /*
-
-
-802.11 Data Frame
-
-
-802.11 frame_contorl for data frames - 2 bytes
- 
,-.
-bits | 0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  a  |  b  |  
c  |  d  |  e   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-val  | 0  |  0  |  0  |  1  |  x  |  0  |  0  |  0  |  1  |  0  |  x  |  x  |  
x  |  x  |  x   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-desc | ^-ver-^  |  ^type-^  |  ^-subtype-^  | to  |from |more |retry| 
pwr |more |wep   |
- |  |   | x=0 data,x=1 data+ack | DS  | DS  |frag | | 
mgm |data |  |
- 
'-'
-/\
-|
-802.11 Data Frame   |
-   ,- 'ctrl' expands to >---'
-  |
-  ,--'---,-.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  Frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `--| |--'
-Total: 28 non-data bytes `.'
-  |
-   .- 'Frame data' expands to 

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject software mce to reproduce it.
> Please give me your exact steps so that I can try to reproduce it here
> too.
>

Hi Borislav,

I tried to use qemu to inject SRAO("mce -b 0 0 0xb100 0x5 0x0 0x0"),
it works well in 1st kernel, but it doesn't work for 1st kernel after kdump 
boots(seems
the cpus remain in 1st kernel don't respond to the simulated broadcasting mce).

But in theory, we know cpus belong to kdump kernel can't respond to the
old mce handler, so a single SRAO injection in 1st kernel should be similar.
For example, I used "... -smp 2 -cpu Haswell" to launch a simulation with 
broadcast
mce supported, and inject SRAO to cpu0 only through qemu monitor
"mce 0 0 0xb100 0x5 0x0 0x0", cpu0 will timeout/panic and reboot
the machine as follows(running on linux-4.9):
  Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception 
handler
  Kernel Offset: disabled
  Rebooting in 30 seconds..

Regards,
Xunlei

[PATCH 13/15] Staging: rtl8192u: ieee80211: ieee80211_tx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 290 +++---
 1 file changed, 150 insertions(+), 140 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index 949c496084fd..5704e4d7aa68 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -1,35 +1,34 @@
 /**
-
-  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License as
-  published by the Free Software Foundation.
-
-  This program is distributed in the hope that it will be useful, but WITHOUT
-  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-  more details.
-
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-**
-
-  Few modifications for Realtek's Wi-Fi drivers by
-  Andrea Merello 
-
-  A special thanks goes to Realtek for their support !
-
-**/
+ *
+ *  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ *  more details.
+ *
+ *  You should have received a copy of the GNU General Public License along 
with
+ *  this program; if not, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ *
+ *  Few modifications for Realtek's Wi-Fi drivers by
+ *  Andrea Merello 
+ *
+ *  A special thanks goes to Realtek for their support !
+ *
+ 
**/
 
 #include 
 #include 
@@ -55,101 +54,101 @@
 
 
 /*
-
-
-802.11 Data Frame
-
-
-802.11 frame_contorl for data frames - 2 bytes
- 
,-.
-bits | 0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  a  |  b  |  
c  |  d  |  e   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-val  | 0  |  0  |  0  |  1  |  x  |  0  |  0  |  0  |  1  |  0  |  x  |  x  |  
x  |  x  |  x   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-desc | ^-ver-^  |  ^type-^  |  ^-subtype-^  | to  |from |more |retry| 
pwr |more |wep   |
- |  |   | x=0 data,x=1 data+ack | DS  | DS  |frag | | 
mgm |data |  |
- 
'-'
-/\
-|
-802.11 Data Frame   |
-   ,- 'ctrl' expands to >---'
-  |
-  ,--'---,-.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  Frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `--| |--'
-Total: 28 non-data bytes `.'
-  |
-   .- 'Frame data' expands to <---'
-   |
-   V
-  ,---.
-Bytes |  1   |  1   |1| 

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject software mce to reproduce it.
> Please give me your exact steps so that I can try to reproduce it here
> too.
>

Hi Borislav,

I tried to use qemu to inject SRAO("mce -b 0 0 0xb100 0x5 0x0 0x0"),
it works well in 1st kernel, but it doesn't work for 1st kernel after kdump 
boots(seems
the cpus remain in 1st kernel don't respond to the simulated broadcasting mce).

But in theory, we know cpus belong to kdump kernel can't respond to the
old mce handler, so a single SRAO injection in 1st kernel should be similar.
For example, I used "... -smp 2 -cpu Haswell" to launch a simulation with 
broadcast
mce supported, and inject SRAO to cpu0 only through qemu monitor
"mce 0 0 0xb100 0x5 0x0 0x0", cpu0 will timeout/panic and reboot
the machine as follows(running on linux-4.9):
  Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception 
handler
  Kernel Offset: disabled
  Rebooting in 30 seconds..

Regards,
Xunlei

[PATCH 11/15] Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 69 +
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
index c3aabbaac7ae..d270c8ac807c 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
@@ -86,38 +86,38 @@ typedef enum _CHNLOP{
((_pHTInfo)->ChnlOp > CHNLOP_NONE) ? TRUE : FALSE
 
 /*
-typedefunion _HT_CAPABILITY{
-   u16 ShortData;
-   u8  CharData[2];
-   struct
-   {
-   u16 AdvCoding:1;
-   u16 ChlWidth:1;
-   u16 MimoPwrSave:2;
-   u16 GreenField:1;
-   u16 ShortGI20Mhz:1;
-   u16 ShortGI40Mhz:1;
-   u16 STBC:1;
-   u16 BeamForm:1;
-   u16 DelayBA:1;
-   u16 MaxAMSDUSize:1;
-   u16 DssCCk:1;
-   u16 PSMP:1;
-   u16 Rsvd:3;
-   }Field;
-}HT_CAPABILITY, *PHT_CAPABILITY;
-
-typedefunion _HT_CAPABILITY_MACPARA{
-   u8  ShortData;
-   u8  CharData[1];
-   struct
-   {
-   u8  MaxRxAMPDU:2;
-   u8  MPDUDensity:2;
-   u8  Rsvd:4;
-   }Field;
-}HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
-*/
+ * typedef union _HT_CAPABILITY{
+ * u16 ShortData;
+ * u8  CharData[2];
+ * struct
+ * {
+ * u16 AdvCoding:1;
+ * u16 ChlWidth:1;
+ * u16 MimoPwrSave:2;
+ * u16 GreenField:1;
+ * u16 ShortGI20Mhz:1;
+ * u16 ShortGI40Mhz:1;
+ * u16 STBC:1;
+ * u16 BeamForm:1;
+ * u16 DelayBA:1;
+ * u16 MaxAMSDUSize:1;
+ * u16 DssCCk:1;
+ * u16 PSMP:1;
+ * u16 Rsvd:3;
+ * }Field;
+ * }HT_CAPABILITY, *PHT_CAPABILITY;
+ *
+ * typedef union _HT_CAPABILITY_MACPARA{
+ * u8  ShortData;
+ * u8  CharData[1];
+ * struct
+ * {
+ * u8  MaxRxAMPDU:2;
+ * u8  MPDUDensity:2;
+ * u8  Rsvd:4;
+ * }Field;
+ * }HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
+ */
 
 typedef enum _HT_ACTION{
ACT_RECOMMAND_WIDTH = 0,
@@ -421,8 +421,9 @@ extern u8 MCS_FILTER_ALL[16];
 extern u8 MCS_FILTER_1SS[16];
 
 /* 2007/07/11 MH Modify the macro. Becaus STA may link with a N-AP. If we set
-   STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
-   to add a macro to judge wireless mode. */
+ * STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
+ * to add a macro to judge wireless mode.
+ */
 #define PICK_RATE(_nLegacyRate, _nMcsRate) \
(_nMcsRate==0)?(_nLegacyRate&0x7f):(_nMcsRate)
 /* 2007/07/12 MH We only define legacy and HT wireless mode now. */
-- 
2.11.1

[PATCH 11/15] Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 69 +
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
index c3aabbaac7ae..d270c8ac807c 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
@@ -86,38 +86,38 @@ typedef enum _CHNLOP{
((_pHTInfo)->ChnlOp > CHNLOP_NONE) ? TRUE : FALSE
 
 /*
-typedefunion _HT_CAPABILITY{
-   u16 ShortData;
-   u8  CharData[2];
-   struct
-   {
-   u16 AdvCoding:1;
-   u16 ChlWidth:1;
-   u16 MimoPwrSave:2;
-   u16 GreenField:1;
-   u16 ShortGI20Mhz:1;
-   u16 ShortGI40Mhz:1;
-   u16 STBC:1;
-   u16 BeamForm:1;
-   u16 DelayBA:1;
-   u16 MaxAMSDUSize:1;
-   u16 DssCCk:1;
-   u16 PSMP:1;
-   u16 Rsvd:3;
-   }Field;
-}HT_CAPABILITY, *PHT_CAPABILITY;
-
-typedefunion _HT_CAPABILITY_MACPARA{
-   u8  ShortData;
-   u8  CharData[1];
-   struct
-   {
-   u8  MaxRxAMPDU:2;
-   u8  MPDUDensity:2;
-   u8  Rsvd:4;
-   }Field;
-}HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
-*/
+ * typedef union _HT_CAPABILITY{
+ * u16 ShortData;
+ * u8  CharData[2];
+ * struct
+ * {
+ * u16 AdvCoding:1;
+ * u16 ChlWidth:1;
+ * u16 MimoPwrSave:2;
+ * u16 GreenField:1;
+ * u16 ShortGI20Mhz:1;
+ * u16 ShortGI40Mhz:1;
+ * u16 STBC:1;
+ * u16 BeamForm:1;
+ * u16 DelayBA:1;
+ * u16 MaxAMSDUSize:1;
+ * u16 DssCCk:1;
+ * u16 PSMP:1;
+ * u16 Rsvd:3;
+ * }Field;
+ * }HT_CAPABILITY, *PHT_CAPABILITY;
+ *
+ * typedef union _HT_CAPABILITY_MACPARA{
+ * u8  ShortData;
+ * u8  CharData[1];
+ * struct
+ * {
+ * u8  MaxRxAMPDU:2;
+ * u8  MPDUDensity:2;
+ * u8  Rsvd:4;
+ * }Field;
+ * }HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
+ */
 
 typedef enum _HT_ACTION{
ACT_RECOMMAND_WIDTH = 0,
@@ -421,8 +421,9 @@ extern u8 MCS_FILTER_ALL[16];
 extern u8 MCS_FILTER_1SS[16];
 
 /* 2007/07/11 MH Modify the macro. Becaus STA may link with a N-AP. If we set
-   STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
-   to add a macro to judge wireless mode. */
+ * STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
+ * to add a macro to judge wireless mode.
+ */
 #define PICK_RATE(_nLegacyRate, _nMcsRate) \
(_nMcsRate==0)?(_nLegacyRate&0x7f):(_nMcsRate)
 /* 2007/07/12 MH We only define legacy and HT wireless mode now. */
-- 
2.11.1

[PATCH 08/15] Staging: rtl8192u: ieee80211: ieee80211_module.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index a9a92d8e6ab0..5fdfff0816c5 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -1,34 +1,34 @@
 
/***
-
-  Copyright(c) 2004 Intel Corporation. All rights reserved.
-
-  Portions of this file are based on the WEP enablement code provided by the
-  Host AP project hostap-drivers v0.1.3
-  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
-  
-  Copyright (c) 2002-2003, Jouni Malinen 
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License as
-  published by the Free Software Foundation.
-
-  This program is distributed in the hope that it will be useful, but WITHOUT
-  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-  more details.
-
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-***/
+ *
+ *  Copyright(c) 2004 Intel Corporation. All rights reserved.
+ *
+ *  Portions of this file are based on the WEP enablement code provided by the
+ *  Host AP project hostap-drivers v0.1.3
+ *  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ *  
+ *  Copyright (c) 2002-2003, Jouni Malinen 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ *  more details.
+ *
+ *  You should have received a copy of the GNU General Public License along 
with
+ *  this program; if not, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ 
***/
 
 #include 
 /* #include  */
-- 
2.11.1

[PATCH 08/15] Staging: rtl8192u: ieee80211: ieee80211_module.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index a9a92d8e6ab0..5fdfff0816c5 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -1,34 +1,34 @@
 
/***
-
-  Copyright(c) 2004 Intel Corporation. All rights reserved.
-
-  Portions of this file are based on the WEP enablement code provided by the
-  Host AP project hostap-drivers v0.1.3
-  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
-  
-  Copyright (c) 2002-2003, Jouni Malinen 
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License as
-  published by the Free Software Foundation.
-
-  This program is distributed in the hope that it will be useful, but WITHOUT
-  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-  more details.
-
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-***/
+ *
+ *  Copyright(c) 2004 Intel Corporation. All rights reserved.
+ *
+ *  Portions of this file are based on the WEP enablement code provided by the
+ *  Host AP project hostap-drivers v0.1.3
+ *  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ *  
+ *  Copyright (c) 2002-2003, Jouni Malinen 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ *  more details.
+ *
+ *  You should have received a copy of the GNU General Public License along 
with
+ *  this program; if not, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ 
***/
 
 #include 
 /* #include  */
-- 
2.11.1

Re: [PATCH] uio: add UIO_MEM_CUSTOM support

[Xiubo Li]

For example, the TCMU will use the map area as ISCSI commands & data ring
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.

Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring
buffer
area(about 1.5G).

The following code is in uio_mmap() in uio.c:

if (idev->info->mmap) {
ret = idev->info->mmap(idev->info, vma);
return ret;


Yes, just missed this return.

}

switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
return uio_mmap_physical(vma);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
default:
return -EINVAL;
}

We already have the equivalent of a CUSTOM memtype because TCMU sets the
info->mmap fn, overriding uio's default handling choices in favor of its
own.

HTH -- Regards -- Andy

[PATCH 10/15] Staging: rtl8192u: ieee80211: rtl819x_BAProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 51503ee0dce7..6619b8fb9700 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -14,7 +14,7 @@
  *   input:  PBA_RECORDpBA  //BA entry to be enabled
  *  u16Time //indicate time delay.
  *  output:  none
-/
+ 
/
 static void ActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA, u16 
Time)
 {
pBA->bValid = true;
@@ -26,7 +26,7 @@ static void ActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA, u16 T
  *function:  deactivate BA entry, including its timer.
  *   input:  PBA_RECORDpBA  //BA entry to be disabled
  *  output:  none
-/
+ 
/
 static void DeActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -38,7 +38,7 @@ static void DeActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA)
  *  PTX_TS_RECORD  pTxTs //Tx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PTX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME
-/
+ 
/
 static u8 TxTsDeleteBA(struct ieee80211_device *ieee, PTX_TS_RECORD pTxTs)
 {
PBA_RECORD  pAdmittedBa = >TxAdmittedBARecord;  
//These two BA entries must exist in TS structure
@@ -66,7 +66,7 @@ static u8 TxTsDeleteBA(struct ieee80211_device *ieee, 
PTX_TS_RECORD pTxTs)
  *  PRX_TS_RECORD  pRxTs //Rx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PRX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME, same with above
-/
+ 
/
 static u8 RxTsDeleteBA(struct ieee80211_device *ieee, PRX_TS_RECORD pRxTs)
 {
PBA_RECORD  pBa = >RxAdmittedBARecord;
@@ -85,7 +85,7 @@ static u8 RxTsDeleteBA(struct ieee80211_device *ieee, 
PRX_TS_RECORD pRxTs)
  *   input:
  *  PBA_RECORD pBA //entry to be reset
  *  output:  none
-/
+ 
/
 void ResetBaEntry(PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -103,7 +103,7 @@ void ResetBaEntry(PBA_RECORD pBA)
  *  u8 type//indicate whether it's 
RSP(ACT_ADDBARSP) ow REQ(ACT_ADDBAREQ)
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-***/
+ 
***/
 static struct sk_buff *ieee80211_ADDBA(struct ieee80211_device *ieee, u8 *Dst, 
PBA_RECORD pBA, u16 StatusCode, u8 type)
 {
struct sk_buff *skb = NULL;
@@ -177,7 +177,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
  *  u16ReasonCode  //status code.
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-/
+ 
/
 static struct sk_buff *ieee80211_DELBA(
struct ieee80211_device  *ieee,
u8   *dst,
@@ -242,7 +242,7 @@ static struct sk_buff *ieee80211_DELBA(
  *  PBA_RECORD pBA //BA_RECORD 

[PATCH 09/15] Staging: rtl8192u: ieee80211: rtl819x_HTProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 164 ++---
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index c27397b14adb..9e8ed8c2e21e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -217,8 +217,8 @@ void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString)
 }
 
 /*
-*  Return: true if station in half n mode and AP supports 40 bw
-*/
+ * Return: true if station in half n mode and AP supports 40 bw
+ */
 static bool IsHTHalfNmode40Bandwidth(struct ieee80211_device *ieee)
 {
boolretValue = false;
@@ -412,7 +412,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device 
*ieee)
  *  u8 *   PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should declare MCS13 only(otherwise return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableMCS14(struct ieee80211_device *ieee, u8 
*PeerMacAddr)
 {
return 0;
@@ -420,17 +420,17 @@ static u8 HTIOTActIsDisableMCS14(struct ieee80211_device 
*ieee, u8 *PeerMacAddr)
 
 
 /**
-* Function:HTIOTActIsDisableMCS15
-*
-* Overview:Check whether driver should declare capability of receiving 
MCS15
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable MCS15
-* 2008.04.15   Emily
-*/
+ * Function:   HTIOTActIsDisableMCS15
+ *
+ * Overview:   Check whether driver should declare capability of receiving 
MCS15
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable MCS15
+ * 2008.04.15  Emily
+ */
 static bool HTIOTActIsDisableMCS15(struct ieee80211_device *ieee)
 {
bool retValue = false;
@@ -457,17 +457,17 @@ static bool HTIOTActIsDisableMCS15(struct 
ieee80211_device *ieee)
 }
 
 /**
-* Function:HTIOTActIsDisableMCSTwoSpatialStream
-*
-* Overview:Check whether driver should declare capability of receiving All 
2 ss packets
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable all two spatial stream packet
-* 2008.04.21   Emily
-*/
+ * Function:   HTIOTActIsDisableMCSTwoSpatialStream
+ *
+ * Overview:   Check whether driver should declare capability of receiving All 
2 ss packets
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable all two spatial stream packet
+ * 2008.04.21  Emily
+ */
 static bool HTIOTActIsDisableMCSTwoSpatialStream(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {
@@ -483,7 +483,7 @@ static bool HTIOTActIsDisableMCSTwoSpatialStream(struct 
ieee80211_device *ieee,
  *  u8*PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should disable EDCA turbo mode(otherwise 
return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableEDCATurbo(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {  /* default enable EDCA Turbo mode. */
@@ -495,7 +495,7 @@ static u8 HTIOTActIsDisableEDCATurbo(struct 
ieee80211_device *ieee,
  *   input:  struct ieee80211_network *network   //current network we live
  *  output:  none
  *  return:  return 1 if true
-  * 
*/
+ 
*/
 static u8 HTIOTActIsMgntUseCCK6M(struct ieee80211_network *network)
 {
u8  retValue = 0;
@@ -542,7 +542,7 @@ void HTResetIOTSetting(
  *  output:  none
  *  return:  none
  *  notice:  posHTCap can't be null and should be initialized before.
-  * 
*/
+ 
**/
 void HTConstructCapabilityElement(struct ieee80211_device *ieee, u8 *posHTCap, 
u8 *len, u8 IsEncrypt)
 {
PRT_HIGH_THROUGHPUT 

Re: [PATCH] uio: add UIO_MEM_CUSTOM support

[Xiubo Li]

For example, the TCMU will use the map area as ISCSI commands & data ring
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.

Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring
buffer
area(about 1.5G).

The following code is in uio_mmap() in uio.c:

if (idev->info->mmap) {
ret = idev->info->mmap(idev->info, vma);
return ret;


Yes, just missed this return.

}

switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
return uio_mmap_physical(vma);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
default:
return -EINVAL;
}

We already have the equivalent of a CUSTOM memtype because TCMU sets the
info->mmap fn, overriding uio's default handling choices in favor of its
own.

HTH -- Regards -- Andy

[PATCH 10/15] Staging: rtl8192u: ieee80211: rtl819x_BAProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 51503ee0dce7..6619b8fb9700 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -14,7 +14,7 @@
  *   input:  PBA_RECORDpBA  //BA entry to be enabled
  *  u16Time //indicate time delay.
  *  output:  none
-/
+ 
/
 static void ActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA, u16 
Time)
 {
pBA->bValid = true;
@@ -26,7 +26,7 @@ static void ActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA, u16 T
  *function:  deactivate BA entry, including its timer.
  *   input:  PBA_RECORDpBA  //BA entry to be disabled
  *  output:  none
-/
+ 
/
 static void DeActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -38,7 +38,7 @@ static void DeActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA)
  *  PTX_TS_RECORD  pTxTs //Tx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PTX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME
-/
+ 
/
 static u8 TxTsDeleteBA(struct ieee80211_device *ieee, PTX_TS_RECORD pTxTs)
 {
PBA_RECORD  pAdmittedBa = >TxAdmittedBARecord;  
//These two BA entries must exist in TS structure
@@ -66,7 +66,7 @@ static u8 TxTsDeleteBA(struct ieee80211_device *ieee, 
PTX_TS_RECORD pTxTs)
  *  PRX_TS_RECORD  pRxTs //Rx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PRX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME, same with above
-/
+ 
/
 static u8 RxTsDeleteBA(struct ieee80211_device *ieee, PRX_TS_RECORD pRxTs)
 {
PBA_RECORD  pBa = >RxAdmittedBARecord;
@@ -85,7 +85,7 @@ static u8 RxTsDeleteBA(struct ieee80211_device *ieee, 
PRX_TS_RECORD pRxTs)
  *   input:
  *  PBA_RECORD pBA //entry to be reset
  *  output:  none
-/
+ 
/
 void ResetBaEntry(PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -103,7 +103,7 @@ void ResetBaEntry(PBA_RECORD pBA)
  *  u8 type//indicate whether it's 
RSP(ACT_ADDBARSP) ow REQ(ACT_ADDBAREQ)
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-***/
+ 
***/
 static struct sk_buff *ieee80211_ADDBA(struct ieee80211_device *ieee, u8 *Dst, 
PBA_RECORD pBA, u16 StatusCode, u8 type)
 {
struct sk_buff *skb = NULL;
@@ -177,7 +177,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
  *  u16ReasonCode  //status code.
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-/
+ 
/
 static struct sk_buff *ieee80211_DELBA(
struct ieee80211_device  *ieee,
u8   *dst,
@@ -242,7 +242,7 @@ static struct sk_buff *ieee80211_DELBA(
  *  PBA_RECORD pBA //BA_RECORD entry which stores the 

[PATCH 09/15] Staging: rtl8192u: ieee80211: rtl819x_HTProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 164 ++---
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index c27397b14adb..9e8ed8c2e21e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -217,8 +217,8 @@ void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString)
 }
 
 /*
-*  Return: true if station in half n mode and AP supports 40 bw
-*/
+ * Return: true if station in half n mode and AP supports 40 bw
+ */
 static bool IsHTHalfNmode40Bandwidth(struct ieee80211_device *ieee)
 {
boolretValue = false;
@@ -412,7 +412,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device 
*ieee)
  *  u8 *   PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should declare MCS13 only(otherwise return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableMCS14(struct ieee80211_device *ieee, u8 
*PeerMacAddr)
 {
return 0;
@@ -420,17 +420,17 @@ static u8 HTIOTActIsDisableMCS14(struct ieee80211_device 
*ieee, u8 *PeerMacAddr)
 
 
 /**
-* Function:HTIOTActIsDisableMCS15
-*
-* Overview:Check whether driver should declare capability of receiving 
MCS15
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable MCS15
-* 2008.04.15   Emily
-*/
+ * Function:   HTIOTActIsDisableMCS15
+ *
+ * Overview:   Check whether driver should declare capability of receiving 
MCS15
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable MCS15
+ * 2008.04.15  Emily
+ */
 static bool HTIOTActIsDisableMCS15(struct ieee80211_device *ieee)
 {
bool retValue = false;
@@ -457,17 +457,17 @@ static bool HTIOTActIsDisableMCS15(struct 
ieee80211_device *ieee)
 }
 
 /**
-* Function:HTIOTActIsDisableMCSTwoSpatialStream
-*
-* Overview:Check whether driver should declare capability of receiving All 
2 ss packets
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable all two spatial stream packet
-* 2008.04.21   Emily
-*/
+ * Function:   HTIOTActIsDisableMCSTwoSpatialStream
+ *
+ * Overview:   Check whether driver should declare capability of receiving All 
2 ss packets
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable all two spatial stream packet
+ * 2008.04.21  Emily
+ */
 static bool HTIOTActIsDisableMCSTwoSpatialStream(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {
@@ -483,7 +483,7 @@ static bool HTIOTActIsDisableMCSTwoSpatialStream(struct 
ieee80211_device *ieee,
  *  u8*PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should disable EDCA turbo mode(otherwise 
return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableEDCATurbo(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {  /* default enable EDCA Turbo mode. */
@@ -495,7 +495,7 @@ static u8 HTIOTActIsDisableEDCATurbo(struct 
ieee80211_device *ieee,
  *   input:  struct ieee80211_network *network   //current network we live
  *  output:  none
  *  return:  return 1 if true
-  * 
*/
+ 
*/
 static u8 HTIOTActIsMgntUseCCK6M(struct ieee80211_network *network)
 {
u8  retValue = 0;
@@ -542,7 +542,7 @@ void HTResetIOTSetting(
  *  output:  none
  *  return:  none
  *  notice:  posHTCap can't be null and should be initialized before.
-  * 
*/
+ 
**/
 void HTConstructCapabilityElement(struct ieee80211_device *ieee, u8 *posHTCap, 
u8 *len, u8 IsEncrypt)
 {
PRT_HIGH_THROUGHPUT pHT = 

[PATCH 04/15] Staging: rtl8192u: r8192U_core.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_core.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index d8dea0337de8..b631990b4969 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -503,8 +503,7 @@ static void watch_dog_timer_callback(unsigned long data);
 
 /
  *   -PROCFS STUFF-
-*
- */
+ /
 
 static struct proc_dir_entry *rtl8192_proc;
 
@@ -715,8 +714,8 @@ static void rtl8192_proc_remove_one(struct net_device *dev)
 }
 
 /
-   -MISC STUFF-
-*/
+ *  -MISC STUFF-
+ */
 
 short check_nic_enough_desc(struct net_device *dev, int queue_index)
 {
@@ -1328,7 +1327,7 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb)
  * 2006.10.30 by Emily
  *
  * \param QUEUEID   Software Queue
-*/
+ */
 static u8 MapHwQueueToFirmwareQueue(u8 QueueID)
 {
u8 QueueSelect = 0x0;   /* default set to */
@@ -1499,7 +1498,7 @@ static void tx_zero_isr(struct urb *tx_urb)
  * The tx procedure is just as following,
  * skb->cb will contain all the following information,
  * priority, morefrag, rate, 
- * */
+ */
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -1840,8 +1839,8 @@ static void rtl8192_update_beacon(struct work_struct 
*work)
 }
 
 /*
-* background support to run QoS activate functionality
-*/
+ * background support to run QoS activate functionality
+ */
 static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK,
 EDCAPARA_VI, EDCAPARA_VO};
 static void rtl8192_qos_activate(struct work_struct *work)
@@ -1946,10 +1945,10 @@ static int rtl8192_handle_beacon(struct net_device *dev,
 }
 
 /*
-* handling the beaconing responses. if we get different QoS setting
-* off the network from the associated setting, adjust the QoS
-* setting
-*/
+ * handling the beaconing responses. if we get different QoS setting
+ * off the network from the associated setting, adjust the QoS
+ * setting
+ */
 static int rtl8192_qos_association_resp(struct r8192_priv *priv,
struct ieee80211_network *network)
 {
@@ -3045,8 +3044,8 @@ static bool rtl8192_adapter_start(struct net_device *dev)
  * be used to stop beacon transmission
  */
 /***
----NET STUFF---
-***/
+ *   ---NET STUFF---
+ ***/
 
 static struct net_device_stats *rtl8192_stats(struct net_device *dev)
 {
@@ -3074,9 +3073,9 @@ static bool HalTxCheckStuck819xUsb(struct net_device *dev)
 }
 
 /*
-*  
-*  First added: 2006.11.19 by emily
-*/
+ * 
+ * First added: 2006.11.19 by emily
+ */
 static RESET_TYPE TxCheckStuck(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -4156,7 +4155,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
  * Output: NONE
  *
  * Return: 0-100 percentage
- *---*/
+ *---
+ */
 static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
 {
if ((antpower <= -100) || (antpower >= 20))
@@ -4529,19 +4529,19 @@ static void TranslateRxSignalStuff819xUsb(struct 
sk_buff *skb,
 }
 
 /**
-* Function:UpdateReceivedRateHistogramStatistics
-* Overview:Record the received data rate
-*
-* Input:
-*  struct net_device *dev
-*  struct ieee80211_rx_stats *stats
-*
-* Output:
-*
-*  (priv->stats.ReceivedRateHistogram[] is updated)
-* Return:
-*  None
-*/
+ * Function:   UpdateReceivedRateHistogramStatistics
+ * Overview:   Record the received data rate
+ *
+ * Input:
+ * struct net_device *dev
+ * struct ieee80211_rx_stats *stats
+ *
+ * Output:
+ *
+ * (priv->stats.ReceivedRateHistogram[] is updated)

[PATCH 04/15] Staging: rtl8192u: r8192U_core.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_core.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index d8dea0337de8..b631990b4969 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -503,8 +503,7 @@ static void watch_dog_timer_callback(unsigned long data);
 
 /
  *   -PROCFS STUFF-
-*
- */
+ /
 
 static struct proc_dir_entry *rtl8192_proc;
 
@@ -715,8 +714,8 @@ static void rtl8192_proc_remove_one(struct net_device *dev)
 }
 
 /
-   -MISC STUFF-
-*/
+ *  -MISC STUFF-
+ */
 
 short check_nic_enough_desc(struct net_device *dev, int queue_index)
 {
@@ -1328,7 +1327,7 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb)
  * 2006.10.30 by Emily
  *
  * \param QUEUEID   Software Queue
-*/
+ */
 static u8 MapHwQueueToFirmwareQueue(u8 QueueID)
 {
u8 QueueSelect = 0x0;   /* default set to */
@@ -1499,7 +1498,7 @@ static void tx_zero_isr(struct urb *tx_urb)
  * The tx procedure is just as following,
  * skb->cb will contain all the following information,
  * priority, morefrag, rate, 
- * */
+ */
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -1840,8 +1839,8 @@ static void rtl8192_update_beacon(struct work_struct 
*work)
 }
 
 /*
-* background support to run QoS activate functionality
-*/
+ * background support to run QoS activate functionality
+ */
 static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK,
 EDCAPARA_VI, EDCAPARA_VO};
 static void rtl8192_qos_activate(struct work_struct *work)
@@ -1946,10 +1945,10 @@ static int rtl8192_handle_beacon(struct net_device *dev,
 }
 
 /*
-* handling the beaconing responses. if we get different QoS setting
-* off the network from the associated setting, adjust the QoS
-* setting
-*/
+ * handling the beaconing responses. if we get different QoS setting
+ * off the network from the associated setting, adjust the QoS
+ * setting
+ */
 static int rtl8192_qos_association_resp(struct r8192_priv *priv,
struct ieee80211_network *network)
 {
@@ -3045,8 +3044,8 @@ static bool rtl8192_adapter_start(struct net_device *dev)
  * be used to stop beacon transmission
  */
 /***
----NET STUFF---
-***/
+ *   ---NET STUFF---
+ ***/
 
 static struct net_device_stats *rtl8192_stats(struct net_device *dev)
 {
@@ -3074,9 +3073,9 @@ static bool HalTxCheckStuck819xUsb(struct net_device *dev)
 }
 
 /*
-*  
-*  First added: 2006.11.19 by emily
-*/
+ * 
+ * First added: 2006.11.19 by emily
+ */
 static RESET_TYPE TxCheckStuck(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -4156,7 +4155,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
  * Output: NONE
  *
  * Return: 0-100 percentage
- *---*/
+ *---
+ */
 static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
 {
if ((antpower <= -100) || (antpower >= 20))
@@ -4529,19 +4529,19 @@ static void TranslateRxSignalStuff819xUsb(struct 
sk_buff *skb,
 }
 
 /**
-* Function:UpdateReceivedRateHistogramStatistics
-* Overview:Record the received data rate
-*
-* Input:
-*  struct net_device *dev
-*  struct ieee80211_rx_stats *stats
-*
-* Output:
-*
-*  (priv->stats.ReceivedRateHistogram[] is updated)
-* Return:
-*  None
-*/
+ * Function:   UpdateReceivedRateHistogramStatistics
+ * Overview:   Record the received data rate
+ *
+ * Input:
+ * struct net_device *dev
+ * struct ieee80211_rx_stats *stats
+ *
+ * Output:
+ *
+ * (priv->stats.ReceivedRateHistogram[] is updated)
+ * Return:
+ * 

[PATCH 07/15] Staging: rtl8192u: ieee80211: ieee80211_softmac.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 71 +++---
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 1bff0e91cc0c..58df6910584c 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -204,14 +204,14 @@ static u8 MgntQuery_MgntFrameTxRate(struct 
ieee80211_device *ieee)
}
 
/*
-   // Data rate of ProbeReq is already decided. Annie, 2005-03-31
-   if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
-   {
-   if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
-   rate = 0x0c;
-   else
-   rate = 0x02;
-   }
+*  //Data rate of ProbeReq is already decided. Annie, 2005-03-31
+* if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
+* {
+* if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
+* rate = 0x0c;
+* else
+* rate = 0x02;
+* }
 */
return rate;
 }
@@ -272,10 +272,10 @@ inline void softmac_mgmt_xmit(struct sk_buff *skb, struct 
ieee80211_device *ieee

if(!ieee->check_nic_enough_desc(ieee->dev,tcb_desc->queue_index)||\

(skb_queue_len(>skb_waitQ[tcb_desc->queue_index]) != 0)||\
(ieee->queue_stop) ) {
-   /* insert the skb packet to the management queue */
-   /* as for the completion function, it does not need
+   /* insert the skb packet to the management queue
+* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
printk("%s():insert to waitqueue!\n",__func__);
skb_queue_tail(>skb_waitQ[tcb_desc->queue_index], 
skb);
} else {
@@ -1460,8 +1460,8 @@ inline void ieee80211_softmac_new_net(struct 
ieee80211_device *ieee, struct ieee
(!apset && ssidset && ssidbroad && ssidmatch)
){
/* if the essid is hidden replace it with the
-   * essid provided by the user.
-   */
+* essid provided by the user.
+*/
if (!ssidbroad) {
strncpy(tmp_ssid, 
ieee->current_network.ssid, IW_ESSID_MAX_SIZE);
tmp_ssid_len = 
ieee->current_network.ssid_len;
@@ -1731,11 +1731,10 @@ static short ieee80211_sta_ps_sleep(struct 
ieee80211_device *ieee, u32 *time_h,
int timeout = ieee->ps_timeout;
u8 dtim;
/*if(ieee->ps == IEEE80211_PS_DISABLED ||
-   ieee->iw_mode != IW_MODE_INFRA ||
-   ieee->state != IEEE80211_LINKED)
-
-   return 0;
-   */
+*  ieee->iw_mode != IW_MODE_INFRA ||
+*  ieee->state != IEEE80211_LINKED)
+*  return 0;
+*/
dtim = ieee->current_network.dtim_data;
if(!(dtim & IEEE80211_DTIM_VALID))
return 0;
@@ -2097,8 +2096,8 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee, 
struct sk_buff *skb,
case IEEE80211_STYPE_DISASSOC:
case IEEE80211_STYPE_DEAUTH:
/* FIXME for now repeat all the association procedure
-   * both for disassociation and deauthentication
-   */
+* both for disassociation and deauthentication
+*/
if ((ieee->softmac_features & IEEE_SOFTMAC_ASSOCIATE) &&
ieee->state == IEEE80211_LINKED &&
ieee->iw_mode == IW_MODE_INFRA){
@@ -2173,7 +2172,7 @@ void ieee80211_softmac_xmit(struct ieee80211_txb *txb, 
struct ieee80211_device *
/* insert the skb packet to the wait queue */
/* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
//printk("error:no descriptor left@queue_index %d\n", 
queue_index);
//ieee80211_stop_queue(ieee);
 #ifdef USB_TX_DRIVER_AGGREGATION_ENABLE
@@ -2522,18 +2521,18 @@ static void ieee80211_associate_retry_wq(struct 
work_struct *work)
goto exit;
 
/* until we do not set the state to IEEE80211_NOLINK
-   * there are no possibility to have someone else trying
-   * to start an association procedure (we get here with
-   * 

[PATCH 06/15] Staging: rtl8192u: ieee80211: rtl819x_TSProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index b9ff8fec2edf..b4c13fff2c65 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -21,7 +21,7 @@ static void TsInactTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void RxPktPendingTimeout(unsigned long data)
 {
PRX_TS_RECORD   pRxTs = (PRX_TS_RECORD)data;
@@ -95,7 +95,7 @@ static void RxPktPendingTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void TsAddBaProcess(unsigned long data)
 {
PTX_TS_RECORD   pTxTs = (PTX_TS_RECORD)data;
-- 
2.11.1

[PATCH 07/15] Staging: rtl8192u: ieee80211: ieee80211_softmac.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 71 +++---
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 1bff0e91cc0c..58df6910584c 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -204,14 +204,14 @@ static u8 MgntQuery_MgntFrameTxRate(struct 
ieee80211_device *ieee)
}
 
/*
-   // Data rate of ProbeReq is already decided. Annie, 2005-03-31
-   if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
-   {
-   if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
-   rate = 0x0c;
-   else
-   rate = 0x02;
-   }
+*  //Data rate of ProbeReq is already decided. Annie, 2005-03-31
+* if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
+* {
+* if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
+* rate = 0x0c;
+* else
+* rate = 0x02;
+* }
 */
return rate;
 }
@@ -272,10 +272,10 @@ inline void softmac_mgmt_xmit(struct sk_buff *skb, struct 
ieee80211_device *ieee

if(!ieee->check_nic_enough_desc(ieee->dev,tcb_desc->queue_index)||\

(skb_queue_len(>skb_waitQ[tcb_desc->queue_index]) != 0)||\
(ieee->queue_stop) ) {
-   /* insert the skb packet to the management queue */
-   /* as for the completion function, it does not need
+   /* insert the skb packet to the management queue
+* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
printk("%s():insert to waitqueue!\n",__func__);
skb_queue_tail(>skb_waitQ[tcb_desc->queue_index], 
skb);
} else {
@@ -1460,8 +1460,8 @@ inline void ieee80211_softmac_new_net(struct 
ieee80211_device *ieee, struct ieee
(!apset && ssidset && ssidbroad && ssidmatch)
){
/* if the essid is hidden replace it with the
-   * essid provided by the user.
-   */
+* essid provided by the user.
+*/
if (!ssidbroad) {
strncpy(tmp_ssid, 
ieee->current_network.ssid, IW_ESSID_MAX_SIZE);
tmp_ssid_len = 
ieee->current_network.ssid_len;
@@ -1731,11 +1731,10 @@ static short ieee80211_sta_ps_sleep(struct 
ieee80211_device *ieee, u32 *time_h,
int timeout = ieee->ps_timeout;
u8 dtim;
/*if(ieee->ps == IEEE80211_PS_DISABLED ||
-   ieee->iw_mode != IW_MODE_INFRA ||
-   ieee->state != IEEE80211_LINKED)
-
-   return 0;
-   */
+*  ieee->iw_mode != IW_MODE_INFRA ||
+*  ieee->state != IEEE80211_LINKED)
+*  return 0;
+*/
dtim = ieee->current_network.dtim_data;
if(!(dtim & IEEE80211_DTIM_VALID))
return 0;
@@ -2097,8 +2096,8 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee, 
struct sk_buff *skb,
case IEEE80211_STYPE_DISASSOC:
case IEEE80211_STYPE_DEAUTH:
/* FIXME for now repeat all the association procedure
-   * both for disassociation and deauthentication
-   */
+* both for disassociation and deauthentication
+*/
if ((ieee->softmac_features & IEEE_SOFTMAC_ASSOCIATE) &&
ieee->state == IEEE80211_LINKED &&
ieee->iw_mode == IW_MODE_INFRA){
@@ -2173,7 +2172,7 @@ void ieee80211_softmac_xmit(struct ieee80211_txb *txb, 
struct ieee80211_device *
/* insert the skb packet to the wait queue */
/* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
//printk("error:no descriptor left@queue_index %d\n", 
queue_index);
//ieee80211_stop_queue(ieee);
 #ifdef USB_TX_DRIVER_AGGREGATION_ENABLE
@@ -2522,18 +2521,18 @@ static void ieee80211_associate_retry_wq(struct 
work_struct *work)
goto exit;
 
/* until we do not set the state to IEEE80211_NOLINK
-   * there are no possibility to have someone else trying
-   * to start an association procedure (we get here with
-   * ieee->state = 

[PATCH 06/15] Staging: rtl8192u: ieee80211: rtl819x_TSProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index b9ff8fec2edf..b4c13fff2c65 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -21,7 +21,7 @@ static void TsInactTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void RxPktPendingTimeout(unsigned long data)
 {
PRX_TS_RECORD   pRxTs = (PRX_TS_RECORD)data;
@@ -95,7 +95,7 @@ static void RxPktPendingTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void TsAddBaProcess(unsigned long data)
 {
PTX_TS_RECORD   pTxTs = (PTX_TS_RECORD)data;
-- 
2.11.1

[PATCH 05/15] Staging: rtl8192u: r8192U.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U.h | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04ea0910..a7ba8f37384e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -626,7 +626,8 @@ typedef struct Stats {
long signal_quality;
long last_signal_strength_inpercent;
/* Correct smoothed ss in dbm, only used in driver
-* to report real power now */
+* to report real power now
+*/
long recv_signal_power;
u8 rx_rssi_percentage[4];
u8 rx_evm_percentage[2];
@@ -672,32 +673,40 @@ typedef struct _BB_REGISTER_DEFINITION {
/* Tx gain stage:   0x80c~0x80f [4 bytes]  */
u32 rfTxGainStage;
/* wire parameter control1: 0x820~0x823, 0x828~0x82b,
-*  0x830~0x833, 0x838~0x83b [16 bytes] */
+*  0x830~0x833, 0x838~0x83b [16 bytes]
+*/
u32 rfHSSIPara1;
/* wire parameter control2: 0x824~0x827, 0x82c~0x82f,
-*  0x834~0x837, 0x83c~0x83f [16 bytes] */
+*  0x834~0x837, 0x83c~0x83f [16 bytes]
+*/
u32 rfHSSIPara2;
/* Tx Rx antenna control:   0x858~0x85f [16 bytes] */
u32 rfSwitchControl;
/* AGC parameter control1:  0xc50~0xc53, 0xc58~0xc5b,
-*  0xc60~0xc63, 0xc68~0xc6b [16 bytes] */
+*  0xc60~0xc63, 0xc68~0xc6b [16 bytes]
+*/
u32 rfAGCControl1;
/* AGC parameter control2:  0xc54~0xc57, 0xc5c~0xc5f,
-*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes] */
+*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes]
+*/
u32 rfAGCControl2;
/* OFDM Rx IQ imbalance matrix: 0xc14~0xc17, 0xc1c~0xc1f,
-*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes] */
+*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes]
+*/
u32 rfRxIQImbalance;
/* Rx IQ DC offset and Rx digital filter, Rx DC notch filter:
 *  0xc10~0xc13, 0xc18~0xc1b,
-*  0xc20~0xc23, 0xc28~0xc2b [16 bytes] */
+*  0xc20~0xc23, 0xc28~0xc2b [16 bytes]
+*/
u32 rfRxAFE;
/* OFDM Tx IQ imbalance matrix: 0xc80~0xc83, 0xc88~0xc8b,
-*  0xc90~0xc93, 0xc98~0xc9b [16 bytes] */
+*  0xc90~0xc93, 0xc98~0xc9b [16 bytes]
+*/
u32 rfTxIQImbalance;
/* Tx IQ DC Offset and Tx DFIR type:
 *  0xc84~0xc87, 0xc8c~0xc8f,
-*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes] */
+*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes]
+*/
u32 rfTxAFE;
/* LSSI RF readback data:   0x8a0~0x8af [16 bytes] */
u32 rfLSSIReadBack;
@@ -776,7 +785,8 @@ typedef struct _phy_ofdm_rx_status_report_819xusb {
 typedef struct _phy_cck_rx_status_report_819xusb {
/* For CCK rate descriptor. This is an unsigned 8:1 variable.
 * LSB bit presend 0.5. And MSB 7 bts presend a signed value.
-* Range from -64~+63.5. */
+* Range from -64~+63.5.
+*/
u8  adc_pwdb_X[4];
u8  sq_rpt;
u8  cck_agc_rpt;
@@ -991,7 +1001,8 @@ typedef struct r8192_priv {
/* Control channel sub-carrier */
u8  nCur40MhzPrimeSC;
/* Test for shorten RF configuration time.
-* We save RF reg0 in this variable to reduce RF reading. */
+* We save RF reg0 in this variable to reduce RF reading.
+*/
u32 RfReg0Value[4];
u8  NumTotalRFPath;
boolbrfpath_rxenable[4];
@@ -1009,11 +1020,13 @@ typedef struct r8192_priv {
 
boolbstore_last_dtpflag;
/* Define to discriminate on High power State or
-* on sitesurvey to change Tx gain index */
+* on sitesurvey to change Tx gain index
+*/
boolbstart_txctrl_bydtp;
rate_adaptive rate_adaptive;
/* TX power tracking
-* OPEN/CLOSE TX POWER TRACKING */
+* OPEN/CLOSE TX POWER TRACKING
+*/
txbbgain_struct txbbgain_table[TxBBGainTableLength];
u8  txpower_count; /* For 6 sec do tracking again */
boolbtxpower_trackingInit;
-- 
2.11.1

[PATCH 05/15] Staging: rtl8192u: r8192U.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U.h | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04ea0910..a7ba8f37384e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -626,7 +626,8 @@ typedef struct Stats {
long signal_quality;
long last_signal_strength_inpercent;
/* Correct smoothed ss in dbm, only used in driver
-* to report real power now */
+* to report real power now
+*/
long recv_signal_power;
u8 rx_rssi_percentage[4];
u8 rx_evm_percentage[2];
@@ -672,32 +673,40 @@ typedef struct _BB_REGISTER_DEFINITION {
/* Tx gain stage:   0x80c~0x80f [4 bytes]  */
u32 rfTxGainStage;
/* wire parameter control1: 0x820~0x823, 0x828~0x82b,
-*  0x830~0x833, 0x838~0x83b [16 bytes] */
+*  0x830~0x833, 0x838~0x83b [16 bytes]
+*/
u32 rfHSSIPara1;
/* wire parameter control2: 0x824~0x827, 0x82c~0x82f,
-*  0x834~0x837, 0x83c~0x83f [16 bytes] */
+*  0x834~0x837, 0x83c~0x83f [16 bytes]
+*/
u32 rfHSSIPara2;
/* Tx Rx antenna control:   0x858~0x85f [16 bytes] */
u32 rfSwitchControl;
/* AGC parameter control1:  0xc50~0xc53, 0xc58~0xc5b,
-*  0xc60~0xc63, 0xc68~0xc6b [16 bytes] */
+*  0xc60~0xc63, 0xc68~0xc6b [16 bytes]
+*/
u32 rfAGCControl1;
/* AGC parameter control2:  0xc54~0xc57, 0xc5c~0xc5f,
-*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes] */
+*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes]
+*/
u32 rfAGCControl2;
/* OFDM Rx IQ imbalance matrix: 0xc14~0xc17, 0xc1c~0xc1f,
-*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes] */
+*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes]
+*/
u32 rfRxIQImbalance;
/* Rx IQ DC offset and Rx digital filter, Rx DC notch filter:
 *  0xc10~0xc13, 0xc18~0xc1b,
-*  0xc20~0xc23, 0xc28~0xc2b [16 bytes] */
+*  0xc20~0xc23, 0xc28~0xc2b [16 bytes]
+*/
u32 rfRxAFE;
/* OFDM Tx IQ imbalance matrix: 0xc80~0xc83, 0xc88~0xc8b,
-*  0xc90~0xc93, 0xc98~0xc9b [16 bytes] */
+*  0xc90~0xc93, 0xc98~0xc9b [16 bytes]
+*/
u32 rfTxIQImbalance;
/* Tx IQ DC Offset and Tx DFIR type:
 *  0xc84~0xc87, 0xc8c~0xc8f,
-*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes] */
+*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes]
+*/
u32 rfTxAFE;
/* LSSI RF readback data:   0x8a0~0x8af [16 bytes] */
u32 rfLSSIReadBack;
@@ -776,7 +785,8 @@ typedef struct _phy_ofdm_rx_status_report_819xusb {
 typedef struct _phy_cck_rx_status_report_819xusb {
/* For CCK rate descriptor. This is an unsigned 8:1 variable.
 * LSB bit presend 0.5. And MSB 7 bts presend a signed value.
-* Range from -64~+63.5. */
+* Range from -64~+63.5.
+*/
u8  adc_pwdb_X[4];
u8  sq_rpt;
u8  cck_agc_rpt;
@@ -991,7 +1001,8 @@ typedef struct r8192_priv {
/* Control channel sub-carrier */
u8  nCur40MhzPrimeSC;
/* Test for shorten RF configuration time.
-* We save RF reg0 in this variable to reduce RF reading. */
+* We save RF reg0 in this variable to reduce RF reading.
+*/
u32 RfReg0Value[4];
u8  NumTotalRFPath;
boolbrfpath_rxenable[4];
@@ -1009,11 +1020,13 @@ typedef struct r8192_priv {
 
boolbstore_last_dtpflag;
/* Define to discriminate on High power State or
-* on sitesurvey to change Tx gain index */
+* on sitesurvey to change Tx gain index
+*/
boolbstart_txctrl_bydtp;
rate_adaptive rate_adaptive;
/* TX power tracking
-* OPEN/CLOSE TX POWER TRACKING */
+* OPEN/CLOSE TX POWER TRACKING
+*/
txbbgain_struct txbbgain_table[TxBBGainTableLength];
u8  txpower_count; /* For 6 sec do tracking again */
boolbtxpower_trackingInit;
-- 
2.11.1

[PATCH 03/15] Staging: rtl8192u: r8192U_dm.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 175 +++
 1 file changed, 97 insertions(+), 78 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 9209aad0515e..9f05280e557b 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -1,18 +1,18 @@
-/*++
-Copyright-c Realtek Semiconductor Corp. All rights reserved.
-
-Module Name:
-   r8192U_dm.c
-
-Abstract:
-   HW dynamic mechanism.
-
-Major Change History:
-   WhenWho What
-   --  --- ---
-   2008-05-14  amy create version 0 porting from 
windows code.
-
---*/
+/*
+ * Copyright-c Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Module Name:
+ *  r8192U_dm.c
+ *
+ * Abstract:
+ * HW dynamic mechanism.
+ *
+ * Major Change History:
+ * WhenWho What
+ * --  --- ---
+ * 2008-05-14  amy create version 0 porting from 
windows code.
+ *
+ */
 #include "r8192U.h"
 #include "r8192U_dm.h"
 #include "r8192U_hw.h"
@@ -158,20 +158,20 @@ void dm_CheckRxAggregation(struct net_device *dev)
unsigned long   curRxOkCnt = 0;
 
 /*
-   if (pHalData->bForcedUsbRxAggr) {
-   if (pHalData->ForcedUsbRxAggrInfo == 0) {
-   if (pHalData->bCurrentRxAggrEnable) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
-   }
-   } else {
-   if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
-   }
-   }
-   return;
-   }
-
-*/
+ * if (pHalData->bForcedUsbRxAggr) {
+ * if (pHalData->ForcedUsbRxAggrInfo == 0) {
+ * if (pHalData->bCurrentRxAggrEnable) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
+ * }
+ * } else {
+ * if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
+ * }
+ * }
+ * return;
+ * }
+ *
+ */
curTxOkCnt = priv->stats.txbytesunicast - lastTxOkCnt;
curRxOkCnt = priv->stats.rxbytesunicast - lastRxOkCnt;
 
@@ -293,7 +293,8 @@ void init_rate_adaptive(struct net_device *dev)
  * WhenWho Remark
  * 05/26/08amy Create version 0 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void dm_check_rate_adaptive(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -347,9 +348,10 @@ static void dm_check_rate_adaptive(struct net_device *dev)
((bshort_gi_enabled) ? BIT(31) : 0);
 
/* 2007/10/08 MH We support RA smooth scheme now. When it is 
the first
-  time to link with AP. We will not change upper/lower 
threshold. If
-  STA stay in high or low level, we must change two different 
threshold
-  to prevent jumping frequently. */
+* time to link with AP. We will not change upper/lower 
threshold. If
+* STA stay in high or low level, we must change two different 
threshold
+* to prevent jumping frequently.
+*/
if (pra->ratr_state == DM_RATR_STA_HIGH) {
HighRSSIThreshForRA = 
pra->high2low_rssi_thresh_for_ra;
LowRSSIThreshForRA  = (priv->CurrentChannelBW != 
HT_CHANNEL_WIDTH_20) ?
@@ -391,7 +393,8 @@ static void dm_check_rate_adaptive(struct net_device *dev)
ping_rssi_state = 1;
}
/*else
-   DbgPrint("TestRSSI is between the 
range.\n");*/
+*  DbgPrint("TestRSSI is between the 
range.\n");
+*/
} else {
/*DbgPrint("TestRSSI Recover to 0x%x\n", 
targetRATR);*/
ping_rssi_state = 0;
@@ -732,8 +735,9 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)

[PATCH 03/15] Staging: rtl8192u: r8192U_dm.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 175 +++
 1 file changed, 97 insertions(+), 78 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 9209aad0515e..9f05280e557b 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -1,18 +1,18 @@
-/*++
-Copyright-c Realtek Semiconductor Corp. All rights reserved.
-
-Module Name:
-   r8192U_dm.c
-
-Abstract:
-   HW dynamic mechanism.
-
-Major Change History:
-   WhenWho What
-   --  --- ---
-   2008-05-14  amy create version 0 porting from 
windows code.
-
---*/
+/*
+ * Copyright-c Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Module Name:
+ *  r8192U_dm.c
+ *
+ * Abstract:
+ * HW dynamic mechanism.
+ *
+ * Major Change History:
+ * WhenWho What
+ * --  --- ---
+ * 2008-05-14  amy create version 0 porting from 
windows code.
+ *
+ */
 #include "r8192U.h"
 #include "r8192U_dm.h"
 #include "r8192U_hw.h"
@@ -158,20 +158,20 @@ void dm_CheckRxAggregation(struct net_device *dev)
unsigned long   curRxOkCnt = 0;
 
 /*
-   if (pHalData->bForcedUsbRxAggr) {
-   if (pHalData->ForcedUsbRxAggrInfo == 0) {
-   if (pHalData->bCurrentRxAggrEnable) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
-   }
-   } else {
-   if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
-   }
-   }
-   return;
-   }
-
-*/
+ * if (pHalData->bForcedUsbRxAggr) {
+ * if (pHalData->ForcedUsbRxAggrInfo == 0) {
+ * if (pHalData->bCurrentRxAggrEnable) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
+ * }
+ * } else {
+ * if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
+ * }
+ * }
+ * return;
+ * }
+ *
+ */
curTxOkCnt = priv->stats.txbytesunicast - lastTxOkCnt;
curRxOkCnt = priv->stats.rxbytesunicast - lastRxOkCnt;
 
@@ -293,7 +293,8 @@ void init_rate_adaptive(struct net_device *dev)
  * WhenWho Remark
  * 05/26/08amy Create version 0 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void dm_check_rate_adaptive(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -347,9 +348,10 @@ static void dm_check_rate_adaptive(struct net_device *dev)
((bshort_gi_enabled) ? BIT(31) : 0);
 
/* 2007/10/08 MH We support RA smooth scheme now. When it is 
the first
-  time to link with AP. We will not change upper/lower 
threshold. If
-  STA stay in high or low level, we must change two different 
threshold
-  to prevent jumping frequently. */
+* time to link with AP. We will not change upper/lower 
threshold. If
+* STA stay in high or low level, we must change two different 
threshold
+* to prevent jumping frequently.
+*/
if (pra->ratr_state == DM_RATR_STA_HIGH) {
HighRSSIThreshForRA = 
pra->high2low_rssi_thresh_for_ra;
LowRSSIThreshForRA  = (priv->CurrentChannelBW != 
HT_CHANNEL_WIDTH_20) ?
@@ -391,7 +393,8 @@ static void dm_check_rate_adaptive(struct net_device *dev)
ping_rssi_state = 1;
}
/*else
-   DbgPrint("TestRSSI is between the 
range.\n");*/
+*  DbgPrint("TestRSSI is between the 
range.\n");
+*/
} else {
/*DbgPrint("TestRSSI Recover to 0x%x\n", 
targetRATR);*/
ping_rssi_state = 0;
@@ -732,8 +735,9 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
tmpCCK40Mindex = 0;
   

[PATCH 01/15] Staging: rtl8192u: ieee80211: ieee80211_wx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 87 ---
 1 file changed, 47 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 563d7fed6e1c..0d24158e038a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -1,34 +1,34 @@
 /**
-
-  Copyright(c) 2004 Intel Corporation. All rights reserved.
-
-  Portions of this file are based on the WEP enablement code provided by the
-  Host AP project hostap-drivers v0.1.3
-  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
-  
-  Copyright (c) 2002-2003, Jouni Malinen 
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License as
-  published by the Free Software Foundation.
-
-  This program is distributed in the hope that it will be useful, but WITHOUT
-  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-  more details.
-
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-**/
+ *
+ *  Copyright(c) 2004 Intel Corporation. All rights reserved.
+ *
+ *  Portions of this file are based on the WEP enablement code provided by the
+ *  Host AP project hostap-drivers v0.1.3
+ *  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ *  
+ *  Copyright (c) 2002-2003, Jouni Malinen 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ *  more details.
+ *
+ *  You should have received a copy of the GNU General Public License along 
with
+ *  this program; if not, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ 
**/
 #include 
 #include 
 #include 
@@ -108,7 +108,8 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
/* Add frequency/channel */
iwe.cmd = SIOCGIWFREQ;
 /* iwe.u.freq.m = ieee80211_frequency(network->channel, network->mode);
-   iwe.u.freq.e = 3; */
+ * iwe.u.freq.e = 3;
+ */
iwe.u.freq.m = network->channel;
iwe.u.freq.e = 0;
iwe.u.freq.i = 0;
@@ -227,7 +228,8 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
 
 
/* Add EXTRA: Age to display seconds since last beacon/probe response
-* for given network. */
+* for given network.
+*/
iwe.cmd = IWEVCUSTOM;
p = custom;
p += snprintf(p, MAX_CUSTOM_LEN - (p - custom),
@@ -325,7 +327,8 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
IEEE80211_DEBUG_WX("Disabling encryption.\n");
 
/* Check all the keys to see if any are still configured,
-* and if no key index was provided, de-init them all */
+* and if no key index was provided, de-init them all
+*/
for (i = 0; i < WEP_KEYS; i++) {
if (ieee->crypt[i] != NULL) {
if (key_provided)
@@ -352,7 +355,8 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
if (*crypt != NULL && (*crypt)->ops != NULL &&
strcmp((*crypt)->ops->name, "WEP") != 0) {
/* changing to use WEP; deinit previously used algorithm
-* on this key */
+

[PATCH 00/15] Staging: rtl8192u - fixed block comments

[Derek Robson]

Fixed style of block comments across all of the rtl8192u driver
This driver has a lot of code commented out that could be deleted, I have not 
changed that.

This is a new series as only some of the 25 set sent last week got applied.

Derek Robson (15):
  Staging: rtl8192u: ieee80211: ieee80211_wx.c - style fix
  Staging: rtl8192u: r819xU_cmdpkt.c - style fix
  Staging: rtl8192u: r8192U_dm.c - style fix
  Staging: rtl8192u: r8192U_core.c - style fix
  Staging: rtl8192u: r8192U.h - style fix
  Staging: rtl8192u: ieee80211: rtl819x_TSProc.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_softmac.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_module.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_HTProc.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_BAProc.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix
  Staging: rtl8192u: ieee80211: rtl819x_BA.h - style fix
  Staging: rtl8192u: ieee80211: ieee80211_tx.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_rx.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211.h - style fix

 drivers/staging/rtl8192u/ieee80211/ieee80211.h |  61 +++--
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  |  60 ++---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c  |  91 ---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c |  71 ++---
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c  | 290 +++--
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c  |  87 ---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h|  12 +-
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c|  28 +-
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h|  69 ++---
 .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 164 ++--
 .../staging/rtl8192u/ieee80211/rtl819x_TSProc.c|   4 +-
 drivers/staging/rtl8192u/r8192U.h  |  39 ++-
 drivers/staging/rtl8192u/r8192U_core.c |  70 ++---
 drivers/staging/rtl8192u/r8192U_dm.c   | 175 +++--
 drivers/staging/rtl8192u/r819xU_cmdpkt.c   |  82 +++---
 15 files changed, 706 insertions(+), 597 deletions(-)

-- 
2.11.1