Re: [PATCH] Fix checkpatch.pl error in drivers:staging:ks7010:ks_wlan_net.cGreg Kroah-Hartman

2016-09-11 Thread Greg KH
On Sun, Sep 11, 2016 at 01:39:13AM +0530, Chinmay Nivsarkar wrote:
> Fixes error foo * bar should be foo *bar in line #843
> 
> Signed-off-by: Chinmay Nivsarkar 
> ---
>  drivers/staging/ks7010/ks_wlan_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Your subject: line is very strange, please fix and resend.

thanks,

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


[PATCH] Fix checkpatch.pl error in drivers:staging:ks7010:ks_wlan_net.c

2016-09-11 Thread Chinmay Nivsarkar
Fixes error foo * bar should be foo *bar in line #843

Signed-off-by: Chinmay Nivsarkar 
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c
b/drivers/staging/ks7010/ks_wlan_net.c
index 1335677..4a6ff9d 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -840,7 +840,7 @@ static int ks_wlan_get_frag(struct net_device *dev,
 /*--*/
 /* Wireless Handler : set Mode of Operation */
 static int ks_wlan_set_mode(struct net_device *dev,
-   struct iw_request_info *info, __u32 * uwrq,
+   struct iw_request_info *info, __u32 *uwrq,
char *extra)
 {
struct ks_wlan_private *priv =
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[GIT PULL] Staging/IIO driver fixes for 4.8-rc6

2016-09-11 Thread Greg KH
The following changes since commit c6935931c1894ff857616ff8549b61236a19148f:

  Linux 4.8-rc5 (2016-09-04 14:31:46 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-4.8-rc6

for you to fetch changes up to 72d508ad488a63678396cf1039fc5a65e04caa9e:

  Merge tag 'iio-fixes-for-4.8b' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus 
(2016-09-09 13:44:37 +0200)


Staging/IIO fixes for 4.8-rc6

Here are a few small IIO fixes for 4.8-rc6.

Nothing major, full details are in the shortlog, all of these have been
in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Colin Ian King (1):
  iio: ensure ret is initialized to zero before entering do loop

Greg Kroah-Hartman (1):
  Merge tag 'iio-fixes-for-4.8b' of git://git.kernel.org/.../jic23/iio into 
staging-linus

Gregor Boirie (2):
  tools:iio:iio_generic_buffer: fix trigger-less mode
  iio:core: fix IIO_VAL_FRACTIONAL sign handling

Kweh, Hock Leong (1):
  iio: fix pressure data output unit in hid-sensor-attributes

Linus Walleij (1):
  iio: accel: kxsd9: Fix scaling bug

Olof Johansson (1):
  iio: accel: bmc150: reset chip at init time

 drivers/iio/accel/bmc150-accel-core.c  | 11 +++
 drivers/iio/accel/kxsd9.c  |  1 +
 drivers/iio/common/hid-sensors/hid-sensor-attributes.c |  4 ++--
 drivers/iio/industrialio-buffer.c  |  4 ++--
 drivers/iio/industrialio-core.c|  5 ++---
 tools/iio/iio_generic_buffer.c |  2 +-
 6 files changed, 19 insertions(+), 8 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-09-11 Thread 'Greg KH'
On Tue, Aug 30, 2016 at 04:29:07PM +, Sell, Timothy C wrote:
> E.g., so even though no obvious error-recovery occurs above in-response to
> kzalloc() failures, the fact that -CONTROLVM_RESP_ERROR_KMALLOC_FAILED is
> provided to bus_epilog() is in-fact sufficient to report the error.
> 
> Is this making sense?

Yes, it does a bit more, but, you should make this more explicit.

> Can you suggest how we might modify our code to make this error-handling /
> recovery strategy clearer?

Have a real error be returned by the function, and then have the caller
handle the error by propagating it back to the firmware through the
message.  That might save you a lot of boiler-plate error handling logic
as well, right?

That will make it obvious that if an error happens, it is caught, and
how it is handled correctly.

Does that help?

thanks,

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


[PATCH] stagging:iio:ad9834: add devicetree property support

2016-09-11 Thread Gwenhael Goavec-Merou
ad9834 driver needs some default properties. Currently these parameters are
provided through platform_data.
This patch adds a function to create this pdata based on device-tree node.

Signed-off-by: Gwenhael Goavec-Merou 
---
 drivers/staging/iio/frequency/ad9834.c | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/drivers/staging/iio/frequency/ad9834.c 
b/drivers/staging/iio/frequency/ad9834.c
index 6366216..6cec154 100644
--- a/drivers/staging/iio/frequency/ad9834.c
+++ b/drivers/staging/iio/frequency/ad9834.c
@@ -316,6 +316,39 @@ static const struct iio_info ad9833_info = {
.driver_module = THIS_MODULE,
 };
 
+#if defined(CONFIG_OF)
+static struct ad9834_platform_data *ad9834_parse_dt(struct spi_device *spi)
+{
+   struct ad9834_platform_data *pdata;
+   struct device_node *np = spi->dev.of_node;
+
+   pdata = devm_kzalloc(&spi->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   if (of_property_read_u32(np, "mclk", &pdata->mclk))
+   return ERR_PTR(-ENODEV);
+   if (of_property_read_u32(np, "freq0", &pdata->freq0))
+   return ERR_PTR(-ENODEV);
+   if (of_property_read_u32(np, "freq1", &pdata->freq1))
+   return ERR_PTR(-ENODEV);
+   if (of_property_read_u16(np, "phase0", &pdata->phase0))
+   return ERR_PTR(-ENODEV);
+   if (of_property_read_u16(np, "phase1", &pdata->phase1))
+   return ERR_PTR(-ENODEV);
+   pdata->en_div2 = of_property_read_bool(np, "en_div2");
+   pdata->en_signbit_msb_out = of_property_read_bool(np,
+   "en_signbit_msb_out");
+
+   return pdata;
+}
+#else
+static struct ad9834_platform_data *ad9834_parse_dt(struct spi_device *spi)
+{
+   return NULL;
+}
+#endif
+
 static int ad9834_probe(struct spi_device *spi)
 {
struct ad9834_platform_data *pdata = dev_get_platdata(&spi->dev);
@@ -324,6 +357,12 @@ static int ad9834_probe(struct spi_device *spi)
struct regulator *reg;
int ret;
 
+   if (!pdata && spi->dev.of_node) {
+   pdata = ad9834_parse_dt(spi);
+   if (IS_ERR(pdata))
+   return PTR_ERR(pdata);
+   }
+
if (!pdata) {
dev_dbg(&spi->dev, "no platform data?\n");
return -ENODEV;
-- 
2.9.3

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


[PATCH 00/26] constify local structures

2016-09-11 Thread Julia Lawall
Constify local structures.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
// The first rule ignores some cases that posed problems
@r disable optional_qualifier@
identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
identifier i != {s5k5baf_cis_rect,smtcfb_fix};
position p;
@@
static struct s i@p = { ... };

@lstruct@
identifier r.s;
@@
struct s { ... };

@used depends on lstruct@
identifier r.i;
@@
i

@bad1@
expression e;
identifier r.i;
assignment operator a;
@@
 (<+...i...+>) a e

@bad2@
identifier r.i;
@@
 &(<+...i...+>)

@bad3@
identifier r.i;
declarer d;
@@
 d(...,<+...i...+>,...);

@bad4@
identifier r.i;
type T;
T[] e;
identifier f;
position p;
@@

f@p(...,
(
  (<+...i...+>)
&
  e
)
,...)

@bad4a@
identifier r.i;
type T;
T *e;
identifier f;
position p;
@@

f@p(...,
(
  (<+...i...+>)
&
  e
)
,...)

@ok5@
expression *e;
identifier r.i;
position p;
@@
e =@p i

@bad5@
expression *e;
identifier r.i;
position p != ok5.p;
@@
e =@p (<+...i...+>)

@rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
identifier s,r.i;
position r.p;
@@

static
+const
 struct s i@p = { ... };

@depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
 disable optional_qualifier@
identifier rr.s,r.i;
@@

static
+const
 struct s i;
// 

---

 drivers/acpi/acpi_apd.c  |8 +++---
 drivers/char/tpm/tpm-interface.c |   10 
 drivers/char/tpm/tpm-sysfs.c |2 -
 drivers/cpufreq/intel_pstate.c   |8 +++---
 drivers/infiniband/hw/i40iw/i40iw_uk.c   |6 ++---
 drivers/media/i2c/tvp514x.c  |2 -
 drivers/media/pci/ddbridge/ddbridge-core.c   |   18 +++
 drivers/media/pci/ngene/ngene-cards.c|   14 ++--
 drivers/media/pci/smipcie/smipcie-main.c |8 +++---
 drivers/misc/sgi-xp/xpc_uv.c |2 -
 drivers/net/arcnet/com20020-pci.c|   10 
 drivers/net/can/c_can/c_can_pci.c|4 +--
 drivers/net/can/sja1000/plx_pci.c|   20 -
 drivers/net/ethernet/mellanox/mlx4/main.c|4 +--
 drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |2 -
 drivers/net/ethernet/renesas/sh_eth.c|   14 ++--
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c |2 -
 drivers/net/wireless/ath/dfs_pattern_detector.c  |2 -
 drivers/net/wireless/intel/iwlegacy/3945.c   |4 +--
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c  |2 -
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c  |2 -
 drivers/platform/chrome/chromeos_laptop.c|   22 +--
 drivers/platform/x86/intel_scu_ipc.c |6 ++---
 drivers/platform/x86/intel_telemetry_debugfs.c   |2 -
 drivers/scsi/esas2r/esas2r_flash.c   |2 -
 drivers/scsi/hptiop.c|6 ++---
 drivers/spi/spi-dw-pci.c |4 +--
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c |2 -
 drivers/usb/misc/ezusb.c |2 -
 drivers/video/fbdev/matrox/matroxfb_g450.c   |2 -
 lib/crc64_ecma.c |2 -
 sound/pci/ctxfi/ctatc.c  |2 -
 sound/pci/hda/patch_ca0132.c |   10 
 sound/pci/riptide/riptide.c  |2 -
 40 files changed, 110 insertions(+), 110 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 03/26] staging: rtl8192e: constify local structures

2016-09-11 Thread Julia Lawall
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.

Done using Coccinelle.
Based on a suggestion by Joe Perches .

Signed-off-by: Julia Lawall 

---
The semantic patch seems too long for a commit log, but is in the cover
letter.

 drivers/staging/rtl8192e/rtl8192e/rtl_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index e01fff0..4c30eea 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -38,7 +38,7 @@ static int channels = 0x3fff;
 static char *ifname = "wlan%d";
 
 
-static struct rtl819x_ops rtl819xp_ops = {
+static const struct rtl819x_ops rtl819xp_ops = {
.nic_type   = NIC_8192E,
.get_eeprom_size= rtl92e_get_eeprom_size,
.init_adapter_variable  = rtl92e_init_variables,

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


[PATCH] staging: vme/devices: vme_user.c: fix: converted decimal permissions to octal

2016-09-11 Thread Ryan Swan
From: ryan 

Ran checkpatch.pl -f vme_user.c
Fixed: ERROR: Use 4 digit octal (0777) not decimal permissions
---
 drivers/staging/vme/devices/vme_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vme/devices/vme_user.c 
b/drivers/staging/vme/devices/vme_user.c
index b95883b..5dd430f 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -773,7 +773,7 @@ static void __exit vme_user_exit(void)
 }
 
 MODULE_PARM_DESC(bus, "Enumeration of VMEbus to which the driver is 
connected");
-module_param_array(bus, int, &bus_num, 0);
+module_param_array(bus, int, &bus_num, );
 
 MODULE_DESCRIPTION("VME User Space Access Driver");
 MODULE_AUTHOR("Martyn Welch 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: gdm724x: gdm_lte: Constify gdm_netdev_ops

2016-09-11 Thread Imre Deak
Fix the following checkpatch.pl warning:
WARNING: struct net_device_ops should normally be const
+static struct net_device_ops gdm_netdev_ops = {

Signed-off-by: Imre Deak 
---
 drivers/staging/gdm724x/gdm_lte.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gdm724x/gdm_lte.c 
b/drivers/staging/gdm724x/gdm_lte.c
index bb55219..e72dfa9 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -828,7 +828,7 @@ void start_rx_proc(struct phy_dev *phy_dev)
rx_complete, phy_dev, USB_COMPLETE);
 }
 
-static struct net_device_ops gdm_netdev_ops = {
+static const struct net_device_ops gdm_netdev_ops = {
.ndo_open   = gdm_lte_open,
.ndo_stop   = gdm_lte_close,
.ndo_set_config = gdm_lte_set_config,
-- 
2.5.0

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


Re: [PATCH 00/26] constify local structures

2016-09-11 Thread Jarkko Sakkinen
On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> Constify local structures.
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)

Just my two cents but:

1. You *can* use a static analysis too to find bugs or other issues.
2. However, you should manually do the commits and proper commit
   messages to subsystems based on your findings. And I generally think
   that if one contributes code one should also at least smoke test changes
   somehow.

I don't know if I'm alone with my opinion. I just think that one should
also do the analysis part and not blindly create and submit patches.

Anyway, I'll apply the TPM change at some point. As I said they were
for better. Thanks.

/Jarkko

> // 
> // The first rule ignores some cases that posed problems
> @r disable optional_qualifier@
> identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
> identifier i != {s5k5baf_cis_rect,smtcfb_fix};
> position p;
> @@
> static struct s i@p = { ... };
> 
> @lstruct@
> identifier r.s;
> @@
> struct s { ... };
> 
> @used depends on lstruct@
> identifier r.i;
> @@
> i
> 
> @bad1@
> expression e;
> identifier r.i;
> assignment operator a;
> @@
>  (<+...i...+>) a e
> 
> @bad2@
> identifier r.i;
> @@
>  &(<+...i...+>)
> 
> @bad3@
> identifier r.i;
> declarer d;
> @@
>  d(...,<+...i...+>,...);
> 
> @bad4@
> identifier r.i;
> type T;
> T[] e;
> identifier f;
> position p;
> @@
> 
> f@p(...,
> (
>   (<+...i...+>)
> &
>   e
> )
> ,...)
> 
> @bad4a@
> identifier r.i;
> type T;
> T *e;
> identifier f;
> position p;
> @@
> 
> f@p(...,
> (
>   (<+...i...+>)
> &
>   e
> )
> ,...)
> 
> @ok5@
> expression *e;
> identifier r.i;
> position p;
> @@
> e =@p i
> 
> @bad5@
> expression *e;
> identifier r.i;
> position p != ok5.p;
> @@
> e =@p (<+...i...+>)
> 
> @rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
> identifier s,r.i;
> position r.p;
> @@
> 
> static
> +const
>  struct s i@p = { ... };
> 
> @depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
>  disable optional_qualifier@
> identifier rr.s,r.i;
> @@
> 
> static
> +const
>  struct s i;
> // 
> 
> ---
> 
>  drivers/acpi/acpi_apd.c  |8 +++---
>  drivers/char/tpm/tpm-interface.c |   10 
>  drivers/char/tpm/tpm-sysfs.c |2 -
>  drivers/cpufreq/intel_pstate.c   |8 +++---
>  drivers/infiniband/hw/i40iw/i40iw_uk.c   |6 ++---
>  drivers/media/i2c/tvp514x.c  |2 -
>  drivers/media/pci/ddbridge/ddbridge-core.c   |   18 +++
>  drivers/media/pci/ngene/ngene-cards.c|   14 ++--
>  drivers/media/pci/smipcie/smipcie-main.c |8 +++---
>  drivers/misc/sgi-xp/xpc_uv.c |2 -
>  drivers/net/arcnet/com20020-pci.c|   10 
>  drivers/net/can/c_can/c_can_pci.c|4 +--
>  drivers/net/can/sja1000/plx_pci.c|   20 -
>  drivers/net/ethernet/mellanox/mlx4/main.c|4 +--
>  drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |2 -
>  drivers/net/ethernet/renesas/sh_eth.c|   14 ++--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c |2 -
>  drivers/net/wireless/ath/dfs_pattern_detector.c  |2 -
>  drivers/net/wireless/intel/iwlegacy/3945.c   |4 +--
>  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c  |2 -
>  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c  |2 -
>  drivers/platform/chrome/chromeos_laptop.c|   22 
> +--
>  drivers/platform/x86/intel_scu_ipc.c |6 ++---
>  drivers/platform/x86/intel_telemetry_debugfs.c   |2 -
>  drivers/scsi/esas2r/esas2r_flash.c   |2 -
>  drivers/scsi/hptiop.c|6 ++---
>  drivers/spi/spi-dw-pci.c |4 +--
>  drivers/staging/rtl8192e/rtl8192e/rtl_core.c |2 -
>  drivers/usb/misc/ezusb.c |2 -
>  drivers/video/fbdev/matrox/matroxfb_g450.c   |2 -
>  lib/crc64_ecma.c |2 -
>  sound/pci/ctxfi/ctatc.c  |2 -
>  sound/pci/hda/patch_ca0132.c |   10 
>  sound/pci/riptide/riptide.c  |2 -
>  40 files changed, 110 insertions(+), 110 deletions(-)
_

RE: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-09-11 Thread Sell, Timothy C
On Sun, 11 Sep 2016 02:17:10 -0700, Greg KH wrote:
> On Tue, Aug 30, 2016 at 04:29:07PM +, Sell, Timothy C wrote:
>> E.g., so even though no obvious error-recovery occurs above in-response to
>> kzalloc() failures, the fact that -CONTROLVM_RESP_ERROR_KMALLOC_FAILED is
>> provided to bus_epilog() is in-fact sufficient to report the error.
>> 
>> Is this making sense?

> Yes, it does a bit more, but, you should make this more explicit.

Agreed.  I believe your recommendation below is the right way to accomplish
this.

>> Can you suggest how we might modify our code to make this error-handling /
>> recovery strategy clearer?

> Have a real error be returned by the function, and then have the caller
> handle the error by propagating it back to the firmware through the
> message.  That might save you a lot of boiler-plate error handling logic
> as well, right?

> That will make it obvious that if an error happens, it is caught, and
> how it is handled correctly.

> Does that help?

Yes it does.  We'll work out a scheme where all of these functions in fact
return their status code to a common dispatch function, whose job it will
be to send this status code back to the firmware.  This might even let us
consolidate/eliminate a few of the other functions we have that deal with
various ways of formatting firmware responses, by encompassing their logic
into this common dispatch function.

That strategy should make it clearer and more explicit as to what is
going on here.

Thanks!

Tim Sell

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


Re: [PATCH 00/26] constify local structures

2016-09-11 Thread Joe Perches
On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> Constify local structures.

Thanks Julia.

A few suggestions & questions:

Perhaps the script should go into scripts/coccinelle/
so that future cases could be caught by the robot
and commit message referenced by the patch instances.

Can you please compile the files modified using the
appropriate defconfig/allyesconfig and show the
movement from data to const by using
$ size .new/old
and include that in the changelogs (maybe next time)?

Is it possible for a rule to trace the instances where
an address of a struct or struct member is taken by
locally defined and declared function call where the
callee does not modify any dereferenced object?

ie:

struct foo {
int bar;
char *baz;
};

struct foo qux[] = {
{ 1, "description 1" },
{ 2, "dewcription 2" },
[ n, "etc" ]...,
};

void message(struct foo *msg)
{
printk("%d %s\n", msg->bar, msg->baz);
}

where some code uses

message(qux[index]);

So could a coccinelle script change:

struct foo qux[] = { to const struct foo quz[] = {

and

void message(struct foo *msg) to void message(const struct foo *msg)

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


Re: [PATCH 00/26] constify local structures

2016-09-11 Thread Julia Lawall

On Sun, 11 Sep 2016, Joe Perches wrote:

> On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> > Constify local structures.
>
> Thanks Julia.
>
> A few suggestions & questions:
>
> Perhaps the script should go into scripts/coccinelle/
> so that future cases could be caught by the robot
> and commit message referenced by the patch instances.

OK.

> Can you please compile the files modified using the
> appropriate defconfig/allyesconfig and show the

I currently send patches for this issue only for files that compile using
the x86 allyesconfig.

> movement from data to const by using
>   $ size .new/old
> and include that in the changelogs (maybe next time)?

OK, thanks for the suggestion.

> Is it possible for a rule to trace the instances where
> an address of a struct or struct member is taken by
> locally defined and declared function call where the
> callee does not modify any dereferenced object?
>
> ie:
>
> struct foo {
>   int bar;
>   char *baz;
> };
>
> struct foo qux[] = {
>   { 1, "description 1" },
>   { 2, "dewcription 2" },
>   [ n, "etc" ]...,
> };
>
> void message(struct foo *msg)
> {
>   printk("%d %s\n", msg->bar, msg->baz);
> }
>
> where some code uses
>
>   message(qux[index]);
>
> So could a coccinelle script change:
>
> struct foo qux[] = { to const struct foo quz[] = {
>
> and
>
> void message(struct foo *msg) to void message(const struct foo *msg)

Yes, this could be possible too.

Thanks for the feedback.

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


Re: [PATCH] staging: vme/devices: vme_user.c: fix: converted decimal permissions to octal

2016-09-11 Thread Greg KH
On Sun, Sep 11, 2016 at 12:21:09PM -0400, Ryan Swan wrote:
> From: ryan 

This needs to match your From: email line.

> 
> Ran checkpatch.pl -f vme_user.c
> Fixed: ERROR: Use 4 digit octal (0777) not decimal permissions

No signed-off-by?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: vme/devices: vme_user.c: fix: converted decimal permissions to octal

2016-09-11 Thread Ryan Swan
From: ryan 

Ran checkpatch.pl -f vme_user.c
Fixed: ERROR: Use 4 digit octal (0777) not decimal permissions

Signed-off-by: Ryan Swan 
---
 drivers/staging/vme/devices/vme_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vme/devices/vme_user.c 
b/drivers/staging/vme/devices/vme_user.c
index b95883b..5dd430f 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -773,7 +773,7 @@ static void __exit vme_user_exit(void)
 }
 
 MODULE_PARM_DESC(bus, "Enumeration of VMEbus to which the driver is 
connected");
-module_param_array(bus, int, &bus_num, 0);
+module_param_array(bus, int, &bus_num, );
 
 MODULE_DESCRIPTION("VME User Space Access Driver");
 MODULE_AUTHOR("Martyn Welch http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: vme/devices: vme_user.c: fix: converted decimal permissions to octal

2016-09-11 Thread Greg KH
On Sun, Sep 11, 2016 at 03:40:30PM -0400, Ryan Swan wrote:
> From: ryan 

If your email client is ok (and yours seems to be), you don't need this
line as it would rename the author of the patch.  This name needs to
match the signed-off-by: line exactly.

> 
> Ran checkpatch.pl -f vme_user.c
> Fixed: ERROR: Use 4 digit octal (0777) not decimal permissions
> 
> Signed-off-by: Ryan Swan 
> ---
>  drivers/staging/vme/devices/vme_user.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Third time's a charm?

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