RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure

2014-11-28 Thread Dexuan Cui 
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, November 28, 2014 14:47 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer
> failure
> On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui  wrote:
> > In the case the user-space daemon crashes, hangs or is killed, we
> > need to down the semaphore, otherwise, after the daemon starts next
> > time, the obsolete data in fcopy_transaction.message or
> > fcopy_transaction.fcopy_msg will be used immediately.
> >
> > Cc: Jason Wang 
> > Cc: Vitaly Kuznetsov 
> > Cc: K. Y. Srinivasan 
> > Signed-off-by: Dexuan Cui 
> > ---
> >
> > v2: I removed the "FCP" prefix as Greg asked.
> >
> > I also updated the output message a little:
> > "FCP: failed to acquire the semaphore" -->
> > "can not acquire the semaphore: it is benign"
> >
> > v3: I added the code in fcopy_release() as Jason Wang suggested.
> > I removed the pr_debug (it isn't so meaningful)and added a
> > comment instead.
> >
> >  drivers/hv/hv_fcopy.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> > index 23b2ce2..faa6ba6 100644
> > --- a/drivers/hv/hv_fcopy.c
> > +++ b/drivers/hv/hv_fcopy.c
> > @@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct
> > *dummy)
> >  * process the pending transaction.
> >  */
> > fcopy_respond_to_host(HV_E_FAIL);
> > +
> > +   /* In the case the user-space daemon crashes, hangs or is killed, we
> > +* need to down the semaphore, otherwise, after the daemon starts
> > next
> > +* time, the obsolete data in fcopy_transaction.message or
> > +* fcopy_transaction.fcopy_msg will be used immediately.
> > +*
> > +* NOTE: fcopy_read() happens to get the semaphore (very rare)?
> > We're
> > +* still OK, because we've reported the failure to the host.
> > +*/
> > +   if (down_trylock(&fcopy_transaction.read_sema))
> > +   ;
> 
> Sorry, I'm not quite understand how if () ; can help here.
> 
> Btw, a question not relate to this patch.
> 
> What happens if a daemon is resume from SIGSTOP and expires the check
> here?
Hi Jason,
My idea is: here we need down_trylock(), but in case we can't get the
semaphore, it's OK anyway:

Scenario 1):
1.1: when the daemon is blocked on the pread(), the daemon receives SIGSTOP;
1.2: the host user runs the PowerShell Copy-VMFile command;
1.3.1: the driver reports the failure to the host user in 5s and
1.3.2: the driver down()-es the semaphore;
1.4: the daemon receives SIGCONT and it will be still blocked on the pread().
Without the down_trylock(), in 1.4, the daemon can receive an obsolete message.
NOTE: in this scenario, the daemon is not killed.

Scenario 2):
In senario 1), if the daemon receives SIGCONT between 1.3.1 and 1.3.2 and
do down() in fcopy_read(), it will receive the message but: the driver has
reported the failure to the host user and the driver's 1.3.2 can't get the
semaphore -- IMO this is acceptably OK, though in the VM, an incomplete
file will be left there.
BTW, I think in the daemon's hv_start_fcopy() we should add a
close(target_fd) before open()-ing a new one.

> >
> > +
> >  }
> >
> >  static int fcopy_handle_handshake(u32 version)
> > @@ -351,6 +363,13 @@ static int fcopy_release(struct inode *inode,
> > struct file *f)
> >  */
> > in_hand_shake = true;
> > opened = false;
> > +
> > +   if (cancel_delayed_work_sync(&fcopy_work)) {
> > +   /* We haven't up()-ed the semaphore(very rare)? */
> > +   if (down_trylock(&fcopy_transaction.read_sema))
> > +   ;
> 
> And this.

Scenario 3):
When the daemon exits(e.g., SIGKILL received), if there is a fcopy_work
pending (scheduled but not start to run yet), we should cancel the
work (as you suggested) and down() the semaphore, otherwise, the
obsolete message will be received by the next instance of the daemon.

Scenario 4):  in the driver's hv_fcopy_onchannelcallback():
schedule_delayed_work(&fcopy_work, 5*HZ);
> if fcopy_release() is running on another vcpu, just before the 
next line?
fcopy_send_data();

In this case, fcopy_release() can cancel fcopy_work, but
can't get the semaphore since it hasn't been up()-ed.
Hmm, in this case,   fcopy_send_data() will do up()  later, and we'll
buffer an obsolete message in the driver, and the message will be
fetched by the next instance of the daemon... 

Looks we need a spinlock here?

Please share your idea.

> >
> > +   fcopy_respond_to_host(HV_E_FAIL);
> > +   }
> > return 0;
> >  }
> >
> > --
> > 1.9.1
> >

-- Dexuan

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriv

Re: [PATCH 1/2] mfd: rtsx: add func to split u32 into register

2014-11-28 Thread Dan Carpenter 
On Fri, Nov 28, 2014 at 02:10:36AM +, 敬锐 wrote:
> eg, in sd_ops.c the cmd.arg is constructed bit by bit, we can put the right
> byte to the right register by shift, so the endian check is not need.

I looked at drivers/mmc/core/sd_ops.c and cmd.arg seems to be cpu
endian.

The new function assumes that the cpu is little endian and manually
converts it to little endian.  This is an endian bug.  I think my fix is
correct or something similar.

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

Re: [PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

2014-11-28 Thread Andy Yan 

Hi Zabel:
On 2014年11月27日 00:34, Philipp Zabel wrote:

Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan:

On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width accesses (writeb,
readb) generate an imprecise external abort.

Signed-off-by: Andy Yan 

---

Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4: None
Changes in v3:
- split multi-register access to one indepent patch

  drivers/gpu/drm/bridge/dw_hdmi.c | 57 +++-
  1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index a53bf63..5e88c8d 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -100,6 +100,11 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
  };
  
+union dw_reg_ptr {

+   u32 __iomem *p32;
+   u8 __iomem *p8;
+};

I see no need to introduce this. Just explicitly multiply the offset in
dw_hdmi_writel.


Is there any disadvantage to do like this?
The compiler can help us do the explicitly multiply by this way.

  struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -121,20 +126,43 @@ struct dw_hdmi {
  
  	struct regmap *regmap;

struct i2c_adapter *ddc;
-   void __iomem *regs;
+   union dw_reg_ptr regs;

Keep this as void __iomem *


unsigned int sample_rate;
int ratio;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
  };
  
+static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)

+{
+   writel(val, hdmi->regs.p32 + offset);

hdmi->regs + 4 * offset


+}
+
+static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
+{
+   return readl(hdmi->regs.p32 + offset);

same here


+}
+
+static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writeb(val, hdmi->regs.p8 + offset);
+}
+
+static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
+{
+   return readb(hdmi->regs.p8 + offset);
+}
+
  static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
  {
-   writeb(val, hdmi->regs + offset);
+   hdmi->write(hdmi, val, offset);
  }
  
  static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)

  {
-   return readb(hdmi->regs + offset);
+   return hdmi->read(hdmi, offset);
  }

  static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
@@ -1508,6 +1536,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
struct dw_hdmi *hdmi;
struct resource *iores;
int ret, irq;
+   u32 val = 1;
  
  	hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);

if (!hdmi)
@@ -1520,6 +1549,22 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
hdmi->ratio = 100;
hdmi->encoder = encoder;
  
+	of_property_read_u32(np, "reg-io-width", &val);

+
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   break;
+   case 1:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+   return -EINVAL;
+   }
+
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
@@ -1544,9 +1589,9 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
return ret;
  
  	iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-   hdmi->regs = devm_ioremap_resource(dev, iores);
-   if (IS_ERR(hdmi->regs))
-   return PTR_ERR(hdmi->regs);
+   hdmi->regs.p32 = devm_ioremap_resource(dev, iores);
+   if (IS_ERR(hdmi->regs.p32))
+   return PTR_ERR(hdmi->regs.p32);
  
  	/* Product and revision IDs */

dev_info(dev,

regards
Philipp






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

Re: [PATCH v13 08/12] drm: bridge/dw_hdmi: add mode_valid support

2014-11-28 Thread Andy Yan 

Hi Philipp:

On 2014年11月27日 00:23, Philipp Zabel wrote:

Am Mittwoch, den 26.11.2014, 21:33 +0800 schrieb Andy Yan:

some platform may not support all the display mode,
add mode_valid interface check it

also add drm_connector_register which add a debugfs
interface for dump display modes and edid information

Signed-off-by: Andy Yan 
---

Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

  drivers/gpu/drm/bridge/dw_hdmi.c | 17 +
  include/drm/bridge/dw_hdmi.h |  2 ++
  2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 5e88c8d..b13e782 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1406,6 +1406,20 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return 0;
  }
  
+static enum drm_mode_status

+dw_hdmi_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = container_of(connector,
+  struct dw_hdmi, connector);
+   enum drm_mode_status mode_status = MODE_OK;
+
+   if (hdmi->plat_data->mode_valid)
+   mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+   return mode_status;
+}
+
  static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector
   *connector)
  {
@@ -1430,6 +1444,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs 
= {
  
  static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {

.get_modes = dw_hdmi_connector_get_modes,
+   .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
  };
  
@@ -1631,6 +1646,8 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
  
  	dev_set_drvdata(dev, hdmi);
  
+	drm_connector_register(&hdmi->connector);

+

This is not right, the connector is registered by the imx-drm core in
the drm_driver .load callback.

Sorry, I didn't found imx-drm core has did that before.And I found many
connector drivers register it by itself.
   This will be removed in next patch.

regards
Philipp







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

Re: [PATCH v13 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

2014-11-28 Thread Andy Yan 

Hi Philipp:

On 2014年11月27日 00:20, Philipp Zabel wrote:

Hi Andy,

I have yet to look at this in more detail, but from a quick test
starting with patch 3, the HDMI display stays black on Nitrogen6X,
and starting with patch 8 I get the following error.

imx-drm display-subsystem: [CONNECTOR:21:HDMI-A-1] drm_connector_register 
failed: -12
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 __clk_disable+0x6c/0x70()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6+ #8377
Backtrace:
[<80012414>] (dump_backtrace) from [<80012754>] (show_stack+0x20/0x24)
  r6:0353 r5: r4:8083ea08 r3:
[<80012734>] (show_stack) from [<805ae670>] (dump_stack+0x8c/0x9c)
[<805ae5e4>] (dump_stack) from [<80022744>] (warn_slowpath_common+0x80/0x9c)
  r5:0009 r4:
[<800226c4>] (warn_slowpath_common) from [<8002281c>] 
(warn_slowpath_null+0x2c/0x34)
  r8:b721c610 r7:b72b0400 r6:b735504c r5:8113 r4:b735504c
[<800227f0>] (warn_slowpath_null) from [<80458088>] (__clk_disable+0x6c/0x70)
[<8045801c>] (__clk_disable) from [<804581a8>] (clk_disable+0x34/0x40)
  r4:b735504c r3:b700e000
[<80458174>] (clk_disable) from [<803241f0>] (dw_hdmi_imx_unbind+0x30/0x60)
  r5:b7355010 r4:b7219a10
[<803241c0>] (dw_hdmi_imx_unbind) from [<8032fc84>] 
(component_unbind.isra.3+0x40/0x78)
  r8:b72a1e40 r7:b725f158 r6:b72b0400 r5:b725f158 r4:b725f4c0 r3:803241c0
[<8032fc44>] (component_unbind.isra.3) from [<8032fd44>] 
(component_unbind_all+0x88/0xb8)
  r5:b725f4c0 r4:b725f140
[<8032fcbc>] (component_unbind_all) from [<80321a3c>] 
(imx_drm_driver_load+0x100/0x13c)
  r7:b72b05cc r6:fff4 r5:b7355010 r4:b72b0400
[<8032193c>] (imx_drm_driver_load) from [<8030c260>] 
(drm_dev_register+0xb8/0x114)
  r7:b686ad10 r6: r5: r4:b72b0400
[<8030c1a8>] (drm_dev_register) from [<8030dd58>] (drm_platform_init+0x54/0xe8)
  r6:80844bf4 r5:b721c600 r4:b72b0400 r3:
[<8030dd04>] (drm_platform_init) from [<803218e8>] (imx_drm_bind+0x20/0x28)
  r6:b725f140 r5:000c r4:b686ad70
[<803218c8>] (imx_drm_bind) from [<8032f9b0>] 
(try_to_bring_up_master.part.2+0xd8/0x118)
[<8032f8d8>] (try_to_bring_up_master.part.2) from [<8032fbe4>] 
(component_add+0xa0/0x100)
  r8:b72a1c40 r7:80602b6c r6:b72a1e40 r5:808451e8 r4:b725f140 r3:
[<8032fb44>] (component_add) from [<8032330c>] (ipu_drm_probe+0x7c/0x150)
  r7:b682ba10 r6:b77b3cc0 r5:b682ba00 r4:b77b4868
[<80323290>] (ipu_drm_probe) from [<80336640>] (platform_drv_probe+0x54/0xb4)
  r9: r8: r7:80844e94 r6:80844e94 r5:fdfb r4:b682ba10
[<803365ec>] (platform_drv_probe) from [<803348a8>] 
(driver_probe_device+0x128/0x25c)
  r7:80844e94 r6: r5:808bc064 r4:b682ba10
[<80334780>] (driver_probe_device) from [<80334a2c>] (__device_attach+0x50/0x54)
  r8: r7:b721c410 r6:803349dc r5:b682ba10 r4:80844e94 r3:80336838
[<803349dc>] (__device_attach) from [<80332c34>] (bus_for_each_drv+0x68/0x9c)
  r5:b682ba10 r4:
[<80332bcc>] (bus_for_each_drv) from [<8033473c>] (device_attach+0x84/0x98)
  r6:808454e0 r5:b682ba44 r4:b682ba10
[<803346b8>] (device_attach) from [<80333d14>] (bus_probe_device+0x94/0xb8)
  r6:808454e0 r5:b682ba10 r4:b682ba18 r3:b7046800
[<80333c80>] (bus_probe_device) from [<80331e58>] (device_add+0x450/0x530)
  r6:b682ba10 r5: r4:b682ba18 r3:
[<80331a08>] (device_add) from [<803362c8>] (platform_device_add+0xc4/0x228)
  r9:0006 r8:b721c410 r7:b7079cc4 r6:b682ba10 r5:b682ba00 r4:
[<80336204>] (platform_device_add) from [<80336b60>] 
(platform_device_register_full+0xcc/0xf0)
  r7:b7079cc4 r6:b7079ce0 r5:b682ba00 r4:b7079ce0
[<80336a94>] (platform_device_register_full) from [<80328354>] 
(ipu_add_client_devices.isra.10+0x164/0x19c)
  r5: r4:b7079ce0
[<803281f0>] (ipu_add_client_devices.isra.10) from [<80328940>] 
(ipu_probe+0x5b4/0x740)
  r10:808450d4 r9:0001 r8:b7028180 r7:b72b0010 r6:808450d4 r5:
  r4:b721c410
[<8032838c>] (ipu_probe) from [<80336640>] (platform_drv_probe+0x54/0xb4)
  r10: r9:b725f580 r8: r7:80845078 r6:80845078 r5:fdfb
  r4:b721c410
[<803365ec>] (platform_drv_probe) from [<803348a8>] 
(driver_probe_device+0x128/0x25c)
  r7:80845078 r6: r5:808bc064 r4:b721c410
[<80334780>] (driver_probe_device) from [<80334acc>] (__driver_attach+0x9c/0xa0)
  r8:807ab5e8 r7: r6:b721c444 r5:80845078 r4:b721c410 r3:
[<80334a30>] (__driver_attach) from [<80332b6c>] (bus_for_each_dev+0x70/0xa4)
  r6:80334a30 r5:80845078 r4: r3:b704685c
[<80332afc>] (bus_for_each_dev) from [<80334334>] (driver_attach+0x2c/0x30)
  r6:808454e0 r5:b728d000 r4:80845078
[<80334308>] (driver_attach) from [<80333fac>] (bus_add_driver+0x15c/0x204)
[<80333e50>] (bus_add_driver) from [<803352d4>] (driver_register+0x88/0x108)
  r7:b7078000 r6:807d86c0 r5:8082be60 r4:80845078
[<8033524c>] (driver_register) from [<8033656c>] 
(__platform_driver_register+0x64/0x6c)
  r5:8082be60 r4:8082be60
[<80336508>] (__platform_dr

Re: [PATCH] staging: lustre: fix sparse warnings related to lock context imbalance

2014-11-28 Thread Dan Carpenter 
On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> 1827 if (valid != 0) {
> 1828 cl_object_attr_lock(obj);
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 cl_object_attr_unlock(obj);
> 
> after:
> 
> 1827 if (valid != 0) {
> 1828 spin_lock(cl_object_attr_guard(obj));
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 spin_unlock(cl_object_attr_guard(obj));

The word "_object" doesn't add any new information to the name.  If you
remove it then the code is improved.

spin_lock(cl_attr_guard(obj));
cl_attr_set(env, obj, attr, valid);
spin_unlock(cl_attr_guard(obj));


regards,
dan carpenter

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

Re: [PATCH 1/2] mfd: rtsx: add func to split u32 into register

2014-11-28 Thread 敬锐 
Let's take an example,

cmd.arg = ((ocr & 0xFF8000) != 0) << 8 | test_pattern;

using "TP" name test_pattern for simplication ,
when we call: rtsx_pci_write_be32(pcr, SD_CMD1, cmd->arg);
we should make sure TP write to SD_CMD4.

If on "be" platform, then cpu_to_be32() do nothing,
and TP is write to SD_CMD1, in this case, it is wrong.

BR,
micky.
On 11/27/2014 11:23 PM, Dan Carpenter wrote:
> On Thu, Nov 27, 2014 at 10:53:58AM +0800, micky_ch...@realsil.com.cn wrote:
>> +static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32 
>> val)
>> +{
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
> This assumes the cpu is little endian.  First convert to big endian
> using cpu_to_be32() and then write it out.
>
>   __be32 be_val = cpu_to_be32()
>
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, be_val);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, be_val >> 8);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, be_val >> 16);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, be_val >> 24);
>
> (Written hurredly in my mail client.  May be wrong).
>
>> +}
>> +
>> +static inline void rtsx_pci_write_le32(struct rtsx_pcr *pcr, u16 reg, u32 
>> val)
>> +{
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 8);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 16);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val >> 24);
>> +}
> We don't have a user for rtsx_pci_write_le32() so don't add it.
>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure

2014-11-28 Thread Jason Wang 



On Fri, Nov 28, 2014 at 4:36 PM, Dexuan Cui  wrote:

 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Friday, November 28, 2014 14:47 PM
 To: Dexuan Cui
 Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; 
driverdev-

 de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
 Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
 Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on 
transfer

 failure
 On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui  
wrote:

 > In the case the user-space daemon crashes, hangs or is killed, we
 > need to down the semaphore, otherwise, after the daemon starts 
next

 > time, the obsolete data in fcopy_transaction.message or
 > fcopy_transaction.fcopy_msg will be used immediately.
 >
 > Cc: Jason Wang 
 > Cc: Vitaly Kuznetsov 
 > Cc: K. Y. Srinivasan 
 > Signed-off-by: Dexuan Cui 
 > ---
 >
 > v2: I removed the "FCP" prefix as Greg asked.
 >
 > I also updated the output message a little:
 > "FCP: failed to acquire the semaphore" -->
 > "can not acquire the semaphore: it is benign"
 >
 > v3: I added the code in fcopy_release() as Jason Wang suggested.
 > I removed the pr_debug (it isn't so meaningful)and added a
 > comment instead.
 >
 >  drivers/hv/hv_fcopy.c | 19 +++
 >  1 file changed, 19 insertions(+)
 >
 > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
 > index 23b2ce2..faa6ba6 100644
 > --- a/drivers/hv/hv_fcopy.c
 > +++ b/drivers/hv/hv_fcopy.c
 > @@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct
 > *dummy)
 >* process the pending transaction.
 >*/
 >   fcopy_respond_to_host(HV_E_FAIL);
 > +
 > +	/* In the case the user-space daemon crashes, hangs or is 
killed, we
 > +	 * need to down the semaphore, otherwise, after the daemon 
starts

 > next
 > +  * time, the obsolete data in fcopy_transaction.message or
 > +  * fcopy_transaction.fcopy_msg will be used immediately.
 > +  *
 > +  * NOTE: fcopy_read() happens to get the semaphore (very rare)?
 > We're
 > +  * still OK, because we've reported the failure to the host.
 > +  */
 > + if (down_trylock(&fcopy_transaction.read_sema))
 > + ;
 
 Sorry, I'm not quite understand how if () ; can help here.
 
 Btw, a question not relate to this patch.
 
 What happens if a daemon is resume from SIGSTOP and expires the 
check

 here?

Hi Jason,
My idea is: here we need down_trylock(), but in case we can't get the
semaphore, it's OK anyway:

Scenario 1):
1.1: when the daemon is blocked on the pread(), the daemon receives 
SIGSTOP;

1.2: the host user runs the PowerShell Copy-VMFile command;
1.3.1: the driver reports the failure to the host user in 5s and
1.3.2: the driver down()-es the semaphore;
1.4: the daemon receives SIGCONT and it will be still blocked on the 
pread().
Without the down_trylock(), in 1.4, the daemon can receive an 
obsolete message.

NOTE: in this scenario, the daemon is not killed.

Scenario 2):
In senario 1), if the daemon receives SIGCONT between 1.3.1 and 1.3.2 
and
do down() in fcopy_read(), it will receive the message but: the 
driver has
reported the failure to the host user and the driver's 1.3.2 can't 
get the
semaphore -- IMO this is acceptably OK, though in the VM, an 
incomplete

file will be left there.
BTW, I think in the daemon's hv_start_fcopy() we should add a
close(target_fd) before open()-ing a new one.


Right, but how about the case when resuming from SIGSTOP but no timeout?

Looks like in this case userspace() may wait in down_interruptible() 
until timeout. We probably need something like this:


   if (down_interruptible(&fcopy_transaction.read_sema)) {
   up(&fcopy_transaction.read_sema);
   return -EINTR;
   }

This should synchronize with the timeout work for sure.
But how about only schedule it after this?
It does not may sense to start the timer during interrupt
since the file may not even opened and it may take time
to handle signals?




 >
 > +
 >  }
 >
 >  static int fcopy_handle_handshake(u32 version)
 > @@ -351,6 +363,13 @@ static int fcopy_release(struct inode *inode,
 > struct file *f)
 >*/
 >   in_hand_shake = true;
 >   opened = false;
 > +
 > + if (cancel_delayed_work_sync(&fcopy_work)) {
 > + /* We haven't up()-ed the semaphore(very rare)? */
 > + if (down_trylock(&fcopy_transaction.read_sema))
 > + ;
 
 And this.


Scenario 3):
When the daemon exits(e.g., SIGKILL received), if there is a 
fcopy_work

pending (scheduled but not start to run yet), we should cancel the
work (as you suggested) and down() the semaphore, otherwise, the
obsolete message will be received by the next instance of the daemon.


Yes



Scenario 4):  in the driver's hv_fcopy_onchannelcallback():
schedule_delayed_work(&fcopy_work, 5*HZ);
> if fcopy_release() is running on another vcpu, just 
before the next line?

fcopy_send_data();

In this case, fcopy_release() can cancel

Re: [PATCH v2] staging: octeon: Fix checkpatch warnings

2014-11-28 Thread Dan Carpenter 
On Thu, Nov 27, 2014 at 05:18:10PM +0100, Luis de Bethencourt wrote:
> Fixing 80 character limit warnings in octeon/ethernet-rx.c
> 
> Signed-off-by: Luis de Bethencourt 
> ---
>  drivers/staging/octeon/ethernet-rx.c | 51 
> +---
>  1 file changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/staging/octeon/ethernet-rx.c 
> b/drivers/staging/octeon/ethernet-rx.c
> index 1789a12..e387eb1 100644
> --- a/drivers/staging/octeon/ethernet-rx.c
> +++ b/drivers/staging/octeon/ethernet-rx.c
> @@ -109,6 +109,7 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t 
> *work)
>   int interface = cvmx_helper_get_interface_num(work->ipprt);
>   int index = cvmx_helper_get_interface_index_num(work->ipprt);
>   union cvmx_gmxx_rxx_frm_ctl gmxx_rxx_frm_ctl;
> +

Do this in a separate patch.

> @@ -332,8 +343,10 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, 
> int budget)
>   skb->protocol = eth_type_trans(skb, dev);
>   skb->dev = dev;
>  
> - if (unlikely(work->word2.s.not_IP || 
> work->word2.s.IP_exc ||
> - work->word2.s.L4_error || 
> !work->word2.s.tcp_or_udp))
> + if (unlikely(work->word2.s.not_IP ||
> + work->word2.s.IP_exc ||
> + work->word2.s.L4_error ||
> + !work->word2.s.tcp_or_udp))
>   skb->ip_summed = CHECKSUM_NONE;

Your patch aligns everything with tabs but it should be slightly
different.  Run your patch through checkpatch.pl --strict to see what I
mean and then redo it all.  This one should look like:

if (unlikely(work->word2.s.not_IP ||
 work->word2.s.IP_exc ||
 work->word2.s.L4_error ||
 !work->word2.s.tcp_or_udp))
skb->ip_summed = CHECKSUM_NONE;

[tab][tab][tab][tab][tab][space][space][space][space][space]work->...

regards,
dan carpenter


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

Re: [PATCH] Drivers:staging:octeon: Fixed checkpatch warning

2014-11-28 Thread Dan Carpenter 
On Thu, Nov 27, 2014 at 05:42:06PM +0530, Athira Lekshmi C V wrote:
> C V is my initals . Can I just go with the name Athira Lekshmi ?
> 

Sign it like you would sign a legal document.

In American, that's normally Firstname Lastname but if you normally sign a legal
document with C V on the end in India then probably "C V" is ok, it's just not
normal in America so we have to ask.

regards,
dan carpenter

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

[PATCH] Drivers:staging:octeon: Fixed checkpatch warning

2014-11-28 Thread Athira Lekshmi 
Fixed the checkpatch warning:
Missing a blank line after declarations

Signed-off-by: Athira Lekshmi 
---
 drivers/staging/octeon/ethernet-rx.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/octeon/ethernet-rx.c 
b/drivers/staging/octeon/ethernet-rx.c
index 44e372f..220106e 100644
--- a/drivers/staging/octeon/ethernet-rx.c
+++ b/drivers/staging/octeon/ethernet-rx.c
@@ -84,6 +84,7 @@ static int cvm_irq_cpu;
 static void cvm_oct_enable_napi(void *_)
 {
int cpu = smp_processor_id();
+
napi_schedule(&cvm_oct_napi[cpu].napi);
 }
 
-- 
1.7.9.5

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

RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure

2014-11-28 Thread Dexuan Cui 
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, November 28, 2014 18:13 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer
> failure
> On Fri, Nov 28, 2014 at 4:36 PM, Dexuan Cui  wrote:
> >>  -Original Message-
> >>  From: Jason Wang [mailto:jasow...@redhat.com]
> >>  Sent: Friday, November 28, 2014 14:47 PM
> >>  To: Dexuan Cui
> >>  Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> >> driverdev-
> >>  de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> >>  Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> >>  Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on
> >> transfer
> >>  failure
> >>  On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui 
> >> wrote:
> >>  > In the case the user-space daemon crashes, hangs or is killed, we
> >>  > need to down the semaphore, otherwise, after the daemon starts
> >> next
> >>  > time, the obsolete data in fcopy_transaction.message or
> >>  > fcopy_transaction.fcopy_msg will be used immediately.
> >>  >
> >>  > Cc: Jason Wang 
> >>  > Cc: Vitaly Kuznetsov 
> >>  > Cc: K. Y. Srinivasan 
> >>  > Signed-off-by: Dexuan Cui 
> >>  > ---
> >>  >
> >>  > v2: I removed the "FCP" prefix as Greg asked.
> >>  >
> >>  > I also updated the output message a little:
> >>  > "FCP: failed to acquire the semaphore" -->
> >>  > "can not acquire the semaphore: it is benign"
> >>  >
> >>  > v3: I added the code in fcopy_release() as Jason Wang suggested.
> >>  > I removed the pr_debug (it isn't so meaningful)and added a
> >>  > comment instead.
> >>  >
> >>  >  drivers/hv/hv_fcopy.c | 19 +++
> >>  >  1 file changed, 19 insertions(+)
> >>  >
> >>  > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> >>  > index 23b2ce2..faa6ba6 100644
> >>  > --- a/drivers/hv/hv_fcopy.c
> >>  > +++ b/drivers/hv/hv_fcopy.c
> >>  > @@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct
> >>  > *dummy)
> >>  >  * process the pending transaction.
> >>  >  */
> >>  > fcopy_respond_to_host(HV_E_FAIL);
> >>  > +
> >>  > +   /* In the case the user-space daemon crashes, hangs or is
> >> killed, we
> >>  > +* need to down the semaphore, otherwise, after the daemon
> >> starts
> >>  > next
> >>  > +* time, the obsolete data in fcopy_transaction.message or
> >>  > +* fcopy_transaction.fcopy_msg will be used immediately.
> >>  > +*
> >>  > +* NOTE: fcopy_read() happens to get the semaphore (very rare)?
> >>  > We're
> >>  > +* still OK, because we've reported the failure to the host.
> >>  > +*/
> >>  > +   if (down_trylock(&fcopy_transaction.read_sema))
> >>  > +   ;
> >>
> >>  Sorry, I'm not quite understand how if () ; can help here.
> >>
> >>  Btw, a question not relate to this patch.
> >>
> >>  What happens if a daemon is resume from SIGSTOP and expires the
> >> check
> >>  here?
> > Hi Jason,
> > My idea is: here we need down_trylock(), but in case we can't get the
> > semaphore, it's OK anyway:
> >
> > Scenario 1):
> > 1.1: when the daemon is blocked on the pread(), the daemon receives
> > SIGSTOP;
> > 1.2: the host user runs the PowerShell Copy-VMFile command;
> > 1.3.1: the driver reports the failure to the host user in 5s and
> > 1.3.2: the driver down()-es the semaphore;
> > 1.4: the daemon receives SIGCONT and it will be still blocked on the
> > pread().
> > Without the down_trylock(), in 1.4, the daemon can receive an
> > obsolete message.
> > NOTE: in this scenario, the daemon is not killed.
> >
> > Scenario 2):
> > In senario 1), if the daemon receives SIGCONT between 1.3.1 and 1.3.2
> > and
> > do down() in fcopy_read(), it will receive the message but: the
> > driver has
> > reported the failure to the host user and the driver's 1.3.2 can't
> > get the
> > semaphore -- IMO this is acceptably OK, though in the VM, an
> > incomplete
> > file will be left there.
> > BTW, I think in the daemon's hv_start_fcopy() we should add a
> > close(target_fd) before open()-ing a new one.
> 
> Right, but how about the case when resuming from SIGSTOP but no timeout?
Sorry, I don't understand this:
if no timeout, fcopy_read() will get the semaphore and fcopy_write()
will try to cancel fcopy_work.

> Looks like in this case userspace() may wait in down_interruptible()
> until timeout. We probably need something like this:
> 
> if (down_interruptible(&fcopy_transaction.read_sema)) {
> up(&fcopy_transaction.read_sema);
> return -EINTR;
> }
until "timeout"?
if the daemon can't get the semaphore, it can only be wake by a signal(the
daemon doesn't install handler, so by default most signals will ki

[PATCH] Drivers:staging:rtl8723au:core: Fixed checkpatch error

2014-11-28 Thread Athira Lekshmi 
Fixed the checkpatch error:
ERROR: spaces required around that '>'

Signed-off-by: Athira Lekshmi 
---
 drivers/staging/rtl8723au/core/rtw_cmd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 44eae8e..9f1cdd4 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -960,7 +960,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
/*  check traffic for  powersaving. */
if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
  pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
+   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
2)
bEnterPS = false;
else
bEnterPS = true;
@@ -1154,7 +1154,7 @@ static void rtw_chk_hi_queue_hdl(struct rtw_adapter 
*padapter)
 
cnt++;
 
-   if (cnt>10)
+   if (cnt > 10)
break;
 
val = rtl8723a_chk_hi_queue_empty(padapter);
-- 
1.7.9.5

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

Re: [PATCH] Drivers:staging:octeon: Fixed checkpatch warning

2014-11-28 Thread Athira Lekshmi C V 
Hello

I sign the documents as Athira Lekshmi.

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

Re: [PATCH] Drivers:staging:rtl8723au:core: Fixed checkpatch error

2014-11-28 Thread Jes Sorensen 
Athira Lekshmi  writes:
> Fixed the checkpatch error:
> ERROR: spaces required around that '>'
>
> Signed-off-by: Athira Lekshmi 
> ---
>  drivers/staging/rtl8723au/core/rtw_cmd.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
> b/drivers/staging/rtl8723au/core/rtw_cmd.c
> index 44eae8e..9f1cdd4 100644
> --- a/drivers/staging/rtl8723au/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
> @@ -960,7 +960,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
> *padapter)
>   /*  check traffic for  powersaving. */
>   if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
> pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
> - pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
> + pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
> 2)
>   bEnterPS = false;
>   else
>   bEnterPS = true;

NACK - I already stated this! Making the line longer than 80 characters
is worse then the 'problem' this fixes.

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

[PATCH] Drivers:staging:rtl8192e: Fixed checkpatch warning

2014-11-28 Thread Athira Lekshmi 
Fixed checkpatch warning:
WARNING: space prohibited before semicolon

Signed-off-by: Athira Lekshmi 
---
 drivers/staging/rtl8192e/rtllib_rx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/rtllib_rx.c 
b/drivers/staging/rtl8192e/rtllib_rx.c
index ca76ad0..cf11b04 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -2687,7 +2687,7 @@ void rtllib_rx_mgt(struct rtllib_device *ieee,
  struct sk_buff *skb,
  struct rtllib_rx_stats *stats)
 {
-   struct rtllib_hdr_4addr *header = (struct rtllib_hdr_4addr *)skb->data ;
+   struct rtllib_hdr_4addr *header = (struct rtllib_hdr_4addr *)skb->data;
 
if ((WLAN_FC_GET_STYPE(le16_to_cpu(header->frame_ctl)) !=
RTLLIB_STYPE_PROBE_RESP) &&
-- 
1.7.9.5

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

Re: [PATCH v2] staging: octeon: Fix checkpatch warnings

2014-11-28 Thread Luis de Bethencourt 
On Fri, Nov 28, 2014 at 01:29:28PM +0300, Dan Carpenter wrote:
> On Thu, Nov 27, 2014 at 05:18:10PM +0100, Luis de Bethencourt wrote:
> > Fixing 80 character limit warnings in octeon/ethernet-rx.c
> > 
> > Signed-off-by: Luis de Bethencourt 
> > ---
> >  drivers/staging/octeon/ethernet-rx.c | 51 
> > +---
> >  1 file changed, 35 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/staging/octeon/ethernet-rx.c 
> > b/drivers/staging/octeon/ethernet-rx.c
> > index 1789a12..e387eb1 100644
> > --- a/drivers/staging/octeon/ethernet-rx.c
> > +++ b/drivers/staging/octeon/ethernet-rx.c
> > @@ -109,6 +109,7 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t 
> > *work)
> > int interface = cvmx_helper_get_interface_num(work->ipprt);
> > int index = cvmx_helper_get_interface_index_num(work->ipprt);
> > union cvmx_gmxx_rxx_frm_ctl gmxx_rxx_frm_ctl;
> > +
> 
> Do this in a separate patch.

Will do within the hour.

> 
> > @@ -332,8 +343,10 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, 
> > int budget)
> > skb->protocol = eth_type_trans(skb, dev);
> > skb->dev = dev;
> >  
> > -   if (unlikely(work->word2.s.not_IP || 
> > work->word2.s.IP_exc ||
> > -   work->word2.s.L4_error || 
> > !work->word2.s.tcp_or_udp))
> > +   if (unlikely(work->word2.s.not_IP ||
> > +   work->word2.s.IP_exc ||
> > +   work->word2.s.L4_error ||
> > +   !work->word2.s.tcp_or_udp))
> > skb->ip_summed = CHECKSUM_NONE;
> 
> Your patch aligns everything with tabs but it should be slightly
> different.  Run your patch through checkpatch.pl --strict to see what I
> mean and then redo it all.  This one should look like:
> 
>   if (unlikely(work->word2.s.not_IP ||
>work->word2.s.IP_exc ||
>work->word2.s.L4_error ||
>!work->word2.s.tcp_or_udp))
>   skb->ip_summed = CHECKSUM_NONE;
> 
> [tab][tab][tab][tab][tab][space][space][space][space][space]work->...
> 
> regards,
> dan carpenter
> 
> 

Fixed the aligns and resubmitting the patch as v3.

Thanks for the review!
Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3] staging: octeon: Fix checkpatch 80 character limit warnings

2014-11-28 Thread Luis de Bethencourt 
Fixing 80 character limit warnings in octeon/ethernet-rx.c

Signed-off-by: Luis de Bethencourt 
---
 drivers/staging/octeon/ethernet-rx.c | 49 
 1 file changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/octeon/ethernet-rx.c 
b/drivers/staging/octeon/ethernet-rx.c
index 1789a12..fcbe836 100644
--- a/drivers/staging/octeon/ethernet-rx.c
+++ b/drivers/staging/octeon/ethernet-rx.c
@@ -126,13 +126,15 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t 
*work)
 
if (*ptr == 0xd5) {
/*
- printk_ratelimited("Port %d received 0xd5 
preamble\n", work->ipprt);
+ printk_ratelimited("Port %d received 0xd5 
preamble\n",
+ work->ipprt);
 */
work->packet_ptr.s.addr += i + 1;
work->len -= i + 5;
} else if ((*ptr & 0xf) == 0xd) {
/*
- printk_ratelimited("Port %d received 0x?d 
preamble\n", work->ipprt);
+ printk_ratelimited("Port %d received 0x?d 
preamble\n",
+ work->ipprt);
 */
work->packet_ptr.s.addr += i;
work->len -= i + 4;
@@ -218,11 +220,13 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, 
int budget)
cvmx_write_csr(CVMX_POW_WQ_INT, wq_int.u64);
break;
}
-   pskb = (struct sk_buff 
**)(cvm_oct_get_buffer_ptr(work->packet_ptr) - sizeof(void *));
+   pskb = (struct sk_buff 
**)(cvm_oct_get_buffer_ptr(work->packet_ptr) -
+   sizeof(void *));
prefetch(pskb);
 
if (USE_ASYNC_IOBDMA && rx_count < (budget - 1)) {
-   cvmx_pow_work_request_async_nocheck(CVMX_SCR_SCRATCH, 
CVMX_POW_NO_WAIT);
+   cvmx_pow_work_request_async_nocheck(CVMX_SCR_SCRATCH,
+   CVMX_POW_NO_WAIT);
did_work_request = 1;
}
rx_count++;
@@ -247,7 +251,8 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, int 
budget)
 * buffer.
 */
