Re: [PATCH] staging: fsl-mc: be consistent when checking strcmp() returns

[Greg KH]

On Tue, Aug 22, 2017 at 07:33:45PM -0700, Joe Perches wrote:
> On Tue, 2017-08-22 at 18:40 -0700, Greg KH wrote:
> > On Thu, Aug 17, 2017 at 02:55:04PM +0300, laurentiu.tu...@nxp.com wrote:
> > > From: Laurentiu Tudor 
> > > 
> > > Throughout the driver we use == 0 / != 0 to check strcmp() returns except
> > > this place, so fix it.
> > 
> > You will just get someone else fixing it as it is not what checkpatch
> > recommends, so just leave it as-is please.
> 
> No.  That's not correct.
> 
> checkpatch does not make a recommendation about
> style use with the strcmp family of functions.

Ah, ok, nevermind then...

Laurentiu, can you resend this?

thanks,

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

Re: [PATCH 1/2] staging: android: ion: Remove extra line (checkpatch)

[Greg KH]

On Tue, Aug 22, 2017 at 10:55:36PM -0400, Nick Fox wrote:
> Remove extra blank line (reported by checkpatch.pl)
> 
> Signed-off-by: Nick Fox 
> ---
>  drivers/staging/android/ion/ion_cma_heap.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
> index a0949bc0dcf4..b06f4cee9c7c 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -31,7 +31,6 @@ struct ion_cma_heap {
>  
>  #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>  
> -

Also doesn't apply...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: android: ion: Change argument to kmalloc (checkpatch)

[Greg KH]

On Tue, Aug 22, 2017 at 10:55:37PM -0400, Nick Fox wrote:
> Change argument to kmalloc() to fix style issue, reported by checkpatch
> 
> Signed-off-by: Nick Fox 
> ---
>  drivers/staging/android/ion/ion_cma_heap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
> index b06f4cee9c7c..bb2c1449cbcf 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -45,7 +45,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
> ion_buffer *buffer,
>   if (!pages)
>   return -ENOMEM;
>  
> - table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + table = kmalloc(sizeof(*table), GFP_KERNEL);

This doesn't apply to linux-next at all, what tree are you working
against?  Always work off of the correct tree please...

thanks,

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Greg KH]

On Tue, Aug 22, 2017 at 08:14:10PM -0700, John Stultz wrote:
> On Tue, Aug 22, 2017 at 8:01 PM, Jisheng Zhang  wrote:
> > On Tue, 22 Aug 2017 19:57:04 -0700 John Stultz wrote:
> >
> >> On Tue, Aug 22, 2017 at 7:56 PM, John Stultz  
> >> wrote:
> >> > On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  
> >> > wrote:
> >> >> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> >> >>
> >> >>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> >> >>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> >> >>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> >> >>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 
> >> >>> > ("ARM:
> >> >>> > 8091/2: add get_user() support for 8 byte types") has added the
> >> >>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable 
> >> >>> > on
> >> >>> > 32bit ARM
> >> >>>
> >> >>> Ok, but:
> >> >>>
> >> >>> >
> >> >>> > Signed-off-by: Jisheng Zhang 
> >> >>> > ---
> >> >>> >  drivers/android/Kconfig | 2 +-
> >> >>> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>> >
> >> >>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> >> >>> > index 832e885349b1..aca5dc30b97b 100644
> >> >>> > --- a/drivers/android/Kconfig
> >> >>> > +++ b/drivers/android/Kconfig
> >> >>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >> >>> >   therefore logically separated from the other devices.
> >> >>> >
> >> >>> >  config ANDROID_BINDER_IPC_32BIT
> >> >>> > -   bool
> >> >>> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> >> >>> > depends on !64BIT && ANDROID_BINDER_IPC
> >> >>>
> >> >>> You don't actually change the depends line :(
> >> >>>
> >> >>> Please fix up, and test it, and then resend.
> >> >>
> >> >> IHOM, the dependency is correct: 64bit platforms don't support
> >> >> ANDROID_BINDER_IPC_32BIT. What do you think?
> >> >
> >> > I think this indicates the commit message is unclear.
> >> >
> >> > Part of it is that the config is inverted from the description. The
> >> > patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> >> > just allows the option to be unselected, so that the 64bit ABI will be
> >> > used on 32bit systems.
> >> >
> >> > Conceptually I don't have an objection to the change (though maybe try
> >> > to rework the commit message), but I don't have anything to actually
> >> > test it on right now, so I'm hesitant to ack it.
> >>
> >> It might also be good to add some detail as to the motivation for this
> >> change? What benefit does it bring to 32bit platforms to use the newer
> >> 64bit ABI?
> >>
> >
> > To be honest, the motivation is just to add one more choice for 32bit
> > platform and let the code be tested under 32bit platform. Maybe we
> > could then remove ANDROID_BINDER_IPC_32BIT and the related code after
> > some time?
> 
> I'm mixed. It would be nice to deprecate the old 32bit ABI, but binder
> is a real Linux kernel interface now, so we don't break compatibility
> (at least if it affects anyone - which may be questionable here - not
> sure there's many upstream 32bit platforms concerned with running
> legacy Android builds).  But just adding the extra option just means
> there's yet another configuration to test and to keep working. So you
> may want to articulate the benefits better to make this worth the
> effort of doing a full transition.

Future versions of Android "might" be changing if they support, or not,
all of the different combinations of 32/64 bit apis.  So maybe we should
wait until a real solid direction with regards to this is published
before worrying about dropping anything...

thanks,

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Greg KH]

On Wed, Aug 23, 2017 at 10:34:20AM +0800, Jisheng Zhang wrote:
> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> 
> > On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> > > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> > > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> > > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> > > 8091/2: add get_user() support for 8 byte types") has added the
> > > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> > > 32bit ARM  
> > 
> > Ok, but:
> > 
> > > 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > >  drivers/android/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> > > index 832e885349b1..aca5dc30b97b 100644
> > > --- a/drivers/android/Kconfig
> > > +++ b/drivers/android/Kconfig
> > > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> > > therefore logically separated from the other devices.
> > >  
> > >  config ANDROID_BINDER_IPC_32BIT
> > > - bool
> > > + bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> > >   depends on !64BIT && ANDROID_BINDER_IPC  
> > 
> > You don't actually change the depends line :(
> > 
> > Please fix up, and test it, and then resend.
> 
> IHOM, the dependency is correct: 64bit platforms don't support
> ANDROID_BINDER_IPC_32BIT. What do you think?

I think your changelog text is totally wrong, please fix this up
properly and resend it if you think it is needed.

thanks,

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

Re: [PATCH] staging: olpc_dcon: Change fixed function names with "%s: ", __func__

[Greg Kroah-Hartman]

On Wed, Aug 23, 2017 at 01:06:52PM +0800, Shurong Zhang wrote:
> Replace hard-coded function names in strings with "%s", __func__
> in the olpc_dcon.c file. Issue found by checkpatch.pl.

What is up with the odd indentation?

And why did you send this twice?  Which patch should I use?  I'll just
drop both, please fix up and send a v2 properly.

thanks,

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

[PATCH] staging: olpc_dcon: Change fixed function names with "%s: ", __func__

[Shurong Zhang]

Replace hard-coded function names in strings with "%s", __func__
in the olpc_dcon.c file. Issue found by checkpatch.pl.

Signed-off-by: Shurong Zhang 
---
 drivers/staging/olpc_dcon/olpc_dcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c 
