Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-14 Thread Marcel Holtmann 
Hi Michael,

> That's the default now, no need for makefiles to set it.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
> drivers/bluetooth/Makefile| 2 --
> drivers/net/can/Makefile  | 1 -
> drivers/net/ethernet/altera/Makefile  | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile   | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
> drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
> drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
> drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
> drivers/net/wireless/ti/wl1251/Makefile   | 2 --
> drivers/net/wireless/ti/wlcore/Makefile   | 2 --
> drivers/staging/rtl8188eu/Makefile| 2 +-
> drivers/staging/rtl8192e/Makefile | 2 --
> drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
> net/bluetooth/Makefile| 2 --
> net/ieee802154/Makefile   | 2 --
> net/mac80211/Makefile | 2 +-
> net/mac802154/Makefile| 2 --
> net/wireless/Makefile | 2 --
> 38 files changed, 5 insertions(+), 68 deletions(-)

for drivers/bluetooth, net/bluetooth, net/ieee802154 and net/mac802154

Acked-by: Marcel Holtmann 

Regards

Marcel

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

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-14 Thread Kalle Valo 
"Michael S. Tsirkin"  writes:

> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/bluetooth/Makefile| 2 --
>  drivers/net/can/Makefile  | 1 -
>  drivers/net/ethernet/altera/Makefile  | 1 -
>  drivers/net/ethernet/atheros/alx/Makefile | 1 -
>  drivers/net/ethernet/freescale/Makefile   | 2 --
>  drivers/net/wireless/ath/Makefile | 2 --
>  drivers/net/wireless/ath/wil6210/Makefile | 2 --
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
>  drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
>  drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
>  drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
>  drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
>  drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
>  drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
>  drivers/net/wireless/ti/wl1251/Makefile   | 2 --
>  drivers/net/wireless/ti/wlcore/Makefile   | 2 --
>  drivers/staging/rtl8188eu/Makefile| 2 +-
>  drivers/staging/rtl8192e/Makefile | 2 --
>  drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
>  net/bluetooth/Makefile| 2 --
>  net/ieee802154/Makefile   | 2 --
>  net/mac80211/Makefile | 2 +-
>  net/mac802154/Makefile| 2 --
>  net/wireless/Makefile | 2 --
>  38 files changed, 5 insertions(+), 68 deletions(-)

For drivers/net/wireless:

Acked-by: Kalle Valo 

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

[PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-14 Thread Michael S. Tsirkin 
That's the default now, no need for makefiles to set it.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/bluetooth/Makefile| 2 --
 drivers/net/can/Makefile  | 1 -
 drivers/net/ethernet/altera/Makefile  | 1 -
 drivers/net/ethernet/atheros/alx/Makefile | 1 -
 drivers/net/ethernet/freescale/Makefile   | 2 --
 drivers/net/wireless/ath/Makefile | 2 --
 drivers/net/wireless/ath/wil6210/Makefile | 2 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
 drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
 drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
 drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
 drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
 drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
 drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
 drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
 drivers/net/wireless/ti/wl1251/Makefile   | 2 --
 drivers/net/wireless/ti/wlcore/Makefile   | 2 --
 drivers/staging/rtl8188eu/Makefile| 2 +-
 drivers/staging/rtl8192e/Makefile | 2 --
 drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
 net/bluetooth/Makefile| 2 --
 net/ieee802154/Makefile   | 2 --
 net/mac80211/Makefile | 2 +-
 net/mac802154/Makefile| 2 --
 net/wireless/Makefile | 2 --
 38 files changed, 5 insertions(+), 68 deletions(-)

diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index b1fc29a..8062718 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -40,5 +40,3 @@ hci_uart-$(CONFIG_BT_HCIUART_QCA) += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
 hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
-
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 26ba4b7..7a85495 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -31,5 +31,4 @@ obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
 obj-$(CONFIG_CAN_XILINXCAN)+= xilinx_can.o
 obj-$(CONFIG_PCH_CAN)  += pch_can.o
 
-subdir-ccflags-y += -D__CHECK_ENDIAN__
 subdir-ccflags-$(CONFIG_CAN_DEBUG_DEVICES) += -DDEBUG
diff --git a/drivers/net/ethernet/altera/Makefile 
b/drivers/net/ethernet/altera/Makefile
index 3eff2fd..d4a187e 100644
--- a/drivers/net/ethernet/altera/Makefile
+++ b/drivers/net/ethernet/altera/Makefile
@@ -5,4 +5,3 @@
 obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
 altera_tse-objs := altera_tse_main.o altera_tse_ethtool.o \
 altera_msgdma.o altera_sgdma.o altera_utils.o
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/ethernet/atheros/alx/Makefile 
b/drivers/net/ethernet/atheros/alx/Makefile
index 5901fa4..ed4a605 100644
--- a/drivers/net/ethernet/atheros/alx/Makefile
+++ b/drivers/net/ethernet/atheros/alx/Makefile
@@ -1,3 +1,2 @@
 obj-$(CONFIG_ALX) += alx.o
 alx-objs := main.o ethtool.o hw.o
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/ethernet/freescale/Makefile 
b/drivers/net/ethernet/freescale/Makefile
index 4a13115..c46df5c 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -4,8 +4,6 @@
 
 obj-$(CONFIG_FEC) += fec.o
 fec-objs :=fec_main.o fec_ptp.o
-CFLAGS_fec_main.o := -D__CHECK_ENDIAN__
-CFLAGS_fec_ptp.o := -D__CHECK_ENDIAN__
 
 obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
 ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
diff --git a/drivers/net/wireless/ath/Makefile 
b/drivers/net/wireless/ath/Makefile
index 89f8d59..4cdebc7 100644
--- a/drivers/net/wireless/ath/Makefile
+++ b/drivers/net/wireless/ath/Makefile
@@ -19,6 +19,4 @@ ath-objs :=   main.o \
 ath-$(CONFIG_ATH_DEBUG) += debug.o

Re: [PATCH] staging : osc : Remove braces from single-line body

2016-12-14 Thread Greg KH 
On Thu, Dec 15, 2016 at 07:03:52AM +0530, Tabrez khan wrote:
> Remove unnecessary braces {} for single if statement block.
> This warning is found using checkpatch.pl.
> 
> Signed-off-by: Tabrez khan 
> ---
>  drivers/staging/lustre/lustre/osc/osc_cache.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
> b/drivers/staging/lustre/lustre/osc/osc_cache.c
> index 4bbe219..5ded31a 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_cache.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
> @@ -1420,10 +1420,8 @@ static void osc_release_write_grant(struct client_obd 
> *cli,
>   struct brw_page *pga)
>  {
>   assert_spin_locked(>cl_loi_list_lock);
> - if (!(pga->flag & OBD_BRW_FROM_GRANT)) {
> + if (!(pga->flag & OBD_BRW_FROM_GRANT))
>   return;
> - }
> -

Why did you also delete the blank line?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging : osc : Remove braces from single-line body

2016-12-14 Thread Tabrez khan 
Remove unnecessary braces {} for single if statement block.
This warning is found using checkpatch.pl.

Signed-off-by: Tabrez khan 
---
 drivers/staging/lustre/lustre/osc/osc_cache.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 4bbe219..5ded31a 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -1420,10 +1420,8 @@ static void osc_release_write_grant(struct client_obd 
*cli,
struct brw_page *pga)
 {
assert_spin_locked(>cl_loi_list_lock);
-   if (!(pga->flag & OBD_BRW_FROM_GRANT)) {
+   if (!(pga->flag & OBD_BRW_FROM_GRANT))
return;
-   }
-
pga->flag &= ~OBD_BRW_FROM_GRANT;
atomic_long_dec(_dirty_pages);
cli->cl_dirty_pages--;
-- 
2.7.4

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

[PATCH] staging: octeon: Call SET_NETDEV_DEV()

2016-12-14 Thread Florian Fainelli 
The Octeon driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.

Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a 
different owner")
Reported-by: Aaro Koskinen 
Signed-off-by: Florian Fainelli 
---
 drivers/staging/octeon/ethernet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/octeon/ethernet.c 
b/drivers/staging/octeon/ethernet.c
index 8130dfe89745..4971aa54756a 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -770,6 +770,7 @@ static int cvm_oct_probe(struct platform_device *pdev)
/* Initialize the device private structure. */
struct octeon_ethernet *priv = netdev_priv(dev);
 
+   SET_NETDEV_DEV(dev, >dev);
dev->netdev_ops = _oct_pow_netdev_ops;
priv->imode = CVMX_HELPER_INTERFACE_MODE_DISABLED;
priv->port = CVMX_PIP_NUM_INPUT_PORTS;
@@ -816,6 +817,7 @@ static int cvm_oct_probe(struct platform_device *pdev)
}
 
/* Initialize the device private structure. */
+   SET_NETDEV_DEV(dev, >dev);
priv = netdev_priv(dev);
priv->netdev = dev;
priv->of_node = cvm_oct_node_for_port(pip, interface,
-- 
2.9.3

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

[PATCH 5/6] storvsc: properly handle SRB_ERROR when sense message is present

2016-12-14 Thread kys 
From: Long Li 

When sense message is present on error, we should pass along to the upper
layer to decide how to deal with the error.
This patch fixes connectivity issues with Fiber Channel devices.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3209387..3c92dc2 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -925,6 +925,13 @@ static void storvsc_handle_error(struct vmscsi_request 
*vm_srb,
switch (SRB_STATUS(vm_srb->srb_status)) {
case SRB_STATUS_ERROR:
/*
+* Let upper layer deal with error when
+* sense message is present.
+*/
+
+   if (vm_srb->srb_status & SRB_STATUS_AUTOSENSE_VALID)
+   break;
+   /*
 * If there is an error; offline the device since all
 * error recovery strategies would have already been
 * deployed on the host side. However, if the command
-- 
1.7.4.1

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

[PATCH 2/6] storvsc: Remove the restriction on max segment size

2016-12-14 Thread kys 
From: K. Y. Srinivasan 

Remove the artificially imposed restriction on max segment size.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index ccb2101..3b1c2f6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1267,8 +1267,6 @@ static int storvsc_do_io(struct hv_device *device,
 static int storvsc_device_configure(struct scsi_device *sdevice)
 {
 
-   blk_queue_max_segment_size(sdevice->request_queue, PAGE_SIZE);
-
blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY);
 
blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * HZ));
-- 
1.7.4.1

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

[PATCH 1/6] storvsc: Enable tracking of queue depth

2016-12-14 Thread kys 
From: K. Y. Srinivasan 

Enable tracking of queue depth.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 05526b7..ccb2101 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1550,6 +1550,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
/* Make sure we dont get a sg segment crosses a page boundary */
.dma_boundary = PAGE_SIZE-1,
.no_write_same =1,
+   .track_queue_depth =1,
 };
 
 enum {
-- 
1.7.4.1

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

[PATCH 3/6] storvsc: Enable multi-queue support

2016-12-14 Thread kys 
From: K. Y. Srinivasan 

Enable multi-q support. We will allocate the outgoing channel using
the following policy:

1. We will make every effort to pick a channel that is in the
   same NUMA node that is initiating the I/O
2. The mapping between the guest CPU and the outgoing channel
   is persistent.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |  113 ++-
 1 files changed, 110 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3b1c2f6..63f6b1a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -458,6 +458,15 @@ struct storvsc_device {
 * Max I/O, the device can support.
 */
u32   max_transfer_bytes;
+   /*
+* Number of sub-channels we will open.
+*/
+   u16 num_sc;
+   struct vmbus_channel **stor_chns;
+   /*
+* Mask of CPUs bound to subchannels.
+*/
+   struct cpumask alloced_cpus;
/* Used for vsc/vsp channel reset process */
struct storvsc_cmd_request init_request;
struct storvsc_cmd_request reset_request;
@@ -635,6 +644,11 @@ static void handle_sc_creation(struct vmbus_channel 
*new_sc)
   (void *),
   sizeof(struct vmstorage_channel_properties),
   storvsc_on_channel_callback, new_sc);
+
+   if (new_sc->state == CHANNEL_OPENED_STATE) {
+   stor_device->stor_chns[new_sc->target_cpu] = new_sc;
+   cpumask_set_cpu(new_sc->target_cpu, _device->alloced_cpus);
+   }
 }
 
 static void  handle_multichannel_storage(struct hv_device *device, int 
max_chns)
@@ -651,6 +665,7 @@ static void  handle_multichannel_storage(struct hv_device 
*device, int max_chns)
if (!stor_device)
return;
 
+   stor_device->num_sc = num_sc;
request = _device->init_request;
vstor_packet = >vstor_packet;
 
@@ -838,6 +853,25 @@ static int storvsc_channel_init(struct hv_device *device, 
bool is_fc)
 * support multi-channel.
 */
max_chns = vstor_packet->storage_channel_properties.max_channel_cnt;
+
+   /*
+* Allocate state to manage the sub-channels.
+* We allocate an array based on the numbers of possible CPUs
+* (Hyper-V does not support cpu online/offline).
+* This Array will be sparseley populated with unique
+* channels - primary + sub-channels.
+* We will however populate all the slots to evenly distribute
+* the load.
+*/
+   stor_device->stor_chns = kzalloc(sizeof(void *) * num_possible_cpus(),
+GFP_KERNEL);
+   if (stor_device->stor_chns == NULL)
+   return -ENOMEM;
+
+   stor_device->stor_chns[device->channel->target_cpu] = device->channel;
+   cpumask_set_cpu(device->channel->target_cpu,
+   _device->alloced_cpus);
+
if (vmstor_proto_version >= VMSTOR_PROTO_VERSION_WIN8) {
if (vstor_packet->storage_channel_properties.flags &
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
@@ -1198,17 +1232,64 @@ static int storvsc_dev_remove(struct hv_device *device)
/* Close the channel */
vmbus_close(device->channel);
 
+   kfree(stor_device->stor_chns);
kfree(stor_device);
return 0;
 }
 
+static struct vmbus_channel *get_og_chn(struct storvsc_device *stor_device,
+   u16 q_num)
+{
+   u16 slot = 0;
+   u16 hash_qnum;
+   struct cpumask alloced_mask;
+   int num_channels, tgt_cpu;
+
+   if (stor_device->num_sc == 0)
+   return stor_device->device->channel;
+
+   /*
+* Our channel array is sparsley populated and we
+* initiated I/O on a processor/hw-q that does not
+* currently have a designated channel. Fix this.
+* The strategy is simple:
+* I. Ensure NUMA locality
+* II. Distribute evenly (best effort)
+* III. Mapping is persistent.
+*/
+
+   cpumask_and(_mask, _device->alloced_cpus,
+   cpumask_of_node(cpu_to_node(q_num)));
+
+   num_channels = cpumask_weight(_mask);
+   if (num_channels == 0)
+   return stor_device->device->channel;
+
+   hash_qnum = q_num;
+   while (hash_qnum >= num_channels)
+   hash_qnum -= num_channels;
+
+   for_each_cpu(tgt_cpu, _mask) {
+   if (slot == hash_qnum)
+   break;
+   slot++;
+   }
+
+   stor_device->stor_chns[q_num] = stor_device->stor_chns[tgt_cpu];
+
+   return stor_device->stor_chns[q_num];
+}
+
+
 static int storvsc_do_io(struct hv_device *device,
-struct storvsc_cmd_request *request)
+

[PATCH 6/6] storvsc: properly set residual data length on errors

2016-12-14 Thread kys 
From: Long Li 

On I/O errors, the Windows driver doesn't set data_transfer_length
on error conditions other than SRB_STATUS_DATA_OVERRUN.
In these cases we need to set data_transfer_length to 0,
indicating there is no data transferred. On SRB_STATUS_DATA_OVERRUN,
data_transfer_length is set by the Windows driver to the actual data 
transferred.

Reported-by: Shiva Krishna 
Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3c92dc2..888e16e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,7 @@ enum storvsc_request_type {
 #define SRB_STATUS_SUCCESS 0x01
 #define SRB_STATUS_ABORTED 0x02
 #define SRB_STATUS_ERROR   0x04
+#define SRB_STATUS_DATA_OVERRUN0x12
 
 #define SRB_STATUS(status) \
(status & ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
@@ -996,6 +997,7 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
struct scsi_cmnd *scmnd = cmd_request->cmd;
struct scsi_sense_hdr sense_hdr;
struct vmscsi_request *vm_srb;
+   u32 data_transfer_length;
struct Scsi_Host *host;
u32 payload_sz = cmd_request->payload_sz;
void *payload = cmd_request->payload;
@@ -1003,6 +1005,7 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
host = stor_dev->host;
 
vm_srb = _request->vstor_packet.vm_srb;
+   data_transfer_length = vm_srb->data_transfer_length;
 
scmnd->result = vm_srb->scsi_status;
 
@@ -1016,13 +1019,20 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
 _hdr);
}
 
-   if (vm_srb->srb_status != SRB_STATUS_SUCCESS)
+   if (vm_srb->srb_status != SRB_STATUS_SUCCESS) {
storvsc_handle_error(vm_srb, scmnd, host, sense_hdr.asc,
 sense_hdr.ascq);
+   /*
+* The Windows driver set data_transfer_length on
+* SRB_STATUS_DATA_OVERRUN. On other errors, this value
+* is untouched.  In these cases we set it to 0.
+*/
+   if (vm_srb->srb_status != SRB_STATUS_DATA_OVERRUN)
+   data_transfer_length = 0;
+   }
 
scsi_set_resid(scmnd,
-   cmd_request->payload->range.len -
-   vm_srb->data_transfer_length);
+   cmd_request->payload->range.len - data_transfer_length);
 
scmnd->scsi_done(scmnd);
 
-- 
1.7.4.1

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

[PATCH 4/6] storvsc: use tagged SRB requests if supported by the device

2016-12-14 Thread kys 
From: Long Li 

Properly set SRB flags when hosting device supports tagged queuing.
This patch improves the performance on Fiber Channel disks.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/storvsc_drv.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 63f6b1a..3209387 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -136,6 +136,8 @@ struct hv_fc_wwn_packet {
 #define SRB_FLAGS_PORT_DRIVER_RESERVED 0x0F00
 #define SRB_FLAGS_CLASS_DRIVER_RESERVED0xF000
 
+#define SP_UNTAGGED((unsigned char) ~0)
+#define SRB_SIMPLE_TAG_REQUEST 0x20
 
 /*
  * Platform neutral description of a scsi request -
@@ -1549,6 +1551,13 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
vm_srb->win8_extension.srb_flags |=
SRB_FLAGS_DISABLE_SYNCH_TRANSFER;
 
+   if (scmnd->device->tagged_supported) {
+   vm_srb->win8_extension.srb_flags |=
+   (SRB_FLAGS_QUEUE_ACTION_ENABLE | SRB_FLAGS_NO_QUEUE_FREEZE);
+   vm_srb->win8_extension.queue_tag = SP_UNTAGGED;
+   vm_srb->win8_extension.queue_action = SRB_SIMPLE_TAG_REQUEST;
+   }
+
/* Build the SRB */
switch (scmnd->sc_data_direction) {
case DMA_TO_DEVICE:
-- 
1.7.4.1

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

[PATCH 0/6] storvsc: Miscellaneous fixes and enhancements

2016-12-14 Thread kys 
From: K. Y. Srinivasan 

Miscellaneous fixes and enhancements.

K. Y. Srinivasan (3):
  storvsc: Enable tracking of queue depth
  storvsc: Remove the restriction on max segment size
  storvsc: Enable multi-queue support

Long Li (3):
  storvsc: use tagged SRB requests if supported by the device
  storvsc: properly handle SRB_ERROR when sense message is present
  storvsc: properly set residual data length on errors

 drivers/scsi/storvsc_drv.c |  148 +---
 1 files changed, 140 insertions(+), 8 deletions(-)

-- 
1.7.4.1

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

[RFC PATCH 3/4] staging: android: ion: Remove page faulting support

2016-12-14 Thread Laura Abbott 

Unclear if this is wanted or needed?

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 74 ---
 1 file changed, 74 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 76b874a0..86dba07 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
 #include "ion_priv.h"
 #include "compat_ion.h"
 
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
-   return (buffer->flags & ION_FLAG_CACHED) &&
-   !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
 }
 
-static inline struct page *ion_buffer_page(struct page *page)
-{
-   return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
-   return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
 /* this function should only be called while dev->lock is held */
 static void ion_buffer_add(struct ion_device *dev,
   struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   struct scatterlist *sg;
-   int i, j, k = 0;
-
-   buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
-   if (!buffer->pages) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   for_each_sg(table->sgl, sg, table->nents, i) {
-   struct page *page = sg_page(sg);
-
-   for (j = 0; j < sg->length / PAGE_SIZE; j++)
-   buffer->pages[k++] = page++;
-   }
-   }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
@@ -845,25 +800,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
 };
 
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>lock);
-   ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
-   BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
-   pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
-   ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
-   mutex_unlock(>lock);
-   if (ret)
-   return VM_FAULT_ERROR;
-
-   return VM_FAULT_NOPAGE;
-}
-
 static void ion_vm_open(struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = vma->vm_private_data;
@@ -900,7 +836,6 @@ static void ion_vm_close(struct vm_area_struct *vma)
 static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
-   .fault = ion_vm_fault,
 };
 
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
@@ -914,15 +849,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
-   VM_DONTDUMP;
-   vma->vm_private_data = buffer;
-   vma->vm_ops = _vma_ops;
-   ion_vm_open(vma);
-   return 0;
-   }
-
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 
-- 
2.7.4

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

[RFC PATCH 1/4] staging: android: ion: Some cleanup

2016-12-14 Thread Laura Abbott 

- dmap_cnt isn't used. Remove it.
- Ion has been using dma apis incorrectly to sync the caches.
  Remove bad usage in preparation for something better.
- The alignment field doesn't actually change the alignment of an
  allocation, it only serves as an error check. This is basically
  pointless. Remove the field.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  6 --
 drivers/staging/android/ion/ion.c   | 92 ++---
 drivers/staging/android/ion/ion.h   |  5 +-
 drivers/staging/android/ion/ion_carveout_heap.c | 16 +
 drivers/staging/android/ion/ion_chunk_heap.c| 15 +---
 drivers/staging/android/ion/ion_cma_heap.c  |  5 +-
 drivers/staging/android/ion/ion_page_pool.c |  3 -
 drivers/staging/android/ion/ion_priv.h  |  4 +-
 drivers/staging/android/ion/ion_system_heap.c   | 14 +---
 9 files changed, 16 insertions(+), 144 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..a27db9d 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
struct ion_handle *handle;
 
handle = ion_alloc(client, data.allocation.len,
-   data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index d5cc307..8dd0932 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
-   unsigned long align,
unsigned long flags)
 {
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>ref);
 
-   ret = heap->ops->allocate(heap, buffer, len, align, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
 
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
 
ion_heap_freelist_drain(heap, 0);
-   ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct 
ion_handle *handle)
 }
 
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-size_t align, unsigned int heap_id_mask,
+unsigned int heap_id_mask,
 unsigned int flags)
 {
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
struct ion_heap *heap;
int ret;
 
-   pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-len, align, heap_id_mask, flags);
+   pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+len, heap_id_mask, flags);
/*
 * traverse the list of heaps available in this system in priority
 * order.  If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
-   buffer = ion_buffer_create(heap, dev, len, align, flags);
+   buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
@@ -797,17 +795,12 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-

[RFC PATCH 4/4] staging: android: ion: Call dma_map_sg for syncing and mapping

2016-12-14 Thread Laura Abbott 

Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 61 ++-
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 86dba07..5177d79 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -776,6 +776,11 @@ static struct sg_table *dup_sg_table(struct sg_table 
*table)
return new_table;
 }
 
+static void free_duped_table(struct sg_table *table)
+{
+   sg_free_table(table);
+   kfree(table);
+}
 
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
@@ -784,15 +789,29 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
struct sg_table *table;
 
-   return dup_sg_table(buffer->sg_table);
+   /*
+* TODO: Need to sync wrt CPU or device completely owning?
+*/
+
+   table = dup_sg_table(buffer->sg_table);
+
+   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+   direction)){
+   ret = -ENOMEM;
+   goto err;
+   }
+
+err:
+   free_duped_table(table);
+   return ERR_PTR(ret);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
-   sg_free_table(table);
-   kfree(table);
+   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   free_duped_table(table);
 }
 
 struct ion_vma_list {
@@ -889,16 +908,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
 
-   if (!buffer->heap->ops->map_kernel) {
-   pr_err("%s: map kernel is not implemented by this heap.\n",
-  __func__);
-   return -ENODEV;
+   /*
+* TODO: Move this elsewhere because we don't always need a vaddr
+*/
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   vaddr = ion_buffer_kmap_get(buffer);
+   mutex_unlock(>lock);
}
 
-   mutex_lock(>lock);
-   vaddr = ion_buffer_kmap_get(buffer);
-   mutex_unlock(>lock);
-   return PTR_ERR_OR_ZERO(vaddr);
+   /*
+* Close enough right now? Flag to skip sync?
+*/
+   if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+DMA_BIDIRECTIONAL))
+   return -ENOMEM;
+
+   return 0;
 }
 
 static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -906,9 +933,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
 {
struct ion_buffer *buffer = dmabuf->priv;
 
-   mutex_lock(>lock);
-   ion_buffer_kmap_put(buffer);
-   mutex_unlock(>lock);
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   ion_buffer_kmap_put(buffer);
+   mutex_unlock(>lock);
+   }
+
+   dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+   DMA_BIDIRECTIONAL);
 
return 0;
 }
-- 
2.7.4

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

[RFC PATCH 0/4] Ion caching (yet again) proof of concept

2016-12-14 Thread Laura Abbott 

Hi,

I've been (once again) looking at alternate caching models for Ion. Part of
this work is also to make Ion fit better in to the dma_buf model.

Ion is a bit unusual for dma_buf. Most drivers that support dma_buf have two
parts: exporting buffers that a driver allocates and importing buffers
allocated elsewhere for use by the driver. Ion is basically designed to export
only and not import buffers from other drivers (the need for import is also
on my TODO list) Even more unusual, there is no actual 'driver' to map into.
Ion currently does nothing except pass back the same sg_table each time without
calling dma_map.

The description of the .map_dma_buf function in dma_buf_ops

 * @map_dma_buf: returns list of scatter pages allocated, increases usecount
 *   of the buffer. Requires atleast one attach to be called
 *   before. Returned sg list should already be mapped into
 *   _device_ address space. This call may sleep. May also return
 *   -EINTR. Should return -EINVAL if attach hasn't been called yet.


So Ion is definitely not doing this correctly. This ties back into correcting
the caching model. If we call dma_map_sg/dma_unmap_sg with begin_cpu_access,
this should be enough to allow the caches to always be properly synchronized
and means we can drop the various dma_sync calls floating around. This is going
to violate one of the big fat comments in ion_buffer_create

/*
 * this will set up dma addresses for the sglist -- it is not
 * technically correct as per the dma api -- a specific
 * device isn't really taking ownership here.  However, in practice on
 * our systems the only dma_address space is physical addresses.
 * Additionally, we can't afford the overhead of invalidating every
 * allocation via dma_map_sg. The implicit contract here is that
 * memory coming from the heaps is ready for dma, ie if it has a
 * cached mapping that mapping has been invalidated
 */
for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
sg_dma_address(sg) = sg_phys(sg);
sg_dma_len(sg) = sg->length;
}


The overhead of invalidating is a valid concern. I'm hoping that the
architecture has either evolved such that this won't be a problem or we can
figure out some clever use of DMA_ATTR_SKIP_CPU_SYNC.

As part of this, I'm considering dropping the fault synchronization. If we have
explicit use begin_cpu_access and use of the dma_buf sync ioctls, I don't think
it should be necessary.

I have a 'pre-RFC' tree at 
https://pagure.io/kernel-ion/branch/ion_cache_proof_dec14
Yes, the patches are not bisectable and there is more to be done. These have
been compile tested only and haven't been hooked up to anything to actually run
(another actually big TODO). I'm mostly looking for feedback if this looks like
the right direction and if there are going to be major problems with this
approach. I don't actually anticipate this getting merged into
drivers/staging/android/ion but this is the easiest way to continue discussion.

Thanks,
Laura

Laura Abbott (4):
  staging: android: ion: Some cleanup
  staging: android: ion: Duplicate sg_table
  staging: android: ion: Remove page faulting support
  staging: android: ion: Call dma_map_sg for syncing and mapping

 drivers/staging/android/ion/ion-ioctl.c |   6 -
 drivers/staging/android/ion/ion.c   | 251 
 drivers/staging/android/ion/ion.h   |   5 +-
 drivers/staging/android/ion/ion_carveout_heap.c |  16 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  15 +-
 drivers/staging/android/ion/ion_cma_heap.c  |   5 +-
 drivers/staging/android/ion/ion_page_pool.c |   3 -
 drivers/staging/android/ion/ion_priv.h  |   4 +-
 drivers/staging/android/ion/ion_system_heap.c   |  14 +-
 9 files changed, 90 insertions(+), 229 deletions(-)

-- 
2.7.4

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

[RFC PATCH 2/4] staging: android: ion: Duplicate sg_table

2016-12-14 Thread Laura Abbott 

Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8dd0932..76b874a0 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,19 +795,49 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+   struct sg_table *new_table;
+   int ret, i;
+   struct scatterlisg *sg, *new_sg;
+
+   new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+   if (!new_table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+   if (ret) {
+   kfree(table);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   new_sg = new_table->sgl;
+   for_each_sg(table->sgl, sg, table->nents, i) {
+   memcpy(new_sg, sg, sizeof(*sg));
+   sg->dma_address = 0;
+   new_sg = sg_next(new_sg);
+   }
+
+   return new_table;
+}
+
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+   struct sg_table *table;
 
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
+   sg_free_table(table);
+   kfree(table);
 }
 
 struct ion_vma_list {
-- 
2.7.4

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

Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

2016-12-14 Thread Stephen Hemminger 
On Wed, 14 Dec 2016 15:27:58 -0800
Greg KH  wrote:

> On Wed, Dec 14, 2016 at 11:18:59PM +, Haiyang Zhang wrote:
> > 
> >   
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Saturday, December 10, 2016 7:21 AM
> > > To: Stephen Hemminger 
> > > Cc: Haiyang Zhang ; o...@aepfle.de;
> > > jasow...@redhat.com; linux-ker...@vger.kernel.org;
> > > bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org;
> > > leann.ogasaw...@canonical.com
> > > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > > serial numbers
> > > 
> > > On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote:  
> > > > On Fri, 9 Dec 2016 22:35:05 +
> > > > Haiyang Zhang  wrote:
> > > >  
> > > > > > > >
> > > > > > > > Emulated NIC is already excluded in start of netvc notifier  
> > > handler.  
> > > > > > > >
> > > > > > > > static int netvsc_netdev_event(struct notifier_block *this,
> > > > > > > >unsigned long event, void *ptr)
> > > > > > > > {
> > > > > > > > struct net_device *event_dev =  
> > > netdev_notifier_info_to_dev(ptr);  
> > > > > > > >
> > > > > > > > /* Skip our own events */
> > > > > > > > if (event_dev->netdev_ops == _ops)
> > > > > > > > return NOTIFY_DONE;
> > > > > > > >  
> > > > > > >
> > > > > > > Emulated device is not based on netvsc. It's the native Linux  
> > > > > > (dec100M?)  
> > > > > > > Driver. So this line doesn't exclude it. And how about other NIC  
> > > type  
> > > > > > > may be added in the future?  
> > > > > >
> > > > > > Sorry, forgot about that haven't used emulated device in years.
> > > > > > The emulated device should appear to be on a PCI bus, but the  
> > > serial  
> > > > > > would not match??  
> > > > >
> > > > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a  
> > > subset  
> > > > > of vmbus devices. So emulated NIC won't have hv_pci serial number.
> > > > >
> > > > > In my patch, the following code ensure, we only try to get serial  
> > > number  
> > > > > after confirming it's vmbus and hv_pci device:
> > > > >
> > > > > +   if (!dev_is_vmbus(dev))
> > > > > +   continue;
> > > > > +
> > > > > +   hdev = device_to_hv_device(dev);
> > > > > +   if (hdev->device_id != HV_PCIE)
> > > > > +   continue;  
> > > >
> > > > Ok, the walk back up the device tree is logically ok, but I don't
> > > > know enough about PCI device tree to be assured that it is safe.
> > > > Also, you could short circuit away most of the unwanted devices
> > > > by making sure the vf_netdev->dev.parent is a PCI device.  
> > > 
> > > Ugh, this seems really really messy.  Can't we just have the
> > > netdev_event interface pass back a pointer to something that we "know"
> > > what it is?  This walking the device tree is a mess, and not good.
> > > 
> > > I'd even argue that dev_is_pci() needs to be removed from the tree too,
> > > as it shouldn't be needed either.  We did a lot of work on the driver
> > > model to prevent the need for having to declare the "type" of 'struct
> > > device' at all, and by doing this type of thing it goes against the
> > > basic design of the model.
> > > 
> > > Yes, it makes things a bit "tougher" in places, but you don't do crazy
> > > things like walk device trees to try to find random devices and then
> > > think it's safe to actually use them :(
> > >   
> > 
> > We register a notifier_block with:
> > register_netdevice_notifier(struct notifier_block *nb)
> > 
> > The "struct notifier_block" basically contains a callback function:
> > struct notifier_block {
> > notifier_fn_t notifier_call;
> > struct notifier_block __rcu *next;
> > int priority;
> > };
> > 
> > It doesn't specify which device we want, so all net devices can trigger
> > this event. Seems we can't have this notifier return VF device only.  
> 
> Ok, I dug in the kernel and it looks like people check the netdev_ops
> structure to see if it matches up with their function pointers to "know"
> if this is their device or not.  Why not do that here?  Or compare the
> "string" of the driver name?  Or any other such trick that the drivers
> that call register_netdevice_notifier do?
> 
> All of which are more sane than walking the device tree...
> 
> And why am I having to do network driver development, ick ick ick :)
> 
> Come on, 'git grep' is your friend.  Even better yet, use a good tool
> like 'vgrep' which makes git grep work really really well.

Normally, that would work but in this case we have one driver (netvsc)
which is managing another driver which is unaware of Hyper-V or netvsc
drivers existence.  The callback is happening in netvsc driver and it
needs to say "hey I know that SR-IOV device, it is

Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

2016-12-14 Thread Greg KH 
On Wed, Dec 14, 2016 at 11:18:59PM +, Haiyang Zhang wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, December 10, 2016 7:21 AM
> > To: Stephen Hemminger 
> > Cc: Haiyang Zhang ; o...@aepfle.de;
> > jasow...@redhat.com; linux-ker...@vger.kernel.org;
> > bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org;
> > leann.ogasaw...@canonical.com
> > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > serial numbers
> > 
> > On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote:
> > > On Fri, 9 Dec 2016 22:35:05 +
> > > Haiyang Zhang  wrote:
> > >
> > > > > > >
> > > > > > > Emulated NIC is already excluded in start of netvc notifier
> > handler.
> > > > > > >
> > > > > > > static int netvsc_netdev_event(struct notifier_block *this,
> > > > > > >  unsigned long event, void *ptr)
> > > > > > > {
> > > > > > >   struct net_device *event_dev =
> > netdev_notifier_info_to_dev(ptr);
> > > > > > >
> > > > > > >   /* Skip our own events */
> > > > > > >   if (event_dev->netdev_ops == _ops)
> > > > > > >   return NOTIFY_DONE;
> > > > > > >
> > > > > >
> > > > > > Emulated device is not based on netvsc. It's the native Linux
> > > > > (dec100M?)
> > > > > > Driver. So this line doesn't exclude it. And how about other NIC
> > type
> > > > > > may be added in the future?
> > > > >
> > > > > Sorry, forgot about that haven't used emulated device in years.
> > > > > The emulated device should appear to be on a PCI bus, but the
> > serial
> > > > > would not match??
> > > >
> > > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a
> > subset
> > > > of vmbus devices. So emulated NIC won't have hv_pci serial number.
> > > >
> > > > In my patch, the following code ensure, we only try to get serial
> > number
> > > > after confirming it's vmbus and hv_pci device:
> > > >
> > > > +   if (!dev_is_vmbus(dev))
> > > > +   continue;
> > > > +
> > > > +   hdev = device_to_hv_device(dev);
> > > > +   if (hdev->device_id != HV_PCIE)
> > > > +   continue;
> > >
> > > Ok, the walk back up the device tree is logically ok, but I don't
> > > know enough about PCI device tree to be assured that it is safe.
> > > Also, you could short circuit away most of the unwanted devices
> > > by making sure the vf_netdev->dev.parent is a PCI device.
> > 
> > Ugh, this seems really really messy.  Can't we just have the
> > netdev_event interface pass back a pointer to something that we "know"
> > what it is?  This walking the device tree is a mess, and not good.
> > 
> > I'd even argue that dev_is_pci() needs to be removed from the tree too,
> > as it shouldn't be needed either.  We did a lot of work on the driver
> > model to prevent the need for having to declare the "type" of 'struct
> > device' at all, and by doing this type of thing it goes against the
> > basic design of the model.
> > 
> > Yes, it makes things a bit "tougher" in places, but you don't do crazy
> > things like walk device trees to try to find random devices and then
> > think it's safe to actually use them :(
> > 
> 
> We register a notifier_block with:
>   register_netdevice_notifier(struct notifier_block *nb)
> 
> The "struct notifier_block" basically contains a callback function:
> struct notifier_block {
> notifier_fn_t notifier_call;
> struct notifier_block __rcu *next;
> int priority;
> };
> 
> It doesn't specify which device we want, so all net devices can trigger
> this event. Seems we can't have this notifier return VF device only.

Ok, I dug in the kernel and it looks like people check the netdev_ops
structure to see if it matches up with their function pointers to "know"
if this is their device or not.  Why not do that here?  Or compare the
"string" of the driver name?  Or any other such trick that the drivers
that call register_netdevice_notifier do?

All of which are more sane than walking the device tree...

And why am I having to do network driver development, ick ick ick :)

Come on, 'git grep' is your friend.  Even better yet, use a good tool
like 'vgrep' which makes git grep work really really well.

thanks,

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

RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

2016-12-14 Thread Haiyang Zhang 


> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, December 10, 2016 7:21 AM
> To: Stephen Hemminger 
> Cc: Haiyang Zhang ; o...@aepfle.de;
> jasow...@redhat.com; linux-ker...@vger.kernel.org;
> bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org;
> leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> serial numbers
> 
> On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote:
> > On Fri, 9 Dec 2016 22:35:05 +
> > Haiyang Zhang  wrote:
> >
> > > > > >
> > > > > > Emulated NIC is already excluded in start of netvc notifier
> handler.
> > > > > >
> > > > > > static int netvsc_netdev_event(struct notifier_block *this,
> > > > > >unsigned long event, void *ptr)
> > > > > > {
> > > > > > struct net_device *event_dev =
> netdev_notifier_info_to_dev(ptr);
> > > > > >
> > > > > > /* Skip our own events */
> > > > > > if (event_dev->netdev_ops == _ops)
> > > > > > return NOTIFY_DONE;
> > > > > >
> > > > >
> > > > > Emulated device is not based on netvsc. It's the native Linux
> > > > (dec100M?)
> > > > > Driver. So this line doesn't exclude it. And how about other NIC
> type
> > > > > may be added in the future?
> > > >
> > > > Sorry, forgot about that haven't used emulated device in years.
> > > > The emulated device should appear to be on a PCI bus, but the
> serial
> > > > would not match??
> > >
> > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a
> subset
> > > of vmbus devices. So emulated NIC won't have hv_pci serial number.
> > >
> > > In my patch, the following code ensure, we only try to get serial
> number
> > > after confirming it's vmbus and hv_pci device:
> > >
> > > +   if (!dev_is_vmbus(dev))
> > > +   continue;
> > > +
> > > +   hdev = device_to_hv_device(dev);
> > > +   if (hdev->device_id != HV_PCIE)
> > > +   continue;
> >
> > Ok, the walk back up the device tree is logically ok, but I don't
> > know enough about PCI device tree to be assured that it is safe.
> > Also, you could short circuit away most of the unwanted devices
> > by making sure the vf_netdev->dev.parent is a PCI device.
> 
> Ugh, this seems really really messy.  Can't we just have the
> netdev_event interface pass back a pointer to something that we "know"
> what it is?  This walking the device tree is a mess, and not good.
> 
> I'd even argue that dev_is_pci() needs to be removed from the tree too,
> as it shouldn't be needed either.  We did a lot of work on the driver
> model to prevent the need for having to declare the "type" of 'struct
> device' at all, and by doing this type of thing it goes against the
> basic design of the model.
> 
> Yes, it makes things a bit "tougher" in places, but you don't do crazy
> things like walk device trees to try to find random devices and then
> think it's safe to actually use them :(
> 

We register a notifier_block with:
register_netdevice_notifier(struct notifier_block *nb)

The "struct notifier_block" basically contains a callback function:
struct notifier_block {
notifier_fn_t notifier_call;
struct notifier_block __rcu *next;
int priority;
};

It doesn't specify which device we want, so all net devices can trigger
this event. Seems we can't have this notifier return VF device only.

Thanks,
- Haiyang

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

Re: [PATCH] staging : i4l : Remove blank lines

2016-12-14 Thread Greg KH 
On Thu, Dec 15, 2016 at 02:49:49AM +0530, Tabrez khan wrote:
> Remove unnecessary blank lines.
> This warning was found using checkpatch.pl.
> 
> Signed-off-by: Tabrez khan 
> ---
>  drivers/staging/i4l/act2000/module.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/i4l/act2000/module.c 
> b/drivers/staging/i4l/act2000/module.c
> index fc14de4..b2ebaf0 100644
> --- a/drivers/staging/i4l/act2000/module.c
> +++ b/drivers/staging/i4l/act2000/module.c
> @@ -563,7 +563,6 @@ if_sendbuf(int id, int channel, int ack, struct sk_buff 
> *skb)
>   return -ENODEV;
>  }
>  
> -
>  /*
>   * Allocate a new card-struct, initialize it
>   * link it into cards-list.

Your description, and subject: do not match what the patch did :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging : osc : coding style fix

2016-12-14 Thread Dilger, Andreas 
On Dec 14, 2016, at 14:11, Tabrez khan  wrote:
> 
> Subject: [PATCH] staging : osc : coding style fix

Thanks for sumbitting your patch.

As a general rule, the patch summary line should try to describe
(as best as possible in a single line) what the patch is actually
fixing.  It is true this is a "coding style fix" but there are
many possible style fixes and it is better to be as specific as
space allows.  Something like:

staging/lustre/osc: remove unnecessary braces

or
staging/lustre/osc: remove braces from single-line body

or
staging/lustre/osc: remove braces in osc_release_write_grant()

would be more specific.  This is doubly important if you are
making a large number of similar patches, since it is desirable
to have a (relatively) unique summary line for each patch to
avoid confusion.

> Remove unnecessary braces {} for single if statement block.
> This warning is found using checkpatch.pl.

The commit body is good.

Please resubmit with a new summary line, then you can include:

Reviewed-by: Andreas Dilger 

Cheers, Andreas

> Signed-off-by: Tabrez khan 
> ---
> drivers/staging/lustre/lustre/osc/osc_cache.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
> b/drivers/staging/lustre/lustre/osc/osc_cache.c
> index 4bbe219..5ded31a 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_cache.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
> @@ -1420,10 +1420,8 @@ static void osc_release_write_grant(struct client_obd 
> *cli,
>   struct brw_page *pga)
> {
>   assert_spin_locked(>cl_loi_list_lock);
> - if (!(pga->flag & OBD_BRW_FROM_GRANT)) {
> + if (!(pga->flag & OBD_BRW_FROM_GRANT))
>   return;
> - }
> -
>   pga->flag &= ~OBD_BRW_FROM_GRANT;
>   atomic_long_dec(_dirty_pages);
>   cli->cl_dirty_pages--;
> -- 
> 2.7.4
> 

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

[PATCH] staging : osc : coding style fix

2016-12-14 Thread Tabrez khan 
Remove unnecessary braces {} for single if statement block.
This warning is found using checkpatch.pl.

Signed-off-by: Tabrez khan 
---
 drivers/staging/lustre/lustre/osc/osc_cache.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 4bbe219..5ded31a 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -1420,10 +1420,8 @@ static void osc_release_write_grant(struct client_obd 
*cli,
struct brw_page *pga)
 {
assert_spin_locked(>cl_loi_list_lock);
-   if (!(pga->flag & OBD_BRW_FROM_GRANT)) {
+   if (!(pga->flag & OBD_BRW_FROM_GRANT))
return;
-   }
-
pga->flag &= ~OBD_BRW_FROM_GRANT;
atomic_long_dec(_dirty_pages);
cli->cl_dirty_pages--;
-- 
2.7.4

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

Re: [PATCH] staging : i4l : Remove blank lines

2016-12-14 Thread Greg KH 
On Thu, Dec 15, 2016 at 01:38:18AM +0530, Tabrez Khan wrote:
> From: Tabrez khan 
> 
> Remove blank lines.

That says what you do, but you did not describe _why_ you did it, which
is more important (hint, we can read the change and see what you did...)

thanks,

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

[PATCH] staging : i4l : Remove blank lines

2016-12-14 Thread Tabrez Khan 
From: Tabrez khan 

Remove blank lines.

Signed-off-by: Tabrez khan 
---
 drivers/staging/i4l/act2000/module.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/i4l/act2000/module.c 
b/drivers/staging/i4l/act2000/module.c
index fc14de4..b2ebaf0 100644
--- a/drivers/staging/i4l/act2000/module.c
+++ b/drivers/staging/i4l/act2000/module.c
@@ -563,7 +563,6 @@ if_sendbuf(int id, int channel, int ack, struct sk_buff 
*skb)
return -ENODEV;
 }
 
-
 /*
  * Allocate a new card-struct, initialize it
  * link it into cards-list.
-- 
2.7.4

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

[driver-core:usermode_ro 4/4] fs/nfs/cache_lib.c:67:28: error: assignment of read-only location 'nfs_cache_getent_prog[0]'

2016-12-14 Thread kbuild test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
usermode_ro
head:   00ed986b7a8fbb11b0c154e8dda5ee7c5ea48a43
commit: 00ed986b7a8fbb11b0c154e8dda5ee7c5ea48a43 [4/4] Introduce 
CONFIG_READONLY_USERMODEHELPER
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 00ed986b7a8fbb11b0c154e8dda5ee7c5ea48a43
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/block/drbd/drbd_nl.c: In function 'drbd_khelper':
>> drivers/block/drbd/drbd_nl.c:347:18: warning: initialization discards 
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 char *argv[] = {drbd_usermode_helper, cmd, mb, NULL };
 ^~~~
   drivers/block/drbd/drbd_nl.c: In function 'conn_khelper':
   drivers/block/drbd/drbd_nl.c:399:18: warning: initialization discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 char *argv[] = {drbd_usermode_helper, cmd, resource_name, NULL };
 ^~~~
--
   fs/nfs/cache_lib.c: In function 'nfs_cache_upcall':
>> fs/nfs/cache_lib.c:67:28: error: assignment of read-only location 
>> 'nfs_cache_getent_prog[0]'
  nfs_cache_getent_prog[0] = '\0';
   ^
--
>> lib/kobject_uevent.c:35:6: error: conflicting types for 'uevent_helper'
char uevent_helper[UEVENT_HELPER_PATH_LEN] = CONFIG_UEVENT_HELPER_PATH;
 ^
   In file included from lib/kobject_uevent.c:19:0:
   include/linux/kobject.h:37:13: note: previous declaration of 'uevent_helper' 
was here
extern char uevent_helper[];
^
   lib/kobject_uevent.c: In function 'init_uevent_argv':
>> lib/kobject_uevent.c:143:15: warning: assignment discards 'const' qualifier 
>> from pointer target type [-Wdiscarded-qualifiers]
 env->argv[0] = uevent_helper;
  ^

vim +67 fs/nfs/cache_lib.c

e571cbf1 Trond Myklebust 2009-08-19  61  * Disable the upcall mechanism 
if we're getting an ENOENT or
e571cbf1 Trond Myklebust 2009-08-19  62  * EACCES error. The admin can 
re-enable it on the fly by using
e571cbf1 Trond Myklebust 2009-08-19  63  * sysfs to set the 
'cache_getent' parameter once the problem
e571cbf1 Trond Myklebust 2009-08-19  64  * has been fixed.
e571cbf1 Trond Myklebust 2009-08-19  65  */
e571cbf1 Trond Myklebust 2009-08-19  66 if (ret == -ENOENT || ret == 
-EACCES)
e571cbf1 Trond Myklebust 2009-08-19 @67 
nfs_cache_getent_prog[0] = '\0';
e571cbf1 Trond Myklebust 2009-08-19  68  out:
e571cbf1 Trond Myklebust 2009-08-19  69 return ret > 0 ? 0 : ret;
e571cbf1 Trond Myklebust 2009-08-19  70  }

:: The code at line 67 was first introduced by commit
:: e571cbf1a4f8d8b6cfd4898df718dae84c75a8e1 NFS: Add a dns resolver for use 
with NFSv4 referrals and migration

:: TO: Trond Myklebust 
:: CC: Trond Myklebust 

---
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

[driver-core:usermode_ro 3/4] drivers/staging/rtl8192e/rtl8192e/rtl_dm.c:272:18: warning: initialization discards 'const' qualifier from pointer target type

2016-12-14 Thread kbuild test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
usermode_ro
head:   00ed986b7a8fbb11b0c154e8dda5ee7c5ea48a43
commit: d57c93cde22bd5ec716de09bf84ae8576adf5e64 [3/4] Make static usermode 
helper binaries constant
config: i386-randconfig-x011-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout d57c93cde22bd5ec716de09bf84ae8576adf5e64
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/staging/rtl8192e/rtl8192e/rtl_dm.c: In function 
'_rtl92e_dm_check_ac_dc_power':
>> drivers/staging/rtl8192e/rtl8192e/rtl_dm.c:272:18: warning: initialization 
>> discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 char *argv[] = {ac_dc_script, DRV_NAME, NULL};
 ^~~~

vim +/const +272 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c

3f3173c2 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  256  _rtl92e_dm_check_tx_power_tracking(dev);
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  257  
713519c7 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  258  _rtl92e_dm_ctrl_initgain_byrssi(dev);
d4244a03 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  259  _rtl92e_dm_bandwidth_autoswitch(dev);
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  260  
6ff54257 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  261  _rtl92e_dm_check_rx_path_selection(dev);
e63b7561 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  262  _rtl92e_dm_check_fsync(dev);
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  263  
500344fd drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  264  _rtl92e_dm_send_rssi_to_fw(dev);
dab9eef4 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  265  _rtl92e_dm_cts_to_self(dev);
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  266  }
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  267  
babb55f9 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-09-20  268  static void _rtl92e_dm_check_ac_dc_power(struct net_device 
*dev)
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  269  {
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  270  struct r8192_priv *priv = rtllib_priv(dev);
d57c93cd drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Greg Kroah-Hartman 
2016-12-11  271  static const char *ac_dc_script = 
"/etc/acpi/wireless-rtl-ac-dc-power.sh";
35e33b04 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Mateusz Kulikowski 
2015-05-31 @272  char *argv[] = {ac_dc_script, DRV_NAME, NULL};
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  273  static char *envp[] = {"HOME=/",
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  274  "TERM=linux",
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  275  "PATH=/usr/bin:/bin",
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  276   NULL};
94a79942 drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-23  277  
b448b0cc drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-25  278  if (priv->ResetProgress == RESET_TYPE_SILENT) {
b448b0cc drivers/staging/rtl8192e/rtl_dm.c  Larry Finger   
2011-08-25  279  RT_TRACE((COMP_INIT | COMP_POWER | COMP_RF),
db2c8da0 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c Masanari Iida  
2012-08-10  280   "GPIOChangeRFWorkItemCallBack(): 
Silent Reset!!!\n");

:: The code at line 272 was first introduced by commit
:: 35e33b0468ab3b3f5b610bfa4fc9367a3b7c09a8 staging: rtl8192e: Fix 
LONG_LINE warnings

:: TO: Mateusz Kulikowski 
:: CC: Greg Kroah-Hartman 

---
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

[driver-core:usermode_ro 3/4] drivers/net/hamradio/baycom_epp.c:311:26: warning: initialization discards 'const' qualifier from pointer target type

2016-12-14 Thread kbuild test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
usermode_ro
head:   00ed986b7a8fbb11b0c154e8dda5ee7c5ea48a43
commit: d57c93cde22bd5ec716de09bf84ae8576adf5e64 [3/4] Make static usermode 
helper binaries constant
config: i386-randconfig-s1-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout d57c93cde22bd5ec716de09bf84ae8576adf5e64
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/net/hamradio/baycom_epp.c: In function 'eppconfig':
>> drivers/net/hamradio/baycom_epp.c:311:26: warning: initialization discards 
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
char *argv[] = { eppconfig_path, "-s", "-p", portarg, "-m", modearg,
 ^~

vim +/const +311 drivers/net/hamradio/baycom_epp.c

^1da177e Linus Torvalds 2005-04-16  295  }
^1da177e Linus Torvalds 2005-04-16  296  
^1da177e Linus Torvalds 2005-04-16  297  /* 
-- */
^1da177e Linus Torvalds 2005-04-16  298  /*
^1da177e Linus Torvalds 2005-04-16  299   *eppconfig_path should be 
setable  via /proc/sys.
^1da177e Linus Torvalds 2005-04-16  300   */
^1da177e Linus Torvalds 2005-04-16  301  
d57c93cd Greg Kroah-Hartman 2016-12-11  302  static const char 
eppconfig_path[256] = "/usr/sbin/eppfpga";
^1da177e Linus Torvalds 2005-04-16  303  
^1da177e Linus Torvalds 2005-04-16  304  static char *envp[] = { "HOME=/", 
"TERM=linux", "PATH=/usr/bin:/bin", NULL };
^1da177e Linus Torvalds 2005-04-16  305  
^1da177e Linus Torvalds 2005-04-16  306  /* eppconfig: called during 
ifconfig up to configure the modem */
^1da177e Linus Torvalds 2005-04-16  307  static int eppconfig(struct 
baycom_state *bc)
^1da177e Linus Torvalds 2005-04-16  308  {
^1da177e Linus Torvalds 2005-04-16  309 char modearg[256];
^1da177e Linus Torvalds 2005-04-16  310 char portarg[16];
^1da177e Linus Torvalds 2005-04-16 @311  char *argv[] = { 
eppconfig_path, "-s", "-p", portarg, "-m", modearg,
^1da177e Linus Torvalds 2005-04-16  312  NULL };
^1da177e Linus Torvalds 2005-04-16  313  
^1da177e Linus Torvalds 2005-04-16  314 /* set up arguments */
^1da177e Linus Torvalds 2005-04-16  315 sprintf(modearg, 
"%sclk,%smodem,fclk=%d,bps=%d,divider=%d%s,extstat",
^1da177e Linus Torvalds 2005-04-16  316 bc->cfg.intclk ? "int" 
: "ext",
^1da177e Linus Torvalds 2005-04-16  317 bc->cfg.extmodem ? 
"ext" : "int", bc->cfg.fclk, bc->cfg.bps,
^1da177e Linus Torvalds 2005-04-16  318 (bc->cfg.fclk + 8 * 
bc->cfg.bps) / (16 * bc->cfg.bps),
^1da177e Linus Torvalds 2005-04-16  319 bc->cfg.loopback ? 
",loopback" : "");

:: The code at line 311 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
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

RE: [PATCH] drivers: staging: comedi: fix function prototypes

2016-12-14 Thread Hartley Sweeten 
On December 14, 2016 6:42 AM, Piotr Gregor wrote:
> Add names of parameters to function prototypes in comedi PCI.
> Checkpatch reports now no errors.
>
> Signed-off-by: Piotr Gregor 
> ---
>  drivers/staging/comedi/comedi_pci.h | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/comedi/comedi_pci.h 
> b/drivers/staging/comedi/comedi_pci.h
> index 4005cc9..7dfd892 100644
> --- a/drivers/staging/comedi/comedi_pci.h
> +++ b/drivers/staging/comedi/comedi_pci.h
> @@ -34,18 +34,20 @@
>  #define PCI_VENDOR_ID_RTD0x1435
>  #define PCI_VENDOR_ID_HUMUSOFT   0x186c
>  
> -struct pci_dev *comedi_to_pci_dev(struct comedi_device *);
> +struct pci_dev *comedi_to_pci_dev(struct comedi_device *dev);
 
For the function prototypes I prefer no names for the "pointer" parameters.

The "struct foo *" declaration is just as clear as "struct foo *bar".

Thanks,
Hartley

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

[PATCH] drivers: staging: comedi: fix function prototypes

2016-12-14 Thread Piotr Gregor 
Add names of parameters to function prototypes in comedi PCI.
Checkpatch reports now no errors.

Signed-off-by: Piotr Gregor 
---
 drivers/staging/comedi/comedi_pci.h | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/comedi_pci.h 
b/drivers/staging/comedi/comedi_pci.h
index 4005cc9..7dfd892 100644
--- a/drivers/staging/comedi/comedi_pci.h
+++ b/drivers/staging/comedi/comedi_pci.h
@@ -34,18 +34,20 @@
 #define PCI_VENDOR_ID_RTD  0x1435
 #define PCI_VENDOR_ID_HUMUSOFT 0x186c
 
-struct pci_dev *comedi_to_pci_dev(struct comedi_device *);
+struct pci_dev *comedi_to_pci_dev(struct comedi_device *dev);
 
-int comedi_pci_enable(struct comedi_device *);
-void comedi_pci_disable(struct comedi_device *);
-void comedi_pci_detach(struct comedi_device *);
+int comedi_pci_enable(struct comedi_device *dev);
+void comedi_pci_disable(struct comedi_device *dev);
+void comedi_pci_detach(struct comedi_device *dev);
 
-int comedi_pci_auto_config(struct pci_dev *, struct comedi_driver *,
+int comedi_pci_auto_config(struct pci_dev *pcidev, struct comedi_driver 
*driver,
   unsigned long context);
-void comedi_pci_auto_unconfig(struct pci_dev *);
+void comedi_pci_auto_unconfig(struct pci_dev *pcidev);
 
-int comedi_pci_driver_register(struct comedi_driver *, struct pci_driver *);
-void comedi_pci_driver_unregister(struct comedi_driver *, struct pci_driver *);
+int comedi_pci_driver_register(struct comedi_driver *comedi_driver,
+  struct pci_driver *pci_driver);
+void comedi_pci_driver_unregister(struct comedi_driver *comedi_driver,
+ struct pci_driver *pci_driver);
 
 /**
  * module_comedi_pci_driver() - Helper macro for registering a comedi PCI 
driver
-- 
2.1.4

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