if (likely(skb_in_hw)) {
-   skb->data = skb->head + work->packet_ptr.s.addr - 
cvmx_ptr_to_phys(skb->head);
+   skb->data = skb->head + work->packet_ptr.s.addr -
+   cvmx_ptr_to_phys(skb->head);
prefetch(skb->data);
skb->len = work->len;
skb_set_tail_pointer(skb, skb->len);
@@ -284,7 +289,8 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, int 
budget)
/* No packet buffers to free */
} else {
int segments = work->word2.s.bufs;
-   union cvmx_buf_ptr segment_ptr = 
work->packet_ptr;
+   union cvmx_buf_ptr segment_ptr =
+   work->packet_ptr;
int len = work->len;
 
while (segments--) {
@@ -300,8 +306,11 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, int 
budget)
 * one: int segment_size =
 * segment_ptr.s.size;
 */
-   int segment_size = 
CVMX_FPA_PACKET_POOL_SIZE -
-   (segment_ptr.s.addr - 
(((segment_ptr.s.addr >> 7) - segment_ptr.s.back) << 7));
+   int segment_size =
+   CVMX_FPA_PACKET_POOL_SIZE -
+   (segment_ptr.s.addr -
+(((segment_ptr.s.addr >> 7) -
+  segment_ptr.s.back) << 7));
/*
 * Don't copy more than what
 * is left in the packet.
@@ -332,8 +341,10 @@ static int cvm_oct_napi_poll(struct napi_struct *napi, int 
budget)
skb->protocol = eth_type_trans(skb, dev);
skb->dev = dev;
 
-   if (unlikely(work->word2.s.not_IP || 
work->word2.s.IP_exc ||
-   work->word2.s.L4_error || 
!work->word2.s.tcp_or_udp))
+   if (unlikely(work->word2.s.not_IP ||
+work->wor

Re: [PATCH v2] staging: octeon: Fix checkpatch warnings

2014-11-28 Thread Dan Carpenter 
On Fri, Nov 28, 2014 at 02:30:34PM +0100, Luis de Bethencourt wrote:
> On Fri, Nov 28, 2014 at 01:29:28PM +0300, Dan Carpenter wrote:
> > On Thu, Nov 27, 2014 at 05:18:10PM +0100, Luis de Bethencourt wrote:
> > > Fixing 80 character limit warnings in octeon/ethernet-rx.c
> > > 
> > > Signed-off-by: Luis de Bethencourt 
> > > ---
> > >  drivers/staging/octeon/ethernet-rx.c | 51 
> > > +---
> > >  1 file changed, 35 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/staging/octeon/ethernet-rx.c 
> > > b/drivers/staging/octeon/ethernet-rx.c
> > > index 1789a12..e387eb1 100644
> > > --- a/drivers/staging/octeon/ethernet-rx.c
> > > +++ b/drivers/staging/octeon/ethernet-rx.c
> > > @@ -109,6 +109,7 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t 
> > > *work)
> > >   int interface = cvmx_helper_get_interface_num(work->ipprt);
> > >   int index = cvmx_helper_get_interface_index_num(work->ipprt);
> > >   union cvmx_gmxx_rxx_frm_ctl gmxx_rxx_frm_ctl;
> > > +
> > 
> > Do this in a separate patch.
> 
> Will do within the hour.
> 

:(  You should always wait overnight or a few hours before sending a
patch.  It's not a race.  Go slowly.

regards,
dan carpenter

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

Re: [PATCH v2] staging: octeon: Fix checkpatch warnings

2014-11-28 Thread Luis de Bethencourt 
On Fri, Nov 28, 2014 at 05:14:32PM +0300, Dan Carpenter wrote:
> On Fri, Nov 28, 2014 at 02:30:34PM +0100, Luis de Bethencourt wrote:
> > On Fri, Nov 28, 2014 at 01:29:28PM +0300, Dan Carpenter wrote:
> > > On Thu, Nov 27, 2014 at 05:18:10PM +0100, Luis de Bethencourt wrote:
> > > > Fixing 80 character limit warnings in octeon/ethernet-rx.c
> > > > 
> > > > Signed-off-by: Luis de Bethencourt 
> > > > ---
> > > >  drivers/staging/octeon/ethernet-rx.c | 51 
> > > > +---
> > > >  1 file changed, 35 insertions(+), 16 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/octeon/ethernet-rx.c 
> > > > b/drivers/staging/octeon/ethernet-rx.c
> > > > index 1789a12..e387eb1 100644
> > > > --- a/drivers/staging/octeon/ethernet-rx.c
> > > > +++ b/drivers/staging/octeon/ethernet-rx.c
> > > > @@ -109,6 +109,7 @@ static inline int 
> > > > cvm_oct_check_rcv_error(cvmx_wqe_t *work)
> > > > int interface = 
> > > > cvmx_helper_get_interface_num(work->ipprt);
> > > > int index = 
> > > > cvmx_helper_get_interface_index_num(work->ipprt);
> > > > union cvmx_gmxx_rxx_frm_ctl gmxx_rxx_frm_ctl;
> > > > +
> > > 
> > > Do this in a separate patch.
> > 
> > Will do within the hour.
> > 
> 
> :(  You should always wait overnight or a few hours before sending a
> patch.  It's not a race.  Go slowly.
> 
> regards,
> dan carpenter
> 

Is the wait so people have more time to review the patch as it is?
I wanted to show my interest by keeping up with reviews but now that you
mention that, it makes sense.

I screwed up and didn't submit the version 3 of this patch with [01/02] for the
character limit warnings. Will wait, since the patch for the empty lines after
variable declarations needs to be applied on-top of this. I will wait until that
one is accepted or rejected before rebasing and submitting the second patch.

Sorry about this.

Thanks for all the help :)

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

Re: [PATCH 1/2] mfd: rtsx: add func to split u32 into register

2014-11-28 Thread Dan Carpenter 
Oh.  You're right.  I'm sorry for the noise.

regards,
dan carpenter

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

RE: [HPDD-discuss] [PATCH] staging: lustre: fix sparse warnings related to lock context imbalance

2014-11-28 Thread Patrick Farrell 
Dan,

I disagree about the change suggested here.  In this particular code, 
'object_attr' is distinct from 'attr', as in a 'setattr' call on an inode.  
'cl_object' is a distinct thing from an inode/file on disk, and specifying it 
is the objects attr is helpful in understanding there is not a direct 
relationship to 'attr' in the general filesystem sense.  (cl_object attrs are 
used in determining actual on disk attributes, but there is not a one-to-one 
correspondence.)

I am willing to be corrected, but that is my first feeling here.

- Patrick

From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Dan 
Carpenter [dan.carpen...@oracle.com]
Sent: Friday, November 28, 2014 4:00 AM
To: Loïc Pefferkorn
Cc: de...@driverdev.osuosl.org; Greg KH; linux-ker...@vger.kernel.org; 
gdon...@gmail.com; hpdd-disc...@ml01.01.org
Subject: Re: [HPDD-discuss] [PATCH] staging: lustre: fix sparse warnings 
related to lock context imbalance

On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> 1827 if (valid != 0) {
> 1828 cl_object_attr_lock(obj);
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 cl_object_attr_unlock(obj);
>
> after:
>
> 1827 if (valid != 0) {
> 1828 spin_lock(cl_object_attr_guard(obj));
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 spin_unlock(cl_object_attr_guard(obj));

The word "_object" doesn't add any new information to the name.  If you
remove it then the code is improved.

spin_lock(cl_attr_guard(obj));
cl_attr_set(env, obj, attr, valid);
spin_unlock(cl_attr_guard(obj));


regards,
dan carpenter

___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v13 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

2014-11-28 Thread Philipp Zabel 
Am Freitag, den 28.11.2014, 17:57 +0800 schrieb Andy Yan:
> Hi Philipp:
[...]
>Very sorry about this trouble. Because I have no imx board, we do all 
> the test on
> RK3288 board.
> I had sent a mail with a debug patch to you directly yesterday, hope 
> it will helpful.
> If you have received the mail, would you please give me a reply?

Yes, that was helpful, thank you.
I needed to apply Russell's "imx-drm: convert imx-drm to use the generic
DRM OF helper" patch for drm_of_find_possible_crtcs to work on imx-drm.

regards
Philipp

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

Re: [HPDD-discuss] [PATCH] staging: lustre: fix sparse warnings related to lock context imbalance

2014-11-28 Thread Dan Carpenter 
On Fri, Nov 28, 2014 at 03:45:24PM +, Patrick Farrell wrote:
> Dan,
> 
> I disagree about the change suggested here.  In this particular code,
> 'object_attr' is distinct from 'attr', as in a 'setattr' call on an
> inode.  'cl_object' is a distinct thing from an inode/file on disk,
> and specifying it is the objects attr is helpful in understanding
> there is not a direct relationship to 'attr' in the general filesystem
> sense.  (cl_object attrs are used in determining actual on disk
> attributes, but there is not a one-to-one correspondence.)
> 
> I am willing to be corrected, but that is my first feeling here.

I haven't looked at it deeply.  Loïc was suggesting that we need new
locking functions to deal with lustre's unwieldy naming schemes and I
think we should just fix the names...

We already have a cl_attr struct.  Is that different from what
we're locking here?  I don't think anyone will think this takes an inode
argument.

regards,
dan carpenter

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

[PATCH] staging:drivers:staging:rtl8188eu:hal:rtl8188e_hal_init.c: Added a blank line after declaration

2014-11-28 Thread Anjana Sasindran 
This patch fix a checkpatch.pl warning

WARNING:Missing blank line after declaration

Signed-off-by: Anjana Sasindran 
---
 drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index 68db5c9..7d460ea 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -182,6 +182,7 @@ static void rtl8188e_SetHalODMVar(struct adapter *Adapter, 
enum hal_odm_variable
case HAL_ODM_STA_INFO:
{
struct sta_info *psta = pValue1;
+
if (bSet) {
DBG_88E("### Set STA_(%d) info\n", 
psta->mac_id);
ODM_CmnInfoPtrArrayHook(podmpriv, 
ODM_CMNINFO_STA_STATUS, psta->mac_id, psta);
-- 
1.9.1

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

Re: [PATCH v2 4/9] staging: panel: Use defined value or checking module params state

2014-11-28 Thread Greg Kroah-Hartman 
On Thu, Nov 27, 2014 at 08:50:55PM +0100, Mariusz Gorski wrote:
> On Thu, Nov 27, 2014 at 07:57:06AM -0800, Greg Kroah-Hartman wrote:
> > On Thu, Nov 27, 2014 at 07:24:17AM -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 27, 2014 at 02:26:59PM +0100, Mariusz Gorski wrote:
> > > > On Wed, Nov 26, 2014 at 01:58:01PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Wed, Nov 19, 2014 at 09:38:46PM +0100, Mariusz Gorski wrote:
> > > > > > Avoid magic number and use a comparison with a defined value instead
> > > > > > that checks whether module param has been set by the user to some
> > > > > > value at loading time.
> > > > > > 
> > > > > > Signed-off-by: Mariusz Gorski 
> > > > > > Acked-by: Willy Tarreau 
> > > > > > ---
> > > > > > v2: Don't introduce new macros for param value check
> > > > > > 
> > > > > >  drivers/staging/panel/panel.c | 86 
> > > > > > +--
> > > > > >  1 file changed, 43 insertions(+), 43 deletions(-)
> > > > > 
> > > > > Ugh, I messed up here, and applied the first series, which was acked.
> > > > > 
> > > > > Mariusz, can you resend the patches that I didn't apply, I can't seem 
> > > > > to
> > > > > get the rest of these to work properly.
> > > > 
> > > > Greg, if I get you here correctly, you've applied all 9 patches from v1
> > > > and none from v2, so what you need now is a v1->v2 patch, right?
> > > 
> > > No, I think I applied the patches sent _before_ the 9 series, it was 4
> > > or 5 or so, you should have gotten an email about them.  Pull my
> > > staging-testing branch and redo your remaining patches please.
> > 
> > And the reason I got confused was because you didn't label your second
> > set of patches "v2", which it was, I saw two separate series, one with a
> > few patches, and then 2 sets of 9, the second set labeled "v2" so I
> > thought they were independant.  Please think of the poor maintainer who
> > has to decipher things like this when you send them out...
> 
> I'm confused right now. As you say, first I've sent a patchset of 4:
> https://lkml.org/lkml/2014/11/11/963

Which I applied.

> Then, a couple of days later, I've sent the initial patchset of 9:
> https://lkml.org/lkml/2014/11/18/922
> 
> And a day I've sent a fixed version of the above patchset, labeled with v2:
> https://lkml.org/lkml/2014/11/19/653

So I thought your series of 9 was separate from the series of 4, you can
see my confusion (remember, I receive on _average_ about 1000 emails a day).

> Isn't this the right way to do? I still don't get my mistake. Because
> what I was just about to do is to resend the v2 patchset, but now I'm
> not sure anymore if this is what I'm supposed to do.
> 
> BTW: Out of these 3 patchsets, 1st and 3rd should be applied.

I tried to apply the 3rd, but it didn't apply due to patches I applied
in your first set of 4 patches.

Does that help?

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

Re: [PATCH v2 4/9] staging: panel: Use defined value or checking module params state

2014-11-28 Thread Mariusz Gorski 
On Fri, Nov 28, 2014 at 12:32:48PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 08:50:55PM +0100, Mariusz Gorski wrote:
> > On Thu, Nov 27, 2014 at 07:57:06AM -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 27, 2014 at 07:24:17AM -0800, Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 27, 2014 at 02:26:59PM +0100, Mariusz Gorski wrote:
> > > > > On Wed, Nov 26, 2014 at 01:58:01PM -0800, Greg Kroah-Hartman wrote:
> > > > > > On Wed, Nov 19, 2014 at 09:38:46PM +0100, Mariusz Gorski wrote:
> > > > > > > Avoid magic number and use a comparison with a defined value 
> > > > > > > instead
> > > > > > > that checks whether module param has been set by the user to some
> > > > > > > value at loading time.
> > > > > > > 
> > > > > > > Signed-off-by: Mariusz Gorski 
> > > > > > > Acked-by: Willy Tarreau 
> > > > > > > ---
> > > > > > > v2: Don't introduce new macros for param value check
> > > > > > > 
> > > > > > >  drivers/staging/panel/panel.c | 86 
> > > > > > > +--
> > > > > > >  1 file changed, 43 insertions(+), 43 deletions(-)
> > > > > > 
> > > > > > Ugh, I messed up here, and applied the first series, which was 
> > > > > > acked.
> > > > > > 
> > > > > > Mariusz, can you resend the patches that I didn't apply, I can't 
> > > > > > seem to
> > > > > > get the rest of these to work properly.
> > > > > 
> > > > > Greg, if I get you here correctly, you've applied all 9 patches from 
> > > > > v1
> > > > > and none from v2, so what you need now is a v1->v2 patch, right?
> > > > 
> > > > No, I think I applied the patches sent _before_ the 9 series, it was 4
> > > > or 5 or so, you should have gotten an email about them.  Pull my
> > > > staging-testing branch and redo your remaining patches please.
> > > 
> > > And the reason I got confused was because you didn't label your second
> > > set of patches "v2", which it was, I saw two separate series, one with a
> > > few patches, and then 2 sets of 9, the second set labeled "v2" so I
> > > thought they were independant.  Please think of the poor maintainer who
> > > has to decipher things like this when you send them out...
> > 
> > I'm confused right now. As you say, first I've sent a patchset of 4:
> > https://lkml.org/lkml/2014/11/11/963
> 
> Which I applied.
> 
> > Then, a couple of days later, I've sent the initial patchset of 9:
> > https://lkml.org/lkml/2014/11/18/922
> > 
> > And a day I've sent a fixed version of the above patchset, labeled with v2:
> > https://lkml.org/lkml/2014/11/19/653
> 
> So I thought your series of 9 was separate from the series of 4, you can
> see my confusion (remember, I receive on _average_ about 1000 emails a day).
> 
> > Isn't this the right way to do? I still don't get my mistake. Because
> > what I was just about to do is to resend the v2 patchset, but now I'm
> > not sure anymore if this is what I'm supposed to do.
> > 
> > BTW: Out of these 3 patchsets, 1st and 3rd should be applied.
> 
> I tried to apply the 3rd, but it didn't apply due to patches I applied
> in your first set of 4 patches.
> 
> Does that help?

Yes, thanks. I've resent the patchset yesterday as v3:
https://lkml.org/lkml/2014/11/27/805

It applies cleanly to current staging-testing (aa9d9be),
I've just retested it. Please give it a try.

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

Re: [PATCH v2 4/9] staging: panel: Use defined value or checking module params state

2014-11-28 Thread Greg Kroah-Hartman 
On Fri, Nov 28, 2014 at 09:57:06PM +0100, Mariusz Gorski wrote:
> > I tried to apply the 3rd, but it didn't apply due to patches I applied
> > in your first set of 4 patches.
> > 
> > Does that help?
> 
> Yes, thanks. I've resent the patchset yesterday as v3:
> https://lkml.org/lkml/2014/11/27/805
> 
> It applies cleanly to current staging-testing (aa9d9be),
> I've just retested it. Please give it a try.

Thanks, I'll do that when I get around to applying staging patches
again, sometime next week, I'm supposed to be on vacation right now...

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

Re: [PATCH] staging: lustre: fix sparse warnings related to lock context imbalance

2014-11-28 Thread Greg KH 
On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> Hello Greg,
> 
> After some investigation, I think that removing these wrappers is not going 
> to improve the code readability:
> 
> On Wed, Nov 26, 2014 at 12:54:43PM -0800, Greg KH wrote:
> > On Wed, Nov 26, 2014 at 05:15:48PM +0100, Loic Pefferkorn wrote:
> > > Add __acquires() and __releases() function annotations, to fix sparse 
> > > warnings related to lock context imbalance.
> > > 
> > > This fixes the following warnings:
> > > 
> > > drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c:153:5: 
> > > warning: context imbalance in 'cfs_trace_lock_tcd' - wrong count at exit
> > > drivers/staging/lustre/lustre/libcfs/hash.c:128:1: warning: context 
> > > imbalance in 'cfs_hash_spin_lock' - wrong count at exit
> > > drivers/staging/lustre/lustre/libcfs/hash.c:142:9: warning: context 
> > > imbalance in 'cfs_hash_rw_lock' - wrong count at exit
> > > drivers/staging/lustre/lustre/ptlrpc/../../lustre/ldlm/l_lock.c:57:17: 
> > > warning: context imbalance in 'lock_res_and_lock' - wrong count at exit
> > > drivers/staging/lustre/lustre/libcfs/libcfs_lock.c:93:1: warning: context 
> > > imbalance in 'cfs_percpt_lock' - wrong count at exit
> > > 
> > > Signed-off-by: Loic Pefferkorn 
> > > ---
> > >  drivers/staging/lustre/lustre/libcfs/hash.c  | 4 
> > >  drivers/staging/lustre/lustre/libcfs/libcfs_lock.c   | 2 ++
> > >  drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c | 2 ++
> > >  drivers/staging/lustre/lustre/obdclass/cl_object.c   | 2 ++
> > >  4 files changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c 
> > > b/drivers/staging/lustre/lustre/libcfs/hash.c
> > > index 32da783..7c6e2a3 100644
> > > --- a/drivers/staging/lustre/lustre/libcfs/hash.c
> > > +++ b/drivers/staging/lustre/lustre/libcfs/hash.c
> > > @@ -126,18 +126,21 @@ cfs_hash_nl_unlock(union cfs_hash_lock *lock, int 
> > > exclusive) {}
> > >  
> > >  static inline void
> > >  cfs_hash_spin_lock(union cfs_hash_lock *lock, int exclusive)
> > > + __acquires(&lock->spin)
> > >  {
> > >   spin_lock(&lock->spin);
> > >  }
> > >  
> > >  static inline void
> > >  cfs_hash_spin_unlock(union cfs_hash_lock *lock, int exclusive)
> > > + __releases(&lock->spin)
> > >  {
> > >   spin_unlock(&lock->spin);
> > >  }
> > 
> > Ugh, how horrid, please just delete these functions and push down the
> > spin_lock/unlock calls down into the places these are called.
> 
> cfs_hash_spin_lock() and cfs_hash_spin_unlock() are referenced by function 
> pointers later in the same file:
> 
> 165 /** no bucket lock, one spinlock to protect everything */
> 166 static cfs_hash_lock_ops_t cfs_hash_nbl_lops = {
> 167 .hs_lock= cfs_hash_spin_lock,
> 168 .hs_unlock  = cfs_hash_spin_unlock,
> 169 .hs_bkt_lock= cfs_hash_nl_lock,
> 170 .hs_bkt_unlock  = cfs_hash_nl_unlock,
> 171 };
> 172 
> 173 /** spin bucket lock, rehash is enabled */
> 174 static cfs_hash_lock_ops_t cfs_hash_bkt_spin_lops = {
> 175 .hs_lock= cfs_hash_rw_lock,
> 176 .hs_unlock  = cfs_hash_rw_unlock,
> 177 .hs_bkt_lock= cfs_hash_spin_lock,
> 178 .hs_bkt_unlock  = cfs_hash_spin_unlock,
> 179 };

That's even worse than I imagined.  Putting sparse markings on these
function calls is just papering over nonsense.  Please work on unwinding
the mess so that you don't need callbacks for locks, that is an
abstraction that isn't needed.

> > >  static inline void
> > >  cfs_hash_rw_lock(union cfs_hash_lock *lock, int exclusive)
> > > + __acquires(&lock->rw)
> > >  {
> > >   if (!exclusive)
> > >   read_lock(&lock->rw);
> > > @@ -147,6 +150,7 @@ cfs_hash_rw_lock(union cfs_hash_lock *lock, int 
> > > exclusive)
> > >  
> > >  static inline void
> > >  cfs_hash_rw_unlock(union cfs_hash_lock *lock, int exclusive)
> > > + __releases(&lock->rw)
> > >  {
> > >   if (!exclusive)
> > >   read_unlock(&lock->rw);
> > 
> > 
> > Same for these.
> 
> Likewise for cfs_hash_rw_lock() and cfs_hash_rw_unlock():
> 
> 173 /** spin bucket lock, rehash is enabled */
> 174 static cfs_hash_lock_ops_t cfs_hash_bkt_spin_lops = {
> 175 .hs_lock= cfs_hash_rw_lock,
> 176 .hs_unlock  = cfs_hash_rw_unlock,
> 177 .hs_bkt_lock= cfs_hash_spin_lock,
> 178 .hs_bkt_unlock  = cfs_hash_spin_unlock,
> 179 };
> 180 
> 181 /** rw bucket lock, rehash is enabled */
> 182 static cfs_hash_lock_ops_t cfs_hash_bkt_rw_lops = {
> 183 .hs_lock= cfs_hash_rw_lock,
> 184 .hs_unlock  = cfs_hash_rw_unlock,
> 185 .hs_bkt_lock= cfs_hash_rw_lock,
> 186 .hs_bkt_unlock  = cfs_hash_rw_unlock,
> 187 };

Same here, ick ick ick.

> > > diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c 
> > > b/drivers/staging/lustre/lustre/libcfs/libcfs_lock.c
> > > index 2c199c7..1e529fc 100644
> > > --- a/drivers/staging/lustre/lustre/libcfs/libcfs_loc

[GIT PULL] Staging driver fixes for 3.18-rc7

2014-11-28 Thread Greg KH 
The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:

  Linux 3.18-rc4 (2014-11-09 14:55:29 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.18-rc7

for you to fetch changes up to 6d4556fc0309608f760f1d329df56d77fdd0c31a:

  staging: r8188eu: Add new device ID for DLink GO-USB-N150 (2014-11-27 
08:55:01 -0800)


Staging/IIO driver fixes for 3.18-rc7

Here are some Staging and IIO driver fixes for 3.18-rc7 that resolve a
number of reported issues, and a new device id for a staging wireless
driver.

All of these have been in linux-next.

Signed-off-by: Greg Kroah-Hartman 


Axel Lin (1):
  iio: adc: men_z188_adc: Add terminating entry for men_z188_ids

Cristina Ciocan (1):
  iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask

Daniel Baluta (1):
  iio: accel: kxcjk-1013: Fix kxcjk10013_set_range

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

Larry Finger (2):
  staging: r8188eu: Fix scheduling while atomic error introduced in commit 
fadbe0cd
  staging: r8188eu: Add new device ID for DLink GO-USB-N150

Srinivas Pandruvada (8):
  iio: gyro: bmg160: Error handling when mode set fails
  iio: gyro: bmg160: Don't let interrupt mode to be open drain
  iio: gyro: bmg160: Send x, y and z motion separately
  iio: gyro: bmg160: Fix iio_event_spec direction
  iio: accel: bmc150: Error handling when mode set fails
  iio: accel: bmc150: Send x, y and z motion separately
  iio: accel: bmc150: Fix iio_event_spec direction
  iio: accel: bmc150: set low default thresholds

 drivers/iio/accel/bmc150-accel.c   | 40 +++
 drivers/iio/accel/kxcjk-1013.c |  2 +
 drivers/iio/adc/men_z188_adc.c |  1 +
 drivers/iio/gyro/bmg160.c  | 53 --
 drivers/staging/rtl8188eu/core/rtw_cmd.c   | 22 +--
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c  | 12 +++---
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c |  2 +-
 drivers/staging/rtl8188eu/os_dep/usb_intf.c|  1 +
 include/linux/iio/events.h |  2 +-
 9 files changed, 105 insertions(+), 30 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ion : ion_cma_heap: fix bug for highmem cma

2014-11-28 Thread Zeng Tao 
when cma is located in highmem, virt_to_page will not
work the right way, use pfn_to_page instead.

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

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index f8cabcb..cc45fc0 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -47,7 +47,7 @@ struct ion_cma_buffer_info {
 static int ion_cma_get_sgtable(struct device *dev, struct sg_table *sgt,
   void *cpu_addr, dma_addr_t handle, size_t size)
 {
-   struct page *page = virt_to_page(cpu_addr);
+   struct page *page = pfn_to_page(handle >> PAGE_SHIFT);
int ret;
 
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
-- 
1.9.1

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

[PATCH] Staging: ft1000 : ft1000-pcmcia: replace __attribute ((__packed__) with __packed macro per coding style guidelines in ft1000_dnld.c

2014-11-28 Thread Geoff Darst 
Replace two instances of __attribute ((__packed__) with __packed macro to 
address the warning found by the checkpatch.pl tool.

Signed-off-by: Geoff Darst 
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
index c1856f7..df1cf0c 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
@@ -99,7 +99,7 @@ struct dsp_file_hdr {
u32  version_data_offset;   /* Offset were scrambled version data 
begins. */
u32  version_data_size; /* Size, in words, of scrambled version data. */
u32  nDspImages;/* Number of DSP images in file. */
-} __attribute__ ((packed));
+} __packed;
 
 struct dsp_image_info {
u32  coff_date; /* Date/time when DSP Coff image was built. */
@@ -110,7 +110,7 @@ struct dsp_image_info {
u32  version;   /* Embedded version # of DSP code. */
unsigned short checksum;/* Dsp File checksum */
unsigned short pad1;
-} __attribute__ ((packed));
+} __packed;
 
 void card_bootload(struct net_device *dev)
 {
-- 
1.9.3

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

Re: [PATCH] Drivers:staging:octeon: Fixed checkpatch warning

2014-11-28 Thread Athira Lekshmi C V 
   Hello

   I have resend the patch signing off as Athira Lekshmi.

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

[PATCH] Drivers:staging:octeon: Fixed checkpatch warning

2014-11-28 Thread Athira Lekshmi 
Fixed the checkpatch warning:
Missing a blank line after declarations

Signed-off-by: Athira Lekshmi 
---
 drivers/staging/octeon/ethernet-rx.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/octeon/ethernet-rx.c 
b/drivers/staging/octeon/ethernet-rx.c
index 44e372f..220106e 100644
--- a/drivers/staging/octeon/ethernet-rx.c
+++ b/drivers/staging/octeon/ethernet-rx.c
@@ -84,6 +84,7 @@ static int cvm_irq_cpu;
 static void cvm_oct_enable_napi(void *_)
 {
int cpu = smp_processor_id();
+
napi_schedule(&cvm_oct_napi[cpu].napi);
 }
 
-- 
1.7.9.5

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