Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

2018-08-31 Thread Dan Carpenter
On Thu, Aug 30, 2018 at 10:35:37PM +0100, John Whitmore wrote:
> On Thu, Aug 30, 2018 at 11:26:28AM +0300, Dan Carpenter wrote:
> > On Thu, Aug 30, 2018 at 11:23:05AM +0300, Dan Carpenter wrote:
> > > On Wed, Aug 29, 2018 at 09:35:27PM +0100, John Whitmore wrote:
> > > > Rename the bit field element AdvCoding, as it causes a checkpatch issue
> > > > with CamelCase naming. As the element is not actually used in code it
> > > > has been renamed to 'not_used_adv_coding'.
> > > > 
> > > > The single line of code which initialises the bit has been removed,
> > > > as the  field is unused.
> > > > 
> > > > This is a purely coding style change which should have no impact
> > > > on runtime code execution.
> > > > 
> > > > Signed-off-by: John Whitmore 
> > > > ---
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 +-
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 1 -
> > > >  2 files changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
> > > > b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > index 64d5359cf7e2..66a0274077d3 100644
> > > > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > @@ -39,7 +39,7 @@ enum ht_extension_chan_offset {
> > > >  
> > > >  struct ht_capability_ele {
> > > > //HT capability info
> > > > -   u8  AdvCoding:1;
> > > > +   u8  not_used_adv_coding:1;
> > > 
> > > I can't review any more of this patchset when this is the first line...
> > > 
> > 
> > That email wasn't very clear.  If you think some of your patches are
> > going to be more controversial than others, put them at the very end so
> > we can at least apply part of the patchset.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Thanks for the clarification, I needed it ;)
> 
> I'm not sure I consider any of the patches in the series as being
> controversial. They are all just simple name changes of member
> variables. As a number of the variables are not used in code the names
> have been changed to reflect that fact. If I'd renamed them and left out
> the 'not_used_' prefix would the changes not be controversial? I
> don't think the fact that the members are unused is a biggy.
> 

I didn't like the new name at all.

Quite often when I review these I just use a script to verify that we're
only renaming variables and not doing code changes outside of that.  But
if I review it by hand I would have seen that the variable was not used
and investigated what was going on.

> What might appear to be controversial is that I didn't simply remove
> the members. I haven't done that because I'm not yet satisfied that
> the structure's size is insignificant. As soon as I am happy that the
> size of the structure is not important, to runtime code execution,
> there'll be a patch which removes a number of 'not_used_...' members
> from a structure.
> 
> Alternatively if the size if important there might be a patch which
> renames a number of unused bitfield members to reserved_1, reserved_2,
> reserved_3

That's a good question.  If a struct is part of the use space API or the
network protocol or defined by the hardware then we can't change the
layout.

One thing I look for is if the struct has pointers which aren't tagged
as __user pointers then it's internal to the kernel.  Unfortunately that
doesn't help here.  Network protocol is all endian specific and this
struct is not.  But again that doesn't help much because it could just
be a bug.  If the struct is __packed then obviously the layout matters.

So I don't know.  I think you're right that actually we can't change
the layout.  The code is really a mess, so it's possible I have misread.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array

2018-08-31 Thread Linus Walleij
On Wed, Aug 29, 2018 at 10:48 PM Janusz Krzysztofik  wrote:

So it's no secret that I strongly fancy this patch set.

What would be great at this point is to have some people test
that the drivers still work as expected, even better if they can do
some benchmarking.

> -   values[PIN_DATA0 + i] = !!(val & BIT(i));
> -   values[PIN_CTRL_RS] = rs;
> +   value_bitmap[0] = val;
> +   __assign_bit(PIN_CTRL_RS, value_bitmap, rs);
> n = 9;
> if (hd->pins[PIN_CTRL_RW]) {
> -   values[PIN_CTRL_RW] = 0;
> +   __clear_bit(PIN_CTRL_RW, value_bitmap);

This seems fine to me, but I understand the comment that the
code becomes harder to read.

I think part of it is those __assign_bit() and __clear_bit() with
the double-underscore of unclear meaning. The meaning is
"non atomic" IIRC, so maybe I should move forward
with my plan to send a sed script to Torvalds just renaming all
of those to something sane in the next merge window.

Like __assign_bit() -> assign_bit_nonatomic()

Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/6] staging: erofs: formatting fix to NULL comparison

2018-08-31 Thread Dan Carpenter
On Fri, Aug 31, 2018 at 11:29:03AM +0800, Chao Yu wrote:
> 
> Hi Xiang,
> 
> I'm not against this change which follows checkpatch's rule, since I think 
> this
> can help to unify coding style in different modules of Linux. Maybe cleanup in
> other filesystem is needed as well.
> 

That code is old, and those filesystems are not in staging so we're not
going to change them.

Let's just apply the patch and not spend any time thinking about it.
Part of the point of style guidelines is so that we don't have to
repeat all these discussions over and over...

Btw, I have a rename_rev.pl patch for reviewing these.  I've attached
it.  rename_rev.pl -r NULL.  I've seen some people screw up the
conversion so having an automated review is nice.

regards,
dan carpenter

#!/usr/bin/perl

# This is a tool to help review variable rename patches. The goal is
# to strip out the automatic sed renames and the white space changes
# and leaves the interesting code changes.
#
# Example 1: A patch renames openInfo to open_info:
# cat diff | rename_review.pl openInfo open_info
#
# Example 2: A patch swaps the first two arguments to some_func():
# cat diff | rename_review.pl \
#-e 's/some_func\((.*?),(.*?),/some_func\($2, $1,/'
#
# Example 3: A patch removes the xkcd_ prefix from some but not all the
# variables.  Instead of trying to figure out which variables were renamed
# just remove the prefix from them all:
# cat diff | rename_review.pl -ea 's/xkcd_//g'
#
# Example 4: A patch renames 20 CamelCase variables.  To review this let's
# just ignore all case changes and all '_' chars.
# cat diff | rename_review -ea 'tr/[A-Z]/[a-z]/' -ea 's/_//g'
#
# The other arguments are:
# -nc removes comments
# -ns removes '\' chars if they are at the end of the line.

use strict;
use File::Temp qw/ :mktemp  /;

sub usage() {
print "usage: cat diff | $0 old new old new old new...\n";
print "   or: cat diff | $0 -e 's/old/new/g'\n";
print " -a : auto";
print " -e : execute on old lines\n";
print " -ea: execute on all lines\n";
print " -nc: no comments\n";
print " -nb: no unneeded braces\n";
print " -ns: no slashes at the end of a line\n";
print " -pull: for function pull.  deletes context.\n";
print " -r : NULL, bool";
exit(1);
}
my @subs;
my @strict_subs;
my @cmds;
my $strip_comments;
my $strip_braces;
my $strip_slashes;
my $pull_context;
my $auto;

sub filter($) {
my $line = shift();
my $old = 0;
if ($line =~ /^-/) {
$old = 1;
}
# remove the first char
$line =~ s/^[ +-]//;
if ($strip_comments) {
$line =~ s/\/\*.*?\*\///g;
$line =~ s/\/\/.*//;
}
foreach my $cmd (@cmds) {
if ($old || $cmd->[0] =~ /^-ea$/) {
eval "\$line =~ $cmd->[1]";
}
}
foreach my $sub (@subs) {
if ($old) {
$line =~ s/$sub->[0]/$sub->[1]/g;
}
}
foreach my $sub (@strict_subs) {
if ($old) {
$line =~ s/\b$sub->[0]\b/$sub->[1]/g;
}
}

# remove the newline so we can move curly braces here if we want.
$line =~ s/\n//;
return $line;
}

while (my $param1 = shift()) {
if ($param1 =~ /^-a$/) {
$auto = 1;
next;
}
if ($param1 =~ /^-nc$/) {
$strip_comments = 1;
next;
}
if ($param1 =~ /^-nb$/) {
$strip_braces = 1;
next;
}
if ($param1 =~ /^-ns$/) {
$strip_slashes = 1;
next;
}
if ($param1 =~ /^-pull$/) {
$pull_context = 1;
next;
}
my $param2 = shift();
if ($param2 =~ /^$/) {
usage();
}
if ($param1 =~ /^-e(a|)$/) {
push @cmds, [$param1, $param2];
next;
}
if ($param1 =~ /^-r$/) {
if ($param2 =~ /bool/) {
push @cmds, ["-e", "s/== true//"];
push @cmds, ["-e", "s/true ==//"];
push @cmds, ["-e", "s/([a-zA-Z\-\>\._]+) == false/!\$1/"];
next;
} elsif ($param2 =~ /NULL/) {
push @cmds, ["-e", "s/ != NULL//"];
push @cmds, ["-e", "s/([a-zA-Z\-\>\._0-9]+) == NULL/!\$1/"];
next;
} elsif ($param2 =~ /BIT/) {
push @cmds, ["-e", 's/1[uU]* *<< *(\d+)/BIT($1)/'];
push @cmds, ["-e", 's/\(1 *<< *(\w+)\)/BIT($1)/'];
push @cmds, ["-e", 's/\(BIT\((.*?)\)\)/BIT($1)/'];
next;
}
usage();
}

push @subs, [$param1, $param2];
}

my ($oldfh, $oldfile) = mkstemp("/tmp/oldX");
my ($newfh, $newfile) = mkstemp("/tmp/newX");

my @input = ;

# auto works on the observation that the - line comes before the + line when we
# rename variables.  Take the first - line.  Find the first + line.  Find the
# one word difference.  Test that the old word never occurs in the new text.
if ($auto) {
my %c_keywords = (  auto => 1,
break => 1,
case => 1,
char => 1,
  

Re: [PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

2018-08-31 Thread David Hildenbrand
On 30.08.2018 21:35, Pasha Tatashin wrote:
>> +
>> +void __ref remove_memory(int nid, u64 start, u64 size)
> 
> Remove __ref, otherwise looks good:

Indeed, will do.

Thanks for the review. Will resend in two weeks when I'm back from vacation.

Cheers!

> 
> Reviewed-by: Pavel Tatashin 
> 
>> +{
>> +lock_device_hotplug();
>> +__remove_memory(nid, start, size);
>> +unlock_device_hotplug();
>> +}
>>  EXPORT_SYMBOL_GPL(remove_memory);
>>  #endif /* CONFIG_MEMORY_HOTREMOVE */


-- 

Thanks,

David / dhildenb
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Images processing

2018-08-31 Thread Jimmy Wilson

Hi,

Have you received my email from last week?

I would like to speak with the person who manage your photos for your
company?

We are here to provide you all kinds of imaging editing.

What we can provide you:
Cutting out for photos
Clipping path for photos
Masking for photos
Retouching for your photos
Retouching for the Beauty Model and Portraits.

We have 20 staffs in house and daily basis 1000 images can be processed.

We give testing for your photos.

Thanks,
Jimmy Wilson

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH v2 1/4] arm64: hyperv: Add core Hyper-V include files

2018-08-31 Thread Michael Kelley (EOSG)
From: KY Srinivasan Sent: Thursday, August 30, 2018 11:23 AM

> > +/*
> > + * This file contains definitions from the Hyper-V Hypervisor Top-Level
> > + * Functional Specification (TLFS):
> > + * 
> > https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
> > +
> A lot of TLFS definitions are ISA independent and we are duplicating these
> definitions both for X86_64 and ARM_64.  Perhaps we should look at splitting
> this file into a common and ISA specific header file.

I agree that we want to end up with x86_64 and ARM64 ISA dependent files
that include an ISA independent file.  My thinking was to not make that
separation now, for a couple of reasons:

1) We don't have a Hyper-V TLFS that is explicit about what should be
considered ISA independent and ISA dependent.  I can make some
reasonable guesses, but it will be subject to change as the Hyper-V team
firms up the interface and decides what they want to commit to.

2) Some of the things defined in the TLFS have names that are
x86-specific (TSC, MSR, etc.).  For the ISA independent parts, those names
should be more generic, which is another dependency on the Hyper-V
team defining the ISA independent parts of the TLFS.

My judgment was that we'll end up with less perturbation overall to go
with this cloned version of hyperv-tlfs.h for now, and then come back
and do the separation once we have a definitive TLFS to base it on.  But
it's a judgment call, and if the sense is that we should do the separation
now, I can give it a try.

> > +#define HvRegisterHypervisorVersion0x0100 /*CPUID
> > 0x4002 */
> > +#defineHvRegisterPrivilegesAndFeaturesInfo0x0200 /*CPUID
> > 0x4003 */
> > +#defineHvRegisterFeaturesInfo0x0201
> > /*CPUID 0x4004 */
> > +#defineHvRegisterImplementationLimitsInfo0x0202 /*CPUID
> > 0x4005 */
> > +#define HvARM64RegisterInterfaceVersion0x00090006 /*CPUID
> > 0x4001 */
> 
> Can we avoid the mixed case names.

Agreed. I'll fix this throughout to use all uppercase, with underscore
as the word separator.

> > + * Linux-specific definitions for managing interactions with Microsoft's
> > + * Hyper-V hypervisor. Definitions that are specified in the Hyper-V
> > + * Top Level Functional Spec (TLFS) should not go in this file, but
> > + * should instead go in hyperv-tlfs.h.
> 
> Would it make sense to breakup this header file into ISA independent and 
> dependent files?

Yes, as above I agree the separation make sense.  And since this file is tied
To Linux and not to the Hyper-V TLFS, the separation isn't affected by the
TLFS issues mentioned above.  I'll give it a try and see if any issues arise.

> > +/*
> > + * Define the IRQ numbers/vectors used by Hyper-V VMbus interrupts
> > + * and by STIMER0 Direct Mode interrupts. Hyper-V should be supplying
> > + * these values through ACPI, but there are no other interrupting
> > + * devices in a Hyper-V VM on ARM64, so it's OK to hard code for now.
> > + * The "CALLBACK_VECTOR" terminology is a left-over from the x86/x64
> > + * world that is used in architecture independent Hyper-V code.
> > + */
> When we have direct device assignment for ARM-64 guests, can we still 
> hardcode.

Yes, we can still hardcode.  These values are in the Per-Processor Interrupt
(PPI) range of 16 to 31.  Any IRQ numbers assigned to a Discrete Device
Assignment (DDA) device will be in the Shared Peripheral Interrupt (SPI)
range of 32-1019 or the Locality-specific Peripheral Interrupt (LPI) range
of greater than 8192.   The handling of DDA interrupts is still under
discussion with the Hyper-V team, but there won't be any conflicts with
the PPI values that are hardcoded here.

> > +/*
> > + * The guest OS needs to register the guest ID with the hypervisor.
> > + * The guest ID is a 64 bit entity and the structure of this ID is
> > + * specified in the Hyper-V specification:
> > + *
> > + * msdn.microsoft.com/en-
> > us/library/windows/hardware/ff542653%28v=vs.85%29.aspx
> > + *
> > + * While the current guideline does not specify how Linux guest ID(s)
> > + * need to be generated, our plan is to publish the guidelines for
> > + * Linux and other guest operating systems that currently are hosted
> > + * on Hyper-V. The implementation here conforms to this yet
> > + * unpublished guidelines.
> > + *
> > + *
> > + * Bit(s)
> > + * 63 - Indicates if the OS is Open Source or not; 1 is Open Source
> > + * 62:56 - Os Type; Linux is 0x100
> > + * 55:48 - Distro specific identification
> > + * 47:16 - Linux kernel version number
> > + * 15:0  - Distro specific identification
> > + *
> > + * Generate the guest ID based on the guideline described above.
> > + */
> 
> No need to repeat the above block comment (already included in the TLFS 
> header).

Agreed.  Will make the change in v3 of the patch.

> > +/* Free the message slot and signal end-of-message if required */
> > +static inline void vmbus_signal_eom(struct hv_message *msg, u32
> > old_msg_type)
> > +{
> > +/*
> > + 

RE: [PATCH v2 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor

2018-08-31 Thread Michael Kelley (EOSG)
From: KY Srinivasan  Sent: Thursday, August 30, 2018 11:51 AM

> > +   /* Allocate percpu VP index */
> > +   hv_vp_index = kmalloc_array(num_possible_cpus(),
> > sizeof(*hv_vp_index),
> > +   GFP_KERNEL);
> > +   if (!hv_vp_index)
> > +   return 1;
> > +
> We should perhaps set the array so the contents are invalid so we can 
> correctly
> handle enlightenments for TL shootdown and IPI.

Agreed.  Will add the initialization in v3 of the patch.

Michael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: SKylake Edac support in linux 2.6.32.696 kernel build

2018-08-31 Thread Greg Kroah-Hartman
On Fri, Aug 31, 2018 at 04:46:41PM +0530, Nitin Gupta wrote:
> Hi All
> 
> I  started back porting  Skylake Edac driver from 4.8 kernel to 2.6.696
> kernel

Ick, why would you ever want to do that?  Just use a newer kernel
please.  If you really want to do this, you are on your own.

good luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: SKylake Edac support in linux 2.6.32.696 kernel build

2018-08-31 Thread Greg Kroah-Hartman
On Fri, Aug 31, 2018 at 11:22:06PM +0530, Nitin Gupta wrote:
> Hi Greg
> 
> Thanks for your comments  but somehow i cant use the latest kernel .

Why not?  What is not working properly for you?  It will be easier to
fix that than to work with a crazy half-backported mess that you will be
the sole person responsible for.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: android: ion: fix ION_IOC_{MAP, SHARE} use-after-free

2018-08-31 Thread Greg Hackmann
The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles.  This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:

- thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
- thread A: starts ION_IOC_MAP and increments the refcount to 2
- thread B: ION_IOC_FREE decrements the refcount to 1
- thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
handle
- thread A: continues ION_IOC_MAP with a dangling ion_handle * to
freed memory

Fix this by holding client->lock for the duration of
ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
remove ion_handle_get_by_id(), since there's literally no way to use it
safely.

This patch is applied on top of 4.9.y.  Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.

Cc: sta...@vger.kernel.org # v4.11-
Signed-off-by: Greg Hackmann 
---
 drivers/staging/android/ion/ion-ioctl.c | 12 ---
 drivers/staging/android/ion/ion.c   | 48 +++--
 drivers/staging/android/ion/ion_priv.h  |  6 ++--
 3 files changed, 40 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 2b700e8455c6..e3596855a703 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -128,11 +128,15 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
{
struct ion_handle *handle;
 
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
+   mutex_lock(&client->lock);
+   handle = ion_handle_get_by_id_nolock(client, 
data.handle.handle);
+   if (IS_ERR(handle)) {
+   mutex_unlock(&client->lock);
return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
+   }
+   data.fd.fd = ion_share_dma_buf_fd_nolock(client, handle);
+   ion_handle_put_nolock(handle);
+   mutex_unlock(&client->lock);
if (data.fd.fd < 0)
ret = data.fd.fd;
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6f9974cb0e15..403df8bf4b48 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -352,18 +352,6 @@ struct ion_handle *ion_handle_get_by_id_nolock(struct 
ion_client *client,
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
-struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-  int id)
-{
-   struct ion_handle *handle;
-
-   mutex_lock(&client->lock);
-   handle = ion_handle_get_by_id_nolock(client, id);
-   mutex_unlock(&client->lock);
-
-   return handle;
-}
-
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -1029,24 +1017,28 @@ static struct dma_buf_ops dma_buf_ops = {
.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
- struct ion_handle *handle)
+static struct dma_buf *__ion_share_dma_buf(struct ion_client *client,
+  struct ion_handle *handle,
+  bool lock_client)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
 
-   mutex_lock(&client->lock);
+   if (lock_client)
+   mutex_lock(&client->lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to share.\n", __func__);
-   mutex_unlock(&client->lock);
+   if (lock_client)
+   mutex_unlock(&client->lock);
return ERR_PTR(-EINVAL);
}
buffer = handle->buffer;
ion_buffer_get(buffer);
-   mutex_unlock(&client->lock);
+   if (lock_client)
+   mutex_unlock(&client->lock);
 
exp_info.ops = &dma_buf_ops;
exp_info.size = buffer->size;
@@ -1061,14 +1053,21 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
 
return dmabuf;
 }
+
+struct dma_buf *ion_share_dma_buf(struct ion_client *client,
+ struct ion_handle *handle)
+{
+   return __ion_share_dma_buf(client, handle, true);
+}
 EXPORT_SYMBOL(ion_share_dma_buf);
 
-int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
+static int __ion_share_dma_buf_fd(struc

Again the photos things

2018-08-31 Thread Jimmy Wilson

Hi,

Have you received my email from last week?

I would like to speak with the person who manage your photos for your
company?

We are here to provide you all kinds of imaging editing.

What we can provide you:
Cutting out for photos
Clipping path for photos
Masking for photos
Retouching for your photos
Retouching for the Beauty Model and Portraits.

We have 20 staffs in house and daily basis 1000 images can be processed.

We give testing for your photos.

Thanks,
Jimmy Wilson

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

2018-08-31 Thread Greg Kroah-Hartman
On Fri, Aug 31, 2018 at 01:06:27PM -0700, Greg Hackmann wrote:
> The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
> times while operating on one of the client's ion_handles.  This creates
> windows where userspace can call ION_IOC_FREE on the same client with
> the same handle, and effectively make the kernel drop its own reference.
> For example:
> 
> - thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
> - thread A: starts ION_IOC_MAP and increments the refcount to 2
> - thread B: ION_IOC_FREE decrements the refcount to 1
> - thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
> handle
> - thread A: continues ION_IOC_MAP with a dangling ion_handle * to
> freed memory
> 
> Fix this by holding client->lock for the duration of
> ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
> remove ion_handle_get_by_id(), since there's literally no way to use it
> safely.
> 
> This patch is applied on top of 4.9.y.  Kernels 4.12 and later are
> unaffected, since all the underlying ion_handle infrastructure has been
> ripped out.

Does 4.4.y or older also need this?  If so, can you send backports, as
this one does not apply there.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Patch "staging: android: ion: fix ION_IOC_{MAP, SHARE} use-after-free" has been added to the 4.9-stable tree

2018-08-31 Thread gregkh


This is a note to let you know that I've just added the patch titled

staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

to the 4.9-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 staging-android-ion-fix-ion_ioc_-map-share-use-after-free.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From ghackm...@android.com  Fri Aug 31 13:10:56 2018
From: Greg Hackmann 
Date: Fri, 31 Aug 2018 13:06:27 -0700
Subject: staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free
To: linux-ker...@vger.kernel.org
Cc: Laura Abbott , Sumit Semwal , 
Greg Kroah-Hartman , de...@driverdev.osuosl.org, 
kernel-t...@android.com, Greg Hackmann , 
sta...@vger.kernel.org
Message-ID: <20180831200627.59712-1-ghackm...@google.com>

From: Greg Hackmann 

This patch is 4.9.y only.  Kernels 4.12 and later are unaffected, since
all the underlying ion_handle infrastructure has been ripped out.

The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles.  This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:

- thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
- thread A: starts ION_IOC_MAP and increments the refcount to 2
- thread B: ION_IOC_FREE decrements the refcount to 1
- thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
handle
- thread A: continues ION_IOC_MAP with a dangling ion_handle * to
freed memory

Fix this by holding client->lock for the duration of
ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
remove ion_handle_get_by_id(), since there's literally no way to use it
safely.

Cc: sta...@vger.kernel.org # v4.11-
Signed-off-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/android/ion/ion-ioctl.c |   12 +---
 drivers/staging/android/ion/ion.c   |   48 +++-
 drivers/staging/android/ion/ion_priv.h  |6 ++--
 3 files changed, 40 insertions(+), 26 deletions(-)

--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -128,11 +128,15 @@ long ion_ioctl(struct file *filp, unsign
{
struct ion_handle *handle;
 
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
+   mutex_lock(&client->lock);
+   handle = ion_handle_get_by_id_nolock(client, 
data.handle.handle);
+   if (IS_ERR(handle)) {
+   mutex_unlock(&client->lock);
return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
+   }
+   data.fd.fd = ion_share_dma_buf_fd_nolock(client, handle);
+   ion_handle_put_nolock(handle);
+   mutex_unlock(&client->lock);
if (data.fd.fd < 0)
ret = data.fd.fd;
break;
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -352,18 +352,6 @@ struct ion_handle *ion_handle_get_by_id_
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
-struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-  int id)
-{
-   struct ion_handle *handle;
-
-   mutex_lock(&client->lock);
-   handle = ion_handle_get_by_id_nolock(client, id);
-   mutex_unlock(&client->lock);
-
-   return handle;
-}
-
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -1029,24 +1017,28 @@ static struct dma_buf_ops dma_buf_ops =
.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
- struct ion_handle *handle)
+static struct dma_buf *__ion_share_dma_buf(struct ion_client *client,
+  struct ion_handle *handle,
+  bool lock_client)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
 
-   mutex_lock(&client->lock);
+   if (lock_client)
+   mutex_lock(&client->lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to share.\n", __func__);
-   mutex_unlock(&client->lock);
+   if (lock_client)
+   mutex_unlock(&client->lock);
return ERR_PTR(-EINVAL);
}
buffer = handle->buf

Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

2018-08-31 Thread Greg Kroah-Hartman
On Fri, Aug 31, 2018 at 01:17:20PM -0700, Greg Hackmann wrote:
> On 08/31/2018 01:12 PM, Greg Kroah-Hartman wrote:
> > On Fri, Aug 31, 2018 at 01:06:27PM -0700, Greg Hackmann wrote:
> >> The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
> >> times while operating on one of the client's ion_handles.  This creates
> >> windows where userspace can call ION_IOC_FREE on the same client with
> >> the same handle, and effectively make the kernel drop its own reference.
> >> For example:
> >>
> >> - thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
> >> - thread A: starts ION_IOC_MAP and increments the refcount to 2
> >> - thread B: ION_IOC_FREE decrements the refcount to 1
> >> - thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
> >> handle
> >> - thread A: continues ION_IOC_MAP with a dangling ion_handle * to
> >> freed memory
> >>
> >> Fix this by holding client->lock for the duration of
> >> ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
> >> remove ion_handle_get_by_id(), since there's literally no way to use it
> >> safely.
> >>
> >> This patch is applied on top of 4.9.y.  Kernels 4.12 and later are
> >> unaffected, since all the underlying ion_handle infrastructure has been
> >> ripped out.
> > 
> > Does 4.4.y or older also need this?  If so, can you send backports, as
> > this one does not apply there.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Yes, 4.4.y and older will need this.  If there are no objections to this
> patch, I'll send backports ASAP.

None from me, thanks!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: android: ion: fix ION_IOC_{MAP, SHARE} use-after-free

2018-08-31 Thread Greg Hackmann
The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles.  This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:

- thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
- thread A: starts ION_IOC_MAP and increments the refcount to 2
- thread B: ION_IOC_FREE decrements the refcount to 1
- thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
handle
- thread A: continues ION_IOC_MAP with a dangling ion_handle * to
freed memory

Fix this by holding client->lock for the duration of
ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
remove ion_handle_get_by_id(), since there's literally no way to use it
safely.

This patch is applied on top of 4.4.y, and applies to older kernels
too.  4.9.y was fixed separately.  Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.

Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738
Cc: sta...@vger.kernel.org # v4.4-
Signed-off-by: Greg Hackmann 
---
 drivers/staging/android/ion/ion.c | 60 +++
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 47cb163da9a0..4adb1138af09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -449,18 +449,6 @@ static struct ion_handle 
*ion_handle_get_by_id_nolock(struct ion_client *client,
return ERR_PTR(-EINVAL);
 }
 
-struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-   int id)
-{
-   struct ion_handle *handle;
-
-   mutex_lock(&client->lock);
-   handle = ion_handle_get_by_id_nolock(client, id);
-   mutex_unlock(&client->lock);
-
-   return handle;
-}
-
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -1138,24 +1126,28 @@ static struct dma_buf_ops dma_buf_ops = {
.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
-   struct ion_handle *handle)
+static struct dma_buf *__ion_share_dma_buf(struct ion_client *client,
+  struct ion_handle *handle,
+  bool lock_client)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
 
-   mutex_lock(&client->lock);
+   if (lock_client)
+   mutex_lock(&client->lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to share.\n", __func__);
-   mutex_unlock(&client->lock);
+   if (lock_client)
+   mutex_unlock(&client->lock);
return ERR_PTR(-EINVAL);
}
buffer = handle->buffer;
ion_buffer_get(buffer);
-   mutex_unlock(&client->lock);
+   if (lock_client)
+   mutex_unlock(&client->lock);
 
exp_info.ops = &dma_buf_ops;
exp_info.size = buffer->size;
@@ -1170,14 +1162,21 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
 
return dmabuf;
 }
+
+struct dma_buf *ion_share_dma_buf(struct ion_client *client,
+ struct ion_handle *handle)
+{
+   return __ion_share_dma_buf(client, handle, true);
+}
 EXPORT_SYMBOL(ion_share_dma_buf);
 
-int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
+static int __ion_share_dma_buf_fd(struct ion_client *client,
+ struct ion_handle *handle, bool lock_client)
 {
struct dma_buf *dmabuf;
int fd;
 
-   dmabuf = ion_share_dma_buf(client, handle);
+   dmabuf = __ion_share_dma_buf(client, handle, lock_client);
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
 
@@ -1187,8 +1186,19 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
struct ion_handle *handle)
 
return fd;
 }
+
+int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
+{
+   return __ion_share_dma_buf_fd(client, handle, true);
+}
 EXPORT_SYMBOL(ion_share_dma_buf_fd);
 
+static int ion_share_dma_buf_fd_nolock(struct ion_client *client,
+  struct ion_handle *handle)
+{
+   return __ion_share_dma_buf_fd(client, handle, false);
+}
+
 struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
 {
struct dma_buf *dmabuf;
@@ -1335,11 +1345,15 @@ static long ion_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
{
struct ion_handle *handle;
 
-  

Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

2018-08-31 Thread Oscar Salvador
On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.

Hi David,

I would like to review this but I am on vacation, so I will not be able to get 
to it
soon.
I plan to do it once I am back.

Thanks
-- 
Oscar Salvador
SUSE L3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v6 0/3] staging: mt7621-mmc: Fix debug macros and their usages

2018-08-31 Thread Nishad Kamdar
This patchset fixes the three debug macros N_MSG, ERR_MSG, and
IRQ_MSG. Each patch fixes one particular macro and its usages.

For N_MSG, deletes the macro and its users as it is a no-op.

For ERR_MSG and IRQ_MSG, replaces printk with dev_ without __func__ or
__LINE__ or current->comm and current->pid. Removes the do {} while(0) loop
for the single statement macro. Further drops the macros and replaces their
usages with dev_. Deletes the commented usages.

Changes in v6:
  - Delete N_MSG() macro and its users as it is a no-op.
  - Patchset reduced to 3 patches as the patch INIT_MSG patch is accepted.

Changes in v5:
  - Remove commented code for N_MSG().
  - Remove commented ERR_MSG() usages.
 
Changes in v4:
  - Create multiple patches, one for each type of macro being
deleted/changed.

Changes in v3:
  - Replace usages of ERR_MSG and IRQ_MSG with dev_err() in code itself.
  - Remove all INIT_MSG usages.
  - Drop ERR_MSG, INIT_MSG and IRQ_MSG from dbg.h.

Changes in v2:
  - Replace printk with dev_.
  - Remove __func__, __LINE__, current->comm, current->pid from arguments.
  - Remove the do {} while(0) loop from these macros.
  - Modify commit message to include other changes.

Nishad Kamdar (3):
  staging: mt7621-mmc: Delete N_MSG() and all its users
  staging: mt7621-mmc: Fix debug macro ERR_MSG and its usages
  staging: mt7621-mmc: Fix debug macro IRQ_MSG and its usages

 drivers/staging/mt7621-mmc/dbg.h |  28 ---
 drivers/staging/mt7621-mmc/sd.c  | 398 +--
 2 files changed, 108 insertions(+), 318 deletions(-)

-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v6 1/3] staging: mt7621-mmc: Delete N_MSG() and all its users

2018-08-31 Thread Nishad Kamdar
This patch removes N_MSG() and all its users since it is a no-op.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - Delete N_MSG() and all its users.
Changes in v5:
  - Remove commented code for N_MSG()
---
 drivers/staging/mt7621-mmc/dbg.h |  10 --
 drivers/staging/mt7621-mmc/sd.c  | 242 ---
 2 files changed, 252 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 4d4898a3ab54..9152db30a2ed 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,16 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#define N_MSG(evt, fmt, args...)
-/*
-do {\
-if ((DBG_EVT_##evt) & sd_debug_zone[host->id]) { \
-printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
-host->id,  ##args , __FUNCTION__, __LINE__, current->comm, 
current->pid);  \
-} \
-} while(0)
-*/
-
 #define ERR_MSG(fmt, args...) \
 do { \
printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 4cd4df4fc75f..0154117fae15 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -230,144 +230,6 @@ static unsigned int msdc_do_command(struct msdc_host   
*host,
 
 static int msdc_tune_cmdrsp(struct msdc_host *host, struct mmc_command *cmd);
 
-#ifdef MT6575_SD_DEBUG
-static void msdc_dump_card_status(struct msdc_host *host, u32 status)
-{
-/* N_MSG is currently a no-op */
-#if 0
-   static char *state[] = {
-   "Idle", /* 0 */
-   "Ready",/* 1 */
-   "Ident",/* 2 */
-   "Stby", /* 3 */
-   "Tran", /* 4 */
-   "Data", /* 5 */
-   "Rcv",  /* 6 */
-   "Prg",  /* 7 */
-   "Dis",  /* 8 */
-   "Reserved", /* 9 */
-   "Reserved", /* 10 */
-   "Reserved", /* 11 */
-   "Reserved", /* 12 */
-   "Reserved", /* 13 */
-   "Reserved", /* 14 */
-   "I/O mode", /* 15 */
-   };
-#endif
-   if (status & R1_OUT_OF_RANGE)
-   N_MSG(RSP, "[CARD_STATUS] Out of Range");
-   if (status & R1_ADDRESS_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Address Error");
-   if (status & R1_BLOCK_LEN_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Block Len Error");
-   if (status & R1_ERASE_SEQ_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Erase Seq Error");
-   if (status & R1_ERASE_PARAM)
-   N_MSG(RSP, "[CARD_STATUS] Erase Param");
-   if (status & R1_WP_VIOLATION)
-   N_MSG(RSP, "[CARD_STATUS] WP Violation");
-   if (status & R1_CARD_IS_LOCKED)
-   N_MSG(RSP, "[CARD_STATUS] Card is Locked");
-   if (status & R1_LOCK_UNLOCK_FAILED)
-   N_MSG(RSP, "[CARD_STATUS] Lock/Unlock Failed");
-   if (status & R1_COM_CRC_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Command CRC Error");
-   if (status & R1_ILLEGAL_COMMAND)
-   N_MSG(RSP, "[CARD_STATUS] Illegal Command");
-   if (status & R1_CARD_ECC_FAILED)
-   N_MSG(RSP, "[CARD_STATUS] Card ECC Failed");
-   if (status & R1_CC_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] CC Error");
-   if (status & R1_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Error");
-   if (status & R1_UNDERRUN)
-   N_MSG(RSP, "[CARD_STATUS] Underrun");
-   if (status & R1_OVERRUN)
-   N_MSG(RSP, "[CARD_STATUS] Overrun");
-   if (status & R1_CID_CSD_OVERWRITE)
-   N_MSG(RSP, "[CARD_STATUS] CID/CSD Overwrite");
-   if (status & R1_WP_ERASE_SKIP)
-   N_MSG(RSP, "[CARD_STATUS] WP Eraser Skip");
-   if (status & R1_CARD_ECC_DISABLED)
-   N_MSG(RSP, "[CARD_STATUS] Card ECC Disabled");
-   if (status & R1_ERASE_RESET)
-   N_MSG(RSP, "[CARD_STATUS] Erase Reset");
-   if (status & R1_READY_FOR_DATA)
-   N_MSG(RSP, "[CARD_STATUS] Ready for Data");
-   if (status & R1_SWITCH_ERROR)
-   N_MSG(RSP, "[CARD_STATUS] Switch error");
-   if (status & R1_APP_CMD)
-   N_MSG(RSP, "[CARD_STATUS] App Command");
-
-   N_MSG(RSP, "[CARD_STATUS] '%s' State", state[R1_CURRENT_STATE(status)]);
-}
-
-static void msdc_dump_ocr_reg(struct msdc_host *host, u32 resp)
-{
-   if (resp & (1 << 7))
-   N_MSG(RSP, "[OCR] Low Voltage Range");
-   if (resp & (1 << 15))
-   N_MSG(RSP, "[OCR] 2.7-2.8 volt");
-   if (resp & (1 << 16))
-   N_MSG(RSP, "[OCR] 2.8-2.9 volt");
-   if (resp & (1 << 17))
-   N_MSG(RSP, "[OCR] 2.9-3.0 volt");
-   

[PATCH v6 2/3] staging: mt7621-mmc: Fix debug macro ERR_MSG and its usages

2018-08-31 Thread Nishad Kamdar
Replace all usages of ERR_MSG with with dev_ without __func__
or __LINE__ or current->comm and current->pid. Remove the do {}
while(0) loop for the single statement macro. Delete commented
ERR_MSG() usage. Drop ERR_MSG from dbg.h. Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - No change
Changes in v5:
  - Remove commented ERR_MSG() usage.
---
 drivers/staging/mt7621-mmc/dbg.h |   6 --
 drivers/staging/mt7621-mmc/sd.c  | 120 +--
 2 files changed, 81 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 9152db30a2ed..79914d98c573 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,12 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#define ERR_MSG(fmt, args...) \
-do { \
-   printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d> PID<%s><0x%x>\n", \
-  host->id,  ##args, __FUNCTION__, __LINE__, current->comm, 
current->pid); \
-} while (0);
-
 #if 1
 //defined CONFIG_MTK_MMC_CD_POLL
 #define IRQ_MSG(fmt, args...)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 0154117fae15..7474f9ed7b5b 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -322,7 +322,6 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr, 
unsigned int hz)
//u8  clksrc = hw->clk_src;
 
if (!hz) { // set mmc system clock to 0 ?
-   //ERR_MSG("set mclk to 0!!!");
msdc_reset_hw(host);
return;
}
@@ -373,7 +372,7 @@ static void msdc_abort_data(struct msdc_host *host)
 {
struct mmc_command *stop = host->mrq->stop;
 
-   ERR_MSG("Need to Abort.");
+   dev_err(mmc_dev(host->mmc), "%d -> Need to Abort.\n", host->id);
 
msdc_reset_hw(host);
msdc_clr_fifo(host);
@@ -382,7 +381,8 @@ static void msdc_abort_data(struct msdc_host *host)
// need to check FIFO count 0 ?
 
if (stop) {  /* try to stop, but may not success */
-   ERR_MSG("stop when abort CMD<%d>", stop->opcode);
+   dev_err(mmc_dev(host->mmc), "%d -> stop when abort CMD<%d>\n",
+   host->id, stop->opcode);
(void)msdc_do_command(host, stop, 0, CMD_TIMEOUT);
}
 
@@ -523,13 +523,14 @@ static void msdc_pm(pm_message_t state, void *data)
 
} else if (evt == PM_EVENT_RESUME || evt == PM_EVENT_USER_RESUME) {
if (!host->suspend) {
-   //ERR_MSG("warning: already resume");
return;
}
 
/* No PM resume when USR suspend */
if (evt == PM_EVENT_RESUME && host->pm_state.event == 
PM_EVENT_USER_SUSPEND) {
-   ERR_MSG("PM Resume when in USR Suspend");   
/* won't happen. */
+   dev_err(mmc_dev(host->mmc),
+   "%d -> PM Resume when in USR Suspend\n",
+   host->id); /* won't happen. */
return;
}
 
@@ -645,7 +646,9 @@ static unsigned int msdc_command_start(struct msdc_host   
*host,
break;
 
if (time_after(jiffies, tmo)) {
-   ERR_MSG("XXX cmd_busy timeout: before CMD<%d>", 
opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX cmd_busy timeout: before 
CMD<%d>\n",
+   host->id, opcode);
cmd->error = -ETIMEDOUT;
msdc_reset_hw(host);
goto end;
@@ -656,7 +659,9 @@ static unsigned int msdc_command_start(struct msdc_host   
*host,
if (!sdc_is_busy())
break;
if (time_after(jiffies, tmo)) {
-   ERR_MSG("XXX sdc_busy timeout: before CMD<%d>", 
opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX sdc_busy timeout: before 
CMD<%d>\n",
+   host->id, opcode);
cmd->error = -ETIMEDOUT;
msdc_reset_hw(host);
goto end;
@@ -695,7 +700,9 @@ static unsigned int msdc_command_resp(struct msdc_host   
*host,
 
spin_unlock(&host->lock);
if (!wait_for_completion_timeout(&host->cmd_done, 10 * timeout)) {
-   ERR_MSG("XXX CMD<%d> wait_for_completion timeout ARG<0x%.8x>", 
opcode, cmd->arg);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> wait_for_completion timeout 
ARG<0x%.8x>\n",
+   host->id, opcode, cmd->arg);
cmd->error = -ETIMEDOUT;
msdc_rese

[PATCH v6 3/3] staging: mt7621-mmc: Fix debug macro IRQ_MSG and its usages

2018-08-31 Thread Nishad Kamdar
Replace all usages of IRQ_MSG with with dev_ without __func__
or __LINE__ or current->comm and current->pid. Remove the do {}
while(0) loop for the single statement macro. Drop IRQ_MSG from dbg.h.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
Changes in v6:
  - No change
Changes in v5:
  - No change
---
 drivers/staging/mt7621-mmc/dbg.h | 12 ---
 drivers/staging/mt7621-mmc/sd.c  | 36 
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 79914d98c573..4ab9f10dccc2 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -102,18 +102,6 @@ do { \
 } while (0)
 #endif /* end of +++ */
 
-#if 1
-//defined CONFIG_MTK_MMC_CD_POLL
-#define IRQ_MSG(fmt, args...)
-#else
-/* PID in ISR in not corrent */
-#define IRQ_MSG(fmt, args...) \
-do { \
-   printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d>\n", \
-  host->id,  ##args, __FUNCTION__, __LINE__);  \
-} while (0);
-#endif
-
 void msdc_debug_proc_init(void);
 
 #if 0 /* --- chhung */
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 7474f9ed7b5b..f3ae19fe0f76 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -279,7 +279,9 @@ static void msdc_tasklet_card(struct work_struct *work)
mmc_detect_change(host->mmc, msecs_to_jiffies(20));
}
 
-   IRQ_MSG("card found<%s>", inserted ? "inserted" : "removed");
+   dev_err(mmc_dev(host->mmc),
+   "%d -> card found<%s>\n",
+   host->id, inserted ? "inserted" : "removed");
 #endif
 
spin_unlock(&host->lock);
@@ -1638,14 +1640,17 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
if (intsts & MSDC_INT_CDSC) {
if (host->mmc->caps & MMC_CAP_NEEDS_POLL)
return IRQ_HANDLED;
-   IRQ_MSG("MSDC_INT_CDSC irq<0x%.8x>", intsts);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> MSDC_INT_CDSC irq<0x%.8x>\n", host->id, intsts);
schedule_delayed_work(&host->card_delaywork, HZ);
/* tuning when plug card ? */
}
 
/* sdio interrupt */
if (intsts & MSDC_INT_SDIOIRQ) {
-   IRQ_MSG("XXX MSDC_INT_SDIOIRQ");  /* seems not sdio irq */
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX MSDC_INT_SDIOIRQ\n",
+   host->id); /* seems not sdio irq */
//mmc_signal_sdio_irq(host->mmc);
}
 
@@ -1663,10 +1668,15 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
msdc_clr_int();
 
if (intsts & MSDC_INT_DATTMO) {
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_DATTMO", 
host->mrq->cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> MSDC_INT_DATTMO\n",
+   host->id, host->mrq->cmd->opcode);
data->error = -ETIMEDOUT;
} else if (intsts & MSDC_INT_DATCRCERR) {
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_DATCRCERR, 
SDC_DCRC_STS<0x%x>", host->mrq->cmd->opcode, readl(host->base + SDC_DCRC_STS));
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> MSDC_INT_DATCRCERR, 
SDC_DCRC_STS<0x%x>\n",
+   host->id, host->mrq->cmd->opcode,
+   readl(host->base + SDC_DCRC_STS);
data->error = -EIO;
}
 
@@ -1699,15 +1709,23 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
}
} else if ((intsts & MSDC_INT_RSPCRCERR) || (intsts & 
MSDC_INT_ACMDCRCERR)) {
if (intsts & MSDC_INT_ACMDCRCERR)
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_ACMDCRCERR", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> 
MSDC_INT_ACMDCRCERR\n",
+   host->id, cmd->opcode);
else
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_RSPCRCERR", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+   "%d -> XXX CMD<%d> 
MSDC_INT_RSPCRCERR\n",
+   host->id, cmd->opcode);
cmd->error = -EIO;
} else if ((intsts & MSDC_INT_CMDTMO) || (intsts & 
MSDC_INT_ACMDTMO)) {
if (intsts & MSDC_INT_ACMDTMO)
-   IRQ_MSG("XXX CMD<%d> MSDC_INT_ACMDTMO", 
cmd->opcode);
+   dev_err(mmc_dev(host->mmc),
+

Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

2018-08-31 Thread John Whitmore
On Thu, Aug 30, 2018 at 03:34:01PM -0700, Joe Perches wrote:
> On Wed, 2018-08-29 at 22:55 +0100, John Whitmore wrote:
> > On Wed, Aug 29, 2018 at 04:21:54PM -0500, Larry Finger wrote:
> > > On 08/29/2018 04:14 PM, Joe Perches wrote:
> []
> > > > Perhaps support for the chipset could be converted to use
> > > > mac80211 and moved into the directory with the other realtek
> > > > drivers in drivers/net/wireless/realtek/rtl8xxxu/...
> []
> > > All the Realtek USB devices should be added to rtl8xxxu, not merely moved
> > > into that directory. Jes Sorensen created a well-designed driver the is
> > > structured to permit addition of different initialization routines, etc.
> > > That said, the conversion will not be easy. In addition, it will require
> > > having your hands on a real device - a requirement that I cannot meet for
> > > the RTL8192U.
> []
> > > Oops... it probably doesn't look like it, at the moment, but 'actual code
> > changes to this driver' was where I'm hoping to get to. There's a lot of
> > stuff in the header files, including member variables, which are not used
> > in the code. I was hoping to strip these out incrementally to minimise
> > the amount of source code that has to be understood. I'm not familiar
> > with the overall network, or 80211, subsystem architecture, but it's hard
> > to see why this driver has it's own private ieee80211.h file.
> 
> That's true and the reason why this code should
> eventually be deleted if possible and its functionality
> integrated into the existing realtek/rtl8u code.
> 
> > I must try and get my hands on the device in question. 
> 
> That'd be good, though likely this device is obsolete.
> Good luck finding one.
>

Maybe if the whole driver was deleted nobody would notice ;)
Thanks for your help. I'm afraid I carried on in the same vain
cleaning stuff up but I do have to look at realtek/rtl8u, thanks
for pointing out where the goalposts are, miles away ;) 

> > Thank ye for your comments, and sorry for the "somewhat useful" changes
> > to date, but doing these changes is letting me get the hang of this code,
> > which I refuse to comment on because there are probably guidelines on using
> > naughty language on here. ;)
> 
> Feel free.
> 
> The one look I took at any existing multi-platform realtek
> code with all the #ifdefs made me not want look at it again.
> 
> https://github.com/hadess/rtl8723bs/
> 
> I said a naughty under my breath too.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATH v6 0/4] gpiolib: speed up GPIO array processing

2018-08-31 Thread Janusz Krzysztofik


The goal is to boost performance of get/set array functions while
processing GPIO arrays which represent pins of a signle chip in
hardware order.  If resulting performance is close to PIO, GPIO API
can be used for data I/O without much loss of speed.

Created and tested on a low end Amstrad Delta board with NAND driver
updated to use GPIO API for data I/O.  Performance degrade compared to
PIO is much better than before the optimization but still not quite
satisfactory.

Janusz Krzysztofik (4):
  gpiolib: Pass bitmaps, not integer arrays, to get/set array
  gpiolib: Identify arrays matching GPIO hardware
  gpiolib: Pass array info to get/set array functions
  gpiolib: Implement fast processing path in get/set array

Changelog:
v6:
[PATCH v6 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set
- use DECLARE_BITMAP() macro for declaring value_bitmap - great idea by
  David Laight, thanks!
drivers/auxdisplay/hd44780.c:
- simplify the code and adjust comments as recommended by Geert
  Uytterhoeven - thanks!,
drivers/i2c/muxes/i2c-mux-gpio.c:
- drop .values member of struct gpiomux - details prvided by Peter
  Rosin, thanks!, 
drivers/mux/gpio.c:
- drop .val member of struct mux_gpio - details prvided by Peter
  Rosin, thanks!,
drivers/net/phy/mdio-mux-gpio.c:
- drop .values member of struct mdio_mux_gpio_state and is processsing.

v5:
[PATCH v5 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set
- drivers/i2c/muxes/i2c-mux-gpio.c:
  - drop assigment of values to struct gpiomux.values, as recommended
by Peter Rosin - thanks!,
  - mark the .values member of the structure as obsolete,
- drivers/mux/gpio.c:
  - drop assigment of values to struct mux_gpio.val, also recommended
by Peter Rosin - thanks!,
  - merk the .val member of the structure as obsolete,
- drivers/auxdisplay/hd44780.c:
  - fix incorrect bitmap size,
  - use >>= operator to simplify notation,
  both catched by Miguel Ojeda - thanks!,
- add Cc: clauses as well as Acked-by: collected so far.
[PATCH v5 2/4] gpiolib: Identify arrays matching GPIO hardware
- add Cc: clause.
[PATCH v5 3/4] gpiolib: Pass array info to get/set array functions
- add Cc: clauses as well as Acked-by: collected so far.
[PATCH v5 4/4] gpiolib: Implement fast processing path in get/set
- add Cc: clause.

v4:
That series was a follow up of the former "mtd: rawnand: ams-delta: Use
gpio-omap accessors for data I/O" which already contained some changes
to gpiolib.  Those previous attempts were commented by Borris Brezillon
who suggested using GPIO API modified to accept bitmaps, and by Linus
Walleij who suggested still more great ideas for further immprovement
of the proposed API changes - thanks!

diffstat:
 Documentation/driver-api/gpio/board.rst |   15 +
 Documentation/driver-api/gpio/consumer.rst  |   48 +++-
 drivers/auxdisplay/hd44780.c|   74 +++
 drivers/bus/ts-nbus.c   |   27 +-
 drivers/gpio/gpio-max3191x.c|   23 +-
 drivers/gpio/gpiolib.c  |  279 ++--
 drivers/gpio/gpiolib.h  |   15 +
 drivers/i2c/muxes/i2c-mux-gpio.c|   16 -
 drivers/mmc/core/pwrseq_simple.c|   15 -
 drivers/mux/gpio.c  |   18 -
 drivers/net/phy/mdio-mux-gpio.c |   13 -
 drivers/pcmcia/soc_common.c |   14 -
 drivers/phy/motorola/phy-mapphone-mdm6600.c |   21 +-
 drivers/staging/iio/adc/ad7606.c|   12 -
 drivers/tty/serial/serial_mctrl_gpio.c  |9 
 include/linux/gpio/consumer.h   |   35 ++-
 16 files changed, 417 insertions(+), 217 deletions(-)

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v6 3/4] gpiolib: Pass array info to get/set array functions

2018-08-31 Thread Janusz Krzysztofik
In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions.  Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a user bulids an array itself from single GPIOs.

Cc: Jonathan Corbet 
Cc: Miguel Ojeda Sandonis 
Cc: Peter Korsgaard 
Cc: Peter Rosin 
Cc: Andrew Lunn 
Cc: Florian Fainelli 
Cc: "David S. Miller" 
Cc: Dominik Brodowski 
Cc: Kishon Vijay Abraham I 
Cc: Lars-Peter Clausen 
Cc: Michael Hennerich 
Cc: Jonathan Cameron 
Cc: Hartmut Knaack 
Cc: Peter Meerwald-Stadler 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Janusz Krzysztofik 
Acked-by: Ulf Hansson 
---
 Documentation/driver-api/gpio/consumer.rst  | 14 ++--
 drivers/auxdisplay/hd44780.c| 12 ++
 drivers/bus/ts-nbus.c   |  6 +++--
 drivers/gpio/gpio-max3191x.c|  6 +++--
 drivers/gpio/gpiolib.c  | 34 -
 drivers/gpio/gpiolib.h  |  2 ++
 drivers/i2c/muxes/i2c-mux-gpio.c|  2 +-
 drivers/mmc/core/pwrseq_simple.c|  2 +-
 drivers/mux/gpio.c  |  3 ++-
 drivers/net/phy/mdio-mux-gpio.c |  2 +-
 drivers/pcmcia/soc_common.c |  3 ++-
 drivers/phy/motorola/phy-mapphone-mdm6600.c |  4 +++-
 drivers/staging/iio/adc/ad7606.c|  3 ++-
 drivers/tty/serial/serial_mctrl_gpio.c  |  2 +-
 include/linux/gpio/consumer.h   |  8 +++
 15 files changed, 75 insertions(+), 28 deletions(-)

diff --git a/Documentation/driver-api/gpio/consumer.rst 
b/Documentation/driver-api/gpio/consumer.rst
index 7e0298b9a7b9..0afd95a12b10 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -325,28 +325,36 @@ The following functions get or set the values of an array 
of GPIOs::
 
int gpiod_get_array_value(unsigned int array_size,
  struct gpio_desc **desc_array,
+ struct gpio_array *array_info,
  unsigned long *value_bitmap);
int gpiod_get_raw_array_value(unsigned int array_size,
  struct gpio_desc **desc_array,
+ struct gpio_array *array_info,
  unsigned long *value_bitmap);
int gpiod_get_array_value_cansleep(unsigned int array_size,
   struct gpio_desc **desc_array,
+  struct gpio_array *array_info,
   unsigned long *value_bitmap);
int gpiod_get_raw_array_value_cansleep(unsigned int array_size,
   struct gpio_desc **desc_array,
+  struct gpio_array *array_info,
   unsigned long *value_bitmap);
 
void gpiod_set_array_value(unsigned int array_size,
   struct gpio_desc **desc_array,
+  struct gpio_array *array_info,
   unsigned long *value_bitmap)
void gpiod_set_raw_array_value(unsigned int array_size,
   struct gpio_desc **desc_array,
+  struct gpio_array *array_info,
   unsigned long *value_bitmap)
void gpiod_set_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
+   struct gpio_array *array_info,
unsigned long *value_bitmap)
void gpiod_set_raw_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
+   struct gpio_array *array_info,
unsigned long *value_bitmap)
 
 The array can be an arbitrary set of GPIOs. The functions will try to access
@@ -358,6 +366,7 @@ accessed sequentially.
 The functions take three arguments:
* array_size- the number of array elements
* desc_array- an array of GPIO descriptors
+   * array_info- optional information obtained from gpiod_array_get()
* value_bitmap  - a bitmap to store the GPIOs' values (get) or
  a bitmap of values to assign to the GPIOs (set)
 
@@ -368,12 +377,13 @@ the struct gpio_descs returned by gpiod_get_array()::
 
struct gpio_descs *my_gpio_descs = gpiod_get_array(...);
gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc,
- my_gpio_value_bitmap);

[PATCH v6 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array

2018-08-31 Thread Janusz Krzysztofik
Most users of get/set array functions iterate consecutive bits of data,
usually a single integer, while processing array of results obtained
from, or building an array of values to be passed to those functions.
Save time wasted on those iterations by changing the functions' API to
accept bitmaps.

All current users are updated as well.

More benefits from the change are expected as soon as planned support
for accepting/passing those bitmaps directly from/to respective GPIO
chip callbacks if applicable is implemented.

Cc: Jonathan Corbet 
Cc: Miguel Ojeda Sandonis 
Cc: Peter Korsgaard 
Cc: Peter Rosin 
Cc: Andrew Lunn 
Cc: Florian Fainelli 
Cc: "David S. Miller" 
Cc: Dominik Brodowski 
Cc: Kishon Vijay Abraham I 
Cc: Lars-Peter Clausen 
Cc: Michael Hennerich 
Cc: Jonathan Cameron 
Cc: Hartmut Knaack 
Cc: Peter Meerwald-Stadler 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Janusz Krzysztofik 
Acked-by: Ulf Hansson 
---
 Documentation/driver-api/gpio/consumer.rst  | 22 
 drivers/auxdisplay/hd44780.c| 62 -
 drivers/bus/ts-nbus.c   | 21 ++-
 drivers/gpio/gpio-max3191x.c| 17 +++---
 drivers/gpio/gpiolib.c  | 86 +++--
 drivers/gpio/gpiolib.h  |  4 +-
 drivers/i2c/muxes/i2c-mux-gpio.c| 14 ++---
 drivers/mmc/core/pwrseq_simple.c| 13 ++---
 drivers/mux/gpio.c  | 15 ++---
 drivers/net/phy/mdio-mux-gpio.c | 11 ++--
 drivers/pcmcia/soc_common.c | 11 ++--
 drivers/phy/motorola/phy-mapphone-mdm6600.c | 17 +++---
 drivers/staging/iio/adc/ad7606.c|  9 +--
 drivers/tty/serial/serial_mctrl_gpio.c  |  7 ++-
 include/linux/gpio/consumer.h   | 18 +++---
 15 files changed, 145 insertions(+), 182 deletions(-)

diff --git a/Documentation/driver-api/gpio/consumer.rst 
b/Documentation/driver-api/gpio/consumer.rst
index aa03f389d41d..ed68042ddccf 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -323,29 +323,29 @@ The following functions get or set the values of an array 
of GPIOs::
 
int gpiod_get_array_value(unsigned int array_size,
  struct gpio_desc **desc_array,
- int *value_array);
+ unsigned long *value_bitmap);
int gpiod_get_raw_array_value(unsigned int array_size,
  struct gpio_desc **desc_array,
- int *value_array);
+ unsigned long *value_bitmap);
int gpiod_get_array_value_cansleep(unsigned int array_size,
   struct gpio_desc **desc_array,
-  int *value_array);
+  unsigned long *value_bitmap);
int gpiod_get_raw_array_value_cansleep(unsigned int array_size,
   struct gpio_desc **desc_array,
-  int *value_array);
+  unsigned long *value_bitmap);
 
void gpiod_set_array_value(unsigned int array_size,
   struct gpio_desc **desc_array,
-  int *value_array)
+  unsigned long *value_bitmap)
void gpiod_set_raw_array_value(unsigned int array_size,
   struct gpio_desc **desc_array,
-  int *value_array)
+  unsigned long *value_bitmap)
void gpiod_set_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
-   int *value_array)
+   unsigned long *value_bitmap)
void gpiod_set_raw_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
-   int *value_array)
+   unsigned long *value_bitmap)
 
 The array can be an arbitrary set of GPIOs. The functions will try to access
 GPIOs belonging to the same bank or chip simultaneously if supported by the