b/drivers/staging/olpc_dcon/olpc_dcon.c
index f7f3a78..3a8d99f 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -456,7 +456,7 @@ static ssize_t dcon_freeze_store(struct device *dev,
if (ret)
return ret;
 
-   pr_info("dcon_freeze_store: %lu\n", output);
+   pr_info("%s: %lu\n", __func__, output);
 
switch (output) {
case 0:
-- 
2.7.4



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

[PATCH] staging: olpc_dcon: Change fixed function names with "%s: ", __func__

[Shurong Zhang]

Replace hard-coded function names in strings with "%s", __func__ in the 
olpc_dcon.c file. Issue found by checkpatch.pl.

Signed-off-by: Shurong Zhang 
---
 drivers/staging/olpc_dcon/olpc_dcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c 
b/drivers/staging/olpc_dcon/olpc_dcon.c
index f7f3a78..3a8d99f 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -456,7 +456,7 @@ static ssize_t dcon_freeze_store(struct device *dev,
if (ret)
return ret;
 
-   pr_info("dcon_freeze_store: %lu\n", output);
+   pr_info("%s: %lu\n", __func__, output);
 
switch (output) {
case 0:
-- 
2.7.4



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

[PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

[Dexuan Cui]

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It uses VMBus ringbuffer as the
transportation layer.

With hv_sock, applications between the host (Windows 10, Windows Server
2016 or newer) and the guest can talk with each other using the traditional
socket APIs.

More info about Hyper-V Sockets is available here:

"Make your own integration services":
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service

The patch implements the necessary support in Linux guest by introducing a new
vsock transport for AF_VSOCK.

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Andy King 
Cc: Dmitry Torokhov 
Cc: George Zhang 
Cc: Jorgen Hansen 
Cc: Reilly Grant 
Cc: Stefan Hajnoczi 
Cc: Vitaly Kuznetsov 
Cc: Cathy Avery 
Cc: Rolf Neugebauer 
Cc: Marcelo Cerri 
---

Changes in v2:
Fixed hvs_stream_allow() for cid and the comments
Thanks Stefan Hajnoczi!

Added proper locking when using vsock_enqueue_accept()
Thanks Stefan Hajnoczi and Jorgen Hansen!

The previous v1 patch is not needed any more:
[PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

Another previous v1 patch is being discussed in another thread:
vsock: only load vmci transport on VMware hypervisor by default


 MAINTAINERS  |   1 +
 net/vmw_vsock/Kconfig|  12 +
 net/vmw_vsock/Makefile   |   3 +
 net/vmw_vsock/hyperv_transport.c | 888 +++
 4 files changed, 904 insertions(+)
 create mode 100644 net/vmw_vsock/hyperv_transport.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2db0f8c..dae0573 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6279,6 +6279,7 @@ F:drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/uio/uio_hv_generic.c
 F: drivers/video/fbdev/hyperv_fb.c
+F: net/vmw_vsock/hyperv_transport.c
 F: include/linux/hyperv.h
 F: tools/hv/
 F: Documentation/ABI/stable/sysfs-bus-vmbus
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index a7ae09d..3f52929 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -46,3 +46,15 @@ config VIRTIO_VSOCKETS_COMMON
  This option is selected by any driver which needs to access
  the virtio_vsock.  The module will be called
  vmw_vsock_virtio_transport_common.
+
+config HYPERV_VSOCKETS
+   tristate "Hyper-V transport for Virtual Sockets"
+   depends on VSOCKETS && HYPERV
+   help
+ This module implements a Hyper-V transport for Virtual Sockets.
+
+ Enable this transport if your Virtual Machine host supports Virtual
+ Sockets over Hyper-V VMBus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called hv_sock. If unsure, say N.
diff --git a/net/vmw_vsock/Makefile b/net/vmw_vsock/Makefile
index 09fc2eb..e63d574 100644
--- a/net/vmw_vsock/Makefile
+++ b/net/vmw_vsock/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_VSOCKETS) += vsock.o
 obj-$(CONFIG_VMWARE_VMCI_VSOCKETS) += vmw_vsock_vmci_transport.o
 obj-$(CONFIG_VIRTIO_VSOCKETS) += vmw_vsock_virtio_transport.o
 obj-$(CONFIG_VIRTIO_VSOCKETS_COMMON) += vmw_vsock_virtio_transport_common.o
+obj-$(CONFIG_HYPERV_VSOCKETS) += hv_sock.o
 
 vsock-y += af_vsock.o af_vsock_tap.o vsock_addr.o
 
@@ -11,3 +12,5 @@ vmw_vsock_vmci_transport-y += vmci_transport.o 
vmci_transport_notify.o \
 vmw_vsock_virtio_transport-y += virtio_transport.o
 
 vmw_vsock_virtio_transport_common-y += virtio_transport_common.o
+
+hv_sock-y += hyperv_transport.o
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
new file mode 100644
index 000..597fb25
--- /dev/null
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -0,0 +1,888 @@
+/*
+ * Hyper-V transport for vsock
+ *
+ * Hyper-V Sockets supplies a byte-stream based communication mechanism
+ * between the host and the VM. This driver implements the necessary
+ * support in the VM by introducing the new vsock transport.
+ *
+ * Copyright (c) 2017, Microsoft Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#include 
+#include 

RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

[Dexuan Cui]

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi 
> wrote:
> > ...
> > We *can* by looking at the destination CID.  Please take a look at
> > drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI
> handles
> > nested virt.
> >
> > It boils down to something like this:
> >
> >  static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
> >  int addr_len, int flags)
> >  {
> >  ...
> >  if (remote_addr.svm_cid == VMADDR_CID_HOST)
> >  transport = host_transport;
> >  else
> >  transport = guest_transport;
> >
> > It's easy for connect(2) but Jorgen mentioned it's harder for listen(2)
> > because the socket would need to listen on both transports.  We define
> > two new constants VMADDR_CID_LISTEN_FROM_GUEST and
> > VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can
> decide
> > which side to listen on.
> 
> If a socket is bound to VMADDR_CID_HOST, we would consider that socket as
> bound to the host side transport, so that would be the same as
> VMADDR_CID_LISTEN_FROM_GUEST. For the guest, we have
> IOCTL_VM_SOCKETS_GET_LOCAL_CID, so that could be used to get and bind
> a socket to the guest transport (VMCI will always return the guest CID as the
> local one, if the VMCI driver is used in a guest, and it looks like virtio 
> will do
> the same). We could treat VMADDR_CID_ANY as always being the guest
> transport, since that is the use case where you don’t know upfront what
> your CID is, if we don’t want to listen on all transports. So we would use the
> host transport, if a socket is bound to VMADDR_CID_HOST, or if there is no
> guest transport, and in all other cases use the guest transport. However,
> having a couple of symbolic names like you suggest certainly makes it more
> obvious, and could be used in combination with this. It would be a plus if
> existing applications would function as intended in most cases.
> 
> >   Or the listen socket could simply listen to
> > both sides.
> 
> The only problem here would be the potential for a guest and a host app to
> have a conflict wrt port numbers, even though they would be able to
> operate fine, if restricted to their appropriate transport.
> 
> Thanks,
> Jorgen

Hi Jorgen, Stefan,
Thank you for the detailed analysis!
You have a much better understanding than me about the complex
scenarios. Can you please work out a patch? :-)

IMO Linux driver of Hyper-V sockets is the simplest case, as we only have
the "to host" option (the host side driver of Hyper-V sockets runs on 
Windows kernel and I don't think the other hypervisors emulate
the full Hyper-V VMBus 4.0, which is required to support Hyper-V sockets).

-- Dexuan

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[John Stultz]

On Tue, Aug 22, 2017 at 8:01 PM, Jisheng Zhang  wrote:
> On Tue, 22 Aug 2017 19:57:04 -0700 John Stultz wrote:
>
>> On Tue, Aug 22, 2017 at 7:56 PM, John Stultz  wrote:
>> > On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  wrote:
>> >> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
>> >>
>> >>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
>> >>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
>> >>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
>> >>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
>> >>> > 8091/2: add get_user() support for 8 byte types") has added the
>> >>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
>> >>> > 32bit ARM
>> >>>
>> >>> Ok, but:
>> >>>
>> >>> >
>> >>> > Signed-off-by: Jisheng Zhang 
>> >>> > ---
>> >>> >  drivers/android/Kconfig | 2 +-
>> >>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>> >
>> >>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
>> >>> > index 832e885349b1..aca5dc30b97b 100644
>> >>> > --- a/drivers/android/Kconfig
>> >>> > +++ b/drivers/android/Kconfig
>> >>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
>> >>> >   therefore logically separated from the other devices.
>> >>> >
>> >>> >  config ANDROID_BINDER_IPC_32BIT
>> >>> > -   bool
>> >>> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
>> >>> > depends on !64BIT && ANDROID_BINDER_IPC
>> >>>
>> >>> You don't actually change the depends line :(
>> >>>
>> >>> Please fix up, and test it, and then resend.
>> >>
>> >> IHOM, the dependency is correct: 64bit platforms don't support
>> >> ANDROID_BINDER_IPC_32BIT. What do you think?
>> >
>> > I think this indicates the commit message is unclear.
>> >
>> > Part of it is that the config is inverted from the description. The
>> > patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
>> > just allows the option to be unselected, so that the 64bit ABI will be
>> > used on 32bit systems.
>> >
>> > Conceptually I don't have an objection to the change (though maybe try
>> > to rework the commit message), but I don't have anything to actually
>> > test it on right now, so I'm hesitant to ack it.
>>
>> It might also be good to add some detail as to the motivation for this
>> change? What benefit does it bring to 32bit platforms to use the newer
>> 64bit ABI?
>>
>
> To be honest, the motivation is just to add one more choice for 32bit
> platform and let the code be tested under 32bit platform. Maybe we
> could then remove ANDROID_BINDER_IPC_32BIT and the related code after
> some time?

I'm mixed. It would be nice to deprecate the old 32bit ABI, but binder
is a real Linux kernel interface now, so we don't break compatibility
(at least if it affects anyone - which may be questionable here - not
sure there's many upstream 32bit platforms concerned with running
legacy Android builds).  But just adding the extra option just means
there's yet another configuration to test and to keep working. So you
may want to articulate the benefits better to make this worth the
effort of doing a full transition.

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Jisheng Zhang]

On Tue, 22 Aug 2017 19:57:04 -0700 John Stultz wrote:

> On Tue, Aug 22, 2017 at 7:56 PM, John Stultz  wrote:
> > On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  wrote: 
> >  
> >> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> >>  
> >>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:  
> >>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> >>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> >>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> >>> > 8091/2: add get_user() support for 8 byte types") has added the
> >>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> >>> > 32bit ARM  
> >>>
> >>> Ok, but:
> >>>  
> >>> >
> >>> > Signed-off-by: Jisheng Zhang 
> >>> > ---
> >>> >  drivers/android/Kconfig | 2 +-
> >>> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> >>> > index 832e885349b1..aca5dc30b97b 100644
> >>> > --- a/drivers/android/Kconfig
> >>> > +++ b/drivers/android/Kconfig
> >>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >>> >   therefore logically separated from the other devices.
> >>> >
> >>> >  config ANDROID_BINDER_IPC_32BIT
> >>> > -   bool
> >>> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> >>> > depends on !64BIT && ANDROID_BINDER_IPC  
> >>>
> >>> You don't actually change the depends line :(
> >>>
> >>> Please fix up, and test it, and then resend.  
> >>
> >> IHOM, the dependency is correct: 64bit platforms don't support
> >> ANDROID_BINDER_IPC_32BIT. What do you think?  
> >
> > I think this indicates the commit message is unclear.
> >
> > Part of it is that the config is inverted from the description. The
> > patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> > just allows the option to be unselected, so that the 64bit ABI will be
> > used on 32bit systems.
> >
> > Conceptually I don't have an objection to the change (though maybe try
> > to rework the commit message), but I don't have anything to actually
> > test it on right now, so I'm hesitant to ack it.  
> 
> It might also be good to add some detail as to the motivation for this
> change? What benefit does it bring to 32bit platforms to use the newer
> 64bit ABI?
> 

To be honest, the motivation is just to add one more choice for 32bit
platform and let the code be tested under 32bit platform. Maybe we
could then remove ANDROID_BINDER_IPC_32BIT and the related code after
some time?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[John Stultz]

On Tue, Aug 22, 2017 at 7:56 PM, John Stultz  wrote:
> On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  wrote:
>> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
>>
>>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
>>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
>>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
>>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
>>> > 8091/2: add get_user() support for 8 byte types") has added the
>>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
>>> > 32bit ARM
>>>
>>> Ok, but:
>>>
>>> >
>>> > Signed-off-by: Jisheng Zhang 
>>> > ---
>>> >  drivers/android/Kconfig | 2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
>>> > index 832e885349b1..aca5dc30b97b 100644
>>> > --- a/drivers/android/Kconfig
>>> > +++ b/drivers/android/Kconfig
>>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
>>> >   therefore logically separated from the other devices.
>>> >
>>> >  config ANDROID_BINDER_IPC_32BIT
>>> > -   bool
>>> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
>>> > depends on !64BIT && ANDROID_BINDER_IPC
>>>
>>> You don't actually change the depends line :(
>>>
>>> Please fix up, and test it, and then resend.
>>
>> IHOM, the dependency is correct: 64bit platforms don't support
>> ANDROID_BINDER_IPC_32BIT. What do you think?
>
> I think this indicates the commit message is unclear.
>
> Part of it is that the config is inverted from the description. The
> patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> just allows the option to be unselected, so that the 64bit ABI will be
> used on 32bit systems.
>
> Conceptually I don't have an objection to the change (though maybe try
> to rework the commit message), but I don't have anything to actually
> test it on right now, so I'm hesitant to ack it.

It might also be good to add some detail as to the motivation for this
change? What benefit does it bring to 32bit platforms to use the newer
64bit ABI?

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

Re: [EXT] Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Jisheng Zhang]

On Tue, 22 Aug 2017 19:56:07 -0700 John Stultz  wrote:

> External Email
> 
> --
> On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  wrote:
> > On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> >  
> >> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:  
> >> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> >> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> >> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> >> > 8091/2: add get_user() support for 8 byte types") has added the
> >> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> >> > 32bit ARM  
> >>
> >> Ok, but:
> >>  
> >> >
> >> > Signed-off-by: Jisheng Zhang 
> >> > ---
> >> >  drivers/android/Kconfig | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> >> > index 832e885349b1..aca5dc30b97b 100644
> >> > --- a/drivers/android/Kconfig
> >> > +++ b/drivers/android/Kconfig
> >> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >> >   therefore logically separated from the other devices.
> >> >
> >> >  config ANDROID_BINDER_IPC_32BIT
> >> > -   bool
> >> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> >> > depends on !64BIT && ANDROID_BINDER_IPC  
> >>
> >> You don't actually change the depends line :(
> >>
> >> Please fix up, and test it, and then resend.  
> >
> > IHOM, the dependency is correct: 64bit platforms don't support
> > ANDROID_BINDER_IPC_32BIT. What do you think?  
> 
> I think this indicates the commit message is unclear.
> 
> Part of it is that the config is inverted from the description. The
> patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> just allows the option to be unselected, so that the 64bit ABI will be
> used on 32bit systems.
> 
> Conceptually I don't have an objection to the change (though maybe try
> to rework the commit message), but I don't have anything to actually
> test it on right now, so I'm hesitant to ack it.
> 

I have tested it on Marvell Berlin 32bit platform: the 64bit binder IPC
works fine on our 32bit platform.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: android: ion: Change argument to kmalloc (checkpatch)

[Nick Fox]

Change argument to kmalloc() to fix style issue, reported by checkpatch

Signed-off-by: Nick Fox 
---
 drivers/staging/android/ion/ion_cma_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index b06f4cee9c7c..bb2c1449cbcf 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -45,7 +45,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (!pages)
return -ENOMEM;
 
-   table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+   table = kmalloc(sizeof(*table), GFP_KERNEL);
if (!table)
goto err;
 
-- 
2.13.5

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

[PATCH 1/2] staging: android: ion: Remove extra line (checkpatch)

[Nick Fox]

Remove extra blank line (reported by checkpatch.pl)

Signed-off-by: Nick Fox 
---
 drivers/staging/android/ion/ion_cma_heap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index a0949bc0dcf4..b06f4cee9c7c 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -31,7 +31,6 @@ struct ion_cma_heap {
 
 #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
 
-
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
unsigned long len,
-- 
2.13.5

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[John Stultz]

On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang  wrote:
> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
>
>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
>> > 8091/2: add get_user() support for 8 byte types") has added the
>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
>> > 32bit ARM
>>
>> Ok, but:
>>
>> >
>> > Signed-off-by: Jisheng Zhang 
>> > ---
>> >  drivers/android/Kconfig | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
>> > index 832e885349b1..aca5dc30b97b 100644
>> > --- a/drivers/android/Kconfig
>> > +++ b/drivers/android/Kconfig
>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
>> >   therefore logically separated from the other devices.
>> >
>> >  config ANDROID_BINDER_IPC_32BIT
>> > -   bool
>> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
>> > depends on !64BIT && ANDROID_BINDER_IPC
>>
>> You don't actually change the depends line :(
>>
>> Please fix up, and test it, and then resend.
>
> IHOM, the dependency is correct: 64bit platforms don't support
> ANDROID_BINDER_IPC_32BIT. What do you think?

I think this indicates the commit message is unclear.

Part of it is that the config is inverted from the description. The
patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
just allows the option to be unselected, so that the 64bit ABI will be
used on 32bit systems.

Conceptually I don't have an objection to the change (though maybe try
to rework the commit message), but I don't have anything to actually
test it on right now, so I'm hesitant to ack it.

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Jisheng Zhang]

On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:

> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> > 8091/2: add get_user() support for 8 byte types") has added the
> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> > 32bit ARM  
> 
> Ok, but:
> 
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/android/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> > index 832e885349b1..aca5dc30b97b 100644
> > --- a/drivers/android/Kconfig
> > +++ b/drivers/android/Kconfig
> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >   therefore logically separated from the other devices.
> >  
> >  config ANDROID_BINDER_IPC_32BIT
> > -   bool
> > +   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> > depends on !64BIT && ANDROID_BINDER_IPC  
> 
> You don't actually change the depends line :(
> 
> Please fix up, and test it, and then resend.

IHOM, the dependency is correct: 64bit platforms don't support
ANDROID_BINDER_IPC_32BIT. What do you think?

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

Re: [PATCH] staging: fsl-mc: be consistent when checking strcmp() returns

[Joe Perches]

On Tue, 2017-08-22 at 18:40 -0700, Greg KH wrote:
> On Thu, Aug 17, 2017 at 02:55:04PM +0300, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor 
> > 
> > Throughout the driver we use == 0 / != 0 to check strcmp() returns except
> > this place, so fix it.
> 
> You will just get someone else fixing it as it is not what checkpatch
> recommends, so just leave it as-is please.

No.  That's not correct.

checkpatch does not make a recommendation about
style use with the strcmp family of functions.

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

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

[Greg KH]

On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> binder API"), we can add back the choice for 32bit ARM "once a 64bit
> __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> 8091/2: add get_user() support for 8 byte types") has added the
> support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> 32bit ARM

Ok, but:

> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/android/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> index 832e885349b1..aca5dc30b97b 100644
> --- a/drivers/android/Kconfig
> +++ b/drivers/android/Kconfig
> @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> therefore logically separated from the other devices.
>  
>  config ANDROID_BINDER_IPC_32BIT
> - bool
> + bool "Use old (Android 4.4 and earlier) 32-bit binder API"
>   depends on !64BIT && ANDROID_BINDER_IPC

You don't actually change the depends line :(

Please fix up, and test it, and then resend.

thanks,

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

Re: [PATCH] android: binder: check result of binder_get_thread() in binder_poll()

[Greg Kroah-Hartman]

On Mon, May 08, 2017 at 01:43:23PM -0700, Dmitry Torokhov wrote:
> If binder_get_thread() fails to give us a thread data, we should avoid
> dereferencing a NULL pointer and return POLLERR instead.
> 
> Signed-off-by: Dmitry Torokhov 
> Reviewed-by: Douglas Anderson 
> ---
>  drivers/android/binder.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)

Doesn't apply to my tree at all :(

Please rebase and resend, thanks.

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

Re: [PATCH 1/5] android: binder: Refactor prev and next buffer into a helper function

[Greg Kroah-Hartman]

On Tue, Aug 15, 2017 at 05:25:55PM -0700, Sherry Yang wrote:
> Change-Id: Ie2a446ad9907f0d306fd1b8e6d79d87e48826ce2

Why is this here?

> Signed-off-by: Sherry Yang 

I can't take patches without any changelog text at all, sorry.  Please
fix up and resend this series.

thanks,

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

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

[Greg KH]

On Tue, Aug 22, 2017 at 08:49:59AM -0700, Greg KH wrote:
> On Mon, Aug 21, 2017 at 11:48:39AM -0700, John Stultz wrote:
> > On Tue, Aug 8, 2017 at 11:08 AM, Greg KH  wrote:
> > > On Tue, Aug 08, 2017 at 10:34:47AM -0700, John Stultz wrote:
> > >> On Fri, Jul 28, 2017 at 4:56 AM, Martijn Coenen  wrote:
> > >> > Commit c4ea41ba195d ("binder: use group leader instead of open 
> > >> > thread")'
> > >> > was incomplete and didn't update a check in binder_mmap(), causing all
> > >> > mmap() calls into the binder driver to fail.
> > >> >
> > >> > Signed-off-by: Martijn Coenen 
> > >> > ---
> > >> >  drivers/android/binder.c | 2 +-
> > >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> >
> > >> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > >> > index f7665c31feca..831cdd7d197d 100644
> > >> > --- a/drivers/android/binder.c
> > >> > +++ b/drivers/android/binder.c
> > >> > @@ -3362,7 +3362,7 @@ static int binder_mmap(struct file *filp, struct 
> > >> > vm_area_struct *vma)
> > >> > const char *failure_string;
> > >> > struct binder_buffer *buffer;
> > >> >
> > >> > -   if (proc->tsk != current)
> > >> > +   if (proc->tsk != current->group_leader)
> > >> > return -EINVAL;
> > >> >
> > >> > if ((vma->vm_end - vma->vm_start) > SZ_4M)
> > >>
> > >> Tested-by: John Stultz 
> > >>
> > >> As Amit already confirmed, this resolves the wifi and bluetooth
> > >> regression I was seeing with Android using 4.13-rc2.
> > >>
> > >> Though I've not seen it show up in Linus' tree yet, so I wanted to
> > >> pester folks so it gets into 4.13-rc (its given me some slight grief
> > >> trying to bisect down a separate issue).
> > >
> > > I will queue this up in the next few days, I need to resolve the patches
> > > that have been sent to me for this, sorry for the delay.
> > 
> > Hey Greg,
> >   Sorry to pester you again on this, but this seems to still be
> > missing in -rc6. Don't want it to slip by.
> 
> It's not lost, just on the bottom of my queue, will catch up with it
> next week...

Now queued up, sorry for the delay.

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

Re: [PATCH] staging: fsl-mc: be consistent when checking strcmp() returns

[Greg KH]

On Thu, Aug 17, 2017 at 02:55:04PM +0300, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> Throughout the driver we use == 0 / != 0 to check strcmp() returns except
> this place, so fix it.

You will just get someone else fixing it as it is not what checkpatch
recommends, so just leave it as-is please.

thanks,

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

Re: [PATCH] staging: fsl-mc: move bus driver out of staging

[Greg KH]

On Sat, Aug 19, 2017 at 08:18:12PM +0300, laurentiu.tu...@nxp.com wrote:
> From: Stuart Yoder 
> 
> Move the source files out of staging into their final locations:
>   -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
>   -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
>   -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
>   -README.txt, providing and overview of DPAA goes to
>Documentation/dpaa2/overview.txt
> 
> Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
> Update dpaa2_eth and dpio staging drivers.
> 
> Signed-off-by: Stuart Yoder 
> Signed-off-by: Laurentiu Tudor 
> [Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Marc Zyngier 

Really?  You all have fixed all of the previous issues found?  Is it
time for another real review?  If so, please ask for it.

thanks,

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

Re: [PATCH] drivers: staging: android: Fix style/formatting issues

[Greg KH]

On Tue, Aug 22, 2017 at 09:04:50PM -0400, Nick Fox wrote:
> Fix two issues reported by checkpatch. The first removes an extra
> blank line, the second changes an argument to kmalloc(). Original
> checkpatch output is below:

That should be two different patches, please break this up.

thanks,

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

Re: [PATCH 2/2] staging:rtl8188eu:core Fix add spaces around

[Greg KH]

On Mon, Aug 21, 2017 at 12:50:07PM +0530, Janani S wrote:
> This patch is created to solve the coding style issues reported
> by checkpatch script.

What issue?

And where is patch 1/2?

> 
> Signed-off-by: Janani S 

Please use your full name.

thanks,

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

Re: [PATCH 3/3] staging:rtl8188eu:core Fix coding style issues

[Greg KH]

On Mon, Aug 21, 2017 at 01:00:14PM +0530, Janani S wrote:
> This patch solves the following warning shown by
> checkpatch script
> WARNING: Comparisons should place the constants
> on the right side of the test

Why the odd line-wrapping?

And where is patch 1/3 and 2/3?

thanks,

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

Re: [PATCH] staging: vboxvideo: constify drm_fb_helper_funcs

[Greg KH]

On Mon, Aug 21, 2017 at 03:36:34PM +0530, Arvind Yadav wrote:
> drm_fb_helper_funcs are not supposed to change at runtime.
> All functions working with drm_fb_helper_funcs provided by
>  work with const drm_fb_helper_funcs.
> So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 
> Reviewed-by: Hans de Goede 
> ---
>  drivers/staging/vboxvideo/vbox_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Does not apply to my tree :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8192e: Change fixed function names with "%s:", __func__

[Greg Kroah-Hartman]

On Mon, Aug 21, 2017 at 09:32:35PM +0800, Shurong Zhang wrote:
> Replace hard-coded function names in strings with "%s", __func__ in the 
> dot11d.c file. Issue found by checkpatch.pl.

Please always wrap your changelog text at 72 columns.

And why did you send this twice?

thanks,

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

[staging:staging-next 280/326] ERROR: "ieee80211_rx_irqsafe" [drivers/staging/rtlwifi/r8822be.ko] undefined!

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-next
head:   aa5ebdeb5d9e5be183721d5105769ad6240d5981
commit: 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6 [280/326] staging: r8822be: 
Add Makefiles and Kconfig for new driver
config: i386-randconfig-i0-08210518 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "ieee80211_rx_irqsafe" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "cfg80211_unlink_bss" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "ieee80211_beacon_get_tim" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_resume_disconnect" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_unregister_hw" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "rate_control_send_low" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "freq_reg_info" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "wiphy_rfkill_start_polling" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_stop_queue" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "cfg80211_get_bss" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "ieee80211_alloc_hw_nm" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_rate_control_register" 
>> [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "wiphy_apply_custom_regulatory" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "wiphy_rfkill_stop_polling" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "wiphy_to_ieee80211_hw" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_stop_tx_ba_cb_irqsafe" 
>> [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "cfg80211_put_bss" [drivers/staging/rtlwifi/r8822be.ko] undefined!
>> ERROR: "wiphy_rfkill_set_hw_state" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_tx_status_irqsafe" [drivers/staging/rtlwifi/r8822be.ko] 
>> undefined!
>> ERROR: "ieee80211_find_sta" [drivers/staging/rtlwifi/r8822be.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] drivers: staging: android: Fix style/formatting issues

[Nick Fox]

Fix two issues reported by checkpatch. The first removes an extra
blank line, the second changes an argument to kmalloc(). Original
checkpatch output is below:

ion/ion_cma_heap.c:34: CHECK: Please don't use multiple blank lines
ion/ion_cma_heap.c:49: CHECK: Prefer kmalloc(sizeof(*table)...) over 
kmalloc(sizeof(struct sg_table)...)
total: 0 errors, 0 warnings, 2 checks, 128 lines checked

Signed-off-by: Nick Fox 
---
 drivers/staging/android/ion/ion_cma_heap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index a0949bc0dcf4..bb2c1449cbcf 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -31,7 +31,6 @@ struct ion_cma_heap {
 
 #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
 
-
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
unsigned long len,
@@ -46,7 +45,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (!pages)
return -ENOMEM;
 
-   table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+   table = kmalloc(sizeof(*table), GFP_KERNEL);
if (!table)
goto err;
 
-- 
2.13.5

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

Re: [PATCH v2 00/46] staging: unisys: Additional code changes

[Greg KH]

On Tue, Aug 22, 2017 at 01:26:50PM -0400, David Kershner wrote:
> Several simplifications and cleanup patches. This series now includes the
> patch to switch to use the new UUID API.
> 
> -- Changes since v1
>  -- Incorporated UUID API patch
>  -- Refactored other patches that were affected by the UUID API patch.

All except patch 16 is now applied, thanks.

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

Re: [PATCH v2 16/46] staging: unisys: use the kernel min define

[Greg KH]

On Tue, Aug 22, 2017 at 01:27:06PM -0400, David Kershner wrote:
> The kernel already provides a min function, we should be using that
> instead of creating our own MINNUM.
> 
> Reviewed-by: Sameer Wadgaonkar 
> Signed-off-by: David Kershner 
> Reviewed-by: Tim Sell 
> ---
>  drivers/staging/unisys/include/iochannel.h  | 3 ---
>  drivers/staging/unisys/visornic/visornic_main.c | 2 +-
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/unisys/include/iochannel.h 
> b/drivers/staging/unisys/include/iochannel.h
> index ca9d6f9..e6f1d55 100644
> --- a/drivers/staging/unisys/include/iochannel.h
> +++ b/drivers/staging/unisys/include/iochannel.h
> @@ -46,9 +46,6 @@
>   * IO Partition is defined below.
>   */
>  
> -/* Defines and enums. */
> -#define MINNUM(a, b) (((a) < (b)) ? (a) : (b))
> -
>  /* Define the two queues per data channel between iopart and ioguestparts. */
>  
>  /* Used by ioguestpart to 'insert' signals to iopart. */
> diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
> b/drivers/staging/unisys/visornic/visornic_main.c
> index 135d37c..7856ed1 100644
> --- a/drivers/staging/unisys/visornic/visornic_main.c
> +++ b/drivers/staging/unisys/visornic/visornic_main.c
> @@ -221,7 +221,7 @@ static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, 
> u32 inp_len,
>   } else {
>   pi_arr[index + i].pi_off = 0;
>   pi_arr[index + i].pi_len =
> - (u16)MINNUM(len, (u32)PI_PAGE_SIZE);
> + (u16)min_t(u32, len, (u32)PI_PAGE_SIZE);

Why do you need to cast PI_PAGE_SIZE if you are using min_t()?  And are
you sure you can then cast the result to u16?  If len is u16, why not
just use min_t(u16,...) ?

thanks,

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

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

[Dexuan Cui]

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote:
> > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > +{
> > > > +   static const u32 valid_cids[] = {
> > > > +   VMADDR_CID_ANY,
> > >
> > > Is this for loopback?
> >
> > No, we don't support lookback in Linux VM, at least for now.
> > In our Linux implementation, Linux VM can only connect to the host, and
> > here when Linux VM calls connect(), I treat  VMADDR_CID_ANY
> > the same as VMADDR_CID_HOST.
> 
> VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> connect(VMADDR_CID_HOST).  It is an error to connect to VMADDR_CID_ANY.

Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since 
we don't support loopback mode.

> > > > +   /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x)
> > > is
> > > > +* reserved as ephemeral ports, which are used as the host's 
> > > > ports
> > > > +* when the host initiates connections.
> > > > +*/
> > > > +   if (port > MAX_HOST_LISTEN_PORT)
> > > > +   return false;
> > >
> > > Without this if statement the guest will attempt to connect.  I guess
> > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > connection attempt will fail.
> >
> > You're correct.
> > To use the vsock common infrastructure, we have to map Hyper-V's
> > GUID  to int , and hence we must limit
> > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > we can only use half of the whole 32-bit port space for listen().
> > This is detailed in the long comments starting at about Line 100.
> >
> > > ...but hardcode this knowledge into the guest driver?
> > I'd like the guest's connect() to fail immediately here.
> > IMO this is better than a connect timeout. :-)
> 
> Thanks for explaining.  Perhaps the comment could be updated:
> 
>  /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
>   * reserved as ephemeral ports, which are used as the host's ports when
>   * the host initiates connections.
>   *
>   * Perform this check in the guest so an immediate error is produced
>   * instead of a timeout.
>   */
> 
> Stefan

Thank you, Stefan! 
Please see the below for the updated version of the function:

static bool hvs_stream_allow(u32 cid, u32 port)
{
/* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
 * reserved as ephemeral ports, which are used as the host's ports
 * when the host initiates connections.
 *
 * Perform this check in the guest so an immediate error is produced
 * instead of a timeout.
 */
if (port > MAX_HOST_LISTEN_PORT)
return false;

if (cid == VMADDR_CID_HOST)
return true;

return false;
}

I'll send a v2 of the patch later today.

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

RE: [PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

[Long Li]

 
> Wouldn't it make sense to backport the changes to set the virt_boundary
> (which probably still is the SG_GAPS flag in such an old kernel)?

We can make storvsc use SG_GAPS. But the following patch is missing in 4.1 
stable block layer to make this work on some I/O situations. Backporting is 
more difficult and affect other code.

commit 5e7c4274a70aa2d6f485996d0ca1dad52d0039ca
Author: Jens Axboe 
Date:   Thu Sep 3 19:28:20 2015 +0300

block: Check for gaps on front and back merges

We are checking for gaps to previous bio_vec, which can
only detect back merges gaps. Moreover, at the point where
we check for a gap, we don't know if we will attempt a back
or a front merge. Thus, check for gap to prev in a back merge
attempt and check for a gap to next in a front merge attempt.

Signed-off-by: Jens Axboe 
[sagig: Minor rename change]
Signed-off-by: Sagi Grimberg 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 43/46] staging: unisys: visorbus: Get rid of passthrough function visorchipset_bus_destroy

[David Kershner]

From: Sameer Wadgaonkar 

The function visorchipset_bus_destroy just called viosrbus_remove_instance,
we can just combine it with visorbus_remove_instance.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c|  9 ++---
 drivers/staging/unisys/visorbus/visorbus_private.h |  2 +-
 drivers/staging/unisys/visorbus/visorchipset.c |  4 ++--
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 6dad259..a3fde23 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1085,7 +1085,7 @@ int visorbus_create_instance(struct visor_device *dev)
  * visorbus_remove_instance() - remove a device instance for the visorbus 
itself
  * @dev: struct visor_device indentifying the bus to remove
  */
-static void visorbus_remove_instance(struct visor_device *dev)
+void visorbus_remove_instance(struct visor_device *dev)
 {
/*
 * Note that this will result in the release method for
@@ -1099,6 +1099,7 @@ static void visorbus_remove_instance(struct visor_device 
*dev)
kfree(dev->vbus_hdr_info);
list_del(>list_all);
device_unregister(>device);
+   visorbus_response(dev, 0, CONTROLVM_BUS_DESTROY);
 }
 
 /*
@@ -1116,12 +1117,6 @@ static void remove_all_visor_devices(void)
}
 }
 
-void visorchipset_bus_destroy(struct visor_device *dev)
-{
-   visorbus_remove_instance(dev);
-   visorbus_response(dev, 0, CONTROLVM_BUS_DESTROY);
-}
-
 int visorchipset_device_create(struct visor_device *dev_info)
 {
int err;
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 55ce5c7..929e09b 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -24,7 +24,7 @@
 #include "visorbus.h"
 
 int visorbus_create_instance(struct visor_device *dev);
-void visorchipset_bus_destroy(struct visor_device *bus_info);
+void visorbus_remove_instance(struct visor_device *bus_info);
 int visorchipset_device_create(struct visor_device *dev_info);
 void visorchipset_device_destroy(struct visor_device *dev_info);
 int visorchipset_device_pause(struct visor_device *dev_info);
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 1cedb3b..a478533 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -700,8 +700,8 @@ static int visorbus_destroy(struct controlvm_message *inmsg)
bus_info->pending_msg_hdr = pmsg_hdr;
}
 
-   /* Response will be handled by visorchipset_bus_destroy */
-   visorchipset_bus_destroy(bus_info);
+   /* Response will be handled by visorbus_remove_instance */
+   visorbus_remove_instance(bus_info);
return 0;
 
 err_respond:
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 42/46] staging: unisys: include: iochannel.h: Add proper copyright statement

[David Kershner]

From: David Binder 

Adds the proper Unisys copyright statement to the top of iochannel.h.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 045e45c..a70760f 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -1,5 +1,19 @@
-/* Copyright (C) 2010 - 2016 UNISYS CORPORATION */
-/* All rights reserved. */
+/*
+ * Copyright (C) 2010 - 2016 UNISYS CORPORATION
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ */
+
 #ifndef __IOCHANNEL_H__
 #define __IOCHANNEL_H__
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 46/46] staging: unisys: use ATTRIBUTE_GROUPS instead of creating our own

[David Kershner]

Greg noticed that we were creating our own attribute groups, instead of
using the ATTRIBUTE_GROUPS macro, this patch fixes our mistake.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 33 ++
 1 file changed, 5 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 38f07b0..d9b0a8b 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -51,15 +51,7 @@ static struct attribute *visorbus_dev_attrs[] = {
NULL,
 };
 
-/* sysfs example for bridge-only sysfs files using device_type's */
-static const struct attribute_group visorbus_dev_group = {
-   .attrs = visorbus_dev_attrs,
-};
-
-static const struct attribute_group *visorbus_dev_groups[] = {
-   _dev_group,
-   NULL,
-};
+ATTRIBUTE_GROUPS(visorbus_dev);
 
 /* filled in with info about parent chipset driver when we register with it */
 static struct visor_vbus_deviceinfo chipset_driverinfo;
@@ -292,15 +284,7 @@ static struct attribute *channel_attrs[] = {
NULL
 };
 
-static const struct attribute_group channel_attr_grp = {
-   .name = "channel",
-   .attrs = channel_attrs,
-};
-
-static const struct attribute_group *visorbus_channel_groups[] = {
-   _attr_grp,
-   NULL
-};
+ATTRIBUTE_GROUPS(channel);
 
 /* end implementation of specific channel attributes */
 
@@ -379,7 +363,7 @@ static ssize_t channel_id_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(channel_id);
 
-static struct attribute *dev_attrs[] = {
+static struct attribute *visorbus_attrs[] = {
_attr_partition_handle.attr,
_attr_partition_guid.attr,
_attr_partition_name.attr,
@@ -389,14 +373,7 @@ static struct attribute *dev_attrs[] = {
NULL
 };
 
-static const struct attribute_group dev_attr_grp = {
-   .attrs = dev_attrs,
-};
-
-static const struct attribute_group *visorbus_groups[] = {
-   _attr_grp,
-   NULL
-};
+ATTRIBUTE_GROUPS(visorbus);
 
 /*
  *  BUS debugfs entries
@@ -666,7 +643,7 @@ int create_visor_device(struct visor_device *dev)
 
mutex_init(>visordriver_callback_lock);
dev->device.bus = _type;
-   dev->device.groups = visorbus_channel_groups;
+   dev->device.groups = channel_groups;
device_initialize(>device);
dev->device.release = visorbus_release_device;
/* keep a reference just for us (now 2) */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 33/46] staging: unisys: reference bus_no and dev_no directly

[David Kershner]

Don't store it in a local variable but reference it from the
visor_device.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 98ce796..83fcf6f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -571,8 +571,6 @@ static int device_changestate_responder(
struct visor_segment_state response_state)
 {
struct controlvm_message outmsg;
-   u32 bus_no = p->chipset_bus_no;
-   u32 dev_no = p->chipset_dev_no;
 
if (!p->pending_msg_hdr)
return -EIO;
@@ -581,8 +579,8 @@ static int device_changestate_responder(
 
controlvm_init_response(, p->pending_msg_hdr, response);
 
-   outmsg.cmd.device_change_state.bus_no = bus_no;
-   outmsg.cmd.device_change_state.dev_no = dev_no;
+   outmsg.cmd.device_change_state.bus_no = p->chipset_bus_no;
+   outmsg.cmd.device_change_state.dev_no = p->chipset_dev_no;
outmsg.cmd.device_change_state.state = response_state;
 
return visorchannel_signalinsert(chipset_dev->controlvm_channel,
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 44/46] staging: unisys: visorbus: Get rid of passthrough function visorchipset_device_create

[David Kershner]

From: Sameer Wadgaonkar 

The function visorchipset_device_create just called create_visor_device,
we can just combine it with create_visor_device.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c| 18 ++-
 drivers/staging/unisys/visorbus/visorbus_private.h |  2 +-
 drivers/staging/unisys/visorbus/visorchipset.c |  4 +--
 3 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index a3fde23..1c037a3 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -658,7 +658,7 @@ EXPORT_SYMBOL_GPL(visorbus_disable_channel_interrupts);
  * Return: 0 if successful, otherwise the negative value returned by
  * device_add() indicating the reason for failure
  */
-static int create_visor_device(struct visor_device *dev)
+int create_visor_device(struct visor_device *dev)
 {
int err;
u32 chipset_bus_no = dev->chipset_bus_no;
@@ -705,6 +705,8 @@ static int create_visor_device(struct visor_device *dev)
goto err_put;
 
list_add_tail(>list_all, _all_device_instances);
+   dev->state.created = 1;
+   visorbus_response(dev, err, CONTROLVM_DEVICE_CREATE);
/* success: reference kept via unmatched get_device() */
return 0;
 
@@ -1117,20 +1119,6 @@ static void remove_all_visor_devices(void)
}
 }
 
-int visorchipset_device_create(struct visor_device *dev_info)
-{
-   int err;
-
-   err = create_visor_device(dev_info);
-   if (err < 0)
-   return err;
-
-   visorbus_response(dev_info, err, CONTROLVM_DEVICE_CREATE);
-   dev_info->state.created = 1;
-
-   return 0;
-}
-
 void visorchipset_device_destroy(struct visor_device *dev_info)
 {
remove_visor_device(dev_info);
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 929e09b..56c38d5 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -25,7 +25,7 @@
 
 int visorbus_create_instance(struct visor_device *dev);
 void visorbus_remove_instance(struct visor_device *bus_info);
-int visorchipset_device_create(struct visor_device *dev_info);
+int create_visor_device(struct visor_device *dev_info);
 void visorchipset_device_destroy(struct visor_device *dev_info);
 int visorchipset_device_pause(struct visor_device *dev_info);
 int visorchipset_device_resume(struct visor_device *dev_info);
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index a478533..153c7e5 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -833,8 +833,8 @@ static int visorbus_device_create(struct controlvm_message 
*inmsg)
   sizeof(struct controlvm_message_header));
dev_info->pending_msg_hdr = pmsg_hdr;
}
-   /* visorchipset_device_create will send response */
-   err = visorchipset_device_create(dev_info);
+   /* create_visor_device will send response */
+   err = create_visor_device(dev_info);
if (err)
goto err_destroy_visorchannel;
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 41/46] staging: unisys: visorinput: ultrainputreport.h: Adjust comment formatting

[David Kershner]

From: David Binder 

The first line of the top file comment should begin on the line following
the block comment opening, thereby following the convention used elsewhere
in the driver set.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorinput/ultrainputreport.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorinput/ultrainputreport.h 
b/drivers/staging/unisys/visorinput/ultrainputreport.h
index 3ffad83..53975a0 100644
--- a/drivers/staging/unisys/visorinput/ultrainputreport.h
+++ b/drivers/staging/unisys/visorinput/ultrainputreport.h
@@ -1,4 +1,5 @@
-/* Copyright (C) 2010 - 2015 UNISYS CORPORATION
+/*
+ * Copyright (C) 2010 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 45/46] staging: unisys: visorbus: Get rid of passthrough function visorchipset_device_destroy

[David Kershner]

From: Sameer Wadgaonkar 

The function visorchipset_device_destroy just called remove_visor_device,
we can just combine it with remove_visor_device.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c|  9 ++---
 drivers/staging/unisys/visorbus/visorbus_private.h |  2 +-
 drivers/staging/unisys/visorbus/visorchipset.c |  2 +-
 3 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c037a3..38f07b0 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -716,11 +716,12 @@ int create_visor_device(struct visor_device *dev)
return err;
 }
 
-static void remove_visor_device(struct visor_device *dev)
+void remove_visor_device(struct visor_device *dev)
 {
list_del(>list_all);
put_device(>device);
device_unregister(>device);
+   visorbus_response(dev, 0, CONTROLVM_DEVICE_DESTROY);
 }
 
 static int get_vbus_header_info(struct visorchannel *chan,
@@ -1119,12 +1120,6 @@ static void remove_all_visor_devices(void)
}
 }
 
-void visorchipset_device_destroy(struct visor_device *dev_info)
-{
-   remove_visor_device(dev_info);
-   visorbus_response(dev_info, 0, CONTROLVM_DEVICE_DESTROY);
-}
-
 /*
  * pause_state_change_complete() - the callback function to be called by a
  * visorbus function driver when a
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 56c38d5..8651c87 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -26,7 +26,7 @@
 int visorbus_create_instance(struct visor_device *dev);
 void visorbus_remove_instance(struct visor_device *bus_info);
 int create_visor_device(struct visor_device *dev_info);
-void visorchipset_device_destroy(struct visor_device *dev_info);
+void remove_visor_device(struct visor_device *dev_info);
 int visorchipset_device_pause(struct visor_device *dev_info);
 int visorchipset_device_resume(struct visor_device *dev_info);
 
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 153c7e5..25a30a4 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -948,7 +948,7 @@ static int visorbus_device_destroy(struct controlvm_message 
*inmsg)
}
 
kfree(dev_info->name);
-   visorchipset_device_destroy(dev_info);
+   remove_visor_device(dev_info);
return 0;
 
 err_respond:
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 31/46] staging: unisys: visorbus: Remove confusing comment in controlvmchannel.

[David Kershner]

Referencing a SegmentIndex doesn't make sense in the Linux drivers, get rid
of the comment.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/controlvmchannel.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index ee21212..32ff5c1 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -273,7 +273,6 @@ struct controlvm_packet_device_create  {
  */
 struct controlvm_packet_device_configure  {
u32 bus_no;
-   /* Control uses header SegmentIndex field to access bus number. */
u32 dev_no;
 } __packed;
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 39/46] staging: unisys: include: visorbus.h: Remove filename in top comment

[David Kershner]

From: David Binder 

Removes unnecessary filename in the top file comment.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 4af2f99..e97bb5f 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -1,6 +1,4 @@
 /*
- * visorbus.h
- *
  * Copyright (C) 2010 - 2013 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 40/46] staging: unisys: visorhba: Adjust top comment formatting

[David Kershner]

From: David Binder 

The first line of the top file comment should begin on the line following
the block comment opening, thereby following the convention used elsewhere
in the driver set.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2f89cb0..8567e44 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -1,4 +1,5 @@
-/* Copyright (c) 2012 - 2015 UNISYS CORPORATION
+/*
+ * Copyright (c) 2012 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 32/46] staging: unisys: don't copy to local variable

[David Kershner]

Do the check with the values in the structure instead of copying them to
local variables.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 29475cc..98ce796 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -373,11 +373,9 @@ static int match_visorbus_dev_by_id(struct device *dev, 
void *data)
 {
struct visor_device *vdev = to_visor_device(dev);
struct visor_busdev *id = data;
-   u32 bus_no = id->bus_no;
-   u32 dev_no = id->dev_no;
 
-   if ((vdev->chipset_bus_no == bus_no) &&
-   (vdev->chipset_dev_no == dev_no))
+   if ((vdev->chipset_bus_no == id->bus_no) &&
+   (vdev->chipset_dev_no == id->dev_no))
return 1;
 
return 0;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 01/46] staging: unisys: visorbus: remove filename from beginning of file

[David Kershner]

From: Zohaib Javed 

The filename was in a comment at the beginning of the file. It is not
needed.

Signed-off-by: Zohaib Javed 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 6d4498f..c8a5cb2 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1,5 +1,4 @@
-/* visorchipset_main.c
- *
+/*
  * Copyright (C) 2010 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 25/46] staging: unisys: visorbus: Remove unnecessary includes for visorchipset.c

[David Kershner]

Visorchipset.c was including unnecessary include files, either included by
other headers or not needed at all.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index bfaf17e..ced1128 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -14,8 +14,6 @@
  */
 
 #include 
-#include 
-#include 
 #include 
 
 #include "visorbus.h"
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 37/46] staging: unisys: visorbus: visorchannel.c: Remove filename in top comment

[David Kershner]

From: David Binder 

Removes unnecessary filename in the top file comment.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 0b20b0e..6afc745 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -1,5 +1,4 @@
-/* visorchannel_funcs.c
- *
+/*
  * Copyright (C) 2010 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 30/46] staging: unisys: Move SIOVM guid to visorbus

[David Kershner]

The SIOVM guid is only used by visorchipset. So define it there instead
of a global header file.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h   | 5 -
 drivers/staging/unisys/visorbus/visorchipset.c | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 8087f19..2babe93 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -190,9 +190,4 @@ struct signal_queue_header {
  0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
 #define VISOR_VHBA_CHANNEL_GUID_STR \
"414815ed-c58c-11da-95a9-00e08161165f"
-/* {72120008-4AAB-11DC-8530-444553544200} */
-#define VISOR_SIOVM_GUID \
-   GUID_INIT(0x72120008, 0x4AAB, 0x11DC, \
- 0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
-
 #endif
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index ced1128..29475cc 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -19,6 +19,11 @@
 #include "visorbus.h"
 #include "visorbus_private.h"
 
+/* {72120008-4AAB-11DC-8530-444553544200} */
+#define VISOR_SIOVM_GUID \
+GUID_INIT(0x72120008, 0x4AAB, 0x11DC, \
+  0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
+
 static const guid_t visor_vhba_channel_guid = VISOR_VHBA_CHANNEL_GUID;
 static const guid_t visor_siovm_guid = VISOR_SIOVM_GUID;
 static const guid_t visor_controlvm_channel_guid = 
VISOR_CONTROLVM_CHANNEL_GUID;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 29/46] staging: unisys: Move VNIC GUID to visornic

[David Kershner]

Instead of including it in the global channel.h, move the VNIC GUID to the
visornic module.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h| 6 --
 drivers/staging/unisys/visornic/visornic_main.c | 7 +++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 01edf79..8087f19 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -190,12 +190,6 @@ struct signal_queue_header {
  0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
 #define VISOR_VHBA_CHANNEL_GUID_STR \
"414815ed-c58c-11da-95a9-00e08161165f"
-/* {8cd5994d-c58e-11da-95a9-00e08161165f} */
-#define VISOR_VNIC_CHANNEL_GUID \
-   GUID_INIT(0x8cd5994d, 0xc58e, 0x11da, \
- 0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
-#define VISOR_VNIC_CHANNEL_GUID_STR \
-   "8cd5994d-c58e-11da-95a9-00e08161165f"
 /* {72120008-4AAB-11DC-8530-444553544200} */
 #define VISOR_SIOVM_GUID \
GUID_INIT(0x72120008, 0x4AAB, 0x11DC, \
diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 7856ed1..ae1ecb6 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -37,6 +37,13 @@
 #define NAPI_WEIGHT 64
 
 /* GUIDS for director channel type supported by this driver.  */
+/* {8cd5994d-c58e-11da-95a9-00e08161165f} */
+#define VISOR_VNIC_CHANNEL_GUID \
+   GUID_INIT(0x8cd5994d, 0xc58e, 0x11da, \
+   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
+#define VISOR_VNIC_CHANNEL_GUID_STR \
+   "8cd5994d-c58e-11da-95a9-00e08161165f"
+
 static struct visor_channeltype_descriptor visornic_channel_types[] = {
/* Note that the only channel type we expect to be reported by the
 * bus driver is the VISOR_VNIC channel.
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 36/46] staging: unisys: visorbus: visorbus_main.c: Remove filename in top comment

[David Kershner]

From: David Binder 

Removes unnecessary filename in the top file comment.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 80a9c22..6dad259 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1,6 +1,4 @@
 /*
- * visorbus_main.c
- *
  * Copyright � 2010 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 38/46] staging: unisys: visorinput: visorinput.c: Remove filename in top comment

[David Kershner]

From: David Binder 

Removes unnecessary filename in the top file comment.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorinput/visorinput.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index d3d9c77..26f0b9b 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -1,5 +1,4 @@
-/* visorinput.c
- *
+/*
  * Copyright (C) 2011 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 15/46] staging: unisys: include: Remove unused #define MAXNUM

[David Kershner]

The MAXNUM #define was not being used, and it shouldn't be used.
Remove it.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 53259d6..ca9d6f9 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -48,7 +48,6 @@
 
 /* Defines and enums. */
 #define MINNUM(a, b) (((a) < (b)) ? (a) : (b))
-#define MAXNUM(a, b) (((a) > (b)) ? (a) : (b))
 
 /* Define the two queues per data channel between iopart and ioguestparts. */
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 26/46] staging: unisys: include: iochannel needs to include skbuff

[David Kershner]

The iochannel.h header file references ETH_HLEN which is defined in
skbuff. Removed it from visorhba since it was no longer needed.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h  | 1 +
 drivers/staging/unisys/visorhba/visorhba_main.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 7f5c0d0..045e45c 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 
 #include "channel.h"
 
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 29efdf9..2f89cb0 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -14,7 +14,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 10/46] staging: unisys: visorbus: Merge vmcallinterface.h into visorchipset.c

[David Kershner]

From: David Binder 

The contents of vmcallinterface.h are better placed within
visorchipset.c from an organizational perspective. The values are only
used in that file.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c| 42 ++-
 drivers/staging/unisys/visorbus/vmcallinterface.h | 61 +
 2 files changed, 41 insertions(+), 62 deletions(-)
 delete mode 100644 drivers/staging/unisys/visorbus/vmcallinterface.h

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index c4087f6..6dd7f29 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -20,7 +20,6 @@
 
 #include "visorbus.h"
 #include "visorbus_private.h"
-#include "vmcallinterface.h"
 
 static const guid_t visor_vhba_channel_guid = VISOR_VHBA_CHANNEL_GUID;
 static const guid_t visor_siovm_guid = VISOR_SIOVM_GUID;
@@ -54,6 +53,47 @@ struct parser_context {
char data[0];
 };
 
+/*
+ * VMCALL_CONTROLVM_ADDR: Used by all guests, not just IO.
+ *
+ * Note: When a new VMCALL is added:
+ * - The 1st 2 hex digits correspond to one of the VMCALL_MONITOR_INTERFACE
+ *   types.
+ * - The next 2 hex digits are the nth relative instance of within a type.
+ * E.G. for VMCALL_VIRTPART_RECYCLE_PART,
+ * - The 0x02 identifies it as a VMCALL_VIRTPART type.
+ * - The 0x01 identifies it as the 1st instance of a VMCALL_VIRTPART type of
+ *   VMCALL.
+ */
+#define VMCALL_CONTROLVM_ADDR 0x0501
+
+enum vmcall_result {
+   VMCALL_RESULT_SUCCESS = 0,
+   VMCALL_RESULT_INVALID_PARAM = 1,
+   VMCALL_RESULT_DATA_UNAVAILABLE = 2,
+   VMCALL_RESULT_FAILURE_UNAVAILABLE = 3,
+   VMCALL_RESULT_DEVICE_ERROR = 4,
+   VMCALL_RESULT_DEVICE_NOT_READY = 5
+};
+
+/*
+ * struct vmcall_io_controlvm_addr_params - Structure for IO VMCALLS. Has
+ * parameters to VMCALL_CONTROLVM_ADDR
+ * interface.
+ * @address:  The Guest-relative physical address of the ControlVm channel.
+ *This VMCall fills this in with the appropriate address.
+ *Contents provided by this VMCALL (OUT).
+ * @channel_bytes: The size of the ControlVm channel in bytes This VMCall fills
+ *this in with the appropriate address. Contents provided by
+ *this VMCALL (OUT).
+ * @unused:   Unused Bytes in the 64-Bit Aligned Struct.
+ */
+struct vmcall_io_controlvm_addr_params {
+   u64 address;
+   u32 channel_bytes;
+   u8 unused[4];
+} __packed;
+
 struct vmcall_controlvm_addr {
struct vmcall_io_controlvm_addr_params params;
int err;
diff --git a/drivers/staging/unisys/visorbus/vmcallinterface.h 
b/drivers/staging/unisys/visorbus/vmcallinterface.h
deleted file mode 100644
index 541911b..000
--- a/drivers/staging/unisys/visorbus/vmcallinterface.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Copyright (C) 2010 - 2015 UNISYS CORPORATION
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT.  See the GNU General Public License for more
- * details.
- */
-
-#ifndef __VMCALLINTERFACE_H__
-#define __VMCALLINTERFACE_H__
-
-/*
- * VMCALL_CONTROLVM_ADDR: Used by all guests, not just IO.
- *
- * Note: When a new VMCALL is added:
- * - The 1st 2 hex digits correspond to one of the VMCALL_MONITOR_INTERFACE
- *   types.
- * - The next 2 hex digits are the nth relative instance of within a type.
- * E.G. for VMCALL_VIRTPART_RECYCLE_PART,
- * - The 0x02 identifies it as a VMCALL_VIRTPART type.
- * - The 0x01 identifies it as the 1st instance of a VMCALL_VIRTPART type of
- *   VMCALL.
- */
-#define VMCALL_CONTROLVM_ADDR 0x0501
-
-enum vmcall_result {
-   VMCALL_RESULT_SUCCESS = 0,
-   VMCALL_RESULT_INVALID_PARAM = 1,
-   VMCALL_RESULT_DATA_UNAVAILABLE = 2,
-   VMCALL_RESULT_FAILURE_UNAVAILABLE = 3,
-   VMCALL_RESULT_DEVICE_ERROR = 4,
-   VMCALL_RESULT_DEVICE_NOT_READY = 5
-};
-
-/*
- * struct vmcall_io_controlvm_addr_params - Structure for IO VMCALLS. Has
- * parameters to VMCALL_CONTROLVM_ADDR
- * interface.
- * @address:  The Guest-relative physical address of the ControlVm channel.
- *This VMCall fills this in with the appropriate address.
- *Contents provided by this VMCALL 

[PATCH v2 19/46] staging: unisys: include: Remove unused throttling defines.

[David Kershner]

We no longer send messages directly to the s-Par event log, so we do not
need the throttling defines anymore.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 2dac0e5..69ccc33 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -58,23 +58,6 @@ enum channel_clientstate {
CHANNELCLI_OWNED = 5
 };
 
-/* Values for VISORA_CHANNEL_PROTOCOL.CliErrorBoot: */
-
-/*
- * Throttling invalid boot channel statetransition error due to client
- * disabled.
- */
-#define VISOR_CLIERRORBOOT_THROTTLEMSG_DISABLED 0x01
-
-/*
- * Throttling invalid boot channel statetransition error due to client
- * not attached.
- */
-#define VISOR_CLIERRORBOOT_THROTTLEMSG_NOTATTACHED 0x02
-
-/* Throttling invalid boot channel statetransition error due to busy channel */
-#define VISOR_CLIERRORBOOT_THROTTLEMSG_BUSY 0x04
-
 /*
  * Values for VISOR_CHANNEL_PROTOCOL.Features: This define exists so that
  * windows guest can look at the FeatureFlags in the io channel, and configure
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 16/46] staging: unisys: use the kernel min define

[David Kershner]

The kernel already provides a min function, we should be using that
instead of creating our own MINNUM.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h  | 3 ---
 drivers/staging/unisys/visornic/visornic_main.c | 2 +-
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index ca9d6f9..e6f1d55 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -46,9 +46,6 @@
  * IO Partition is defined below.
  */
 
-/* Defines and enums. */
-#define MINNUM(a, b) (((a) < (b)) ? (a) : (b))
-
 /* Define the two queues per data channel between iopart and ioguestparts. */
 
 /* Used by ioguestpart to 'insert' signals to iopart. */
diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 135d37c..7856ed1 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -221,7 +221,7 @@ static u16 add_physinfo_entries(u64 inp_pfn, u16 inp_off, 
u32 inp_len,
} else {
pi_arr[index + i].pi_off = 0;
pi_arr[index + i].pi_len =
-   (u16)MINNUM(len, (u32)PI_PAGE_SIZE);
+   (u16)min_t(u32, len, (u32)PI_PAGE_SIZE);
}
}
return index + i;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 27/46] staging: unisys: visorinput: Get rid of unused includes

[David Kershner]

Cleanups caused us to not need to include a bunch of headers, got rid of
them.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorinput/visorinput.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index 3cfeefe..d3d9c77 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -21,11 +21,8 @@
  * standard way the Linux expects for input drivers.
  */
 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 35/46] staging: unisys: visorbus: visorchipset.c: Fix SonarQube sprintf findings

[David Kershner]

From: David Binder 

Fixes two sprintf invocations where we attempt to format an unsigned
integer as a signed integer.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 7094d62..1cedb3b 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -210,7 +210,7 @@ static ssize_t error_show(struct device *dev, struct 
device_attribute *attr,
, sizeof(u32));
if (err)
return err;
-   return sprintf(buf, "%i\n", error);
+   return sprintf(buf, "%u\n", error);
 }
 
 static ssize_t error_store(struct device *dev, struct device_attribute *attr,
@@ -245,7 +245,7 @@ static ssize_t textid_show(struct device *dev, struct 
device_attribute *attr,
if (err)
return err;
 
-   return sprintf(buf, "%i\n", text_id);
+   return sprintf(buf, "%u\n", text_id);
 }
 
 static ssize_t textid_store(struct device *dev, struct device_attribute *attr,
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 34/46] staging: unisys: visorbus: Get rid of passthrough function visorchipset_bus_create

[David Kershner]

The function visorchipset_bus_create just called visorbus_create_instance,
we should just combine it with visorbus_create_instance.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c| 19 +++
 drivers/staging/unisys/visorbus/visorbus_private.h |  3 +--
 drivers/staging/unisys/visorbus/visorchipset.c |  5 +---
 3 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 8e8abac..80a9c22 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1032,7 +1032,7 @@ EXPORT_SYMBOL_GPL(visorbus_register_visor_driver);
  * Return: 0 for success, otherwise negative errno value indicating reason for
  * failure
  */
-static int visorbus_create_instance(struct visor_device *dev)
+int visorbus_create_instance(struct visor_device *dev)
 {
int id = dev->chipset_bus_no;
int err;
@@ -1065,12 +1065,15 @@ static int visorbus_create_instance(struct visor_device 
*dev)
 
list_add_tail(>list_all, _all_bus_instances);
 
+   dev->state.created = 1;
dev->vbus_hdr_info = (void *)hdr_info;
write_vbus_chp_info(dev->visorchannel, hdr_info,
_driverinfo);
write_vbus_bus_info(dev->visorchannel, hdr_info,
_driverinfo);
 
+   visorbus_response(dev, err, CONTROLVM_BUS_CREATE);
+
return 0;
 
 err_debugfs_dir:
@@ -1115,20 +1118,6 @@ static void remove_all_visor_devices(void)
}
 }
 
-int visorchipset_bus_create(struct visor_device *dev)
-{
-   int err;
-
-   err = visorbus_create_instance(dev);
-   if (err < 0)
-   return err;
-
-   visorbus_response(dev, err, CONTROLVM_BUS_CREATE);
-   dev->state.created = 1;
-
-   return 0;
-}
-
 void visorchipset_bus_destroy(struct visor_device *dev)
 {
visorbus_remove_instance(dev);
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 1895035..55ce5c7 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -23,7 +23,7 @@
 #include "vbuschannel.h"
 #include "visorbus.h"
 
-int visorchipset_bus_create(struct visor_device *bus_info);
+int visorbus_create_instance(struct visor_device *dev);
 void visorchipset_bus_destroy(struct visor_device *bus_info);
 int visorchipset_device_create(struct visor_device *dev_info);
 void visorchipset_device_destroy(struct visor_device *dev_info);
@@ -38,7 +38,6 @@ int visorbus_init(void);
 void visorbus_exit(void);
 
 /* visorchannel access functions */
-
 struct visorchannel *visorchannel_create(u64 physaddr,
 unsigned long channel_bytes,
 gfp_t gfp, const guid_t *guid);
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 83fcf6f..7094d62 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -644,9 +644,8 @@ static int visorbus_create(struct controlvm_message *inmsg)
 
bus_info->visorchannel = visorchannel;
 
-   /* Response will be handled by visorchipset_bus_create */
-   err = visorchipset_bus_create(bus_info);
-   /* If visorchipset_bus_create didn't respond, need to respond here */
+   /* Response will be handled by visorbus_create_instance on success */
+   err = visorbus_create_instance(bus_info);
if (err)
goto err_destroy_channel;
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 28/46] staging: unisys: include: remove unnecessary blank line from channel.h

[David Kershner]

Remove unnecessary blank line from channel.h #defines.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 9fd4cc1..01edf79 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -24,7 +24,6 @@
 #define SIGNATURE_16(A, B) ((A) | ((B) << 8))
 #define SIGNATURE_32(A, B, C, D) \
(SIGNATURE_16(A, B) | (SIGNATURE_16(C, D) << 16))
-
 #define VISOR_CHANNEL_SIGNATURE SIGNATURE_32('E', 'C', 'N', 'L')
 
 /*
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 03/46] staging: unisys: visorbus: Adding a new line between function definition

[David Kershner]

From: Zohaib Javed 

Added a new line before issue_vmcall_io_controlvm_addr() function
definition.

Signed-off-by: Zohaib Javed 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index c8a5cb2..12def21 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1325,6 +1325,7 @@ static int unisys_vmcall(unsigned long tuple, unsigned 
long param)
return -EFAULT;
}
 }
+
 static unsigned int
 issue_vmcall_io_controlvm_addr(u64 *control_addr, u32 *control_bytes)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 24/46] staging: unisys: visorbus: fix include dependency

[David Kershner]

Due to include order, the visorbus_private.h file was missing a required
include header visorbus.h. If visorchipset.c or visorbus_main.c ever were
to change the order of the includes for visobus.h and visorbus_private.h,
the code would fail to compile.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 6af9f7c..1895035 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -21,6 +21,7 @@
 
 #include "controlvmchannel.h"
 #include "vbuschannel.h"
+#include "visorbus.h"
 
 int visorchipset_bus_create(struct visor_device *bus_info);
 void visorchipset_bus_destroy(struct visor_device *bus_info);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 22/46] staging: unisys: include: Remove unnecessary forward declaration

[David Kershner]

The struct visor_device had a forward declaration that was not needed.
Remove it.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 097d4b3..1b21d66 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -39,7 +39,6 @@
 
 #include "channel.h"
 
-struct visor_driver;
 struct visor_device;
 extern struct bus_type visorbus_type;
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 23/46] staging: unisys: include: Remove unneeded includes from visorbus.h

[David Kershner]

A bunch of code churn has caused the following include files to not be
needed by visorbus.h:

linux/poll.h
linux/kernel.h
linux/uuid.h
linux/seq_file.h

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 1b21d66..4af2f99 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -31,10 +31,6 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
 #include "channel.h"
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 07/46] staging: unisys: visorbus: fix multi-line function definition

[David Kershner]

From: Charles Daniels 

Fixed incorrectly styled function definitions in visorbus/visorchipset.c
by placing the function names on the same line as the return.

Signed-off-by: Charles Daniels 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 150 +++---
 1 file changed, 61 insertions(+), 89 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 8dbde10..c4087f6 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -285,8 +285,7 @@ static void parser_done(struct parser_context *ctx)
kfree(ctx);
 }
 
-static void *
-parser_string_get(struct parser_context *ctx)
+static void *parser_string_get(struct parser_context *ctx)
 {
u8 *pscan;
unsigned long nscan;
@@ -319,8 +318,7 @@ parser_string_get(struct parser_context *ctx)
return value;
 }
 
-static void *
-parser_name_get(struct parser_context *ctx)
+static void *parser_name_get(struct parser_context *ctx)
 {
struct visor_controlvm_parameters_header *phdr = NULL;
 
@@ -373,9 +371,9 @@ struct visor_device *visorbus_get_device_by_id(u32 bus_no, 
u32 dev_no,
return vdev;
 }
 
-static void
-controlvm_init_response(struct controlvm_message *msg,
-   struct controlvm_message_header *msg_hdr, int response)
+static void controlvm_init_response(struct controlvm_message *msg,
+   struct controlvm_message_header *msg_hdr,
+   int response)
 {
memset(msg, 0, sizeof(struct controlvm_message));
memcpy(>hdr, msg_hdr, sizeof(struct controlvm_message_header));
@@ -388,10 +386,10 @@ controlvm_init_response(struct controlvm_message *msg,
}
 }
 
-static int
-controlvm_respond_chipset_init(struct controlvm_message_header *msg_hdr,
-  int response,
-  enum visor_chipset_feature features)
+static int controlvm_respond_chipset_init(
+   struct controlvm_message_header *msg_hdr,
+   int response,
+   enum visor_chipset_feature features)
 {
struct controlvm_message outmsg;
 
@@ -401,8 +399,7 @@ controlvm_respond_chipset_init(struct 
controlvm_message_header *msg_hdr,
 CONTROLVM_QUEUE_REQUEST, );
 }
 
-static int
-chipset_init(struct controlvm_message *inmsg)
+static int chipset_init(struct controlvm_message *inmsg)
 {
static int chipset_inited;
enum visor_chipset_feature features = 0;
@@ -436,9 +433,9 @@ chipset_init(struct controlvm_message *inmsg)
return res;
 }
 
-static int
-controlvm_respond(struct controlvm_message_header *msg_hdr, int response,
- struct visor_segment_state *state)
+static int controlvm_respond(struct controlvm_message_header *msg_hdr,
+int response,
+struct visor_segment_state *state)
 {
struct controlvm_message outmsg;
 
@@ -460,8 +457,8 @@ enum crash_obj_type {
CRASH_BUS,
 };
 
-static int
-save_crash_message(struct controlvm_message *msg, enum crash_obj_type cr_type)
+static int save_crash_message(struct controlvm_message *msg,
+ enum crash_obj_type cr_type)
 {
u32 local_crash_msg_offset;
u16 local_crash_msg_count;
@@ -525,10 +522,9 @@ save_crash_message(struct controlvm_message *msg, enum 
crash_obj_type cr_type)
return 0;
 }
 
-static int
-controlvm_responder(enum controlvm_id cmd_id,
-   struct controlvm_message_header *pending_msg_hdr,
-   int response)
+static int controlvm_responder(enum controlvm_id cmd_id,
+  struct controlvm_message_header *pending_msg_hdr,
+  int response)
 {
if (!pending_msg_hdr)
return -EIO;
@@ -539,10 +535,10 @@ controlvm_responder(enum controlvm_id cmd_id,
return controlvm_respond(pending_msg_hdr, response, NULL);
 }
 
-static int
-device_changestate_responder(enum controlvm_id cmd_id,
-struct visor_device *p, int response,
-struct visor_segment_state response_state)
+static int device_changestate_responder(
+   enum controlvm_id cmd_id,
+   struct visor_device *p, int response,
+   struct visor_segment_state response_state)
 {
struct controlvm_message outmsg;
u32 bus_no = p->chipset_bus_no;
@@ -563,8 +559,7 @@ device_changestate_responder(enum controlvm_id cmd_id,
 

[PATCH v2 21/46] staging: unisys: include: Fix up comment style in visorbus.h

[David Kershner]

Visorbus.h had comments that did not have /* on its own line, this patch
makes it uniform.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 354de7f..097d4b3 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -1,4 +1,5 @@
-/* visorbus.h
+/*
+ * visorbus.h
  *
  * Copyright (C) 2010 - 2013 UNISYS CORPORATION
  * All rights reserved.
@@ -54,8 +55,9 @@ struct visorchipset_state {
/* Remaining bits in this 32-bit word are unused. */
 };
 
-/** This struct describes a specific Supervisor channel, by providing its
- *  GUID, name, and sizes.
+/*
+ * This struct describes a specific Supervisor channel, by providing its
+ * GUID, name, and sizes.
  */
 struct visor_channeltype_descriptor {
const guid_t guid;
@@ -187,7 +189,8 @@ int visorbus_write_channel(struct visor_device *dev,
 int visorbus_enable_channel_interrupts(struct visor_device *dev);
 void visorbus_disable_channel_interrupts(struct visor_device *dev);
 
-/* Levels of severity for diagnostic events, in order from lowest severity to
+/*
+ * Levels of severity for diagnostic events, in order from lowest severity to
  * highest (i.e. fatal errors are the most severe, and should always be logged,
  * but info events rarely need to be logged except during debugging). The
  * values DIAG_SEVERITY_ENUM_BEGIN and DIAG_SEVERITY_ENUM_END are not valid
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 14/46] staging: unisys: visorbus: merging the visorbus_device_pause_response and visorbus_device_resume_response functions into one.

[David Kershner]

From: Sameer Wadgaonkar 

The functions viosrbus_device_pause_response() and
viosrbus_device_resume_response() are functionally similar.
Merging these functions into a single function called
visorbus_device_changestate_response().

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c|  6 +++--
 drivers/staging/unisys/visorbus/visorbus_private.h |  4 +--
 drivers/staging/unisys/visorbus/visorchipset.c | 19 +++
 3 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 93db8d3..8e8abac 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1170,7 +1170,8 @@ static void pause_state_change_complete(struct 
visor_device *dev, int status)
return;
 
dev->pausing = false;
-   visorbus_device_pause_response(dev, status);
+   visorbus_device_changestate_response(dev, status,
+segment_state_standby);
 }
 
 /*
@@ -1194,7 +1195,8 @@ static void resume_state_change_complete(struct 
visor_device *dev, int status)
 * which will presumably want to send some sort of response to
 * the initiator.
 */
-   visorbus_device_resume_response(dev, status);
+   visorbus_device_changestate_response(dev, status,
+segment_state_running);
 }
 
 /*
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index fed7e62..6af9f7c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -30,8 +30,8 @@ int visorchipset_device_pause(struct visor_device *dev_info);
 int visorchipset_device_resume(struct visor_device *dev_info);
 
 void visorbus_response(struct visor_device *p, int response, int controlvm_id);
-void visorbus_device_resume_response(struct visor_device *p, int response);
-void visorbus_device_pause_response(struct visor_device *p, int response);
+void visorbus_device_changestate_response(struct visor_device *p, int response,
+ struct visor_segment_state state);
 
 int visorbus_init(void);
 void visorbus_exit(void);
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index a203c19..bfaf17e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1455,23 +1455,12 @@ void visorbus_response(struct visor_device *bus_info, 
int response,
bus_info->pending_msg_hdr = NULL;
 }
 
-void visorbus_device_pause_response(struct visor_device *dev_info,
-   int response)
-{
-   device_changestate_responder(CONTROLVM_DEVICE_CHANGESTATE,
-dev_info, response,
-segment_state_standby);
-
-   kfree(dev_info->pending_msg_hdr);
-   dev_info->pending_msg_hdr = NULL;
-}
-
-void visorbus_device_resume_response(struct visor_device *dev_info,
-int response)
+void visorbus_device_changestate_response(struct visor_device *dev_info,
+ int response,
+ struct visor_segment_state state)
 {
device_changestate_responder(CONTROLVM_DEVICE_CHANGESTATE,
-dev_info, response,
-segment_state_running);
+dev_info, response, state);
 
kfree(dev_info->pending_msg_hdr);
dev_info->pending_msg_hdr = NULL;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 11/46] staging: unisys: visorbus: Remove unnecessary comments

[David Kershner]

From: David Binder 

Removes comments that do not provide any valuable information.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 6dd7f29..28ea21f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -53,18 +53,7 @@ struct parser_context {
char data[0];
 };
 
-/*
- * VMCALL_CONTROLVM_ADDR: Used by all guests, not just IO.
- *
- * Note: When a new VMCALL is added:
- * - The 1st 2 hex digits correspond to one of the VMCALL_MONITOR_INTERFACE
- *   types.
- * - The next 2 hex digits are the nth relative instance of within a type.
- * E.G. for VMCALL_VIRTPART_RECYCLE_PART,
- * - The 0x02 identifies it as a VMCALL_VIRTPART type.
- * - The 0x01 identifies it as the 1st instance of a VMCALL_VIRTPART type of
- *   VMCALL.
- */
+/* VMCALL_CONTROLVM_ADDR: Used by all guests, not just IO. */
 #define VMCALL_CONTROLVM_ADDR 0x0501
 
 enum vmcall_result {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 20/46] staging: unisys: include: cleanup channel comment

[David Kershner]

A comment in channel.h was referencing windows guests, in reality the OS
of the guest is agnostic and the comment should reflect that.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h |  9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 69ccc33..9fd4cc1 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -60,11 +60,10 @@ enum channel_clientstate {
 
 /*
  * Values for VISOR_CHANNEL_PROTOCOL.Features: This define exists so that
- * windows guest can look at the FeatureFlags in the io channel, and configure
- * the windows driver to use interrupts or not based on this setting.  This 
flag
- * is set in uislib after the VISOR_VHBA_init_channel is called.  All feature
- * bits for all channels should be defined here.  The io channel feature bits
- * are defined right here
+ * a guest can look at the FeatureFlags in the io channel, and configure the
+ * driver to use interrupts or not based on this setting. All feature bits for
+ * all channels should be defined here. The io channel feature bits are defined
+ * below.
  */
 #define VISOR_DRIVER_ENABLES_INTS (0x1ULL << 1)
 #define VISOR_CHANNEL_IS_POLLING (0x1ULL << 3)
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 04/46] staging: unisys: Switch to use new generic UUID API

[David Kershner]

From: Andy Shevchenko 

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

While here, re-indent couple of lines to increase readability.

Cc: David Kershner 
Cc: Greg Kroah-Hartman 
Cc: sparmaintai...@unisys.com
Cc: de...@driverdev.osuosl.org
Signed-off-by: Andy Shevchenko 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/Documentation/overview.txt  | 14 ++---
 drivers/staging/unisys/include/channel.h   | 29 -
 drivers/staging/unisys/include/iochannel.h |  2 +-
 drivers/staging/unisys/include/visorbus.h  | 14 ++---
 drivers/staging/unisys/visorbus/controlvmchannel.h | 16 ++---
 drivers/staging/unisys/visorbus/vbuschannel.h  |  8 +--
 drivers/staging/unisys/visorbus/visorbus_main.c| 44 +++---
 drivers/staging/unisys/visorbus/visorbus_private.h |  6 +-
 drivers/staging/unisys/visorbus/visorchannel.c | 46 +++
 drivers/staging/unisys/visorbus/visorchipset.c | 33 ++-
 drivers/staging/unisys/visorhba/visorhba_main.c|  6 +-
 drivers/staging/unisys/visorinput/visorinput.c | 38 ++--
 drivers/staging/unisys/visornic/visornic_main.c|  6 +-
 13 files changed, 130 insertions(+), 132 deletions(-)

diff --git a/drivers/staging/unisys/Documentation/overview.txt 
b/drivers/staging/unisys/Documentation/overview.txt
index e0466bf..9ab30af 100644
--- a/drivers/staging/unisys/Documentation/overview.txt
+++ b/drivers/staging/unisys/Documentation/overview.txt
@@ -221,7 +221,7 @@ The following files exist under 
/sys/devices/visorbus/vbus:dev:
 
 The visorhba driver registers with visorbus as the function driver to
 handle virtual scsi disk devices, specified using the
-VISOR_VHBA_CHANNEL_UUID type in the visorbus_register_visor_driver()
+VISOR_VHBA_CHANNEL_GUID type in the visorbus_register_visor_driver()
 call. visorhba uses scsi_add_host() to expose a Linux block device
 (e.g., /sys/block/) in the guest environment for each s-Par virtual device.
 
@@ -240,7 +240,7 @@ When compiled as a module, visorhba can be autoloaded by 
visorbus in
 standard udev/systemd environments, as it includes the modules.alias
 definition:
 
-"visorbus:"+VISOR_VHBA_CHANNEL_UUID_STR
+"visorbus:"+VISOR_VHBA_CHANNEL_GUID_STR
 
 i.e.:
 
@@ -252,7 +252,7 @@ i.e.:
 
 The visornic driver registers with visorbus as the function driver to
 handle virtual network devices, specified using the
-VISOR_VNIC_CHANNEL_UUID type in the visorbus_register_visor_driver()
+VISOR_VNIC_CHANNEL_GUID type in the visorbus_register_visor_driver()
 call. visornic uses register_netdev() to expose a Linux device of class net
 (e.g., /sys/class/net/) in the guest environment for each s-Par virtual
 device.
@@ -270,7 +270,7 @@ When compiled as a module, visornic can be autoloaded by 
visorbus in
 standard udev/systemd environments, as it includes the modules.alias
 definition:
 
-"visorbus:"+VISOR_VNIC_CHANNEL_UUID_STR
+"visorbus:"+VISOR_VNIC_CHANNEL_GUID_STR
 
 i.e.:
 
@@ -282,7 +282,7 @@ i.e.:
 
 The visorinput driver registers with visorbus as the function driver to
 handle human input devices, specified using the
-VISOR_KEYBOARD_CHANNEL_UUID and VISOR_MOUSE_CHANNEL_UUID
+VISOR_KEYBOARD_CHANNEL_GUID and VISOR_MOUSE_CHANNEL_GUID
 types in the visorbus_register_visor_driver() call. visorinput uses
 input_register_device() to expose devices of class input
 (e.g., /sys/class/input/) for virtual keyboard and virtual mouse devices.
@@ -307,8 +307,8 @@ When compiled as a module, visorinput can be autoloaded by 
visorbus in
 standard udev/systemd environments, as it includes the modules.alias
 definition:
 
-"visorbus:"+VISOR_MOUSE_CHANNEL_UUID_STR
-"visorbus:"+VISOR_KEYBOARD_CHANNEL_UUID_STR
+"visorbus:"+VISOR_MOUSE_CHANNEL_GUID_STR
+"visorbus:"+VISOR_KEYBOARD_CHANNEL_GUID_STR
 
 i.e.:
 
diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index d6d99cc..2dac0e5 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -128,13 +128,13 @@ struct channel_header {
u32 header_size;
u64 size;
u64 features;
-   uuid_le chtype;
+   guid_t chtype;
u64 partition_handle;
u64 handle;
u64 ch_space_offset;
u32 version_id;
u32 partition_index;
-   uuid_le zone_uuid;
+   guid_t zone_guid;
u32 cli_str_offset;
u32 cli_state_boot;
u32 cmd_state_cli;
@@ -204,23 +204,20 @@ struct signal_queue_header {
 
 /* CHANNEL Guids */
 /* {414815ed-c58c-11da-95a9-00e08161165f} */
-#define VISOR_VHBA_CHANNEL_UUID \
-   UUID_LE(0x414815ed, 0xc58c, 0x11da, \
-   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
-static 

[PATCH v2 18/46] staging: unisys: include: Remove unused vdiskmgmt commands

[David Kershner]

The vdisk task management commands are no longer used by s-Par, this
patch removes the definitions for them.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 32 +---
 1 file changed, 32 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 2b57839..7f5c0d0 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -495,36 +495,6 @@ struct uiscmdrsp_disknotify {
u32 channel, id, lun;
 } __packed;
 
-/*
- * struct uiscmdrsp_vdiskmgmt - The following is used by virthba/vSCSI to send
- * the Acquire/Release commands to the IOVM.
- * @enum vdisktype: The type of task.
- * @struct vdest:   The vdisk for which this task mgmt is generated.
- * @handle: This is a handle that the guest has saved off for its
- *  own use. It's value is preserved by iopart and returned
- *  as in the task mgmt rsp.
- * @notify_handle:  For Linux guests, this is a pointer to wait_queue_head
- *  that a thread is waiting on to see if the tskmgmt
- *  command has completed. When the rsp is received by
- *  guest, the thread receiving the response uses this to
- *  notify the thread waiting for taskmgmt command
- *  completion. It's value is preserved by iopart and
- *  returned as in the task mgmt rsp.
- * @notifyresult_handle: Handle to the location in guest where the result of 
the
- *  taskmgmt command (result field) is saved to when the
- *  response is handled. It's value is preserved by iopart
- *  and returned as in the task mgmt rsp.
- * @result: Result of taskmgmt command - set by IOPart.
- */
-struct uiscmdrsp_vdiskmgmt {
-   enum vdisk_mgmt_types vdisktype;
-   struct uisscsi_dest vdest;
-   u64 handle;
-   u64 notify_handle;
-   u64 notifyresult_handle;
-   char result;
-} __packed;
-
 /* Keeping cmd and rsp info in one structure for now cmd rsp packet for SCSI */
 struct uiscmdrsp {
char cmdtype;
@@ -533,13 +503,11 @@ struct uiscmdrsp {
 #define CMD_NET_TYPE 2
 #define CMD_SCSITASKMGMT_TYPE 3
 #define CMD_NOTIFYGUEST_TYPE  4
-#define CMD_VDISKMGMT_TYPE5
union {
struct uiscmdrsp_scsi scsi;
struct uiscmdrsp_net net;
struct uiscmdrsp_scsitaskmgmt scsitaskmgmt;
struct uiscmdrsp_disknotify disknotify;
-   struct uiscmdrsp_vdiskmgmt vdiskmgmt;
};
/* Send the response when the cmd is done (scsi and scsittaskmgmt). */
void *private_data;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 12/46] staging: unisys: include: fix improper use of dma_data_direction

[David Kershner]

From: Steven Matthews 

Replace use of standard Linux dma_data_direction with a Unisys-
specific uis_dma_data_direction and provide a function to convert
from the latter to the former.  This is necessary because Unisys
s-Par depends on the exact format of this field in multiple OSs
and languages, and so using the standard version creates an
unnecessary dependency between the kernel and s-Par.

Signed-off-by: Steven Matthews 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h  | 15 --
 drivers/staging/unisys/visorhba/visorhba_main.c | 26 +-
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index d2ef705..53259d6 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -28,7 +28,7 @@
  */
 
 #include 
-#include 
+
 #include "channel.h"
 
 /*
@@ -60,6 +60,15 @@
 
 /* Size of cdb - i.e., SCSI cmnd */
 #define MAX_CMND_SIZE 16
+
+/* Unisys-specific DMA direction values */
+enum uis_dma_data_direction {
+   UIS_DMA_BIDIRECTIONAL = 0,
+   UIS_DMA_TO_DEVICE = 1,
+   UIS_DMA_FROM_DEVICE = 2,
+   UIS_DMA_NONE = 3
+};
+
 #define MAX_SENSE_SIZE 64
 #define MAX_PHYS_INFO 64
 
@@ -182,7 +191,7 @@ struct vhba_config_max {
  * @bufflen:   Length of data to be transferred out or in.
  * @guest_phys_entries:Number of entries in scatter-gather list.
  * @struct gpi_list:   Physical address information for each fragment.
- * @enum data_dir: Direction of the data, if any.
+ * @data_dir:  Direction of the data, if any.
  * @struct vdest:  Identifies the virtual hba, id, channel, lun to which
  * cmd was sent.
  * @linuxstat: Original Linux status used by Linux vdisk.
@@ -205,7 +214,7 @@ struct uiscmdrsp_scsi {
u32 bufflen;
u16 guest_phys_entries;
struct guest_phys_info gpi_list[MAX_PHYS_INFO];
-   enum dma_data_direction data_dir;
+   u32 data_dir;
struct uisscsi_dest vdest;
/* Needed to queue the rsp back to cmd originator. */
int linuxstat;
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2a4248a..29efdf9 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -478,6 +478,29 @@ static const char *visorhba_get_info(struct Scsi_Host *shp)
 }
 
 /*
+ * dma_data_dir_linux_to_spar - convert dma_data_direction value to
+ * Unisys-specific equivalent
+ * @d: dma direction value to convert
+ *
+ * Returns the Unisys-specific dma direction value corresponding to @d
+ */
+static u32 dma_data_dir_linux_to_spar(enum dma_data_direction d)
+{
+   switch (d) {
+   case DMA_BIDIRECTIONAL:
+   return UIS_DMA_BIDIRECTIONAL;
+   case DMA_TO_DEVICE:
+   return UIS_DMA_TO_DEVICE;
+   case DMA_FROM_DEVICE:
+   return UIS_DMA_FROM_DEVICE;
+   case DMA_NONE:
+   return UIS_DMA_NONE;
+   default:
+   return UIS_DMA_NONE;
+   }
+}
+
+/*
  * visorhba_queue_command_lck - Queues command to the Service Partition
  * @scsicmd:   Command to be queued
  * @vsiorhba_cmnd_done: Done command to call when scsicmd is returned
@@ -525,7 +548,8 @@ static int visorhba_queue_command_lck(struct scsi_cmnd 
*scsicmd,
cmdrsp->scsi.vdest.id = scsidev->id;
cmdrsp->scsi.vdest.lun = scsidev->lun;
/* save datadir */
-   cmdrsp->scsi.data_dir = scsicmd->sc_data_direction;
+   cmdrsp->scsi.data_dir =
+   dma_data_dir_linux_to_spar(scsicmd->sc_data_direction);
memcpy(cmdrsp->scsi.cmnd, cdb, MAX_CMND_SIZE);
cmdrsp->scsi.bufflen = scsi_bufflen(scsicmd);
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 02/46] staging: unisys: include: iochannel.h: Removed unused DEFINE

[David Kershner]

From: Zohaib Javed 

Removed unused #define GPI_ENTRIES_PER_PAGE

Signed-off-by: Zohaib Javed 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 80b9ef3..40eb7d5 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -133,8 +133,6 @@ struct guest_phys_info {
u64 length;
 } __packed;
 
-#define GPI_ENTRIES_PER_PAGE (PAGE_SIZE / sizeof(struct guest_phys_info))
-
 /*
  * struct uisscsi_dest
  * @channel: Bus number.
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 05/46] staging: unisys: visorbus: Update comment style vbuschannel.h

[David Kershner]

From: Mark Foresta 

Moved blocked comment on to own line at beginning of struct to follow
standard. Since this is an internal structure, the block comment isn't
actually a kernel-doc so we only start the block with one asterisk.

Signed-off-by: Mark Foresta 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 61e38bd..27e04de 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -43,7 +43,8 @@
  */
 #define VISOR_VBUS_CHANNEL_VERSIONID 1
 
-/* struct visor_vbus_deviceinfo
+/*
+ * struct visor_vbus_deviceinfo
  * @devtype:  Short string identifying the device type.
  * @drvname:  Driver .sys file name.
  * @infostrs: Kernel vversion.
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 06/46] staging: unisys: visorbus: visorbus_private.h remove filename

[David Kershner]

From: Mark Foresta 

Remove the filename in the comment at the beginning of the file.

Signed-off-by: Mark Foresta 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index d91c5b5..74248c5 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -1,5 +1,4 @@
-/* visorbus_private.h
- *
+/*
  * Copyright (C) 2010 - 2015 UNISYS CORPORATION
  * All rights reserved.
  *
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 09/46] staging: unisys: visornic: visornic_main.c: fix multiline dereference.

[David Kershner]

From: Sameer Wadgaonkar 

This patch fixes two checkpatch warnings in the visornic_main.c
file to avoid multiline dereference.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c |  9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index feb05f9..135d37c 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -288,11 +288,10 @@ static int visor_copy_fragsinfo_from_skb(struct sk_buff 
*skb,
 
for (frag = 0; frag < numfrags; frag++) {
count = add_physinfo_entries(page_to_pfn(
-   skb_frag_page(_shinfo(skb)->frags[frag])),
- skb_shinfo(skb)->frags[frag].
- page_offset,
- skb_shinfo(skb)->frags[frag].
- size, count, frags_max, frags);
+ skb_frag_page(_shinfo(skb)->frags[frag])),
+ skb_shinfo(skb)->frags[frag].page_offset,
+ skb_shinfo(skb)->frags[frag].size, count,
+ frags_max, frags);
/* add_physinfo_entries only returns
 * zero if the frags array is out of room
 * That should never happen because we
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 17/46] staging: unisys: include: iochannel.h: Update comments for #defines

[David Kershner]

Cleaned up some #defines to make the beginning of the file read easier.

Reviewed-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index e6f1d55..2b57839 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -46,12 +46,12 @@
  * IO Partition is defined below.
  */
 
-/* Define the two queues per data channel between iopart and ioguestparts. */
-
-/* Used by ioguestpart to 'insert' signals to iopart. */
+/*
+ * Define the two queues per data channel between iopart and ioguestparts.
+ * IOCHAN_TO_IOPART -- used by guest to 'insert' signals to iopart.
+ * IOCHAN_FROM_IOPART -- used by guest to 'remove' signals from IO part.
+ */
 #define IOCHAN_TO_IOPART 0
-
-/* Used by ioguestpart to 'remove' signals from iopart, same previous queue. */
 #define IOCHAN_FROM_IOPART 1
 
 /* Size of cdb - i.e., SCSI cmnd */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 08/46] staging: unisys: visornic: update the struct visornic_devdata comments

[David Kershner]

From: Sameer Wadgaonkar 

Cleaned up the in-line comments in the structure and added a single block
comment for the structure.

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: David Binder 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 86 --
 1 file changed, 61 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index feb78d5..feb05f9 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -68,10 +68,68 @@ struct chanstat {
unsigned long extra_rcvbufs_sent;
 };
 
+/* struct visornic_devdata
+ *
+ * @enabled:0 disabled 1 enabled to receive.
+ * @enab_dis_acked: NET_RCV_ENABLE/DISABLE acked by IOPART.
+ * @struct *dev:
+ * @struct *netdev:
+ * @struct net_stats:
+ * @interrupt_rcvd:
+ * @rsp_queue:
+ * @struct **rcvbuf:
+ * @incarnation_id: incarnation_id lets IOPART know about
+ *  re-birth.
+ * @old_flags:  flags as they were prior to
+ *  set_multicast_list.
+ * @usage:  count of users.
+ * @num_rcv_bufs:   number of rcv buffers the vnic will post.
+ * @num_rcv_bufs_could_not_alloc:
+ * @num_rcvbuf_in_iovm:
+ * @alloc_failed_in_if_needed_cnt:
+ * @alloc_failed_in_repost_rtn_cnt:
+ * @max_outstanding_net_xmits:  absolute max number of outstanding xmits
+ *  - should never hit this.
+ * @upper_threshold_net_xmits:  high water mark for calling
+ *  netif_stop_queue().
+ * @lower_threshold_net_xmits:  high water mark for calling
+ *  netif_wake_queue().
+ * @struct xmitbufhead: xmitbufhead - head of the xmit buffer list
+ *  sent to the IOPART end.
+ * @server_down_complete_func:
+ * @struct timeout_reset:
+ * @struct *cmdrsp_rcv: cmdrsp_rcv is used for posting/unposting 
rcv
+ *  buffers.
+ * @struct *xmit_cmdrsp:xmit_cmdrsp - issues NET_XMIT - only one
+ *  active xmit at a time.
+ * @server_down:IOPART is down.
+ * @server_change_state:Processing SERVER_CHANGESTATE msg.
+ * @going_away: device is being torn down.
+ * @struct *eth_debugfs_dir:
+ * @interrupts_rcvd:
+ * @interrupts_notme:
+ * @interrupts_disabled:
+ * @busy_cnt:
+ * @priv_lock:  spinlock to access devdata structures.
+ * @flow_control_upper_hits:
+ * @flow_control_lower_hits:
+ * @n_rcv0: # rcvs of 0 buffers.
+ * @n_rcv1: # rcvs of 1 buffers.
+ * @n_rcv2: # rcvs of 2 buffers.
+ * @n_rcvx: # rcvs of >2 buffers.
+ * @found_repost_rcvbuf_cnt:# repost_rcvbuf_cnt.
+ * @repost_found_skb_cnt:   # of found the skb.
+ * @n_repost_deficit:   # of lost rcv buffers.
+ * @bad_rcv_buf:# of unknown rcv skb not freed.
+ * @n_rcv_packets_not_accepted: # bogs rcv packets.
+ * @queuefullmsg_logged:
+ * @struct chstat:
+ * @struct irq_poll_timer:
+ * @struct napi:
+ * @struct cmdrsp:
+ */
 struct visornic_devdata {
-   /* 0 disabled 1 enabled to receive */
unsigned short enabled;
-   /* NET_RCV_ENABLE/DISABLE acked by IOPART */
unsigned short enab_dis_acked;
 
struct visor_device *dev;
@@ -80,47 +138,34 @@ struct visornic_devdata {
atomic_t interrupt_rcvd;
wait_queue_head_t rsp_queue;
struct sk_buff **rcvbuf;
-   /* incarnation_id lets IOPART know about re-birth */
u64 incarnation_id;
-   /* flags as they were prior to set_multicast_list */
unsigned short old_flags;
-   /* count of users */
atomic_t usage;
 
-   /* number of rcv buffers the vnic will post */
int num_rcv_bufs;
int num_rcv_bufs_could_not_alloc;
atomic_t num_rcvbuf_in_iovm;
unsigned long alloc_failed_in_if_needed_cnt;
unsigned long alloc_failed_in_repost_rtn_cnt;
 
-   /* absolute max number of outstanding xmits - should never hit this */
unsigned long max_outstanding_net_xmits;
-   /* high water mark for calling netif_stop_queue() */
unsigned long upper_threshold_net_xmits;
-   /* high water mark for calling netif_wake_queue() */
unsigned long lower_threshold_net_xmits;
-   /* xmitbufhead - head of the xmit buffer list sent to the IOPART end */
struct sk_buff_head xmitbufhead;
 
visorbus_state_complete_func 

[PATCH v2 13/46] staging: unisys: visorbus: merging the visorbus_*_response functions into one.

[David Kershner]

From: Sameer Wadgaonkar 

The functions visorbus_create_response(), visorbus_destroy_response(),
viosrbus_device_create_response(), viosrbus_device_destroy_response()
are all functionally similar. Merging these four functions into a
single function called visorbus_response().

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c| 10 ++--
 drivers/staging/unisys/visorbus/visorbus_private.h |  5 +--
 drivers/staging/unisys/visorbus/visorchipset.c | 41 +--
 3 files changed, 10 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index e89cee0..93db8d3 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1123,7 +1123,8 @@ int visorchipset_bus_create(struct visor_device *dev)
if (err < 0)
return err;
 
-   visorbus_create_response(dev, err);
+   visorbus_response(dev, err, CONTROLVM_BUS_CREATE);
+   dev->state.created = 1;
 
return 0;
 }
@@ -1131,7 +1132,7 @@ int visorchipset_bus_create(struct visor_device *dev)
 void visorchipset_bus_destroy(struct visor_device *dev)
 {
visorbus_remove_instance(dev);
-   visorbus_destroy_response(dev, 0);
+   visorbus_response(dev, 0, CONTROLVM_BUS_DESTROY);
 }
 
 int visorchipset_device_create(struct visor_device *dev_info)
@@ -1142,7 +1143,8 @@ int visorchipset_device_create(struct visor_device 
*dev_info)
if (err < 0)
return err;
 
-   visorbus_device_create_response(dev_info, err);
+   visorbus_response(dev_info, err, CONTROLVM_DEVICE_CREATE);
+   dev_info->state.created = 1;
 
return 0;
 }
@@ -1150,7 +1152,7 @@ int visorchipset_device_create(struct visor_device 
*dev_info)
 void visorchipset_device_destroy(struct visor_device *dev_info)
 {
remove_visor_device(dev_info);
-   visorbus_device_destroy_response(dev_info, 0);
+   visorbus_response(dev_info, 0, CONTROLVM_DEVICE_DESTROY);
 }
 
 /*
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 74248c5..fed7e62 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -29,10 +29,7 @@ void visorchipset_device_destroy(struct visor_device 
*dev_info);
 int visorchipset_device_pause(struct visor_device *dev_info);
 int visorchipset_device_resume(struct visor_device *dev_info);
 
-void visorbus_create_response(struct visor_device *p, int response);
-void visorbus_destroy_response(struct visor_device *p, int response);
-void visorbus_device_create_response(struct visor_device *p, int response);
-void visorbus_device_destroy_response(struct visor_device *p, int response);
+void visorbus_response(struct visor_device *p, int response, int controlvm_id);
 void visorbus_device_resume_response(struct visor_device *p, int response);
 void visorbus_device_pause_response(struct visor_device *p, int response);
 
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 28ea21f..a203c19 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1446,50 +1446,15 @@ static void setup_crash_devices_work_queue(struct 
work_struct *work)
visorbus_device_create(_crash_dev_msg);
 }
 
-void visorbus_create_response(struct visor_device *bus_info, int response)
+void visorbus_response(struct visor_device *bus_info, int response,
+  int controlvm_id)
 {
-   if (response >= 0)
-   bus_info->state.created = 1;
-
-   controlvm_responder(CONTROLVM_BUS_CREATE, bus_info->pending_msg_hdr,
-   response);
+   controlvm_responder(controlvm_id, bus_info->pending_msg_hdr, response);
 
kfree(bus_info->pending_msg_hdr);
bus_info->pending_msg_hdr = NULL;
 }
 
-void visorbus_destroy_response(struct visor_device *bus_info, int response)
-{
-   controlvm_responder(CONTROLVM_BUS_DESTROY, bus_info->pending_msg_hdr,
-   response);
-
-   kfree(bus_info->pending_msg_hdr);
-   bus_info->pending_msg_hdr = NULL;
-}
-
-void visorbus_device_create_response(struct visor_device *dev_info,
-int response)
-{
-   if (response >= 0)
-   dev_info->state.created = 1;
-
-   controlvm_responder(CONTROLVM_DEVICE_CREATE, dev_info->pending_msg_hdr,
-   response);
-
-   kfree(dev_info->pending_msg_hdr);
-   dev_info->pending_msg_hdr = NULL;
-}
-
-void visorbus_device_destroy_response(struct visor_device *dev_info,
-   

[PATCH v2 00/46] staging: unisys: Additional code changes

[David Kershner]

Several simplifications and cleanup patches. This series now includes the
patch to switch to use the new UUID API.

-- Changes since v1
 -- Incorporated UUID API patch
 -- Refactored other patches that were affected by the UUID API patch.

Andy Shevchenko (1):
  staging: unisys: Switch to use new generic UUID API

Charles Daniels (1):
  staging: unisys: visorbus: fix multi-line function definition

David Binder (10):
  staging: unisys: visorbus: Merge vmcallinterface.h into visorchipset.c
  staging: unisys: visorbus: Remove unnecessary comments
  staging: unisys: visorbus: visorchipset.c: Fix SonarQube sprintf findings
  staging: unisys: visorbus: visorbus_main.c: Remove filename in top comment
  staging: unisys: visorbus: visorchannel.c: Remove filename in top comment
  staging: unisys: visorinput: visorinput.c: Remove filename in top comment
  staging: unisys: include: visorbus.h: Remove filename in top comment
  staging: unisys: visorhba: Adjust top comment formatting
  staging: unisys: visorinput: ultrainputreport.h: Adjust comment formatting
  staging: unisys: include: iochannel.h: Add proper copyright statement

David Kershner (21):
  staging: unisys: include: Remove unused #define MAXNUM
  staging: unisys: use the kernel min define
  staging: unisys: include: iochannel.h: Update comments for #defines
  staging: unisys: include: Remove unused vdiskmgmt commands
  staging: unisys: include: Remove unused throttling defines.
  staging: unisys: include: cleanup channel comment
  staging: unisys: include: Fix up comment style in visorbus.h
  staging: unisys: include: Remove unnecessary forward declaration
  staging: unisys: include: Remove unneeded includes from visorbus.h
  staging: unisys: visorbus: fix include dependency
  staging: unisys: visorbus: Remove unnecessary includes for visorchipset.c
  staging: unisys: include: iochannel needs to include skbuff
  staging: unisys: visorinput: Get rid of unused includes
  staging: unisys: include: remove unnecessary blank line from channel.h
  staging: unisys: Move VNIC GUID to visornic
  staging: unisys: Move SIOVM guid to visorbus
  staging: unisys: visorbus: Remove confusing comment in controlvmchannel.
  staging: unisys: don't copy to local variable
  staging: unisys: reference bus_no and dev_no directly
  staging: unisys: visorbus: Get rid of passthrough function 
visorchipset_bus_create
  staging: unisys: use ATTRIBUTE_GROUPS instead of creating our own

Mark Foresta (2):
  staging: unisys: visorbus: Update comment style vbuschannel.h
  staging: unisys: visorbus: visorbus_private.h remove filename

Sameer Wadgaonkar (7):
  staging: unisys: visornic: update the struct visornic_devdata comments
  staging: unisys: visornic: visornic_main.c: fix multiline dereference.
  staging: unisys: visorbus: merging the visorbus_*_response functions into one.
  staging: unisys: visorbus: merging the visorbus_device_pause_response and 
visorbus_device_resume_response functions into one.
  staging: unisys: visorbus: Get rid of passthrough function 
visorchipset_bus_destroy
  staging: unisys: visorbus: Get rid of passthrough function 
visorchipset_device_create
  staging: unisys: visorbus: Get rid of passthrough function 
visorchipset_device_destroy

Steven Matthews (1):
  staging: unisys: include: fix improper use of dma_data_direction

Zohaib Javed (3):
  staging: unisys: visorbus: remove filename from beginning of file
  staging: unisys: include: iochannel.h: Removed unused DEFINE
  staging: unisys: visorbus: Adding a new line between function definition

 drivers/staging/unisys/Documentation/overview.txt|  14 +-
 drivers/staging/unisys/include/channel.h |  53 +--
 drivers/staging/unisys/include/iochannel.h   |  84 +--
 drivers/staging/unisys/include/visorbus.h|  30 +-
 drivers/staging/unisys/visorbus/controlvmchannel.h   |  17 +-
 drivers/staging/unisys/visorbus/vbuschannel.h|  11 +-
 drivers/staging/unisys/visorbus/visorbus_main.c  | 138 +-
 drivers/staging/unisys/visorbus/visorbus_private.h   |  28 +-
 drivers/staging/unisys/visorbus/visorchannel.c   |  49 +--
 drivers/staging/unisys/visorbus/visorchipset.c   | 296 +---
 drivers/staging/unisys/visorbus/vmcallinterface.h|  61 +--
 drivers/staging/unisys/visorhba/visorhba_main.c  |  36 +-
 drivers/staging/unisys/visorinput/ultrainputreport.h |   3 +-
 drivers/staging/unisys/visorinput/visorinput.c   |  44 +--
 drivers/staging/unisys/visornic/visornic_main.c  | 110 ++--
 15 files changed, 410 insertions(+), 564 deletions(-)
 delete mode 100644 drivers/staging/unisys/visorbus/vmcallinterface.h

base-commit: a575de2da5e20c31f4ffcb1df555c199ad77fc20
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH][staging-next] staging: typec: tcpm: make function tcpm_get_pwr_opmode

[Colin King]

From: Colin Ian King 

The function pointer tcpm_get_pwr_opmode is local to the source and does
not need to be in global scope, so make it static.

Cleans up sparse warning:
symbol 'tcpm_get_pwr_opmode' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/staging/typec/tcpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 7b5ba27dd935..a911cad41a59 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -2131,7 +2131,7 @@ static void tcpm_swap_complete(struct tcpm_port *port, 
int result)
}
 }
 
-enum typec_pwr_opmode tcpm_get_pwr_opmode(enum typec_cc_status cc)
+static enum typec_pwr_opmode tcpm_get_pwr_opmode(enum typec_cc_status cc)
 {
switch (cc) {
case TYPEC_CC_RP_1_5:
-- 
2.14.1

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

[PATCH] staging: rtlwifi: fix multiple build errors

[Randy Dunlap]

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

Fix many build errors when NETDEVICES is not enabled.

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtlwifi/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20170822.orig/drivers/staging/rtlwifi/Kconfig
+++ linux-next-20170822/drivers/staging/rtlwifi/Kconfig
@@ -1,6 +1,6 @@
 config R8822BE
tristate "Realtek RTL8822BE Wireless Network Adapter"
-   depends on PCI && m
+   depends on NETDEVICES && PCI && m
select FW_LOADER
---help---
This is the staging driver for Realtek RTL8822BE 802.11ac PCIe


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

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

[Greg KH]

On Mon, Aug 21, 2017 at 11:48:39AM -0700, John Stultz wrote:
> On Tue, Aug 8, 2017 at 11:08 AM, Greg KH  wrote:
> > On Tue, Aug 08, 2017 at 10:34:47AM -0700, John Stultz wrote:
> >> On Fri, Jul 28, 2017 at 4:56 AM, Martijn Coenen  wrote:
> >> > Commit c4ea41ba195d ("binder: use group leader instead of open thread")'
> >> > was incomplete and didn't update a check in binder_mmap(), causing all
> >> > mmap() calls into the binder driver to fail.
> >> >
> >> > Signed-off-by: Martijn Coenen 
> >> > ---
> >> >  drivers/android/binder.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> >> > index f7665c31feca..831cdd7d197d 100644
> >> > --- a/drivers/android/binder.c
> >> > +++ b/drivers/android/binder.c
> >> > @@ -3362,7 +3362,7 @@ static int binder_mmap(struct file *filp, struct 
> >> > vm_area_struct *vma)
> >> > const char *failure_string;
> >> > struct binder_buffer *buffer;
> >> >
> >> > -   if (proc->tsk != current)
> >> > +   if (proc->tsk != current->group_leader)
> >> > return -EINVAL;
> >> >
> >> > if ((vma->vm_end - vma->vm_start) > SZ_4M)
> >>
> >> Tested-by: John Stultz 
> >>
> >> As Amit already confirmed, this resolves the wifi and bluetooth
> >> regression I was seeing with Android using 4.13-rc2.
> >>
> >> Though I've not seen it show up in Linus' tree yet, so I wanted to
> >> pester folks so it gets into 4.13-rc (its given me some slight grief
> >> trying to bisect down a separate issue).
> >
> > I will queue this up in the next few days, I need to resolve the patches
> > that have been sent to me for this, sorry for the delay.
> 
> Hey Greg,
>   Sorry to pester you again on this, but this seems to still be
> missing in -rc6. Don't want it to slip by.

It's not lost, just on the bottom of my queue, will catch up with it
next week...

thanks,

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

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Dan Carpenter]

Try saving this email and then do `cat email.txt | git am`.  It is
corrupted.  This is not how to send a v2 patch.  Please read:

https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb

Look through the email archives for examples of other v2 patches.

regards,
dan carpenter

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

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Rishabh Hardas]

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote:
> On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote:
> > From: RishabhHardas 
> > 
> > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
> > 'fips_handler'
> > that they were not declared and need to be made static. This patch makes 
> > both the symbols
> > static inline, to remove the warnings.
> > 
> > Signed-off-by: RishabhHardas 
> 
> I doubt you sign your name on legal documents without a ' ' somewhere in
> it :(
> 
> Please fix up and resend.
> 
> thanks,
> 
> greg k-h

>From 717ec264a6212b8526c381d3673dd0ee45352266 Mon Sep 17 00:00:00 2001
From: Rishabh Hardas 
Date: Tue, 22 Aug 2017 18:56:45 +0530
Subject: [PATCH v2] staging/ccree: Declare compiled out fuctions static inline

Signed-off-by: Rishabh Hardas 
---

Changes in v2:
Corrected my Name.
 drivers/staging/ccree/ssi_fips.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 369ddf9..63bcca7 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -40,8 +40,8 @@ static inline int ssi_fips_init(struct ssi_drvdata *p_drvdata)
 }

 static inline void ssi_fips_fini(struct ssi_drvdata *drvdata) {}
-void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool ok) {}
-void fips_handler(struct ssi_drvdata *drvdata) {}
+static inline void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool 
ok) {}
+static inline void fips_handler(struct ssi_drvdata *drvdata) {}

 #endif /* CONFIG_CRYPTO_FIPS */

--
1.9.1

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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

[Jorgen S. Hansen]

> On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi  wrote:
> 
> On Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote:
>>> Not all features need to be supported.  For example, VMCI supports
>>> SOCK_DGRAM while Hyper-V and virtio do not.  But features that are
>>> available should behave identically.
>> I totally agree, though I'm afraid Hyper-V may have a little more limitations
>> compared to VMware/KVM duo to the  <--> 
>> mapping.
>> 
 Can we use the 'protocol' parameter in the socket() function:
 int socket(int domain, int type, int protocol)
 
 IMO currently the 'protocol' is not really used.
 I think we can modify __vsock_core_init() to allow multiple transport 
 layers
>>> to
 be registered, and we can define different 'protocol' numbers for
 VMware/KVM/Hyper-V, and ask the application to explicitly specify what
>>> should
 be used. Considering compatibility, we can use the default transport in a
>>> given
 VM depending on the underlying hypervisor.
>>> 
>>> I think AF_VSOCK should hide the transport from users/applications.
>> Ideally yes, but let's consider the KVM-on-KVM nested scenario: when
>> an application in the Level-1 VM creates an AF_VSOCK socket and call
>> connect() for it, how can we know if the app is trying to connect to
>> the Level-0 host, or connect to the Level-2 VM? We can't.
> 
> We *can* by looking at the destination CID.  Please take a look at
> drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI handles
> nested virt.
> 
> It boils down to something like this:
> 
>  static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
>  int addr_len, int flags)
>  {
>  ...
>  if (remote_addr.svm_cid == VMADDR_CID_HOST)
>  transport = host_transport;
>  else
>  transport = guest_transport;
> 
> It's easy for connect(2) but Jorgen mentioned it's harder for listen(2)
> because the socket would need to listen on both transports.  We define
> two new constants VMADDR_CID_LISTEN_FROM_GUEST and
> VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can decide
> which side to listen on.

If a socket is bound to VMADDR_CID_HOST, we would consider that socket as bound 
to the host side transport, so that would be the same as 
VMADDR_CID_LISTEN_FROM_GUEST. For the guest, we have 
IOCTL_VM_SOCKETS_GET_LOCAL_CID, so that could be used to get and bind a socket 
to the guest transport (VMCI will always return the guest CID as the local one, 
if the VMCI driver is used in a guest, and it looks like virtio will do the 
same). We could treat VMADDR_CID_ANY as always being the guest transport, since 
that is the use case where you don’t know upfront what your CID is, if we don’t 
want to listen on all transports. So we would use the host transport, if a 
socket is bound to VMADDR_CID_HOST, or if there is no guest transport, and in 
all other cases use the guest transport. However, having a couple of symbolic 
names like you suggest certainly makes it more obvious, and could be used in 
combination with this. It would be a plus if existing applications would 
function as intended in most cases.

>   Or the listen socket could simply listen to
> both sides.

The only problem here would be the potential for a guest and a host app to have 
a conflict wrt port numbers, even though they would be able to operate fine, if 
restricted to their appropriate transport.

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

Re: [PATCH 15/15] usb: make device_type const

[Heikki Krogerus]

On Sat, Aug 19, 2017 at 01:52:26PM +0530, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 930e8f3..4aa5195 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -135,7 +135,7 @@ static void ulpi_dev_release(struct device *dev)
>   kfree(to_ulpi_dev(dev));
>  }
>  
> -static struct device_type ulpi_dev_type = {
> +static const struct device_type ulpi_dev_type = {
>   .name = "ulpi_device",
>   .groups = ulpi_dev_attr_groups,
>   .release = ulpi_dev_release,

Thanks,

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

[PATCH][next] staging: r8822be: fix a couple of spelling mistakes

[Colin King]

From: Colin Ian King 

Trivial fixes to spelling mistake in pr_err error messages:

errorr -> error
mismactch -> mismatch

Signed-off-by: Colin Ian King 
---
 .../staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c |  2 +-
 .../rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c| 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c 
b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
index fadb35f3ba88..ee7c3d0a6e34 100644
--- a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
+++ b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
@@ -1256,7 +1256,7 @@ halmac_init_mac_cfg_88xx(struct halmac_adapter 
*halmac_adapter,
 
status = halmac_api->halmac_init_trx_cfg(halmac_adapter, mode);
if (status != HALMAC_RET_SUCCESS) {
-   pr_err("halmac_init_trx_cfg errorr = %x\n", status);
+   pr_err("halmac_init_trx_cfg error = %x\n", status);
return status;
}
status = halmac_api->halmac_init_protocol_cfg(halmac_adapter);
diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c 
b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
index cc39679aaa64..50f6f256795a 100644
--- a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
+++ b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
@@ -2477,7 +2477,7 @@ halmac_parse_psd_data_88xx(struct halmac_adapter 
*halmac_adapter, u8 *c2h_buf,
"[TRACE]Seq num : h2c -> %d c2h -> %d\n",
psd_set->seq_num, h2c_seq);
if (h2c_seq != psd_set->seq_num) {
-   pr_err("[ERR]Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("[ERR]Seq num mismatch : h2c -> %d c2h -> %d\n",
   psd_set->seq_num, h2c_seq);
return HALMAC_RET_SUCCESS;
}
@@ -2531,7 +2531,7 @@ halmac_parse_efuse_data_88xx(struct halmac_adapter 
*halmac_adapter, u8 *c2h_buf,
halmac_adapter->halmac_state.efuse_state_set.seq_num,
h2c_seq);
if (h2c_seq != halmac_adapter->halmac_state.efuse_state_set.seq_num) {
-   pr_err("[ERR]Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("[ERR]Seq num mismatch : h2c -> %d c2h -> %d\n",
   halmac_adapter->halmac_state.efuse_state_set.seq_num,
   h2c_seq);
return HALMAC_RET_SUCCESS;
@@ -2728,7 +2728,7 @@ halmac_parse_h2c_ack_phy_efuse_88xx(struct halmac_adapter 
*halmac_adapter,
halmac_adapter->halmac_state.efuse_state_set.seq_num,
h2c_seq);
if (h2c_seq != halmac_adapter->halmac_state.efuse_state_set.seq_num) {
-   pr_err("[ERR]Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("[ERR]Seq num mismatch : h2c -> %d c2h -> %d\n",
   halmac_adapter->halmac_state.efuse_state_set.seq_num,
   h2c_seq);
return HALMAC_RET_SUCCESS;
@@ -2765,7 +2765,7 @@ halmac_parse_h2c_ack_cfg_para_88xx(struct halmac_adapter 
*halmac_adapter,
h2c_seq);
if (h2c_seq !=
halmac_adapter->halmac_state.cfg_para_state_set.seq_num) {
-   pr_err("Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("Seq num mismatch : h2c -> %d c2h -> %d\n",
   halmac_adapter->halmac_state.cfg_para_state_set.seq_num,
   h2c_seq);
return HALMAC_RET_SUCCESS;
@@ -2833,7 +2833,7 @@ halmac_parse_h2c_ack_update_packet_88xx(struct 
halmac_adapter *halmac_adapter,
halmac_adapter->halmac_state.update_packet_set.seq_num,
h2c_seq);
if (h2c_seq != halmac_adapter->halmac_state.update_packet_set.seq_num) {
-   pr_err("[ERR]Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("[ERR]Seq num mismatch : h2c -> %d c2h -> %d\n",
   halmac_adapter->halmac_state.update_packet_set.seq_num,
   h2c_seq);
return HALMAC_RET_SUCCESS;
@@ -2916,7 +2916,7 @@ halmac_parse_h2c_ack_channel_switch_88xx(struct 
halmac_adapter *halmac_adapter,
halmac_adapter->halmac_state.scan_state_set.seq_num,
h2c_seq);
if (h2c_seq != halmac_adapter->halmac_state.scan_state_set.seq_num) {
-   pr_err("[ERR]Seq num mismactch : h2c -> %d c2h -> %d\n",
+   pr_err("[ERR]Seq num misactch : h2c -> %d c2h -> %d\n",
   halmac_adapter->halmac_state.scan_state_set.seq_num,
   h2c_seq);
return HALMAC_RET_SUCCESS;
@@ -2968,7 +2968,7 @@ halmac_parse_h2c_ack_iqk_88xx(struct halmac_adapter 
*halmac_adapter,

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Dan Carpenter]

Google for how to send a v2 patch.

https://www.google.com/search?q=how+to+send+a+v2+patch

https://kernelnewbies.org/FirstKernelPatch

regards,
dan carpenter

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

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Rishabh Hardas]

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote:
> On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote:
> > From: RishabhHardas 
> > 
> > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
> > 'fips_handler'
> > that they were not declared and need to be made static. This patch makes 
> > both the symbols
> > static inline, to remove the warnings.
> > 
> > Signed-off-by: RishabhHardas 
> 
> I doubt you sign your name on legal documents without a ' ' somewhere in
> it :(
> 
> Please fix up and resend.
> 
> thanks,
> 
> greg k-h
From: Rishabh Hardas 

Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
'fips_handler'
that they were not declared and need to be made static. This patch makes both 
the symbols
static inline, to remove the warnings.

Signed-off-by: Rishabh Hardas 
---
 drivers/staging/ccree/ssi_fips.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 369ddf9..63bcca7 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -40,1 +40,1 @@ static inline int ssi_fips_init(struct ssi_drvdata *p_drvdata)
 }

 static inline void ssi_fips_fini(struct ssi_drvdata *drvdata) {}
-void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool ok) {}
-void fips_handler(struct ssi_drvdata *drvdata) {}
+static inline void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool 
ok) {}
+static inline void fips_handler(struct ssi_drvdata *drvdata) {}

 #endif /* CONFIG_CRYPTO_FIPS */

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

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

[Dan Carpenter]

I'm skeptical that these are the absolute platonic ideal of what the
code should look like...  You may be right that it's mathematically
impossible to make these lines more readable, but we can't really debate
alternate versions of this until someone sends us a patch.

regards,
dan carpenter

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

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

[Marcus Wolf]

Hi everybody,

from my point of view, we should stay with the old implementation.

Ok - line is too long according to style guide. But these long lines are 
IMHO easy to read:
All four are pretty similar. By having all Tokens in exact the same length 
and having one below other, you can easily detect the differences between
the lines and that's important. As soon as you start to wrap them 
- regardless how - you won't be able to detect the differences that easy 
any more - and from my Point of view that's a disadvantage.

Cheers,

Marcus

> Dan Carpenter  hat am 22. August 2017 um 12:03
> geschrieben:
>
>
> On Tue, Aug 22, 2017 at 02:57:49PM +0530, Rishabh Hardas wrote:
> > On Sat, Aug 19, 2017 at 09:47:28PM -0700, Joe Perches wrote:
> > > On Wed, 2017-08-16 at 10:31 +0300, Dan Carpenter wrote:
> > > > On Wed, Aug 16, 2017 at 10:53:18AM +0530, Rishabh Hardas wrote:
> > > > > @@ -143,10 +142,13 @@ struct pi433_rx_cfg {
> > > > >
> > > > > #define PI433_IOC_MAGIC 'r'
> > > > >
> > > > > -#define PI433_IOC_RD_TX_CFG _IOR(PI433_IOC_MAGIC,
> > > > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > > > -#define PI433_IOC_WR_TX_CFG _IOW(PI433_IOC_MAGIC,
> > > > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > > > -
> > > > > -#define PI433_IOC_RD_RX_CFG _IOR(PI433_IOC_MAGIC,
> > > > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > > > -#define PI433_IOC_WR_RX_CFG _IOW(PI433_IOC_MAGIC,
> > > > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > > > +#define PI433_IOC_RD_TX_CFG _IOR(PI433_IOC_MAGIC,
> > > > > PI433_TX_CFG_IOCTL_NR,\
> > > > > + char[sizeof(struct pi433_tx_cfg)])
> > > > > +#define PI433_IOC_WR_TX_CFG _IOW(PI433_IOC_MAGIC,
> > > > > PI433_TX_CFG_IOCTL_NR,\
> > > > > + char[sizeof(struct pi433_tx_cfg)])
> > > > > +#define PI433_IOC_RD_RX_CFG _IOR(PI433_IOC_MAGIC,
> > > > > PI433_RX_CFG_IOCTL_NR,\
> > > > > + char[sizeof(struct pi433_rx_cfg)])
> > > > > +#define PI433_IOC_WR_RX_CFG _IOW(PI433_IOC_MAGIC,
> > > > > PI433_RX_CFG_IOCTL_NR,\
> > > > > + char[sizeof(struct pi433_rx_cfg)])
> > > >
> > > >
> > > > These don't help readability. The original was better.
> > >
> > > The original wasn't any good either.
> > >
> > > It'd be better to avoid the macros altogether
> > > as almost all are use-once.
> > >
> > >
> > So should I keep this as it is or remove the macros ?
> > Because as Dan said the corrections that I made aren't goo either.
> >
>
> Find a way to correct it which makes the code more readable than it was
> before.
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

[Stefan Hajnoczi]

On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > Sent: Thursday, August 17, 2017 07:56
> > To: Dexuan Cui 
> > On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote:
> > > +static u32 hvs_get_local_cid(void)
> > > +{
> > > + return VMADDR_CID_ANY;
> > > +}
> > 
> > Interesting concept: the guest never knows its CID.  This is nice from a
> > live migration perspective.  Currently VMCI and virtio adjust listen
> > socket local CIDs after migration.
> > 
> > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > +{
> > > + static const u32 valid_cids[] = {
> > > + VMADDR_CID_ANY,
> > 
> > Is this for loopback?
> 
> No, we don't support lookback in Linux VM, at least for now.
> In our Linux implementation, Linux VM can only connect to the host, and
> here when Linux VM calls connect(), I treat  VMADDR_CID_ANY 
> the same as VMADDR_CID_HOST.

VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
connect(VMADDR_CID_HOST).  It is an error to connect to VMADDR_CID_ANY.

> > > + VMADDR_CID_HOST,
> > > + };
> > > + int i;
> > > +
> > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x)
> > is
> > > +  * reserved as ephemeral ports, which are used as the host's ports
> > > +  * when the host initiates connections.
> > > +  */
> > > + if (port > MAX_HOST_LISTEN_PORT)
> > > + return false;
> > 
> > Without this if statement the guest will attempt to connect.  I guess
> > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > connection attempt will fail.
> 
> You're correct.
> To use the vsock common infrastructure, we have to map Hyper-V's
> GUID  to int , and hence we must limit
> the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> we can only use half of the whole 32-bit port space for listen().
> This is detailed in the long comments starting at about Line 100.
>  
> > ...but hardcode this knowledge into the guest driver?
> I'd like the guest's connect() to fail immediately here.
> IMO this is better than a connect timeout. :-)

Thanks for explaining.  Perhaps the comment could be updated:

 /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
  * reserved as ephemeral ports, which are used as the host's ports when
  * the host initiates connections.
  *
  * Perform this check in the guest so an immediate error is produced
  * instead of a timeout.
  */

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

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

[Dan Carpenter]

On Tue, Aug 22, 2017 at 02:57:49PM +0530, Rishabh Hardas wrote:
> On Sat, Aug 19, 2017 at 09:47:28PM -0700, Joe Perches wrote:
> > On Wed, 2017-08-16 at 10:31 +0300, Dan Carpenter wrote:
> > > On Wed, Aug 16, 2017 at 10:53:18AM +0530, Rishabh Hardas wrote:
> > > > @@ -143,10 +142,13 @@ struct pi433_rx_cfg {
> > > > 
> > > >  #define PI433_IOC_MAGIC'r'
> > > > 
> > > > -#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC, 
> > > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > > -#define PI433_IOC_WR_TX_CFG_IOW(PI433_IOC_MAGIC, 
> > > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > > -
> > > > -#define PI433_IOC_RD_RX_CFG_IOR(PI433_IOC_MAGIC, 
> > > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > > -#define PI433_IOC_WR_RX_CFG_IOW(PI433_IOC_MAGIC, 
> > > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > > +#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC, 
> > > > PI433_TX_CFG_IOCTL_NR,\
> > > > +char[sizeof(struct pi433_tx_cfg)])
> > > > +#define PI433_IOC_WR_TX_CFG_IOW(PI433_IOC_MAGIC, 
> > > > PI433_TX_CFG_IOCTL_NR,\
> > > > +char[sizeof(struct pi433_tx_cfg)])
> > > > +#define PI433_IOC_RD_RX_CFG_IOR(PI433_IOC_MAGIC, 
> > > > PI433_RX_CFG_IOCTL_NR,\
> > > > +char[sizeof(struct pi433_rx_cfg)])
> > > > +#define PI433_IOC_WR_RX_CFG_IOW(PI433_IOC_MAGIC, 
> > > > PI433_RX_CFG_IOCTL_NR,\
> > > > +char[sizeof(struct pi433_rx_cfg)])
> > > 
> > > 
> > > These don't help readability.  The original was better.
> > 
> > The original wasn't any good either.
> > 
> > It'd be better to avoid the macros altogether
> > as almost all are use-once.
> > 
> > 
> So should I keep this as it is or remove the macros ?
> Because as Dan said the corrections that I made aren't goo either.
> 

Find a way to correct it which makes the code more readable than it was
before.

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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

[Stefan Hajnoczi]

On Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > CID is not really used by us, because we only support guest<->host
> > communication,
> > > and don't support guest<->guest communication. The Hyper-V host
> > references
> > > every VM by VmID (which is invisible to the VM), and a VM can only talk to
> > the
> > > host via this feature.
> > 
> > Applications running inside the guest should use VMADDR_CID_HOST (2) to
> > connect to the host, even on Hyper-V.
> I have no objection, and this patch does support this usage of the
> user-space applications.
>
> > By the way, we should collaborate on a test suite and a vsock(7) man
> > page that documents the semantics of AF_VSOCK sockets.  This way our
> > transports will have the same behavior and AF_VSOCK applications will
> > work on all 3 hypervisors.
> I can't agree more. :-)
> BTW, I have been using Rolf's test suite to test my patch:
> https://github.com/rn/virtsock/tree/master/c
> Maybe this can be a good starting point.

Thanks for sharing this, I will try it with virtio-vsock.

I have a netcat-like utility here:
https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c

> > Not all features need to be supported.  For example, VMCI supports
> > SOCK_DGRAM while Hyper-V and virtio do not.  But features that are
> > available should behave identically.
> I totally agree, though I'm afraid Hyper-V may have a little more limitations
> compared to VMware/KVM duo to the  <--> 
> mapping.
>  
> > > Can we use the 'protocol' parameter in the socket() function:
> > > int socket(int domain, int type, int protocol)
> > >
> > > IMO currently the 'protocol' is not really used.
> > > I think we can modify __vsock_core_init() to allow multiple transport 
> > > layers
> > to
> > >  be registered, and we can define different 'protocol' numbers for
> > > VMware/KVM/Hyper-V, and ask the application to explicitly specify what
> > should
> > > be used. Considering compatibility, we can use the default transport in a
> > given
> > > VM depending on the underlying hypervisor.
> > 
> > I think AF_VSOCK should hide the transport from users/applications.
> Ideally yes, but let's consider the KVM-on-KVM nested scenario: when
> an application in the Level-1 VM creates an AF_VSOCK socket and call
> connect() for it, how can we know if the app is trying to connect to
> the Level-0 host, or connect to the Level-2 VM? We can't.

We *can* by looking at the destination CID.  Please take a look at
drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI handles
nested virt.

It boils down to something like this:

  static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
  int addr_len, int flags)
  {
  ...
  if (remote_addr.svm_cid == VMADDR_CID_HOST)
  transport = host_transport;
  else
  transport = guest_transport;

It's easy for connect(2) but Jorgen mentioned it's harder for listen(2)
because the socket would need to listen on both transports.  We define
two new constants VMADDR_CID_LISTEN_FROM_GUEST and
VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can decide
which side to listen on.  Or the listen socket could simply listen to
both sides.

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

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

[Rishabh Hardas]

On Sat, Aug 19, 2017 at 09:47:28PM -0700, Joe Perches wrote:
> On Wed, 2017-08-16 at 10:31 +0300, Dan Carpenter wrote:
> > On Wed, Aug 16, 2017 at 10:53:18AM +0530, Rishabh Hardas wrote:
> > > @@ -143,10 +142,13 @@ struct pi433_rx_cfg {
> > > 
> > >  #define PI433_IOC_MAGIC  'r'
> > > 
> > > -#define PI433_IOC_RD_TX_CFG  _IOR(PI433_IOC_MAGIC, 
> > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > -#define PI433_IOC_WR_TX_CFG  _IOW(PI433_IOC_MAGIC, 
> > > PI433_TX_CFG_IOCTL_NR, char[sizeof(struct pi433_tx_cfg)])
> > > -
> > > -#define PI433_IOC_RD_RX_CFG  _IOR(PI433_IOC_MAGIC, 
> > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > -#define PI433_IOC_WR_RX_CFG  _IOW(PI433_IOC_MAGIC, 
> > > PI433_RX_CFG_IOCTL_NR, char[sizeof(struct pi433_rx_cfg)])
> > > +#define PI433_IOC_RD_TX_CFG  _IOR(PI433_IOC_MAGIC, 
> > > PI433_TX_CFG_IOCTL_NR,\
> > > +  char[sizeof(struct pi433_tx_cfg)])
> > > +#define PI433_IOC_WR_TX_CFG  _IOW(PI433_IOC_MAGIC, 
> > > PI433_TX_CFG_IOCTL_NR,\
> > > +  char[sizeof(struct pi433_tx_cfg)])
> > > +#define PI433_IOC_RD_RX_CFG  _IOR(PI433_IOC_MAGIC, 
> > > PI433_RX_CFG_IOCTL_NR,\
> > > +  char[sizeof(struct pi433_rx_cfg)])
> > > +#define PI433_IOC_WR_RX_CFG  _IOW(PI433_IOC_MAGIC, 
> > > PI433_RX_CFG_IOCTL_NR,\
> > > +  char[sizeof(struct pi433_rx_cfg)])
> > 
> > 
> > These don't help readability.  The original was better.
> 
> The original wasn't any good either.
> 
> It'd be better to avoid the macros altogether
> as almost all are use-once.
> 
> 
So should I keep this as it is or remove the macros ?
Because as Dan said the corrections that I made aren't goo either.

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

Re: [PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

[Christoph Hellwig]

Wouldn't it make sense to backport the changes to set the virt_boundary
(which probably still is the SG_GAPS flag in such an old kernel)?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel