[PATCH v7 3/4] mmc: Add realtek USB sdmmc host driver

2014-04-10 Thread rogerable
From: Roger Tseng 

Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
USB card reader MFD driver.

Signed-off-by: Roger Tseng 
Acked-by: Ulf Hansson 
---
 drivers/mmc/host/Kconfig  |7 +
 drivers/mmc/host/Makefile |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c | 1455 +
 3 files changed, 1463 insertions(+)
 create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1384f67..1c01df4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -689,3 +689,10 @@ config MMC_REALTEK_PCI
help
  Say Y here to include driver code to support SD/MMC card interface
  of Realtek PCI-E card reader
+
+config MMC_REALTEK_USB
+   tristate "Realtek USB SD/MMC Card Interface Driver"
+   depends on MFD_RTSX_USB
+   help
+ Say Y here to include driver code to support SD/MMC card interface
+ of Realtek RTS5129/39 series card reader
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3483b6b..8194317 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_MMC_USHC)+= ushc.o
 obj-$(CONFIG_MMC_WMT)  += wmt-sdmmc.o
 
 obj-$(CONFIG_MMC_REALTEK_PCI)  += rtsx_pci_sdmmc.o
+obj-$(CONFIG_MMC_REALTEK_USB)  += rtsx_usb_sdmmc.o
 
 obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-pltfm.o
 obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c
new file mode 100644
index 000..e11fafa
--- /dev/null
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -0,0 +1,1455 @@
+/* Realtek USB SD/MMC Card Interface driver
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Roger Tseng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#include 
+#include 
+#define RTSX_USB_USE_LEDS_CLASS
+#endif
+
+struct rtsx_usb_sdmmc {
+   struct platform_device  *pdev;
+   struct rtsx_ucr *ucr;
+   struct mmc_host *mmc;
+   struct mmc_request  *mrq;
+
+   struct mutexhost_mutex;
+
+   u8  ssc_depth;
+   unsigned intclock;
+   boolvpclk;
+   booldouble_clk;
+   boolhost_removal;
+   boolcard_exist;
+   boolinitial_mode;
+   boolddr_mode;
+
+   unsigned char   power_mode;
+
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+   struct led_classdev led;
+   charled_name[32];
+   struct work_struct  led_work;
+#endif
+};
+
+static inline struct device *sdmmc_dev(struct rtsx_usb_sdmmc *host)
+{
+   return &(host->pdev->dev);
+}
+
+static inline void sd_clear_error(struct rtsx_usb_sdmmc *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   rtsx_usb_ep0_write_register(ucr, CARD_STOP,
+ SD_STOP | SD_CLR_ERR,
+ SD_STOP | SD_CLR_ERR);
+
+   rtsx_usb_clear_dma_err(ucr);
+   rtsx_usb_clear_fsm_err(ucr);
+}
+
+#ifdef DEBUG
+static void sd_print_debug_regs(struct rtsx_usb_sdmmc *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   u8 val = 0;
+
+   rtsx_usb_ep0_read_register(ucr, SD_STAT1, &val);
+   dev_dbg(sdmmc_dev(host), "SD_STAT1: 0x%x\n", val);
+   rtsx_usb_ep0_read_register(ucr, SD_STAT2, &val);
+   dev_dbg(sdmmc_dev(host), "SD_STAT2: 0x%x\n", val);
+   rtsx_usb_ep0_read_register(ucr, SD_BUS_STAT, &val);
+   dev_dbg(sdmmc_dev(host), "SD_BUS_STAT: 0x%x\n", val);
+}
+#else
+#define sd_print_debug_regs(host)
+#endif /* DEBUG */
+
+static int sd_read_data(struct rtsx_usb_sdmmc *host, struct mmc_command *cmd,
+  u16 byte_cnt, u8 *buf, int buf_len, int timeout)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   int err;
+   u8 trans_mode;
+
+   if (!buf)
+   buf_len = 0;
+
+   rtsx_usb_init_cmd(ucr);
+   if (cmd != NULL) {
+   dev_d

[PATCH v7 0/4] Add modules for realtek USB card reader

2014-04-10 Thread rogerable
From: Roger Tseng 

This patchset adds modules to support Realtek USB vendor specific class flash
card reader: one base module in MFD subsystem and two host modules in both mmc
and memstick subsystems. The architecture is similar to rtsx_pci.

This work is done primarily to replace the staging driver: staging/rts5139,
which doesn't utilize mmc nor memstick subsystems. Once the patchset or its
revision is applied, we may need Greg's help to remove the staging one.

v2:
1. Fix potential buffer overflow in rtsx_usb_seq_write_register()
2. Remove unnecessary casting and messages
3. Revise coding style and white spaces

v3:
1. Fix MMC detection fail when under xhci
2. Minor change of pm_runtime behavior in rtsx_usb_ms to prevent some rare
   freeze due to erroneous Memstick card(not MS-Pro)
3. Further revise coding style as suggested in the thread of v2
4. Using managed resources: devm_*
5. Change license from "GPL v2 and later" to "GPL v2"

v4:
1. Remove invocations to deprecated/removed mmc_suspend|resume_host APIs and
   unnecessary platform device pm routines
2. Support CRC-ignored R1 response for CMD13 in response to commit:
   a27fbf2f067b0cd6f172c8b696b9a44c58bfaa7a: mmc: add ignorance case for 
   CMD13 CRC error
3. Remove unnecessary #ifdef CONFIG_PM_RUNTIME

v5:
1. rtsx_usb_ms.c: adding header inclusion, removing unnecessary NULL checking,
   and add cancel_work_sync in removal handler to wait possible pending
   works.
(Changes only rtsx_usb_ms. Other files remain the same to v4)

v6:
NOTE:since the v3 of patch 1/3 (rtsx_usb) has been merged, only diffs are
submitted and splitted into two.
1. rtsx_usb.c: fix possible race conditions:
   rtsx_usb_bulk_transfer_sglist(): del_timer() => del_timer_sync()
   rtsx_usb_probe(): move setup_timer() before mfd_add_devices() and also
 remove unnecessary init_timer()
2. rtsx_usb.c: rtsx_usb_suspend(): add comments to LED turn-off
(Changes only rtsx_usb.c. Other files remain the same to v5)

v7:
1. rtsx_usb_sdmmc: remove unnecessary pm usage balancing during removal
2. rtsx_usb_sdmmc: add Acked-by: Ulf Hansson 

Roger Tseng (4):
  [v6 fix] mfd/rtsx_usb: fix possible race condition
  [v6 fix] mfd/rtsx_usb: add comment in rtsx_usb_suspend
  mmc: Add realtek USB sdmmc host driver
  memstick: Add realtek USB memstick host driver

 drivers/memstick/host/Kconfig   |   10 +
 drivers/memstick/host/Makefile  |1 +
 drivers/memstick/host/rtsx_usb_ms.c |  839 
 drivers/mfd/rtsx_usb.c  |   14 +-
 drivers/mmc/host/Kconfig|7 +
 drivers/mmc/host/Makefile   |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c   | 1455 +++
 7 files changed, 2323 insertions(+), 4 deletions(-)
 create mode 100644 drivers/memstick/host/rtsx_usb_ms.c
 create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c

-- 
1.8.2

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


[PATCH v7 4/4] memstick: Add realtek USB memstick host driver

2014-04-10 Thread rogerable
From: Roger Tseng 

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng 
---
 drivers/memstick/host/Kconfig   |  10 +
 drivers/memstick/host/Makefile  |   1 +
 drivers/memstick/host/rtsx_usb_ms.c | 839 
 3 files changed, 850 insertions(+)
 create mode 100644 drivers/memstick/host/rtsx_usb_ms.c

diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kconfig
index 1b37cf8..7310e32 100644
--- a/drivers/memstick/host/Kconfig
+++ b/drivers/memstick/host/Kconfig
@@ -52,3 +52,13 @@ config MEMSTICK_REALTEK_PCI
 
  To compile this driver as a module, choose M here: the module will
  be called rtsx_pci_ms.
+
+config MEMSTICK_REALTEK_USB
+   tristate "Realtek USB Memstick Card Interface Driver"
+   depends on MFD_RTSX_USB
+   help
+ Say Y here to include driver code to support Memstick card interface
+ of Realtek RTS5129/39 series USB card reader
+
+ To compile this driver as a module, choose M here: the module will
+ be called rts5139_ms.
diff --git a/drivers/memstick/host/Makefile b/drivers/memstick/host/Makefile
index af3459d..491c955 100644
--- a/drivers/memstick/host/Makefile
+++ b/drivers/memstick/host/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_MEMSTICK_TIFM_MS)  += tifm_ms.o
 obj-$(CONFIG_MEMSTICK_JMICRON_38X) += jmb38x_ms.o
 obj-$(CONFIG_MEMSTICK_R592)+= r592.o
 obj-$(CONFIG_MEMSTICK_REALTEK_PCI) += rtsx_pci_ms.o
+obj-$(CONFIG_MEMSTICK_REALTEK_USB) += rtsx_usb_ms.o
diff --git a/drivers/memstick/host/rtsx_usb_ms.c 
b/drivers/memstick/host/rtsx_usb_ms.c
new file mode 100644
index 000..a7282b7
--- /dev/null
+++ b/drivers/memstick/host/rtsx_usb_ms.c
@@ -0,0 +1,839 @@
+/* Realtek USB Memstick Card Interface driver
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Roger Tseng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rtsx_usb_ms {
+   struct platform_device  *pdev;
+   struct rtsx_ucr *ucr;
+   struct memstick_host*msh;
+   struct memstick_request *req;
+
+   struct mutexhost_mutex;
+   struct work_struct  handle_req;
+
+   struct task_struct  *detect_ms;
+   struct completion   detect_ms_exit;
+
+   u8  ssc_depth;
+   unsigned intclock;
+   int power_mode;
+   unsigned char   ifmode;
+   booleject;
+};
+
+static inline struct device *ms_dev(struct rtsx_usb_ms *host)
+{
+   return &(host->pdev->dev);
+}
+
+static inline void ms_clear_error(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   rtsx_usb_ep0_write_register(ucr, CARD_STOP,
+ MS_STOP | MS_CLR_ERR,
+ MS_STOP | MS_CLR_ERR);
+
+   rtsx_usb_clear_dma_err(ucr);
+   rtsx_usb_clear_fsm_err(ucr);
+}
+
+#ifdef DEBUG
+
+static void ms_print_debug_regs(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   u16 i;
+   u8 *ptr;
+
+   /* Print MS host internal registers */
+   rtsx_usb_init_cmd(ucr);
+
+   /* MS_CFG to MS_INT_REG */
+   for (i = 0xFD40; i <= 0xFD44; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_SHARE_MODE to CARD_GPIO */
+   for (i = 0xFD51; i <= 0xFD56; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_PULL_CTLx */
+   for (i = 0xFD60; i <= 0xFD65; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_DATA_SOURCE, CARD_SELECT, CARD_CLK_EN, CARD_PWR_CTL */
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_DATA_SOURCE, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_SELECT, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_CLK_EN, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_PWR_CTL, 0, 0);
+
+   rtsx_usb_send_cmd(ucr, MODE_CR, 100);
+   rtsx_usb_get_rsp(ucr, 21, 100);
+
+   ptr = ucr->rsp_buf;
+   for (i = 0xFD40; i <= 0xFD44; i++)
+   dev_dbg(ms_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   for (i =

[PATCH v7 1/4] [v6 fix] mfd/rtsx_usb: fix possible race condition

2014-04-10 Thread rogerable
From: Roger Tseng 

Fix two possible race condition generated by misuse of del_timer in
rtsx_usb_bulk_transfer_sglist() and uninitialized timers before mfd_add_devices
in rtsx_usb_probe().

Signed-off-by: Roger Tseng 
---
 drivers/mfd/rtsx_usb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index b53b9d4..0ca7973 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -67,7 +67,7 @@ static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
ucr->sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
add_timer(&ucr->sg_timer);
usb_sg_wait(&ucr->current_sg);
-   del_timer(&ucr->sg_timer);
+   del_timer_sync(&ucr->sg_timer);
 
if (act_len)
*act_len = ucr->current_sg.bytes;
@@ -644,14 +644,14 @@ static int rtsx_usb_probe(struct usb_interface *intf,
if (ret)
goto out_init_fail;
 
+   /* initialize USB SG transfer timer */
+   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
+
ret = mfd_add_devices(&intf->dev, usb_dev->devnum, rtsx_usb_cells,
ARRAY_SIZE(rtsx_usb_cells), NULL, 0, NULL);
if (ret)
goto out_init_fail;
 
-   /* initialize USB SG transfer timer */
-   init_timer(&ucr->sg_timer);
-   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
 #ifdef CONFIG_PM
intf->needs_remote_wakeup = 1;
usb_enable_autosuspend(usb_dev);
-- 
1.8.2

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


[PATCH v7 2/4] [v6 fix] mfd/rtsx_usb: add comment in rtsx_usb_suspend

2014-04-10 Thread rogerable
From: Roger Tseng 

Explain why there is no need to have a symmetric LED turn-on in resume handler
while calling rtsx_usb_turn_off_led() in suspend handler.

Signed-off-by: Roger Tseng 
---
 drivers/mfd/rtsx_usb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 0ca7973..141ea52 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,9 +687,15 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
pm_message_t message)
dev_dbg(&intf->dev, "%s called with pm message 0x%04u\n",
__func__, message.event);
 
+   /*
+* Call to make sure LED is off during suspend to save more power.
+* It is NOT a permanent state and could be turned on anytime later.
+* Thus no need to call turn_on when resunming.
+*/
mutex_lock(&ucr->dev_mutex);
rtsx_usb_turn_off_led(ucr);
mutex_unlock(&ucr->dev_mutex);
+
return 0;
 }
 
-- 
1.8.2

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Marcos A. Di Pietro
On 04/10/2014 07:27 PM, Greg KH wrote:
> On Thu, Apr 10, 2014 at 06:56:01PM -0400, Marcos A. Di Pietro wrote:
>> On 04/10/2014 04:55 PM, Greg KH wrote:
>>> On Thu, Apr 10, 2014 at 04:22:13PM -0400, Marcos A. Di Pietro wrote:
 On 04/10/2014 04:14 PM, Greg KH wrote:
> On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
>> Fixes code style errors in drivers/staging/bcm/Qos.c
>>
>> Patch submitted as part of the Eudyptula Challenge.
>>
>> Signed-off-by: Marcos A. Di Pietro 
>> ---
>>  drivers/staging/bcm/Qos.c | 13 -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>> index 4f31583..e7fccbc 100644
>> --- a/drivers/staging/bcm/Qos.c
>> +++ b/drivers/staging/bcm/Qos.c
>> @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
>> Service.
>>  */
>>  #include "headers.h"
>>
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
>> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
>> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>> -
>> -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct 
>> iphdr *iphd,
>> -  struct bcm_classifier_rule 
>> *pstClassifierRule);
>> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
>> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
>> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
>> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 
>> EthCSCupport);
>> +
>> +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>> *iphd,
>> +   struct bcm_classifier_rule *pstClassifierRule);
>>
>>  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
>
> For some reason this patch doesn't apply at all to my tree, can you redo
> it and resend?
>
> thanks,
>
> greg k-h
>

 Which tree are you using? Is there a way I could pull from a tree that
 best resembles yours?
>>>
>>> Try it against Linus's tree right now, that's where I tried to apply it
>>> as my tree is "empty" right now.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> >From 6e6efa45b862042e30308dc9512a5af877c53f2a Mon Sep 17 00:00:00 2001
>> From: "Marcos A. Di Pietro" 
>> Date: Thu, 10 Apr 2014 18:33:21 -0400
>> Subject: [PATCH 1/1] Fixes code style errors in drivers/staging/bcm/Qos.c
>>
>> Patch submitted as part of the Eudyptula Challenge.
>>
>> Signed-off-by: Marcos A. Di Pietro 
> 
> Why add this to the end of an email?  I need a "fresh" email in order to
> not have to edit this by hand :(
> 
>> ---
>>  drivers/staging/bcm/Qos.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>> index 4f31583..b64d0b6 100644
>> --- a/drivers/staging/bcm/Qos.c
>> +++ b/drivers/staging/bcm/Qos.c
>> @@ -4,11 +4,15 @@ This file contains the routines related to Quality of
>> Service.
>>  */
>>  #include "headers.h"
>>
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> 
> That's pretty obviously not going to apply properly, you have line-wrapp
> on.  You can't cut-and-paste patches into gmail, see
> Documentation/email_clients.txt for details.
> 
> thanks,
> 
> greg k-h
> 
Fixes code style errors in drivers/staging/bcm/Qos.c

Patch submitted as part of the Eudyptula Challenge

Signed-off-by: Marcos A. Di Pietro 
---
 drivers/staging/bcm/Qos.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 4f31583..9ddb20c 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -4,8 +4,11 @@ This file contains the routines related to Quality of Service.
 */
 #include "headers.h"

-static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
-static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct sk_buff* 
skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct bcm_classifier_rule 
*pstClassifierRule, B_UINT8 EthCSCupport);
+static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
+   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
+static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
+   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
+   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);

 static USHORT

Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Marcos A. Di Pietro
On 04/10/2014 07:56 PM, Greg KH wrote:
> On Thu, Apr 10, 2014 at 07:27:27PM -0400, Marcos A. Di Pietro wrote:
>>> That's pretty obviously not going to apply properly, you have line-wrapp
>>> on.  You can't cut-and-paste patches into gmail, see
>>> Documentation/email_clients.txt for details.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>> I'm so sorry about that. I already read it and configured Thunderbird as 
>> recommended. I just forgot to turn line wrap off.
> 
> That worked, as this line shows :)
> 
> But you put the patch at the end of the email, I can't do anything with
> it, I need it as a "clean" email, something I don't have to edit by hand
> when applying.
> 
> Also...
> 
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
>> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
>> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
>> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> +
>> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
>> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
>> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>>
>>  static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>> *iphd,
>> -  struct bcm_classifier_rule *pstClassifierRule);
>> +   struct bcm_classifier_rule *pstClassifierRule);
> 
> What happened to the tabs?
> 
> And why modify this last line, what was wrong with it?
> 
> thanks,
> 
> greg k-h
> 
There's nothing wrong with it. I was just trying to make it consistent with the 
formatting I gave the other function definitions. I'll go ahead and remove 
those changes and send it as a clean email.

Thanks for your patience!
Marcos 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: unisys: fix UUID use in s-Par drivers

2014-04-10 Thread Greg Kroah-Hartman
On Fri, Mar 21, 2014 at 11:38:26AM -0500, Romer, Benjamin M wrote:
> This patch removes the GUID type from the s-Par modules and replaces it
> with the standard uuid_le type.
> 
> guidutils.h was removed entirely, and references to it were replaced
> with linux/uuid.h. In some cases, includes were also rearranged for
> better readability.
> 
> All references to the GUID type were corrected to use uuid_le.
> Comparisons between UUIDs were corrected to use uuid_le_cmp(), printing
> was corrected to use %pUL instead of strings from formatting macros, and
> uses of a local copy of the null UUID were corrected to use
> NULL_UUID_LE.
> 
> In commontypes.h, redundant macro definitions were removed to simplify
> the file since many of these macros used UUIDs.
> 
> Signed-off-by: Benjamin Romer 

This patch also doesn't apply to the tree, and as it's in base64 mode, I
can't even edit it by hand to try to see how to resolve it :(

Please fix up and resend.

thanks,

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Greg KH
On Thu, Apr 10, 2014 at 07:27:27PM -0400, Marcos A. Di Pietro wrote:
> > That's pretty obviously not going to apply properly, you have line-wrapp
> > on.  You can't cut-and-paste patches into gmail, see
> > Documentation/email_clients.txt for details.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> I'm so sorry about that. I already read it and configured Thunderbird as 
> recommended. I just forgot to turn line wrap off.

That worked, as this line shows :)

But you put the patch at the end of the email, I can't do anything with
it, I need it as a "clean" email, something I don't have to edit by hand
when applying.

Also...

> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> +
> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
> 
>  static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
> *iphd,
> -  struct bcm_classifier_rule *pstClassifierRule);
> +   struct bcm_classifier_rule *pstClassifierRule);

What happened to the tabs?

And why modify this last line, what was wrong with it?

thanks,

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Marcos A. Di Pietro
On 04/10/2014 07:27 PM, Greg KH wrote:
> On Thu, Apr 10, 2014 at 06:56:01PM -0400, Marcos A. Di Pietro wrote:
>> On 04/10/2014 04:55 PM, Greg KH wrote:
>>> On Thu, Apr 10, 2014 at 04:22:13PM -0400, Marcos A. Di Pietro wrote:
 On 04/10/2014 04:14 PM, Greg KH wrote:
> On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
>> Fixes code style errors in drivers/staging/bcm/Qos.c
>>
>> Patch submitted as part of the Eudyptula Challenge.
>>
>> Signed-off-by: Marcos A. Di Pietro 
>> ---
>>  drivers/staging/bcm/Qos.c | 13 -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>> index 4f31583..e7fccbc 100644
>> --- a/drivers/staging/bcm/Qos.c
>> +++ b/drivers/staging/bcm/Qos.c
>> @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
>> Service.
>>  */
>>  #include "headers.h"
>>
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
>> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
>> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>> -
>> -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct 
>> iphdr *iphd,
>> -  struct bcm_classifier_rule 
>> *pstClassifierRule);
>> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
>> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
>> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
>> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 
>> EthCSCupport);
>> +
>> +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>> *iphd,
>> +   struct bcm_classifier_rule *pstClassifierRule);
>>
>>  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
>
> For some reason this patch doesn't apply at all to my tree, can you redo
> it and resend?
>
> thanks,
>
> greg k-h
>

 Which tree are you using? Is there a way I could pull from a tree that
 best resembles yours?
>>>
>>> Try it against Linus's tree right now, that's where I tried to apply it
>>> as my tree is "empty" right now.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> >From 6e6efa45b862042e30308dc9512a5af877c53f2a Mon Sep 17 00:00:00 2001
>> From: "Marcos A. Di Pietro" 
>> Date: Thu, 10 Apr 2014 18:33:21 -0400
>> Subject: [PATCH 1/1] Fixes code style errors in drivers/staging/bcm/Qos.c
>>
>> Patch submitted as part of the Eudyptula Challenge.
>>
>> Signed-off-by: Marcos A. Di Pietro 
> 
> Why add this to the end of an email?  I need a "fresh" email in order to
> not have to edit this by hand :(
> 
>> ---
>>  drivers/staging/bcm/Qos.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>> index 4f31583..b64d0b6 100644
>> --- a/drivers/staging/bcm/Qos.c
>> +++ b/drivers/staging/bcm/Qos.c
>> @@ -4,11 +4,15 @@ This file contains the routines related to Quality of
>> Service.
>>  */
>>  #include "headers.h"
>>
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> 
> That's pretty obviously not going to apply properly, you have line-wrapp
> on.  You can't cut-and-paste patches into gmail, see
> Documentation/email_clients.txt for details.
> 
> thanks,
> 
> greg k-h
> 
I'm so sorry about that. I already read it and configured Thunderbird as 
recommended. I just forgot to turn line wrap off.
Let's try it again.


>From 6e6efa45b862042e30308dc9512a5af877c53f2a Mon Sep 17 00:00:00 2001
From: "Marcos A. Di Pietro" 
Date: Thu, 10 Apr 2014 18:33:21 -0400
Subject: [PATCH 1/1] Fixes code style errors in drivers/staging/bcm/Qos.c

Patch submitted as part of the Eudyptula Challenge.

Signed-off-by: Marcos A. Di Pietro 
---
 drivers/staging/bcm/Qos.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 4f31583..b64d0b6 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -4,11 +4,15 @@ This file contains the routines related to Quality of Service.
 */
 #include "headers.h"

-static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
-static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct sk_buff* 
skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct bcm_classifier_rule 
*pstClassifierRule, B_UINT8 EthCSCupport);
+static void EThCSGetPktInfo(struct bcm_mini_adapter *Ad

Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Greg KH
On Thu, Apr 10, 2014 at 06:56:01PM -0400, Marcos A. Di Pietro wrote:
> On 04/10/2014 04:55 PM, Greg KH wrote:
> > On Thu, Apr 10, 2014 at 04:22:13PM -0400, Marcos A. Di Pietro wrote:
> >> On 04/10/2014 04:14 PM, Greg KH wrote:
> >>> On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
>  Fixes code style errors in drivers/staging/bcm/Qos.c
> 
>  Patch submitted as part of the Eudyptula Challenge.
> 
>  Signed-off-by: Marcos A. Di Pietro 
>  ---
>   drivers/staging/bcm/Qos.c | 13 -
>   1 file changed, 8 insertions(+), 5 deletions(-)
> 
>  diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>  index 4f31583..e7fccbc 100644
>  --- a/drivers/staging/bcm/Qos.c
>  +++ b/drivers/staging/bcm/Qos.c
>  @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
>  Service.
>   */
>   #include "headers.h"
> 
>  -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
>  pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>  -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
>  sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
>  bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>  -
>  -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct 
>  iphdr *iphd,
>  -  struct bcm_classifier_rule 
>  *pstClassifierRule);
>  +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
>  +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>  +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
>  +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
>  +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 
>  EthCSCupport);
>  +
>  +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>  *iphd,
>  +   struct bcm_classifier_rule *pstClassifierRule);
> 
>   static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
> >>>
> >>> For some reason this patch doesn't apply at all to my tree, can you redo
> >>> it and resend?
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>
> >> Which tree are you using? Is there a way I could pull from a tree that
> >> best resembles yours?
> > 
> > Try it against Linus's tree right now, that's where I tried to apply it
> > as my tree is "empty" right now.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> >From 6e6efa45b862042e30308dc9512a5af877c53f2a Mon Sep 17 00:00:00 2001
> From: "Marcos A. Di Pietro" 
> Date: Thu, 10 Apr 2014 18:33:21 -0400
> Subject: [PATCH 1/1] Fixes code style errors in drivers/staging/bcm/Qos.c
> 
> Patch submitted as part of the Eudyptula Challenge.
> 
> Signed-off-by: Marcos A. Di Pietro 

Why add this to the end of an email?  I need a "fresh" email in order to
not have to edit this by hand :(

> ---
>  drivers/staging/bcm/Qos.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
> index 4f31583..b64d0b6 100644
> --- a/drivers/staging/bcm/Qos.c
> +++ b/drivers/staging/bcm/Qos.c
> @@ -4,11 +4,15 @@ This file contains the routines related to Quality of
> Service.
>  */
>  #include "headers.h"
> 
> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID
> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);

That's pretty obviously not going to apply properly, you have line-wrapp
on.  You can't cut-and-paste patches into gmail, see
Documentation/email_clients.txt for details.

thanks,

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Marcos A. Di Pietro
On 04/10/2014 04:55 PM, Greg KH wrote:
> On Thu, Apr 10, 2014 at 04:22:13PM -0400, Marcos A. Di Pietro wrote:
>> On 04/10/2014 04:14 PM, Greg KH wrote:
>>> On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
 Fixes code style errors in drivers/staging/bcm/Qos.c

 Patch submitted as part of the Eudyptula Challenge.

 Signed-off-by: Marcos A. Di Pietro 
 ---
  drivers/staging/bcm/Qos.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

 diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
 index 4f31583..e7fccbc 100644
 --- a/drivers/staging/bcm/Qos.c
 +++ b/drivers/staging/bcm/Qos.c
 @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
 Service.
  */
  #include "headers.h"

 -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
 pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
 -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
 sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
 bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
 -
 -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
 *iphd,
 -  struct bcm_classifier_rule *pstClassifierRule);
 +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
 +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
 +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
 +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
 +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 
 EthCSCupport);
 +
 +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
 *iphd,
 +   struct bcm_classifier_rule *pstClassifierRule);

  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
>>>
>>> For some reason this patch doesn't apply at all to my tree, can you redo
>>> it and resend?
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Which tree are you using? Is there a way I could pull from a tree that
>> best resembles yours?
> 
> Try it against Linus's tree right now, that's where I tried to apply it
> as my tree is "empty" right now.
> 
> thanks,
> 
> greg k-h
> 

>From 6e6efa45b862042e30308dc9512a5af877c53f2a Mon Sep 17 00:00:00 2001
From: "Marcos A. Di Pietro" 
Date: Thu, 10 Apr 2014 18:33:21 -0400
Subject: [PATCH 1/1] Fixes code style errors in drivers/staging/bcm/Qos.c

Patch submitted as part of the Eudyptula Challenge.

Signed-off-by: Marcos A. Di Pietro 
---
 drivers/staging/bcm/Qos.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 4f31583..b64d0b6 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -4,11 +4,15 @@ This file contains the routines related to Quality of
Service.
 */
 #include "headers.h"

-static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID
pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
-static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct
sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct
bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
+static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
+   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
+
+static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
+   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
+   struct bcm_classifier_rule *pstClassifierRule, B_UINT8
EthCSCupport);

 static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct
iphdr *iphd,
-  struct bcm_classifier_rule *pstClassifierRule);
+   struct bcm_classifier_rule *pstClassifierRule);

 static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);

-- 
1.8.3.2

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Greg KH
On Thu, Apr 10, 2014 at 04:22:13PM -0400, Marcos A. Di Pietro wrote:
> On 04/10/2014 04:14 PM, Greg KH wrote:
> > On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
> >> Fixes code style errors in drivers/staging/bcm/Qos.c
> >>
> >> Patch submitted as part of the Eudyptula Challenge.
> >>
> >> Signed-off-by: Marcos A. Di Pietro 
> >> ---
> >>  drivers/staging/bcm/Qos.c | 13 -
> >>  1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
> >> index 4f31583..e7fccbc 100644
> >> --- a/drivers/staging/bcm/Qos.c
> >> +++ b/drivers/staging/bcm/Qos.c
> >> @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
> >> Service.
> >>  */
> >>  #include "headers.h"
> >>
> >> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
> >> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> >> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
> >> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
> >> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
> >> -
> >> -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
> >> *iphd,
> >> -  struct bcm_classifier_rule *pstClassifierRule);
> >> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
> >> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> >> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
> >> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
> >> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 
> >> EthCSCupport);
> >> +
> >> +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
> >> *iphd,
> >> +   struct bcm_classifier_rule *pstClassifierRule);
> >>
> >>  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
> > 
> > For some reason this patch doesn't apply at all to my tree, can you redo
> > it and resend?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Which tree are you using? Is there a way I could pull from a tree that
> best resembles yours?

Try it against Linus's tree right now, that's where I tried to apply it
as my tree is "empty" right now.

thanks,

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


Re: [PATCH] staging: unisys: fix copyright notices

2014-04-10 Thread Greg Kroah-Hartman
On Thu, Apr 10, 2014 at 10:08:52AM -0500, Romer, Benjamin M wrote:
> This patch replaces the inconsistent copyright symbols in each source
> file with (C).
> 
> Signed-off-by: Benjamin Romer 
> ---

This patch is in base64, which ok, I can handle, as git can deal with
that.  But then it totally fails to apply to Linus's latest tree at all.

Can you please take a look at this, and resend it after fixing up
whatever needs to be fixed on your end?