@@ -356,8 +356,8 @@ accessed sequentially.
 The functions take three arguments:
* array_size- the number of array elements
* desc_array- an array of GPIO descriptors
-   * value_array   - an array to store the GPIOs' values (get) or
- an array of values to assign to the GPIOs (set)
+   * value_bitmap  - a bitmap to store the GPIOs' values (get) or
+ a bitmap of values to assign to the GPIOs (set)
 
 The descriptor

[PATCH v6 4/4] gpiolib: Implement fast processing path in get/set array

2018-08-31 Thread Janusz Krzysztofik
Certain GPIO descriptor arrays returned by gpio_get_array() may contain
information on direct mapping of array members to pins of a single GPIO
chip in hardware order.  In such cases, bitmaps of values can be passed
directly from/to the chip's .get/set_multiple() callbacks without
wasting time on iterations.

Add respective code to gpiod_get/set_array_bitmap_complex() functions.
Pins not applicable for fast path are processed as before, skipping
over the 'fast' ones.

Cc: Jonathan Corbet 
Signed-off-by: Janusz Krzysztofik 
---
 Documentation/driver-api/gpio/board.rst| 15 ++
 Documentation/driver-api/gpio/consumer.rst |  8 +++
 drivers/gpio/gpiolib.c | 87 --
 3 files changed, 105 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/gpio/board.rst 
