Re: [PATCH] mmc: rtsx: usb backend needs LED support
On Wednesday 30 April 2014 11:34:33 Roger wrote: > I think Ulf's idea is to fix the bug by modifying the .c files. > I really found the problem of my ifdef hackery and it should do > something similar in sdhci.c as: > > From: Roger Tseng > Date: Wed, 30 Apr 2014 11:11:25 +0800 > Subject: [PATCH] mmc: rtsx: fix possible linking error if built-in > > rtsx_usb_sdmmc module uses the LED classdev if available, but the code > failed > to consider the situation that it is built-in and the LED classdev is a > module, > leading to following linking error: > >LD init/built-in.o > drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove': > rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to > `led_classdev_unregister' > drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe': > rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to > `led_classdev_register' > > Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS. > > Signed-off-by: Roger Tseng Yes, that should work, too. Acked-by: Arnd Bergmann > --- > drivers/mmc/host/rtsx_usb_sdmmc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c > b/drivers/mmc/host/rtsx_usb_sdmmc.c > index e11fafa..38bdda5 100644 > --- a/drivers/mmc/host/rtsx_usb_sdmmc.c > +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c > @@ -34,7 +34,8 @@ > #include > #include > > -#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) > +#if defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ > + defined(CONFIG_MMC_REALTEK_USB_MODULE)) > #include > #include > #define RTSX_USB_USE_LEDS_CLASS > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6 v2] staging: comedi: addi_apci_1564: remove use of devpriv->s_EeParameters
Ian and Hartley, Thanks so much, I greatly appreciate the review. I'll fix the changelog for patch 4 and send once more (as I assume that's easier for Greg). Also, I should know better about the cover letter as well...I was once told not to send them for strictly cleanup patchsets (as Greg can't do anything with them and cleanups should be obvious) but I've gotten in the habit of not doing a cover letter for any patchsets. I will send cover letters (and be more careful about my other mistakes) in the future. Thanks, Chase On Tue, Apr 29, 2014 at 3:33 PM, Hartley Sweeten wrote: > On, Tuesday, April 29, 2014 1:38 AM, Chase Southwood wrote: >> This driver no longer reads the eeprom to find the board specific data, >> all the necessary data is in the boardinfo. Use the boardinfo directly >> instead of passing through devpriv->s_EeParameters. >> >> Signed-off-by: Chase Southwood >> Cc: Ian Abbott >> Cc: H Hartley Sweeten >> --- >> 2: Incorrect patch title fixed. >> >> Ian and Hartley, >> >> The auto_attach() function is starting to look much better now. My next >> patchset >> will be geared towards only allocating subdevices which are actually used. > > Other than Ian's comment on patch 4/6 everything looks good to me. > > For the series: > Reviewed-by: H Hartley Sweeten > > BTW, for a patch series you should include a cover letter (PATCH 00/xx). > > Regards, > Hartley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 4/4] memstick: Add realtek USB memstick host driver
On 04/28/2014 06:10 PM, Lee Jones wrote: 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 Applied, thanks. Greg, Since all patches have been applied and the device is now supported by the new driver, would you remove the former staging one at drivers/staging/rts5139? Similar removal had been done for our PCIE devices in: commit cd2112220b6b0a35fa12ba988a0dd837515dfaf8 Author: Greg Kroah-Hartman Date: Fri Oct 26 09:03:21 2012 -0700 Staging: remove rts_pstor driver Best regards, Roger Tseng ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6 v3] staging: comedi: addi_apci_1564: simplify the PCI bar reading and don't read the unused bars
This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1 (dev->iobase), don't bother reading the unused PCI bars. Signed-off-by: Chase Southwood Cc: Ian Abbott Cc: H Hartley Sweeten --- 2: Bad PCI bar numbers corrected. 3: Fixed silly typos in the changelog drivers/staging/comedi/drivers/addi_apci_1564.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c b/drivers/staging/comedi/drivers/addi_apci_1564.c index fe42f9d..7e42d47 100644 --- a/drivers/staging/comedi/drivers/addi_apci_1564.c +++ b/drivers/staging/comedi/drivers/addi_apci_1564.c @@ -65,15 +65,8 @@ static int apci1564_auto_attach(struct comedi_device *dev, if (ret) return ret; - if (this_board->i_IorangeBase1) - dev->iobase = pci_resource_start(pcidev, 1); - else - dev->iobase = pci_resource_start(pcidev, 0); - - devpriv->iobase = dev->iobase; - devpriv->i_IobaseAmcc = pci_resource_start(pcidev, 0); - devpriv->i_IobaseAddon = pci_resource_start(pcidev, 2); - devpriv->i_IobaseReserved = pci_resource_start(pcidev, 3); + dev->iobase = pci_resource_start(pcidev, 1); + devpriv->i_IobaseAmcc = pci_resource_start(pcidev, 0); /* Initialize parameters that can be overridden in EEPROM */ devpriv->s_EeParameters.i_NbrAiChannel = this_board->i_NbrAiChannel; -- 1.9.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 41/47] staging/lustre/llite: remove dead code
On Tue, Apr 29, 2014 at 11:21:48PM -0400, Oleg Drokin wrote: > I can rediff this patch with this particular part dropped if there are > any concerns and it's possible to reintegrate it in a changed form. No no. I knew that Greg had already merged this stuff by the time I got around to reviewing it. It was just some bonus grumbling after the fact. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mmc: rtsx: usb backend needs LED support
On 30 April 2014 05:34, Roger wrote: > > On 04/29/2014 08:46 PM, Arnd Bergmann wrote: >> >> On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote: >>> >>> On 29 April 2014 11:45, Arnd Bergmann wrote: drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove': :(.text+0x806480): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe': :(.text+0x806708): undefined reference to `led_classdev_register' This adds an explicit dependency in Kconfig >>> >>> >>> I think the proper solution is to fix the dependency in the driver code >>> instead. >>> >>> There are already some ifdefs hackery for making it optional to use >>> leds, apparently that's not working properly. >>> >> >> Ah, right, I misinterpreted the bug. Here is a new version: >> >> 8<- >>> >>> From 5b5588f8c9b8ded8b296fd32d87b2d118e548a29 Mon Sep 17 00:00:00 2001 >> >> From: Arnd Bergmann >> Date: Tue, 29 Apr 2014 11:41:40 +0200 >> Subject: [PATCH] mmc: rtsx: usb backend needs LED support >> >> Building the rtsx USB driver uses the LED classdev base >> support if available, but that fails if the classdev >> is a module and the MMC driver is built-in, leading to this >> link error. >> >> drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove': >> :(.text+0x806480): undefined reference to `led_classdev_unregister' >> drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe': >> :(.text+0x806708): undefined reference to `led_classdev_register' >> >> This adds an explicit dependency in Kconfig to ensure that >> the MMC driver has to be a module if LEDS_CLASS is a module, >> but still allows it to be built-in if LEDS_CLASS is either >> disabled or built-in. >> >> Signed-off-by: Arnd Bergmann >> >> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig >> index 92d91fe..68da9b8 100644 >> >> --- a/drivers/mmc/host/Kconfig >> +++ b/drivers/mmc/host/Kconfig >> @@ -696,6 +696,7 @@ config MMC_REALTEK_PCI >> config MMC_REALTEK_USB >> tristate "Realtek USB SD/MMC Card Interface Driver" >> depends on MFD_RTSX_USB >> + depends on m || LEDS_CLASS!=m >> >> help >> Say Y here to include driver code to support SD/MMC card >> interface >> of Realtek RTS5129/39 series card reader >> >> . >> > > I think Ulf's idea is to fix the bug by modifying the .c files. > I really found the problem of my ifdef hackery and it should do something > similar in sdhci.c as: > > From: Roger Tseng > Date: Wed, 30 Apr 2014 11:11:25 +0800 > Subject: [PATCH] mmc: rtsx: fix possible linking error if built-in > > rtsx_usb_sdmmc module uses the LED classdev if available, but the code > failed > to consider the situation that it is built-in and the LED classdev is a > module, > leading to following linking error: > > LD init/built-in.o > drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove': > rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to > `led_classdev_unregister' > drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe': > rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to > `led_classdev_register' > > Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS. > > Signed-off-by: Roger Tseng Acked-by: Ulf Hansson > --- > drivers/mmc/host/rtsx_usb_sdmmc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c > b/drivers/mmc/host/rtsx_usb_sdmmc.c > index e11fafa..38bdda5 100644 > --- a/drivers/mmc/host/rtsx_usb_sdmmc.c > +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c > @@ -34,7 +34,8 @@ > #include > #include > > -#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) > +#if defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ > + defined(CONFIG_MMC_REALTEK_USB_MODULE)) > #include > #include > #define RTSX_USB_USE_LEDS_CLASS > > Best regards, > Roger Tseng ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/6 v3] staging: comedi: addi_apci_1564: simplify the PCI bar reading and don't read the unused bars
On 2014-04-30 08:57, Chase Southwood wrote: This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1 (dev->iobase), don't bother reading the unused PCI bars. Signed-off-by: Chase Southwood Cc: Ian Abbott Cc: H Hartley Sweeten --- 2: Bad PCI bar numbers corrected. 3: Fixed silly typos in the changelog drivers/staging/comedi/drivers/addi_apci_1564.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) Okay now! 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 00/32] staging: comedi: continue async command cleanup
On 2014-04-29 20:59, H Hartley Sweeten wrote: Remove some unnecessary pacer divisor calculations. The divisors are calculated as part of the (*do_cmdtest) and don't need done in the (*do_cmd). Remomove the older, unused, divisor calc functions in 8253.h to avoid any confusion. Remove some unnecessary private data members in a couple drivers and the addi_common.h header. Tidy up hwdrv_apci3120 a bit. Fix a couple 8254 timer programming issues. As Ian Abbott pointed out, the i8254_load() function does not use the I8254_MODE* defines. Convert all drivers to use the i8254_set_mode()/i8254_write() sequence instead. v2: Fix some i8254_load() issued pointed out by Ian Abbott in patches 01, 02, 03, and 05. Add a couple new patchs (24 thru 32) to fix/clarify the remaining i8254_load() issues. H Hartley Sweeten (32): staging: comedi: cb_pcidas: don't calc ai pacer divisors twice staging: comedi: cb_pcidas: don't calc ao pacer divisors twice staging: comedi: das16m1: don't calc pacer divisors twice staging: comedi: das1800: refactor Step 4 of das1800_ai_do_cmdtest() staging: comedi: das1800: don't calc pacer divisors twice staging: comedi: 8253.h: rename i8253_cascade_ns_to_timer_2div() staging: comedi: 8253.h: remove the unused i8253_cascade_ns_to_timer_*() staging: comedi: adl_pci9111: tidy up (*do_cmdtest) Step 4 staging: comedi: addi_apci_2032: tidy up cmd use in apci2032_interrupt() staging: comedi: amplc_pci224: remove 'ai_stop_continuous' from private data staging: comedi: amplc_pci230: remove 'ai_continuous' from private data staging: comedi: amplc_pci230: remove 'ao_continuous' from private data staging: comedi: addi_common.h: remove 'ui_AiFlags' from private data staging: comedi: addi_common.h: remove 'ui_AiScanLength' from private data staging: comedi: addi_common.h: remove 'pui_AiChannelList' from private data staging: comedi: addi_common.h: remove 'ui_AiTimer0' from private data staging: comedi: addi_common.h: remove 'ui_AiTimer1' from private data staging: comedi: addi_common.h: remove 'ui_AiDataLength' from private data staging: comedi: addi_common.h: remove 'ui_AiNbrofScans' from private data staging: comedi: addi_common.h: remove 'b_AiContinuous' from private data staging: comedi: hwdrv_apci3120: cmd->convert_src is always TRIG_TIMER staging: comedi: hwdrv_apci3120: fix 'b_AiCyclicAcquisition' usage staging: comedi: hwdrv_apci3120: remove clearing of 'b_OutputMemoryStatus' staging: comedi: pcl711: fix 8254 timer programming staging: comedi: ni_at_ao: fix 8254 timer programming staging: comedi: me4000: fix 8254 timer programming staging: comedi: amplc_pci244: clarify 8254 timer programming staging: comedi: das800: clarify 8254 timer programming staging: comedi: ni_labpc: fix 8254 timer programming staging: comedi: ni_at_a2150: clarify 8254 timer programming staging: comedi: das16m1: clarify 8254 timer programming staging: comedi: das16: clarify 8254 timer programming drivers/staging/comedi/drivers/8253.h | 105 + .../staging/comedi/drivers/addi-data/addi_common.h | 10 +- .../comedi/drivers/addi-data/hwdrv_apci3120.c | 163 +++-- drivers/staging/comedi/drivers/addi_apci_2032.c| 20 +-- drivers/staging/comedi/drivers/adl_pci9111.c | 38 ++--- drivers/staging/comedi/drivers/amplc_pci224.c | 30 ++-- drivers/staging/comedi/drivers/amplc_pci230.c | 47 ++ drivers/staging/comedi/drivers/cb_pcidas.c | 49 +++ drivers/staging/comedi/drivers/das16.c | 7 +- drivers/staging/comedi/drivers/das16m1.c | 48 +++--- drivers/staging/comedi/drivers/das1800.c | 147 ++- drivers/staging/comedi/drivers/das800.c| 21 +-- drivers/staging/comedi/drivers/me4000.c| 8 +- drivers/staging/comedi/drivers/ni_at_a2150.c | 4 +- drivers/staging/comedi/drivers/ni_at_ao.c | 8 +- drivers/staging/comedi/drivers/ni_labpc.c | 92 +--- drivers/staging/comedi/drivers/pcl711.c| 19 ++- 17 files changed, 274 insertions(+), 542 deletions(-) Looks good! As a side node, I wonder if it's worth stripping out those `| I8254_BINARY` bits as it's basically 'OR'ing with zero anyway. 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
[patch] staging: rtl8192u: cleanup a switch statement
The white space was all wrong here. The case statements were indented
too far. The if else blocks weren't indented at all. There was a break
statement aligned with the else block and it confused my static checker
because "were curly braces intended" so that the break statement was
only on the else side? Also I removed some commented out code.
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 2131912..9caf6fd 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -1903,20 +1903,17 @@ static void ieee80211_process_action(struct
ieee80211_device *ieee,
}
tmp = *act;
act ++;
- switch (tmp)
- {
- case ACT_CAT_BA:
- if (*act == ACT_ADDBAREQ)
+ switch (tmp) {
+ case ACT_CAT_BA:
+ if (*act == ACT_ADDBAREQ)
ieee80211_rx_ADDBAReq(ieee, skb);
- else if (*act == ACT_ADDBARSP)
+ else if (*act == ACT_ADDBARSP)
ieee80211_rx_ADDBARsp(ieee, skb);
- else if (*act == ACT_DELBA)
+ else if (*act == ACT_DELBA)
ieee80211_rx_DELBA(ieee, skb);
- break;
- default:
-// if (net_ratelimit())
-// IEEE80211_DEBUG(IEEE80211_DL_BA, "unknown action
frame(%d)\n", tmp);
- break;
+ break;
+ default:
+ break;
}
return;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: parport: Fix format string mismatch in bw-qcam.c
Fix format string mismatch in bw-qcam.c
Signed-off-by: Masanari Iida
---
drivers/media/parport/bw-qcam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c
index 8a0e84c..416507a 100644
--- a/drivers/media/parport/bw-qcam.c
+++ b/drivers/media/parport/bw-qcam.c
@@ -937,7 +937,7 @@ static struct qcam *qcam_init(struct parport *port)
return NULL;
v4l2_dev = &qcam->v4l2_dev;
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "bw-qcam%d", num_cams);
+ snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "bw-qcam%u", num_cams);
if (v4l2_device_register(port->dev, v4l2_dev) < 0) {
v4l2_err(v4l2_dev, "Could not register v4l2_device\n");
--
2.0.0.rc1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: parport: Fix format string mismatch in bw-qcam.c
On Wed, Apr 30, 2014 at 07:51:13PM +0900, Masanari Iida wrote: > Fix format string mismatch in bw-qcam.c > > Signed-off-by: Masanari Iida > --- > drivers/media/parport/bw-qcam.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c > index 8a0e84c..416507a 100644 > --- a/drivers/media/parport/bw-qcam.c > +++ b/drivers/media/parport/bw-qcam.c This isn't a "staging" driver, so why is "staging" in the Subject? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] [linux-next] [staging] rtl8821ae: fixed defined-not-used warning
The function halbtc8192e2ant_iswifi_status_changed is called only
at line 4158 which is #if'd in the same way as I'm now #if-ing the function.
Signed-off-by: Jan Moskyto Matejka
---
drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
index 81706f4..7af412d 100644
--- a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
+++ b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
@@ -503,6 +503,7 @@ static void halbtc8192e2ant_querybt_info(struct btc_coexist
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
}
+#if (BT_AUTO_REPORT_ONLY_8192E_2ANT != 0)
static bool halbtc8192e2ant_iswifi_status_changed(struct btc_coexist
*btcoexist)
{
static bool pre_wifi_busy;
@@ -534,6 +535,7 @@ static bool halbtc8192e2ant_iswifi_status_changed(struct
btc_coexist *btcoexist)
return false;
}
+#endif
static void halbtc8192e2ant_update_btlink_info(struct btc_coexist *btcoexist)
{
--
1.8.4.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [linux-next] [staging] rtl8821ae: fixed defined-not-used warning
On Wed, 2014-04-30 at 14:15 +0200, Jan Moskyto Matejka wrote:
> --- a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
> +++ b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
> @@ -503,6 +503,7 @@ static void halbtc8192e2ant_querybt_info(struct
> btc_coexist *btcoexist)
> btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
> }
>
> +#if (BT_AUTO_REPORT_ONLY_8192E_2ANT != 0)
> static bool halbtc8192e2ant_iswifi_status_changed(struct btc_coexist
> *btcoexist)
> {
> static bool pre_wifi_busy;
> @@ -534,6 +535,7 @@ static bool halbtc8192e2ant_iswifi_status_changed(struct
> btc_coexist *btcoexist)
>
> return false;
> }
> +#endif
>
> static void halbtc8192e2ant_update_btlink_info(struct btc_coexist *btcoexist)
> {
The output of
git grep BT_AUTO_REPORT_ONLY_8192E_2ANT next-20140430
is
next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
(BT_AUTO_REPORT_ONLY_8192E_2ANT == 1)
next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
(BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
(BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h:#define
BT_AUTO_REPORT_ONLY_8192E_2ANT 0
So it seems that some trivial cleaning up is possible. Ie, drop the
#define and drop the three tests that are either always true or always
false. Is there a reason not to do that cleaning up?
Paul Bolle
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: parport: Fix format string mismatch in bw-qcam.c
CC to Stephen Rothwell > This isn't a "staging" driver, so why is "staging" in the Subject? I made this patch based on linux-next. "media" directory really exist in current linux-next. For example... https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/staging?id=refs/tags/next-20140430 But as I see the patch itself carefully, the path "staging" does NOT included. So it seemed something going wrong with linux-next merger. I will resend the patch with correct title and correct mailing list later on. Thanks. Masanari On Wed, Apr 30, 2014 at 8:43 PM, Greg KH wrote: > On Wed, Apr 30, 2014 at 07:51:13PM +0900, Masanari Iida wrote: >> Fix format string mismatch in bw-qcam.c >> >> Signed-off-by: Masanari Iida >> --- >> drivers/media/parport/bw-qcam.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/media/parport/bw-qcam.c >> b/drivers/media/parport/bw-qcam.c >> index 8a0e84c..416507a 100644 >> --- a/drivers/media/parport/bw-qcam.c >> +++ b/drivers/media/parport/bw-qcam.c > > This isn't a "staging" driver, so why is "staging" in the Subject? > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [linux-next] [staging] rtl8821ae: fixed defined-not-used warning
On Wed, Apr 30, 2014 at 02:39:50PM +0200, Paul Bolle wrote:
> On Wed, 2014-04-30 at 14:15 +0200, Jan Moskyto Matejka wrote:
> > --- a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
> > +++ b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
> > @@ -503,6 +503,7 @@ static void halbtc8192e2ant_querybt_info(struct
> > btc_coexist *btcoexist)
> > btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
> > }
> >
> > +#if (BT_AUTO_REPORT_ONLY_8192E_2ANT != 0)
> > static bool halbtc8192e2ant_iswifi_status_changed(struct btc_coexist
> > *btcoexist)
> > {
> > static bool pre_wifi_busy;
> > @@ -534,6 +535,7 @@ static bool
> > halbtc8192e2ant_iswifi_status_changed(struct btc_coexist *btcoexist)
> >
> > return false;
> > }
> > +#endif
> >
> > static void halbtc8192e2ant_update_btlink_info(struct btc_coexist
> > *btcoexist)
> > {
>
> The output of
> git grep BT_AUTO_REPORT_ONLY_8192E_2ANT next-20140430
>
> is
> next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
> (BT_AUTO_REPORT_ONLY_8192E_2ANT == 1)
> next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
> (BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
> next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:#if
> (BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
>
> next-20140430:drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h:#define
> BT_AUTO_REPORT_ONLY_8192E_2ANT 0
>
> So it seems that some trivial cleaning up is possible. Ie, drop the
> #define and drop the three tests that are either always true or always
> false. Is there a reason not to do that cleaning up?
I thought this part of code is here for somebody who wants to make a
custom build with this variable changed to compile in the other
behaviour. But after a while, it stopped to make sense for me. I may
clean it up. I'll send a cleanup-patch later.
--
Jan Matějka
SUSE Labs
signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] [linux-next] [staging] rtl8821ae: fixed defined-not-used warning
by cleaning up BT_AUTO_REPORT_ONLY_8192E_2ANT
(always set to 0, never used as constant)
halbtc8192e2ant_iswifi_status_changed was called only from the unused code
Signed-off-by: Jan Moskyto Matejka
---
.../staging/rtl8821ae/btcoexist/halbtc8192e2ant.c | 43 --
.../staging/rtl8821ae/btcoexist/halbtc8192e2ant.h | 2 -
2 files changed, 45 deletions(-)
diff --git a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
index 81706f4..d238179 100644
--- a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
+++ b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c
@@ -503,38 +503,6 @@ static void halbtc8192e2ant_querybt_info(struct
btc_coexist *btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
}
-static bool halbtc8192e2ant_iswifi_status_changed(struct btc_coexist
*btcoexist)
-{
- static bool pre_wifi_busy;
- static bool pre_under_4way, pre_bt_hson;
- bool wifi_busy = false, under_4way = false, bt_hson = false;
- bool wifi_connected = false;
-
- btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_CONNECTED,
- &wifi_connected);
- btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_BUSY, &wifi_busy);
- btcoexist->btc_get(btcoexist, BTC_GET_BL_HS_OPERATION, &bt_hson);
- btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_4_WAY_PROGRESS,
- &under_4way);
-
- if (wifi_connected) {
- if (wifi_busy != pre_wifi_busy) {
- pre_wifi_busy = wifi_busy;
- return true;
- }
- if (under_4way != pre_under_4way) {
- pre_under_4way = under_4way;
- return true;
- }
- if (bt_hson != pre_bt_hson) {
- pre_bt_hson = bt_hson;
- return true;
- }
- }
-
- return false;
-}
-
static void halbtc8192e2ant_update_btlink_info(struct btc_coexist *btcoexist)
{
struct btc_bt_link_info *bt_link_info = &btcoexist->bt_link_info;
@@ -3833,9 +3801,6 @@ void ex_halbtc8192e2ant_display_coex_info(struct
btc_coexist *btcoexist)
"0x774(lp rx[31:16]/tx[15:0])",
coex_sta->low_priority_rx, coex_sta->low_priority_tx);
CL_PRINTF(cli_buf);
-#if (BT_AUTO_REPORT_ONLY_8192E_2ANT == 1)
- halbtc8192e2ant_monitor_bt_ctr(btcoexist);
-#endif
btcoexist->btc_disp_dbg_msg(btcoexist, BTC_DBG_DISP_COEX_STATISTICS);
}
@@ -4011,14 +3976,12 @@ void ex_halbtc8192e2ant_bt_info_notify(struct
btc_coexist *btcoexist,
* do nothing here. */
}
-#if (BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
if ((coex_sta->bt_info_ext & BIT4)) {
/* BT auto report already enabled, do nothing */
} else {
halbtc8192e2ant_bt_autoreport(btcoexist, FORCE_EXEC,
true);
}
-#endif
}
/* check BIT2 first ==> check if bt is under inquiry or page scan */
@@ -4148,14 +4111,8 @@ void ex_halbtc8192e2ant_periodical(struct btc_coexist
*btcoexist)
"\n");
}
-#if (BT_AUTO_REPORT_ONLY_8192E_2ANT == 0)
halbtc8192e2ant_querybt_info(btcoexist);
halbtc8192e2ant_monitor_bt_ctr(btcoexist);
halbtc8192e2ant_monitor_bt_enable_disable(btcoexist);
-#else
- if (halbtc8192e2ant_iswifi_status_changed(btcoexist) ||
- coex_dm->auto_tdma_adjust)
- halbtc8192e2ant_run_coexist_mechanism(btcoexist);
-#endif
}
diff --git a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h
b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h
index 6d109edb..416d3dda 100644
--- a/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h
+++ b/drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.h
@@ -1,8 +1,6 @@
/*
* The following is for 8192E 2Ant BT Co-exist definition
*/
-#defineBT_AUTO_REPORT_ONLY_8192E_2ANT 0
-
#defineBT_INFO_8192E_2ANT_B_FTPBIT7
#defineBT_INFO_8192E_2ANT_B_A2DP BIT6
#defineBT_INFO_8192E_2ANT_B_HIDBIT5
--
1.8.4.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Drivers/hv
Greg, Some time back I had sent a buch of patches for Hyper-V drivers. Are they still in the queue or should I resend them. Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the send path
> -Original Message- > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > Sent: Wednesday, April 23, 2014 2:25 PM > To: da...@davemloft.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com > Cc: KY Srinivasan > Subject: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the > send path > > We send packets using a copy-free mechanism (this is the Guest to Host > transport via VMBUS). While this is obviously optimal for large packets, it > may > not be optimal for small packets. Hyper-V host supports a second mechanism > for sending packets that is "copy based". We implement that mechanism in > this patch. > > In this version of the patch I have addressed a comment from David Miller. David, Please let me know if there is some other issue you want addressed in this patch. Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 net-next 1/1] hyperv: Properly handle checksum offload
Do checksum offload only if the client of the driver wants checksum to be offloaded. In V1 version of this patch, I addressed comments from Stephen Hemminger and Eric Dumazet . In this version of the patch I have addressed comments from David Miller. This patch fixes a bug that is exposed in gateway scenarios. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang Cc: sta...@kernel.org --- drivers/net/hyperv/netvsc_drv.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 939e3af..64c7816 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -467,6 +467,10 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) if (skb_is_gso(skb)) goto do_lso; + if ((skb->ip_summed == CHECKSUM_NONE) || + (skb->ip_summed == CHECKSUM_UNNECESSARY)) + goto do_send; + rndis_msg_size += NDIS_CSUM_PPI_SIZE; ppi = init_ppi_data(rndis_msg, NDIS_CSUM_PPI_SIZE, TCPIP_CHKSUM_PKTINFO); -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the send path
From: KY Srinivasan Date: Wed, 30 Apr 2014 14:17:04 + > Please let me know if there is some other issue you want addressed in this > patch. If the patch isn't in patchwork, I'm not going to apply it and you need to simply resubmit it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the send path
We send packets using a copy-free mechanism (this is the Guest to Host transport
via VMBUS). While this is obviously optimal for large packets,
it may not be optimal for small packets. Hyper-V host supports
a second mechanism for sending packets that is "copy based". We implement that
mechanism in this patch.
In this version of the patch I have addressed a comment from David Miller.
With this patch (and all of the other offload and VRSS patches), we are now able
to almost saturate a 10G interface between Linux VMs on Hyper-V
on different hosts - close to 9 Gbps as measured via iperf.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 14 +++
drivers/net/hyperv/netvsc.c | 226 +--
drivers/net/hyperv/netvsc_drv.c |3 +-
3 files changed, 234 insertions(+), 9 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index d1f7826..4b7df5a 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -140,6 +140,8 @@ struct hv_netvsc_packet {
void *send_completion_ctx;
void (*send_completion)(void *context);
+ u32 send_buf_index;
+
/* This points to the memory after page_buf */
struct rndis_message *rndis_msg;
@@ -582,6 +584,9 @@ struct nvsp_message {
#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */
#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY (1024*1024*15) /* 15MB */
+#define NETVSC_SEND_BUFFER_SIZE(1024 * 1024) /* 1MB
*/
+#define NETVSC_INVALID_INDEX -1
+
#define NETVSC_RECEIVE_BUFFER_ID 0xcafe
@@ -607,6 +612,15 @@ struct netvsc_device {
u32 recv_section_cnt;
struct nvsp_1_receive_buffer_section *recv_section;
+ /* Send buffer allocated by us */
+ void *send_buf;
+ u32 send_buf_size;
+ u32 send_buf_gpadl_handle;
+ u32 send_section_cnt;
+ u32 send_section_size;
+ unsigned long *send_section_map;
+ int map_words;
+
/* Used for NetVSP initialization protocol */
struct completion channel_init_wait;
struct nvsp_message channel_init_pkt;
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index bbee446..c041f63 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "hyperv_net.h"
@@ -80,7 +81,7 @@ get_in_err:
}
-static int netvsc_destroy_recv_buf(struct netvsc_device *net_device)
+static int netvsc_destroy_buf(struct netvsc_device *net_device)
{
struct nvsp_message *revoke_packet;
int ret = 0;
@@ -146,10 +147,62 @@ static int netvsc_destroy_recv_buf(struct netvsc_device
*net_device)
net_device->recv_section = NULL;
}
+ /* Deal with the send buffer we may have setup.
+* If we got a send section size, it means we received a
+* SendsendBufferComplete msg (ie sent
+* NvspMessage1TypeSendReceiveBuffer msg) therefore, we need
+* to send a revoke msg here
+*/
+ if (net_device->send_section_size) {
+ /* Send the revoke receive buffer */
+ revoke_packet = &net_device->revoke_packet;
+ memset(revoke_packet, 0, sizeof(struct nvsp_message));
+
+ revoke_packet->hdr.msg_type =
+ NVSP_MSG1_TYPE_REVOKE_SEND_BUF;
+ revoke_packet->msg.v1_msg.revoke_recv_buf.id = 0;
+
+ ret = vmbus_sendpacket(net_device->dev->channel,
+ revoke_packet,
+ sizeof(struct nvsp_message),
+ (unsigned long)revoke_packet,
+ VM_PKT_DATA_INBAND, 0);
+ /* If we failed here, we might as well return and
+* have a leak rather than continue and a bugchk
+*/
+ if (ret != 0) {
+ netdev_err(ndev, "unable to send "
+ "revoke send buffer to netvsp\n");
+ return ret;
+ }
+ }
+ /* Teardown the gpadl on the vsp end */
+ if (net_device->send_buf_gpadl_handle) {
+ ret = vmbus_teardown_gpadl(net_device->dev->channel,
+ net_device->send_buf_gpadl_handle);
+
+ /* If we failed here, we might as well return and have a leak
+* rather than continue and a bugchk
+*/
+ if (ret != 0) {
+ netdev_err(ndev,
+ "unable to teardown send buffer's gpadl\n");
+ return ret;
+ }
+ net_device->recv_buf_gpadl_handle = 0;
+ }
+ if (net_device->send_buf) {
+
[RESEND] [PATCH] staging: android: fix missing a blank line after declarations
This patch fixes "Missing a blank line after declarations" warnings.
Signed-off-by: Seunghun Lee
---
drivers/staging/android/alarm-dev.c |1 +
drivers/staging/android/binder.c | 34 +
drivers/staging/android/ion/ion.c | 10
drivers/staging/android/ion/ion_heap.c|2 ++
drivers/staging/android/ion/ion_priv.h|1 +
drivers/staging/android/ion/ion_system_heap.c |5
drivers/staging/android/logger.c |3 +++
drivers/staging/android/sw_sync.c |2 ++
drivers/staging/android/sync.c|8 ++
drivers/staging/android/timed_gpio.c |1 +
10 files changed, 67 insertions(+)
diff --git a/drivers/staging/android/alarm-dev.c
b/drivers/staging/android/alarm-dev.c
index 2fc7cdd..f200e8a 100644
--- a/drivers/staging/android/alarm-dev.c
+++ b/drivers/staging/android/alarm-dev.c
@@ -329,6 +329,7 @@ static int alarm_release(struct inode *inode, struct file
*file)
if (file->private_data) {
for (i = 0; i < ANDROID_ALARM_TYPE_COUNT; i++) {
uint32_t alarm_type_mask = 1U << i;
+
if (alarm_enabled & alarm_type_mask) {
alarm_dbg(INFO,
"%s: clear alarm, pending %d\n",
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index fc59281..3a4394f 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -118,6 +118,7 @@ static int binder_set_stop_on_user_error(const char *val,
struct kernel_param *kp)
{
int ret;
+
ret = param_set_int(val, kp);
if (binder_stop_on_user_error < 2)
wake_up(&binder_user_error_wait);
@@ -194,6 +195,7 @@ static struct binder_transaction_log_entry
*binder_transaction_log_add(
struct binder_transaction_log *log)
{
struct binder_transaction_log_entry *e;
+
e = &log->entry[log->next];
memset(e, 0, sizeof(*e));
log->next++;
@@ -432,6 +434,7 @@ static inline void binder_unlock(const char *tag)
static void binder_set_nice(long nice)
{
long min_nice;
+
if (can_nice(current, nice)) {
set_user_nice(current, nice);
return;
@@ -584,6 +587,7 @@ static int binder_update_page_range(struct binder_proc
*proc, int allocate,
for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {
int ret;
struct page **page_array_ptr;
+
page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];
BUG_ON(*page);
@@ -726,6 +730,7 @@ static struct binder_buffer *binder_alloc_buf(struct
binder_proc *proc,
binder_insert_allocated_buffer(proc, buffer);
if (buffer_size != size) {
struct binder_buffer *new_buffer = (void *)buffer->data + size;
+
list_add(&new_buffer->entry, &buffer->entry);
new_buffer->free = 1;
binder_insert_free_buffer(proc, new_buffer);
@@ -838,6 +843,7 @@ static void binder_free_buf(struct binder_proc *proc,
if (!list_is_last(&buffer->entry, &proc->buffers)) {
struct binder_buffer *next = list_entry(buffer->entry.next,
struct binder_buffer, entry);
+
if (next->free) {
rb_erase(&next->rb_node, &proc->free_buffers);
binder_delete_free_buffer(proc, next);
@@ -846,6 +852,7 @@ static void binder_free_buf(struct binder_proc *proc,
if (proc->buffers.next != &buffer->entry) {
struct binder_buffer *prev = list_entry(buffer->entry.prev,
struct binder_buffer, entry);
+
if (prev->free) {
binder_delete_free_buffer(proc, buffer);
rb_erase(&prev->rb_node, &proc->free_buffers);
@@ -1107,6 +1114,7 @@ static int binder_inc_ref(struct binder_ref *ref, int
strong,
struct list_head *target_list)
{
int ret;
+
if (strong) {
if (ref->strong == 0) {
ret = binder_inc_node(ref->node, 1, 1, target_list);
@@ -1138,6 +1146,7 @@ static int binder_dec_ref(struct binder_ref *ref, int
strong)
ref->strong--;
if (ref->strong == 0) {
int ret;
+
ret = binder_dec_node(ref->node, strong, 1);
if (ret)
return ret;
@@ -1177,6 +1186,7 @@ static void binder_send_failed_reply(struct
binder_transaction *t,
uint32_t error_code)
{
struct binder_thread *target_thread;
+
BUG_ON(t->flags & TF_ONE_WAY);
while (1) {
tar
RE: [PATCH 00/32] staging: comedi: continue async command cleanup
On Wednesday, April 30, 2014 2:13 AM, Ian Abbott wrote: > On 2014-04-29 20:59, H Hartley Sweeten wrote: >> Remove some unnecessary pacer divisor calculations. The divisors are >> calculated >> as part of the (*do_cmdtest) and don't need done in the (*do_cmd). >> >> Remomove the older, unused, divisor calc functions in 8253.h to avoid any >> confusion. >> >> Remove some unnecessary private data members in a couple drivers and the >> addi_common.h header. >> >> Tidy up hwdrv_apci3120 a bit. >> >> Fix a couple 8254 timer programming issues. As Ian Abbott pointed out, >> the i8254_load() function does not use the I8254_MODE* defines. Convert >> all drivers to use the i8254_set_mode()/i8254_write() sequence instead. >> >> v2: Fix some i8254_load() issued pointed out by Ian Abbott in patches >> 01, 02, 03, and 05. >> Add a couple new patchs (24 thru 32) to fix/clarify the remaining >> i8254_load() issues. >> >> H Hartley Sweeten (32): [snip] > Looks good! > > As a side node, I wonder if it's worth stripping out those `| > I8254_BINARY` bits as it's basically 'OR'ing with zero anyway. I like the I8254_BINARY, it documents the mode that the counter is used in. But, if you want to strip them out... BTW, I noticed that the i8254_set_mode() helpers have a slight "bug". if (mode > (I8254_MODE5 | I8254_BINARY)) return -1; This test will not allow the mode (I8254_MODE5 | I8254_BCD). Nothing uses it right now, and it's a bit silly to use BCD counting anyway. But... > Reviewed-by: Ian Abbott Thanks, Hartley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 6/6 v2] staging: comedi: addi_apci_1564: remove use of devpriv->s_EeParameters
On Wednesday, April 30, 2014 12:52 AM, Chase Southwood wrote: > Thanks so much, I greatly appreciate the review. I'll fix the > changelog for patch 4 and send once more (as I assume that's easier > for Greg). Also, I should know better about the cover letter as > well...I was once told not to send them for strictly cleanup patchsets > (as Greg can't do anything with them and cleanups should be obvious) > but I've gotten in the habit of not doing a cover letter for any > patchsets. I will send cover letters (and be more careful about my > other mistakes) in the future. Chase, Good job on the cleanup you have done so far. The cover letter does not get committed as part of the patch set. But when you are submitting a series it give a convenient place to add the sign off tag for a series. Also, if you would have done a cover letter for this series you would have probably spotted the subject line issues in patches 5 and 6. Keep up the good work! Hartley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 net-next 1/1] hyperv: Properly handle checksum offload
From: "K. Y. Srinivasan" Date: Wed, 30 Apr 2014 09:05:21 -0700 > Do checksum offload only if the client of the driver wants checksum to be > offloaded. > > In V1 version of this patch, I addressed comments from > Stephen Hemminger and > Eric Dumazet . > > In this version of the patch I have addressed comments from > David Miller. > > This patch fixes a bug that is exposed in gateway scenarios. > > > Signed-off-by: K. Y. Srinivasan > Reviewed-by: Haiyang Zhang It does not make any sense to submit a patch for net-next and also ask for it to be included in -stable. First of all, -stable submissions are handled by me directly for networking. Therefore you should not CC: stable on such patches, instead you ask me politly to include it in my stable submission queue. Second of all, if a patch is destined for stable, it should be submitted for 'net' not 'net-next'. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: fix coding style issues in comedi_fops.c
This is a patch to fix coding style
warnings found by the checkpatch.pl tool
Signed-off-by: Raghavendra Chandra Ganiga
---
drivers/staging/comedi/comedi_fops.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index acc8019..a62d639 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1435,13 +1435,15 @@ static int __comedi_get_user_cmd(struct comedi_device
*dev,
s = &dev->subdevices[cmd->subdev];
if (s->type == COMEDI_SUBD_UNUSED) {
- dev_dbg(dev->class_dev, "%d not valid subdevice\n",
cmd->subdev);
+ dev_dbg(dev->class_dev, "%d not valid subdevice\n",
+ cmd->subdev);
return -EIO;
}
if (!s->do_cmd || !s->do_cmdtest || !s->async) {
dev_dbg(dev->class_dev,
- "subdevice %d does not support commands\n",
cmd->subdev);
+ "subdevice %d does not support commands\n",
+ cmd->subdev);
return -EIO;
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the send path
From: "K. Y. Srinivasan" Date: Wed, 30 Apr 2014 10:14:31 -0700 > We send packets using a copy-free mechanism (this is the Guest to Host > transport > via VMBUS). While this is obviously optimal for large packets, > it may not be optimal for small packets. Hyper-V host supports > a second mechanism for sending packets that is "copy based". We implement that > mechanism in this patch. > > In this version of the patch I have addressed a comment from David Miller. > > With this patch (and all of the other offload and VRSS patches), we are now > able > to almost saturate a 10G interface between Linux VMs on Hyper-V > on different hosts - close to 9 Gbps as measured via iperf. > > Signed-off-by: K. Y. Srinivasan > Reviewed-by: Haiyang Zhang Applied. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 net 1/1] hyperv: Properly handle checksum offload
Do checksum offload only if the client of the driver wants checksum to be offloaded. In V1 version of this patch, I addressed comments from Stephen Hemminger and Eric Dumazet . In this version of the patch I have addressed comments from David Miller. This patch fixes a bug that is exposed in gateway scenarios. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang --- drivers/net/hyperv/netvsc_drv.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 939e3af..64c7816 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -467,6 +467,10 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) if (skb_is_gso(skb)) goto do_lso; + if ((skb->ip_summed == CHECKSUM_NONE) || + (skb->ip_summed == CHECKSUM_UNNECESSARY)) + goto do_send; + rndis_msg_size += NDIS_CSUM_PPI_SIZE; ppi = init_ppi_data(rndis_msg, NDIS_CSUM_PPI_SIZE, TCPIP_CHKSUM_PKTINFO); -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V1 net-next 1/1] hyperv: Enable sendbuf mechanism on the send path
On Wed, Apr 30, 2014 at 10:14:31AM -0700, K. Y. Srinivasan wrote: > + /* Setup state for managing the send buffer. */ > + net_device->map_words = DIV_ROUND_UP(net_device->send_section_cnt, > + BITS_PER_LONG); > + > + net_device->send_section_map = > + kzalloc(net_device->map_words * sizeof(ulong), GFP_KERNEL); > + if (net_device->send_section_map == NULL) > + goto cleanup; I told you about this returning success bug if kmalloc() fails but you didn't fix it. > + > goto exit; > > cleanup: > - netvsc_destroy_recv_buf(net_device); > + netvsc_destroy_buf(net_device); > > exit: > return ret; regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: fix coding style issues in comedi_fops.c
On Wed, Apr 30, 2014 at 11:04:49PM +0530, Raghavendra Ganiga wrote: > This is a patch to fix coding style > warnings found by the checkpatch.pl tool > Someone fixed this already. You should be working against linux-next for this kind of thing. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 net 1/1] hyperv: Properly handle checksum offload
From: "K. Y. Srinivasan" Date: Wed, 30 Apr 2014 11:58:25 -0700 > Do checksum offload only if the client of the driver wants checksum to be > offloaded. > > In V1 version of this patch, I addressed comments from > Stephen Hemminger and > Eric Dumazet . > > In this version of the patch I have addressed comments from > David Miller. > > This patch fixes a bug that is exposed in gateway scenarios. > > Signed-off-by: K. Y. Srinivasan > Reviewed-by: Haiyang Zhang Applied and queued up for -stable, t hanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: Fix format string mismatch in ad7280a.c
On 28/04/14 17:00, Masanari Iida wrote: Fix two format string mismatch in ad7280a.c Signed-off-by: Masanari Iida Applied to the togreg branch of iio.git Note this will initially get pushed out as testing for the autobuilders to play. Thanks, Jonathan --- drivers/staging/iio/adc/ad7280a.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/adc/ad7280a.c b/drivers/staging/iio/adc/ad7280a.c index 1ac11f6..d215edf 100644 --- a/drivers/staging/iio/adc/ad7280a.c +++ b/drivers/staging/iio/adc/ad7280a.c @@ -443,7 +443,7 @@ static ssize_t ad7280_show_balance_timer(struct device *dev, msecs = (ret >> 3) * 71500; - return sprintf(buf, "%d\n", msecs); + return sprintf(buf, "%u\n", msecs); } static ssize_t ad7280_store_balance_timer(struct device *dev, @@ -619,7 +619,7 @@ static ssize_t ad7280_read_channel_config(struct device *dev, return -EINVAL; } - return sprintf(buf, "%d\n", val); + return sprintf(buf, "%u\n", val); } static ssize_t ad7280_write_channel_config(struct device *dev, ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Fixing coding style issues in android alarm-dev.c
fixing "Missing a blank line after declarations" found by checkpatch.pl script
Signed-off-by: Karim Raslan
---
drivers/staging/android/alarm-dev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/alarm-dev.c
b/drivers/staging/android/alarm-dev.c
index 2fc7cdd..f200e8a 100644
--- a/drivers/staging/android/alarm-dev.c
+++ b/drivers/staging/android/alarm-dev.c
@@ -329,6 +329,7 @@ static int alarm_release(struct inode *inode, struct file
*file)
if (file->private_data) {
for (i = 0; i < ANDROID_ALARM_TYPE_COUNT; i++) {
uint32_t alarm_type_mask = 1U << i;
+
if (alarm_enabled & alarm_type_mask) {
alarm_dbg(INFO,
"%s: clear alarm, pending %d\n",
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
30.May.14 Update info
Hi, I would like to share personal classified information about my experience and role which I played in the pursuit of my career this will benefit us greatly,interested reply through my private email: ( sgt.rho...@aim.com ) please view website below to know more Rgds, Rhodes ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6 v2] staging: comedi: addi_apci_1564: remove use of devpriv->s_EeParameters
Hartley, Yes, you raise very good points. In any case, I have added cover letters to my submitting checklist so hopefully everything will be a lot easier for everyone next go round. Thanks, Chase On Wed, Apr 30, 2014 at 11:58 AM, Hartley Sweeten wrote: > On Wednesday, April 30, 2014 12:52 AM, Chase Southwood wrote: >> Thanks so much, I greatly appreciate the review. I'll fix the >> changelog for patch 4 and send once more (as I assume that's easier >> for Greg). Also, I should know better about the cover letter as >> well...I was once told not to send them for strictly cleanup patchsets >> (as Greg can't do anything with them and cleanups should be obvious) >> but I've gotten in the habit of not doing a cover letter for any >> patchsets. I will send cover letters (and be more careful about my >> other mistakes) in the future. > > Chase, > > Good job on the cleanup you have done so far. > > The cover letter does not get committed as part of the patch set. But > when you are submitting a series it give a convenient place to add > the sign off tag for a series. Also, if you would have done a cover letter > for this series you would have probably spotted the subject line issues > in patches 5 and 6. > > Keep up the good work! > > Hartley > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