thanks,

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Marcos A. Di Pietro
On 04/10/2014 04:14 PM, Greg KH wrote:
> On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
>> Fixes code style errors in drivers/staging/bcm/Qos.c
>>
>> Patch submitted as part of the Eudyptula Challenge.
>>
>> Signed-off-by: Marcos A. Di Pietro 
>> ---
>>  drivers/staging/bcm/Qos.c | 13 -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
>> index 4f31583..e7fccbc 100644
>> --- a/drivers/staging/bcm/Qos.c
>> +++ b/drivers/staging/bcm/Qos.c
>> @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
>> Service.
>>  */
>>  #include "headers.h"
>>
>> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
>> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
>> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
>> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>> -
>> -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>> *iphd,
>> -  struct bcm_classifier_rule *pstClassifierRule);
>> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
>> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
>> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
>> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
>> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
>> +
>> +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
>> *iphd,
>> +   struct bcm_classifier_rule *pstClassifierRule);
>>
>>  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);
> 
> For some reason this patch doesn't apply at all to my tree, can you redo
> it and resend?
> 
> thanks,
> 
> greg k-h
> 

Which tree are you using? Is there a way I could pull from a tree that
best resembles yours?

thanks,

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


Re: [WIP] [PATCH v2 0/3] remove wrong cast of gfp_t flags

2014-04-10 Thread Greg KH
On Sat, Apr 05, 2014 at 12:32:07AM +0200, Silvio Fricke wrote:
> Hi Dan,
> 
> thanks for your review.
> Attached second version of this series.

I don't understand what the [WIP] marking is.  Please just resend these
as "real" patches if you feel they are ready to be merged.  If we have
issues with them, we will be sure to let you know :)

thanks,

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


Re: [PATCH] Staging:bcm: Fixes coding style issues in drivers/staging/bcm/Qos.c

2014-04-10 Thread Greg KH
On Tue, Mar 25, 2014 at 01:55:47PM -0400, Marcos A. Di Pietro wrote:
> Fixes code style errors in drivers/staging/bcm/Qos.c
> 
> Patch submitted as part of the Eudyptula Challenge.
> 
> Signed-off-by: Marcos A. Di Pietro 
> ---
>  drivers/staging/bcm/Qos.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
> index 4f31583..e7fccbc 100644
> --- a/drivers/staging/bcm/Qos.c
> +++ b/drivers/staging/bcm/Qos.c
> @@ -4,11 +4,14 @@ This file contains the routines related to Quality of 
> Service.
>  */
>  #include "headers.h"
> 
> -static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter, PVOID 
> pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> -static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter, struct 
> sk_buff* skb, struct bcm_eth_packet_info *pstEthCsPktInfo, struct 
> bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
> -
> -static USHORT  IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
> *iphd,
> -  struct bcm_classifier_rule *pstClassifierRule);
> +static void EThCSGetPktInfo(struct bcm_mini_adapter *Adapter,
> +   PVOID pvEthPayload, struct bcm_eth_packet_info *pstEthCsPktInfo);
> +static bool EThCSClassifyPkt(struct bcm_mini_adapter *Adapter,
> +   struct sk_buff *skb, struct bcm_eth_packet_info *pstEthCsPktInfo,
> +   struct bcm_classifier_rule *pstClassifierRule, B_UINT8 EthCSCupport);
> +
> +static USHORT IpVersion4(struct bcm_mini_adapter *Adapter, struct iphdr 
> *iphd,
> +   struct bcm_classifier_rule *pstClassifierRule);
> 
>  static VOID PruneQueue(struct bcm_mini_adapter *Adapter, INT iIndex);

For some reason this patch doesn't apply at all to my tree, can you redo
it and resend?

thanks,

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


Re: [PATCH v4 1/1] staging: comedi: Fix checkpatch warning

2014-04-10 Thread Greg Kroah-Hartman
On Fri, Apr 04, 2014 at 11:10:51PM +0200, Camille Begue wrote:
> Wrap lines > 80 columns.
> 
> Signed-off-by: Camille Begue 

Unfortunatly someone sent this same patch a few days before you, so I
had to accept that one, not this one, sorry.

Feel free to send other cleanup patches, we need all the help we can get
here :)

thanks,

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


[PATCH] staging: comedi: fix circular locking dependency in comedi_mmap()

2014-04-10 Thread Ian Abbott
Mmapping a comedi data buffer with lockdep checking enabled produced the
following kernel debug messages:

==
[ INFO: possible circular locking dependency detected ]
3.5.0-rc3-ija1+ #9 Tainted: G C
---
comedi_test/4160 is trying to acquire lock:
 (&dev->mutex#2){+.+.+.}, at: [] comedi_mmap+0x57/0x1d9 
[comedi]

but task is already holding lock:
 (&mm->mmap_sem){++}, at: [] vm_mmap_pgoff+0x41/0x76

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_sem){++}:
   [] lock_acquire+0x97/0x105
   [] might_fault+0x6d/0x90
   [] do_devinfo_ioctl.isra.7+0x11e/0x14c [comedi]
   [] comedi_unlocked_ioctl+0x256/0xe48 [comedi]
   [] vfs_ioctl+0x18/0x34
   [] do_vfs_ioctl+0x382/0x43c
   [] sys_ioctl+0x42/0x65
   [] system_call_fastpath+0x16/0x1b

-> #0 (&dev->mutex#2){+.+.+.}:
   [] __lock_acquire+0x101d/0x1591
   [] lock_acquire+0x97/0x105
   [] mutex_lock_nested+0x46/0x2a4
   [] comedi_mmap+0x57/0x1d9 [comedi]
   [] mmap_region+0x281/0x492
   [] do_mmap_pgoff+0x26b/0x2a7
   [] vm_mmap_pgoff+0x5d/0x76
   [] sys_mmap_pgoff+0xc7/0x10d
   [] sys_mmap+0x16/0x20
   [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&mm->mmap_sem);
   lock(&dev->mutex#2);
   lock(&mm->mmap_sem);
  lock(&dev->mutex#2);

 *** DEADLOCK ***

To avoid the circular dependency, just try to get the lock in
`comedi_mmap()` instead of blocking.  Since the comedi device's main mutex
is heavily used, do a down-read of its `attach_lock` rwsemaphore
instead.  Trying to down-read `attach_lock` should only fail if
some task has down-write locked it, and that is only done while the
comedi device is being attached to or detached from a low-level hardware
device.

Unfortunately, acquiring the `attach_lock` doesn't prevent another
task replacing the comedi data buffer we are trying to mmap.  The
details of the buffer are held in a `struct comedi_buf_map` and pointed
to by `s->async->buf_map` where `s` is the comedi subdevice whose buffer
we are trying to map.  The `struct comedi_buf_map` is already reference
counted with a `struct kref`, so we can stop it being freed prematurely.

Modify `comedi_mmap()` to call new function
`comedi_buf_map_from_subdev_get()` to read the subdevice's current
buffer map pointer and increment its reference instead of accessing
`async->buf_map` directly.  Call `comedi_buf_map_put()` to decrement the
reference once the buffer map structure has been dealt with.  (Note that
`comedi_buf_map_put()` does nothing if passed a NULL pointer.)

`comedi_buf_map_from_subdev_get()` checks the subdevice's buffer map
pointer has been set and the buffer map has been initialized enough for
`comedi_mmap()` to deal with it (specifically, check the `n_pages`
member has been set to a non-zero value).  If all is well, the buffer
map's reference is incremented and a pointer to it is returned.  The
comedi subdevice's spin-lock is used to protect the checks.  Also use
the spin-lock in `__comedi_buf_alloc()` and `__comedi_buf_free()` to
protect changes to the subdevice's buffer map structure pointer and the
buffer map structure's `n_pages` member.  (This checking of `n_pages` is
a bit clunky and I [Ian Abbott] plan to deal with it in the future.)

Signed-off-by: Ian Abbott 
Cc:  # 3.14.x, 3.15.x
---
 drivers/staging/comedi/comedi_buf.c  | 37 ++--
 drivers/staging/comedi/comedi_fops.c | 18 
 drivers/staging/comedi/comedi_internal.h |  2 ++
 3 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index 924fce9..2575950 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -61,6 +61,8 @@ static void __comedi_buf_free(struct comedi_device *dev,
  struct comedi_subdevice *s)
 {
struct comedi_async *async = s->async;
+   struct comedi_buf_map *bm;
+   unsigned long flags;
 
if (async->prealloc_buf) {
vunmap(async->prealloc_buf);
@@ -68,8 +70,11 @@ static void __comedi_buf_free(struct comedi_device *dev,
async->prealloc_bufsz = 0;
}
 
-   comedi_buf_map_put(async->buf_map);
+   spin_lock_irqsave(&s->spin_lock, flags);
+   bm = async->buf_map;
async->buf_map = NULL;
+   spin_unlock_irqrestore(&s->spin_lock, flags);
+   comedi_buf_map_put(bm);
 }
 
 static void __comedi_buf_alloc(struct comedi_device *dev,
@@ -80,6 +85,7 @@ static void __comedi_buf_alloc(struct comedi_device *dev,
struct page **pages = NULL;
struct com

Re: [PATCH] staging: r8723au: Add missing initialization of change_inx in sort algorithm

2014-04-10 Thread Geert Uytterhoeven
Hi Larry,

On Thu, Apr 10, 2014 at 8:01 PM, Larry Finger  wrote:
> On 04/10/2014 12:46 PM, Geert Uytterhoeven wrote:
>>
>> drivers/staging/rtl8723au/core/rtw_wlan_util.c: In function
>> ‘WMMOnAssocRsp23a’:
>> drivers/staging/rtl8723au/core/rtw_wlan_util.c:684: warning: ‘change_inx’
>> may be used uninitialized in this function
>>
>> Depending on the uninitialized data on the stack, the array may not be
>> sorted correctly.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>
> Acked-by: Larry Finger 
>
> Geert,
>
> Thanks for this. I wonder why my gcc on x86_64 did not flag this problem.

Because it's too new?

Several warnings were disabled in more recent versions of gcc (still
using 4.1.2 for m68k here ;-) due to too many false positives.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: r8723au: Add missing initialization of change_inx in sort algorithm

2014-04-10 Thread Larry Finger

On 04/10/2014 12:46 PM, Geert Uytterhoeven wrote:

drivers/staging/rtl8723au/core/rtw_wlan_util.c: In function ‘WMMOnAssocRsp23a’:
drivers/staging/rtl8723au/core/rtw_wlan_util.c:684: warning: ‘change_inx’ may 
be used uninitialized in this function

Depending on the uninitialized data on the stack, the array may not be
sorted correctly.

Signed-off-by: Geert Uytterhoeven 
---


Acked-by: Larry Finger 

Geert,

Thanks for this. I wonder why my gcc on x86_64 did not flag this problem.

Larry


  drivers/staging/rtl8723au/core/rtw_wlan_util.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_wlan_util.c 
b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
index 0dfcfbce3b52..a4361bb93865 100644
--- a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
@@ -681,7 +681,7 @@ void WMMOnAssocRsp23a(struct rtw_adapter *padapter)
inx[0] = 0; inx[1] = 1; inx[2] = 2; inx[3] = 3;

if (pregpriv->wifi_spec == 1) {
-   u32 j, tmp, change_inx;
+   u32 j, tmp, change_inx = false;

/* entry indx: 0->vo, 1->vi, 2->be, 3->bk. */
for (i = 0; i < 4; i++) {



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


[PATCH] staging: r8723au: Add missing initialization of change_inx in sort algorithm

2014-04-10 Thread Geert Uytterhoeven
drivers/staging/rtl8723au/core/rtw_wlan_util.c: In function ‘WMMOnAssocRsp23a’:
drivers/staging/rtl8723au/core/rtw_wlan_util.c:684: warning: ‘change_inx’ may 
be used uninitialized in this function

Depending on the uninitialized data on the stack, the array may not be
sorted correctly.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/staging/rtl8723au/core/rtw_wlan_util.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_wlan_util.c 
b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
index 0dfcfbce3b52..a4361bb93865 100644
--- a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
@@ -681,7 +681,7 @@ void WMMOnAssocRsp23a(struct rtw_adapter *padapter)
inx[0] = 0; inx[1] = 1; inx[2] = 2; inx[3] = 3;
 
if (pregpriv->wifi_spec == 1) {
-   u32 j, tmp, change_inx;
+   u32 j, tmp, change_inx = false;
 
/* entry indx: 0->vo, 1->vi, 2->be, 3->bk. */
for (i = 0; i < 4; i++) {
-- 
1.7.9.5

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


Re: system hang

2014-04-10 Thread g...@kroah.com
On Thu, Apr 10, 2014 at 07:59:38AM +, Narasimharao Bolisetti wrote:
> 
> Hi,
> 
> I have checked the same in the recent kernel versions also. Issue is still 
> remain.

What versions have you tried, and what are the logs from those versions?

> ::DISCLAIMER::
> 
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in 
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, 
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written 
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
> 
> 


Oops, sorry, nope, I'm not allowed to respond to anyone with such an
email footer, it's not compatible with Linux kernel development (Linux
is not confidential.)

Best of luck, I suggest you work with the vendor who is forcing you to
stick with such an old kernel version.

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


Re: staging/rtl8187se should be removed

2014-04-10 Thread Greg KH
On Thu, Apr 10, 2014 at 06:21:36PM +0300, Dan Carpenter wrote:
> The thing about keeping e100 in parallel with the other driver is that
> some devices didn't work on the other driver and also it wasn't staging
> code.
> 
> I don't have strong opinions either way, but if we decide to keep the
> old driver around for another kernel release "just in case" then we
> should make it print a warning on load or something to say that it's
> soon going to be removed.

No, I'll just remove it entirely, no need for it to be around at all
anymore.

thanks,

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


Re: staging/rtl8187se should be removed

2014-04-10 Thread Dan Carpenter
The thing about keeping e100 in parallel with the other driver is that
some devices didn't work on the other driver and also it wasn't staging
code.

I don't have strong opinions either way, but if we decide to keep the
old driver around for another kernel release "just in case" then we
should make it print a warning on load or something to say that it's
soon going to be removed.

regards,
dan carpenter

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


[PATCH] staging: unisys: fix copyright notices

2014-04-10 Thread Romer, Benjamin M
This patch replaces the inconsistent copyright symbols in each source
file with (C).

Signed-off-by: Benjamin Romer 
---
 drivers/staging/unisys/channels/channel.c   | 2 +-
 drivers/staging/unisys/channels/chanstub.c  | 2 +-
 drivers/staging/unisys/channels/chanstub.h  | 2 +-
 drivers/staging/unisys/common-spar/include/channels/channel.h   | 2 +-
 drivers/staging/unisys/common-spar/include/channels/channel_guid.h  | 2 +-
 drivers/staging/unisys/common-spar/include/channels/controlframework.h  | 2 +-
 drivers/staging/unisys/common-spar/include/channels/controlvmchannel.h  | 2 +-
 drivers/staging/unisys/common-spar/include/channels/diagchannel.h   | 2 +-
 drivers/staging/unisys/common-spar/include/channels/iochannel.h | 2 +-
 drivers/staging/unisys/common-spar/include/channels/vbuschannel.h   | 2 +-
 drivers/staging/unisys/common-spar/include/controlvmcompletionstatus.h  | 2 +-
 .../staging/unisys/common-spar/include/diagnostics/appos_subsystems.h   | 2 +-
 drivers/staging/unisys/common-spar/include/iovmcall_gnuc.h  | 2 +-
 drivers/staging/unisys/common-spar/include/vbusdeviceinfo.h | 2 +-
 drivers/staging/unisys/common-spar/include/version.h| 2 +-
 drivers/staging/unisys/common-spar/include/vmcallinterface.h| 2 +-
 drivers/staging/unisys/include/commontypes.h| 2 +-
 drivers/staging/unisys/include/guestlinuxdebug.h| 2 +-
 drivers/staging/unisys/include/guidutils.h  | 2 +-
 drivers/staging/unisys/include/periodic_work.h  | 2 +-
 drivers/staging/unisys/include/procobjecttree.h | 2 +-
 drivers/staging/unisys/include/sparstop.h   | 2 +-
 drivers/staging/unisys/include/timskmod.h   | 2 +-
 drivers/staging/unisys/include/timskmodutils.h  | 2 +-
 drivers/staging/unisys/include/uisqueue.h   | 2 +-
 drivers/staging/unisys/include/uisthread.h  | 2 +-
 drivers/staging/unisys/include/uisutils.h   | 2 +-
 drivers/staging/unisys/include/uniklog.h| 2 +-
 drivers/staging/unisys/uislib/uislib.c  | 2 +-
 drivers/staging/unisys/uislib/uisqueue.c| 2 +-
 drivers/staging/unisys/uislib/uisthread.c   | 2 +-
 drivers/staging/unisys/uislib/uisutils.c| 2 +-
 drivers/staging/unisys/virthba/virthba.c| 2 +-
 drivers/staging/unisys/virthba/virthba.h| 2 +-
 drivers/staging/unisys/virtpci/virtpci.c| 2 +-
 drivers/staging/unisys/virtpci/virtpci.h| 2 +-
 drivers/staging/unisys/visorchannel/globals.h   | 2 +-
 drivers/staging/unisys/visorchannel/visorchannel.h  | 2 +-
 drivers/staging/unisys/visorchannel/visorchannel_funcs.c| 2 +-
 drivers/staging/unisys/visorchannel/visorchannel_main.c | 2 +-
 drivers/staging/unisys/visorchipset/controlvm.h | 2 +-
 drivers/staging/unisys/visorchipset/controlvm_direct.c  | 2 +-
 drivers/staging/unisys/visorchipset/file.c  | 2 +-
 drivers/staging/unisys/visorchipset/file.h  | 2 +-
 drivers/staging/unisys/visorchipset/globals.h   | 2 +-
 drivers/staging/unisys/visorchipset/parser.c| 2 +-
 drivers/staging/unisys/visorchipset/parser.h| 2 +-
 drivers/staging/unisys/visorchipset/testing.h   | 2 +-
 drivers/staging/unisys/visorchipset/visorchipset.h  | 2 +-
 drivers/staging/unisys/visorchipset/visorchipset_main.c | 2 +-
 drivers/staging/unisys/visorchipset/visorchipset_umode.h| 2 +-
 drivers/staging/unisys/visorutil/charqueue.c| 2 +-
 drivers/staging/unisys/visorutil/charqueue.h| 2 +-
 drivers/staging/unisys/visorutil/easyproc.c | 2 +-
 drivers/staging/unisys/visorutil/easyproc.h | 2 +-
 drivers/staging/unisys/visorutil/memregion.h| 2 +-
 drivers/staging/unisys/visorutil/memregion_direct.c | 2 +-
 drivers/staging/unisys/visorutil/periodic_work.c| 2 +-
 drivers/staging/unisys/visorutil/procobjecttree.c   | 2 +-
 drivers/staging/unisys/visorutil/visorkmodutils.c   | 2 +-
 60 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/drivers/sta

Re: [PATCH] unisys: staging: Check for s-Par firmware before initializing s-Par modules

2014-04-10 Thread Romer, Benjamin M
On Wed, 2014-04-09 at 12:25 -0700, Greg Kroah-Hartman wrote:
> Patches need to do only one thing, so can you please split this up in to
> multiple patches, each one only doing one thing.

Sorry about that! I'll send another patch that fixes all of the
copyright statements at once then. :)

> You forgot to add a "Reported-by:" line here, and possibly a
> "Tested-by:" if someone tested it and reported that it solved the
> problem.  Proper attribution is very important.

Will do! Thanks for all the feedback. I'll rework my patch. :)

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


Re: [report] staging: r8723au: rtw_report_sec_ie23a() is buggy

2014-04-10 Thread Jes Sorensen
Dan Carpenter  writes:
> Hello Larry, Jes,
>
> The rtw_report_sec_ie23a() is very buggy.
>
> 1) It uses GFP_KERNEL but the callers are holding a spinlock.
>
>   rtw_select_and_join_from_scanned_queue23a() <- takes lock
>   -> rtw_joinbss_cmd23a()
>-> rtw_restruct_sec_ie23a()
>   -> rtw_report_sec_ie23a()
>
> 2) The sprintf() can overflow because we're putting over 512 characters
>into a IW_CUSTOM_MAX (256) character buffer.
>
> 3) It could actually be far worse than 512.  It could be a forever
>loop!  :P  The "i" variable is declared as u8 so it will always be
>less than IW_CUSTOM_MAX (256).
>
> 4) What is the point of this function?  It doesn't seem to store "buff"
>anywhere or do anything with "wrqu".
>
> I have included my suggestion for how to start fixing the function but
> it's not a complete solution because I don't know the answer to #4.
>
> regards,
> dan carpenter

Dan,

Some of this code is a total nightmare :( The problem is we don't even
know the intensions of the original author, and at times weird
assumptions were made, so we have to analyse our way through it all to
figure out what to do with it.

I'll add this one to my list for further investigation. Note I already
made modifications to it today, replacing _WPA_IE_ID_ with
WLAN_EID_VENDOR_SPECIFIC.

I am keeping a git tree with my current changes here:

https://git.kernel.org/cgit/linux/kernel/git/jes/linux.git/log/?h=rtl8723au-next

albeit these commits haven't been pushed yet.

Cheers,
Jes

>
> diff --git a/drivers/staging/rtl8723au/os_dep/mlme_linux.c 
> b/drivers/staging/rtl8723au/os_dep/mlme_linux.c
> index b30d4d3..6927227 100644
> --- a/drivers/staging/rtl8723au/os_dep/mlme_linux.c
> +++ b/drivers/staging/rtl8723au/os_dep/mlme_linux.c
> @@ -102,42 +102,30 @@ void rtw_os_indicate_disconnect23a(struct rtw_adapter 
> *adapter)
>  
>  void rtw_report_sec_ie23a(struct rtw_adapter *adapter, u8 authmode, u8 
> *sec_ie)
>  {
> - uintlen;
> - u8  *buff, *p, i;
> + char buf[IW_CUSTOM_MAX];
> + int len;
> + int i;
> + int printed = 0;
>   union iwreq_data wrqu;
>  
>   RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
>("+rtw_report_sec_ie23a, authmode =%d\n", authmode));
>  
> - buff = NULL;
> - if (authmode == _WPA_IE_ID_) {
> - RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
> -  ("rtw_report_sec_ie23a, authmode =%d\n", authmode));
> -
> - buff = kzalloc(IW_CUSTOM_MAX, GFP_KERNEL);
> - if (!buff)
> - return;
> - p = buff;
> -
> - p += sprintf(p, "ASSOCINFO(ReqIEs =");
> -
> - len = sec_ie[1]+2;
> - len =  (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX;
> -
> - for (i = 0; i < len; i++)
> - p += sprintf(p, "%02x", sec_ie[i]);
> -
> - p += sprintf(p, ")");
> -
> - memset(&wrqu, 0, sizeof(wrqu));
> -
> - wrqu.data.length = p-buff;
> -
> - wrqu.data.length = (wrqu.data.length < IW_CUSTOM_MAX) ?
> -wrqu.data.length : IW_CUSTOM_MAX;
> + if (authmode != _WPA_IE_ID_)
> + return;
>  
> - kfree(buff);
> + printed += sprintf(p, "ASSOCINFO(ReqIEs =");
> + len = min(sec_ie[1] + 2, IW_CUSTOM_MAX);
> + for (i = 0; i < len; i++) {
> + printed += scnprintf(buf + printed, sizeof(buf) - printed,
> +  "%02x", sec_ie[i]);
>   }
> + printed += scnprintf(buf + printed, sizeof(buf) - printed, ")");
> +
> + memset(&wrqu, 0, sizeof(wrqu));
> + /* FIXME: store the buf somewhere */
> + wrqu.data.length = printed;
> + /* FIXME: do something with wrqu */
>  }
>  
>  #ifdef CONFIG_8723AU_AP_MODE
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] staging: comedi: declare das6402_boards as static

2014-04-10 Thread Ian Abbott

On 2014-04-10 15:38, Michele Curti wrote:


das6402_boards array is used in das6402.c only, so declare it as static.

Signed-off-by: Michele Curti 


Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] staging: comedi: declare das6402_boards as static

2014-04-10 Thread Dan Carpenter
On Thu, Apr 10, 2014 at 04:38:00PM +0200, Michele Curti wrote:
> 
> das6402_boards array is used in das6402.c only, so declare it as static.
> 
> Signed-off-by: Michele Curti 

Looks good.

regards,
dan carpenter

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


[PATCH v2] staging: comedi: declare das6402_boards as static

2014-04-10 Thread Michele Curti

das6402_boards array is used in das6402.c only, so declare it as static.

Signed-off-by: Michele Curti 
---
 drivers/staging/comedi/drivers/das6402.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/das6402.c 
b/drivers/staging/comedi/drivers/das6402.c
index e0cfb6c..d18eea6 100644
--- a/drivers/staging/comedi/drivers/das6402.c
+++ b/drivers/staging/comedi/drivers/das6402.c
@@ -125,7 +125,7 @@ struct das6402_boardinfo {
unsigned int maxdata;
 };
 
-struct das6402_boardinfo das6402_boards[] = {
+static struct das6402_boardinfo das6402_boards[] = {
{
.name   = "das6402-12",
.maxdata= 0x0fff,
-- 
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[report] staging: r8723au: rtw_report_sec_ie23a() is buggy

2014-04-10 Thread Dan Carpenter
Hello Larry, Jes,

The rtw_report_sec_ie23a() is very buggy.

1) It uses GFP_KERNEL but the callers are holding a spinlock.

rtw_select_and_join_from_scanned_queue23a() <- takes lock
-> rtw_joinbss_cmd23a()
   -> rtw_restruct_sec_ie23a()
  -> rtw_report_sec_ie23a()

2) The sprintf() can overflow because we're putting over 512 characters
   into a IW_CUSTOM_MAX (256) character buffer.

3) It could actually be far worse than 512.  It could be a forever
   loop!  :P  The "i" variable is declared as u8 so it will always be
   less than IW_CUSTOM_MAX (256).

4) What is the point of this function?  It doesn't seem to store "buff"
   anywhere or do anything with "wrqu".