b/Documentation/driver-api/gpio/board.rst
index 2c112553df84..c66821e033c2 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -193,3 +193,18 @@ And the table can be added to the board code as follows::
 
 The line will be hogged as soon as the gpiochip is created or - in case the
 chip was created earlier - when the hog table is registered.
+
+Arrays of pins
+--
+In addition to requesting pins belonging to a function one by one, a device may
+also request an array of pins assigned to the function.  The way those pins are
+mapped to the device determines if the array qualifies for fast bitmap
+processing.  If yes, a bitmap is passed over get/set array functions directly
+between a caller and a respective .get/set_multiple() callback of a GPIO chip.
+
+In order to qualify for fast bitmap processing, the pin mapping must meet the
+following requirements:
+- it must belong to the same chip as other 'fast' pins of the function,
+- its index within the function must match its hardware number within the chip.
+
+Open drain and open source pins are excluded from fast bitmap output 
processing.
diff --git a/Documentation/driver-api/gpio/consumer.rst 
b/Documentation/driver-api/gpio/consumer.rst
index 0afd95a12b10..cf992e5ab976 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -388,6 +388,14 @@ array_info should be set to NULL.
 Note that for optimal performance GPIOs belonging to the same chip should be
 contiguous within the array of descriptors.
 
+Still better performance may be achieved if array indexes of the descriptors
+match hardware pin numbers of a single chip.  If an array passed to a get/set
+array function matches the one obtained from gpiod_get_array() and array_info
+associated with the array is also passed, the function may take a fast bitmap
+processing path, passing the value_bitmap argument directly to the respective
+.get/set_multiple() callback of the chip.  That allows for utilization of GPIO
+banks as data I/O ports without much loss of performance.
+
 The return value of gpiod_get_array_value() and its variants is 0 on success
 or negative on error. Note the difference to gpiod_get_value(), which returns
 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 4d26cdbdb7cf..b799a89c4c17 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2787,7 +2787,36 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,
  struct gpio_array *array_info,
  unsigned long *value_bitmap)
 {
-   int i = 0;
+   int err, i = 0;
+
+   /*
+* Validate array_info against desc_array and its size.
+* It should immediately follow desc_array if both
+* have been obtained from the same gpiod_get_array() call.
+*/
+   if (array_info && array_info->desc == desc_array &&
+   array_size <= array_info->size &&
+   (void *)array_info == desc_array + array_info->size) {
+   if (!can_sleep)
+   WARN_ON(array_info->chip->can_sleep);
+
+   err = gpio_chip_get_multiple(array_info->chip,
+array_info->get_mask,
+value_bitmap);
+   if (err)
+   return err;
+
+   if (!raw && !bitmap_empty(array_info->invert_mask, array_size))
+   bitmap_xor(value_bitmap, value_bitmap,
+  array_info->invert_mask, array_size);
+
+   if (bitmap_full(array_info->get_mask, array_size))
+   return 0;
+
+   i = find_first_zero_bit(array_info->get_mask, array_size);
+   } else {
+   array_info = NULL;
+   }
 
while (i < array_size) {
struct gpio_chip *chip = desc_array[i]->gdev->chip;
@@ -2818,7 +2847,12 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,

[PATCH v6 2/4] gpiolib: Identify arrays matching GPIO hardware

2018-08-31 Thread Janusz Krzysztofik
Certain GPIO array lookup results may map directly to GPIO pins of a
single GPIO chip in hardware order.  If that condition is recognized
and handled efficiently, significant performance gain of get/set array
functions may be possible.

While processing a request for an array of GPIO descriptors, identify
those which represent corresponding pins of a single GPIO chip.  Skip
over pins which require open source or open drain special processing.
Moreover, identify pins which require inversion.  Pass a pointer to
that information with the array to the caller so it can benefit from
enhanced performance as soon as get/set array functions can accept and
make efficient use of it.

Cc: Jonathan Corbet 
Signed-off-by: Janusz Krzysztofik 
---
 Documentation/driver-api/gpio/consumer.rst |  4 +-
 drivers/gpio/gpiolib.c | 72 +-
 drivers/gpio/gpiolib.h |  9 
 include/linux/gpio/consumer.h  |  9 
 4 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/gpio/consumer.rst 
b/Documentation/driver-api/gpio/consumer.rst
index ed68042ddccf..7e0298b9a7b9 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -109,9 +109,11 @@ For a function using multiple GPIOs all of those can be 
obtained with one call::
   enum gpiod_flags flags)
 
 This function returns a struct gpio_descs which contains an array of
-descriptors::
+descriptors.  It also contains a pointer to a gpiolib private structure which,
+if passed back to get/set array functions, may speed up I/O proocessing::
 
struct gpio_descs {
+   struct gpio_array *info;
unsigned int ndescs;
struct gpio_desc *desc[];
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f0e9ffa8cab6..c1ed1c759345 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4174,7 +4174,9 @@ struct gpio_descs *__must_check gpiod_get_array(struct 
device *dev,
 {
struct gpio_desc *desc;
struct gpio_descs *descs;
-   int count;
+   struct gpio_array *array_info = NULL;
+   struct gpio_chip *chip;
+   int count, bitmap_size;
 
count = gpiod_count(dev, con_id);
if (count < 0)
@@ -4190,9 +4192,77 @@ struct gpio_descs *__must_check gpiod_get_array(struct 
device *dev,
gpiod_put_array(descs);
return ERR_CAST(desc);
}
+
descs->desc[descs->ndescs] = desc;
+
+   chip = gpiod_to_chip(desc);
+   /*
+* Select a chip of first array member
+* whose index matches its pin hardware number
+* as a candidate for fast bitmap processing.
+*/
+   if (!array_info && gpio_chip_hwgpio(desc) == descs->ndescs) {
+   struct gpio_descs *array;
+
+   bitmap_size = BITS_TO_LONGS(chip->ngpio > count ?
+   chip->ngpio : count);
+
+   array = kzalloc(struct_size(descs, desc, count) +
+   struct_size(array_info, invert_mask,
+   3 * bitmap_size), GFP_KERNEL);
+   if (!array) {
+   gpiod_put_array(descs);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   memcpy(array, descs,
+  struct_size(descs, desc, descs->ndescs + 1));
+   kfree(descs);
+
+   descs = array;
+   array_info = (void *)(descs->desc + count);
+   array_info->get_mask = array_info->invert_mask +
+ bitmap_size;
+   array_info->set_mask = array_info->get_mask +
+ bitmap_size;
+
+   array_info->desc = descs->desc;
+   array_info->size = count;
+   array_info->chip = chip;
+   bitmap_set(array_info->get_mask, descs->ndescs,
+  count - descs->ndescs);
+   bitmap_set(array_info->set_mask, descs->ndescs,
+  count - descs->ndescs);
+   descs->info = array_info;
+   }
+   /*
+* Unmark members which don't qualify for fast bitmap
+* processing (different chip, not in hardware order)
+*/
+   if (array_info && (chip != array_info->chip ||
+   gpio_chip_hwgpio(desc) != descs->ndescs)) {
+   __clear_bit(descs->ndescs, array_info->get_mask);
+   __cle

[PATCH 03/20] staging:rtl8192u: Remove unused functions - Style

2018-08-31 Thread John Whitmore
Remove unused function declarations. This is a coding style change
which should have no impact on runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 10 --
 drivers/staging/rtl8192u/r8192U_core.c |  7 ---
 2 files changed, 17 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 70bbd1fadcca..b3e6ce2acedb 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1103,22 +1103,12 @@ void force_pci_posting(struct net_device *dev);
 
 void rtl8192_rtx_disable(struct net_device *dev);
 void rtl8192_rx_enable(struct net_device *dev);
-void rtl8192_tx_enable(struct net_device *dev);
 
-void rtl8192_disassociate(struct net_device *dev);
-void rtl8185_set_rf_pins_enable(struct net_device *dev, u32 a);
-
-void rtl8192_set_anaparam(struct net_device *dev, u32 a);
-void rtl8185_set_anaparam2(struct net_device *dev, u32 a);
 void rtl8192_update_msr(struct net_device *dev);
 int rtl8192_down(struct net_device *dev);
 int rtl8192_up(struct net_device *dev);
 void rtl8192_commit(struct net_device *dev);
 void rtl8192_set_chan(struct net_device *dev, short ch);
-void write_phy(struct net_device *dev, u8 adr, u8 data);
-void write_phy_cck(struct net_device *dev, u8 adr, u32 data);
-void write_phy_ofdm(struct net_device *dev, u8 adr, u32 data);
-void rtl8185_tx_antenna(struct net_device *dev, u8 ant);
 void rtl8192_set_rxconf(struct net_device *dev);
 void rtl819xusb_beacon_tx(struct net_device *dev, u16 tx_rate);
 
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 12783b88eb58..98bb40c50f40 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -830,13 +830,6 @@ void rtl8192_rx_enable(struct net_device *dev)
rtl8192_rx_initiate(dev);
 }
 
-
-void rtl8192_tx_enable(struct net_device *dev)
-{
-}
-
-
-
 void rtl8192_rtx_disable(struct net_device *dev)
 {
u8 cmd;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 10/20] staging:rtl8192u: Rename PHY_Beacon_RSSI_SLID_WIN_MAX - Style

2018-08-31 Thread John Whitmore
Rename the Macro PHY_Beacon_RSSI_SLID_WIN_MAX to
PHY_BEACON_RSSI_SLID_WIN_MAX, this clears the checkpatch issue with
CamelCase naming.

This is purely a coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 528c50be3894..87c1a69b2e1c 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -150,7 +150,7 @@ extern u32 rt_global_debug_component;
 #define RTL819X_DEFAULT_RF_TYPE RF_1T2R
 
 #define IEEE80211_WATCH_DOG_TIME2000
-#definePHY_Beacon_RSSI_SLID_WIN_MAX10
+#definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
 #defineOFDM_Table_Length   19
 #defineCCK_Table_length12
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dd87cee6604b..4d43176bdb6c 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3997,15 +3997,15 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
 
if (pprevious_stats->bPacketBeacon) {
/* record the beacon pwdb to the sliding window. */
-   if (slide_beacon_adc_pwdb_statistics++ >= 
PHY_Beacon_RSSI_SLID_WIN_MAX) {
-   slide_beacon_adc_pwdb_statistics = 
PHY_Beacon_RSSI_SLID_WIN_MAX;
+   if (slide_beacon_adc_pwdb_statistics++ >= 
PHY_BEACON_RSSI_SLID_WIN_MAX) {
+   slide_beacon_adc_pwdb_statistics = 
PHY_BEACON_RSSI_SLID_WIN_MAX;
last_beacon_adc_pwdb = 
priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index];
priv->stats.Slide_Beacon_Total -= last_beacon_adc_pwdb;
}
priv->stats.Slide_Beacon_Total += pprevious_stats->RxPWDBAll;
priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index] = 
pprevious_stats->RxPWDBAll;
slide_beacon_adc_pwdb_index++;
-   if (slide_beacon_adc_pwdb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
+   if (slide_beacon_adc_pwdb_index >= PHY_BEACON_RSSI_SLID_WIN_MAX)
slide_beacon_adc_pwdb_index = 0;
pprevious_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total / 
slide_beacon_adc_pwdb_statistics;
if (pprevious_stats->RxPWDBAll >= 3)
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 14/20] staging:rtl8192u: Rename Offset - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'Offset' to 'offset', this clears the
checkpatch issue with CamelCase naming.

This is a coding style change which should not impact runtime code
execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 9931ede1524b..8aaea1d8cf50 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -159,7 +159,7 @@ extern u32 rt_global_debug_component;
 struct tx_desc_819x_usb {
/* DWORD 0 */
u16 pkt_size;
-   u8  Offset;
+   u8  offset;
u8  Reserved0:3;
u8  CmdInit:1;
u8  LastSeg:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 2a3cb0f1ac07..d4af6cc01fc6 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1516,7 +1516,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* DWORD 0 */
tx_desc->LINIP = 0;
tx_desc->CmdInit = 1;
-   tx_desc->Offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
+   tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
/*DWORD 1*/
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 15/20] staging:rtl8192u: Rename Reserved... structure members - Style

2018-08-31 Thread John Whitmore
Rename the 'Reserved...' members of the 'tx_desc_819x_usb' structure
to 'reserved...'. This change clears the checkpatch issue with
CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 8aaea1d8cf50..5d643870a1e3 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -160,7 +160,7 @@ struct tx_desc_819x_usb {
/* DWORD 0 */
u16 pkt_size;
u8  offset;
-   u8  Reserved0:3;
+   u8  reserved0:3;
u8  CmdInit:1;
u8  LastSeg:1;
u8  FirstSeg:1;
@@ -177,7 +177,7 @@ struct tx_desc_819x_usb {
u8  PIFS:1;
u8  QueueSelect:5;
u8  NoACM:1;
-   u8  Reserved1:2;
+   u8  reserved1:2;
u8  SecCAMID:5;
u8  SecDescAssign:1;
u8  SecType:2;
@@ -185,13 +185,13 @@ struct tx_desc_819x_usb {
/* DWORD 2 */
u16 TxBufferSize;
u8  ResvForPaddingLen:7;
-   u8  Reserved3:1;
-   u8  Reserved4;
+   u8  reserved3:1;
+   u8  reserved4;
 
/* DWORD 3, 4, 5 */
-   u32 Reserved5;
-   u32 Reserved6;
-   u32 Reserved7;
+   u32 reserved5;
+   u32 reserved6;
+   u32 reserved7;
 };
 
 struct tx_desc_cmd_819x_usb {
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 19/20] staging:rtl8192u: Rename LINIP - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'LINIP' to 'linip', this change is to
conform to the coding style guidelines, member variables in
lowercase.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 66efa59eabf0..68e82b32a88e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -164,7 +164,7 @@ struct tx_desc_819x_usb {
u8  cmd_init:1;
u8  last_seg:1;
u8  first_seg:1;
-   u8  LINIP:1;
+   u8  linip:1;
u8  OWN:1;
 
/* DWORD 1 */
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index a4d1b55a1117..911d0214b48a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1514,7 +1514,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* Fill Tx descriptor */
memset(tx_desc, 0, sizeof(struct tx_desc_819x_usb));
/* DWORD 0 */
-   tx_desc->LINIP = 0;
+   tx_desc->linip = 0;
tx_desc->cmd_init = 1;
tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 16/20] staging:rtl8192u: Rename CmdInit - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'CmdInit, to 'cmd_init', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should have no impact on
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 5d643870a1e3..4d29b7427a0e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -161,7 +161,7 @@ struct tx_desc_819x_usb {
u16 pkt_size;
u8  offset;
u8  reserved0:3;
-   u8  CmdInit:1;
+   u8  cmd_init:1;
u8  LastSeg:1;
u8  FirstSeg:1;
u8  LINIP:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index d4af6cc01fc6..b385c686370b 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1515,7 +1515,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
memset(tx_desc, 0, sizeof(struct tx_desc_819x_usb));
/* DWORD 0 */
tx_desc->LINIP = 0;
-   tx_desc->CmdInit = 1;
+   tx_desc->cmd_init = 1;
tx_desc->offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 18/20] staging:rtl8192u: Rename FirstSeg - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'FirstSeg' to 'first_seg', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change and as such should not impact
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 672cbfa688f7..66efa59eabf0 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -163,7 +163,7 @@ struct tx_desc_819x_usb {
u8  reserved0:3;
u8  cmd_init:1;
u8  last_seg:1;
-   u8  FirstSeg:1;
+   u8  first_seg:1;
u8  LINIP:1;
u8  OWN:1;
 
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dfbba1177470..a4d1b55a1117 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1556,7 +1556,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
 * all of the descriptors
 */
/* DWORD 0 */
-   tx_desc->FirstSeg = 1;
+   tx_desc->first_seg = 1;
tx_desc->last_seg = 1;
tx_desc->OWN = 1;
 
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 17/20] staging:rtl8192u: Rename LastSeg - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'LastSeg' to 'last_seg', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 4d29b7427a0e..672cbfa688f7 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -162,7 +162,7 @@ struct tx_desc_819x_usb {
u8  offset;
u8  reserved0:3;
u8  cmd_init:1;
-   u8  LastSeg:1;
+   u8  last_seg:1;
u8  FirstSeg:1;
u8  LINIP:1;
u8  OWN:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b385c686370b..dfbba1177470 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1557,7 +1557,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
 */
/* DWORD 0 */
tx_desc->FirstSeg = 1;
-   tx_desc->LastSeg = 1;
+   tx_desc->last_seg = 1;
tx_desc->OWN = 1;
 
/* DWORD 2 */
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 05/20] staging:rtl8192u: Rename RTL819xU_MODULE_NAME - Style

2018-08-31 Thread John Whitmore
Rename the MACRO RTL819xU_MODULE_NAME to RTL819XU_MODULE_NAME, this
clears the checkpatch issue with CamelCase naming.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 4dcfcb4d3911..81a7072a6285 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -40,7 +40,7 @@
 #include "ieee80211/ieee80211.h"
 
 #define RTL8192U
-#define RTL819xU_MODULE_NAME "rtl819xU"
+#define RTL819XU_MODULE_NAME "rtl819xU"
 /* HW security */
 #define MAX_KEY_LEN 61
 #define KEY_BUF_SIZE5
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 98bb40c50f40..b3d32ea29fee 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -128,7 +128,7 @@ static void rtl8192_usb_disconnect(struct usb_interface 
*intf);
 
 
 static struct usb_driver rtl8192_usb_driver = {
-   .name   = RTL819xU_MODULE_NAME,   /* Driver name   */
+   .name   = RTL819XU_MODULE_NAME,   /* Driver name   */
.id_table   = rtl8192_usb_id_tbl, /* PCI_ID table  */
.probe  = rtl8192_usb_probe,  /* probe fn  */
.disconnect = rtl8192_usb_disconnect, /* remove fn */
@@ -627,7 +627,7 @@ static int __maybe_unused proc_get_stats_rx(struct seq_file 
*m, void *v)
 static void rtl8192_proc_module_init(void)
 {
RT_TRACE(COMP_INIT, "Initializing proc filesystem");
-   rtl8192_proc = proc_mkdir(RTL819xU_MODULE_NAME, init_net.proc_net);
+   rtl8192_proc = proc_mkdir(RTL819XU_MODULE_NAME, init_net.proc_net);
 }
 
 static void rtl8192_proc_init_one(struct net_device *dev)
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 00/20] staging:rtl8192u: r8192U.h cleanup - Style

2018-08-31 Thread John Whitmore
Yet another series of patchs to cleanup and clear some checkpatch
isses, this time the file r8192U.h. These are all simple changes
which are mostly renaming variables. A MACRO has been removed as
it's not used in the code, and added SPDX-License-Identifier.

John Whitmore (20):
  staging:rtl8192u: Remove write_cam() - Style
  staging:rtl8192u: Remove read_cam() - Style
  staging:rtl8192u: Remove unused functions - Style
  staging:rtl8192u: Add SPDX-License-Identifier - Style
  staging:rtl8192u: Rename RTL819xU_MODULE_NAME - Style
  staging:rtl8192u: Rename Rx_Smooth_Factor - Style
  staging:rtl8192u: Refactor RT_TRACE - Style
  staging:rtl8192u: Fix space characters - Style
  staging:rtl8192u: Remove RT_DEBUG_DATA - Style
  staging:rtl8192u: Rename PHY_Beacon_RSSI_SLID_WIN_MAX - Style
  staging:rtl8192u: Rename OFDM_Table_Length - Style
  staging:rtl8192u: Rename CCK_Table_length - Style
  staging:rtl8192u: Rename PktSize Style
  staging:rtl8192u: Rename Offset - Style
  staging:rtl8192u: Rename Reserved... structure members - Style
  staging:rtl8192u: Rename CmdInit - Style
  staging:rtl8192u: Rename LastSeg - Style
  staging:rtl8192u: Rename FirstSeg - Style
  staging:rtl8192u: Rename LINIP - Style
  staging:rtl8192u: Rename OWN - Style

 drivers/staging/rtl8192u/r8192U.h  | 82 --
 drivers/staging/rtl8192u/r8192U_core.c | 67 +++--
 drivers/staging/rtl8192u/r8192U_dm.c   | 22 +++
 3 files changed, 58 insertions(+), 113 deletions(-)

-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 01/20] staging:rtl8192u: Remove write_cam() - Style

2018-08-31 Thread John Whitmore
Remove the function write_cam() as it is unused.

Simple style change which should not impact runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 1 -
 drivers/staging/rtl8192u/r8192U_core.c | 7 ---
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 1b51601df1ee..77324a471de1 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1092,7 +1092,6 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb);
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb);
 
 u32 read_cam(struct net_device *dev, u8 addr);
-void write_cam(struct net_device *dev, u8 addr, u32 data);
 
 int read_nic_byte(struct net_device *dev, int x, u8 *data);
 int read_nic_byte_E(struct net_device *dev, int x, u8 *data);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 6b22aaa40ff9..caa618a845df 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -237,13 +237,6 @@ static void CamResetAllEntry(struct net_device *dev)
write_nic_dword(dev, RWCAM, ulcommand);
 }
 
-
-void write_cam(struct net_device *dev, u8 addr, u32 data)
-{
-   write_nic_dword(dev, WCAMI, data);
-   write_nic_dword(dev, RWCAM, BIT(31) | BIT(16) | (addr & 0xff));
-}
-
 u32 read_cam(struct net_device *dev, u8 addr)
 {
u32 data;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 04/20] staging:rtl8192u: Add SPDX-License-Identifier - Style

2018-08-31 Thread John Whitmore
Add SPDX-License-Identifier tag to the start of header file. This is
a coding style change which should have no impact on runtime code
execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index b3e6ce2acedb..4dcfcb4d3911 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * This is part of rtl8187 OpenSource driver.
  * Copyright (C) Andrea Merello 2004-2005  
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 07/20] staging:rtl8192u: Refactor RT_TRACE - Style

2018-08-31 Thread John Whitmore
Refactor the MACRO RT_TRACE to add parentheses around the parameter
'component', this clears the checkpatch warning with respect to
precedence issues.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index b5ad69af8dac..c613894a6088 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -52,7 +52,7 @@
 extern u32 rt_global_debug_component;
 #define RT_TRACE(component, x, args...) \
do {\
-   if (rt_global_debug_component & component)  \
+   if (rt_global_debug_component & (component))\
pr_debug("RTL8192U: " x "\n", ##args);  \
} while (0)
 
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 02/20] staging:rtl8192u: Remove read_cam() - Style

2018-08-31 Thread John Whitmore
Remove the function read_cam(), as it is unused in code.

Simple style change which should not impact runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 --
 drivers/staging/rtl8192u/r8192U_core.c | 9 -
 2 files changed, 11 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 77324a471de1..70bbd1fadcca 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1091,8 +1091,6 @@ bool init_firmware(struct net_device *dev);
 short rtl819xU_tx_cmd(struct net_device *dev, struct sk_buff *skb);
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb);
 
-u32 read_cam(struct net_device *dev, u8 addr);
-
 int read_nic_byte(struct net_device *dev, int x, u8 *data);
 int read_nic_byte_E(struct net_device *dev, int x, u8 *data);
 int read_nic_dword(struct net_device *dev, int x, u32 *data);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index caa618a845df..12783b88eb58 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -237,15 +237,6 @@ static void CamResetAllEntry(struct net_device *dev)
write_nic_dword(dev, RWCAM, ulcommand);
 }
 
