[PATCH 1/3] staging: media: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 .../staging/media/atomisp/pci/atomisp2/atomisp_cmd.c   | 12 ++--
 .../media/atomisp/pci/atomisp2/atomisp_compat_css20.c  |  6 +++---
 .../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c |  6 +++---
 .../staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c  | 18 +-
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c|  2 +-
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc7938f533..63e79a23fe7e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -194,7 +194,7 @@ static int write_target_freq_to_hw(struct atomisp_device 
*isp,
if (isp_sspm1 & ISP_FREQ_VALID_MASK) {
dev_dbg(isp->dev, "clearing ISPSSPM1 valid bit.\n");
intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
-   isp_sspm1 & ~(1 << ISP_FREQ_VALID_OFFSET));
+   isp_sspm1 & ~(BIT(ISP_FREQ_VALID_OFFSET)));
}
 
ratio = (2 * isp->hpll_freq + new_freq / 2) / new_freq - 1;
@@ -207,7 +207,7 @@ static int write_target_freq_to_hw(struct atomisp_device 
*isp,
intel_mid_msgbus_write32(PUNIT_PORT, ISPSSPM1,
   isp_sspm1
   | ratio << ISP_REQ_FREQ_OFFSET
-  | 1 << ISP_FREQ_VALID_OFFSET
+  | BIT(ISP_FREQ_VALID_OFFSET)
   | guar_ratio << ISP_REQ_GUAR_FREQ_OFFSET);
 
isp_sspm1 = intel_mid_msgbus_read32(PUNIT_PORT, ISPSSPM1);
@@ -417,10 +417,10 @@ void atomisp_msi_irq_init(struct atomisp_device *isp, 
struct pci_dev *dev)
u16 msg16;
 
pci_read_config_dword(dev, PCI_MSI_CAPID, );
-   msg32 |= 1 << MSI_ENABLE_BIT;
+   msg32 |= BIT(MSI_ENABLE_BIT);
pci_write_config_dword(dev, PCI_MSI_CAPID, msg32);
 
-   msg32 = (1 << INTR_IER) | (1 << INTR_IIR);
+   msg32 = (BIT(INTR_IER)) | (BIT(INTR_IIR));
pci_write_config_dword(dev, PCI_INTERRUPT_CTRL, msg32);
 
pci_read_config_word(dev, PCI_COMMAND, );
@@ -435,7 +435,7 @@ void atomisp_msi_irq_uninit(struct atomisp_device *isp, 
struct pci_dev *dev)
u16 msg16;
 
pci_read_config_dword(dev, PCI_MSI_CAPID, );
-   msg32 &=  ~(1 << MSI_ENABLE_BIT);
+   msg32 &=  ~(BIT(MSI_ENABLE_BIT));
pci_write_config_dword(dev, PCI_MSI_CAPID, msg32);
 
msg32 = 0x0;
@@ -536,7 +536,7 @@ static void clear_irq_reg(struct atomisp_device *isp)
 {
u32 msg_ret;
pci_read_config_dword(isp->pdev, PCI_INTERRUPT_CTRL, _ret);
-   msg_ret |= 1 << INTR_IIR;
+   msg_ret |= BIT(INTR_IIR);
pci_write_config_dword(isp->pdev, PCI_INTERRUPT_CTRL, msg_ret);
 }
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index 2e20a81091f4..a3acd99a02e9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -2017,11 +2017,11 @@ void atomisp_css_input_set_mode(struct 
atomisp_sub_device *asd,

>stream_env[ATOMISP_INPUT_STREAM_GENERAL].stream_config;
s_config->mode = IA_CSS_INPUT_MODE_TPG;
s_config->source.tpg.mode = IA_CSS_TPG_MODE_CHECKERBOARD;
-   s_config->source.tpg.x_mask = (1 << 4) - 1;
+   s_config->source.tpg.x_mask = (BIT(4)) - 1;
s_config->source.tpg.x_delta = -2;
-   s_config->source.tpg.y_mask = (1 << 4) - 1;
+   s_config->source.tpg.y_mask = (BIT(4)) - 1;
s_config->source.tpg.y_delta = 3;
-   s_config->source.tpg.xy_mask = (1 << 8) - 1;
+   s_config->source.tpg.xy_mask = (BIT(8)) - 1;
return;
}
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
index fcfe8d7190b0..44736a39cda5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
@@ -44,9 +44,9 @@ struct _iunit_debug {
unsigned intdbgopt;
 };
 
-#define OPTION_BIN_LIST(1<<0)
-#define OPTION_BIN_RUN (1<<1)
-#define OPTION_MEM_STAT(1<<2)
+#define OPTION_BIN_LIST(BIT(0))
+#define OPTION_BIN_RUN (BIT(1))
+#define OPTION_MEM_STAT(BIT(2))
 #define OPTION_VALID   

[PATCH 3/3] staging: media: omap4iss: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
 drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_csi2.c 
b/drivers/staging/media/omap4iss/iss_csi2.c
index f71d5f2f179f..f6acc541e8a2 100644
--- a/drivers/staging/media/omap4iss/iss_csi2.c
+++ b/drivers/staging/media/omap4iss/iss_csi2.c
@@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device 
*csi2, const char *subname)
snprintf(name, sizeof(name), "CSI2%s", subname);
snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
 
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, csi2);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c 
b/drivers/staging/media/omap4iss/iss_ipipe.c
index d38782e8e84c..d86ef8a031f2 100644
--- a/drivers/staging/media/omap4iss/iss_ipipe.c
+++ b/drivers/staging/media/omap4iss/iss_ipipe.c
@@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device 
*ipipe)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c 
b/drivers/staging/media/omap4iss/iss_ipipeif.c
index 23de8330731d..cb88b2bd0d82 100644
--- a/drivers/staging/media/omap4iss/iss_ipipeif.c
+++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
@@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct iss_ipipeif_device 
*ipipeif)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipeif);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_resizer.c 
b/drivers/staging/media/omap4iss/iss_resizer.c
index f1d352c711d5..4bbfa20b3c38 100644
--- a/drivers/staging/media/omap4iss/iss_resizer.c
+++ b/drivers/staging/media/omap4iss/iss_resizer.c
@@ -782,7 +782,7 @@ static int resizer_init_entities(struct iss_resizer_device 
*resizer)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, resizer);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
-- 
2.11.0

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


[PATCH 2/3] staging: media: davinci_vpfe: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++---
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 ++---
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434cebd79..7eeb53217168 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1815,7 +1815,7 @@ vpfe_ipipe_init(struct vpfe_ipipe_device *ipipe, struct 
platform_device *pdev)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
index 46fd2c7f69c3..c07f028dd6be 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -1021,7 +1021,7 @@ int vpfe_ipipeif_init(struct vpfe_ipipeif_device *ipipeif,
 
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
 
v4l2_set_subdevdata(sd, ipipeif);
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c 
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 569bcdc9ce2f..0d160c1257d2 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -821,7 +821,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
/* Correct whole line or partial */
if (vdfc->corr_whole_line)
-   val |= 1 << ISIF_VDFC_CORR_WHOLE_LN_SHIFT;
+   val |= BIT(ISIF_VDFC_CORR_WHOLE_LN_SHIFT);
 
/* level shift value */
val |= (vdfc->def_level_shift & ISIF_VDFC_LEVEL_SHFT_MASK) <<
@@ -849,7 +849,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* set DFCMARST and set DFCMWR */
-   val |= 1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT;
+   val |= BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT);
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -880,7 +880,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
}
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* clear DFCMARST and set DFCMWR */
-   val &= ~(1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT);
+   val &= ~(BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT));
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -904,10 +904,10 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
   DM365_ISIF_DFCMWR_MEMORY_WRITE, DFCMEMCTL);
}
/* enable VDFC */
-   isif_merge(isif->isif_cfg.base_addr, (1 << ISIF_VDFC_EN_SHIFT),
-  (1 << ISIF_VDFC_EN_SHIFT), DFCCTL);
+   isif_merge(isif->isif_cfg.base_addr, (BIT(ISIF_VDFC_EN_SHIFT)),
+  (BIT(ISIF_VDFC_EN_SHIFT)), DFCCTL);
 
-   isif_merge(isif->isif_cfg.base_addr, (1 << ISIF_VDFC_EN_SHIFT),
+   isif_merge(isif->isif_cfg.base_addr, (BIT(ISIF_VDFC_EN_SHIFT)),
   (0 << ISIF_VDFC_EN_SHIFT), DFCCTL);
 
isif_write(isif->isif_cfg.base_addr, 0x6, DFCMEMCTL);
@@ -1140,7 +1140,7 @@ static int isif_config_raw(struct v4l2_subdev *sd, int 
mode)
isif_write(isif->isif_cfg.base_addr, val, CGAMMAWD);
/* Configure DPCM compression settings */
if (params->v4l2_pix_fmt == V4L2_PIX_FMT_SGRBG10DPCM8) {
-   val =  1 << ISIF_DPCM_EN_SHIFT;
+   val =  BIT(ISIF_DPCM_EN_SHIFT);
val |= (params->dpcm_predictor &
ISIF_DPCM_PREDICTOR_MASK) << ISIF_DPCM_PREDICTOR_SHIFT;
}
@@ -1893,7 +1893,7 @@ static const struct v4l2_ctrl_config vpfe_isif_crgain = {
.name = "CRGAIN",
.type = V4L2_CTRL_TYPE_INTEGER,
.min = 0,
-   .max = (1 << 12) - 1,
+   .max = (BIT(12)) - 1,
.step = 1,
.def = 0,
 };
@@ -1904,7 +1904,7 @@ static const struct v4l2_ctrl_config vpfe_isif_cgrgain = {
.name = "CGRGAIN",
 

[PATCH 0/3] staging: media: Replace a bit shift.

2017-03-21 Thread Arushi Singhal
Replace a bit shift by a use of BIT in media driver.

Arushi Singhal (3):
  staging: media: Replace a bit shift by a use of BIT.
  staging: media: davinci_vpfe: Replace a bit shift by a use of BIT.
  staging: media: omap4iss: Replace a bit shift by a use of BIT.

 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 12 +-
 .../atomisp/pci/atomisp2/atomisp_compat_css20.c|  6 ++---
 .../media/atomisp/pci/atomisp2/atomisp_drvfs.c |  6 ++---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  | 18 +++
 .../media/atomisp/pci/atomisp2/hmm/hmm_bo.c|  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++---
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 ++---
 drivers/staging/media/omap4iss/iss_csi2.c  |  2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c |  2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  2 +-
 drivers/staging/media/omap4iss/iss_resizer.c   |  2 +-
 13 files changed, 44 insertions(+), 44 deletions(-)

-- 
2.11.0

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


[PATCH] staging: media: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/octeon/ethernet-tx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/octeon/ethernet-tx.c 
b/drivers/staging/octeon/ethernet-tx.c
index ff4119e8de42..f00186ac4e27 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -381,7 +381,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device 
*dev)
(ip_hdr(skb)->version == 4) &&
(ip_hdr(skb)->ihl == 5) &&
((ip_hdr(skb)->frag_off == 0) ||
-(ip_hdr(skb)->frag_off == htons(1 << 14))) &&
+(ip_hdr(skb)->frag_off == htons(BIT(14 &&
((ip_hdr(skb)->protocol == IPPROTO_TCP) ||
 (ip_hdr(skb)->protocol == IPPROTO_UDP))) {
/* Use hardware checksum calc */
@@ -613,7 +613,7 @@ int cvm_oct_xmit_pow(struct sk_buff *skb, struct net_device 
*dev)
 #endif
work->word2.s.is_frag = !((ip_hdr(skb)->frag_off == 0) ||
  (ip_hdr(skb)->frag_off ==
- 1 << 14));
+ BIT(14)));
 #if 0
/* Assume Linux is sending a good packet */
work->word2.s.IP_exc = 0;
-- 
2.11.0

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


staging: iio: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/iio/adc/ad7816.c |  2 +-
 drivers/staging/iio/cdc/ad7150.c |  2 +-
 drivers/staging/iio/cdc/ad7746.c | 22 +++---
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 17d280581e24..42f637ca0251 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -222,7 +222,7 @@ static ssize_t ad7816_show_value(struct device *dev,
value = (s8)((data >> AD7816_TEMP_FLOAT_OFFSET) - 103);
data &= AD7816_TEMP_FLOAT_MASK;
if (value < 0)
-   data = (1 << AD7816_TEMP_FLOAT_OFFSET) - data;
+   data = (BIT(AD7816_TEMP_FLOAT_OFFSET)) - data;
return sprintf(buf, "%d.%.2d\n", value, data * 25);
}
return sprintf(buf, "%u\n", data);
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c
index ca72af3e9d4b..c5574b3ee939 100644
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -232,7 +232,7 @@ static int ad7150_write_event_config(struct iio_dev 
*indio_dev,
if (ret < 0)
goto error_ret;
 
-   cfg = ret & ~((0x03 << 5) | (0x1 << 7));
+   cfg = ret & ~((0x03 << 5) | (BIT(7)));
 
switch (type) {
case IIO_EV_TYPE_MAG_ADAPTIVE:
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 81f8b9ee1120..8c573817826f 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -45,20 +45,20 @@
 #define AD7746_STATUS_RDYCAP   BIT(0)
 
 /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */
-#define AD7746_CAPSETUP_CAPEN  (1 << 7)
-#define AD7746_CAPSETUP_CIN2   (1 << 6) /* AD7746 only */
-#define AD7746_CAPSETUP_CAPDIFF(1 << 5)
-#define AD7746_CAPSETUP_CACHOP (1 << 0)
+#define AD7746_CAPSETUP_CAPEN  (BIT(7))
+#define AD7746_CAPSETUP_CIN2   (BIT(6)) /* AD7746 only */
+#define AD7746_CAPSETUP_CAPDIFF(BIT(5))
+#define AD7746_CAPSETUP_CACHOP (BIT(0))
 
 /* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) */
-#define AD7746_VTSETUP_VTEN(1 << 7)
+#define AD7746_VTSETUP_VTEN(BIT(7))
 #define AD7746_VTSETUP_VTMD_INT_TEMP   (0 << 5)
-#define AD7746_VTSETUP_VTMD_EXT_TEMP   (1 << 5)
+#define AD7746_VTSETUP_VTMD_EXT_TEMP   (BIT(5))
 #define AD7746_VTSETUP_VTMD_VDD_MON(2 << 5)
 #define AD7746_VTSETUP_VTMD_EXT_VIN(3 << 5)
-#define AD7746_VTSETUP_EXTREF  (1 << 4)
-#define AD7746_VTSETUP_VTSHORT (1 << 1)
-#define AD7746_VTSETUP_VTCHOP  (1 << 0)
+#define AD7746_VTSETUP_EXTREF  (BIT(4))
+#define AD7746_VTSETUP_VTSHORT (BIT(1))
+#define AD7746_VTSETUP_VTCHOP  (BIT(0))
 
 /* Excitation Setup Register Bit Designations (AD7746_REG_EXC_SETUP) */
 #define AD7746_EXCSETUP_CLKCTRLBIT(7)
@@ -75,14 +75,14 @@
 #define AD7746_CONF_VTFS_MASK  GENMASK(7, 6)
 #define AD7746_CONF_CAPFS_MASK GENMASK(5, 3)
 #define AD7746_CONF_MODE_IDLE  (0 << 0)
-#define AD7746_CONF_MODE_CONT_CONV (1 << 0)
+#define AD7746_CONF_MODE_CONT_CONV (BIT(0))
 #define AD7746_CONF_MODE_SINGLE_CONV   (2 << 0)
 #define AD7746_CONF_MODE_PWRDN (3 << 0)
 #define AD7746_CONF_MODE_OFFS_CAL  (5 << 0)
 #define AD7746_CONF_MODE_GAIN_CAL  (6 << 0)
 
 /* CAPDAC Register Bit Designations (AD7746_REG_CAPDACx) */
-#define AD7746_CAPDAC_DACEN(1 << 7)
+#define AD7746_CAPDAC_DACEN(BIT(7))
 #define AD7746_CAPDAC_DACP(x)  ((x) & 0x7F)
 
 /*
-- 
2.11.0

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


[PATCH] staging: rtl8712: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/rtl8712/rtl8712_xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c 
b/drivers/staging/rtl8712/rtl8712_xmit.c
index 7fe626583c8a..a17531b30c1d 100644
--- a/drivers/staging/rtl8712/rtl8712_xmit.c
+++ b/drivers/staging/rtl8712/rtl8712_xmit.c
@@ -503,7 +503,7 @@ static void update_txdesc(struct xmit_frame *pxmitframe, 
uint *pmem, int sz)
switch (pattrib->encrypt) { /*SEC_TYPE*/
case _WEP40_:
case _WEP104_:
-   ptxdesc->txdw1 |= cpu_to_le32((0x01 << 22) &
+   ptxdesc->txdw1 |= cpu_to_le32((BIT(22)) &
  0x00c0);
/*KEY_ID when WEP is used;*/
ptxdesc->txdw1 |= cpu_to_le32((psecuritypriv->
-- 
2.11.0

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


[PATCH] staging: sm750fb: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 5e4bfb601cea..112ee4182a0a 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -44,7 +44,7 @@ static unsigned int get_mxclk_freq(void)
OD = (pll_reg & PLL_CTRL_OD_MASK) >> PLL_CTRL_OD_SHIFT;
POD = (pll_reg & PLL_CTRL_POD_MASK) >> PLL_CTRL_POD_SHIFT;
 
-   return DEFAULT_INPUT_CLOCK * M / N / (1 << OD) / (1 << POD);
+   return DEFAULT_INPUT_CLOCK * M / N / (BIT(OD)) / (BIT(POD));
 }
 
 /*
-- 
2.11.0

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


[PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

2017-03-21 Thread Eddie Youseph
Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Eddie Youseph 
---
Changes in v2:
- Added changelog

 drivers/staging/media/bcm2048/radio-bcm2048.c | 44 +--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index d605c41..7d33bce 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2020,27 +2020,27 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
return count;   \
 }
 
-DEFINE_SYSFS_PROPERTY(power_state, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(mute, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(audio_route, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(dac_output, unsigned, int, "%u", 0)
-
-DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned, int, "%u", value > 3)
-
-DEFINE_SYSFS_PROPERTY(rds, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_wline, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
+
+DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, int, "%u", value > 3)
+
+DEFINE_SYSFS_PROPERTY(rds, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, int, "%u", 0)
 property_read(rds_pi, unsigned int, "%x")
 property_str_read(rds_rt, (BCM2048_MAX_RDS_RT + 1))
 property_str_read(rds_ps, (BCM2048_MAX_RDS_PS + 1))
@@ -2052,7 +2052,7 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
 property_read(region_top_frequency, unsigned int, "%u")
 property_signed_read(fm_carrier_error, int, "%d")
 property_signed_read(fm_rssi, int, "%d")
-DEFINE_SYSFS_PROPERTY(region, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(region, unsigned int, int, "%u", 0)
 
 static struct device_attribute attrs[] = {
__ATTR(power_state, 0644, bcm2048_power_state_read,
-- 
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: lustre: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c   | 2 +-
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c| 8 
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c | 2 +-
 drivers/staging/lustre/lnet/lnet/lib-ptl.c| 4 ++--
 drivers/staging/lustre/lnet/lnet/net_fault.c  | 8 
 drivers/staging/lustre/lustre/llite/lproc_llite.c | 4 ++--
 drivers/staging/lustre/lustre/obdclass/lustre_handles.c   | 2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c   | 2 +-
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 79321e4aaf30..449f04f125b7 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -2241,7 +2241,7 @@ static int kiblnd_hdev_get_attr(struct kib_hca_dev *hdev)
 * matching that of the native system
 */
hdev->ibh_page_shift = PAGE_SHIFT;
-   hdev->ibh_page_size  = 1 << PAGE_SHIFT;
+   hdev->ibh_page_size  = BIT(PAGE_SHIFT);
hdev->ibh_page_mask  = ~((__u64)hdev->ibh_page_size - 1);
 
hdev->ibh_mr_size = hdev->ibh_ibdev->attrs.max_mr_size;
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index eaa4399e6a2e..5bef8a7e053b 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -1906,14 +1906,14 @@ ksocknal_connect(struct ksock_route *route)
if (retry_later) /* needs reschedule */
break;
 
-   if (wanted & (1 << SOCKLND_CONN_ANY)) {
+   if (wanted & (BIT(SOCKLND_CONN_ANY))) {
type = SOCKLND_CONN_ANY;
-   } else if (wanted & (1 << SOCKLND_CONN_CONTROL)) {
+   } else if (wanted & (BIT(SOCKLND_CONN_CONTROL))) {
type = SOCKLND_CONN_CONTROL;
-   } else if (wanted & (1 << SOCKLND_CONN_BULK_IN)) {
+   } else if (wanted & (BIT(SOCKLND_CONN_BULK_IN))) {
type = SOCKLND_CONN_BULK_IN;
} else {
-   LASSERT(wanted & (1 << SOCKLND_CONN_BULK_OUT));
+   LASSERT(wanted & (BIT(SOCKLND_CONN_BULK_OUT)));
type = SOCKLND_CONN_BULK_OUT;
}
 
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
index fc7eec83ac07..2d1e3479cf7e 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
@@ -71,7 +71,7 @@ static int typed_conns = 1;
 module_param(typed_conns, int, 0444);
 MODULE_PARM_DESC(typed_conns, "use different sockets for bulk");
 
-static int min_bulk = 1 << 10;
+static int min_bulk = BIT(10);
 module_param(min_bulk, int, 0644);
 MODULE_PARM_DESC(min_bulk, "smallest 'large' message");
 
diff --git a/drivers/staging/lustre/lnet/lnet/lib-ptl.c 
b/drivers/staging/lustre/lnet/lnet/lib-ptl.c
index 63cce0c4a065..b980c669705e 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-ptl.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-ptl.c
@@ -332,7 +332,7 @@ lnet_mt_test_exhausted(struct lnet_match_table *mtable, int 
pos)
LASSERT(pos <= LNET_MT_HASH_IGNORE);
/* mtable::mt_mhash[pos] is marked as exhausted or not */
bmap = >mt_exhausted[pos >> LNET_MT_BITS_U64];
-   pos &= (1 << LNET_MT_BITS_U64) - 1;
+   pos &= (BIT(LNET_MT_BITS_U64)) - 1;
 
return (*bmap & (1ULL << pos));
 }
@@ -347,7 +347,7 @@ lnet_mt_set_exhausted(struct lnet_match_table *mtable, int 
pos, int exhausted)
 
/* set mtable::mt_mhash[pos] as exhausted/non-exhausted */
bmap = >mt_exhausted[pos >> LNET_MT_BITS_U64];
-   pos &= (1 << LNET_MT_BITS_U64) - 1;
+   pos &= (BIT(LNET_MT_BITS_U64)) - 1;
 
if (!exhausted)
*bmap &= ~(1ULL << pos);
diff --git a/drivers/staging/lustre/lnet/lnet/net_fault.c 
b/drivers/staging/lustre/lnet/lnet/net_fault.c
index 18183cbb9859..e83761a77d22 100644
--- a/drivers/staging/lustre/lnet/lnet/net_fault.c
+++ b/drivers/staging/lustre/lnet/lnet/net_fault.c
@@ -997,10 +997,10 @@ lnet_fault_ctl(int opc, struct libcfs_ioctl_data *data)
 int
 lnet_fault_init(void)
 {
-   BUILD_BUG_ON(LNET_PUT_BIT != 1 << LNET_MSG_PUT);
-   BUILD_BUG_ON(LNET_ACK_BIT != 1 << LNET_MSG_ACK);
-   BUILD_BUG_ON(LNET_GET_BIT != 1 << LNET_MSG_GET);
-   BUILD_BUG_ON(LNET_REPLY_BIT != 1 << LNET_MSG_REPLY);
+   BUILD_BUG_ON(LNET_PUT_BIT != 

[PATCH] staging: fbtft: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 4 ++--
 drivers/staging/fbtft/fb_ili9163.c | 2 +-
 drivers/staging/fbtft/fb_ili9325.c | 2 +-
 drivers/staging/fbtft/fb_ssd1289.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 4ee76dbd30b5..d31deeab69b2 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -369,7 +369,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* select left side (sc0)
 * set addr
 */
-   write_reg(par, 0x00, (1 << 6) | (u8)addr_win.xs);
+   write_reg(par, 0x00, (BIT(6)) | (u8)addr_win.xs);
write_reg(par, 0x00, (0x17 << 3) | (u8)y);
 
/* write bitmap */
@@ -392,7 +392,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* select right side (sc1)
 * set addr
 */
-   write_reg(par, 0x01, 1 << 6);
+   write_reg(par, 0x01, BIT(6));
write_reg(par, 0x01, (0x17 << 3) | (u8)y);
 
/* write bitmap */
diff --git a/drivers/staging/fbtft/fb_ili9163.c 
b/drivers/staging/fbtft/fb_ili9163.c
index 579e17734612..06a5a5f6e33e 100644
--- a/drivers/staging/fbtft/fb_ili9163.c
+++ b/drivers/staging/fbtft/fb_ili9163.c
@@ -194,7 +194,7 @@ static int set_var(struct fbtft_par *par)
 
/* Colorspcae */
if (par->bgr)
-   mactrl_data |= (1 << 2);
+   mactrl_data |= (BIT(2));
write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, mactrl_data);
write_reg(par, MIPI_DCS_WRITE_MEMORY_START);
return 0;
diff --git a/drivers/staging/fbtft/fb_ili9325.c 
b/drivers/staging/fbtft/fb_ili9325.c
index 7189de5ae4b3..ab1267a9cd11 100644
--- a/drivers/staging/fbtft/fb_ili9325.c
+++ b/drivers/staging/fbtft/fb_ili9325.c
@@ -126,7 +126,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x0013, 0x); /* VDV[4:0] for VCOM amplitude */
mdelay(200); /* Dis-charge capacitor power voltage */
write_reg(par, 0x0010, /* SAP, BT[3:0], AP, DSTB, SLP, STB */
-   (1 << 12) | (bt << 8) | (1 << 7) | (0x01 << 4));
+   (BIT(12)) | (bt << 8) | (BIT(7)) | (BIT(4)));
write_reg(par, 0x0011, 0x220 | vc); /* DC1[2:0], DC0[2:0], VC[2:0] */
mdelay(50); /* Delay 50ms */
write_reg(par, 0x0012, vrh); /* Internal reference voltage= Vci; */
diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index c603e1516e64..b22a07d79b34 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -47,7 +47,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x0E, 0x2B00);
write_reg(par, 0x1E, 0x00B7);
write_reg(par, 0x01,
-   (1 << 13) | (par->bgr << 11) | (1 << 9) | (HEIGHT - 1));
+   (BIT(13)) | (par->bgr << 11) | (BIT(9)) | (HEIGHT - 1));
write_reg(par, 0x02, 0x0600);
write_reg(par, 0x10, 0x);
write_reg(par, 0x05, 0x);
-- 
2.11.0

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


[PATCH] staging: rts5208: Replace a bit shift by a use of BIT.

2017-03-21 Thread Arushi Singhal
This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/rts5208/rtsx_chip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_chip.c 
b/drivers/staging/rts5208/rtsx_chip.c
index 3511157a2c78..06a61800b71a 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -1490,7 +1490,7 @@ int rtsx_write_register(struct rtsx_chip *chip, u16 addr, 
u8 mask, u8 data)
 
for (i = 0; i < MAX_RW_REG_CNT; i++) {
val = rtsx_readl(chip, RTSX_HAIMR);
-   if ((val & (1 << 31)) == 0) {
+   if ((val & (BIT(31))) == 0) {
if (data != (u8)val) {
rtsx_trace(chip);
return STATUS_FAIL;
@@ -1518,7 +1518,7 @@ int rtsx_read_register(struct rtsx_chip *chip, u16 addr, 
u8 *data)
 
for (i = 0; i < MAX_RW_REG_CNT; i++) {
val = rtsx_readl(chip, RTSX_HAIMR);
-   if ((val & (1 << 31)) == 0)
+   if ((val & (BIT(31))) == 0)
break;
}
 
-- 
2.11.0

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


[PATCH 0/2] staging: ks7010: refactor hostif_sme_task()

2017-03-21 Thread Tobin C. Harding
Function lends itself to being refactored. There are two checkpatch
issues generated from this function.

Patch 01 removes a redundant nested conditional check.

Patch 02 inverts two conditionals, and reduces the subsequent code
indentation.

Tobin C. Harding (2):
  staging: ks7010: remove redundant check
  staging: ks7010: invert if statement conditionals

 drivers/staging/ks7010/ks_hostif.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

-- 
2.7.4

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


[PATCH 1/2] staging: ks7010: remove redundant check

2017-03-21 Thread Tobin C. Harding
Function checks for condition inside a loop that checks the same
condition, this is redundant. Fix also removes checkpatch CHECK.

Remove redundant check.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks_hostif.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 460ab13..b1213c8 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -2607,8 +2607,7 @@ void hostif_sme_task(unsigned long dev)
DPRINTK(3, "\n");
 
if (priv->dev_state >= DEVICE_STATE_BOOT) {
-   if (cnt_smeqbody(priv) > 0
-   && priv->dev_state >= DEVICE_STATE_BOOT) {
+   if (cnt_smeqbody(priv) > 0) {
hostif_sme_execute(priv,
   priv->sme_i.event_buff[priv->sme_i.
  qhead]);
-- 
2.7.4

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


[PATCH 2/2] staging: ks7010: invert if statement conditionals

2017-03-21 Thread Tobin C. Harding
Checkpatch emits WARNING: Avoid multiple line dereference.

Function uses if statement blocks to guard the body of the
function. If we invert these conditionals and return, then the code
becomes more readable and subsequent code is indented less. The
checkpatch fix then follows trivially.

Invert conditionals, return from function if new conditional evaluates
to true. Reduce the level of indentation in subsequent code.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks_hostif.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index b1213c8..d48c3ba 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -2606,16 +2606,16 @@ void hostif_sme_task(unsigned long dev)
 
DPRINTK(3, "\n");
 
-   if (priv->dev_state >= DEVICE_STATE_BOOT) {
-   if (cnt_smeqbody(priv) > 0) {
-   hostif_sme_execute(priv,
-  priv->sme_i.event_buff[priv->sme_i.
- qhead]);
-   inc_smeqhead(priv);
-   if (cnt_smeqbody(priv) > 0)
-   tasklet_schedule(>sme_task);
-   }
-   }
+   if (priv->dev_state < DEVICE_STATE_BOOT)
+   return;
+
+   if (cnt_smeqbody(priv) <= 0)
+   return;
+
+   hostif_sme_execute(priv, priv->sme_i.event_buff[priv->sme_i.qhead]);
+   inc_smeqhead(priv);
+   if (cnt_smeqbody(priv) > 0)
+   tasklet_schedule(>sme_task);
 }
 
 /* send to Station Management Entity module */
-- 
2.7.4

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


[PATCH 4/4] staging: ks7010: add braces to multi-line indent

2017-03-21 Thread Tobin C. Harding
The addition of curly braces around single statements that span
multiple lines makes the code more readable in general.

Add curly braces to multi-line indented statement.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks_hostif.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 24feee3..38ea7a2 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -2455,16 +2455,18 @@ void hostif_sme_execute(struct ks_wlan_private *priv, 
int event)
hostif_phy_information_request(priv);
break;
case SME_MIC_FAILURE_REQUEST:
-   if (priv->wpa.mic_failure.failure == 1)
-   hostif_mic_failure_request(
-   priv, priv->wpa.mic_failure.failure - 1, 0);
-   else if (priv->wpa.mic_failure.failure == 2)
-   hostif_mic_failure_request(
-   priv, priv->wpa.mic_failure.failure - 1,
-   priv->wpa.mic_failure.counter);
-   else
+   if (priv->wpa.mic_failure.failure == 1) {
+   hostif_mic_failure_request(priv,
+  
priv->wpa.mic_failure.failure - 1,
+  0);
+   } else if (priv->wpa.mic_failure.failure == 2) {
+   hostif_mic_failure_request(priv,
+  
priv->wpa.mic_failure.failure - 1,
+  
priv->wpa.mic_failure.counter);
+   } else {
DPRINTK(4, "SME_MIC_FAILURE_REQUEST: failure count=%u 
error?\n",
priv->wpa.mic_failure.failure);
+   }
break;
case SME_MIC_FAILURE_CONFIRM:
if (priv->wpa.mic_failure.failure == 2) {
-- 
2.7.4

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


[PATCH 3/4] staging: ks7010: add explicit check to 'size' variables

2017-03-21 Thread Tobin C. Harding
When checking the value of a variable that holds a 0 an explicit check
is good style. i.e

  -if (!size)
  +if (size == 0)

Update checks on 'numerical' variables to use explicit checks.

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks7010_sdio.c | 4 ++--
 drivers/staging/ks7010/ks_hostif.c   | 2 +-
 drivers/staging/ks7010/ks_wlan_net.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index dbb1f05..8829989 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -591,7 +591,7 @@ static void ks_sdio_interrupt(struct sdio_func *func)
}
DPRINTK(4, "WSTATUS_RSIZE=%02X\n", rw_data);
rsize = rw_data & RSIZE_MASK;
-   if (rsize) {/* Read schedule */
+   if (rsize != 0) {   /* Read schedule */
ks_wlan_hw_rx((void *)priv,
  (uint16_t)(rsize << 4));
}
@@ -829,7 +829,7 @@ static void ks7010_card_init(struct ks_wlan_private *priv)
DPRINTK(1, "wait time out!! SME_START\n");
}
 
-   if (priv->mac_address_valid && priv->version_size)
+   if (priv->mac_address_valid && priv->version_size != 0)
priv->dev_state = DEVICE_STATE_PREINIT;
 
hostif_sme_enqueue(priv, SME_GET_EEPROM_CKSUM);
diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index dc730a3..24feee3 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -129,7 +129,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct 
link_ap_info_t *ap_info)
memcpy(ap->rate_set.body, ap_info->rate_set.body,
   ap_info->rate_set.size);
ap->rate_set.size = ap_info->rate_set.size;
-   if (ap_info->ext_rate_set.size) {
+   if (ap_info->ext_rate_set.size != 0) {
/* rate_set */
memcpy(>rate_set.body[ap->rate_set.size],
   ap_info->ext_rate_set.body,
diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index c097ecd..5e68699 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -335,7 +335,7 @@ static int ks_wlan_get_essid(struct net_device *dev,
/* Note : if dwrq->flags != 0, we should
 * get the relevant SSID from the SSID list...
 */
-   if (priv->reg.ssid.size) {
+   if (priv->reg.ssid.size != 0) {
/* Get the current SSID */
memcpy(extra, priv->reg.ssid.body, priv->reg.ssid.size);
 
@@ -928,7 +928,7 @@ static int ks_wlan_set_encode(struct net_device *dev,
/* Do we want to just set the transmit key index ? */
if ((index >= 0) && (index < 4)) {
/* set_wep_key(priv, index, 0, 0, 1);   xxx */
-   if (priv->reg.wep_key[index].size) {
+   if (priv->reg.wep_key[index].size != 0) {
priv->reg.wep_index = index;
priv->need_commit |= SME_WEP_INDEX;
} else {
@@ -1531,7 +1531,7 @@ static int ks_wlan_get_scan(struct net_device *dev,
return -EAGAIN;
}
 
-   if (!priv->aplist.size) {
+   if (priv->aplist.size == 0) {
/* Client error, no scan results...
 * The caller need to restart the scan.
 */
-- 
2.7.4

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


[PATCH 0/4] staging: ks7010: fix style issues

2017-03-21 Thread Tobin C. Harding
Review from previous (merged) patch set made comment on a couple of
style issues. In the same review a bug was reported. We start off
fixing the bug then move on to fix the style issues. None of these
issues are reported by checkpatch, Sparse, or Smatch. Some instances
were introduced by Tobin Harding in the afore mentioned patch set. An
attempt at fixing the whole driver was made, however, an audit of
every 'if' statement was not conducted. 

Patch 01 fixes incorrect usage of return value of memcmp().

Patch 02 adds explicit checks to calls to memcmp() across the whole
driver.

Patch 03 adds previously removed explicit checks to 'size' variables.

Patch 04 adds previously removed braces to multi-line single statement
code blocks.

Code has not been tested. Patch set applies and builds on x86_64 and
PowerPC.

Tobin C. Harding (4):
  staging: ks7010: fix memcmp() bug
  staging: ks7010: add explicit check to memcmp() calls
  staging: ks7010: add explicit check to 'size' variables
  staging: ks7010: add braces to multi-line indent

 drivers/staging/ks7010/ks7010_sdio.c |  8 
 drivers/staging/ks7010/ks_hostif.c   | 35 ++-
 drivers/staging/ks7010/ks_wlan_net.c | 19 +--
 3 files changed, 31 insertions(+), 31 deletions(-)

-- 
2.7.4

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


[PATCH 2/4] staging: ks7010: add explicit check to memcmp() calls

2017-03-21 Thread Tobin C. Harding
Calls to functions memcmp() and strcmp() are more clearly readable
when the return value is explicitly checked. i.e

if (memcmp(foo, bar, size) == 0)

Modify driver to use an explicit check on the value returned by
memcmp().

Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks_hostif.c   | 15 +++
 drivers/staging/ks7010/ks_wlan_net.c | 13 ++---
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 460ab13..dc730a3 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -271,7 +271,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct 
ap_info_t *ap_info,
memcpy(ap->rsn_ie.body, bp + 2, ap->rsn_ie.size);
break;
case 221:   /* WPA */
-   if (!memcmp(bp + 2, "\x00\x50\xf2\x01", 4)) {   /* WPA 
OUI check */
+   if (memcmp(bp + 2, "\x00\x50\xf2\x01", 4) == 0) {   
/* WPA OUI check */
ap->wpa_ie.id = *bp;
if (*(bp + 1) <= RSN_IE_BODY_MAX) {
ap->wpa_ie.size = *(bp + 1);
@@ -325,7 +325,7 @@ int hostif_data_indication_wpa(struct ks_wlan_private *priv,
eth_proto = ntohs(eth_hdr->h_proto);
 
/* source address check */
-   if (!memcmp(_hdr->h_source[0], >eth_addr[0], ETH_ALEN))
+   if (memcmp(_hdr->h_source[0], >eth_addr[0], ETH_ALEN) == 0)
return 0;
 
if (eth_hdr->h_dest_snap != eth_hdr->h_source_snap) {
@@ -353,7 +353,7 @@ int hostif_data_indication_wpa(struct ks_wlan_private *priv,
   (uint8_t)0,  /* priority */
   (uint8_t *)michael_mic.Result);
}
-   if (memcmp(michael_mic.Result, RecvMIC, 8)) {
+   if (memcmp(michael_mic.Result, RecvMIC, 8) != 0) {
now = jiffies;
mic_failure = >wpa.mic_failure;
/* MIC FAILURE */
@@ -421,7 +421,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
DPRINTK(3, "ether protocol = %04X\n", eth_proto);
 
/* source address check */
-   if (!memcmp(>eth_addr[0], eth_hdr->h_source, ETH_ALEN)) {
+   if (memcmp(>eth_addr[0], eth_hdr->h_source, ETH_ALEN) == 0) {
DPRINTK(1, "invalid : source is own mac address !!\n");
DPRINTK(1,
"eth_hdrernet->h_dest=%02X:%02X:%02X:%02X:%02X:%02X\n",
@@ -836,9 +836,8 @@ void hostif_scan_indication(struct ks_wlan_private *priv)
 
if (priv->scan_ind_count) {
for (i = 0; i < priv->aplist.size; i++) {   /* bssid check 
*/
-   if (!memcmp
-   (ap_info->bssid,
-priv->aplist.ap[i].bssid, ETH_ALEN)) {
+   if (memcmp(ap_info->bssid,
+  priv->aplist.ap[i].bssid, ETH_ALEN) == 0) {
if (ap_info->frame_type ==
FRAME_TYPE_PROBE_RESP)
get_ap_information(priv, ap_info,
@@ -1168,7 +1167,7 @@ int hostif_data_request(struct ks_wlan_private *priv, 
struct sk_buff *packet)
 
/* packet check */
eth = (struct ethhdr *)packet->data;
-   if (memcmp(>eth_addr[0], eth->h_source, ETH_ALEN)) {
+   if (memcmp(>eth_addr[0], eth->h_source, ETH_ALEN) != 0) {
DPRINTK(1, "invalid mac address !!\n");
DPRINTK(1, "ethernet->h_source=%pM\n", eth->h_source);
ret = -ENXIO;
diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 3f9eba4..c097ecd 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -1924,9 +1924,8 @@ static int ks_wlan_set_pmksa(struct net_device *dev,
if (list_empty(>pmklist.head)) {  /* new list */
for (i = 0; i < PMK_LIST_MAX; i++) {
pmk = >pmklist.pmk[i];
-   if (!memcmp
-   ("\x00\x00\x00\x00\x00\x00", pmk->bssid,
-ETH_ALEN))
+   if (memcmp("\x00\x00\x00\x00\x00\x00",
+  pmk->bssid, ETH_ALEN) == 0)
break; /* loop */
}
memcpy(pmk->bssid, pmksa->bssid.sa_data, ETH_ALEN);
@@ -1938,7 +1937,7 @@ static int ks_wlan_set_pmksa(struct net_device *dev,
/* search cache data */
list_for_each(ptr, >pmklist.head) {
pmk = list_entry(ptr, struct pmk_t, list);
-   if 

[PATCH 1/4] staging: ks7010: fix memcmp() bug

2017-03-21 Thread Tobin C. Harding
Call site to memcmp() treats return value as if it were an error code,
it is not. If memcmp() finds inputs to be not the same, an error
return code should be set explicitly.

Correctly handle return value from call to memcmp(), set error code
explicitly.

Reported-by: Dan Carpenter 
Signed-off-by: Tobin C. Harding 
---
 drivers/staging/ks7010/ks7010_sdio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index 28b91be..dbb1f05 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -695,8 +695,8 @@ static int ks7010_sdio_data_compare(struct ks_wlan_private 
*priv, u32 address,
if (ret)
goto err_free_read_buf;
 
-   ret = memcmp(data, read_buf, size);
-   if (ret) {
+   if (memcmp(data, read_buf, size) != 0) {
+   ret = -EIO;
DPRINTK(0, "data compare error (%d)\n", ret);
goto err_free_read_buf;
}
-- 
2.7.4

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


Re: [patch 0/7] staging: speakup: introduce tty-based comms

2017-03-21 Thread Samuel Thibault
Hello,

So Rob, how do you see this going?  Shall we introduce a serdev_device
*tty_port_register_serdev_device(tty, device)? Will you work on it or
should I give it a try?

Samuel

Samuel Thibault, on mer. 15 mars 2017 16:03:23 +0100, wrote:
> Rob Herring, on mer. 15 mars 2017 09:45:59 -0500, wrote:
> > On Mon, Mar 13, 2017 at 8:18 PM, Samuel Thibault
> >  wrote:
> > > Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote:
> > >> Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote:
> > >> > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com 
> > >> > wrote:
> > >> > > This patchset introduces a TTY-based way for the synths to 
> > >> > > communicate
> > >> > > with devices as an alternate for direct serial comms used by the 
> > >> > > synths
> > >> > > at the moment. It then migrates some of the synths to the TTY-based
> > >> > > comms. Synths migrated in this patchset are dummy, acntsa, bns and
> > >> > > txprt.
> > >> >
> > >> > What about using the serbus code that is now in the tree?  That should
> > >> > make this a lot easier than your patchset from what I can see.
> > >>
> > >> Mmm... AIUI from reading tty_port_register_device_attr, one
> > >> would have to have registered a speakup serdev device driver
> > >> *before* tty_port_register_device_attr gets called, so that
> > >> serdev_tty_port_register matches the driver in the loop of
> > >> of_serdev_register_devices, and no TTY cdev is created?
> > 
> > Not exactly. The driver doesn't have to be registered nor loaded, but
> > the device does have to be present so no tty cdev is created. The only
> > way a device is present currently is when a node is in the DT. I
> > expect the x86 folks will be adding ACPI support soon.
> 
> Ok, but in our case there is no hardware device that the system can
> see/probe, it's just plugged externally.
> 
> > >> That would mean that speakup can not be loaded as a module after ttyS0
> > >> initialization, that won't fly for our use needs. The line discipline
> > >> mechanism allows us to attach ourself to an existing tty.  Could we
> > >> imagine a tty_port function which removes the cdev and tries to register
> > >> the tty port again to serdev?
> > >>
> > >> What we basically need to be able to say on speakup module load is
> > >> e.g. "I'm now attaching a device to ttyS0, use this serdev_device_ops to
> > >> discuss with it".
> > >
> > > That for_each_available_child_of_node loop is really way more complex
> > > than what we need.  And what's more, it's not working without CONFIG_OF
> > > (!)
> > >
> > > It would really make sense to me to have a
> > >
> > > serdev_device *tty_port_register_serdev_device(tty, device)
> > >
> > > which unregisters the character device of the tty, and creates instead a
> > > controler with the given device plugged to it. Really much like a line
> > > discipline, but way simpler :)
> > 
> > What would trigger calling this function?
> 
> From the user point of view, loading the speakup module for the external
> device, typically, with "ttyS0" as module parameter. Then the speakup
> init function can do whatever it needs to achieve this :)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-03-21 Thread Steve Longerbeam



On 03/21/2017 04:27 AM, Russell King - ARM Linux wrote:

On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:

@@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
incc = imx_media_find_mbus_format(infmt->code,
  CS_SEL_ANY, true);

-   if (sdformat->format.width < priv->crop.width * 3 / 4)
-   sdformat->format.width = priv->crop.width / 2;
-   else
-   sdformat->format.width = priv->crop.width;
-
-   if (sdformat->format.height < priv->crop.height * 3 / 4)
-   sdformat->format.height = priv->crop.height / 2;
-   else
-   sdformat->format.height = priv->crop.height;
+   sdformat->format.width = compose->width;
+   sdformat->format.height = compose->height;

if (incc->bayer) {
sdformat->format.code = infmt->code;


We need to do more in here, because right now setting the source pads
overwrites the colorimetry etc information.  Maybe something like the
below?


I'm thinking, to support propagating the colorimetry params, there
should be a util function

void imx_media_copy_colorimetry(struct v4l2_mbus_framefmt *out,
struct v4l2_mbus_framefmt *in);

that can be used throughout the pipeline, that does exactly what
you add below.


 I'm wondering if it would be a saner approach to copy the
sink format and update the parameters that can be changed, rather than
trying to list all the parameters that shouldn't be changed.


For CSI that is a bit difficult, because the source formats are
hardly related to the sink formats, so so much would have to be
modified after copying the sink format that it would be rather
pointless, except to forward the colorimetry params.

Steve


 What if the format structure gains a new member?

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1492b92e1970..756204ced53c 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1221,6 +1221,12 @@ static void csi_try_fmt(struct csi_priv *priv,
sdformat->format.field =  (infmt->height == 480) ?
V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
}
+
+   /* copy settings we can't change */
+   sdformat->format.colorspace = infmt->colorspace;
+   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
+   sdformat->format.quantization = infmt->quantization;
+   sdformat->format.xfer_func = infmt->xfer_func;
break;
case CSI_SINK_PAD:
v4l_bound_align_image(>format.width, MIN_W, MAX_W,




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


[PATCH] speakup: Fix spurious space pronunciation on spelling letters

2017-03-21 Thread Samuel Thibault
This gathers emitting the caps start string, space, spelled letter
string, space, and caps stop string, into one printf, to avoid
sending to the synth a space character alone, which the synth would
then pronounce.

Similarly, emit space along control-letter and letter spelling.

Signed-off-by: Samuel Thibault 
Tested-by: Zahari Yurukov 

Index: linux-4.10/drivers/staging/speakup/main.c
===
--- linux-4.10.orig/drivers/staging/speakup/main.c
+++ linux-4.10/drivers/staging/speakup/main.c
@@ -448,20 +448,17 @@ static void speak_char(u16 ch)
pr_info("speak_char: cp == NULL!\n");
return;
}
-   synth_buffer_add(SPACE);
if (IS_CHAR(ch, B_CAP)) {
spk_pitch_shift++;
-   synth_printf("%s", spk_str_caps_start);
-   synth_printf("%s", cp);
-   synth_printf("%s", spk_str_caps_stop);
+   synth_printf("%s %s %s",
+spk_str_caps_start, cp, spk_str_caps_stop);
} else {
if (*cp == '^') {
-   synth_printf("%s", spk_msg_get(MSG_CTRL));
cp++;
-   }
-   synth_printf("%s", cp);
+   synth_printf(" %s%s ", spk_msg_get(MSG_CTRL), cp);
+   } else
+   synth_printf(" %s ", cp);
}
-   synth_buffer_add(SPACE);
 }
 
 static u16 get_char(struct vc_data *vc, u16 *pos, u_char *attribs)

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


Re: [PATCH] Staging: ks7010 - fixed style block comments

2017-03-21 Thread Tobin C. Harding
On Wed, Mar 22, 2017 at 07:29:50AM +1300, Derek Robson wrote:
> On Tue, Mar 21, 2017 at 08:56:25AM +0100, Greg KH wrote:
> > On Sun, Mar 19, 2017 at 01:07:17PM +1300, Derek Robson wrote:
> > > Fixed style of all block comments across whole driver
> > > Found by checkpatch
> > > 
> > > Signed-off-by: Derek Robson 
> > > ---
> > >  drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
> > >  drivers/staging/ks7010/ks_hostif.h   | 35 +-
> > >  drivers/staging/ks7010/ks_wlan.h |  3 ++-
> > >  drivers/staging/ks7010/ks_wlan_net.c | 41 
> > > +++-
> > >  4 files changed, 55 insertions(+), 27 deletions(-)
> > 
> > This patch doesn't apply to my tree at all :(
> >
> 
> Am I working from the right/best tree for driver/staging?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> 
> Thanks for helping the new guy :-)

I think you just got unlucky on this one Derek, a patch set of mine
that happened to fix this got merged the same morning you submitted
your patch set.

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


Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-03-21 Thread Steve Longerbeam

Hi Philipp, Russell,


On 03/20/2017 10:23 AM, Philipp Zabel wrote:

Hi Steve, Russell,



What do you think of this:

--8<--
From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 20 Mar 2017 17:10:21 +0100
Subject: [PATCH] media: imx: csi: add sink selection rectangles

Move the crop rectangle to the sink pad and add a sink compose rectangle
to configure scaling. Also propagate rectangles from sink pad to crop
rectangle, to compose rectangle, and to the source pads both in ACTIVE
and TRY variants of set_fmt/selection, and initialize the default crop
and compose rectangles.




I applied this patch.

I noticed Philipp fixed a bug in the sink->source pad format
propagation. I was only propagating the active runs, and not
the trial runs. I fixed this everywhere in the pipeline, applied
to the "propagate sink pad formats to source pads" patch. Try
runs should now work correctly across the whole pipeline, but
I haven't tested this.

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


Re: [PATCH 10/10] staging: ks7010: rename return value identifier

2017-03-21 Thread Tobin C. Harding
On Tue, Mar 21, 2017 at 03:53:46PM +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:37:12PM +1100, Tobin C. Harding wrote:
> >  static int ks7010_sdio_data_compare(struct ks_wlan_private *priv, u32 
> > address,
> > unsigned char *data, unsigned int size)
> >  {
> > -   int rc;
> > +   int ret;
> > unsigned char *read_buf;
> >  
> > read_buf = kmalloc(ROM_BUFF_SIZE, GFP_KERNEL);
> > if (!read_buf)
> > return -ENOMEM;
> >  
> > -   rc = ks7010_sdio_read(priv, address, read_buf, size);
> > -   if (rc)
> > +   ret = ks7010_sdio_read(priv, address, read_buf, size);
> > +   if (ret)
> > goto err_free_read_buf;
> >  
> > -   rc = memcmp(data, read_buf, size);
> > -   if (rc) {
> > -   DPRINTK(0, "data compare error (%d)\n", rc);
> > +   ret = memcmp(data, read_buf, size);
> > +   if (ret) {
> 
> You didn't introduce this, but this is a bug.  memcpy() doesn't return
> error codes.  Could you fix it in a follow on patch?

I have a sneaking suspicion that I may have introduced this in an
earlier patch. I'll fix it. Good spot, cheers.

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


Re: [PATCH 09/10] staging: ks7010: remove zero comparison

2017-03-21 Thread Tobin C. Harding
On Tue, Mar 21, 2017 at 03:49:22PM +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:37:11PM +1100, Tobin C. Harding wrote:
> > Comparison, equal to zero, is redundant
> > 
> > 'if (foo == 0)'  is equal to  'if (!foo)'
> > 
> > Typical kernel coding style is to use the shorter form.
> > 
> > Remove unnecessary zero comparison.
> 
> Not exactly.  If you're talking about the number zero then == 0 and != 0
> are good style.  "if (size == 0) ".  Other times we're talking about
> error codes or whatever and not the number zero so it should be
> "if (ret) ".  Also for strcmp() functions, please use != 0 and == 0.
> 
>   if (strcmp(foo, bar) != 0)  <-- read this as "foo != bar"
>   if (strcmp(foo, bar) == 0)  <-- read this as "foo == bar"
>   if (strcmp(foo, bar) < 0)  <-- read this as "foo < bar"
> 
> regards,
> dan carpenter
> 
> 

What is best for flags please?

-   if (dwrq->flags == 0) {
+   if (!dwrq->flags) {


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


Re: [PATCH 04/10] staging: ks7010: fix checkpatch BRACES

2017-03-21 Thread Tobin C. Harding
On Tue, Mar 21, 2017 at 03:36:34PM +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:37:06PM +1100, Tobin C. Harding wrote:
> > Checkpatch emits CHECK: Unbalanced braces around else
> > statement. Statements in question are single statements so we do not
> > need braces. Checkpatch also warns about multiple line dereference for
> > this code.
> > 
> > Fix if/else/else if statement use of braces. Fix function argument layout
> > at the same time since it is the same statement.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  drivers/staging/ks7010/ks_hostif.c | 22 +-
> >  1 file changed, 9 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/staging/ks7010/ks_hostif.c 
> > b/drivers/staging/ks7010/ks_hostif.c
> > index db10e16..68e26f4 100644
> > --- a/drivers/staging/ks7010/ks_hostif.c
> > +++ b/drivers/staging/ks7010/ks_hostif.c
> > @@ -2456,19 +2456,15 @@ void hostif_sme_execute(struct ks_wlan_private 
> > *priv, int event)
> > hostif_phy_information_request(priv);
> > break;
> > case SME_MIC_FAILURE_REQUEST:
> > -   if (priv->wpa.mic_failure.failure == 1) {
> > -   hostif_mic_failure_request(priv,
> > -  priv->wpa.mic_failure.
> > -  failure - 1, 0);
> > -   } else if (priv->wpa.mic_failure.failure == 2) {
> > -   hostif_mic_failure_request(priv,
> > -  priv->wpa.mic_failure.
> > -  failure - 1,
> > -  priv->wpa.mic_failure.
> > -  counter);
> > -   } else
> > -   DPRINTK(4,
> > -   "SME_MIC_FAILURE_REQUEST: failure count=%u 
> > error?\n",
> > +   if (priv->wpa.mic_failure.failure == 1)
> > +   hostif_mic_failure_request(
> > +   priv, priv->wpa.mic_failure.failure - 1, 0);
> > +   else if (priv->wpa.mic_failure.failure == 2)
> > +   hostif_mic_failure_request(
> > +   priv, priv->wpa.mic_failure.failure - 1,
> > +   priv->wpa.mic_failure.counter);
> > +   else
> > +   DPRINTK(4, "SME_MIC_FAILURE_REQUEST: failure count=%u 
> > error?\n",
> > priv->wpa.mic_failure.failure);
> 
> No.  This isn't nice.
> 
> Multi-line indents get curly braces generally for readability.  It's
> better to go over the 80 character limit here.
> 
> 
>   if (priv->wpa.mic_failure.failure == 1) {
>   hostif_mic_failure_request(priv,
>  
> priv->wpa.mic_failure.failure - 1,
>  0);
>   } else if priv->wpa.mic_failure.failure == 2) {
>   hostif_mic_failure_request(priv,
>  
> priv->wpa.mic_failure.failure - 1,
>  
> priv->wpa.mic_failure.counter);
>   } else {
>   DPRINTK(4, "SME_MIC_FAILURE_REQUEST: failure count=%u 
> error?\n",
>   priv->wpa.mic_failure.failure);
>   }
> 
> regards,
> dan carpenter
> 

Ok, point noted, thank you.

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


Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-21 Thread Robert Perry Hooker
Thanks for taking a look, Dan. Sorry if I missed the mark here.

Can you tell me a bit more about the bug this would introduce?

I see that ieee80211_is_action is defined like this: static inline bool 
ieee80211_is_action(__le16 fc)

...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).

Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered by 
implicitly casting a u8 to __le16? Or am I
missing something else?

Regards,
Perry

On Tue, 2017-03-21 at 23:19 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:55:40PM -0600, Perry Hooker wrote:
> > This commit fixes the following sparse warnings:
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: 
> > incorrect type in argument 1 (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: 
> > incorrect type in assignment (different base > > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > 
> > Signed-off-by: Perry Hooker 
> > ---
> >  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +---
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > index a37896f..d1c75c7 100644
> > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > @@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 
> > *buff, u32 size)
> > } else {
> > s32Freq = ieee80211_channel_to_frequency(curr_channel, 
> > NL80211_BAND_2GHZ);
> >  
> > -   if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > +   if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> 
> Nah...  You're just introducing bugs here.  Please be more careful.
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

2017-03-21 Thread Eric Anholt
Michael Zoran  writes:

> On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
>> Michael Zoran  writes:
>> 
>> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> > > Michael Zoran  writes:
>> > > 
>> > > > > > Since the API is completely documented, I see no reason we
>> > > > > > or
>> > > > > > anybody
>> > > > > > couldn't essentially rewrite the driver while it's in
>> > > > > > staging.  I
>> > > > > > just
>> > > > > > think it would be best for everyone if the new version was
>> > > > > > a
>> > > > > > drop
>> > > > > > in
>> > > > > > replacement for the original version.  Essential an
>> > > > > > enhancement
>> > > > > > rather
>> > > > > > then a competitor.
>> > > > > 
>> > > > > I think my comments weren't fundamental changes, but you
>> > > > > surely
>> > > > > mean
>> > > > > the devicetree ABI? I like to see this driver ASAP out of
>> > > > > staging
>> > > > > and
>> > > > > i'm not interested to maintain 2 functional identical driver
>> > > > > only
>> > > > > to
>> > > > > keep compability with the Foundation tree. Currently i'm
>> > > > > afraid
>> > > > > that
>> > > > > we build up many drivers in staging, which need a complete
>> > > > > rewrite
>> > > > > later if they should come out of staging. It would be nice if
>> > > > > we
>> > > > > could avoid the situation we have with the thermal driver.
>> > > > > 
>> > > > > Stefan
>> > > > 
>> > > > The API I'm talking about here is the mailbox API that is used
>> > > > to
>> > > > talk
>> > > > to the firmware.  The numbers and structures to pass are
>> > > > documented. 
>> > > > Nothing prevents anybody from rewriting this driver and
>> > > > submitting
>> > > > it
>> > > > to the appropriate subsystems.  It's certainly small enough.
>> > > > 
>> > > > If you really want working thermal or cpu speed drivers today,
>> > > > nothing
>> > > > stops anybody from submitting the downstream drivers after
>> > > > doing
>> > > > some
>> > > > minor touchups and submitting them to staging.  That would at
>> > > > least
>> > > > get
>> > > > things working while people argue about what the correct DT
>> > > > nodes
>> > > > should be.
>> > > > 
>> > > > I would also like to point out that the RPI 3 has been out for
>> > > > over
>> > > > a
>> > > > year and nobody has been able to get working video out of it
>> > > > through
>> > > > VC4 on a mainline tree.  At least until now.  So I'm not sure
>> > > > the
>> > > > best
>> > > > way to go is for the expander driver to go under the GPIO
>> > > > subtree.
>> > > 
>> > > Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe
>> > > for
>> > > connection when the GPIO line isn't present in the DT.
>> > 
>> > Just a FYI, Eric Anholt has offically announced support for VC4 for
>> > HDMI on mainline Linus build without any support from the expander
>> > on
>> > the RPI 3.  
>> > 
>> > Sounds like this particular driver isn't needed then, correct?
>> 
>> That's the HDMI audio that just landed.  HDMI has been working on the
>> pi3 since 9d44a8d530e8cc97d71ffcbc0ff3b5553c62.
>> 
>> In the absence of a GPIO line for hotplug detect, we use DDC, which
>> is
>> slower and throws an error in dmesg when the probe happens but HDMI
>> is
>> disconnected.  As such, having a GPIO driver would improve things for
>> people.
>
>
> Would a non DT based solution be outside the realm of possibilities?  I
> wrote a very simple library that emulates vcgencmd from the kernel. 
> One of the commands for vcgencmd is to query the HDMI hotplug status. 
> It's sort of semi documentated on the web.  The vcgencmd library works,
> but I haven't tested if the virtualized hotplug info from the command
> output is correct in all cases.
>
> What I'm thinking is I could package this in a single file library that
> would get put in upstream, but it would only support 1 command only. To
> query the virtual hotplug status.
>
> The only thing is you would need to take a dependency from VC4 to
> vchiq/vc04_services.  It would get VC4 working better on upstream, but
> it would mean taking a dependency from VC4 to vc04_services and the
> stagging tree(with all that imples).
>
> I think this may be a better solution then arguing with the DT folks on
> this expander driver that isn't being directly controlled.
>
> What do you think?

Not interested.  We should expose the full GPIO expander using the
firmware's GPIO expander interfaces, which is a more generally useful
solution.


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


Re: [PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

2017-03-21 Thread Michael Zoran
On Tue, 2017-03-21 at 23:30 +0300, Dan Carpenter wrote:
> I've read Stefan's review comments and intervened where I didn't
> understand them.  The recent ones are very specific and reasonable...
> 
> Just send a v2.  I don't get what the deal is...

Partly because Eric and Stefan have publically annouced all over the
who knows where that they don't want this in staging.  They say it
needs to go to the general tree.  So I'm not 100% sure a V2 makes sense
when people aren't even agreeing if this is the correct place for this 
to be.

I did not write the driver myself, I've simply been burdened myself
that VC4 doesn't really work that good on the RPI 3 so I was hoping it
would unblock people after finding it on the web.

If people want a V2, then they are going to have to be very specific
about what needs to change and exactly how it to change. Not just say
they don't like it.

If it's suddenly so important, why can't someone else add in their
corrections after my Signed-off-by: and add their own Signed-off-by:. 
Or better yet submit the original driver themselves.






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


Re: [PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

2017-03-21 Thread Dan Carpenter
I've read Stefan's review comments and intervened where I didn't
understand them.  The recent ones are very specific and reasonable...

Just send a v2.  I don't get what the deal is...

regards,
dan carpenter

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


Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 01:55:40PM -0600, Perry Hooker wrote:
> This commit fixes the following sparse warnings:
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: incorrect 
> type in argument 1 (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: incorrect 
> type in assignment (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: incorrect 
> type in assignment (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: incorrect 
> type in assignment (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: incorrect 
> type in assignment (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: incorrect 
> type in assignment (different base types)
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: incorrect 
> type in assignment (different base types)
> 
> Signed-off-by: Perry Hooker 
> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index a37896f..d1c75c7 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, 
> u32 size)
>   } else {
>   s32Freq = ieee80211_channel_to_frequency(curr_channel, 
> NL80211_BAND_2GHZ);
>  
> - if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> + if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {

Nah...  You're just introducing bugs here.  Please be more careful.

regards,
dan carpenter

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


Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

2017-03-21 Thread Michael Zoran
On Tue, 2017-03-21 at 12:09 -0700, Michael Zoran wrote:
> On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
> > Michael Zoran  writes:
> > 
> > > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > > > Michael Zoran  writes:
> > > > 
> > > > > > > Since the API is completely documented, I see no reason
> > > > > > > we
> > > > > > > or
> > > > > > > anybody
> > > > > > > couldn't essentially rewrite the driver while it's in
> > > > > > > staging.  I
> > > > > > > just
> > > > > > > think it would be best for everyone if the new version
> > > > > > > was
> > > > > > > a
> > > > > > > drop
> > > > > > > in
> > > > > > > replacement for the original version.  Essential an
> > > > > > > enhancement
> > > > > > > rather
> > > > > > > then a competitor.
> > > > > > 
> > > > > > I think my comments weren't fundamental changes, but you
> > > > > > surely
> > > > > > mean
> > > > > > the devicetree ABI? I like to see this driver ASAP out of
> > > > > > staging
> > > > > > and
> > > > > > i'm not interested to maintain 2 functional identical
> > > > > > driver
> > > > > > only
> > > > > > to
> > > > > > keep compability with the Foundation tree. Currently i'm
> > > > > > afraid
> > > > > > that
> > > > > > we build up many drivers in staging, which need a complete
> > > > > > rewrite
> > > > > > later if they should come out of staging. It would be nice
> > > > > > if
> > > > > > we
> > > > > > could avoid the situation we have with the thermal driver.
> > > > > > 
> > > > > > Stefan
> > > > > 
> > > > > The API I'm talking about here is the mailbox API that is
> > > > > used
> > > > > to
> > > > > talk
> > > > > to the firmware.  The numbers and structures to pass are
> > > > > documented. 
> > > > > Nothing prevents anybody from rewriting this driver and
> > > > > submitting
> > > > > it
> > > > > to the appropriate subsystems.  It's certainly small enough.
> > > > > 
> > > > > If you really want working thermal or cpu speed drivers
> > > > > today,
> > > > > nothing
> > > > > stops anybody from submitting the downstream drivers after
> > > > > doing
> > > > > some
> > > > > minor touchups and submitting them to staging.  That would at
> > > > > least
> > > > > get
> > > > > things working while people argue about what the correct DT
> > > > > nodes
> > > > > should be.
> > > > > 
> > > > > I would also like to point out that the RPI 3 has been out
> > > > > for
> > > > > over
> > > > > a
> > > > > year and nobody has been able to get working video out of it
> > > > > through
> > > > > VC4 on a mainline tree.  At least until now.  So I'm not sure
> > > > > the
> > > > > best
> > > > > way to go is for the expander driver to go under the GPIO
> > > > > subtree.
> > > > 
> > > > Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to
> > > > probe
> > > > for
> > > > connection when the GPIO line isn't present in the DT.
> > > 
> > > Just a FYI, Eric Anholt has offically announced support for VC4
> > > for
> > > HDMI on mainline Linus build without any support from the
> > > expander
> > > on
> > > the RPI 3.  
> > > 
> > > Sounds like this particular driver isn't needed then, correct?
> > 
> > That's the HDMI audio that just landed.  HDMI has been working on
> > the
> > pi3 since 9d44a8d530e8cc97d71ffcbc0ff3b5553c62.
> > 
> > In the absence of a GPIO line for hotplug detect, we use DDC, which
> > is
> > slower and throws an error in dmesg when the probe happens but HDMI
> > is
> > disconnected.  As such, having a GPIO driver would improve things
> > for
> > people.
> 
> 
> Would a non DT based solution be outside the realm of
> possibilities?  I
> wrote a very simple library that emulates vcgencmd from the kernel. 
> One of the commands for vcgencmd is to query the HDMI hotplug
> status. 
> It's sort of semi documentated on the web.  The vcgencmd library
> works,
> but I haven't tested if the virtualized hotplug info from the command
> output is correct in all cases.
> 
> What I'm thinking is I could package this in a single file library
> that
> would get put in upstream, but it would only support 1 command only.
> To
> query the virtual hotplug status.
> 
> The only thing is you would need to take a dependency from VC4 to
> vchiq/vc04_services.  It would get VC4 working better on upstream,
> but
> it would mean taking a dependency from VC4 to vc04_services and the
> stagging tree(with all that imples).
> 
> I think this may be a better solution then arguing with the DT folks
> on
> this expander driver that isn't being directly controlled.
> 
> What do you think?

Just to clarify, this would be a soft dependency.  We would have the
function in place on all RPI but it would only actually do something if
both vc04_services is in the .config AND vc04_services gets put into
the DT on the platforms that it would benefit the most at this time(The
RPI3).

The idea is that you would only use the function in the cases that you
don't have a better way to get the 

Re: [PATCH v7] staging: adis16060_core: Replace mlock with buf_lock and refactor code

2017-03-21 Thread Jonathan Cameron
On 20/03/17 12:53, simran singhal wrote:
> The IIO subsystem is redefining iio_dev->mlock to be used by
> the IIO core only for protecting device operating mode changes.
> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
> 
> In this driver, mlock was being used to protect hardware state
> changes. Replace it with buf_lock in the devices global data.
> 
> As buf_lock protects both the adis16060_spi_write() and
> adis16060_spi_read() functions and both are always called in
> pair. First write, then read. Thus, refactor the code to have
> one single function adis16060_spi_write_than_read() which is
> protected by the existing buf_lock.
> 
> Removed nested locks as the function adis16060_read_raw call
> a lock on >buf_lock and then calls the function
> adis16060_spi_write which again tries to get hold
> of the same lock.
> 
> The locks in adis16060_read_raw are dropped and now have a
> single safe function adis16060_spi_write_than_read
> with the locks inside it being called.
> 
> Signed-off-by: simran singhal 
So close!  If part of the exercise here wasn't learning how
to get things near perfect, I'd probably have picked this up
and fixed it (whilst moaning extensively :)  Not this time
though: roll on v8.

Anyhow, see inline.  Always worth checking the patch before
emailing for anything that has snuck in and shouldn't be there.

I always find git gui particularly useful for seeing this stuff
as well.

The actual chance is correct and the patch well presented.

Jonathan
p.s. I'd probably have picked it up anyway, but there is
always a slight pause after one sends a pull request as
I will want to fast forward my tree if / when Greg pulls.
> ---
> 
>  v7:
>-Change subject
>-Remove lock from read_raw instead of from 
> function adis16060_spi_write_than_read().
>  
>  drivers/staging/iio/gyro/adis16060_core.c | 38 
> +--
>  1 file changed, 11 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
> b/drivers/staging/iio/gyro/adis16060_core.c
> index c9d46e7..193587c 100644
> --- a/drivers/staging/iio/gyro/adis16060_core.c
> +++ b/drivers/staging/iio/gyro/adis16060_core.c
> @@ -40,25 +40,18 @@ struct adis16060_state {
>  
>  static struct iio_dev *adis16060_iio_dev;
>  
> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
> +  u8 conf, u16 *val)
>  {
>   int ret;
>   struct adis16060_state *st = iio_priv(indio_dev);
>  
>   mutex_lock(>buf_lock);
> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>   ret = spi_write(st->us_w, st->buf, 3);
> - mutex_unlock(>buf_lock);
> -
> - return ret;
> -}
> -
> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
> -{
> - int ret;
> - struct adis16060_state *st = iio_priv(indio_dev);
>  
> - mutex_lock(>buf_lock);
> + if (ret < 0)
> + return ret;
>  
>   ret = spi_read(st->us_r, st->buf, 3);
>  
> @@ -69,8 +62,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
> u16 *val)
>*/
>   if (!ret)
>   *val = ((st->buf[0] & 0x3) << 12) |
> - (st->buf[1] << 4) |
> - ((st->buf[2] >> 4) & 0xF);
> +  (st->buf[1] << 4) |
> +  ((st->buf[2] >> 4) & 0xF);
Why the above change? Not related to everything else in the patch
(looks like an editor thinking it knows better on alignment to me!)
>   mutex_unlock(>buf_lock);
>  
>   return ret;
> @@ -83,20 +76,15 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>  {
>   u16 tval = 0;
>   int ret;
> + struct adis16060_state *st = iio_priv(indio_dev);
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - /* Take the iio_dev status lock */
> - mutex_lock(_dev->mlock);
> - ret = adis16060_spi_write(indio_dev, chan->address);
> + ret = adis16060_spi_write_than_read(indio_dev,
> + chan->address, );
>   if (ret < 0)
> - goto out_unlock;
> + return ret;
>  
> - ret = adis16060_spi_read(indio_dev, );
> - if (ret < 0)
> - goto out_unlock;
> -
> - mutex_unlock(_dev->mlock);
>   *val = tval;
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_OFFSET:
> @@ -110,10 +98,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>   }
>  
>   return -EINVAL;
> -
> -out_unlock:
> - mutex_unlock(_dev->mlock);
> - return ret;
>  }
>  
>  static const struct iio_info adis16060_info = {
> 

___
devel mailing list
de...@linuxdriverproject.org

Re: [PATCH v2 0/2] Remove Typedefs.

2017-03-21 Thread Jonathan Cameron
On 21/03/17 15:06, Arushi Singhal wrote:
> Typedefs are removed in sm750fb driver.
> 
> Arushi Singhal (2):
>   staging: sm750fb: Remove typedef from "typedef struct _mode_parameter_t"
>   staging: sm750fb: Remove typedef from "typedef enum _spolarity_t"
> 
>  drivers/staging/sm750fb/ddk750_mode.c |  8 +---
>  drivers/staging/sm750fb/ddk750_mode.h | 19 ---
>  drivers/staging/sm750fb/sm750_hw.c|  2 +-
>  3 files changed, 14 insertions(+), 15 deletions(-)
> 
Please be careful to only cc linux-iio for patches with an IIO component...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread Jonathan Cameron
On 21/03/17 15:05, SIMRAN SINGHAL wrote:
> On Tue, Mar 21, 2017 at 8:01 PM, kbuild test robot <l...@intel.com> wrote:
>> Hi simran,
>>
>> [auto build test WARNING on iio/togreg]
>> [also build test WARNING on v4.11-rc3 next-20170321]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/simran-singhal/staging-Use-buf_lock-instead-of-mlock-and-Refactor-code/20170321-213956
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
>> config: x86_64-randconfig-x016-201712 (attached as .config)
>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All warnings (new ones prefixed by >>):
>>
> I am not getting any error, and I have already sent the v7 of this patch
> please check out that:
> https://groups.google.com/forum/#!topic/outreachy-kernel/5uz6IpcOpMA
> 
> 
>>In file included from include/uapi/linux/stddef.h:1:0,
>> from include/linux/stddef.h:4,
>> from include/uapi/linux/posix_types.h:4,
>> from include/uapi/linux/types.h:13,
>> from include/linux/types.h:5,
>> from include/linux/list.h:4,
>> from include/linux/module.h:9,
>> from drivers/staging/iio/gyro/adis16060_core.c:9:
>>drivers/staging/iio/gyro/adis16060_core.c: In function 
>> 'adis16060_read_raw':
>>include/linux/compiler.h:149:2: warning: this 'if' clause does not 
>> guard... [-Wmisleading-indentation]
>>  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>>  ^
>>include/linux/compiler.h:147:23: note: in expansion of macro '__trace_if'
>> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>>   ^~
>>>> drivers/staging/iio/gyro/adis16060_core.c:89:3: note: in expansion of 
>>>> macro 'if'
>>   if (ret < 0)
>>   ^~
>>drivers/staging/iio/gyro/adis16060_core.c:91:4: note: ...this statement, 
>> but the latter is misleadingly indented as if it is guarded by the 'if'
>>return ret;
>>^~
All this rather complex bit of magic is saying, is that the indenting on the 
return
is probably wrong.  Which it isn't, but there is something else wrong that
would make the autobuilder think so.  No brackets around the two lines that
should run if the if statement is true!

This is the autobuilder magic running directly on patches on the mailing list.
I force the equivalent tests by pushing patches out first in a testing branch,
so that this stuff can be fixed before patches go into a non rebasing branch
(fixing them there makes for a very messy history).

If the autobuilder bots have spare cycles, they tend to start running patches
off the mailing list - hence magic like this one, though the results can be
hard to read sometimes!

Jonathan
>>
>> vim +/if +89 drivers/staging/iio/gyro/adis16060_core.c
>>
>> e071f6b8 Barry Song   2010-10-27   3   *
>> e071f6b8 Barry Song   2010-10-27   4   * Copyright 2010 Analog Devices 
>> Inc.
>> e071f6b8 Barry Song   2010-10-27   5   *
>> e071f6b8 Barry Song   2010-10-27   6   * Licensed under the GPL-2 or 
>> later.
>> e071f6b8 Barry Song   2010-10-27   7   */
>> e071f6b8 Barry Song   2010-10-27   8
>> 45296236 Paul Gortmaker   2011-08-30  @9  #include 
>> e071f6b8 Barry Song   2010-10-27  10  #include 
>> e071f6b8 Barry Song   2010-10-27  11  #include 
>> e071f6b8 Barry Song   2010-10-27  12  #include 
>> e071f6b8 Barry Song   2010-10-27  13  #include 
>> e071f6b8 Barry Song   2010-10-27  14  #include 
>> e071f6b8 Barry Song   2010-10-27  15  #include 
>> e071f6b8 Barry Song   2010-10-27  16  #include 
>> 14f98326 Jonathan Cameron 2011-02-28  17
>> 06458e27 Jonathan Cameron 2012-04-25  18  #include 
>> 06458e27 Jonathan Cameron 2012-04-25  19  #include 
>> e071f6b8 Barry Song   2010-10-27  20
>> 14f98326 Jonathan Cameron 2011-02-28  21  #define ADIS16060_GYRO 
>>0x20 /* Measure Angular Rate (Gyro) */
>> 14f98326 Jonathan Cameron 2011-02-28  22  #define ADIS16060_TEMP_OUT0x10 
>> /* Measure Temperature */
>> 14f98326 Jonathan Cameron 2011-02-28  23  #define ADIS16060_AIN2 
>>0x80 /* Measure AIN2 */
>> 14f98326 Jonathan Cameron 2011-02-28  24  #define ADIS16060_AIN1 
>>   

[PATCH] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Prasant Jalan
This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

2017-03-21 Thread Michael Zoran
On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
> Michael Zoran  writes:
> 
> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > > Michael Zoran  writes:
> > > 
> > > > > > Since the API is completely documented, I see no reason we
> > > > > > or
> > > > > > anybody
> > > > > > couldn't essentially rewrite the driver while it's in
> > > > > > staging.  I
> > > > > > just
> > > > > > think it would be best for everyone if the new version was
> > > > > > a
> > > > > > drop
> > > > > > in
> > > > > > replacement for the original version.  Essential an
> > > > > > enhancement
> > > > > > rather
> > > > > > then a competitor.
> > > > > 
> > > > > I think my comments weren't fundamental changes, but you
> > > > > surely
> > > > > mean
> > > > > the devicetree ABI? I like to see this driver ASAP out of
> > > > > staging
> > > > > and
> > > > > i'm not interested to maintain 2 functional identical driver
> > > > > only
> > > > > to
> > > > > keep compability with the Foundation tree. Currently i'm
> > > > > afraid
> > > > > that
> > > > > we build up many drivers in staging, which need a complete
> > > > > rewrite
> > > > > later if they should come out of staging. It would be nice if
> > > > > we
> > > > > could avoid the situation we have with the thermal driver.
> > > > > 
> > > > > Stefan
> > > > 
> > > > The API I'm talking about here is the mailbox API that is used
> > > > to
> > > > talk
> > > > to the firmware.  The numbers and structures to pass are
> > > > documented. 
> > > > Nothing prevents anybody from rewriting this driver and
> > > > submitting
> > > > it
> > > > to the appropriate subsystems.  It's certainly small enough.
> > > > 
> > > > If you really want working thermal or cpu speed drivers today,
> > > > nothing
> > > > stops anybody from submitting the downstream drivers after
> > > > doing
> > > > some
> > > > minor touchups and submitting them to staging.  That would at
> > > > least
> > > > get
> > > > things working while people argue about what the correct DT
> > > > nodes
> > > > should be.
> > > > 
> > > > I would also like to point out that the RPI 3 has been out for
> > > > over
> > > > a
> > > > year and nobody has been able to get working video out of it
> > > > through
> > > > VC4 on a mainline tree.  At least until now.  So I'm not sure
> > > > the
> > > > best
> > > > way to go is for the expander driver to go under the GPIO
> > > > subtree.
> > > 
> > > Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe
> > > for
> > > connection when the GPIO line isn't present in the DT.
> > 
> > Just a FYI, Eric Anholt has offically announced support for VC4 for
> > HDMI on mainline Linus build without any support from the expander
> > on
> > the RPI 3.  
> > 
> > Sounds like this particular driver isn't needed then, correct?
> 
> That's the HDMI audio that just landed.  HDMI has been working on the
> pi3 since 9d44a8d530e8cc97d71ffcbc0ff3b5553c62.
> 
> In the absence of a GPIO line for hotplug detect, we use DDC, which
> is
> slower and throws an error in dmesg when the probe happens but HDMI
> is
> disconnected.  As such, having a GPIO driver would improve things for
> people.


Would a non DT based solution be outside the realm of possibilities?  I
wrote a very simple library that emulates vcgencmd from the kernel. 
One of the commands for vcgencmd is to query the HDMI hotplug status. 
It's sort of semi documentated on the web.  The vcgencmd library works,
but I haven't tested if the virtualized hotplug info from the command
output is correct in all cases.

What I'm thinking is I could package this in a single file library that
would get put in upstream, but it would only support 1 command only. To
query the virtual hotplug status.

The only thing is you would need to take a dependency from VC4 to
vchiq/vc04_services.  It would get VC4 working better on upstream, but
it would mean taking a dependency from VC4 to vc04_services and the
stagging tree(with all that imples).

I think this may be a better solution then arguing with the DT folks on
this expander driver that isn't being directly controlled.

What do you think?

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


[PATCH v2] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Prasant Jalan
This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


Re: [Outreachy kernel] [PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

2017-03-21 Thread Alison Schofield
On Tue, Mar 21, 2017 at 11:33:54PM +0530, simran singhal wrote:
> The patch series replaces mlock with a private lock for driver ad9834 and
> Fix coding style issues related to white spaces.

Hi Simran,  

I'm getting lost.  Patchset Subject Line needs subsystem and driver.
The comment above says ad9834 but the patches below say ade7753.

Can we drive adis16060 through ACK and then come back to this one?
(ie. applyling lessons learned)

thanks,
alisons
> 
> v3:
>   -Using new private "lock" instead of using "buf_lock"
>as it can cause deadlock.
>   -Sending it as a series of two patches.
> 
> v2:
>   -Using the existing buf_lock instead of lock.
>
> 
> simran singhal (2):
>   staging: iio: ade7753: Remove trailing whitespaces
>   staging: iio: ade7753: Replace mlock with driver private lock
> 
>  drivers/staging/iio/meter/ade7753.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1490119436-20042-1-git-send-email-singhalsimran0%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Greg KH
On Wed, Mar 22, 2017 at 12:10:50AM +0530, Prasant Jalan wrote:
> This patch replaces spaces with tabs for indentation as per kernel
> coding standards.
> 
> Signed-off-by: Prasant Jalan 
> ---
>  drivers/staging/vt6656/rf.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Didn't you just send this same patch?  If this is a 'v2' patch, please
read Documentation/SubmittingPatches for how to properly do that (hint,
you need more info here...)

thanks,

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


Re: [PATCH] Staging: ks7010 - fixed style block comments

2017-03-21 Thread Greg KH
On Wed, Mar 22, 2017 at 07:29:50AM +1300, Derek Robson wrote:
> On Tue, Mar 21, 2017 at 08:56:25AM +0100, Greg KH wrote:
> > On Sun, Mar 19, 2017 at 01:07:17PM +1300, Derek Robson wrote:
> > > Fixed style of all block comments across whole driver
> > > Found by checkpatch
> > > 
> > > Signed-off-by: Derek Robson 
> > > ---
> > >  drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
> > >  drivers/staging/ks7010/ks_hostif.h   | 35 +-
> > >  drivers/staging/ks7010/ks_wlan.h |  3 ++-
> > >  drivers/staging/ks7010/ks_wlan_net.c | 41 
> > > +++-
> > >  4 files changed, 55 insertions(+), 27 deletions(-)
> > 
> > This patch doesn't apply to my tree at all :(
> >
> 
> Am I working from the right/best tree for driver/staging?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

What branch did you use?  You should use staging-next, or worse case,
staging-testing.  Don't use 'master', as that tracks Linus's tree and is
usually quite old.

thanks,

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


[PATCH] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Prasant Jalan
This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread SIMRAN SINGHAL
On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield  wrote:
> On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:
>
> Hi Simran,
>
> I going to ask for a v7 without looking at the code ;)
> Subject line needs subsystem and driver.
> Subject and log message can be improved.
>
>> The IIO subsystem is redefining iio_dev->mlock to be used by
>> the IIO core only for protecting device operating mode changes.
>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>>
>> In this driver, mlock was being used to protect hardware state
>> changes. Replace it with buf_lock in the devices global data.
>^^^ this was not done
>>
>> As buf_lock protects both the adis16060_spi_write() and
>> adis16060_spi_read() functions and both are always called in
>> pair. First write, then read. Thus, refactor the code to have
>> one single function adis16060_spi_write_than_read() which is
>> protected by the existing buf_lock.
> This was done.  So, you were able to obsolete the need for mlock
> by creating the paired function.

I am still using mlock but now locking it and performing both write and
read and than unlocking.

So, now have a single safe function.

>
>>
>> Removed nested locks as the function adis16060_read_raw call
>> a lock on >buf_lock and then calls the function
>> adis16060_spi_write which again tries to get hold
>> of the same lock.
>  this was not done.  Yes, you avoided nested locks through
> proper coding, but we don't want to give the impression in the
> log message that there was a pre-existing nested lock issue.
>
> I did checkpatch & compile it...but looked no further yet.
>
> alisons
>>
>> Signed-off-by: simran singhal 
>> ---
>>
>>  v6:
>>-Change commit message
>>-Remove nested lock
>>
>>  drivers/staging/iio/gyro/adis16060_core.c | 40 
>> ++-
>>  1 file changed, 13 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index c9d46e7..1c6de46 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -40,25 +40,17 @@ struct adis16060_state {
>>
>>  static struct iio_dev *adis16060_iio_dev;
>>
>> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
>> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
>> +  u8 conf, u16 *val)
>>  {
>>   int ret;
>>   struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
>> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>>   ret = spi_write(st->us_w, st->buf, 3);
>> - mutex_unlock(>buf_lock);
>> -
>> - return ret;
>> -}
>> -
>> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
>> -{
>> - int ret;
>> - struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> + if (ret < 0)
>> + return ret;
>>
>>   ret = spi_read(st->us_r, st->buf, 3);
>>
>> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
>> u16 *val)
>>*/
>>   if (!ret)
>>   *val = ((st->buf[0] & 0x3) << 12) |
>> - (st->buf[1] << 4) |
>> - ((st->buf[2] >> 4) & 0xF);
>> +  (st->buf[1] << 4) |
>> +  ((st->buf[2] >> 4) & 0xF);
>>   mutex_unlock(>buf_lock);
>>
>>   return ret;
>> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  {
>>   u16 tval = 0;
>>   int ret;
>> + struct adis16060_state *st = iio_priv(indio_dev);
>>
>>   switch (mask) {
>>   case IIO_CHAN_INFO_RAW:
>>   /* Take the iio_dev status lock */
>> - mutex_lock(_dev->mlock);
>> - ret = adis16060_spi_write(indio_dev, chan->address);
>> + mutex_lock(>buf_lock);
>> + ret = adis16060_spi_write_than_read(indio_dev,
>> + chan->address, );
>> + mutex_unlock(>buf_lock);
>>   if (ret < 0)
>> - goto out_unlock;
>> + return ret;
>>
>> - ret = adis16060_spi_read(indio_dev, );
>> - if (ret < 0)
>> - goto out_unlock;
>> -
>> - mutex_unlock(_dev->mlock);
>>   *val = tval;
>>   return IIO_VAL_INT;
>>   case IIO_CHAN_INFO_OFFSET:
>> @@ -110,10 +100,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>   }
>>
>>   return -EINVAL;
>> -
>> -out_unlock:
>> - mutex_unlock(_dev->mlock);
>> - return ret;
>>  }
>>
>>  static const struct iio_info adis16060_info = {
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> 

Re: [PATCH] drivers: staging: vt6656: fxed coding style errors

2017-03-21 Thread Greg KH
On Tue, Mar 21, 2017 at 10:25:40PM +0530, Prasant Jalan wrote:
> This patch replaces spaces with tabs for indentation as per kernel
> coding standards.
> 
> Signed-off-by: Prasant Jalan 
> ---
>  drivers/staging/vt6656/rf.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 068c1c8..f69bced 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr1, length1);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
> - MESSAGE_REQUEST_RF_INIT, length1, array);
> + MESSAGE_REQUEST_RF_INIT, length1, array);
>  
>   /* Channel Table 0 */
>   value = 0;
> @@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr2, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH0, length, array);
> + value, MESSAGE_REQUEST_RF_CH0, length, array);
>  
>   length2 -= length;
>   value += length;
> @@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr3, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH1, length, array);
> + value, MESSAGE_REQUEST_RF_CH1, length, array);
>  
>   length3 -= length;
>   value += length;
> @@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>  
>   /* Init Table 2 */
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - 0, MESSAGE_REQUEST_RF_INIT2, length1, array);
> + 0, MESSAGE_REQUEST_RF_INIT2, length1, array);
>  
>   /* Channel Table 0 */
>   value = 0;
> @@ -937,7 +937,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr2, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH2, length, 
> array);
> + value, MESSAGE_REQUEST_RF_CH2, length, array);

Why make this last change?  It's now not indented properly :(

thanks,

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


Re: [PATCH] Staging: ks7010 - fixed style block comments

2017-03-21 Thread Derek Robson
On Tue, Mar 21, 2017 at 08:56:25AM +0100, Greg KH wrote:
> On Sun, Mar 19, 2017 at 01:07:17PM +1300, Derek Robson wrote:
> > Fixed style of all block comments across whole driver
> > Found by checkpatch
> > 
> > Signed-off-by: Derek Robson 
> > ---
> >  drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
> >  drivers/staging/ks7010/ks_hostif.h   | 35 +-
> >  drivers/staging/ks7010/ks_wlan.h |  3 ++-
> >  drivers/staging/ks7010/ks_wlan_net.c | 41 
> > +++-
> >  4 files changed, 55 insertions(+), 27 deletions(-)
> 
> This patch doesn't apply to my tree at all :(
>

Am I working from the right/best tree for driver/staging?

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

Thanks for helping the new guy :-)



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


Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Jonathan Cameron


On 21 March 2017 17:27:02 GMT+00:00, Julia Lawall  wrote:
>
>
>On Tue, 21 Mar 2017, Arushi Singhal wrote:
>
>>
>>
>> On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield
>
>> wrote:
>>   On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
>>   >
>>   >
>>   > On Tue, 21 Mar 2017, Arushi Singhal wrote:
>>   >
>>   > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield
>>   
>>   > > wrote:
>>   > >       On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi
>>   Singhal wrote:
>>   > >       > Patchseries of IIO coding tasks
>>   > >
>>   > >       This wouldn't be a patchset.  Although they touch the
>>   same
>>   > >       driver, the changes are unrelated.  See more below...
>>   > >
>>   > > This I have send as a Patchset because as you have
>mentioned
>>   below that the
>>   > > [PATCH 2/2] was already done before by someone but I think
>>   so it is not yet
>>   > > applied in the Greg's tree yet.So I have done both the
>>   changes and as they
>>   > > should be applied one after other so that's why I have send
>>   them as
>>   > > Patchset.
>>   >
>>   > For the IIO patches, it is better to work on the IIO tree,
>not
>>   Greg's.
>>   > Greg manages staging, not IIO.  The IIO patches should appear
>>   in Greg's
>>   > tree eventually.
>>   >
>>   > julia
>>
>>   We didn't direct applicants to create an iio tree.  At this
>>   point,
>>   it seems more than is necessary.  They can follow the
>directions
>>   in the
>>   task descriptions and avoid the collisions.
>>
>>   Of course, they are welcome to create a tree to iio/testing.
>>
>>   (IMHO it's more overhead/busy work and maybe not the best use
>>   of time in the home stretch of the application period.)
>>
>>   alisons
>>
>>
>> Hi Alison
>> As you have mentioned that my [PATCH 2/2] is already being done
>someone. So
>> how can I make the changes of [PATCH 1/2] on top of it as [PATCH 2/2]
>is not
>> yet applied on the staging tree.
>
>Make a patch that applies to the current state of the IIO tree.  Just
>clone that one like you cloned the staging one.
>
>julia
>
Slight amendment,. Normally would be the togreg branch which doesn't rebase.

With all the current churn might be best to use the testing branch and i will 
fix up any issues if i
 have to rebase as result of build tests.

Will.send Greg a pull later anyway, so should be less difference after he pulls 
that.

J
>> Please suggest me.
>> Thanks
>> Arushi
>>   >
>>   > >       >
>>   > >       > Arushi Singhal (2):
>>   > >       >   staging: ad7759: Replace mlock with driver
>private
>>   lock
>>   > >
>>   > >       This one is already been submitted.  If you have a v2
>>   for it,
>>   > >       then v2
>>   > >       the original patch.
>>   > >
>>   > > Is it submitted by me only before? And this is not the v2.
>>   > > I have just resed it.
>>   > >       >   staging: iio: ade7759: Move header content to
>>   implementation
>>   > >       file
>>   > >
>>   > >       This patch is done and applied already.  See the
>>   Coding Task #1
>>   > >       notes
>>   > >       in the IIO Tasks page.
>>   > >
>>   > > Not at applied I think so.
>>   > > Thanks
>>   > > Arushi
>>   > >
>>   > >       alisons
>>   > >
>>   > >       >
>>   > >       >  drivers/staging/iio/meter/ade7759.c   | 56
>>   > >       +--
>>   > >       >  drivers/staging/iio/meter/ade7759.h   | 53
>>   > >       -
>>   > >       >  2 files changed, 54 insertions(+), 57 deletions(-)
>>   > >       >
>>   > >       > --
>>   > >       > 2.11.0
>>   > >       >
>>   > > > --
>>   > > > You received this message because you are subscribed to
>>   the Google
>>   > > Groups "outreachy-kernel" group.
>>   > > > To unsubscribe from this group and stop receiving emails
>>   from it,
>>   > > send an email to
>>   outreachy-kernel+unsubscr...@googlegroups.com.
>>   > > > To post to this group, send email to
>>   > > outreachy-ker...@googlegroups.com.
>>   > > > To view this discussion on the
>webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737
>>   -1-ar
>>   > > ushisinghal19971997%40gmail.com.
>>   > > > For more options, visit
>>   https://groups.google.com/d/optout.
>>   > >
>>   > >
>>   > > --
>>   > > You received this message because you are subscribed to the
>>   Google Groups
>>   > > "outreachy-kernel" group.
>>   > > To unsubscribe from this group and stop receiving emails
>>   from it, send an
>>   > > email to 

RE: [PATCH v2] scsi: storvsc: Add support for FC rport.

2017-03-21 Thread KY Srinivasan


> -Original Message-
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Friday, March 17, 2017 8:18 AM
> To: KY Srinivasan ; h...@infradead.org; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: step...@networkplumber.org; dan.carpen...@oracle.com;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: [PATCH v2] scsi: storvsc: Add support for FC rport.
> 
> Included in the current storvsc driver for Hyper-V is the ability
> to access luns on an FC fabric via a virtualized fiber channel
> adapter exposed by the Hyper-V host. The driver also attaches to
> the FC transport to allow host and port names to be published under
> /sys/class/fc_host/hostX. Current customer tools running on the VM
> require that these names be available in the well known standard
> location under fc_host/hostX.
> 
> A problem arose when attaching to the FC transport. The scsi_scan
> code attempts to call fc_user_scan which has basically become a no-op
> due to the fact that the virtualized FC device does not expose rports.
> At this point you cannot refresh the scsi bus after mapping or unmapping
> luns on the SAN without a reboot of the VM.
> 
> This patch stubs in an rport per fc_host in storvsc so that the
> requirement of a defined rport is now met within the fc_transport and
> echo "- - -" > /sys/class/scsi_host/hostX/scan now works.
> 
> Signed-off-by: Cathy Avery 

Acked-by: K. Y. Srinivasan 
> ---
> Changes since v1:
> - Fix fc_rport_identifiers init [Stephen Hemminger]
> - Better error checking
> ---
>  drivers/scsi/storvsc_drv.c | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 638e5f4..37646d1 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -478,6 +478,9 @@ struct storvsc_device {
>*/
>   u64 node_name;
>   u64 port_name;
> +#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
> + struct fc_rport *rport;
> +#endif
>  };
> 
>  struct hv_host_device {
> @@ -1816,19 +1819,27 @@ static int storvsc_probe(struct hv_device
> *device,
>   target = (device->dev_instance.b[5] << 8 |
>device->dev_instance.b[4]);
>   ret = scsi_add_device(host, 0, target, 0);
> - if (ret) {
> - scsi_remove_host(host);
> - goto err_out2;
> - }
> + if (ret)
> + goto err_out3;
>   }
>  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
>   if (host->transportt == fc_transport_template) {
> + struct fc_rport_identifiers ids = {
> + .roles = FC_PORT_ROLE_FCP_TARGET,
> + };
> +
>   fc_host_node_name(host) = stor_device->node_name;
>   fc_host_port_name(host) = stor_device->port_name;
> + stor_device->rport = fc_remote_port_add(host, 0, );
> + if (!stor_device->rport)
> + goto err_out3;
>   }
>  #endif
>   return 0;
> 
> +err_out3:
> + scsi_remove_host(host);
> +
>  err_out2:
>   /*
>* Once we have connected with the host, we would need to
> @@ -1854,8 +1865,10 @@ static int storvsc_remove(struct hv_device *dev)
>   struct Scsi_Host *host = stor_device->host;
> 
>  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
> - if (host->transportt == fc_transport_template)
> + if (host->transportt == fc_transport_template) {
> + fc_remote_port_delete(stor_device->rport);
>   fc_remove_host(host);
> + }
>  #endif
>   scsi_remove_host(host);
>   storvsc_dev_remove(dev);
> --
> 2.5.0

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


[PATCH v3 2/2] staging: iio: ade7753: Replace mlock with driver private lock

2017-03-21 Thread simran singhal
The IIO subsystem is redefining iio_dev->mlock to be used by
the IIO core only for protecting device operating mode changes.
ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.

In this driver, mlock was being used to protect hardware state
changes.  Replace it with a lock in the devices global data.

Signed-off-by: simran singhal 
---
 drivers/staging/iio/meter/ade7753.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7753.c 
b/drivers/staging/iio/meter/ade7753.c
index b71fbd3..9674e05 100644
--- a/drivers/staging/iio/meter/ade7753.c
+++ b/drivers/staging/iio/meter/ade7753.c
@@ -80,11 +80,13 @@
  * @us: actual spi_device
  * @tx: transmit buffer
  * @rx: receive buffer
+ * @lock:   protect sensor state
  * @buf_lock:   mutex to protect tx and rx
  **/
 struct ade7753_state {
struct spi_device   *us;
struct mutexbuf_lock;
+   struct mutexlock;  /* protect sensor state */
u8  tx[ADE7753_MAX_TX] cacheline_aligned;
u8  rx[ADE7753_MAX_RX];
 };
@@ -484,7 +486,7 @@ static ssize_t ade7753_write_frequency(struct device *dev,
if (!val)
return -EINVAL;
 
-   mutex_lock(_dev->mlock);
+   mutex_lock(>lock);
 
t = 27900 / val;
if (t > 0)
@@ -505,7 +507,7 @@ static ssize_t ade7753_write_frequency(struct device *dev,
ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg);
 
 out:
-   mutex_unlock(_dev->mlock);
+   mutex_unlock(>lock);
 
return ret ? ret : len;
 }
-- 
2.7.4

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


[PATCH v3 1/2] staging: iio: ade7753: Remove trailing whitespaces

2017-03-21 Thread simran singhal
This patch removes trailing whitespaces in order to follow the Linux
coding style.

Signed-off-by: simran singhal 
---
 drivers/staging/iio/meter/ade7753.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7753.c 
b/drivers/staging/iio/meter/ade7753.c
index dfd8b71..b71fbd3 100644
--- a/drivers/staging/iio/meter/ade7753.c
+++ b/drivers/staging/iio/meter/ade7753.c
@@ -83,10 +83,10 @@
  * @buf_lock:   mutex to protect tx and rx
  **/
 struct ade7753_state {
-   struct spi_device   *us;
-   struct mutexbuf_lock;
-   u8  tx[ADE7753_MAX_TX] 
cacheline_aligned;
-   u8  rx[ADE7753_MAX_RX];
+   struct spi_device   *us;
+   struct mutexbuf_lock;
+   u8  tx[ADE7753_MAX_TX] cacheline_aligned;
+   u8  rx[ADE7753_MAX_RX];
 };
 
 static int ade7753_spi_write_reg_8(struct device *dev,
-- 
2.7.4

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


[PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

2017-03-21 Thread simran singhal
The patch series replaces mlock with a private lock for driver ad9834 and
Fix coding style issues related to white spaces.

v3:
  -Using new private "lock" instead of using "buf_lock"
   as it can cause deadlock.
  -Sending it as a series of two patches.

v2:
  -Using the existing buf_lock instead of lock.
   

simran singhal (2):
  staging: iio: ade7753: Remove trailing whitespaces
  staging: iio: ade7753: Replace mlock with driver private lock

 drivers/staging/iio/meter/ade7753.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

-- 
2.7.4

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


Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread Alison Schofield
On Tue, Mar 21, 2017 at 10:34:01PM +0530, SIMRAN SINGHAL wrote:
> On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield  
> wrote:
> > On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:
> >
> > Hi Simran,
> >
> > I going to ask for a v7 without looking at the code ;)
> > Subject line needs subsystem and driver.
> > Subject and log message can be improved.
> 
> Hi Alison,
> I have already sent v7 with changed subject.

Simran,
I see v7.  Needs subsystem (iio) and to nitpick, driver name
is "adis16060" ;) Other comments still apply. 
Please append all version histories below the --- for review.
v7:
v6:
.
.
v2: 
thanks,
alisons
> 
> >
> >> The IIO subsystem is redefining iio_dev->mlock to be used by
> >> the IIO core only for protecting device operating mode changes.
> >> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
> >>
> >> In this driver, mlock was being used to protect hardware state
> >> changes. Replace it with buf_lock in the devices global data.
> >^^^ this was not done
> >>
> >> As buf_lock protects both the adis16060_spi_write() and
> >> adis16060_spi_read() functions and both are always called in
> >> pair. First write, then read. Thus, refactor the code to have
> >> one single function adis16060_spi_write_than_read() which is
> >> protected by the existing buf_lock.
> > This was done.  So, you were able to obsolete the need for mlock
> > by creating the paired function.
> >
> >>
> >> Removed nested locks as the function adis16060_read_raw call
> >> a lock on >buf_lock and then calls the function
> >> adis16060_spi_write which again tries to get hold
> >> of the same lock.
> >  this was not done.  Yes, you avoided nested locks through
> > proper coding, but we don't want to give the impression in the
> > log message that there was a pre-existing nested lock issue.
> >
> > I did checkpatch & compile it...but looked no further yet.
> >
> > alisons
> >>
> >> Signed-off-by: simran singhal 
> >> ---
> >>
> >>  v6:
> >>-Change commit message
> >>-Remove nested lock
> >>
> >>  drivers/staging/iio/gyro/adis16060_core.c | 40 
> >> ++-
> >>  1 file changed, 13 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
> >> b/drivers/staging/iio/gyro/adis16060_core.c
> >> index c9d46e7..1c6de46 100644
> >> --- a/drivers/staging/iio/gyro/adis16060_core.c
> >> +++ b/drivers/staging/iio/gyro/adis16060_core.c
> >> @@ -40,25 +40,17 @@ struct adis16060_state {
> >>
> >>  static struct iio_dev *adis16060_iio_dev;
> >>
> >> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
> >> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
> >> +  u8 conf, u16 *val)
> >>  {
> >>   int ret;
> >>   struct adis16060_state *st = iio_priv(indio_dev);
> >>
> >> - mutex_lock(>buf_lock);
> >> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
> >> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
> >>   ret = spi_write(st->us_w, st->buf, 3);
> >> - mutex_unlock(>buf_lock);
> >> -
> >> - return ret;
> >> -}
> >> -
> >> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
> >> -{
> >> - int ret;
> >> - struct adis16060_state *st = iio_priv(indio_dev);
> >>
> >> - mutex_lock(>buf_lock);
> >> + if (ret < 0)
> >> + return ret;
> >>
> >>   ret = spi_read(st->us_r, st->buf, 3);
> >>
> >> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
> >> u16 *val)
> >>*/
> >>   if (!ret)
> >>   *val = ((st->buf[0] & 0x3) << 12) |
> >> - (st->buf[1] << 4) |
> >> - ((st->buf[2] >> 4) & 0xF);
> >> +  (st->buf[1] << 4) |
> >> +  ((st->buf[2] >> 4) & 0xF);
> >>   mutex_unlock(>buf_lock);
> >>
> >>   return ret;
> >> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev 
> >> *indio_dev,
> >>  {
> >>   u16 tval = 0;
> >>   int ret;
> >> + struct adis16060_state *st = iio_priv(indio_dev);
> >>
> >>   switch (mask) {
> >>   case IIO_CHAN_INFO_RAW:
> >>   /* Take the iio_dev status lock */
> >> - mutex_lock(_dev->mlock);
> >> - ret = adis16060_spi_write(indio_dev, chan->address);
> >> + mutex_lock(>buf_lock);
> >> + ret = adis16060_spi_write_than_read(indio_dev,
> >> + chan->address, );
> >> + mutex_unlock(>buf_lock);
> >>   if (ret < 0)
> >> - goto out_unlock;
> >> + return ret;
> >>
> >> - ret = adis16060_spi_read(indio_dev, );
> >> - if (ret < 0)
> >> - goto out_unlock;
> >> -
> >> - mutex_unlock(_dev->mlock);
> >> 

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Alison Schofield
On Tue, Mar 21, 2017 at 10:52:46PM +0530, Arushi Singhal wrote:
> On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield 
> wrote:
> 
> > On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
> > >
> > >
> > > On Tue, 21 Mar 2017, Arushi Singhal wrote:
> > >
> > > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield <
> > amsfiel...@gmail.com>
> > > > wrote:
> > > >   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> > > >   > Patchseries of IIO coding tasks
> > > >
> > > >   This wouldn't be a patchset.  Although they touch the same
> > > >   driver, the changes are unrelated.  See more below...
> > > >
> > > > This I have send as a Patchset because as you have mentioned below
> > that the
> > > > [PATCH 2/2] was already done before by someone but I think so it is
> > not yet
> > > > applied in the Greg's tree yet.So I have done both the changes and as
> > they
> > > > should be applied one after other so that's why I have send them as
> > > > Patchset.
> > >
> > > For the IIO patches, it is better to work on the IIO tree, not Greg's.
> > > Greg manages staging, not IIO.  The IIO patches should appear in Greg's
> > > tree eventually.
> > >
> > > julia
> >
> > We didn't direct applicants to create an iio tree.  At this point,
> > it seems more than is necessary.  They can follow the directions in the
> > task descriptions and avoid the collisions.
> >
> > Of course, they are welcome to create a tree to iio/testing.
> >
> > (IMHO it's more overhead/busy work and maybe not the best use
> > of time in the home stretch of the application period.)
> >
> > alisons
> >
> 
> Hi Alison
> As you have mentioned that my [PATCH 2/2] is already being done someone. So
> how can I make the changes of [PATCH 1/2] on top of it as [PATCH 2/2] is
> not yet applied on the staging tree.
> Please suggest me.
> Thanks
> Arushi

Arushi - 
I don't see anything needing to be done by you!
Your ad7759 mlock patch is awaiting review.  It's not your issue
to keep up with all changes going into the file.  When it gets applied 
will most likely merge with no merge issue at all. 
alisons
> 
> > >
> > > >   >
> > > >   > Arushi Singhal (2):
> > > >   >   staging: ad7759: Replace mlock with driver private lock
> > > >
> > > >   This one is already been submitted.  If you have a v2 for it,
> > > >   then v2
> > > >   the original patch.
> > > >
> > > > Is it submitted by me only before? And this is not the v2.
> > > > I have just resed it.
> > > >   >   staging: iio: ade7759: Move header content to implementation
> > > >   file
> > > >
> > > >   This patch is done and applied already.  See the Coding Task #1
> > > >   notes
> > > >   in the IIO Tasks page.
> > > >
> > > > Not at applied I think so.
> > > > Thanks
> > > > Arushi
> > > >
> > > >   alisons
> > > >
> > > >   >
> > > >   >  drivers/staging/iio/meter/ade7759.c   | 56
> > > >   +--
> > > >   >  drivers/staging/iio/meter/ade7759.h   | 53
> > > >   -
> > > >   >  2 files changed, 54 insertions(+), 57 deletions(-)
> > > >   >
> > > >   > --
> > > >   > 2.11.0
> > > >   >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > Groups "outreachy-kernel" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > > To post to this group, send email to
> > > > outreachy-ker...@googlegroups.com.
> > > > > To view this discussion on the web visithttps://groups.google.
> > com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> > > > ushisinghal19971997%40gmail.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "outreachy-kernel" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > an
> > > > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > To post to this group, send email to outreachy-ker...@googlegroups.com
> > .
> > > > To view this discussion on the web visithttps://groups.google.
> > com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> > > > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > >
> >
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

2017-03-21 Thread Eric Anholt
Michael Zoran  writes:

> On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> Michael Zoran  writes:
>> 
>> > > > Since the API is completely documented, I see no reason we or
>> > > > anybody
>> > > > couldn't essentially rewrite the driver while it's in
>> > > > staging.  I
>> > > > just
>> > > > think it would be best for everyone if the new version was a
>> > > > drop
>> > > > in
>> > > > replacement for the original version.  Essential an enhancement
>> > > > rather
>> > > > then a competitor.
>> > > 
>> > > I think my comments weren't fundamental changes, but you surely
>> > > mean
>> > > the devicetree ABI? I like to see this driver ASAP out of staging
>> > > and
>> > > i'm not interested to maintain 2 functional identical driver only
>> > > to
>> > > keep compability with the Foundation tree. Currently i'm afraid
>> > > that
>> > > we build up many drivers in staging, which need a complete
>> > > rewrite
>> > > later if they should come out of staging. It would be nice if we
>> > > could avoid the situation we have with the thermal driver.
>> > > 
>> > > Stefan
>> > 
>> > The API I'm talking about here is the mailbox API that is used to
>> > talk
>> > to the firmware.  The numbers and structures to pass are
>> > documented. 
>> > Nothing prevents anybody from rewriting this driver and submitting
>> > it
>> > to the appropriate subsystems.  It's certainly small enough.
>> > 
>> > If you really want working thermal or cpu speed drivers today,
>> > nothing
>> > stops anybody from submitting the downstream drivers after doing
>> > some
>> > minor touchups and submitting them to staging.  That would at least
>> > get
>> > things working while people argue about what the correct DT nodes
>> > should be.
>> > 
>> > I would also like to point out that the RPI 3 has been out for over
>> > a
>> > year and nobody has been able to get working video out of it
>> > through
>> > VC4 on a mainline tree.  At least until now.  So I'm not sure the
>> > best
>> > way to go is for the expander driver to go under the GPIO subtree.
>> 
>> Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe for
>> connection when the GPIO line isn't present in the DT.
>
> Just a FYI, Eric Anholt has offically announced support for VC4 for
> HDMI on mainline Linus build without any support from the expander on
> the RPI 3.  
>
> Sounds like this particular driver isn't needed then, correct?

That's the HDMI audio that just landed.  HDMI has been working on the
pi3 since 9d44a8d530e8cc97d71ffcbc0ff3b5553c62.

In the absence of a GPIO line for hotplug detect, we use DDC, which is
slower and throws an error in dmesg when the probe happens but HDMI is
disconnected.  As such, having a GPIO driver would improve things for
people.


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


Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Julia Lawall


On Tue, 21 Mar 2017, Arushi Singhal wrote:

>
>
> On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield 
> wrote:
>   On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
>   >
>   >
>   > On Tue, 21 Mar 2017, Arushi Singhal wrote:
>   >
>   > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield
>   
>   > > wrote:
>   > >       On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi
>   Singhal wrote:
>   > >       > Patchseries of IIO coding tasks
>   > >
>   > >       This wouldn't be a patchset.  Although they touch the
>   same
>   > >       driver, the changes are unrelated.  See more below...
>   > >
>   > > This I have send as a Patchset because as you have mentioned
>   below that the
>   > > [PATCH 2/2] was already done before by someone but I think
>   so it is not yet
>   > > applied in the Greg's tree yet.So I have done both the
>   changes and as they
>   > > should be applied one after other so that's why I have send
>   them as
>   > > Patchset.
>   >
>   > For the IIO patches, it is better to work on the IIO tree, not
>   Greg's.
>   > Greg manages staging, not IIO.  The IIO patches should appear
>   in Greg's
>   > tree eventually.
>   >
>   > julia
>
>   We didn't direct applicants to create an iio tree.  At this
>   point,
>   it seems more than is necessary.  They can follow the directions
>   in the
>   task descriptions and avoid the collisions.
>
>   Of course, they are welcome to create a tree to iio/testing.
>
>   (IMHO it's more overhead/busy work and maybe not the best use
>   of time in the home stretch of the application period.)
>
>   alisons
>
>
> Hi Alison
> As you have mentioned that my [PATCH 2/2] is already being done someone. So
> how can I make the changes of [PATCH 1/2] on top of it as [PATCH 2/2] is not
> yet applied on the staging tree.

Make a patch that applies to the current state of the IIO tree.  Just
clone that one like you cloned the staging one.

julia

> Please suggest me.
> Thanks
> Arushi
>   >
>   > >       >
>   > >       > Arushi Singhal (2):
>   > >       >   staging: ad7759: Replace mlock with driver private
>   lock
>   > >
>   > >       This one is already been submitted.  If you have a v2
>   for it,
>   > >       then v2
>   > >       the original patch.
>   > >
>   > > Is it submitted by me only before? And this is not the v2.
>   > > I have just resed it.
>   > >       >   staging: iio: ade7759: Move header content to
>   implementation
>   > >       file
>   > >
>   > >       This patch is done and applied already.  See the
>   Coding Task #1
>   > >       notes
>   > >       in the IIO Tasks page.
>   > >
>   > > Not at applied I think so.
>   > > Thanks
>   > > Arushi
>   > >
>   > >       alisons
>   > >
>   > >       >
>   > >       >  drivers/staging/iio/meter/ade7759.c   | 56
>   > >       +--
>   > >       >  drivers/staging/iio/meter/ade7759.h   | 53
>   > >       -
>   > >       >  2 files changed, 54 insertions(+), 57 deletions(-)
>   > >       >
>   > >       > --
>   > >       > 2.11.0
>   > >       >
>   > > > --
>   > > > You received this message because you are subscribed to
>   the Google
>   > > Groups "outreachy-kernel" group.
>   > > > To unsubscribe from this group and stop receiving emails
>   from it,
>   > > send an email to
>   outreachy-kernel+unsubscr...@googlegroups.com.
>   > > > To post to this group, send email to
>   > > outreachy-ker...@googlegroups.com.
>   > > > To view this discussion on the 
> webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737
>   -1-ar
>   > > ushisinghal19971997%40gmail.com.
>   > > > For more options, visit
>   https://groups.google.com/d/optout.
>   > >
>   > >
>   > > --
>   > > You received this message because you are subscribed to the
>   Google Groups
>   > > "outreachy-kernel" group.
>   > > To unsubscribe from this group and stop receiving emails
>   from it, send an
>   > > email to outreachy-kernel+unsubscr...@googlegroups.com.
>   > > To post to this group, send email to
>   outreachy-ker...@googlegroups.com.
>   > > To view this discussion on the 
> webvisithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0
>   H2z8x
>   > > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
>   > > For more options, visit https://groups.google.com/d/optout.
>   > >
>   > >
>
>
>
>___
devel mailing list
de...@linuxdriverproject.org

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Julia Lawall


On Tue, 21 Mar 2017, Alison Schofield wrote:

> On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Mar 2017, Arushi Singhal wrote:
> >
> > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield 
> > > wrote:
> > >   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> > >   > Patchseries of IIO coding tasks
> > >
> > >   This wouldn't be a patchset.  Although they touch the same
> > >   driver, the changes are unrelated.  See more below...
> > >
> > > This I have send as a Patchset because as you have mentioned below that 
> > > the
> > > [PATCH 2/2] was already done before by someone but I think so it is not 
> > > yet
> > > applied in the Greg's tree yet.So I have done both the changes and as they
> > > should be applied one after other so that's why I have send them as
> > > Patchset.
> >
> > For the IIO patches, it is better to work on the IIO tree, not Greg's.
> > Greg manages staging, not IIO.  The IIO patches should appear in Greg's
> > tree eventually.
> >
> > julia
>
> We didn't direct applicants to create an iio tree.  At this point,
> it seems more than is necessary.  They can follow the directions in the
> task descriptions and avoid the collisions.

I meant just pull from the IIO tree you mentioned, work on that, submit
patches, and then expect to see the patches show up there at some time in
the future.

If someone make IIO patches on Greg's tree, then they will have an out of
date view.

julia

>
> Of course, they are welcome to create a tree to iio/testing.
>
> (IMHO it's more overhead/busy work and maybe not the best use
> of time in the home stretch of the application period.)
>
> alisons
> >
> > >   >
> > >   > Arushi Singhal (2):
> > >   >   staging: ad7759: Replace mlock with driver private lock
> > >
> > >   This one is already been submitted.  If you have a v2 for it,
> > >   then v2
> > >   the original patch.
> > >
> > > Is it submitted by me only before? And this is not the v2.
> > > I have just resed it.
> > >   >   staging: iio: ade7759: Move header content to implementation
> > >   file
> > >
> > >   This patch is done and applied already.  See the Coding Task #1
> > >   notes
> > >   in the IIO Tasks page.
> > >
> > > Not at applied I think so.
> > > Thanks
> > > Arushi
> > >
> > >   alisons
> > >
> > >   >
> > >   >  drivers/staging/iio/meter/ade7759.c   | 56
> > >   +--
> > >   >  drivers/staging/iio/meter/ade7759.h   | 53
> > >   -
> > >   >  2 files changed, 54 insertions(+), 57 deletions(-)
> > >   >
> > >   > --
> > >   > 2.11.0
> > >   >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > Groups "outreachy-kernel" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > To post to this group, send email to
> > > outreachy-ker...@googlegroups.com.
> > > > To view this discussion on the web 
> > > > visithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> > > ushisinghal19971997%40gmail.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "outreachy-kernel" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > > To view this discussion on the web 
> > > visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> > > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170321170221.GB2793%40d830.WORKGROUP.
> For more options, visit https://groups.google.com/d/optout.
>___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread SIMRAN SINGHAL
On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield  wrote:
> On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:
>
> Hi Simran,
>
> I going to ask for a v7 without looking at the code ;)
> Subject line needs subsystem and driver.
> Subject and log message can be improved.

Hi Alison,
I have already sent v7 with changed subject.

>
>> The IIO subsystem is redefining iio_dev->mlock to be used by
>> the IIO core only for protecting device operating mode changes.
>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>>
>> In this driver, mlock was being used to protect hardware state
>> changes. Replace it with buf_lock in the devices global data.
>^^^ this was not done
>>
>> As buf_lock protects both the adis16060_spi_write() and
>> adis16060_spi_read() functions and both are always called in
>> pair. First write, then read. Thus, refactor the code to have
>> one single function adis16060_spi_write_than_read() which is
>> protected by the existing buf_lock.
> This was done.  So, you were able to obsolete the need for mlock
> by creating the paired function.
>
>>
>> Removed nested locks as the function adis16060_read_raw call
>> a lock on >buf_lock and then calls the function
>> adis16060_spi_write which again tries to get hold
>> of the same lock.
>  this was not done.  Yes, you avoided nested locks through
> proper coding, but we don't want to give the impression in the
> log message that there was a pre-existing nested lock issue.
>
> I did checkpatch & compile it...but looked no further yet.
>
> alisons
>>
>> Signed-off-by: simran singhal 
>> ---
>>
>>  v6:
>>-Change commit message
>>-Remove nested lock
>>
>>  drivers/staging/iio/gyro/adis16060_core.c | 40 
>> ++-
>>  1 file changed, 13 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index c9d46e7..1c6de46 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -40,25 +40,17 @@ struct adis16060_state {
>>
>>  static struct iio_dev *adis16060_iio_dev;
>>
>> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
>> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
>> +  u8 conf, u16 *val)
>>  {
>>   int ret;
>>   struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
>> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>>   ret = spi_write(st->us_w, st->buf, 3);
>> - mutex_unlock(>buf_lock);
>> -
>> - return ret;
>> -}
>> -
>> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
>> -{
>> - int ret;
>> - struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> + if (ret < 0)
>> + return ret;
>>
>>   ret = spi_read(st->us_r, st->buf, 3);
>>
>> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
>> u16 *val)
>>*/
>>   if (!ret)
>>   *val = ((st->buf[0] & 0x3) << 12) |
>> - (st->buf[1] << 4) |
>> - ((st->buf[2] >> 4) & 0xF);
>> +  (st->buf[1] << 4) |
>> +  ((st->buf[2] >> 4) & 0xF);
>>   mutex_unlock(>buf_lock);
>>
>>   return ret;
>> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  {
>>   u16 tval = 0;
>>   int ret;
>> + struct adis16060_state *st = iio_priv(indio_dev);
>>
>>   switch (mask) {
>>   case IIO_CHAN_INFO_RAW:
>>   /* Take the iio_dev status lock */
>> - mutex_lock(_dev->mlock);
>> - ret = adis16060_spi_write(indio_dev, chan->address);
>> + mutex_lock(>buf_lock);
>> + ret = adis16060_spi_write_than_read(indio_dev,
>> + chan->address, );
>> + mutex_unlock(>buf_lock);
>>   if (ret < 0)
>> - goto out_unlock;
>> + return ret;
>>
>> - ret = adis16060_spi_read(indio_dev, );
>> - if (ret < 0)
>> - goto out_unlock;
>> -
>> - mutex_unlock(_dev->mlock);
>>   *val = tval;
>>   return IIO_VAL_INT;
>>   case IIO_CHAN_INFO_OFFSET:
>> @@ -110,10 +100,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>   }
>>
>>   return -EINVAL;
>> -
>> -out_unlock:
>> - mutex_unlock(_dev->mlock);
>> - return ret;
>>  }
>>
>>  static const struct iio_info adis16060_info = {
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving 

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Alison Schofield
On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
> 
> 
> On Tue, 21 Mar 2017, Arushi Singhal wrote:
> 
> > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield 
> > wrote:
> >   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> >   > Patchseries of IIO coding tasks
> >
> >   This wouldn't be a patchset.  Although they touch the same
> >   driver, the changes are unrelated.  See more below...
> >
> > This I have send as a Patchset because as you have mentioned below that the
> > [PATCH 2/2] was already done before by someone but I think so it is not yet
> > applied in the Greg's tree yet.So I have done both the changes and as they
> > should be applied one after other so that's why I have send them as
> > Patchset.
> 
> For the IIO patches, it is better to work on the IIO tree, not Greg's.
> Greg manages staging, not IIO.  The IIO patches should appear in Greg's
> tree eventually.
> 
> julia

We didn't direct applicants to create an iio tree.  At this point,
it seems more than is necessary.  They can follow the directions in the
task descriptions and avoid the collisions.

Of course, they are welcome to create a tree to iio/testing.

(IMHO it's more overhead/busy work and maybe not the best use
of time in the home stretch of the application period.)

alisons
> 
> >   >
> >   > Arushi Singhal (2):
> >   >   staging: ad7759: Replace mlock with driver private lock
> >
> >   This one is already been submitted.  If you have a v2 for it,
> >   then v2
> >   the original patch.
> >
> > Is it submitted by me only before? And this is not the v2.
> > I have just resed it.
> >   >   staging: iio: ade7759: Move header content to implementation
> >   file
> >
> >   This patch is done and applied already.  See the Coding Task #1
> >   notes
> >   in the IIO Tasks page.
> >
> > Not at applied I think so.
> > Thanks
> > Arushi
> >
> >   alisons
> >
> >   >
> >   >  drivers/staging/iio/meter/ade7759.c   | 56
> >   +--
> >   >  drivers/staging/iio/meter/ade7759.h   | 53
> >   -
> >   >  2 files changed, 54 insertions(+), 57 deletions(-)
> >   >
> >   > --
> >   > 2.11.0
> >   >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "outreachy-kernel" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > To post to this group, send email to
> > outreachy-ker...@googlegroups.com.
> > > To view this discussion on the web 
> > > visithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> > ushisinghal19971997%40gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web 
> > visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >

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


[PATCH] drivers: staging: vt6656: fxed coding style errors

2017-03-21 Thread Prasant Jalan
This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..f69bced 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length, array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread Alison Schofield
On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:

Hi Simran,  

I going to ask for a v7 without looking at the code ;)
Subject line needs subsystem and driver.
Subject and log message can be improved.

> The IIO subsystem is redefining iio_dev->mlock to be used by
> the IIO core only for protecting device operating mode changes.
> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
> 
> In this driver, mlock was being used to protect hardware state
> changes. Replace it with buf_lock in the devices global data.
   ^^^ this was not done
> 
> As buf_lock protects both the adis16060_spi_write() and
> adis16060_spi_read() functions and both are always called in
> pair. First write, then read. Thus, refactor the code to have
> one single function adis16060_spi_write_than_read() which is
> protected by the existing buf_lock.
This was done.  So, you were able to obsolete the need for mlock
by creating the paired function.

> 
> Removed nested locks as the function adis16060_read_raw call
> a lock on >buf_lock and then calls the function
> adis16060_spi_write which again tries to get hold
> of the same lock.
 this was not done.  Yes, you avoided nested locks through
proper coding, but we don't want to give the impression in the
log message that there was a pre-existing nested lock issue.

I did checkpatch & compile it...but looked no further yet.

alisons
> 
> Signed-off-by: simran singhal 
> ---
> 
>  v6:
>-Change commit message
>-Remove nested lock
> 
>  drivers/staging/iio/gyro/adis16060_core.c | 40 
> ++-
>  1 file changed, 13 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
> b/drivers/staging/iio/gyro/adis16060_core.c
> index c9d46e7..1c6de46 100644
> --- a/drivers/staging/iio/gyro/adis16060_core.c
> +++ b/drivers/staging/iio/gyro/adis16060_core.c
> @@ -40,25 +40,17 @@ struct adis16060_state {
>  
>  static struct iio_dev *adis16060_iio_dev;
>  
> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
> +  u8 conf, u16 *val)
>  {
>   int ret;
>   struct adis16060_state *st = iio_priv(indio_dev);
>  
> - mutex_lock(>buf_lock);
> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>   ret = spi_write(st->us_w, st->buf, 3);
> - mutex_unlock(>buf_lock);
> -
> - return ret;
> -}
> -
> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
> -{
> - int ret;
> - struct adis16060_state *st = iio_priv(indio_dev);
>  
> - mutex_lock(>buf_lock);
> + if (ret < 0)
> + return ret;
>  
>   ret = spi_read(st->us_r, st->buf, 3);
>  
> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
> u16 *val)
>*/
>   if (!ret)
>   *val = ((st->buf[0] & 0x3) << 12) |
> - (st->buf[1] << 4) |
> - ((st->buf[2] >> 4) & 0xF);
> +  (st->buf[1] << 4) |
> +  ((st->buf[2] >> 4) & 0xF);
>   mutex_unlock(>buf_lock);
>  
>   return ret;
> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>  {
>   u16 tval = 0;
>   int ret;
> + struct adis16060_state *st = iio_priv(indio_dev);
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
>   /* Take the iio_dev status lock */
> - mutex_lock(_dev->mlock);
> - ret = adis16060_spi_write(indio_dev, chan->address);
> + mutex_lock(>buf_lock);
> + ret = adis16060_spi_write_than_read(indio_dev,
> + chan->address, );
> + mutex_unlock(>buf_lock);
>   if (ret < 0)
> - goto out_unlock;
> + return ret;
>  
> - ret = adis16060_spi_read(indio_dev, );
> - if (ret < 0)
> - goto out_unlock;
> -
> - mutex_unlock(_dev->mlock);
>   *val = tval;
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_OFFSET:
> @@ -110,10 +100,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>   }
>  
>   return -EINVAL;
> -
> -out_unlock:
> - mutex_unlock(_dev->mlock);
> - return ret;
>  }
>  
>  static const struct iio_info adis16060_info = {
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> 

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Julia Lawall


On Tue, 21 Mar 2017, Arushi Singhal wrote:

> On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield 
> wrote:
>   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
>   > Patchseries of IIO coding tasks
>
>   This wouldn't be a patchset.  Although they touch the same
>   driver, the changes are unrelated.  See more below...
>
> This I have send as a Patchset because as you have mentioned below that the
> [PATCH 2/2] was already done before by someone but I think so it is not yet
> applied in the Greg's tree yet.So I have done both the changes and as they
> should be applied one after other so that's why I have send them as
> Patchset.

For the IIO patches, it is better to work on the IIO tree, not Greg's.
Greg manages staging, not IIO.  The IIO patches should appear in Greg's
tree eventually.

julia

>   >
>   > Arushi Singhal (2):
>   >   staging: ad7759: Replace mlock with driver private lock
>
>   This one is already been submitted.  If you have a v2 for it,
>   then v2
>   the original patch.
>
> Is it submitted by me only before? And this is not the v2.
> I have just resed it.
>   >   staging: iio: ade7759: Move header content to implementation
>   file
>
>   This patch is done and applied already.  See the Coding Task #1
>   notes
>   in the IIO Tasks page.
>
> Not at applied I think so.
> Thanks
> Arushi
>
>   alisons
>
>   >
>   >  drivers/staging/iio/meter/ade7759.c   | 56
>   +--
>   >  drivers/staging/iio/meter/ade7759.h   | 53
>   -
>   >  2 files changed, 54 insertions(+), 57 deletions(-)
>   >
>   > --
>   > 2.11.0
>   >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to
> outreachy-ker...@googlegroups.com.
> > To view this discussion on the web 
> > visithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> ushisinghal19971997%40gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

2017-03-21 Thread Alison Schofield
On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> Patchseries of IIO coding tasks

This wouldn't be a patchset.  Although they touch the same
driver, the changes are unrelated.  See more below...
> 
> Arushi Singhal (2):
>   staging: ad7759: Replace mlock with driver private lock

This one is already been submitted.  If you have a v2 for it, then v2
the original patch.

>   staging: iio: ade7759: Move header content to implementation file

This patch is done and applied already.  See the Coding Task #1 notes
in the IIO Tasks page.

alisons

> 
>  drivers/staging/iio/meter/ade7759.c   | 56 
> +--
>  drivers/staging/iio/meter/ade7759.h   | 53 -
>  2 files changed, 54 insertions(+), 57 deletions(-)
> 
> -- 
> 2.11.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737-1-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Prasant Jalan
This patch fixes the following:
- Replace spaces with tabs for indentation
- adds spaces around symbol '-'
- uses __func__ macro to print function name
- truncated the line such that it is within 80 char limit
as per kernel coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..3a9d19a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[3] = (u8)(data >> 24);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
+   0, 0, ARRAY_SIZE(reg_data), reg_data);
 
return true;
 }
@@ -643,9 +643,9 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, u32 
channel)
case RATE_48M:
case RATE_54M:
if (channel > CB_MAX_CHANNEL_24G)
-   power = priv->ofdm_a_pwr_tbl[channel-15];
+   power = priv->ofdm_a_pwr_tbl[channel - 15];
else
-   power = priv->ofdm_pwr_tbl[channel-1];
+   power = priv->ofdm_pwr_tbl[channel - 1];
break;
}
 
@@ -771,7 +771,7 @@ int vnt_rf_set_txpower(struct vnt_private *priv, u8 power, 
u32 rate)
ret &= vnt_rf_write_embedded(priv, 0x015C0800);
} else {
dev_dbg(>usb->dev,
-   " vnt_rf_set_txpower> 11G mode\n");
+   " %s> 11G mode\n", __func__);
 
power_setting = ((0x3f - power) << 20) | (0x7 << 8);
 
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2,
+   length, array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


[PATCH v2 2/2] staging: sm750fb: Remove typedef from "typedef enum _spolarity_t"

2017-03-21 Thread Arushi Singhal
This patch removes typedefs from enum and renames it from "typedef enum
_spolarity_t" to "enum spolarity" as per kernel coding standards."

Signed-off-by: Arushi Singhal 
---
changes in v2
 -change the subject and commit message of PATCH.

 drivers/staging/sm750fb/ddk750_mode.h | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 9dc4d6c5a779..d5eae36d85cb 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -3,11 +3,10 @@
 
 #include "ddk750_chip.h"
 
-typedef enum _spolarity_t {
+enum spolarity {
POS = 0, /* positive */
NEG, /* negative */
-}
-spolarity_t;
+};
 
 struct mode_parameter {
/* Horizontal timing. */
@@ -15,14 +14,14 @@ struct mode_parameter {
unsigned long horizontal_display_end;
unsigned long horizontal_sync_start;
unsigned long horizontal_sync_width;
-   spolarity_t horizontal_sync_polarity;
+   enum spolarity horizontal_sync_polarity;
 
/* Vertical timing. */
unsigned long vertical_total;
unsigned long vertical_display_end;
unsigned long vertical_sync_start;
unsigned long vertical_sync_height;
-   spolarity_t vertical_sync_polarity;
+   enum spolarity vertical_sync_polarity;
 
/* Refresh timing. */
unsigned long pixel_clock;
@@ -30,7 +29,7 @@ struct mode_parameter {
unsigned long vertical_frequency;
 
/* Clock Phase. This clock phase only applies to Panel. */
-   spolarity_t clock_phase_polarity;
+   enum spolarity clock_phase_polarity;
 };
 
 int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
-- 
2.11.0

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


[PATCH v2 1/2] staging: sm750fb: Remove typedef from "typedef struct _mode_parameter_t"

2017-03-21 Thread Arushi Singhal
This patch removes typedefs from struct and renames it from "typedef
struct _mode_parameter_t" to "struct mode_parameter" as per kernel
coding standards."

Signed-off-by: Arushi Singhal 
---
changes in v2
 -change the subject and commit message of PATCH.

 drivers/staging/sm750fb/ddk750_mode.c | 8 +---
 drivers/staging/sm750fb/ddk750_mode.h | 8 +++-
 drivers/staging/sm750fb/sm750_hw.c| 2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index eea5aef2956f..9665bb9478dc 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -12,7 +12,8 @@
  * HW only supports 7 predefined pixel clocks, and clock select is
  * in bit 29:27 of Display Control register.
  */
-static unsigned long displayControlAdjust_SM750LE(mode_parameter_t 
*pModeParam, unsigned long dispControl)
+static unsigned long displayControlAdjust_SM750LE(struct mode_parameter 
*pModeParam,
+ unsigned long dispControl)
 {
unsigned long x, y;
 
@@ -72,7 +73,8 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
 }
 
 /* only timing related registers will be  programed */
-static int programModeRegisters(mode_parameter_t *pModeParam, struct pll_value 
*pll)
+static int programModeRegisters(struct mode_parameter *pModeParam,
+   struct pll_value *pll)
 {
int ret = 0;
int cnt = 0;
@@ -198,7 +200,7 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam, struct pll_value *
return ret;
 }
 
-int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock)
+int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock)
 {
struct pll_value pll;
unsigned int uiActualPixelClk;
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 6d204b8b4a01..9dc4d6c5a779 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -9,7 +9,7 @@ typedef enum _spolarity_t {
 }
 spolarity_t;
 
-typedef struct _mode_parameter_t {
+struct mode_parameter {
/* Horizontal timing. */
unsigned long horizontal_total;
unsigned long horizontal_display_end;
@@ -31,9 +31,7 @@ typedef struct _mode_parameter_t {
 
/* Clock Phase. This clock phase only applies to Panel. */
spolarity_t clock_phase_polarity;
-}
-mode_parameter_t;
-
-int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
+};
 
+int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index fab3fc9c8330..baf1bbdc92ff 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -252,7 +252,7 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc,
 {
int ret, fmt;
u32 reg;
-   mode_parameter_t modparm;
+   struct mode_parameter modparm;
clock_type_t clock;
struct sm750_dev *sm750_dev;
struct lynxfb_par *par;
-- 
2.11.0

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


[PATCH v2 0/2] Remove Typedefs.

2017-03-21 Thread Arushi Singhal
Typedefs are removed in sm750fb driver.

Arushi Singhal (2):
  staging: sm750fb: Remove typedef from "typedef struct _mode_parameter_t"
  staging: sm750fb: Remove typedef from "typedef enum _spolarity_t"

 drivers/staging/sm750fb/ddk750_mode.c |  8 +---
 drivers/staging/sm750fb/ddk750_mode.h | 19 ---
 drivers/staging/sm750fb/sm750_hw.c|  2 +-
 3 files changed, 14 insertions(+), 15 deletions(-)

-- 
changes in v2
 -change the spelling of coverpatch subject.
2.11.0

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


Re: [PATCH v5] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread SIMRAN SINGHAL
On Tue, Mar 21, 2017 at 8:01 PM, kbuild test robot <l...@intel.com> wrote:
> Hi simran,
>
> [auto build test WARNING on iio/togreg]
> [also build test WARNING on v4.11-rc3 next-20170321]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/simran-singhal/staging-Use-buf_lock-instead-of-mlock-and-Refactor-code/20170321-213956
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> config: x86_64-randconfig-x016-201712 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
I am not getting any error, and I have already sent the v7 of this patch
please check out that:
https://groups.google.com/forum/#!topic/outreachy-kernel/5uz6IpcOpMA


>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from drivers/staging/iio/gyro/adis16060_core.c:9:
>drivers/staging/iio/gyro/adis16060_core.c: In function 
> 'adis16060_read_raw':
>include/linux/compiler.h:149:2: warning: this 'if' clause does not 
> guard... [-Wmisleading-indentation]
>  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>  ^
>include/linux/compiler.h:147:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>   ^~
>>> drivers/staging/iio/gyro/adis16060_core.c:89:3: note: in expansion of macro 
>>> 'if'
>   if (ret < 0)
>   ^~
>drivers/staging/iio/gyro/adis16060_core.c:91:4: note: ...this statement, 
> but the latter is misleadingly indented as if it is guarded by the 'if'
>return ret;
>^~
>
> vim +/if +89 drivers/staging/iio/gyro/adis16060_core.c
>
> e071f6b8 Barry Song   2010-10-27   3   *
> e071f6b8 Barry Song   2010-10-27   4   * Copyright 2010 Analog Devices 
> Inc.
> e071f6b8 Barry Song   2010-10-27   5   *
> e071f6b8 Barry Song   2010-10-27   6   * Licensed under the GPL-2 or 
> later.
> e071f6b8 Barry Song   2010-10-27   7   */
> e071f6b8 Barry Song   2010-10-27   8
> 45296236 Paul Gortmaker   2011-08-30  @9  #include 
> e071f6b8 Barry Song   2010-10-27  10  #include 
> e071f6b8 Barry Song   2010-10-27  11  #include 
> e071f6b8 Barry Song   2010-10-27  12  #include 
> e071f6b8 Barry Song   2010-10-27  13  #include 
> e071f6b8 Barry Song   2010-10-27  14  #include 
> e071f6b8 Barry Song   2010-10-27  15  #include 
> e071f6b8 Barry Song   2010-10-27  16  #include 
> 14f98326 Jonathan Cameron 2011-02-28  17
> 06458e27 Jonathan Cameron 2012-04-25  18  #include 
> 06458e27 Jonathan Cameron 2012-04-25  19  #include 
> e071f6b8 Barry Song   2010-10-27  20
> 14f98326 Jonathan Cameron 2011-02-28  21  #define ADIS16060_GYRO  
>   0x20 /* Measure Angular Rate (Gyro) */
> 14f98326 Jonathan Cameron 2011-02-28  22  #define ADIS16060_TEMP_OUT0x10 
> /* Measure Temperature */
> 14f98326 Jonathan Cameron 2011-02-28  23  #define ADIS16060_AIN2  
>   0x80 /* Measure AIN2 */
> 14f98326 Jonathan Cameron 2011-02-28  24  #define ADIS16060_AIN1  
>   0x40 /* Measure AIN1 */
> 14f98326 Jonathan Cameron 2011-02-28  25
> 14f98326 Jonathan Cameron 2011-02-28  26  /**
> 14f98326 Jonathan Cameron 2011-02-28  27   * struct adis16060_state - device 
> instance specific data
> 14f98326 Jonathan Cameron 2011-02-28  28   * @us_w: actual 
> spi_device to write config
> 14f98326 Jonathan Cameron 2011-02-28  29   * @us_r: actual 
> spi_device to read back data
> 25985edc Lucas De Marchi  2011-03-30  30   * @buf:  transmit or 
> receive buffer
> 14f98326 Jonathan Cameron 2011-02-28  31   * @buf_lock: mutex to 
> protect tx and rx
> 14f98326 Jonathan Cameron 2011-02-28  32   **/
> 14f98326 Jonathan Cameron 2011-02-28  33  struct adis16060_state {
> 14f98326 Jonathan Cameron 2011-02-28  34struct spi_device 
>   *us_w;
> 14f98326 Jonathan Cameron 2011-02-28  35struct spi_device 
>   *us_r;
> 14f98326 Jonathan Cameron 2011-02-28  36struct mutex  
>   buf_lock;
> 14f98326 Jonathan Cameron 2011-02-28

[PATCH] drivers: staging: vt6656: fixed coding style errors

2017-03-21 Thread Prasant Jalan
Fixed coding style errors. No errors with checkpatch.pl

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..3a9d19a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[3] = (u8)(data >> 24);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
+   0, 0, ARRAY_SIZE(reg_data), reg_data);
 
return true;
 }
@@ -643,9 +643,9 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, u32 
channel)
case RATE_48M:
case RATE_54M:
if (channel > CB_MAX_CHANNEL_24G)
-   power = priv->ofdm_a_pwr_tbl[channel-15];
+   power = priv->ofdm_a_pwr_tbl[channel - 15];
else
-   power = priv->ofdm_pwr_tbl[channel-1];
+   power = priv->ofdm_pwr_tbl[channel - 1];
break;
}
 
@@ -771,7 +771,7 @@ int vnt_rf_set_txpower(struct vnt_private *priv, u8 power, 
u32 rate)
ret &= vnt_rf_write_embedded(priv, 0x015C0800);
} else {
dev_dbg(>usb->dev,
-   " vnt_rf_set_txpower> 11G mode\n");
+   " %s> 11G mode\n", __func__);
 
power_setting = ((0x3f - power) << 20) | (0x7 << 8);
 
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2,
+   length, array);
 
length2 -= length;
value += length;
-- 
2.7.4

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


Re: [PATCH v5] staging: Use buf_lock instead of mlock and Refactor code

2017-03-21 Thread kbuild test robot
Hi simran,

[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.11-rc3 next-20170321]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/simran-singhal/staging-Use-buf_lock-instead-of-mlock-and-Refactor-code/20170321-213956
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-randconfig-x016-201712 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/staging/iio/gyro/adis16060_core.c:9:
   drivers/staging/iio/gyro/adis16060_core.c: In function 'adis16060_read_raw':
   include/linux/compiler.h:149:2: warning: this 'if' clause does not guard... 
[-Wmisleading-indentation]
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
   include/linux/compiler.h:147:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
>> drivers/staging/iio/gyro/adis16060_core.c:89:3: note: in expansion of macro 
>> 'if'
  if (ret < 0)
  ^~
   drivers/staging/iio/gyro/adis16060_core.c:91:4: note: ...this statement, but 
the latter is misleadingly indented as if it is guarded by the 'if'
   return ret;
   ^~

vim +/if +89 drivers/staging/iio/gyro/adis16060_core.c

e071f6b8 Barry Song   2010-10-27   3   *
e071f6b8 Barry Song   2010-10-27   4   * Copyright 2010 Analog Devices Inc.
e071f6b8 Barry Song   2010-10-27   5   *
e071f6b8 Barry Song   2010-10-27   6   * Licensed under the GPL-2 or later.
e071f6b8 Barry Song   2010-10-27   7   */
e071f6b8 Barry Song   2010-10-27   8  
45296236 Paul Gortmaker   2011-08-30  @9  #include 
e071f6b8 Barry Song   2010-10-27  10  #include 
e071f6b8 Barry Song   2010-10-27  11  #include 
e071f6b8 Barry Song   2010-10-27  12  #include 
e071f6b8 Barry Song   2010-10-27  13  #include 
e071f6b8 Barry Song   2010-10-27  14  #include 
e071f6b8 Barry Song   2010-10-27  15  #include 
e071f6b8 Barry Song   2010-10-27  16  #include 
14f98326 Jonathan Cameron 2011-02-28  17  
06458e27 Jonathan Cameron 2012-04-25  18  #include 
06458e27 Jonathan Cameron 2012-04-25  19  #include 
e071f6b8 Barry Song   2010-10-27  20  
14f98326 Jonathan Cameron 2011-02-28  21  #define ADIS16060_GYRO
0x20 /* Measure Angular Rate (Gyro) */
14f98326 Jonathan Cameron 2011-02-28  22  #define ADIS16060_TEMP_OUT0x10 /* 
Measure Temperature */
14f98326 Jonathan Cameron 2011-02-28  23  #define ADIS16060_AIN2
0x80 /* Measure AIN2 */
14f98326 Jonathan Cameron 2011-02-28  24  #define ADIS16060_AIN1
0x40 /* Measure AIN1 */
14f98326 Jonathan Cameron 2011-02-28  25  
14f98326 Jonathan Cameron 2011-02-28  26  /**
14f98326 Jonathan Cameron 2011-02-28  27   * struct adis16060_state - device 
instance specific data
14f98326 Jonathan Cameron 2011-02-28  28   * @us_w: actual 
spi_device to write config
14f98326 Jonathan Cameron 2011-02-28  29   * @us_r: actual 
spi_device to read back data
25985edc Lucas De Marchi  2011-03-30  30   * @buf:  transmit or 
receive buffer
14f98326 Jonathan Cameron 2011-02-28  31   * @buf_lock: mutex to 
protect tx and rx
14f98326 Jonathan Cameron 2011-02-28  32   **/
14f98326 Jonathan Cameron 2011-02-28  33  struct adis16060_state {
14f98326 Jonathan Cameron 2011-02-28  34struct spi_device   
*us_w;
14f98326 Jonathan Cameron 2011-02-28  35struct spi_device   
*us_r;
14f98326 Jonathan Cameron 2011-02-28  36struct mutex
buf_lock;
14f98326 Jonathan Cameron 2011-02-28  37  
14f98326 Jonathan Cameron 2011-02-28  38u8 buf[3] cacheline_aligned;
14f98326 Jonathan Cameron 2011-02-28  39  };
e071f6b8 Barry Song   2010-10-27  40  
3a5952f9 Jonathan Cameron 2011-06-27  41  static struct iio_dev 
*adis16060_iio_dev;
e071f6b8 Barry Song   2010-10-27  42  
71db16e5 simran singhal   2017-03-19  43  static int 
adis16060_spi_write_than_read(struct iio_dev *indio_dev,
71db16e5 simran singhal   2017-03-19  44
 u8 conf, u16 *val)
e071f6b8 Barry Song   2010-10-27  45  {
e071f6b8 Barry Song   2010-10-27  46int ret;
3a5952f9 Jonathan Cameron 2011-06-27  47struct adis16060_state *st = 
iio_priv(indio_dev)

Re: [PATCH 2/2] staging: vt6656: rf.c: spaces preferred around that '-'

2017-03-21 Thread Matthew Giassa

* Dan Carpenter  [2017-03-21 15:55:52 +0300]:


On Mon, Mar 20, 2017 at 08:46:01PM -0700, Matthew Giassa wrote:

Resolving 2 checkpatch warnings generated due to:
CHECK: spaces preferred around that '-'

Signed-off-by: Matthew Giassa 
---
 drivers/staging/vt6656/rf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 0e3a62a..fe09627 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[3] = (u8)(data >> 24);

vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
+   0, 0, ARRAY_SIZE(reg_data), reg_data);


This isn't described in the changelog.

regards,
dan carpenter



Would it be preferable if the changelog was more verbose? The
literal text from the checkpatch.pl warning itself is indeed in the
changelog:


On Mon, Mar 20, 2017 at 08:46:01PM -0700, Matthew Giassa wrote:

Resolving 2 checkpatch warnings generated due to:
CHECK: spaces preferred around that '-'


Cheers.

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


[PATCH 2/2] staging: iio: ade7759: Move header content to implementation file

2017-03-21 Thread Arushi Singhal
The contents of ade7759.h are only used in ade7759.c.
Move the header contents to the implemtation file,
and delete the header file.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/iio/meter/ade7759.c | 52 ++-
 drivers/staging/iio/meter/ade7759.h | 54 -
 2 files changed, 51 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7759.c 
b/drivers/staging/iio/meter/ade7759.c
index 1d1e0b33021f..86ac103dffe5 100644
--- a/drivers/staging/iio/meter/ade7759.c
+++ b/drivers/staging/iio/meter/ade7759.c
@@ -21,7 +21,57 @@
 #include 
 #include 
 #include "meter.h"
-#include "ade7759.h"
+
+#define ADE7759_WAVEFORM  0x01
+#define ADE7759_AENERGY   0x02
+#define ADE7759_RSTENERGY 0x03
+#define ADE7759_STATUS0x04
+#define ADE7759_RSTSTATUS 0x05
+#define ADE7759_MODE  0x06
+#define ADE7759_CFDEN 0x07
+#define ADE7759_CH1OS 0x08
+#define ADE7759_CH2OS 0x09
+#define ADE7759_GAIN  0x0A
+#define ADE7759_APGAIN0x0B
+#define ADE7759_PHCAL 0x0C
+#define ADE7759_APOS  0x0D
+#define ADE7759_ZXTOUT0x0E
+#define ADE7759_SAGCYC0x0F
+#define ADE7759_IRQEN 0x10
+#define ADE7759_SAGLVL0x11
+#define ADE7759_TEMP  0x12
+#define ADE7759_LINECYC   0x13
+#define ADE7759_LENERGY   0x14
+#define ADE7759_CFNUM 0x15
+#define ADE7759_CHKSUM0x1E
+#define ADE7759_DIEREV0x1F
+
+#define ADE7759_READ_REG(a)a
+#define ADE7759_WRITE_REG(a) ((a) | 0x80)
+
+#define ADE7759_MAX_TX6
+#define ADE7759_MAX_RX6
+#define ADE7759_STARTUP_DELAY 1000
+
+#define ADE7759_SPI_SLOW(u32)(300 * 1000)
+#define ADE7759_SPI_BURST   (u32)(1000 * 1000)
+#define ADE7759_SPI_FAST(u32)(2000 * 1000)
+
+/**
+ * struct ade7759_state - device instance specific data
+ * @us:actual spi_device
+ * @buf_lock:  mutex to protect tx and rx
+ * @tx:transmit buffer
+ * @rx:receive buffer
+ * @lock   protect sensor state
+ **/
+
+struct ade7759_state {
+   struct spi_device   *us;
+   struct mutexbuf_lock; /* protect tx and rx */
+   u8  tx[ADE7759_MAX_TX] cacheline_aligned;
+   u8  rx[ADE7759_MAX_RX];
+};
 
 static int ade7759_spi_write_reg_8(struct device *dev,
u8 reg_address,
diff --git a/drivers/staging/iio/meter/ade7759.h 
b/drivers/staging/iio/meter/ade7759.h
index 4f69bb93cc45..e69de29bb2d1 100644
--- a/drivers/staging/iio/meter/ade7759.h
+++ b/drivers/staging/iio/meter/ade7759.h
@@ -1,54 +0,0 @@
-#ifndef _ADE7759_H
-#define _ADE7759_H
-
-#define ADE7759_WAVEFORM  0x01
-#define ADE7759_AENERGY   0x02
-#define ADE7759_RSTENERGY 0x03
-#define ADE7759_STATUS0x04
-#define ADE7759_RSTSTATUS 0x05
-#define ADE7759_MODE  0x06
-#define ADE7759_CFDEN 0x07
-#define ADE7759_CH1OS 0x08
-#define ADE7759_CH2OS 0x09
-#define ADE7759_GAIN  0x0A
-#define ADE7759_APGAIN0x0B
-#define ADE7759_PHCAL 0x0C
-#define ADE7759_APOS  0x0D
-#define ADE7759_ZXTOUT0x0E
-#define ADE7759_SAGCYC0x0F
-#define ADE7759_IRQEN 0x10
-#define ADE7759_SAGLVL0x11
-#define ADE7759_TEMP  0x12
-#define ADE7759_LINECYC   0x13
-#define ADE7759_LENERGY   0x14
-#define ADE7759_CFNUM 0x15
-#define ADE7759_CHKSUM0x1E
-#define ADE7759_DIEREV0x1F
-
-#define ADE7759_READ_REG(a)a
-#define ADE7759_WRITE_REG(a) ((a) | 0x80)
-
-#define ADE7759_MAX_TX6
-#define ADE7759_MAX_RX6
-#define ADE7759_STARTUP_DELAY 1000
-
-#define ADE7759_SPI_SLOW   (u32)(300 * 1000)
-#define ADE7759_SPI_BURST  (u32)(1000 * 1000)
-#define ADE7759_SPI_FAST   (u32)(2000 * 1000)
-
-/**
- * struct ade7759_state - device instance specific data
- * @us:actual spi_device
- * @buf_lock:  mutex to protect tx and rx
- * @tx:transmit buffer
- * @rx:receive buffer
- * @lock   protect sensor state
- **/
-struct ade7759_state {
-   struct spi_device   *us;
-   struct mutexbuf_lock;
-   u8  tx[ADE7759_MAX_TX] cacheline_aligned;
-   u8  rx[ADE7759_MAX_RX];
-};
-
-#endif
-- 
2.11.0

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


[PATCH 1/2] staging: ad7759: Replace mlock with driver private lock

2017-03-21 Thread Arushi Singhal
The IIO subsystem is redefining iio_dev->mlock to be used by
the IIO core only for protecting device operating mode changes.
ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.

In this driver, mlock was being used to protect hardware state
changes.  Replace it with a lock in the devices global data.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/iio/meter/ade7759.c | 4 ++--
 drivers/staging/iio/meter/ade7759.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7759.c 
b/drivers/staging/iio/meter/ade7759.c
index 944ee3401029..1d1e0b33021f 100644
--- a/drivers/staging/iio/meter/ade7759.c
+++ b/drivers/staging/iio/meter/ade7759.c
@@ -381,7 +381,7 @@ static ssize_t ade7759_write_frequency(struct device *dev,
if (!val)
return -EINVAL;
 
-   mutex_lock(_dev->mlock);
+   mutex_lock(>buf_lock);
 
t = 27900 / val;
if (t > 0)
@@ -402,7 +402,7 @@ static ssize_t ade7759_write_frequency(struct device *dev,
ret = ade7759_spi_write_reg_16(dev, ADE7759_MODE, reg);
 
 out:
-   mutex_unlock(_dev->mlock);
+   mutex_unlock(>buf_lock);
 
return ret ? ret : len;
 }
diff --git a/drivers/staging/iio/meter/ade7759.h 
b/drivers/staging/iio/meter/ade7759.h
index f0716d2fdf8e..4f69bb93cc45 100644
--- a/drivers/staging/iio/meter/ade7759.h
+++ b/drivers/staging/iio/meter/ade7759.h
@@ -42,6 +42,7 @@
  * @buf_lock:  mutex to protect tx and rx
  * @tx:transmit buffer
  * @rx:receive buffer
+ * @lock   protect sensor state
  **/
 struct ade7759_state {
struct spi_device   *us;
-- 
2.11.0

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


[PATCH 0/2] IIO coding tasks

2017-03-21 Thread Arushi Singhal
Patchseries of IIO coding tasks

Arushi Singhal (2):
  staging: ad7759: Replace mlock with driver private lock
  staging: iio: ade7759: Move header content to implementation file

 drivers/staging/iio/meter/ade7759.c   | 56 +--
 drivers/staging/iio/meter/ade7759.h   | 53 -
 2 files changed, 54 insertions(+), 57 deletions(-)

-- 
2.11.0

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


Re: [PATCH 2/2] staging: vt6656: rf.c: spaces preferred around that '-'

2017-03-21 Thread Dan Carpenter
On Mon, Mar 20, 2017 at 08:46:01PM -0700, Matthew Giassa wrote:
> Resolving 2 checkpatch warnings generated due to:
> CHECK: spaces preferred around that '-'
> 
> Signed-off-by: Matthew Giassa 
> ---
>  drivers/staging/vt6656/rf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 0e3a62a..fe09627 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
> data)
>   reg_data[3] = (u8)(data >> 24);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
> - 0, 0, ARRAY_SIZE(reg_data), reg_data);
> + 0, 0, ARRAY_SIZE(reg_data), reg_data);

This isn't described in the changelog.

regards,
dan carpenter

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


Re: [PATCH 10/10] staging: ks7010: rename return value identifier

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 01:37:12PM +1100, Tobin C. Harding wrote:
>  static int ks7010_sdio_data_compare(struct ks_wlan_private *priv, u32 
> address,
>   unsigned char *data, unsigned int size)
>  {
> - int rc;
> + int ret;
>   unsigned char *read_buf;
>  
>   read_buf = kmalloc(ROM_BUFF_SIZE, GFP_KERNEL);
>   if (!read_buf)
>   return -ENOMEM;
>  
> - rc = ks7010_sdio_read(priv, address, read_buf, size);
> - if (rc)
> + ret = ks7010_sdio_read(priv, address, read_buf, size);
> + if (ret)
>   goto err_free_read_buf;
>  
> - rc = memcmp(data, read_buf, size);
> - if (rc) {
> - DPRINTK(0, "data compare error (%d)\n", rc);
> + ret = memcmp(data, read_buf, size);
> + if (ret) {

You didn't introduce this, but this is a bug.  memcpy() doesn't return
error codes.  Could you fix it in a follow on patch?

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


Re: [PATCH 09/10] staging: ks7010: remove zero comparison

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 01:37:11PM +1100, Tobin C. Harding wrote:
> Comparison, equal to zero, is redundant
> 
> 'if (foo == 0)'  is equal to  'if (!foo)'
> 
> Typical kernel coding style is to use the shorter form.
> 
> Remove unnecessary zero comparison.

Not exactly.  If you're talking about the number zero then == 0 and != 0
are good style.  "if (size == 0) ".  Other times we're talking about
error codes or whatever and not the number zero so it should be
"if (ret) ".  Also for strcmp() functions, please use != 0 and == 0.

if (strcmp(foo, bar) != 0)  <-- read this as "foo != bar"
if (strcmp(foo, bar) == 0)  <-- read this as "foo == bar"
if (strcmp(foo, bar) < 0)  <-- read this as "foo < bar"

regards,
dan carpenter


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


[PATCH v2] staging: lustre: replace simple_strtoul with kstrtoint

2017-03-21 Thread Marcin Ciupak
Replace simple_strtoul with kstrtoint.
simple_strtoul is marked for obsoletion as reported by checkpatch.pl

Signed-off-by: Marcin Ciupak 
---
v2:
-improving kstrtoint error handling
-updating commit message

 drivers/staging/lustre/lustre/obdclass/obd_mount.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/obd_mount.c 
b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
index 8e0d4b1d86dc..42858ee5b444 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
@@ -924,12 +924,20 @@ static int lmd_parse(char *options, struct 
lustre_mount_data *lmd)
lmd->lmd_flags |= LMD_FLG_ABORT_RECOV;
clear++;
} else if (strncmp(s1, "recovery_time_soft=", 19) == 0) {
-   lmd->lmd_recovery_time_soft = max_t(int,
-   simple_strtoul(s1 + 19, NULL, 10), time_min);
+   int res;
+
+   rc = kstrtoint(s1 + 19, 10, );
+   if (rc)
+   goto invalid;
+   lmd->lmd_recovery_time_soft = max_t(int, res, time_min);
clear++;
} else if (strncmp(s1, "recovery_time_hard=", 19) == 0) {
-   lmd->lmd_recovery_time_hard = max_t(int,
-   simple_strtoul(s1 + 19, NULL, 10), time_min);
+   int res;
+
+   rc = kstrtoint(s1 + 19, 10, );
+   if (rc)
+   goto invalid;
+   lmd->lmd_recovery_time_hard = max_t(int, res, time_min);
clear++;
} else if (strncmp(s1, "noir", 4) == 0) {
lmd->lmd_flags |= LMD_FLG_NOIR; /* test purpose only. */
-- 
2.11.1

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


Re: [PATCH 04/10] staging: ks7010: fix checkpatch BRACES

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 01:37:06PM +1100, Tobin C. Harding wrote:
> Checkpatch emits CHECK: Unbalanced braces around else
> statement. Statements in question are single statements so we do not
> need braces. Checkpatch also warns about multiple line dereference for
> this code.
> 
> Fix if/else/else if statement use of braces. Fix function argument layout
> at the same time since it is the same statement.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  drivers/staging/ks7010/ks_hostif.c | 22 +-
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_hostif.c 
> b/drivers/staging/ks7010/ks_hostif.c
> index db10e16..68e26f4 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -2456,19 +2456,15 @@ void hostif_sme_execute(struct ks_wlan_private *priv, 
> int event)
>   hostif_phy_information_request(priv);
>   break;
>   case SME_MIC_FAILURE_REQUEST:
> - if (priv->wpa.mic_failure.failure == 1) {
> - hostif_mic_failure_request(priv,
> -priv->wpa.mic_failure.
> -failure - 1, 0);
> - } else if (priv->wpa.mic_failure.failure == 2) {
> - hostif_mic_failure_request(priv,
> -priv->wpa.mic_failure.
> -failure - 1,
> -priv->wpa.mic_failure.
> -counter);
> - } else
> - DPRINTK(4,
> - "SME_MIC_FAILURE_REQUEST: failure count=%u 
> error?\n",
> + if (priv->wpa.mic_failure.failure == 1)
> + hostif_mic_failure_request(
> + priv, priv->wpa.mic_failure.failure - 1, 0);
> + else if (priv->wpa.mic_failure.failure == 2)
> + hostif_mic_failure_request(
> + priv, priv->wpa.mic_failure.failure - 1,
> + priv->wpa.mic_failure.counter);
> + else
> + DPRINTK(4, "SME_MIC_FAILURE_REQUEST: failure count=%u 
> error?\n",
>   priv->wpa.mic_failure.failure);

No.  This isn't nice.

Multi-line indents get curly braces generally for readability.  It's
better to go over the 80 character limit here.


if (priv->wpa.mic_failure.failure == 1) {
hostif_mic_failure_request(priv,
   
priv->wpa.mic_failure.failure - 1,
   0);
} else if priv->wpa.mic_failure.failure == 2) {
hostif_mic_failure_request(priv,
   
priv->wpa.mic_failure.failure - 1,
   
priv->wpa.mic_failure.counter);
} else {
DPRINTK(4, "SME_MIC_FAILURE_REQUEST: failure count=%u 
error?\n",
priv->wpa.mic_failure.failure);
}

regards,
dan carpenter

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


Re: [PATCH 2/5] staging: bcm2835-camera: Fix integer underrun in port_parameter_get

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 04:51:03AM -0700, Michael Zoran wrote:
> The original version seems to have been applied at this point.  The
> whole function looks like it could use some cleanup in general.  Should
> I just submit those an independent patch when I get to it or should I
> submit a V2 the way you describe and have GregK replace it?

Send them as independent follow up patches.

regards,
dan carpenter

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


Re: [PATCH 1/2] staging: sm750fb: Remove typedefs from struct

2017-03-21 Thread Greg KH
On Tue, Mar 21, 2017 at 04:56:38PM +0530, Arushi Singhal wrote:
> This patch removes typedefs from structure and renames them as
> per kernel coding standards.

In the subject, and in the text, say _which_ typedef you changed, and
what you changed it to.

Same for your patch 2/2.

thanks,

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


Re: [PATCH 2/5] staging: bcm2835-camera: Fix integer underrun in port_parameter_get

2017-03-21 Thread Michael Zoran
On Tue, 2017-03-21 at 14:45 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 04:36:16AM -0700, Michael Zoran wrote:
> > On Tue, 2017-03-21 at 13:41 +0300, Dan Carpenter wrote:
> > > You're fixing a bug you introduced in [PATCH 1/5].  Don't do
> > > that.  Just
> > > fix Dave's patch and add a note in the commit log.
> > > 
> > > regards,
> > > dan carpenter
> > > 
> > 
> > OK, thanks I'm still learning about the whole process.  It looks
> > like
> > Dave's version has already been applied though.
> > 
> > I just want to have as much as possible a separation between what
> > I'm
> > passing upstream from the github(as a favor to him mostly) just to
> > keep
> > the two trees in sync, and what I'm submitting.  I don't want the
> > logs
> > to get too mixed up.  It's just a personal thing.
> > 
> 
> Sure.  I understand that.  But please do what I am saying?
> 
> Also I feel like there should be a tag for bugfixes to a patch like:
> 
> Fixes-from: Michael Zoran 
> 
> A good deal of my work gets folded into the original patches and I
> don't
> get any sort of credit that you can measure for it.  I've lobbied for
> the Fixes-from: tag for a while...  It would only cover bug fixes not
> bike shedding or style issues.
> 
> regards,
> dan carpenter
> 

Sure, I'll do that from now on.

The original version seems to have been applied at this point.  The
whole function looks like it could use some cleanup in general.  Should
I just submit those an independent patch when I get to it or should I
submit a V2 the way you describe and have GregK replace it?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/5] staging: bcm2835-camera: Fix integer underrun in port_parameter_get

2017-03-21 Thread Dan Carpenter
On Tue, Mar 21, 2017 at 04:36:16AM -0700, Michael Zoran wrote:
> On Tue, 2017-03-21 at 13:41 +0300, Dan Carpenter wrote:
> > You're fixing a bug you introduced in [PATCH 1/5].  Don't do
> > that.  Just
> > fix Dave's patch and add a note in the commit log.
> > 
> > regards,
> > dan carpenter
> > 
> 
> OK, thanks I'm still learning about the whole process.  It looks like
> Dave's version has already been applied though.
> 
> I just want to have as much as possible a separation between what I'm
> passing upstream from the github(as a favor to him mostly) just to keep
> the two trees in sync, and what I'm submitting.  I don't want the logs
> to get too mixed up.  It's just a personal thing.
> 

Sure.  I understand that.  But please do what I am saying?

Also I feel like there should be a tag for bugfixes to a patch like:

Fixes-from: Michael Zoran 

A good deal of my work gets folded into the original patches and I don't
get any sort of credit that you can measure for it.  I've lobbied for
the Fixes-from: tag for a while...  It would only cover bug fixes not
bike shedding or style issues.

regards,
dan carpenter

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


[PATCH 10/11] staging: speakup: Match alignment with open parenthesis.

2017-03-21 Thread Arushi Singhal
Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   | 2 +-
 drivers/staging/speakup/selection.c  | 2 +-
 drivers/staging/speakup/serialio.c   | 2 +-
 drivers/staging/speakup/speakup_acntpc.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 7568e8149613..55bf7af1d6ea 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1160,7 +1160,7 @@ static void spkup_write(const u16 *in_buf, int count)
if (last_type & CH_RPT) {
synth_printf(" ");
synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
-   ++rep_count);
+++rep_count);
synth_printf(" ");
}
rep_count = 0;
diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index 4417c00e68a7..08f68fc2864e 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -75,7 +75,7 @@ int speakup_set_selection(struct tty_struct *tty)
speakup_clear_selection();
spk_sel_cons = vc_cons[fg_console].d;
dev_warn(tty->dev,
-   "Selection: mark console not the same as cut\n");
+"Selection: mark console not the same as cut\n");
return -EINVAL;
}
 
diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index e860e48818a4..5e31acac19de 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -125,7 +125,7 @@ static void start_serial_interrupt(int irq)
pr_err("Unable to request Speakup serial I R Q\n");
/* Set MCR */
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2,
-   speakup_info.port_tts + UART_MCR);
+speakup_info.port_tts + UART_MCR);
/* Turn on Interrupts */
outb(UART_IER_MSI|UART_IER_RLSI|UART_IER_RDI,
speakup_info.port_tts + UART_IER);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index b4058bd82e42..ad72f8e883fc 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -261,9 +261,9 @@ static int synth_probe(struct spk_synth *synth)
if (port_forced) {
speakup_info.port_tts = port_forced;
pr_info("probe forced to %x by kernel command line\n",
-   speakup_info.port_tts);
+   speakup_info.port_tts);
if (synth_request_region(speakup_info.port_tts - 1,
-   SYNTH_IO_EXTENT)) {
+SYNTH_IO_EXTENT)) {
pr_warn("sorry, port already reserved\n");
return -EBUSY;
}
@@ -272,7 +272,7 @@ static int synth_probe(struct spk_synth *synth)
} else {
for (i = 0; synth_portlist[i]; i++) {
if (synth_request_region(synth_portlist[i],
-   SYNTH_IO_EXTENT)) {
+SYNTH_IO_EXTENT)) {
pr_warn
("request_region: failed with 0x%x, %d\n",
 synth_portlist[i], SYNTH_IO_EXTENT);
-- 
2.11.0

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


[PATCH 08/11] staging: speakup: Removed Unnecessary parentheses.

2017-03-21 Thread Arushi Singhal
Unnecessary parentheses are removed to improve readability.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/kobjects.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index afb61e153592..ca85476e3ff7 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -392,7 +392,7 @@ static ssize_t synth_store(struct kobject *kobj, struct 
kobj_attribute *attr,
len--;
new_synth_name[len] = '\0';
spk_strlwr(new_synth_name);
-   if (synth && (!strcmp(new_synth_name, synth->name))) {
+   if (synth && !strcmp(new_synth_name, synth->name)) {
pr_warn("%s already in use\n", new_synth_name);
} else if (synth_init(new_synth_name) != 0) {
pr_warn("failed to init synth %s\n", new_synth_name);
-- 
2.11.0

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


[PATCH 06/11] staging: speakup: Moved OR operator to previous line.

2017-03-21 Thread Arushi Singhal
Moved logical OR operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c10445624e92..def1a36da9dd 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2173,10 +2173,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (up_flag || spk_killed || type == KT_SHIFT)
goto out;
spk_shut_up &= 0xfe;
-   kh = (value == KVAL(K_DOWN))
-   || (value == KVAL(K_UP))
-   || (value == KVAL(K_LEFT))
-   || (value == KVAL(K_RIGHT));
+   kh = (value == KVAL(K_DOWN)) ||
+   (value == KVAL(K_UP)) ||
+   (value == KVAL(K_LEFT)) ||
+   (value == KVAL(K_RIGHT));
if ((cursor_track != read_all_mode) || !kh)
if (!spk_no_intr)
spk_do_flush();
-- 
2.11.0

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


[PATCH 11/11] staging: speakup: Fix alignment with parenthesis.

2017-03-21 Thread Arushi Singhal
This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/speakup_apollo.c | 2 +-
 drivers/staging/speakup/speakup_decext.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/speakup_apollo.c 
b/drivers/staging/speakup/speakup_apollo.c
index 9cfdbbfb9742..6ad83dc642c4 100644
--- a/drivers/staging/speakup/speakup_apollo.c
+++ b/drivers/staging/speakup/speakup_apollo.c
@@ -173,7 +173,7 @@ static void do_catch_up(struct spk_synth *synth)
if (!synth->io_ops->synth_out(synth, ch)) {
outb(UART_MCR_DTR, speakup_info.port_tts + UART_MCR);
outb(UART_MCR_DTR | UART_MCR_RTS,
-   speakup_info.port_tts + UART_MCR);
+speakup_info.port_tts + UART_MCR);
schedule_timeout(msecs_to_jiffies(full_time_val));
continue;
}
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 929a28d618dc..c564bf8e1531 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -206,11 +206,11 @@ static void do_catch_up(struct spk_synth *synth)
if (!in_escape)
synth->io_ops->synth_out(synth, 
PROCSPEECH);
spin_lock_irqsave(_info.spinlock,
-   flags);
+ flags);
jiffy_delta_val = jiffy_delta->u.n.value;
delay_time_val = delay_time->u.n.value;
spin_unlock_irqrestore(_info.spinlock,
-   flags);
+  flags);
schedule_timeout(msecs_to_jiffies
 (delay_time_val));
jiff_max = jiffies + jiffy_delta_val;
-- 
2.11.0

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


[PATCH 09/11] staging: speakup: Simplify the NULL comparisons

2017-03-21 Thread Arushi Singhal
Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.
Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/fakekey.c |  2 +-
 drivers/staging/speakup/main.c| 32 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index d76da0a1382c..294c74b47224 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -56,7 +56,7 @@ int speakup_add_virtual_keyboard(void)
 
 void speakup_remove_virtual_keyboard(void)
 {
-   if (virt_keyboard != NULL) {
+   if (virt_keyboard) {
input_unregister_device(virt_keyboard);
virt_keyboard = NULL;
}
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index def1a36da9dd..7568e8149613 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -304,7 +304,7 @@ static void speakup_shut_up(struct vc_data *vc)
spk_shut_up |= 0x01;
spk_parked &= 0xfe;
speakup_date(vc);
-   if (synth != NULL)
+   if (synth)
spk_do_flush();
 }
 
@@ -449,7 +449,7 @@ static void speak_char(u16 ch)
}
 
cp = spk_characters[ch];
-   if (cp == NULL) {
+   if (!cp) {
pr_info("speak_char: cp == NULL!\n");
return;
}
@@ -1177,7 +1177,7 @@ static void do_handle_shift(struct vc_data *vc, u_char 
value, char up_flag)
 {
unsigned long flags;
 
-   if (synth == NULL || up_flag || spk_killed)
+   if (!synth || up_flag || spk_killed)
return;
spin_lock_irqsave(_info.spinlock, flags);
if (cursor_track == read_all_mode) {
@@ -1215,7 +1215,7 @@ static void do_handle_latin(struct vc_data *vc, u_char 
value, char up_flag)
spin_unlock_irqrestore(_info.spinlock, flags);
return;
}
-   if (synth == NULL || spk_killed) {
+   if (!synth || spk_killed) {
spin_unlock_irqrestore(_info.spinlock, flags);
return;
}
@@ -1341,7 +1341,7 @@ static int speakup_allocate(struct vc_data *vc)
int vc_num;
 
vc_num = vc->vc_num;
-   if (speakup_console[vc_num] == NULL) {
+   if (!speakup_console[vc_num]) {
speakup_console[vc_num] = kzalloc(sizeof(*speakup_console[0]),
  GFP_ATOMIC);
if (!speakup_console[vc_num])
@@ -1394,7 +1394,7 @@ static void kbd_fakekey2(struct vc_data *vc, int command)
 
 static void read_all_doc(struct vc_data *vc)
 {
-   if ((vc->vc_num != fg_console) || synth == NULL || spk_shut_up)
+   if ((vc->vc_num != fg_console) || !synth || spk_shut_up)
return;
if (!synth_supports_indexing())
return;
@@ -1509,7 +1509,7 @@ static int pre_handle_cursor(struct vc_data *vc, u_char 
value, char up_flag)
spin_lock_irqsave(_info.spinlock, flags);
if (cursor_track == read_all_mode) {
spk_parked &= 0xfe;
-   if (synth == NULL || up_flag || spk_shut_up) {
+   if (!synth || up_flag || spk_shut_up) {
spin_unlock_irqrestore(_info.spinlock, flags);
return NOTIFY_STOP;
}
@@ -1531,7 +1531,7 @@ static void do_handle_cursor(struct vc_data *vc, u_char 
value, char up_flag)
 
spin_lock_irqsave(_info.spinlock, flags);
spk_parked &= 0xfe;
-   if (synth == NULL || up_flag || spk_shut_up || cursor_track == CT_Off) {
+   if (!synth || up_flag || spk_shut_up || cursor_track == CT_Off) {
spin_unlock_irqrestore(_info.spinlock, flags);
return;
}
@@ -1730,7 +1730,7 @@ static void speakup_bs(struct vc_data *vc)
return;
if (!spk_parked)
speakup_date(vc);
-   if (spk_shut_up || synth == NULL) {
+   if (spk_shut_up || !synth) {
spin_unlock_irqrestore(_info.spinlock, flags);
return;
}
@@ -1747,7 +1747,7 @@ static void speakup_con_write(struct vc_data *vc, u16 
*str, int len)
 {
unsigned long flags;
 
-   if ((vc->vc_num != fg_console) || spk_shut_up || synth == NULL)
+   if ((vc->vc_num != fg_console) || spk_shut_up || !synth)
return;
if (!spin_trylock_irqsave(_info.spinlock, flags))
/* Speakup output, discard */
@@ -1776,7 +1776,7 @@ static void speakup_con_update(struct vc_data *vc)
 {
unsigned long flags;
 
-   if (speakup_console[vc->vc_num] == NULL || spk_parked)
+   if (!speakup_console[vc->vc_num] || spk_parked)
return;
if (!spin_trylock_irqsave(_info.spinlock, flags))
/* Speakup output, 

[PATCH 07/11] staging: speakup: spaces preferred around operator

2017-03-21 Thread Arushi Singhal
Fixed the checkpatch.pl issues like:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
etc.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  | 20 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_keypc.c  |  6 +++---
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 6 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index 0bc8d6afadfa..a654334c98b9 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -20,7 +20,7 @@
 #define A_CAP 0x0007
 #define B_NUM 0x0008
 #define NUM 0x0009
-#define ALPHANUM (B_ALPHA|B_NUM)
+#define ALPHANUM (B_ALPHA | B_NUM)
 #define SOME 0x0010
 #define MOST 0x0020
 #define PUNC 0x0040
@@ -30,14 +30,14 @@
 #define B_EXNUM 0x0100
 #define CH_RPT 0x0200
 #define B_CTL 0x0400
-#define A_CTL (B_CTL+SYNTH_OK)
+#define A_CTL (B_CTL + SYNTH_OK)
 #define B_SYM 0x0800
-#define B_CAPSYM (B_CAP|B_SYM)
+#define B_CAPSYM (B_CAP | B_SYM)
 
 /* FIXME: u16 */
-#define IS_WDLM(x) (spk_chartab[((u_char)x)]_WDLM)
-#define IS_CHAR(x, type) (spk_chartab[((u_char)x)])
-#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)]) == type)
+#define IS_WDLM(x) (spk_chartab[((u_char)x)] & B_WDLM)
+#define IS_CHAR(x, type) (spk_chartab[((u_char)x)] & type)
+#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)] & type) == type)
 
 int speakup_thread(void *data);
 void spk_reset_default_chars(void);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index c5beb5602c42..b4058bd82e42 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -282,7 +282,7 @@ static int synth_probe(struct spk_synth *synth)
if (port_val == 0x53fc) {
/* 'S' and out bits */
synth_port_control = synth_portlist[i];
-   speakup_info.port_tts = synth_port_control+1;
+   speakup_info.port_tts = synth_port_control + 1;
break;
}
}
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 5e35d7e11361..5d22c3b7edd4 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -250,7 +250,7 @@ static int dt_getstatus(void)
 static void dt_sendcmd(u_int cmd)
 {
outb_p(cmd & 0xFF, speakup_info.port_tts);
-   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts+1);
+   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts + 1);
 }
 
 static int dt_waitbit(int bit)
@@ -286,11 +286,11 @@ static int dt_ctrl(u_int cmd)
 
if (!dt_waitbit(STAT_cmd_ready))
return -1;
-   outb_p(0, speakup_info.port_tts+2);
-   outb_p(0, speakup_info.port_tts+3);
+   outb_p(0, speakup_info.port_tts + 2);
+   outb_p(0, speakup_info.port_tts + 3);
dt_getstatus();
-   dt_sendcmd(CMD_control|cmd);
-   outb_p(0, speakup_info.port_tts+6);
+   dt_sendcmd(CMD_control | cmd);
+   outb_p(0, speakup_info.port_tts + 6);
while (dt_getstatus() & STAT_cmd_ready) {
udelay(20);
if (--timeout == 0)
@@ -318,8 +318,8 @@ udelay(50);
break;
 udelay(50);
}
-   outb_p(DMA_sync, speakup_info.port_tts+4);
-   outb_p(0, speakup_info.port_tts+4);
+   outb_p(DMA_sync, speakup_info.port_tts + 4);
+   outb_p(0, speakup_info.port_tts + 4);
udelay(100);
for (timeout = 0; timeout < 10; timeout++) {
if (!(dt_getstatus() & STAT_flushing))
@@ -337,8 +337,8 @@ static int dt_sendchar(char ch)
return -1;
if (!(dt_stat & STAT_rr_char))
return -2;
-   outb_p(DMA_single_in, speakup_info.port_tts+4);
-   outb_p(ch, speakup_info.port_tts+4);
+   outb_p(DMA_single_in, speakup_info.port_tts + 4);
+   outb_p(ch, speakup_info.port_tts + 4);
dma_state ^= STAT_dma_state;
return 0;
 }
@@ -354,7 +354,7 @@ static int testkernel(void)
dt_sendcmd(CMD_sync);
if (!dt_waitbit(STAT_cmd_ready))
status = -2;
-   else if (dt_stat&0x8000)
+   else if (dt_stat & 0x8000)
return 0;
else if (dt_stat == 0x0dec)
pr_warn("dec_pc at 0x%x, software not loaded\n",
diff --git a/drivers/staging/speakup/speakup_dtlk.c 
b/drivers/staging/speakup/speakup_dtlk.c
index 693fac4365c3..5973acc0a006 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ 

[PATCH 04/11] staging: speakup: fixes braces {} should be used on all arms of this statement

2017-03-21 Thread Arushi Singhal
This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   | 35 +++-
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 ++-
 5 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f8fccc8bf6b2..21e76b031449 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -409,8 +409,9 @@ static void say_attributes(struct vc_data *vc)
if (bg > 7) {
synth_printf(" %s ", spk_msg_get(MSG_ON_BLINKING));
bg -= 8;
-   } else
+   } else {
synth_printf(" %s ", spk_msg_get(MSG_ON));
+   }
synth_printf("%s\n", spk_msg_get(MSG_COLORS_START + bg));
 }
 
@@ -643,8 +644,9 @@ static void say_prev_word(struct vc_data *vc)
break;
spk_y--;
spk_x = vc->vc_cols - 1;
-   } else
+   } else {
spk_x--;
+   }
spk_pos -= 2;
ch = get_char(vc, (u_short *)spk_pos, );
if (ch == SPACE || ch == 0)
@@ -697,8 +699,9 @@ static void say_next_word(struct vc_data *vc)
spk_y++;
spk_x = 0;
edge_said = edge_right;
-   } else
+   } else {
spk_x++;
+   }
spk_pos += 2;
last_state = state;
}
@@ -729,8 +732,9 @@ static void spell_word(struct vc_data *vc)
spk_pitch_shift++;
else/* synth has no pitch */
last_cap = spk_str_caps_stop;
-   } else
+   } else {
str_cap = spk_str_caps_stop;
+   }
if (str_cap != last_cap) {
synth_printf("%s", str_cap);
last_cap = str_cap;
@@ -1343,8 +1347,9 @@ static int speakup_allocate(struct vc_data *vc)
if (!speakup_console[vc_num])
return -ENOMEM;
speakup_date(vc);
-   } else if (!spk_parked)
+   } else if (!spk_parked) {
speakup_date(vc);
+   }
 
return 0;
 }
@@ -1397,9 +1402,9 @@ static void read_all_doc(struct vc_data *vc)
prev_cursor_track = cursor_track;
cursor_track = read_all_mode;
spk_reset_index_count(0);
-   if (get_sentence_buf(vc, 0) == -1)
+   if (get_sentence_buf(vc, 0) == -1) {
kbd_fakekey2(vc, RA_DOWN_ARROW);
-   else {
+   } else {
say_sentence_num(0, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -1446,8 +1451,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
if (!say_sentence_num(sentcount + 1, 1)) {
sn = 1;
spk_reset_index_count(sn);
-   } else
+   } else {
synth_insert_next_index(0);
+   }
if (!say_sentence_num(sn, 0)) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
return;
@@ -1476,9 +1482,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
rv = get_sentence_buf(vc, 0);
if (rv == -1)
read_all_doc(vc);
-   if (rv == 0)
+   if (rv == 0) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
-   else {
+   } else {
say_sentence_num(1, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -2177,10 +2183,11 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (type == KT_SPEC && value == 1) {
value = '\n';
type = KT_LATIN;
-   } else if (type == KT_LETTER)
+   } else if (type == KT_LETTER) {
type = KT_LATIN;
-   else if (value == 0x7f)
+   } else if (value == 0x7f) {
value = 8;  /* make del = backspace */
+   }
ret = (*spk_special_handler) (vc, type, value, keycode);
spk_close_press = 0;
if (ret < 0)
@@ -2274,9 +2281,9 @@ static int 

[PATCH 05/11] staging: speakup: Remove multiple assignments

2017-03-21 Thread Arushi Singhal
This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 21e76b031449..c10445624e92 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2106,7 +2106,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
spk_keydown = 0;
goto out;
}
-   value = spk_lastkey = pad_chars[value];
+   value = pad_chars[value];
+   spk_lastkey = value;
spk_keydown++;
spk_parked &= 0xfe;
goto no_map;
-- 
2.11.0

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


[PATCH 01/11] staging: speakup: Moved logical to previous line.

2017-03-21 Thread Arushi Singhal
Moved logical operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f280e22d7e15..f71206878363 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -905,8 +905,8 @@ static int get_sentence_buf(struct vc_data *vc, int 
read_punc)
while (start < end) {
sentbuf[bn][i] = get_char(vc, (u_short *)start, );
if (i > 0) {
-   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
-   && numsentences[bn] < 9) {
+   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == 
'.' &&
+   numsentences[bn] < 9) {
/* Sentence Marker */
numsentences[bn]++;
sentmarks[bn][numsentences[bn]] =
@@ -1292,8 +1292,8 @@ void spk_reset_default_chars(void)
 
/* First, free any non-default */
for (i = 0; i < 256; i++) {
-   if ((spk_characters[i] != NULL)
-   && (spk_characters[i] != spk_default_chars[i]))
+   if (spk_characters[i] &&
+   (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
 
@@ -2088,8 +2088,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
tty = vc->port.tty;
if (type >= 0xf0)
type -= 0xf0;
-   if (type == KT_PAD
-   && (vt_get_leds(fg_console, VC_NUMLOCK))) {
+   if (type == KT_PAD &&
+   (vt_get_leds(fg_console, VC_NUMLOCK))) {
if (up_flag) {
spk_keydown = 0;
goto out;
-- 
2.11.0

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


[PATCH 03/11] staging: speakup: Simplify "NULL" comparisons

2017-03-21 Thread Arushi Singhal
Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.
Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/selection.c   | 2 +-
 drivers/staging/speakup/varhandlers.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index afd9a446a06f..4417c00e68a7 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -175,7 +175,7 @@ static struct speakup_paste_work speakup_paste_work = {
 
 int speakup_paste_selection(struct tty_struct *tty)
 {
-   if (cmpxchg(_paste_work.tty, NULL, tty) != NULL)
+   if (cmpxchg(_paste_work.tty, NULL, tty))
return -EBUSY;
 
tty_kref_get(tty);
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..5910fe0b1365 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -98,7 +98,7 @@ void speakup_register_var(struct var_t *var)
}
}
p_header = var_ptrs[var->var_id];
-   if (p_header->data != NULL)
+   if (p_header->data)
return;
p_header->data = var;
switch (p_header->var_type) {
@@ -210,11 +210,11 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
return -ERANGE;
 
var_data->u.n.value = val;
-   if (var->var_type == VAR_TIME && p_val != NULL) {
+   if (var->var_type == VAR_TIME && p_val) {
*p_val = msecs_to_jiffies(val);
return 0;
}
-   if (p_val != NULL)
+   if (p_val)
*p_val = val;
if (var->var_id == PUNC_LEVEL) {
spk_punc_mask = spk_punc_masks[val];
-- 
2.11.0

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


[PATCH 02/11] staging: speakup: Remove multiple assignments

2017-03-21 Thread Arushi Singhal
This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f71206878363..f8fccc8bf6b2 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -270,9 +270,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
u16 *pos)
 
 static void speakup_date(struct vc_data *vc)
 {
-   spk_x = spk_cx = vc->vc_x;
-   spk_y = spk_cy = vc->vc_y;
-   spk_pos = spk_cp = vc->vc_pos;
+   spk_x = vc->vc_x;
+   spk_cx = spk_x;
+   spk_y = vc->vc_y;
+   spk_cy = spk_y;
+   spk_pos = vc->vc_pos;
+   spk_cp = spk_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
 }
@@ -1655,9 +1658,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
-   spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
-   spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
-   spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+   spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+   spk_cp = spk_pos;
+   spk_x = speakup_console[vc_num]->ht.rx[hc];
+   spk_cx = spk_x;
+   spk_y = speakup_console[vc_num]->ht.ry[hc];
+   spk_cy = spk_y;
return 1;
}
return 0;
-- 
2.11.0

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


[RESEND PATCH 00/11] staging:speakup: Multiple Checkpatch issues.

2017-03-21 Thread Arushi Singhal
Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (11):
  staging: speakup: Moved logical to previous line.
  staging: speakup: Remove multiple assignments
  staging: speakup: Simplify "NULL" comparisons
  staging: speakup: fixes braces {} should be used on all arms of this
statement
  staging: speakup: Remove multiple assignments
  staging: speakup: Moved OR operator to previous line.
  staging: speakup: spaces preferred around operator
  staging: speakup: Removed Unnecessary parentheses.
  staging: speakup: Simplify the NULL comparisons
  staging: speakup: Match alignment with open parenthesis.
  staging: speakup: Fix alignment with parenthesis.

 drivers/staging/speakup/fakekey.c|   2 +-
 drivers/staging/speakup/kobjects.c   |   2 +-
 drivers/staging/speakup/main.c   | 110 +--
 drivers/staging/speakup/selection.c  |   4 +-
 drivers/staging/speakup/serialio.c   |   2 +-
 drivers/staging/speakup/speakup.h|  12 ++--
 drivers/staging/speakup/speakup_acntpc.c |   8 +--
 drivers/staging/speakup/speakup_apollo.c |   2 +-
 drivers/staging/speakup/speakup_decext.c |  10 +--
 drivers/staging/speakup/speakup_decpc.c  |  26 
 drivers/staging/speakup/speakup_dectlk.c |   6 +-
 drivers/staging/speakup/speakup_dtlk.c   |   2 +-
 drivers/staging/speakup/speakup_keypc.c  |   6 +-
 drivers/staging/speakup/speakup_ltlk.c   |   2 +-
 drivers/staging/speakup/varhandlers.c|  18 ++---
 15 files changed, 114 insertions(+), 98 deletions(-)

-- 
2.11.0

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


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-21 Thread Russell King - ARM Linux
On Tue, Mar 21, 2017 at 11:59:02AM +0100, Hans Verkuil wrote:
> Ah, good to hear that -s works with MC. I was not sure about that.
> Thanks for the feedback!

Not soo good on iMX6:

$ v4l2-compliance -d /dev/video10 -s --expbuf-device=/dev/video0
...
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
fail: v4l2-test-input-output.cpp(420): G_INPUT not supported 
for a capture device
test VIDIOC_G/S/ENUMINPUT: FAIL
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
...
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
fail: v4l2-test-controls.cpp(782): subscribe event for control 
'User Controls' failed
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
...
Streaming ioctls:
test read/write: OK (Not Supported)
fail: v4l2-test-buffers.cpp(297): g_field() == V4L2_FIELD_ANY
fail: v4l2-test-buffers.cpp(703): buf.check(q, last_seq)
fail: v4l2-test-buffers.cpp(973): captureBufs(node, q, m2m_q, 
frame_count, false)
test MMAP: FAIL
test USERPTR: OK (Not Supported)
fail: v4l2-test-buffers.cpp(1188): can_stream && ret != EINVAL
test DMABUF: FAIL

(/dev/video0 being CODA).  CODA itself seems to have failures:

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
warn: v4l2-test-formats.cpp(1187): S_PARM is supported for 
buftype 2, but not ENUM_FRAMEINTERVALS
warn: v4l2-test-formats.cpp(1194): S_PARM is supported but 
doesn't report V4L2_CAP_TIMEPERFRAME
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
fail: v4l2-test-formats.cpp(774): fmt_out.g_colorspace() != col
...
Streaming ioctls:
test read/write: OK (Not Supported)
fail: v4l2-test-buffers.cpp(956): q.create_bufs(node, 1, ) 
!= EINVAL
test MMAP: FAIL
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/5] staging: bcm2835-camera: Fix integer underrun in port_parameter_get

2017-03-21 Thread Michael Zoran
On Tue, 2017-03-21 at 13:41 +0300, Dan Carpenter wrote:
> You're fixing a bug you introduced in [PATCH 1/5].  Don't do
> that.  Just
> fix Dave's patch and add a note in the commit log.
> 
> regards,
> dan carpenter
> 

OK, thanks I'm still learning about the whole process.  It looks like
Dave's version has already been applied though.

I just want to have as much as possible a separation between what I'm
passing upstream from the github(as a favor to him mostly) just to keep
the two trees in sync, and what I'm submitting.  I don't want the logs
to get too mixed up.  It's just a personal thing.

The sound driver enhancements where 100% original for example.  I wrote
all of that.




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


Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-03-21 Thread Russell King - ARM Linux
On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:
> @@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
>   incc = imx_media_find_mbus_format(infmt->code,
> CS_SEL_ANY, true);
>  
> - if (sdformat->format.width < priv->crop.width * 3 / 4)
> - sdformat->format.width = priv->crop.width / 2;
> - else
> - sdformat->format.width = priv->crop.width;
> -
> - if (sdformat->format.height < priv->crop.height * 3 / 4)
> - sdformat->format.height = priv->crop.height / 2;
> - else
> - sdformat->format.height = priv->crop.height;
> + sdformat->format.width = compose->width;
> + sdformat->format.height = compose->height;
>  
>   if (incc->bayer) {
>   sdformat->format.code = infmt->code;

We need to do more in here, because right now setting the source pads
overwrites the colorimetry etc information.  Maybe something like the
below?  I'm wondering if it would be a saner approach to copy the
sink format and update the parameters that can be changed, rather than
trying to list all the parameters that shouldn't be changed.  What if
the format structure gains a new member?

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1492b92e1970..756204ced53c 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1221,6 +1221,12 @@ static void csi_try_fmt(struct csi_priv *priv,
sdformat->format.field =  (infmt->height == 480) ?
V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
}
+
+   /* copy settings we can't change */
+   sdformat->format.colorspace = infmt->colorspace;
+   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
+   sdformat->format.quantization = infmt->quantization;
+   sdformat->format.xfer_func = infmt->xfer_func;
break;
case CSI_SINK_PAD:
v4l_bound_align_image(>format.width, MIN_W, MAX_W,



-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 2/2] staging: sm750fb: Remove typedefs from enum

2017-03-21 Thread Arushi Singhal
This patch removes typedefs from enum and renames them as
per kernel coding standards.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_mode.h | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 9dc4d6c5a779..d5eae36d85cb 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -3,11 +3,10 @@
 
 #include "ddk750_chip.h"
 
-typedef enum _spolarity_t {
+enum spolarity {
POS = 0, /* positive */
NEG, /* negative */
-}
-spolarity_t;
+};
 
 struct mode_parameter {
/* Horizontal timing. */
@@ -15,14 +14,14 @@ struct mode_parameter {
unsigned long horizontal_display_end;
unsigned long horizontal_sync_start;
unsigned long horizontal_sync_width;
-   spolarity_t horizontal_sync_polarity;
+   enum spolarity horizontal_sync_polarity;
 
/* Vertical timing. */
unsigned long vertical_total;
unsigned long vertical_display_end;
unsigned long vertical_sync_start;
unsigned long vertical_sync_height;
-   spolarity_t vertical_sync_polarity;
+   enum spolarity vertical_sync_polarity;
 
/* Refresh timing. */
unsigned long pixel_clock;
@@ -30,7 +29,7 @@ struct mode_parameter {
unsigned long vertical_frequency;
 
/* Clock Phase. This clock phase only applies to Panel. */
-   spolarity_t clock_phase_polarity;
+   enum spolarity clock_phase_polarity;
 };
 
 int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
-- 
2.11.0

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


[PATCH 1/2] staging: sm750fb: Remove typedefs from struct

2017-03-21 Thread Arushi Singhal
This patch removes typedefs from structure and renames them as
per kernel coding standards.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_mode.c | 8 +---
 drivers/staging/sm750fb/ddk750_mode.h | 8 +++-
 drivers/staging/sm750fb/sm750_hw.c| 2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index 37b5d4850fb9..bb673e18999b 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -12,7 +12,8 @@
  * HW only supports 7 predefined pixel clocks, and clock select is
  * in bit 29:27 of Display Control register.
  */
-static unsigned long displayControlAdjust_SM750LE(mode_parameter_t 
*pModeParam, unsigned long dispControl)
+static unsigned long displayControlAdjust_SM750LE(struct mode_parameter 
*pModeParam,
+ unsigned long dispControl)
 {
unsigned long x, y;
 
@@ -72,7 +73,8 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
 }
 
 /* only timing related registers will be  programed */
-static int programModeRegisters(mode_parameter_t *pModeParam, struct pll_value 
*pll)
+static int programModeRegisters(struct mode_parameter *pModeParam,
+   struct pll_value *pll)
 {
int ret = 0;
int cnt = 0;
@@ -203,7 +205,7 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam, struct pll_value *
return ret;
 }
 
-int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock)
+int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock)
 {
struct pll_value pll;
unsigned int uiActualPixelClk;
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 6d204b8b4a01..9dc4d6c5a779 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -9,7 +9,7 @@ typedef enum _spolarity_t {
 }
 spolarity_t;
 
-typedef struct _mode_parameter_t {
+struct mode_parameter {
/* Horizontal timing. */
unsigned long horizontal_total;
unsigned long horizontal_display_end;
@@ -31,9 +31,7 @@ typedef struct _mode_parameter_t {
 
/* Clock Phase. This clock phase only applies to Panel. */
spolarity_t clock_phase_polarity;
-}
-mode_parameter_t;
-
-int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
+};
 
+int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index fab3fc9c8330..baf1bbdc92ff 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -252,7 +252,7 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc,
 {
int ret, fmt;
u32 reg;
-   mode_parameter_t modparm;
+   struct mode_parameter modparm;
clock_type_t clock;
struct sm750_dev *sm750_dev;
struct lynxfb_par *par;
-- 
2.11.0

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


  1   2   >