I have included my suggestion for how to start fixing the function but
it's not a complete solution because I don't know the answer to #4.

regards,
dan carpenter

diff --git a/drivers/staging/rtl8723au/os_dep/mlme_linux.c 
b/drivers/staging/rtl8723au/os_dep/mlme_linux.c
index b30d4d3..6927227 100644
--- a/drivers/staging/rtl8723au/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8723au/os_dep/mlme_linux.c
@@ -102,42 +102,30 @@ void rtw_os_indicate_disconnect23a(struct rtw_adapter 
*adapter)
 
 void rtw_report_sec_ie23a(struct rtw_adapter *adapter, u8 authmode, u8 *sec_ie)
 {
-   uintlen;
-   u8  *buff, *p, i;
+   char buf[IW_CUSTOM_MAX];
+   int len;
+   int i;
+   int printed = 0;
union iwreq_data wrqu;
 
RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
 ("+rtw_report_sec_ie23a, authmode =%d\n", authmode));
 
-   buff = NULL;
-   if (authmode == _WPA_IE_ID_) {
-   RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
-("rtw_report_sec_ie23a, authmode =%d\n", authmode));
-
-   buff = kzalloc(IW_CUSTOM_MAX, GFP_KERNEL);
-   if (!buff)
-   return;
-   p = buff;
-
-   p += sprintf(p, "ASSOCINFO(ReqIEs =");
-
-   len = sec_ie[1]+2;
-   len =  (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX;
-
-   for (i = 0; i < len; i++)
-   p += sprintf(p, "%02x", sec_ie[i]);
-
-   p += sprintf(p, ")");
-
-   memset(&wrqu, 0, sizeof(wrqu));
-
-   wrqu.data.length = p-buff;
-
-   wrqu.data.length = (wrqu.data.length < IW_CUSTOM_MAX) ?
-  wrqu.data.length : IW_CUSTOM_MAX;
+   if (authmode != _WPA_IE_ID_)
+   return;
 
-   kfree(buff);
+   printed += sprintf(p, "ASSOCINFO(ReqIEs =");
+   len = min(sec_ie[1] + 2, IW_CUSTOM_MAX);
+   for (i = 0; i < len; i++) {
+   printed += scnprintf(buf + printed, sizeof(buf) - printed,
+"%02x", sec_ie[i]);
}
+   printed += scnprintf(buf + printed, sizeof(buf) - printed, ")");
+
+   memset(&wrqu, 0, sizeof(wrqu));
+   /* FIXME: store the buf somewhere */
+   wrqu.data.length = printed;
+   /* FIXME: do something with wrqu */
 }
 
 #ifdef CONFIG_8723AU_AP_MODE
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: comedi: declare das6402_boards as static

2014-04-10 Thread Dan Carpenter
On Thu, Apr 10, 2014 at 03:54:47PM +0200, Michele Curti wrote:
> Hi,
> das6402_boards array seems to be used in das6402.c only, so declare it 
> as static.
> 
> This patch applies to linux-next next-20140410.
> 
> Regards,
> Michele
> 

The patch is fine, but you have too much fluff in the changelog.  We
just apply patches automatically by saving the raw email as text
(including headers and everything) the we do a
`cat raw_email.txt | git am`.

Your changelog is all "Hello, how are you?  blah blah blah.  Best
wishes, etc.".  It should just say:

das6402_boards array is used in das6402.c only, so declare it as static.

Signed-off-by ...

You can put the "This patch applies to linux-next next-20140410" under
the --- cut off line so that we're aware but it doesn't get saved in the
log.  For staging it doesn't really matter, because either the patch
applies to linux-next or we'll ask you to redo it.

Please send a v2 with a terser changelog.

regards,
dan carpenter

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


[PATCH] staging: comedi: declare das6402_boards as static

2014-04-10 Thread Michele Curti
Hi,
das6402_boards array seems to be used in das6402.c only, so declare it 
as static.

This patch applies to linux-next next-20140410.

Regards,
Michele

Signed-off-by: Michele Curti 
---
 drivers/staging/comedi/drivers/das6402.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/das6402.c 
b/drivers/staging/comedi/drivers/das6402.c
index e0cfb6c..d18eea6 100644
--- a/drivers/staging/comedi/drivers/das6402.c
+++ b/drivers/staging/comedi/drivers/das6402.c
@@ -125,7 +125,7 @@ struct das6402_boardinfo {
unsigned int maxdata;
 };
 
-struct das6402_boardinfo das6402_boards[] = {
+static struct das6402_boardinfo das6402_boards[] = {
{
.name   = "das6402-12",
.maxdata= 0x0fff,
-- 
1.9.1

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


[PATCH 3/3] staging: rtl8821ae: Fix rtl8821ae/hw.h pointer declaration style

2014-04-10 Thread Mark Einon
Fix all occurences of the checkpatch error:

ERROR: "foo* bar" should be "foo *bar"

Signed-off-by: Mark Einon 
---
 drivers/staging/rtl8821ae/rtl8821ae/hw.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.h 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
index 335d4ab..256e514 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.h
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
@@ -56,12 +56,12 @@ void rtl8821ae_set_key(struct ieee80211_hw *hw, u32 
key_index,
 
 void rtl8821ae_read_bt_coexist_info_from_hwpg(struct ieee80211_hw *hw,
  bool autoload_fail,
- u8* hwinfo);
+ u8 *hwinfo);
 void rtl8812ae_read_bt_coexist_info_from_hwpg(struct ieee80211_hw *hw,
  bool autoload_fail,
- u8* hwinfo);
-void rtl8821ae_bt_reg_init(struct ieee80211_hw* hw);
-void rtl8821ae_bt_hw_init(struct ieee80211_hw* hw);
+ u8 *hwinfo);
+void rtl8821ae_bt_reg_init(struct ieee80211_hw *hw);
+void rtl8821ae_bt_hw_init(struct ieee80211_hw *hw);
 void rtl8821ae_suspend(struct ieee80211_hw *hw);
 void rtl8821ae_resume(struct ieee80211_hw *hw);
 void rtl8821ae_allow_all_destaddr(struct ieee80211_hw *hw,
-- 
1.7.10.4

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


[PATCH 1/3] staging: rtl8821ae: Fix whitespace in rtl8821ae/hw.h

2014-04-10 Thread Mark Einon
Fix checkpatch warnings, lines over 80 chars using tabs where possible.

Signed-off-by: Mark Einon 
---
 drivers/staging/rtl8821ae/rtl8821ae/hw.h |   27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.h 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
index 4fb6bf0..3f20681 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.h
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
@@ -34,42 +34,43 @@ void rtl8821ae_get_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val);
 void rtl8821ae_read_eeprom_info(struct ieee80211_hw *hw);
 
 void rtl8821ae_interrupt_recognized(struct ieee80211_hw *hw,
-   
 u32 *p_inta, u32 *p_intb);
+   u32 *p_inta, u32 *p_intb);
 int rtl8821ae_hw_init(struct ieee80211_hw *hw);
 void rtl8821ae_card_disable(struct ieee80211_hw *hw);
 void rtl8821ae_enable_interrupt(struct ieee80211_hw *hw);
 void rtl8821ae_disable_interrupt(struct ieee80211_hw *hw);
-int rtl8821ae_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype 
type);
+int rtl8821ae_set_network_type(struct ieee80211_hw *hw,
+  enum nl80211_iftype type);
 void rtl8821ae_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid);
 void rtl8821ae_set_qos(struct ieee80211_hw *hw, int aci);
 void rtl8821ae_set_beacon_related_registers(struct ieee80211_hw *hw);
 void rtl8821ae_set_beacon_interval(struct ieee80211_hw *hw);
 void rtl8821ae_update_interrupt_mask(struct ieee80211_hw *hw,
-   
u32 add_msr, u32 rm_msr);
+u32 add_msr, u32 rm_msr);
 void rtl8821ae_set_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val);
 void rtl8821ae_update_hal_rate_tbl(struct ieee80211_hw *hw,
-   
struct ieee80211_sta *sta,
-   
u8 rssi_level);
+  struct ieee80211_sta *sta,
+  u8 rssi_level);
 void rtl8821ae_update_channel_access_setting(struct ieee80211_hw *hw);
 bool rtl8821ae_gpio_radio_on_off_checking(struct ieee80211_hw *hw, u8 *valid);
 void rtl8821ae_enable_hw_security_config(struct ieee80211_hw *hw);
 void rtl8821ae_set_key(struct ieee80211_hw *hw, u32 key_index,
-   u8 *p_macaddr, bool is_group, 
u8 enc_algo,
-   bool is_wepkey, bool clear_all);
+  u8 *p_macaddr, bool is_group, u8 enc_algo,
+  bool is_wepkey, bool clear_all);
 
 void rtl8821ae_read_bt_coexist_info_from_hwpg(struct ieee80211_hw *hw,
-   
bool autoload_fail,
-   
u8* hwinfo);
+ bool autoload_fail,
+ u8* hwinfo);
 void rtl8812ae_read_bt_coexist_info_from_hwpg(struct ieee80211_hw *hw,
-   
bool autoload_fail,
-   
u8* hwinfo);
+ bool autoload_fail,
+ u8* hwinfo);
 void rtl8821ae_bt_reg_init(struct ieee80211_hw* hw);
 void rtl8821ae_bt_hw_init(struct ieee80211_hw* hw);
 void rtl8821ae_suspend(struct ieee80211_hw *hw);
 void rtl8821ae_resume(struct ieee80211_hw *hw);
 void rtl8821ae_allow_all_destaddr(struct ieee80211_hw *hw,
-   
  bool allow_all_da,
-   
  bool write_into_reg);
+ bool allow_all_da,
+ bool write_into_reg);
 void _rtl8821ae_stop_tx_beacon(struct ieee80211_hw *hw);
 void _rtl8821ae_resume_tx_beacon(struct ieee80211_hw *hw);
 #endif
-- 
1.7.10.4

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


[PATCH 2/3] staging: rtl8821ae: Remove FSF mailing address from rtl8821ae/hw.h header

2014-04-10 Thread Mark Einon
Fix checkpatch check:

CHECK: Do not include the paragraph about writing to the Free Software
Foundation's mailing address from the sample GPL notice. The FSF has
changed addresses in the past, and may do so again. Linux already
includes a copy of the GPL.

Signed-off-by: Mark Einon 
---
 drivers/staging/rtl8821ae/rtl8821ae/hw.h |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.h 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
index 3f20681..335d4ab 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.h
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * The full GNU General Public License is included in this distribution in the
  * file called LICENSE.
  *
-- 
1.7.10.4

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


Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

2014-04-10 Thread Dan Carpenter
On Thu, Apr 10, 2014 at 09:57:23PM +1000, Vitaly Osipov wrote:
> Thanks, that's helpful - I for some reason thought that multi-part
> patch had to have more or less uniform subject. We the checkpatch.pl
> people come from http://www.eudyptula-challenge.org/, where at some
> stage we are told to submit a patch for a single style issue in the
> staging tree. All newbies... Hoping to be back with more substantial
> contributions soon.

Yeah, I know about eudyptula.  No worries.  Newbies are welcome in
staging.

regards,
dan carpenter

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


Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

2014-04-10 Thread Vitaly Osipov
Thanks, that's helpful - I for some reason thought that multi-part
patch had to have more or less uniform subject. We the checkpatch.pl
people come from http://www.eudyptula-challenge.org/, where at some
stage we are told to submit a patch for a single style issue in the
staging tree. All newbies... Hoping to be back with more substantial
contributions soon.
Regards,
Vitaly