-u32 read_cam(struct net_device *dev, u8 addr)
-{
-   u32 data;
-
-   write_nic_dword(dev, RWCAM, 0x8000 | (addr & 0xff));
-   read_nic_dword(dev, 0xa8, &data);
-   return data;
-}
-
 int write_nic_byte_E(struct net_device *dev, int indx, u8 data)
 {
int status;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 13/20] staging:rtl8192u: Rename PktSize Style

2018-08-31 Thread John Whitmore
Rename the member variable 'PktSize' to 'pkt_size', this change
clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index e86a4b35a1f4..9931ede1524b 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -158,7 +158,7 @@ extern u32 rt_global_debug_component;
 /* For rtl819x */
 struct tx_desc_819x_usb {
/* DWORD 0 */
-   u16 PktSize;
+   u16 pkt_size;
u8  Offset;
u8  Reserved0:3;
u8  CmdInit:1;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 4d43176bdb6c..2a3cb0f1ac07 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1517,7 +1517,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
tx_desc->LINIP = 0;
tx_desc->CmdInit = 1;
tx_desc->Offset =  sizeof(struct tx_fwinfo_819x_usb) + 8;
-   tx_desc->PktSize = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
+   tx_desc->pkt_size = (skb->len - TX_PACKET_SHIFT_BYTES) & 0x;
 
/*DWORD 1*/
tx_desc->SecCAMID = 0;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 20/20] staging:rtl8192u: Rename OWN - Style

2018-08-31 Thread John Whitmore
Rename the member variable 'OWN' to 'own', this is to comply with the
coding standard, where variables are named in lowercase.

This is a simple coding style change which should have no impact on
runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  | 2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 68e82b32a88e..f963b664e221 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -165,7 +165,7 @@ struct tx_desc_819x_usb {
u8  last_seg:1;
u8  first_seg:1;
u8  linip:1;
-   u8  OWN:1;
+   u8  own:1;
 
/* DWORD 1 */
u8  TxFWInfoSize;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 911d0214b48a..4d0f70ec31ac 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1558,7 +1558,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
/* DWORD 0 */
tx_desc->first_seg = 1;
tx_desc->last_seg = 1;
-   tx_desc->OWN = 1;
+   tx_desc->own = 1;
 
/* DWORD 2 */
tx_desc->TxBufferSize = (u32)(skb->len - USB_HWDESC_HEADER_LEN);
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 08/20] staging:rtl8192u: Fix space characters - Style

2018-08-31 Thread John Whitmore
Fix the spacing issues, remove space after cast operation, and replace
spaces at start of line with tab.

These changes are purely coding style changes to resolve checkpatch
issues. There should be no impact on runtime code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index c613894a6088..e65a893fd084 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -112,7 +112,7 @@ extern u32 rt_global_debug_component;
do {\
if ((rt_global_debug_component & (level)) == (level)) { \
int i;  \
-   u8 *pdata = (u8 *) data;\
+   u8 *pdata = (u8 *)data; \
pr_debug("RTL8192U: %s()\n", __func__); \
for (i = 0; i < (int)(datalen); i++) {  \
printk("%2x ", pdata[i]);   \
@@ -877,9 +877,9 @@ typedef struct r8192_priv {
int rx_inx;
 #endif
 
-   struct sk_buff_head rx_queue;
-   struct sk_buff_head skb_queue;
-   struct work_struct qos_activate;
+   struct sk_buff_head rx_queue;
+   struct sk_buff_head skb_queue;
+   struct work_struct qos_activate;
short  tx_urb_index;
atomic_t tx_pending[0x10]; /* UART_PRIORITY + 1 */
 
@@ -1027,7 +1027,7 @@ typedef struct r8192_priv {
u8  nrxAMPDU_aggr_num;
 
/* For gpio */
-bool bHwRadioOff;
+   bool bHwRadioOff;
 
u32 reset_count;
bool bpbc_pressed;
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 11/20] staging:rtl8192u: Rename OFDM_Table_Length - Style

2018-08-31 Thread John Whitmore
Rename the defined constant OFDM_Table_Length to OFDM_TABLE_LENGTH,
this clears the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h| 2 +-
 drivers/staging/rtl8192u/r8192U_dm.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 87c1a69b2e1c..6edbc8146e82 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -152,7 +152,7 @@ extern u32 rt_global_debug_component;
 #define IEEE80211_WATCH_DOG_TIME2000
 #definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
-#defineOFDM_Table_Length   19
+#defineOFDM_TABLE_LENGTH   19
 #defineCCK_Table_length12
 
 /* For rtl819x */
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 5fb5f583f703..19b3b11c5edb 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -454,7 +454,7 @@ static void dm_bandwidth_autoswitch(struct net_device *dev)
 }  /* dm_BandwidthAutoSwitch */
 
 /* OFDM default at 0db, index=6. */
-static u32 OFDMSwingTable[OFDM_Table_Length] = {
+static u32 OFDMSwingTable[OFDM_TABLE_LENGTH] = {
0x7f8001fe, /* 0, +6db */
0x71c001c7, /* 1, +5db */
0x65400195, /* 2, +4db */
@@ -672,7 +672,7 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
if (!priv->btxpower_trackingInit) {
/* Query OFDM default setting */
tmpRegA = rtl8192_QueryBBReg(dev, rOFDM0_XATxIQImbalance, 
bMaskDWord);
-   for (i = 0; i < OFDM_Table_Length; i++) { /* find the index */
+   for (i = 0; i < OFDM_TABLE_LENGTH; i++) { /* find the index */
if (tmpRegA == OFDMSwingTable[i]) {
priv->OFDM_index = (u8)i;
RT_TRACE(COMP_POWER_TRACKING, "Initial reg0x%x 
= 0x%x, OFDM_index=0x%x\n",
@@ -716,8 +716,8 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
if (priv->ThermalMeter[0] >= (u8)tmpRegA) { /* lower temperature */
tmpOFDMindex = tmpCCK20Mindex = 
6+(priv->ThermalMeter[0]-(u8)tmpRegA);
tmpCCK40Mindex = tmpCCK20Mindex - 6;
-   if (tmpOFDMindex >= OFDM_Table_Length)
-   tmpOFDMindex = OFDM_Table_Length-1;
+   if (tmpOFDMindex >= OFDM_TABLE_LENGTH)
+   tmpOFDMindex = OFDM_TABLE_LENGTH - 1;
if (tmpCCK20Mindex >= CCK_Table_length)
tmpCCK20Mindex = CCK_Table_length-1;
if (tmpCCK40Mindex >= CCK_Table_length)
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 09/20] staging:rtl8192u: Remove RT_DEBUG_DATA - Style

2018-08-31 Thread John Whitmore
Remove the RT_DEBUG_DATA Macro. The macro causes a number of
checkpatch issues, and is not actually used in code, so can simply
be removed without issue.

This is a coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index e65a893fd084..528c50be3894 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -103,28 +103,8 @@ extern u32 rt_global_debug_component;
 #expr, __FILE__, __func__, __LINE__);  \
}   \
} while (0)
-/*
- * Debug out data buf.
- * If you want to print DATA buffer related BA,
- * please set ieee80211_debug_level to DATA|BA
- */
-#define RT_DEBUG_DATA(level, data, datalen) \
-   do {\
-   if ((rt_global_debug_component & (level)) == (level)) { \
-   int i;  \
-   u8 *pdata = (u8 *)data; \
-   pr_debug("RTL8192U: %s()\n", __func__); \
-   for (i = 0; i < (int)(datalen); i++) {  \
-   printk("%2x ", pdata[i]);   \
-   if ((i+1)%16 == 0)  \
-   printk("\n");   \
-   }   \
-   printk("\n");   \
-   }   \
-   } while (0)
 #else
 #define RTL8192U_ASSERT(expr) do {} while (0)
-#define RT_DEBUG_DATA(level, data, datalen) do {} while (0)
 #endif /* RTL8169_DEBUG */
 
 /* Queue Select Value in TxDesc */
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 12/20] staging:rtl8192u: Rename CCK_Table_length - Style

2018-08-31 Thread John Whitmore
Rename the constant CCK_Table_length to CCK_TABLE_LENGTH, this clears
the checkpatch issue with CamelCase naming.

This is a simple coding style change which should not impact runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h|  2 +-
 drivers/staging/rtl8192u/r8192U_dm.c | 14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 6edbc8146e82..e86a4b35a1f4 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -153,7 +153,7 @@ extern u32 rt_global_debug_component;
 #definePHY_BEACON_RSSI_SLID_WIN_MAX10
 /* For Tx Power Tracking */
 #defineOFDM_TABLE_LENGTH   19
-#defineCCK_Table_length12
+#defineCCK_TABLE_LENGTH12
 
 /* For rtl819x */
 struct tx_desc_819x_usb {
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 19b3b11c5edb..874da0620936 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -476,7 +476,7 @@ static u32 OFDMSwingTable[OFDM_TABLE_LENGTH] = {
0x1040  /* 18, -12db */
 };
 
-static u8  CCKSwingTable_Ch1_Ch13[CCK_Table_length][8] = {
+static u8  CCKSwingTable_Ch1_Ch13[CCK_TABLE_LENGTH][8] = {
{0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04},   /* 0, +0db ===> 
CCK40M default */
{0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03},   /* 1, -1db */
{0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03},   /* 2, -2db */
@@ -491,7 +491,7 @@ static u8   CCKSwingTable_Ch1_Ch13[CCK_Table_length][8] = {
{0x0f, 0x0f, 0x0d, 0x0b, 0x08, 0x05, 0x03, 0x01}/* 11, -11db */
 };
 
-static u8  CCKSwingTable_Ch14[CCK_Table_length][8] = {
+static u8  CCKSwingTable_Ch14[CCK_TABLE_LENGTH][8] = {
{0x36, 0x35, 0x2e, 0x1b, 0x00, 0x00, 0x00, 0x00},   /* 0, +0db  
===> CCK40M default */
{0x30, 0x2f, 0x29, 0x18, 0x00, 0x00, 0x00, 0x00},   /* 1, -1db */
{0x2b, 0x2a, 0x25, 0x15, 0x00, 0x00, 0x00, 0x00},   /* 2, -2db */
@@ -682,7 +682,7 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
 
/* Query CCK default setting From 0xa22 */
TempCCk = rtl8192_QueryBBReg(dev, rCCK0_TxFilter1, bMaskByte2);
-   for (i = 0; i < CCK_Table_length; i++) {
+   for (i = 0; i < CCK_TABLE_LENGTH; i++) {
if (TempCCk == (u32)CCKSwingTable_Ch1_Ch13[i][0]) {
priv->CCK_index = (u8) i;
RT_TRACE(COMP_POWER_TRACKING, "Initial reg0x%x 
= 0x%x, CCK_index=0x%x\n",
@@ -718,10 +718,10 @@ static void 
dm_TXPowerTrackingCallback_ThermalMeter(struct net_device *dev)
tmpCCK40Mindex = tmpCCK20Mindex - 6;
if (tmpOFDMindex >= OFDM_TABLE_LENGTH)
tmpOFDMindex = OFDM_TABLE_LENGTH - 1;
-   if (tmpCCK20Mindex >= CCK_Table_length)
-   tmpCCK20Mindex = CCK_Table_length-1;
-   if (tmpCCK40Mindex >= CCK_Table_length)
-   tmpCCK40Mindex = CCK_Table_length-1;
+   if (tmpCCK20Mindex >= CCK_TABLE_LENGTH)
+   tmpCCK20Mindex = CCK_TABLE_LENGTH - 1;
+   if (tmpCCK40Mindex >= CCK_TABLE_LENGTH)
+   tmpCCK40Mindex = CCK_TABLE_LENGTH - 1;
} else {
tmpval = (u8)tmpRegA - priv->ThermalMeter[0];
 
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 06/20] staging:rtl8192u: Rename Rx_Smooth_Factor - Style

2018-08-31 Thread John Whitmore
Rename the MACRO Rx_Smooth_Factor to RX_SMOOTH_FACTOR, this clears the
checkpatch issue with CamelCase naming.

This is a coding style change which should have no impact on runtime
code execution.

Signed-off-by: John Whitmore 
---
 drivers/staging/rtl8192u/r8192U.h  |  2 +-
 drivers/staging/rtl8192u/r8192U_core.c | 20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 81a7072a6285..b5ad69af8dac 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -45,7 +45,7 @@
 #define MAX_KEY_LEN 61
 #define KEY_BUF_SIZE5
 
-#defineRx_Smooth_Factor20
+#defineRX_SMOOTH_FACTOR20
 #define DMESG(x, a...)
 #define DMESGW(x, a...)
 #define DMESGE(x, a...)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b3d32ea29fee..dd87cee6604b 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3975,13 +3975,13 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,

pprevious_stats->RxMIMOSignalStrength[rfpath];
if (pprevious_stats->RxMIMOSignalStrength[rfpath]  > 
priv->stats.rx_rssi_percentage[rfpath]) {
priv->stats.rx_rssi_percentage[rfpath] =
-   
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+   
((priv->stats.rx_rssi_percentage[rfpath] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (RX_SMOOTH_FACTOR);
priv->stats.rx_rssi_percentage[rfpath] = 
priv->stats.rx_rssi_percentage[rfpath]  + 1;
} else {
priv->stats.rx_rssi_percentage[rfpath] =
-   
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+   
((priv->stats.rx_rssi_percentage[rfpath] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (RX_SMOOTH_FACTOR);
}
RT_TRACE(COMP_DBG,
 "priv->stats.rx_rssi_percentage[rfPath]  = 
%d\n",
@@ -4026,13 +4026,13 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
pprevious_stats->RxPWDBAll;
if (pprevious_stats->RxPWDBAll > 
(u32)priv->undecorated_smoothed_pwdb) {
priv->undecorated_smoothed_pwdb =
-   (((priv->undecorated_smoothed_pwdb) * 
(Rx_Smooth_Factor - 1)) +
-(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
+   (((priv->undecorated_smoothed_pwdb) * 
(RX_SMOOTH_FACTOR - 1)) +
+(pprevious_stats->RxPWDBAll)) / 
(RX_SMOOTH_FACTOR);
priv->undecorated_smoothed_pwdb = 
priv->undecorated_smoothed_pwdb + 1;
} else {
priv->undecorated_smoothed_pwdb =
-   (((priv->undecorated_smoothed_pwdb) * 
(Rx_Smooth_Factor - 1)) +
-(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
+   (((priv->undecorated_smoothed_pwdb) * 
(RX_SMOOTH_FACTOR - 1)) +
+(pprevious_stats->RxPWDBAll)) / 
(RX_SMOOTH_FACTOR);
}
}
 
@@ -4075,8 +4075,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
if 
(priv->stats.rx_evm_percentage[nspatial_stream] == 0) /* initialize */

priv->stats.rx_evm_percentage[nspatial_stream] = 
pprevious_stats->RxMIMOSignalQuality[nspatial_stream];

priv->stats.rx_evm_percentage[nspatial_stream] =
-   
((priv->stats.rx_evm_percentage[nspatial_stream] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalQuality[nspatial_stream] * 1)) / 
(Rx_Smooth_Factor);
+   
((priv->stats.rx_evm_percentage[nspatial_stream] * (RX_SMOOTH_FACTOR - 1)) +
+
(pprevious_stats->RxMIMOSignalQuality[nspatial_stream] * 1)) / 
(RX_SMOOTH_FACTOR);
}

Re: [PATCH v6 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array

2018-08-31 Thread Peter Rosin
On 2018-09-01 00:56, Janusz Krzysztofik wrote:
> Most users of get/set array functions iterate consecutive bits of data,
> usually a single integer, while processing array of results obtained
> from, or building an array of values to be passed to those functions.
> Save time wasted on those iterations by changing the functions' API to
> accept bitmaps.
> 
> All current users are updated as well.
> 
> More benefits from the change are expected as soon as planned support
> for accepting/passing those bitmaps directly from/to respective GPIO
> chip callbacks if applicable is implemented.

> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c 
> b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 401308e3d036..e28ddc2d 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -22,18 +22,16 @@ struct gpiomux {
>   struct i2c_mux_gpio_platform_data data;
>   unsigned gpio_base;
>   struct gpio_desc **gpios;
> - int *values;
>  };
>  
>  static void i2c_mux_gpio_set(const struct gpiomux *mux, unsigned val)
>  {
> - int i;
> -
> - for (i = 0; i < mux->data.n_gpios; i++)
> - mux->values[i] = (val >> i) & 1;
> + DECLARE_BITMAP(value_bitmap, mux->data.n_gpios);

Picking a random driver for this comment, it applies to many of them.

I think this creates a VLA? Can't you, for the bit-count, just go with
BITS_PER_TYPE(unsigned)? Or whatever is appropriate for the driver
in question.

Also, I find that where you use DECLARE_BITMAP, the _bitmap suffix is
just noise and I would very much like to zap it.

Cheers,
Peter

> + 
> + *value_bitmap = val;
>  
>   gpiod_set_array_value_cansleep(mux->data.n_gpios,
> -mux->gpios, mux->values);
> +mux->gpios, value_bitmap);
>  }
>  
>  static int i2c_mux_gpio_select(struct i2c_mux_core *muxc, u32 chan)
> @@ -182,15 +180,13 @@ static int i2c_mux_gpio_probe(struct platform_device 
> *pdev)
>   return -EPROBE_DEFER;
>  
>   muxc = i2c_mux_alloc(parent, &pdev->dev, mux->data.n_values,
> -  mux->data.n_gpios * sizeof(*mux->gpios) +
> -  mux->data.n_gpios * sizeof(*mux->values), 0,
> +  mux->data.n_gpios * sizeof(*mux->gpios), 0,
>i2c_mux_gpio_select, NULL);
>   if (!muxc) {
>   ret = -ENOMEM;
>   goto alloc_failed;
>   }
>   mux->gpios = muxc->priv;
> - mux->values = (int *)(mux->gpios + mux->data.n_gpios);
>   muxc->priv = mux;
>  
>   platform_set_drvdata(pdev, muxc);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()

2018-08-31 Thread David Miller
From: Dexuan Cui 
Date: Thu, 30 Aug 2018 05:42:13 +

> 
> This patch fixes the race between netvsc_probe() and
> rndis_set_subchannel(), which can cause a deadlock.
> 
> These are the related 3 paths which show the deadlock:
 ...
> Before path #1 finishes, path #2 can start to run, because just before
> the "bus_probe_device(dev);" in device_add() in path #1, there is a line
> "object_uevent(&dev->kobj, KOBJ_ADD);", so systemd-udevd can
> immediately try to load hv_netvsc and hence path #2 can start to run.
> 
> Next, path #2 offloads the subchannal's initialization to a workqueue,
> i.e. path #3, so we can end up in a deadlock situation like this:
> 
> Path #2 gets the device lock, and is trying to get the rtnl lock;
> Path #3 gets the rtnl lock and is waiting for all the subchannel messages
> to be processed;
> Path #1 is trying to get the device lock, but since #2 is not releasing
> the device lock, path #1 has to sleep; since the VMBus messages are
> processed one by one, this means the sub-channel messages can't be
> procedded, so #3 has to sleep with the rtnl lock held, and finally #2
> has to sleep... Now all the 3 paths are sleeping and we hit the deadlock.
> 
> With the patch, we can make sure #2 gets both the device lock and the
> rtnl lock together, gets its job done, and releases the locks, so #1
> and #3 will not be blocked for ever.
> 
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Signed-off-by: Dexuan Cui 

Applied and queued up for -stable.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel