Re: [PATCH] Staging: rtl8192u: fix sparse warnings in r8192U_core.c
On Thu, Aug 07, 2014 at 10:10:47AM +0530, A Raghavendra Rao wrote: Signed-off-by: A Raghavendra Rao ar...@cdac.in This looks very similar to what I submitted on July 31st. At this time Greg had additional comments which led to a quite different patchset (though its review is not completed yet), you may find interesting to review this whole thread. Antoine ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:r819xU: coding style: Fixed commenting style
This is a patch to the r819xU_phyreg.h file that fixes commenting style warning Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- drivers/staging/rtl8192u/r819xU_phyreg.h | 188 --- 1 file changed, 97 insertions(+), 91 deletions(-) diff --git a/drivers/staging/rtl8192u/r819xU_phyreg.h b/drivers/staging/rtl8192u/r819xU_phyreg.h index 64285d6..f07d2f1 100644 --- a/drivers/staging/rtl8192u/r819xU_phyreg.h +++ b/drivers/staging/rtl8192u/r819xU_phyreg.h @@ -2,10 +2,10 @@ #define _R819XU_PHYREG_H -#define RF_DATA 0x1d4 // FW will write RF data in the register. +#define RF_DATA 0x1d4 /* FW will write RF data in the register.*/ -//Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF -//page 1 +/* Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF */ +/* page 1 */ #define rPMAC_Reset0x100 #define rPMAC_TxStart 0x104 #define rPMAC_TxLegacySIG 0x108 @@ -34,15 +34,16 @@ #define rPMAC_CCKCRxRC32OK 0x188 #define rPMAC_TxStatus 0x18c -//page8 -#define rFPGA0_RFMOD 0x800 //RF mode CCK TxSC +/* page8 */ +#define rFPGA0_RFMOD 0x800 /* RF mode CCK TxSC */ #define rFPGA0_TxInfo 0x804 #define rFPGA0_PSDFunction 0x808 #define rFPGA0_TxGainStage 0x80c #define rFPGA0_RFTiming1 0x810 #define rFPGA0_RFTiming2 0x814 -//#define rFPGA0_XC_RFTiming 0x818 -//#define rFPGA0_XD_RFTiming 0x81c +/* #define rFPGA0_XC_RFTiming 0x818 + * #define rFPGA0_XD_RFTiming 0x81c + */ #define rFPGA0_XA_HSSIParameter1 0x820 #define rFPGA0_XA_HSSIParameter2 0x824 #define rFPGA0_XB_HSSIParameter1 0x828 @@ -79,51 +80,51 @@ #define rFPGA0_XAB_RFInterfaceRB 0x8e0 #define rFPGA0_XCD_RFInterfaceRB 0x8e4 -//page 9 -#define rFPGA1_RFMOD 0x900 //RF mode OFDM TxSC +/* page 9 */ +#define rFPGA1_RFMOD 0x900 /* RF mode OFDM TxSC */ #define rFPGA1_TxBlock 0x904 #define rFPGA1_DebugSelect 0x908 #define rFPGA1_TxInfo 0x90c -//page a +/* page a */ #define rCCK0_System 0xa00 #define rCCK0_AFESetting 0xa04 #define rCCK0_CCA 0xa08 -#define rCCK0_RxAGC1 0xa0c //AGC default value, saturation level -#define rCCK0_RxAGC2 0xa10 //AGC DAGC +#define rCCK0_RxAGC1 0xa0c /* AGC default value, saturation level */ +#define rCCK0_RxAGC2 0xa10 /* AGC DAGC */ #define rCCK0_RxHP 0xa14 -#define rCCK0_DSPParameter10xa18 //Timing recovery Channel estimation threshold -#define rCCK0_DSPParameter20xa1c //SQ threshold +#define rCCK0_DSPParameter10xa18 /* Timing recovery Channel estimation threshold */ +#define rCCK0_DSPParameter20xa1c /* SQ threshold */ #define rCCK0_TxFilter10xa20 #define rCCK0_TxFilter20xa24 -#define rCCK0_DebugPort0xa28 //debug port and Tx filter3 -#define rCCK0_FalseAlarmReport 0xa2c //0xa2d +#define rCCK0_DebugPort0xa28 /* debug port and Tx filter3 */ +#define rCCK0_FalseAlarmReport 0xa2c /* 0xa2d */ #define rCCK0_TRSSIReport 0xa50 -#define rCCK0_RxReport 0xa54 //0xa57 -#define rCCK0_FACounterLower 0xa5c //0xa5b -#define rCCK0_FACounterUpper 0xa58 //0xa5c +#define rCCK0_RxReport 0xa54 /* 0xa57 */ +#define rCCK0_FACounterLower 0xa5c /* 0xa5b */ +#define rCCK0_FACounterUpper 0xa58 /* 0xa5c */ -//page c +/* page c */ #define rOFDM0_LSTF0xc00 #define rOFDM0_TRxPathEnable 0xc04 #define rOFDM0_TRMuxPar0xc08 #define rOFDM0_TRSWIsolation 0xc0c -#define rOFDM0_XARxAFE 0xc10 //RxIQ DC offset, Rx digital filter, DC notch filter -#define rOFDM0_XARxIQImbalance 0xc14 //RxIQ imblance matrix +#define rOFDM0_XARxAFE 0xc10 /* RxIQ DC offset, Rx digital filter, DC notch filter */ +#define rOFDM0_XARxIQImbalance 0xc14 /* RxIQ imblance matrix */ #define rOFDM0_XBRxAFE 0xc18 #define rOFDM0_XBRxIQImbalance
[PATCH v3] staging: comedi: add NI USB-6501 support
Enable support for the National Instruments USB-6501 module. The NI USB-6501 is a Full-Speed USB 2.0 (12 Mbit/s) device that provides 24 digital I/O lines channels and one 32-bit counter. This is a preliminary version: GPIO: works counter: doesn't work Signed-off-by: Luca Ellero luca.ell...@brickedbrain.com --- Changes for v2: - rename file to ni_usb6501 - migrate comments to the standard block comment format - fix checkpatch.pl --strict checks: Please don't use multiple blank lines - add verbose config description to avoid checkpatch warning: please write a paragraph that describes the config symbol fully - correct some spelling mistakes Changes for v3: - fix extra space characters - remove some useless blanks lines - rewrite ni6501_dio_insn_bits() as suggested by Dan Carpenter (replace redundant code with for loops) drivers/staging/comedi/Kconfig | 11 + drivers/staging/comedi/drivers/Makefile |1 + drivers/staging/comedi/drivers/ni_usb6501.c | 425 +++ 3 files changed, 437 insertions(+) create mode 100644 drivers/staging/comedi/drivers/ni_usb6501.c diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig index 36f2c71..7d6cebc 100644 --- a/drivers/staging/comedi/Kconfig +++ b/drivers/staging/comedi/Kconfig @@ -1209,6 +1209,17 @@ config COMEDI_DT9812 To compile this driver as a module, choose M here: the module will be called dt9812. +config COMEDI_NI_USB6501 + tristate NI USB-6501 support + ---help--- + Enable support for the National Instruments USB-6501 module. + + The NI USB-6501 is a Full-Speed USB 2.0 (12 Mbit/s) device that + provides 24 digital I/O lines channels and one 32-bit counter. + + To compile this driver as a module, choose M here: the module will be + called ni_usb6501. + config COMEDI_USBDUX tristate ITL USB-DUX-D support ---help--- diff --git a/drivers/staging/comedi/drivers/Makefile b/drivers/staging/comedi/drivers/Makefile index 8873d48..87ac791 100644 --- a/drivers/staging/comedi/drivers/Makefile +++ b/drivers/staging/comedi/drivers/Makefile @@ -125,6 +125,7 @@ obj-$(CONFIG_COMEDI_QUATECH_DAQP_CS)+= quatech_daqp_cs.o # Comedi USB drivers obj-$(CONFIG_COMEDI_DT9812)+= dt9812.o +obj-$(CONFIG_COMEDI_NI_USB6501)+= ni_usb6501.o obj-$(CONFIG_COMEDI_USBDUX)+= usbdux.o obj-$(CONFIG_COMEDI_USBDUXFAST)+= usbduxfast.o obj-$(CONFIG_COMEDI_USBDUXSIGMA) += usbduxsigma.o diff --git a/drivers/staging/comedi/drivers/ni_usb6501.c b/drivers/staging/comedi/drivers/ni_usb6501.c new file mode 100644 index 000..6a4f965 --- /dev/null +++ b/drivers/staging/comedi/drivers/ni_usb6501.c @@ -0,0 +1,425 @@ +/* + * comedi/drivers/ni_usb6501.c + * Comedi driver for National Instruments USB-6501 + * + * COMEDI - Linux Control and Measurement Device Interface + * Copyright (C) 2014 Luca Ellero luca.ell...@brickedbrain.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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. + */ + +/* + * Driver: ni_usb6501 + * Description: National Instruments USB-6501 module + * Devices: [National Instruments] USB-6501 (ni_usb6501) + * Author: Luca Ellero luca.ell...@brickedbrain.com + * Updated: 5 Aug 2014 + * Status: works + * + * This driver works, but counter device is not implemented yet. + * + * Configuration Options: + * none + */ + +/* + * NI-6501 - USB PROTOCOL DESCRIPTION + * + * Every command is composed by two USB packets: + * - request (out) + * - response (in) + * + * Every packet is at least 12 bytes long, here is the meaning of + * every field (all values are hex): + * + * byte 0 is always 00 + * byte 1 is always 01 + * byte 2 is always 00 + * byte 3 is the total packet length + * + * byte 4 is always 00 + * byte 5 is is the total packet length - 4 + * byte 6 is always 01 + * byte 7 is the command + * + * byte 8 is 02 (request) or 00 (response) + * byte 9 is 00 (response) or 10 (port request) or 20 (counter request) + * byte 10 is always 00 + * byte 11 is 00 (request) or 02 (response) + * + * + * CMD: 0xE READ_PORT + * REQ: 00 01 00 10 00 0C 01 0E 02 10 00 00 00 03 PORT 00 + * RES: 00 01 00 10 00 0C 01 00 00 00 00 02 00 03 BMAP 00 + + * CMD: 0xF WRITE_PORT + * REQ: 00 01 00 14 00 10 01 0F 02 10 00 00 00 03 PORT 00 03 BMAP 00 00 + * RES: 00 01 00 0C 00 08 01 00 00 00 00 02 + * + * CMD: 0x12
[PATCH] Staging: wlan-ng: fix sparse warning in prism2fw.c
Fix the following sparse warning :
In file included from drivers/staging/wlan-ng/prism2usb.c:5:0:
drivers/staging/wlan-ng/prism2fw.c: In function
‘read_cardpda.constprop.43’:
drivers/staging/wlan-ng/prism2fw.c:792:1: warning: the frame size of
1068 bytes is larger than 1024 bytes [-Wframe-larger-than=]
The variable to 'struct p80211msg_p2req_readpda' was previously being created
on the stack, which inturn exeeded the frame size limit, resulting in a
sparse warning. This patch alloctes the memory to the structure dynamically
and the operations are left unchanged.
Signed-off-by: A Raghavendra Rao ar...@cdac.in
---
drivers/staging/wlan-ng/prism2fw.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2fw.c
b/drivers/staging/wlan-ng/prism2fw.c
index 42c14b0..3f5f7cc 100644
--- a/drivers/staging/wlan-ng/prism2fw.c
+++ b/drivers/staging/wlan-ng/prism2fw.c
@@ -764,30 +764,35 @@ static int plugimage(struct imgchunk *fchunk, unsigned
int nfchunks,
static int read_cardpda(struct pda *pda, wlandevice_t *wlandev)
{
int result = 0;
- struct p80211msg_p2req_readpda msg;
+ struct p80211msg_p2req_readpda *msg;
+
+ msg = kzalloc(sizeof(*msg), GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
/* set up the msg */
- msg.msgcode = DIDmsg_p2req_readpda;
- msg.msglen = sizeof(msg);
- strcpy(msg.devname, wlandev-name);
- msg.pda.did = DIDmsg_p2req_readpda_pda;
- msg.pda.len = HFA384x_PDA_LEN_MAX;
- msg.pda.status = P80211ENUM_msgitem_status_no_value;
- msg.resultcode.did = DIDmsg_p2req_readpda_resultcode;
- msg.resultcode.len = sizeof(u32);
- msg.resultcode.status = P80211ENUM_msgitem_status_no_value;
-
- if (prism2mgmt_readpda(wlandev, msg) != 0) {
+ msg-msgcode = DIDmsg_p2req_readpda;
+ msg-msglen = sizeof(msg);
+ strcpy(msg-devname, wlandev-name);
+ msg-pda.did = DIDmsg_p2req_readpda_pda;
+ msg-pda.len = HFA384x_PDA_LEN_MAX;
+ msg-pda.status = P80211ENUM_msgitem_status_no_value;
+ msg-resultcode.did = DIDmsg_p2req_readpda_resultcode;
+ msg-resultcode.len = sizeof(u32);
+ msg-resultcode.status = P80211ENUM_msgitem_status_no_value;
+
+ if (prism2mgmt_readpda(wlandev, msg) != 0) {
/* prism2mgmt_readpda prints an errno if appropriate */
result = -1;
- } else if (msg.resultcode.data == P80211ENUM_resultcode_success) {
- memcpy(pda-buf, msg.pda.data, HFA384x_PDA_LEN_MAX);
+ } else if (msg-resultcode.data == P80211ENUM_resultcode_success) {
+ memcpy(pda-buf, msg-pda.data, HFA384x_PDA_LEN_MAX);
result = mkpdrlist(pda);
} else {
/* resultcode must've been something other than success */
result = -1;
}
+ kfree(msg);
return result;
}
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: iio: accel: Add blank lines between declarations and code
On 07/08/14 01:22, Murilo Opsfelder Araujo wrote:
This patch adds missing blank lines between declarations and code and
fixes lines starting by spaces, satisfying checkpatch.pl.
Signed-off-by: Murilo Opsfelder Araujo mopsfel...@gmail.com
Applied to the togreg branch of iio.git. Initially pushed out
as testing for the autobuilders to play around with it.
J
---
drivers/staging/iio/accel/adis16201_core.c | 5 +++--
drivers/staging/iio/accel/adis16203_core.c | 2 ++
drivers/staging/iio/accel/adis16204_core.c | 1 +
drivers/staging/iio/accel/adis16209_core.c | 1 +
drivers/staging/iio/accel/adis16240_core.c | 1 +
drivers/staging/iio/accel/lis3l02dq_core.c | 4
drivers/staging/iio/accel/lis3l02dq_ring.c | 1 +
drivers/staging/iio/accel/sca3000_core.c | 1 +
8 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16201_core.c
b/drivers/staging/iio/accel/adis16201_core.c
index 50ba1fa..7eae5fd 100644
--- a/drivers/staging/iio/accel/adis16201_core.c
+++ b/drivers/staging/iio/accel/adis16201_core.c
@@ -111,6 +111,7 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan-type) {
@@ -131,8 +132,8 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
}
static const struct iio_chan_spec adis16201_channels[] = {
- ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
- ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
+ ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
+ ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
ADIS_ACCEL_CHAN(X, ADIS16201_XACCL_OUT, ADIS16201_SCAN_ACC_X,
BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
ADIS_ACCEL_CHAN(Y, ADIS16201_YACCL_OUT, ADIS16201_SCAN_ACC_Y,
diff --git a/drivers/staging/iio/accel/adis16203_core.c
b/drivers/staging/iio/accel/adis16203_core.c
index f472137..fbbe93f 100644
--- a/drivers/staging/iio/accel/adis16203_core.c
+++ b/drivers/staging/iio/accel/adis16203_core.c
@@ -37,6 +37,7 @@ static int adis16203_write_raw(struct iio_dev *indio_dev,
struct adis *st = iio_priv(indio_dev);
/* currently only one writable parameter which keeps this simple */
u8 addr = adis16203_addresses[chan-scan_index];
+
return adis_write_reg_16(st, addr, val 0x3FFF);
}
@@ -50,6 +51,7 @@ static int adis16203_read_raw(struct iio_dev *indio_dev,
int bits;
u8 addr;
s16 val16;
+
switch (mask) {
case IIO_CHAN_INFO_RAW:
return adis_single_conversion(indio_dev, chan,
diff --git a/drivers/staging/iio/accel/adis16204_core.c
b/drivers/staging/iio/accel/adis16204_core.c
index 19eaebc..4c8acbc 100644
--- a/drivers/staging/iio/accel/adis16204_core.c
+++ b/drivers/staging/iio/accel/adis16204_core.c
@@ -119,6 +119,7 @@ static int adis16204_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan-type) {
diff --git a/drivers/staging/iio/accel/adis16209_core.c
b/drivers/staging/iio/accel/adis16209_core.c
index 374dc6e..b2c7aed 100644
--- a/drivers/staging/iio/accel/adis16209_core.c
+++ b/drivers/staging/iio/accel/adis16209_core.c
@@ -44,6 +44,7 @@ static int adis16209_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan-type) {
diff --git a/drivers/staging/iio/accel/adis16240_core.c
b/drivers/staging/iio/accel/adis16240_core.c
index 74ace2a..205d6d0 100644
--- a/drivers/staging/iio/accel/adis16240_core.c
+++ b/drivers/staging/iio/accel/adis16240_core.c
@@ -163,6 +163,7 @@ static int adis16240_write_raw(struct iio_dev *indio_dev,
int bits = 10;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
val16 = val ((1 bits) - 1);
diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c
b/drivers/staging/iio/accel/lis3l02dq_core.c
index 898653c..f5e145c 100644
--- a/drivers/staging/iio/accel/lis3l02dq_core.c
+++ b/drivers/staging/iio/accel/lis3l02dq_core.c
@@ -212,6 +212,7 @@ static int lis3l02dq_write_thresh(struct iio_dev
*indio_dev,
int val, int val2)
{
u16 value = val;
+
return lis3l02dq_spi_write_reg_s16(indio_dev,
LIS3L02DQ_REG_THS_L_ADDR,
value);
@@ -226,6 +227,7 @@ static int lis3l02dq_write_raw(struct iio_dev *indio_dev,
int ret = -EINVAL, reg;
u8 uval;
s8 sval;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
if (val 255 || val -256)
@@ -302,6 +304,7 @@ static ssize_t
Re: [PATCH v3 2/2] staging: iio: accel: sca3000_core.c: Adjust code to fit 80-chars limit
On 07/08/14 01:22, Murilo Opsfelder Araujo wrote: Signed-off-by: Murilo Opsfelder Araujo mopsfel...@gmail.com Applied to the togreg branch of iio.git. Thanks, Jonathan --- drivers/staging/iio/accel/sca3000_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/iio/accel/sca3000_core.c b/drivers/staging/iio/accel/sca3000_core.c index bc53fedb..e4e5639 100644 --- a/drivers/staging/iio/accel/sca3000_core.c +++ b/drivers/staging/iio/accel/sca3000_core.c @@ -506,7 +506,8 @@ static int sca3000_read_raw(struct iio_dev *indio_dev, mutex_unlock(st-lock); return ret; } - *val = ((st-rx[0] 0x3F) 3) | ((st-rx[1] 0xE0) 5); + *val = ((st-rx[0] 0x3F) 3) | +((st-rx[1] 0xE0) 5); } mutex_unlock(st-lock); return IIO_VAL_INT; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: fixing coding style problems
On 2014/08/06 06:55 PM, Niklas Svensson wrote: This patch fixes warnings of checkpatch.pl script: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around devpriv-timer +init_timer((devpriv-timer)); CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis +dev_info(dev-class_dev, +%s: %i microvolt, %li microsecond waveform attached\n, Task of Eudyptula challenge. Signed-off-by: Niklas Svensson n...@flawful.org Reviewed-by: Ian Abbott abbo...@mev.co.uk -- -=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=- -=( 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 v3] staging: comedi: add NI USB-6501 support
On 2014/08/07 08:10 AM, Luca Ellero wrote: Enable support for the National Instruments USB-6501 module. The NI USB-6501 is a Full-Speed USB 2.0 (12 Mbit/s) device that provides 24 digital I/O lines channels and one 32-bit counter. This is a preliminary version: GPIO: works counter: doesn't work Signed-off-by: Luca Ellero luca.ell...@brickedbrain.com --- Changes for v2: - rename file to ni_usb6501 - migrate comments to the standard block comment format - fix checkpatch.pl --strict checks: Please don't use multiple blank lines - add verbose config description to avoid checkpatch warning: please write a paragraph that describes the config symbol fully - correct some spelling mistakes Changes for v3: - fix extra space characters - remove some useless blanks lines - rewrite ni6501_dio_insn_bits() as suggested by Dan Carpenter (replace redundant code with for loops) drivers/staging/comedi/Kconfig | 11 + drivers/staging/comedi/drivers/Makefile |1 + drivers/staging/comedi/drivers/ni_usb6501.c | 425 +++ 3 files changed, 437 insertions(+) create mode 100644 drivers/staging/comedi/drivers/ni_usb6501.c Signed-off-by: Ian Abbott abbo...@mev.co.uk -- -=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=- -=( 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] staging: iio: adis16060: Fix coding style problem
On 06/08/14 18:06, Oussama Jabbari wrote:
This patch fixes a warning from checkpatch.pl script :
WARNING: Missing a blank line after declarations
Signed-off-by: Oussama Jabbari oussama.jabb...@gmail.com
Whilst I find it hard to care about this particular issue,
I'm accepting this mainly to avoid getting the same thing
sometime in the future!
Anyhow, a nicely formatted patch. The only change I would
have suggested would be in the title which might as be more
specific.
[PATCH] staging:iio:adis16060 Add missing blank line after declaration.
Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.
J
---
The reason of this patch is for completing one task
of the Eudyptula Challenge.
drivers/staging/iio/gyro/adis16060_core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/iio/gyro/adis16060_core.c
b/drivers/staging/iio/gyro/adis16060_core.c
index d5d395c..4c5869d 100644
--- a/drivers/staging/iio/gyro/adis16060_core.c
+++ b/drivers/staging/iio/gyro/adis16060_core.c
@@ -180,6 +180,7 @@ static int adis16060_w_probe(struct spi_device *spi)
int ret;
struct iio_dev *indio_dev = adis16060_iio_dev;
struct adis16060_state *st;
+
if (!indio_dev) {
ret = -ENODEV;
goto error_ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
On Thu, Aug 7, 2014 at 12:42 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Wed, Aug 06, 2014 at 09:22:43PM +0300, Evgeny Budilovsky wrote: Signed-off-by: Evgeny Budilovsky bud...@gmail.com Why is this needed? Is the current code a bug? Where was the reference added? Is this causing a problem without this patch applied? How far back should it be backported, if at all? I need lots more details here before I can take this patch, sorry. Sorry for the little information in the previous mail. The motivation for this patch was to clean some of the warnings that were generated on drivers/staging by the sparse utility. For this particular case the warning was staging/lustre/lustre/llite/lproc_llite.c:913:51: warning: dereference of noderef expression And this is since current-real_parent is accessed directly and not trough the rcu_dereference, which is the common way to access it throughout the kernel. This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. greg k-h -- Best Regards, Evgeny ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad9951: Use devm_iio_device_register
On 03/08/14 11:00, Himangi Saraogi wrote:
This patch introduces the use of devm_iio_device_register and does away
with the unregister in the remove function. The remove function is no
longer required and is completely removed.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
Applied to the togreg branch of iio.git
Thanks,
J
---
drivers/staging/iio/frequency/ad9951.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/staging/iio/frequency/ad9951.c
b/drivers/staging/iio/frequency/ad9951.c
index 5e8990a..d465db0 100644
--- a/drivers/staging/iio/frequency/ad9951.c
+++ b/drivers/staging/iio/frequency/ad9951.c
@@ -175,7 +175,7 @@ static int ad9951_probe(struct spi_device *spi)
idev-info = ad9951_info;
idev-modes = INDIO_DIRECT_MODE;
- ret = iio_device_register(idev);
+ ret = devm_iio_device_register(spi-dev, idev);
if (ret)
return ret;
spi-max_speed_hz = 200;
@@ -186,20 +186,12 @@ static int ad9951_probe(struct spi_device *spi)
return 0;
}
-static int ad9951_remove(struct spi_device *spi)
-{
- iio_device_unregister(spi_get_drvdata(spi));
-
- return 0;
-}
-
static struct spi_driver ad9951_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
},
.probe = ad9951_probe,
- .remove = ad9951_remove,
};
module_spi_driver(ad9951_driver);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:iio:ad9852: Use devm_iio_device_register
On 03/08/14 10:58, Himangi Saraogi wrote:
This patch introduces the use of devm_iio_device_register and does away
with the unregister in the remove function.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
Applied to the togreg branch of iio.git
Thanks,
J
---
drivers/staging/iio/frequency/ad9852.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/staging/iio/frequency/ad9852.c
b/drivers/staging/iio/frequency/ad9852.c
index 11e4367..af2f2cc 100644
--- a/drivers/staging/iio/frequency/ad9852.c
+++ b/drivers/staging/iio/frequency/ad9852.c
@@ -218,7 +218,7 @@ static int ad9852_probe(struct spi_device *spi)
idev-info = ad9852_info;
idev-modes = INDIO_DIRECT_MODE;
- ret = iio_device_register(idev);
+ ret = devm_iio_device_register(spi-dev, idev);
if (ret)
return ret;
spi-max_speed_hz = 200;
@@ -230,20 +230,12 @@ static int ad9852_probe(struct spi_device *spi)
return 0;
}
-static int ad9852_remove(struct spi_device *spi)
-{
- iio_device_unregister(spi_get_drvdata(spi));
-
- return 0;
-}
-
static struct spi_driver ad9852_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
},
.probe = ad9852_probe,
- .remove = ad9852_remove,
};
module_spi_driver(ad9852_driver);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Wed, Aug 06, 2014 at 11:18:13PM +0300, Dan Carpenter wrote:
On Wed, Aug 06, 2014 at 10:43:00PM +0530, Srikrishan Malik wrote:
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index c03d77c9c5b8..09209171b50c 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -785,12 +785,12 @@ int mdc_enqueue(struct obd_export *exp, struct
ldlm_enqueue_info *einfo,
__u64 flags, saved_flags = extra_lock_flags;
int rc;
struct ldlm_res_id res_id;
- static const ldlm_policy_data_t lookup_policy =
- { .l_inodebits = { MDS_INODELOCK_LOOKUP } };
- static const ldlm_policy_data_t update_policy =
- { .l_inodebits = { MDS_INODELOCK_UPDATE } };
- static const ldlm_policy_data_t layout_policy =
- { .l_inodebits = { MDS_INODELOCK_LAYOUT } };
+ static const ldlm_policy_data_t lookup_policy = {
+ .l_inodebits = { MDS_INODELOCK_LOOKUP } };
+ static const ldlm_policy_data_t update_policy = {
+ .l_inodebits = { MDS_INODELOCK_UPDATE } };
+ static const ldlm_policy_data_t layout_policy = {
+ .l_inodebits = { MDS_INODELOCK_LAYOUT } };
static const ldlm_policy_data_t getxattr_policy = {
.l_inodebits = { MDS_INODELOCK_XATTR } };
ldlm_policy_data_t const *policy = lookup_policy;
That looks silly before and after. Everything is indented in a funny
way.
Is this better:
static const ldlm_policy_data_t lookup_policy = {
.l_inodebits = { MDS_INODELOCK_LOOKUP }
};
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:r819xU: coding style: Fixed commenting style
On Thu, Aug 07, 2014 at 12:15:57PM +0530, Sanjeev Sharma wrote: This is a patch to the r819xU_phyreg.h file that fixes commenting style warning Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- drivers/staging/rtl8192u/r819xU_phyreg.h | 188 --- 1 file changed, 97 insertions(+), 91 deletions(-) diff --git a/drivers/staging/rtl8192u/r819xU_phyreg.h b/drivers/staging/rtl8192u/r819xU_phyreg.h index 64285d6..f07d2f1 100644 --- a/drivers/staging/rtl8192u/r819xU_phyreg.h +++ b/drivers/staging/rtl8192u/r819xU_phyreg.h @@ -2,10 +2,10 @@ #define _R819XU_PHYREG_H -#define RF_DATA0x1d4 // FW will write RF data in the register. +#define RF_DATA0x1d4 /* FW will write RF data in the register.*/ -//Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF -//page 1 +/* Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF */ Does that line look correct? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
URGENT BUSINESS REQUEST
Dear Friend I am Mr. Ahmed Zama,I work for UBA bank Ouagadougou Burkina Faso. I have a business proposal which concerns the transfer of 4.8 M Euros into a foreign account. Everything about this transaction shall be legally done without any problem. If you are interested to help me, I will give you more details as soon as I receive your positive response. You will be entitled to 30%, 60% will be for me, While 10% will be mapped out for expenses that may be incurred on the process of transferring this fund. If you are willing to work with me, send me immediately the information listed bellow. Name .. Nationality .. Age.. Occupation .. Mobile Telephone Line.. Address Thanks Ahmed Zama --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Thu, 2014-08-07 at 19:01 +0300, Dan Carpenter wrote:
On Thu, Aug 07, 2014 at 09:01:36PM +0530, Srikrishan Malik wrote:
On Wed, Aug 06, 2014 at 11:18:13PM +0300, Dan Carpenter wrote:
That looks silly before and after. Everything is indented in a funny
way.
Is this better:
static const ldlm_policy_data_t lookup_policy = {
.l_inodebits = { MDS_INODELOCK_LOOKUP }
};
That is indented too far.
Honestly, I think it looks best on one line but in terms of real life we
can't ignore checkpatch warnings because eventually someone else will
try to fix it to not be on one line.
This function has the silly thing where the types are in one column and
the variables are in another. But then over time inevitably we add more
variables and nothing is lined up any more.
I think it's best to move this const variable block to the very front of
the list.
req doesn't need to be initialized.
rc is normally the last variable declared.
lvb_type should be initialized to LVB_T_NONE instead of zero.
__u64 should be u64.
All those changes could be done as one patch titled, cleanup variable
declarations in mdc_enqueue(). There may be other cleanups you could
do as well. Look hard.
I think it looks odd to mix named and unnamed
initializers for the typedef and its members.
ldlm_policy_data_t is a union and it could be
explicit instead of a typedef.
Perhaps:
static const union ldlm_policy_data lookup_policy = {
.l_inodebits = {
.bits = MDS_INODELOCK_LOOKUP,
},
};
or maybe use another DECLARE_foo macro indirection.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 1/2] Staging: rtl8188eu: Lines over 80 characters fixed.
This is a patch to the hal/rtl8188eu_recv.c file that fixes up a line
over 80 characters warning found by the checkpatch.pl tool.
Signed-off-by: Adrian Remonda adrianremo...@gmail.com
---
drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c | 28 +-
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index f25c87c..8be4819 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -41,15 +41,19 @@ int rtl8188eu_init_recv_priv(struct adapter *padapter)
/* init recv_buf */
_rtw_init_queue(precvpriv-free_recv_buf_queue);
- precvpriv-pallocated_recv_buf = kzalloc(NR_RECVBUFF * sizeof(struct
recv_buf) + 4, GFP_KERNEL);
+ precvpriv-pallocated_recv_buf =
+ kzalloc(NR_RECVBUFF * sizeof(struct recv_buf) + 4, GFP_KERNEL);
if (precvpriv-pallocated_recv_buf == NULL) {
res = _FAIL;
- RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, (alloc recv_buf
fail!\n));
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
+ (alloc recv_buf fail!\n));
goto exit;
}
- memset(precvpriv-pallocated_recv_buf, 0, NR_RECVBUFF * sizeof(struct
recv_buf) + 4);
+ memset(precvpriv-pallocated_recv_buf, 0,
+ NR_RECVBUFF * sizeof(struct recv_buf) + 4);
- precvpriv-precv_buf = (u8
*)N_BYTE_ALIGMENT((size_t)(precvpriv-pallocated_recv_buf), 4);
+ precvpriv-precv_buf = (u8 *)N_BYTE_ALIGMENT((size_t)
+ (precvpriv-pallocated_recv_buf), 4);
precvbuf = (struct recv_buf *)precvpriv-precv_buf;
@@ -66,20 +70,23 @@ int rtl8188eu_init_recv_priv(struct adapter *padapter)
{
int i;
size_t tmpaddr = 0;
- size_t alignment = 0;
+ size_t alignm = 0;
struct sk_buff *pskb = NULL;
skb_queue_head_init(precvpriv-free_recv_skb_queue);
for (i = 0; i NR_PREALLOC_RECV_SKB; i++) {
- pskb = __netdev_alloc_skb(padapter-pnetdev,
MAX_RECVBUF_SZ + RECVBUFF_ALIGN_SZ, GFP_KERNEL);
+ pskb = __netdev_alloc_skb(padapter-pnetdev,
+ MAX_RECVBUF_SZ + RECVBUFF_ALIGN_SZ,
+ GFP_KERNEL);
if (pskb) {
pskb-dev = padapter-pnetdev;
tmpaddr = (size_t)pskb-data;
- alignment = tmpaddr (RECVBUFF_ALIGN_SZ-1);
- skb_reserve(pskb, (RECVBUFF_ALIGN_SZ -
alignment));
+ alignm = tmpaddr (RECVBUFF_ALIGN_SZ-1);
+ skb_reserve(pskb, (RECVBUFF_ALIGN_SZ - alignm));
- skb_queue_tail(precvpriv-free_recv_skb_queue,
pskb);
+ skb_queue_tail(precvpriv-free_recv_skb_queue,
+ pskb);
}
pskb = NULL;
}
@@ -109,7 +116,8 @@ void rtl8188eu_free_recv_priv(struct adapter *padapter)
if (skb_queue_len(precvpriv-free_recv_skb_queue))
- DBG_88E(KERN_WARNING free_recv_skb_queue not empty, %d\n,
skb_queue_len(precvpriv-free_recv_skb_queue));
+ DBG_88E(KERN_WARNING free_recv_skb_queue not empty, %d\n,
+ skb_queue_len(precvpriv-free_recv_skb_queue));
skb_queue_purge(precvpriv-free_recv_skb_queue);
}
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8188eu: Lines over 80 characters fixed.
On Mon, Aug 04, 2014 at 03:52:17PM -0700, Joe Perches wrote:
On Tue, 2014-08-05 at 00:45 +0200, Adrian Remonda wrote:
This is a patch to the hal/rtl8188eu_recv.c file that fixes up a line
over 80 characters warning found by the checkpatch.pl tool.
[]
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index f25c87c..8be4819 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -41,15 +41,19 @@ int rtl8188eu_init_recv_priv(struct adapter
*padapter)
/* init recv_buf */
_rtw_init_queue(precvpriv-free_recv_buf_queue);
- precvpriv-pallocated_recv_buf = kzalloc(NR_RECVBUFF * sizeof(struct
recv_buf) + 4, GFP_KERNEL);
+ precvpriv-pallocated_recv_buf =
+ kzalloc(NR_RECVBUFF * sizeof(struct recv_buf) + 4, GFP_KERNEL);
if (precvpriv-pallocated_recv_buf == NULL) {
res = _FAIL;
- RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, (alloc recv_buf
fail!\n));
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
+ (alloc recv_buf fail!\n));
goto exit;
}
- memset(precvpriv-pallocated_recv_buf, 0, NR_RECVBUFF * sizeof(struct
recv_buf) + 4);
+ memset(precvpriv-pallocated_recv_buf, 0,
+ NR_RECVBUFF * sizeof(struct recv_buf) + 4);
- precvpriv-precv_buf = (u8
*)N_BYTE_ALIGMENT((size_t)(precvpriv-pallocated_recv_buf), 4);
+ precvpriv-precv_buf = (u8 *)N_BYTE_ALIGMENT((size_t)
+ (precvpriv-pallocated_recv_buf), 4);
Several bits of this are not nice.
the +4 seems senseless.
zalloc followed by a memset(,0,) is senseless.
N_BYTE_ALIGNMENT seems senseless as alloc is
suitable for any alignmet.
btw: The merge window is open, please be patient
with any staging patch during the merge window.
I have resent the changes now. Is this ok? Or should I wait until the merge
window is close?
Also N_BYTE_ALIGNMENT is being used by several files in the 8188, should
I remove this macro?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6655: wpactl.c: Fix sparse warnings
Add missing __user macro casting in the function wpa_set_keys.
This is okay since the function handles the possibility of
param-u.wpa_key.key and param-u.wpa_key.seq pointing to
kernelspace using a flag, fcpfkernel.
Signed-off-by: Martin Berglund mar...@rogsta.net
---
This was submitted as part of Eudyptula challenge task 16
drivers/staging/vt6655/wpactl.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index 5f454ca..d75dd79 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -224,7 +224,9 @@ int wpa_set_keys(PSDevice pDevice, void *ctx,
} else {
spin_unlock_irq(pDevice-lock);
if (param-u.wpa_key.key
- copy_from_user(abyKey[0], param-u.wpa_key.key,
param-u.wpa_key.key_len)) {
+ copy_from_user(abyKey[0],
+ (void __user *)param-u.wpa_key.key,
+ param-u.wpa_key.key_len)) {
spin_lock_irq(pDevice-lock);
return -EINVAL;
}
@@ -262,7 +264,9 @@ int wpa_set_keys(PSDevice pDevice, void *ctx,
} else {
spin_unlock_irq(pDevice-lock);
if (param-u.wpa_key.seq
- copy_from_user(abySeq[0], param-u.wpa_key.seq,
param-u.wpa_key.seq_len)) {
+ copy_from_user(abySeq[0],
+ (void __user *)param-u.wpa_key.seq,
+ param-u.wpa_key.seq_len)) {
spin_lock_irq(pDevice-lock);
return -EINVAL;
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Mon, Jul 21, 2014 at 11:32 PM, David Miller da...@davemloft.net wrote: From: Olaf Hering o...@aepfle.de Date: Mon, 21 Jul 2014 11:18:51 +0200 On Mon, Jul 21, Richard Weinberger wrote: My concern is that 10 seconds is maybe not a the right choice. (As we cannot know all implementations) Until someone reports an issue with it, 10 is fine. Just like 20 or 666. Wrong, this is policy and belongs in userspace. The /etc/init.d/network restart nonsense now hit Linus' tree. Yue, what is your proposal to fix that? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: wpactl.c: Fix sparse warnings
On Thu, Aug 07, 2014 at 11:08:34PM +0100, Martin Berglund wrote:
Add missing __user macro casting in the function wpa_set_keys.
This is okay since the function handles the possibility of
param-u.wpa_key.key and param-u.wpa_key.seq pointing to
kernelspace using a flag, fcpfkernel.
Signed-off-by: Martin Berglund mar...@rogsta.net
---
This was submitted as part of Eudyptula challenge task 16
drivers/staging/vt6655/wpactl.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index 5f454ca..d75dd79 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -224,7 +224,9 @@ int wpa_set_keys(PSDevice pDevice, void *ctx,
} else {
spin_unlock_irq(pDevice-lock);
if (param-u.wpa_key.key
- copy_from_user(abyKey[0], param-u.wpa_key.key,
param-u.wpa_key.key_len)) {
+ copy_from_user(abyKey[0],
+(void __user *)param-u.wpa_key.key,
Would it be better to mark this pointer as __user in the structure
itself? Or is it also used as a kernel structure in other places?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
-Original Message- From: Richard Weinberger [mailto:richard.weinber...@gmail.com] Sent: Friday, August 8, 2014 6:37 AM To: David Miller; Yue Zhang (OSTC DEV) Cc: o...@aepfle.de; net...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; LKML; Greg KH; jasow...@redhat.com; Haiyang Zhang; KY Srinivasan; Thomas Shao; Dexuan Cui Subject: Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation On Mon, Jul 21, 2014 at 11:32 PM, David Miller da...@davemloft.net wrote: From: Olaf Hering o...@aepfle.de Date: Mon, 21 Jul 2014 11:18:51 +0200 On Mon, Jul 21, Richard Weinberger wrote: My concern is that 10 seconds is maybe not a the right choice. (As we cannot know all implementations) Until someone reports an issue with it, 10 is fine. Just like 20 or 666. Wrong, this is policy and belongs in userspace. The /etc/init.d/network restart nonsense now hit Linus' tree. Yue, what is your proposal to fix that? //richard Hi Richard and all, Sorry for the late response -- actually we have been trying to figure out a solution that's acceptable to all. IMO the most feasible and need-the-least-change solution may be: the hyperv network VSC driver passes the event RNDIS_STATUS_NETWORK_CHANGE to the udev daemon? In this way, every distro only needs to add a udev rule, which should be simple. Any comment? -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Fri, Aug 08, 2014 at 03:13:58AM +, Dexuan Cui wrote: -Original Message- From: Richard Weinberger [mailto:richard.weinber...@gmail.com] Sent: Friday, August 8, 2014 6:37 AM To: David Miller; Yue Zhang (OSTC DEV) Cc: o...@aepfle.de; net...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; LKML; Greg KH; jasow...@redhat.com; Haiyang Zhang; KY Srinivasan; Thomas Shao; Dexuan Cui Subject: Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation On Mon, Jul 21, 2014 at 11:32 PM, David Miller da...@davemloft.net wrote: From: Olaf Hering o...@aepfle.de Date: Mon, 21 Jul 2014 11:18:51 +0200 On Mon, Jul 21, Richard Weinberger wrote: My concern is that 10 seconds is maybe not a the right choice. (As we cannot know all implementations) Until someone reports an issue with it, 10 is fine. Just like 20 or 666. Wrong, this is policy and belongs in userspace. The /etc/init.d/network restart nonsense now hit Linus' tree. Yue, what is your proposal to fix that? //richard Hi Richard and all, Sorry for the late response -- actually we have been trying to figure out a solution that's acceptable to all. IMO the most feasible and need-the-least-change solution may be: the hyperv network VSC driver passes the event RNDIS_STATUS_NETWORK_CHANGE to the udev daemon? In this way, every distro only needs to add a udev rule, which should be simple. No, don't do that, again, act like any other network device, drop the link and bring it up when it comes back. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
On Thu, Aug 07, 2014 at 02:13:50PM +0300, Evgeny Budilovsky wrote: On Thu, Aug 7, 2014 at 12:42 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Wed, Aug 06, 2014 at 09:22:43PM +0300, Evgeny Budilovsky wrote: Signed-off-by: Evgeny Budilovsky bud...@gmail.com Why is this needed? Is the current code a bug? Where was the reference added? Is this causing a problem without this patch applied? How far back should it be backported, if at all? I need lots more details here before I can take this patch, sorry. Sorry for the little information in the previous mail. The motivation for this patch was to clean some of the warnings that were generated on drivers/staging by the sparse utility. For this particular case the warning was staging/lustre/lustre/llite/lproc_llite.c:913:51: warning: dereference of noderef expression And this is since current-real_parent is accessed directly and not trough the rcu_dereference, which is the common way to access it throughout the kernel. This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. You are right, and if this is just for some random statistics file, can we just delete the whole function? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
Hello! On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. You are right, and if this is just for some random statistics file, can we just delete the whole function? I hope not! This is used all around the client to tally up various operations executed counts. The statistic is then used by various userspace monitoring tools. Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging:r819xU: coding style: Fixed commenting style
Opps, I forget. Let me correct and send V2 patch. Regards Sanjeev Sharma -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, August 07, 2014 9:33 PM To: Sharma, Sanjeev Cc: de...@driverdev.osuosl.org; oor...@gmail.com; linux-ker...@vger.kernel.org Subject: Re: [PATCH] staging:r819xU: coding style: Fixed commenting style On Thu, Aug 07, 2014 at 12:15:57PM +0530, Sanjeev Sharma wrote: This is a patch to the r819xU_phyreg.h file that fixes commenting style warning Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- drivers/staging/rtl8192u/r819xU_phyreg.h | 188 --- 1 file changed, 97 insertions(+), 91 deletions(-) diff --git a/drivers/staging/rtl8192u/r819xU_phyreg.h b/drivers/staging/rtl8192u/r819xU_phyreg.h index 64285d6..f07d2f1 100644 --- a/drivers/staging/rtl8192u/r819xU_phyreg.h +++ b/drivers/staging/rtl8192u/r819xU_phyreg.h @@ -2,10 +2,10 @@ #define _R819XU_PHYREG_H -#define RF_DATA0x1d4 // FW will write RF data in the register. +#define RF_DATA0x1d4 /* FW will write RF data in the register.*/ -//Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF -//page 1 +/* Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF */ Does that line look correct? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
On Fri, Aug 08, 2014 at 12:03:20AM -0400, Oleg Drokin wrote: Hello! On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. You are right, and if this is just for some random statistics file, can we just delete the whole function? I hope not! This is used all around the client to tally up various operations executed counts. Why would you do that? Why would they care? The statistic is then used by various userspace monitoring tools. Why not use the in-kernel monitoring tools instead of creating your own? What does userspace do with that information? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
On Aug 8, 2014, at 12:42 AM, Greg Kroah-Hartman wrote: On Fri, Aug 08, 2014 at 12:03:20AM -0400, Oleg Drokin wrote: Hello! On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. You are right, and if this is just for some random statistics file, can we just delete the whole function? I hope not! This is used all around the client to tally up various operations executed counts. Why would you do that? Why would they care? We would do that to provide information on the client operations performed. They would care because they are interested in what particular clients might be doing. The statistic is then used by various userspace monitoring tools. Why not use the in-kernel monitoring tools instead of creating your own? What does userspace do with that information? We don't really control the userspace tools. People write tools to suit their needs to monitor loads, see odd things the end users are doing or possibly for some debugging even. Correlating these numbers with what server sees also proves useful at times (write combining for example). Here's a sample of output of a recently mounted client that I poked on a bit (the lines starting with # are my comments): # cat /proc/fs/lustre/llite/lustre-88008dde27f0/stats snapshot_time 1407473168.466102 secs.usecs read_bytes1 samples [bytes] 0 0 0 write_bytes 4 samples [bytes] 2 7 19 osc_write 4 samples [bytes] 2 7 19 # The bytes counts show you minimum, maximum of writes seen and total number of bytes read-written. # Lustre (and many other network filesystems) is very sensitive to small IO, esp. reads so it's good # to know if you have a lot of it. open 6 samples [regs] # The regs type just shows you how many of given type operations were performed since last statistic reset. # Frequently that allows people to guess where does high load come from on a particular client when # it's otherwise not obvious because not a lot of cpu is used. # Some operations are heavier than others too. close 6 samples [regs] readdir 4 samples [regs] setattr 1 samples [regs] truncate 4 samples [regs] getattr 7 samples [regs] create1 samples [regs] alloc_inode 1 samples [regs] getxattr 8 samples [regs] inode_permission 28 samples [regs] As more operations types are seen the list grows. Then there are also specific stats for readahead (data and metadata) so that interested people can make informed decisions on the tuning there should they be unsatisfied with default settings. I am not sure there's a similar mechanism in the kernel already that would allow us to get this sort of data easily all in one place? Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current-real_parent field
On Fri, Aug 08, 2014 at 01:06:15AM -0400, Oleg Drokin wrote: On Aug 8, 2014, at 12:42 AM, Greg Kroah-Hartman wrote: On Fri, Aug 08, 2014 at 12:03:20AM -0400, Oleg Drokin wrote: Hello! On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: This is not a critical bug and in the worst case the code here may cause miss of statistics counter increase. This is why I think it is not worth to backport the patch at all. You are right, and if this is just for some random statistics file, can we just delete the whole function? I hope not! This is used all around the client to tally up various operations executed counts. Why would you do that? Why would they care? We would do that to provide information on the client operations performed. They would care because they are interested in what particular clients might be doing. The statistic is then used by various userspace monitoring tools. Why not use the in-kernel monitoring tools instead of creating your own? What does userspace do with that information? We don't really control the userspace tools. People write tools to suit their needs to monitor loads, see odd things the end users are doing or possibly for some debugging even. Correlating these numbers with what server sees also proves useful at times (write combining for example). Here's a sample of output of a recently mounted client that I poked on a bit (the lines starting with # are my comments): # cat /proc/fs/lustre/llite/lustre-88008dde27f0/stats snapshot_time 1407473168.466102 secs.usecs read_bytes1 samples [bytes] 0 0 0 write_bytes 4 samples [bytes] 2 7 19 osc_write 4 samples [bytes] 2 7 19 # The bytes counts show you minimum, maximum of writes seen and total number of bytes read-written. # Lustre (and many other network filesystems) is very sensitive to small IO, esp. reads so it's good # to know if you have a lot of it. open 6 samples [regs] # The regs type just shows you how many of given type operations were performed since last statistic reset. # Frequently that allows people to guess where does high load come from on a particular client when # it's otherwise not obvious because not a lot of cpu is used. # Some operations are heavier than others too. close 6 samples [regs] readdir 4 samples [regs] setattr 1 samples [regs] truncate 4 samples [regs] getattr 7 samples [regs] create1 samples [regs] alloc_inode 1 samples [regs] getxattr 8 samples [regs] inode_permission 28 samples [regs] As more operations types are seen the list grows. Then there are also specific stats for readahead (data and metadata) so that interested people can make informed decisions on the tuning there should they be unsatisfied with default settings. I am not sure there's a similar mechanism in the kernel already that would allow us to get this sort of data easily all in one place? perf should show you this, if not, please add the functionality there. A filesystem is not the place to have performance monitoring code, this needs to be removed before it can be moved out of staging. Please work with the trace/perf developers on this if there is something lacking there. thanks, greg k-h dG Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