On Thu, Apr 10, 2014 at 7:48 PM, Dan Carpenter  wrote:
> The two subjects are really close to being the same.  You should choose
> better subjects.  Like:
>
> [PATCH 2/2] staging: media: omap24xx: use pr_info() instead of KERN_INFO
>
>
> (All the checkpatch.pl people use the exact same subject for everything
> though, so you're not alone in this).
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

2014-04-10 Thread Dan Carpenter
The two subjects are really close to being the same.  You should choose
better subjects.  Like:

[PATCH 2/2] staging: media: omap24xx: use pr_info() instead of KERN_INFO


(All the checkpatch.pl people use the exact same subject for everything
though, so you're not alone in this).

regards,
dan carpenter

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


[patch 2/2] Staging: unisys: use after free in list_for_each()

2014-04-10 Thread Dan Carpenter
These should be using the _safe version of list_for_each() because we
free the current element and it leads to a use after free bug.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/unisys/visorchipset/visorchipset.h 
b/drivers/staging/unisys/visorchipset/visorchipset.h
index d4bf203..d95825d 100644
--- a/drivers/staging/unisys/visorchipset/visorchipset.h
+++ b/drivers/staging/unisys/visorchipset/visorchipset.h
@@ -104,9 +104,9 @@ finddevice(struct list_head *list, U32 busNo, U32 devNo)
 
 static inline void delbusdevices(struct list_head *list, U32 busNo)
 {
-   VISORCHIPSET_DEVICE_INFO *p;
+   VISORCHIPSET_DEVICE_INFO *p, *tmp;
 
-   list_for_each_entry(p, list, entry) {
+   list_for_each_entry_safe(p, tmp, list, entry) {
if (p->busNo == busNo) {
list_del(&p->entry);
kfree(p);
diff --git a/drivers/staging/unisys/visorchipset/visorchipset_main.c 
b/drivers/staging/unisys/visorchipset/visorchipset_main.c
index 257c6e5..c475e25 100644
--- a/drivers/staging/unisys/visorchipset/visorchipset_main.c
+++ b/drivers/staging/unisys/visorchipset/visorchipset_main.c
@@ -605,16 +605,16 @@ EXPORT_SYMBOL_GPL(visorchipset_register_busdev_client);
 static void
 cleanup_controlvm_structures(void)
 {
-   VISORCHIPSET_BUS_INFO *bi;
-   VISORCHIPSET_DEVICE_INFO *di;
+   VISORCHIPSET_BUS_INFO *bi, *tmp_bi;
+   VISORCHIPSET_DEVICE_INFO *di, *tmp_di;
 
-   list_for_each_entry(bi, &BusInfoList, entry) {
+   list_for_each_entry_safe(bi, tmp_bi, &BusInfoList, entry) {
busInfo_clear(bi);
list_del(&bi->entry);
kfree(bi);
}
 
-   list_for_each_entry(di, &DevInfoList, entry) {
+   list_for_each_entry_safe(di, tmp_di, &DevInfoList, entry) {
devInfo_clear(di);
list_del(&di->entry);
kfree(di);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[patch 1/2] staging: unisys: use after free in error messages

2014-04-10 Thread Dan Carpenter
We dereference "bus" when we report the error so we have to move the
kfree() down a couple lines.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/unisys/uislib/uislib.c 
b/drivers/staging/unisys/uislib/uislib.c
index 8ea9c46..3152a21 100644
--- a/drivers/staging/unisys/uislib/uislib.c
+++ b/drivers/staging/unisys/uislib/uislib.c
@@ -381,17 +381,17 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
cmd.add_vbus.busTypeGuid = msg->cmd.createBus.busDataTypeGuid;
cmd.add_vbus.busInstGuid = msg->cmd.createBus.busInstGuid;
if (!VirtControlChanFunc) {
-   kfree(bus);
LOGERR("CONTROLVM_BUS_CREATE Failed: virtpci callback 
not registered.");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->busNo,
 POSTCODE_SEVERITY_ERR);
+   kfree(bus);
return CONTROLVM_RESP_ERROR_VIRTPCI_DRIVER_FAILURE;
}
if (!VirtControlChanFunc(&cmd)) {
-   kfree(bus);
LOGERR("CONTROLVM_BUS_CREATE Failed: virtpci 
GUEST_ADD_VBUS returned error.");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->busNo,
 POSTCODE_SEVERITY_ERR);
+   kfree(bus);
return
CONTROLVM_RESP_ERROR_VIRTPCI_DRIVER_CALLBACK_ERROR;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH 2/3] staging: r8188eu: Fix case where ethtype was never obtained and always be checked against 0

2014-04-10 Thread David Laight
From: Dan Carpenter
...
> > -   if (auth_alg == 2) {
> > +   if (auth_alg == dot11AuthAlgrthm_8021X) {
> > +   /* get ether_type */
> > +   ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE;
> > +   memcpy(ðer_type, ptr, 2);
> > +   ether_type = ntohs((unsigned short)ether_type);
> 
> This cast doesn't make sense.  u16 and unsigned short are the same
> thing.  Anyway, the "ether_type" should be declared as __be16 because
> it's network endian.

Is it worth doing just:
ether_type = ptr[0] << 8 | ptr[1];
Or, if 'ptr' can't be misaligned, just reading a BE short.
If the compiler doesn't inline memcpy() the above code is horrid.

Are there MD inline functions for reading misaligned 16/32 bit date
with specific endianness?

David



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


[PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

2014-04-10 Thread Vitaly Osipov
tcm825x.c:

changed printk to pr_info

Signed-off-by: Vitaly Osipov 
---
 drivers/staging/media/omap24xx/tcm825x.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/omap24xx/tcm825x.c 
b/drivers/staging/media/omap24xx/tcm825x.c
index 2326481..3367ccd 100644
--- a/drivers/staging/media/omap24xx/tcm825x.c
+++ b/drivers/staging/media/omap24xx/tcm825x.c
@@ -914,8 +914,8 @@ static int __init tcm825x_init(void)
 
rval = i2c_add_driver(&tcm825x_i2c_driver);
if (rval)
-   printk(KERN_INFO "%s: failed registering " TCM825X_NAME "\n",
-  __func__);
+   pr_info("%s: failed registering " TCM825X_NAME "\n",
+   __func__);
 
return rval;
 }
-- 
1.7.9.5

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


[PATCH 1/2] staging: media: omap24xx: fix up checkpatch error message

2014-04-10 Thread Vitaly Osipov
tcm825x.c and tcm825x.h:

fixing ERROR: Macros with complex values should be enclosed in parenthesis

Signed-off-by: Vitaly Osipov 
---
 drivers/staging/media/omap24xx/tcm825x.c |8 
 drivers/staging/media/omap24xx/tcm825x.h |4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/omap24xx/tcm825x.c 
b/drivers/staging/media/omap24xx/tcm825x.c
index f4dd32d..2326481 100644
--- a/drivers/staging/media/omap24xx/tcm825x.c
+++ b/drivers/staging/media/omap24xx/tcm825x.c
@@ -89,10 +89,10 @@ static const struct tcm825x_reg rgb565  =   { 0x02, 
TCM825X_PICFMT };
 
 /* Our own specific controls */
 #define V4L2_CID_ALC   V4L2_CID_PRIVATE_BASE
-#define V4L2_CID_H_EDGE_EN V4L2_CID_PRIVATE_BASE + 1
-#define V4L2_CID_V_EDGE_EN V4L2_CID_PRIVATE_BASE + 2
-#define V4L2_CID_LENS  V4L2_CID_PRIVATE_BASE + 3
-#define V4L2_CID_MAX_EXPOSURE_TIME V4L2_CID_PRIVATE_BASE + 4
+#define V4L2_CID_H_EDGE_EN (V4L2_CID_PRIVATE_BASE + 1)
+#define V4L2_CID_V_EDGE_EN (V4L2_CID_PRIVATE_BASE + 2)
+#define V4L2_CID_LENS  (V4L2_CID_PRIVATE_BASE + 3)
+#define V4L2_CID_MAX_EXPOSURE_TIME (V4L2_CID_PRIVATE_BASE + 4)
 #define V4L2_CID_LAST_PRIV V4L2_CID_MAX_EXPOSURE_TIME
 
 /*  Video controls  */
diff --git a/drivers/staging/media/omap24xx/tcm825x.h 
b/drivers/staging/media/omap24xx/tcm825x.h
index 9970fb1..4a41127 100644
--- a/drivers/staging/media/omap24xx/tcm825x.h
+++ b/drivers/staging/media/omap24xx/tcm825x.h
@@ -21,8 +21,8 @@
 
 #define TCM825X_NAME "tcm825x"
 
-#define TCM825X_MASK(x)  x & 0x00ff
-#define TCM825X_ADDR(x) (x & 0xff00) >> 8
+#define TCM825X_MASK(x)  (x & 0x00ff)
+#define TCM825X_ADDR(x) ((x & 0xff00) >> 8)
 
 /* The TCM825X I2C sensor chip has a fixed slave address of 0x3d. */
 #define TCM825X_I2C_ADDR   0x3d
-- 
1.7.9.5

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


RE: system hang

2014-04-10 Thread Narasimharao Bolisetti

Hi,

I have checked the same in the recent kernel versions also. Issue is still 
remain.

Regards,
Narasimharao B


-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: 10 April 2014 13:26
To: narasimharo bolisetti
Cc: linux-ker...@vger.kernel.org; kernelnewb...@nl.linux.org; 
de...@linuxdriverproject.org; linux-ser...@vger.kernel.org; 
linux-hotp...@vger.kernel.org; g...@kroah.com; Narasimharao Bolisetti; 
nrbolise...@gmail.com; sta...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-...@vger.kernel.org
Subject: Re: system hang

On Thu, Apr 10, 2014 at 12:05:52AM -0700, narasimharo bolisetti wrote:
>  My kernel version is:
>  2.6.35.6-45.fc14.i686

Maintenance for this kernel has been dropped years ago, so it very likely 
contains many bugs that were fixed in more recent ones. You should definitely 
upgrade.

Hoping this helps,
Willy



::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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


Re: system hang

2014-04-10 Thread Willy Tarreau
On Thu, Apr 10, 2014 at 12:05:52AM -0700, narasimharo bolisetti wrote:
>  My kernel version is:
>  2.6.35.6-45.fc14.i686 

Maintenance for this kernel has been dropped years ago, so it very
likely contains many bugs that were fixed in more recent ones. You
should definitely upgrade.

Hoping this helps,
Willy

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


system hang

2014-04-10 Thread narasimharo bolisetti
 Hi Greg/All, 
    
 This is Narasimharao working for a s/wcompany HCLT.. 
    
 I am working a issue and
 the description is below: 
    
 system stops booting and
 needs a series of console inputs (space bar or return) to
 continue booting. Each input advances the process a little
 bit. 
 Actually I am trying to
 upgrade the s/w from usb pendrive, part of this upgrade
 having multiple times we are disconnecting and connecting
 the usb pen drive. 
    
 system stops booting and
 needs a series of console inputs (space bar or return) to
 continue booting. Each input advances the process a little
 bit. 
 I have tried to find the
 root cause for the issue but not get success, can you help
 me regarding to this what is the root cause and how i can
 fix this? 
    
 One more thing i observed
 that the space allocated for tty by 'tty_write_room'
 is suddenly consumed by more than 2k at the time of issue
 occurs and gradually
  
 consuming remaining memory
 and when reaches to zero upgrade completely hangs and when
 console inputs (space bar or return) to continue booting,
  
 Each input advances the
 process a little bit. This console i/p's creating some
 space for the same . Is this problem in tty?
  
 one more thing we observed
 that whenever we increase the logging then this problem
 happens regularly. 
    
 [   66.233676]
 EXT3-fs (sda14): using internal journal 
 [   66.233691]
 EXT3-fs (sda14): mounted filesystem with ordered data
 mode 
  
 [   76.822878]
 par.que...par_queue_user_receive: Freeze check =0 
 [   76.828711]
 par.que...par_queue_user_receive: <*> returned
 -ERESTARTSYS <*> event =-512 
 [   76.837241]
 par_ldisc_open:record is found for ttyS4 
 [   76.842766]
 par.que...par_queue_user_receive: Freeze check =0 
 [   76.848594]
 par.que...par_queue_user_receive: <*> returned
 -ERESTARTSYS <*> event =-512 
 [  101.781654] usb
 1-1.3: USB disconnect, address 3 
 [  104.029178] usb
 1-1.3: new high speed USB device using fsl-ehci and address
 4 
 [  104.159085] scsi2
 : usb-storage 1-1.3:1.0 
 [  105.163726] scsi
 2:0:0:0: Direct-Access Kingston
 DataTraveler 2.0 1.00 PQ: 0 ANSI: 2 
 [  105.173202] sd
 2:0:0:0: Attached scsi generic sg1 type 0 
 [  105.173686] sd
 2:0:0:0: [sdb] 4006912 512-byte logical blocks: (2.05
 GB/1.91 GiB) 
 [  105.174177] sd
 2:0:0:0: [sdb] Write Protect is off 
 [  105.174188] sd
 2:0:0:0: [sdb] Mode Sense: 23 00 00 00 
 [  105.174197] sd
 2:0:0:0: [sdb] Assuming drive cache: write through 
 [  105.178804] sd
 2:0:0:0: [sdb] Assuming drive cache: write through 
 [  105.178825] 
 sdb: sdb1 
 [  105.295052] sd
 2:0:0:0: [sdb] Assuming drive cache: write through 
 [  105.301142] sd
 2:0:0:0: [sdb] Attached SCSI removable
 disk  
 - Hangs at this place and
 console i/p’s to continue booting. 
    
 I have tried with
 different sizes and different vendors pen drives but problem
 is the same and occurs at the same place. 
    
 Your valuable inputs and
 suggetions are helpful to fix this issue. 
    
 My kernel version is:
 2.6.35.6-45.fc14.i686 
    
 Thanks in advance for
 helping and replying. 
    
    
 Regards, 
 Narasimharao B 
    
    
    
    
    
 
 
 
 
 ::DISCLAIMER::
 

 The contents of
 this e-mail and any attachment(s) are confidential and
 intended for the named recipient(s) only.
 E-mail transmission is not guaranteed to be secure or
 error-free as information could be intercepted, corrupted, 
 lost, destroyed, arrive late or incomplete, or may contain
 viruses in transmission. The e mail and its contents 
 (with or without referred errors) shall therefore not attach
 any liability on the originator or HCL or its affiliates. 
 Views or opinions, if any, presented in this email are
 solely those of the author and may not necessarily reflect
 the 
 views or opinions of HCL or its affiliates. Any form of
 reproduction, dissemination, copying, disclosure,
 modification, 
 distribution and / or publication of this message without
 the prior written consent of authorized representative of 
 HCL is strictly prohibited. If you have received this email
 in error please delete it and notify the sender immediately.
 
 Before opening any email and/or attachments, please check
 them for viruses and other defects.
 

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