[PATCH] Staging: wlan-ng: hfa384x_usb: Fixed cast to restricted __le16 sparse warning
warning: cast to restricted __le16 Signed-off-by: Jaya Durga --- drivers/staging/wlan-ng/hfa384x_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c index a812e55..0e95e45 100644 --- a/drivers/staging/wlan-ng/hfa384x_usb.c +++ b/drivers/staging/wlan-ng/hfa384x_usb.c @@ -3380,7 +3380,7 @@ static void hfa384x_usbin_rx(struct wlandevice *wlandev, struct sk_buff *skb) u16 fc; /* Byte order convert once up front. */ - usbin->rxfrm.desc.status = le16_to_cpu(usbin->rxfrm.desc.status); + le16_to_cpus(&usbin->rxfrm.desc.status); usbin->rxfrm.desc.time = le32_to_cpu(usbin->rxfrm.desc.time); /* Now handle frame based on port# */ -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: wlan-ng: hfa384x_usb: Fixed cast to restricted __le16 sparse warning
On Fri, Jun 16, 2017 at 02:57:08PM +0530, Jaya Durga wrote: > warning: cast to restricted __le16 What does this mean? It doesn't tell us why you are doing what you are doing here. Please be much more specific and descriptive. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: wlan-ng: hfa384x_usb: Fixed sparse warning cast to restricted __le16
when building with make C=1 CF=-D__CHECK_ENDIAN__ drivers/staging/wlan-ng/hfa384x_usb.c:3383:36: warning: cast to restricted __le16 fixed by using the le16_to_cpus function. Signed-off-by: Jaya Durga --- drivers/staging/wlan-ng/hfa384x_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c index a812e55..0e95e45 100644 --- a/drivers/staging/wlan-ng/hfa384x_usb.c +++ b/drivers/staging/wlan-ng/hfa384x_usb.c @@ -3380,7 +3380,7 @@ static void hfa384x_usbin_rx(struct wlandevice *wlandev, struct sk_buff *skb) u16 fc; /* Byte order convert once up front. */ - usbin->rxfrm.desc.status = le16_to_cpu(usbin->rxfrm.desc.status); + le16_to_cpus(&usbin->rxfrm.desc.status); usbin->rxfrm.desc.time = le32_to_cpu(usbin->rxfrm.desc.time); /* Now handle frame based on port# */ -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fusb302: don't bitshift __le16 type
The header field in struct pd_message is declared as an __le16 type. The data in the message is supposed to be little endian. This means we don't have to go and shift the individual bytes into position when we're filling the buffer, we can just copy the contents right away. As an added benefit we don't get fishy results on big endian systems anymore. Signed-off-by: Frans Klaver --- drivers/staging/typec/fusb302/fusb302.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c index 4a356e509fe4..03a3809d18f0 100644 --- a/drivers/staging/typec/fusb302/fusb302.c +++ b/drivers/staging/typec/fusb302/fusb302.c @@ -1039,8 +1039,8 @@ static int fusb302_pd_send_message(struct fusb302_chip *chip, } /* packsym tells the FUSB302 chip that the next X bytes are payload */ buf[pos++] = FUSB302_TKN_PACKSYM | (len & 0x1F); - buf[pos++] = msg->header & 0xFF; - buf[pos++] = (msg->header >> 8) & 0xFF; + memcpy(&buf[pos], &msg->header, sizeof(msg->header)); + pos += sizeof(msg->header); len -= 2; memcpy(&buf[pos], msg->payload, len); -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fusb302: don't bitshift __le16 type
On Fri, Jun 16, 2017 at 07:45:56PM +0200, Frans Klaver wrote: > The header field in struct pd_message is declared as an __le16 type. The > data in the message is supposed to be little endian. This means we don't > have to go and shift the individual bytes into position when we're > filling the buffer, we can just copy the contents right away. As an > added benefit we don't get fishy results on big endian systems anymore. > > Signed-off-by: Frans Klaver Reviewed-by: Guenter Roeck > --- > drivers/staging/typec/fusb302/fusb302.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/typec/fusb302/fusb302.c > b/drivers/staging/typec/fusb302/fusb302.c > index 4a356e509fe4..03a3809d18f0 100644 > --- a/drivers/staging/typec/fusb302/fusb302.c > +++ b/drivers/staging/typec/fusb302/fusb302.c > @@ -1039,8 +1039,8 @@ static int fusb302_pd_send_message(struct fusb302_chip > *chip, > } > /* packsym tells the FUSB302 chip that the next X bytes are payload */ > buf[pos++] = FUSB302_TKN_PACKSYM | (len & 0x1F); > - buf[pos++] = msg->header & 0xFF; > - buf[pos++] = (msg->header >> 8) & 0xFF; > + memcpy(&buf[pos], &msg->header, sizeof(msg->header)); > + pos += sizeof(msg->header); > > len -= 2; > memcpy(&buf[pos], msg->payload, len); > -- > 2.13.0 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: comedi: use centralized error clean-up in comedi_init()
Centralize the "clean-up on error" handling in `comedi_init()` using
`goto` statements. Also change some of the explicit `-EIO` return
values to the error return values from the failing functions as there is
no good reason to use `-EIO` explicitly.
Signed-off-by: Ian Abbott
---
drivers/staging/comedi/comedi_fops.c | 43 ++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index 4ed485a99c68..ca11be21f64b 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2881,29 +2881,25 @@ static int __init comedi_init(void)
retval = register_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
COMEDI_NUM_MINORS, "comedi");
if (retval)
- return -EIO;
+ return retval;
+
cdev_init(&comedi_cdev, &comedi_fops);
comedi_cdev.owner = THIS_MODULE;
retval = kobject_set_name(&comedi_cdev.kobj, "comedi");
- if (retval) {
- unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
-COMEDI_NUM_MINORS);
- return retval;
- }
+ if (retval)
+ goto out_unregister_chrdev_region;
+
+ retval = cdev_add(&comedi_cdev, MKDEV(COMEDI_MAJOR, 0),
+ COMEDI_NUM_MINORS);
+ if (retval)
+ goto out_unregister_chrdev_region;
- if (cdev_add(&comedi_cdev, MKDEV(COMEDI_MAJOR, 0), COMEDI_NUM_MINORS)) {
- unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
-COMEDI_NUM_MINORS);
- return -EIO;
- }
comedi_class = class_create(THIS_MODULE, "comedi");
if (IS_ERR(comedi_class)) {
+ retval = PTR_ERR(comedi_class);
pr_err("failed to create class\n");
- cdev_del(&comedi_cdev);
- unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
-COMEDI_NUM_MINORS);
- return PTR_ERR(comedi_class);
+ goto out_cdev_del;
}
comedi_class->dev_groups = comedi_dev_groups;
@@ -2914,12 +2910,8 @@ static int __init comedi_init(void)
dev = comedi_alloc_board_minor(NULL);
if (IS_ERR(dev)) {
- comedi_cleanup_board_minors();
- class_destroy(comedi_class);
- cdev_del(&comedi_cdev);
- unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
-COMEDI_NUM_MINORS);
- return PTR_ERR(dev);
+ retval = PTR_ERR(dev);
+ goto out_cleanup_board_minors;
}
/* comedi_alloc_board_minor() locked the mutex */
mutex_unlock(&dev->mutex);
@@ -2929,6 +2921,15 @@ static int __init comedi_init(void)
comedi_proc_init();
return 0;
+
+out_cleanup_board_minors:
+ comedi_cleanup_board_minors();
+ class_destroy(comedi_class);
+out_cdev_del:
+ cdev_del(&comedi_cdev);
+out_unregister_chrdev_region:
+ unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0), COMEDI_NUM_MINORS);
+ return retval;
}
module_init(comedi_init);
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] staging: comedi: comedi_init() fix clean-up
Patch 1 is fixes a "clean-up on error" bug when initializing the comedi module. Patch 2 uses the power of "goto" to simplify the clean-up code. 1) staging: comedi: fix clean-up of comedi_class in comedi_init() 2) staging: comedi: use centralized error clean-up in comedi_init() drivers/staging/comedi/comedi_fops.c | 42 +++- 1 file changed, 22 insertions(+), 20 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: comedi: fix clean-up of comedi_class in comedi_init()
There is a clean-up bug in the core comedi module initialization
functions, `comedi_init()`. If the `comedi_num_legacy_minors` module
parameter is non-zero (and valid), it creates that many "legacy" devices
and registers them in SysFS. A failure causes the function to clean up
and return an error. Unfortunately, it fails to destroy the "comedi"
class that was created earlier. Fix it by adding a call to
`class_destroy(comedi_class)` at the appropriate place in the clean-up
sequence.
Signed-off-by: Ian Abbott
Cc: # 3.9+
---
A slightly different patch is needed for kernels <3.9.
---
drivers/staging/comedi/comedi_fops.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index f191c2a75732..4ed485a99c68 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2915,6 +2915,7 @@ static int __init comedi_init(void)
dev = comedi_alloc_board_minor(NULL);
if (IS_ERR(dev)) {
comedi_cleanup_board_minors();
+ class_destroy(comedi_class);
cdev_del(&comedi_cdev);
unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
COMEDI_NUM_MINORS);
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: Remove assignments of (void*) functions
Remove assignments of (void*) functions Signed-off-by: Naeil ZOUEIDI --- drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c index 34cc56f0b471..aab5fa6c19a9 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c @@ -146,7 +146,7 @@ sh_css_load_blob_info(const char *fw, const struct ia_css_fw_info *bi, struct ia char *namebuffer; int namelength = (int)strlen(name); - namebuffer = (char *) kmalloc(namelength + 1, GFP_KERNEL); + namebuffer = kmalloc(namelength + 1, GFP_KERNEL); if (namebuffer == NULL) return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY; @@ -162,7 +162,7 @@ sh_css_load_blob_info(const char *fw, const struct ia_css_fw_info *bi, struct ia size_t configstruct_size = sizeof(struct ia_css_config_memory_offsets); size_t statestruct_size = sizeof(struct ia_css_state_memory_offsets); - char *parambuf = (char *)kmalloc(paramstruct_size + configstruct_size + statestruct_size, + char *parambuf = kmalloc(paramstruct_size + configstruct_size + statestruct_size, GFP_KERNEL); if (parambuf == NULL) return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY; -- 2.11.1 -- Naeil ZOUEIDI ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> The header field in struct pd_message is declared as an __le16 type. The
> data in the message is supposed to be little endian. This means we don't
> have to go and shift the individual bytes into position when we're
> filling the buffer, we can just copy the contents right away. As an
> added benefit we don't get fishy results on big endian systems anymore.
Thanks for pointing this out.
There are several instances of this class of error.
Here's a cocci script to find them.
This is best used with cocci's --all-includes option like:
$ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
[ many defects...]
$ cat lebe_bitshifts.cocci
@@
typedef __le16, __le32, __le64, __be16, __be32, __be64;
{ __le16, __le32, __le64, __be16, __be32, __be64 } a;
expression b;
@@
* a << b
@@
{ __le16, __le32, __le64, __be16, __be32, __be64 } a;
expression b;
@@
* a <<= b
@@
{ __le16, __le32, __le64, __be16, __be32, __be64 } a;
expression b;
@@
* a >> b
@@
{ __le16, __le32, __le64, __be16, __be32, __be64 } a;
expression b;
@@
* a >>= b
$
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: ccree: - style fix, spaces and tabs
Changed code indent to be tabs across whole driver
Found using checkpatch
Signed-off-by: Derek Robson
V1 had vague subject.
---
drivers/staging/ccree/ssi_cipher.c | 45 +-
drivers/staging/ccree/ssi_driver.c | 6 ++---
drivers/staging/ccree/ssi_driver.h | 6 ++---
drivers/staging/ccree/ssi_fips.h | 8 +++---
drivers/staging/ccree/ssi_fips_ext.c | 4 +--
drivers/staging/ccree/ssi_fips_ll.c| 40 +++---
drivers/staging/ccree/ssi_fips_local.c | 28 ++---
drivers/staging/ccree/ssi_fips_local.h | 12 -
8 files changed, 75 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 2dfc6a3bd4c1..34450a5e6573 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -258,45 +258,45 @@ static void ssi_blkcipher_exit(struct crypto_tfm *tfm)
typedef struct tdes_keys{
-u8 key1[DES_KEY_SIZE];
-u8 key2[DES_KEY_SIZE];
-u8 key3[DES_KEY_SIZE];
+ u8 key1[DES_KEY_SIZE];
+ u8 key2[DES_KEY_SIZE];
+ u8 key3[DES_KEY_SIZE];
}tdes_keys_t;
-static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
+static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
/* The function verifies that tdes keys are not weak.*/
static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen)
{
#ifdef CCREE_FIPS_SUPPORT
-tdes_keys_t *tdes_key = (tdes_keys_t*)key;
+ tdes_keys_t *tdes_key = (tdes_keys_t*)key;
/* verify key1 != key2 and key3 != key2*/
-if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2,
sizeof(tdes_key->key1)) == 0) ||
+ if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2,
sizeof(tdes_key->key1)) == 0) ||
(memcmp((u8*)tdes_key->key3, (u8*)tdes_key->key2,
sizeof(tdes_key->key3)) == 0) )) {
-return -ENOEXEC;
-}
+ return -ENOEXEC;
+ }
#endif /* CCREE_FIPS_SUPPORT */
-return 0;
+ return 0;
}
/* The function verifies that xts keys are not weak.*/
static int ssi_fips_verify_xts_keys(const u8 *key, unsigned int keylen)
{
#ifdef CCREE_FIPS_SUPPORT
-/* Weak key is define as key that its first half (128/256 lsb) equals
its second half (128/256 msb) */
-int singleKeySize = keylen >> 1;
+ /* Weak key is define as key that its first half (128/256 lsb) equals
its second half (128/256 msb) */
+ int singleKeySize = keylen >> 1;
if (unlikely(memcmp(key, &key[singleKeySize], singleKeySize) == 0)) {
return -ENOEXEC;
}
#endif /* CCREE_FIPS_SUPPORT */
-return 0;
+ return 0;
}
static enum cc_hw_crypto_key hw_key_to_cc_hw_key(int slot_num)
@@ -720,12 +720,13 @@ ssi_blkcipher_create_data_desc(
}
static int ssi_blkcipher_complete(struct device *dev,
- struct ssi_ablkcipher_ctx *ctx_p,
- struct blkcipher_req_ctx *req_ctx,
- struct scatterlist *dst, struct scatterlist
*src,
- unsigned int ivsize,
- void *areq,
- void __iomem *cc_base)
+ struct ssi_ablkcipher_ctx *ctx_p,
+ struct blkcipher_req_ctx *req_ctx,
+ struct scatterlist *dst,
+ struct scatterlist *src,
+ unsigned int ivsize,
+ void *areq,
+ void __iomem *cc_base)
{
int completion_error = 0;
u32 inflight_counter;
@@ -779,7 +780,7 @@ static int ssi_blkcipher_process(
/* No data to process is valid */
return 0;
}
-/*For CTS in case of data size aligned to 16 use CBC mode*/
+ /*For CTS in case of data size aligned to 16 use CBC mode*/
if (((nbytes % AES_BLOCK_SIZE) == 0) && (ctx_p->cipher_mode ==
DRV_CIPHER_CBC_CTS)){
ctx_p->cipher_mode = DRV_CIPHER_CBC;
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index 190922970bf0..b9d0dd27e853 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -437,9 +437,9 @@ static void cleanup_cc_resources(struct p
[PATCH V3] staging: vt6655 - style fix
Fix checkpatch.pl warnings of the form "function definition argument
'foo' should also have an identifier name" in header files.
Signed-off-by: Derek Robson
V1 and V2 had vague subject line
---
drivers/staging/vt6655/card.h| 30 ++---
drivers/staging/vt6655/channel.h | 4 +--
drivers/staging/vt6655/mac.h | 58
drivers/staging/vt6655/power.h | 16 +++
drivers/staging/vt6655/rf.h | 16 +--
5 files changed, 57 insertions(+), 67 deletions(-)
diff --git a/drivers/staging/vt6655/card.h b/drivers/staging/vt6655/card.h
index 03369ffaa4d6..1a04dbb57d42 100644
--- a/drivers/staging/vt6655/card.h
+++ b/drivers/staging/vt6655/card.h
@@ -64,25 +64,25 @@ typedef enum _CARD_STATUS_TYPE {
struct vnt_private;
void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type);
-void CARDvUpdateBasicTopRate(struct vnt_private *);
-bool CARDbIsOFDMinBasicRate(struct vnt_private *);
-void CARDvSetLoopbackMode(struct vnt_private *, unsigned short wLoopbackMode);
-bool CARDbSoftwareReset(struct vnt_private *);
-void CARDvSetFirstNextTBTT(struct vnt_private *,
+void CARDvUpdateBasicTopRate(struct vnt_private *priv);
+bool CARDbIsOFDMinBasicRate(struct vnt_private *priv);
+void CARDvSetLoopbackMode(struct vnt_private *priv, unsigned short
wLoopbackMode);
+bool CARDbSoftwareReset(struct vnt_private *priv);
+void CARDvSetFirstNextTBTT(struct vnt_private *priv,
unsigned short wBeaconInterval);
-void CARDvUpdateNextTBTT(struct vnt_private *, u64 qwTSF,
+void CARDvUpdateNextTBTT(struct vnt_private *priv, u64 qwTSF,
unsigned short wBeaconInterval);
-bool CARDbGetCurrentTSF(struct vnt_private *, u64 *pqwCurrTSF);
+bool CARDbGetCurrentTSF(struct vnt_private *priv, u64 *pqwCurrTSF);
u64 CARDqGetNextTBTT(u64 qwTSF, unsigned short wBeaconInterval);
u64 CARDqGetTSFOffset(unsigned char byRxRate, u64 qwTSF1, u64 qwTSF2);
-unsigned char CARDbyGetPktType(struct vnt_private *);
-void CARDvSafeResetTx(struct vnt_private *);
-void CARDvSafeResetRx(struct vnt_private *);
-bool CARDbRadioPowerOff(struct vnt_private *);
-bool CARDbRadioPowerOn(struct vnt_private *);
-bool CARDbSetPhyParameter(struct vnt_private *, u8);
-bool CARDbUpdateTSF(struct vnt_private *, unsigned char byRxRate,
+unsigned char CARDbyGetPktType(struct vnt_private *priv);
+void CARDvSafeResetTx(struct vnt_private *priv);
+void CARDvSafeResetRx(struct vnt_private *priv);
+bool CARDbRadioPowerOff(struct vnt_private *priv);
+bool CARDbRadioPowerOn(struct vnt_private *priv);
+bool CARDbSetPhyParameter(struct vnt_private *priv, u8 bb_type);
+bool CARDbUpdateTSF(struct vnt_private *priv, unsigned char byRxRate,
u64 qwBSSTimestamp);
-bool CARDbSetBeaconPeriod(struct vnt_private *, unsigned short
wBeaconInterval);
+bool CARDbSetBeaconPeriod(struct vnt_private *priv, unsigned short
wBeaconInterval);
#endif /* __CARD_H__ */
diff --git a/drivers/staging/vt6655/channel.h b/drivers/staging/vt6655/channel.h
index 2621dfabff06..8fe70760e548 100644
--- a/drivers/staging/vt6655/channel.h
+++ b/drivers/staging/vt6655/channel.h
@@ -21,8 +21,8 @@
#include "card.h"
-void vnt_init_bands(struct vnt_private *);
+void vnt_init_bands(struct vnt_private *priv);
-bool set_channel(struct vnt_private *, struct ieee80211_channel *);
+bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch);
#endif /* _CHANNEL_H_ */
diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
index 33b758cb79d4..db401e32ae23 100644
--- a/drivers/staging/vt6655/mac.h
+++ b/drivers/staging/vt6655/mac.h
@@ -885,57 +885,57 @@ do {
\
#define MACvSetRFLE_LatchBase(iobase) \
MACvWordRegBitsOn(iobase, MAC_REG_SOFTPWRCTL, SOFTPWRCTL_RFLEOPT)
-bool MACbIsRegBitsOn(struct vnt_private *, unsigned char byRegOfs,
+bool MACbIsRegBitsOn(struct vnt_private *priv, unsigned char byRegOfs,
unsigned char byTestBits);
-bool MACbIsRegBitsOff(struct vnt_private *, unsigned char byRegOfs,
+bool MACbIsRegBitsOff(struct vnt_private *priv, unsigned char byRegOfs,
unsigned char byTestBits);
-bool MACbIsIntDisable(struct vnt_private *);
+bool MACbIsIntDisable(struct vnt_private *priv);
-void MACvSetShortRetryLimit(struct vnt_private *, unsigned char byRetryLimit);
+void MACvSetShortRetryLimit(struct vnt_private *priv, unsigned char
byRetryLimit);
-void MACvSetLongRetryLimit(struct vnt_private *, unsigned char byRetryLimit);
-void MACvGetLongRetryLimit(struct vnt_private *,
+void MACvSetLongRetryLimit(struct vnt_private *priv, unsigned char
byRetryLimit);
+void MACvGetLongRetryLimit(struct vnt_private *priv,
unsigned char *pbyRetryLimit);
-void MACvSetLoopbackMode(struct vnt_private *, unsigned char byLoopbackMode);
+void MACvSetLoopbackMode(struct vnt_private *priv, unsigned
[PATCH V2] staging: sm750fb - style fix
Fixed checkpatch.pl warnings of the form "function definition argument 'foo' should also have an identifier name" in header files. Signed-off-by: Derek Robson V1 had vague subject --- drivers/staging/sm750fb/sm750.h | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h index 5b186dafedec..4386122799b2 100644 --- a/drivers/staging/sm750fb/sm750.h +++ b/drivers/staging/sm750fb/sm750.h @@ -189,14 +189,22 @@ void hw_sm750_initAccel(struct sm750_dev *sm750_dev); int hw_sm750_deWait(void); int hw_sm750le_deWait(void); -int hw_sm750_output_setMode(struct lynxfb_output*, struct fb_var_screeninfo*, - struct fb_fix_screeninfo*); -int hw_sm750_crtc_checkMode(struct lynxfb_crtc*, struct fb_var_screeninfo*); -int hw_sm750_crtc_setMode(struct lynxfb_crtc*, struct fb_var_screeninfo*, - struct fb_fix_screeninfo*); -int hw_sm750_setColReg(struct lynxfb_crtc*, ushort, ushort, ushort, ushort); -int hw_sm750_setBLANK(struct lynxfb_output*, int); -int hw_sm750le_setBLANK(struct lynxfb_output*, int); +int hw_sm750_output_setMode(struct lynxfb_output *output, + struct fb_var_screeninfo *var, + struct fb_fix_screeninfo *fix); + +int hw_sm750_crtc_checkMode(struct lynxfb_crtc *crtc, + struct fb_var_screeninfo *var); + +int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc, + struct fb_var_screeninfo *var, + struct fb_fix_screeninfo *fix); + +int hw_sm750_setColReg(struct lynxfb_crtc *crtc, ushort index, + ushort red, ushort green, ushort blue); + +int hw_sm750_setBLANK(struct lynxfb_output *output, int blank); +int hw_sm750le_setBLANK(struct lynxfb_output *output, int blank); int hw_sm750_pan_display(struct lynxfb_crtc *crtc, const struct fb_var_screeninfo *var, const struct fb_info *info); -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: unisys: visorhba - style fix
Fixed style of permissions to octal.
Found using checkpatch
Signed-off-by: Derek Robson
V1 has vauge subject
---
drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2fd31c9762c6..a6e7a6bbc428 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -1090,7 +1090,7 @@ static int visorhba_probe(struct visor_device *dev)
goto err_scsi_remove_host;
}
devdata->debugfs_info =
- debugfs_create_file("info", S_IRUSR | S_IRGRP,
+ debugfs_create_file("info", 0440,
devdata->debugfs_dir, devdata,
&info_debugfs_fops);
if (!devdata->debugfs_info) {
--
2.13.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: rtl8723bs - remove asm includes
Fixed checkpatch warnings "Use #include instead of " Found using checkpatch Signed-off-by: Derek Robson V1 had vauge subject. --- drivers/staging/rtl8723bs/include/osdep_service_linux.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8723bs/include/osdep_service_linux.h b/drivers/staging/rtl8723bs/include/osdep_service_linux.h index 486e8184b0b2..0c9b4f622fee 100644 --- a/drivers/staging/rtl8723bs/include/osdep_service_linux.h +++ b/drivers/staging/rtl8723bs/include/osdep_service_linux.h @@ -26,10 +26,10 @@ /* include */ #include #include - #include + #include #include - #include - #include + #include + #include #include #include #include -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: rtl8192u: style fix
Fixed checkpatch.pl warnings of "function definition argument FOO should
also have an identifier name"
Found using checkpatch
Signed-off-by: Derek Robson
V1 had vauge subjet
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h | 4 ++--
drivers/staging/rtl8192u/r8192U.h| 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 899c77ed2a43..b062cad052b9 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -2187,7 +2187,7 @@ int ieee80211_encrypt_fragment(struct ieee80211_device
*ieee,
struct sk_buff *frag, int hdr_len);
int ieee80211_xmit(struct sk_buff *skb, struct net_device *dev);
-void ieee80211_txb_free(struct ieee80211_txb *);
+void ieee80211_txb_free(struct ieee80211_txb *txb);
/* ieee80211_rx.c */
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
index 005bf89aae65..a0aa0f5be63a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
@@ -82,8 +82,8 @@ struct ieee80211_crypt_data {
int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops);
int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops);
struct ieee80211_crypto_ops *ieee80211_get_crypto_ops(const char *name);
-void ieee80211_crypt_deinit_entries(struct ieee80211_device *, int);
-void ieee80211_crypt_deinit_handler(unsigned long);
+void ieee80211_crypt_deinit_entries(struct ieee80211_device *ieee, int force);
+void ieee80211_crypt_deinit_handler(unsigned long data);
void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee,
struct ieee80211_crypt_data **crypt);
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index 4c7a5e3d3e5e..51c150a39fc2 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1147,9 +1147,9 @@ int write_nic_word(struct net_device *dev, int x, u16 y);
int write_nic_dword(struct net_device *dev, int x, u32 y);
void force_pci_posting(struct net_device *dev);
-void rtl8192_rtx_disable(struct net_device *);
-void rtl8192_rx_enable(struct net_device *);
-void rtl8192_tx_enable(struct net_device *);
+void rtl8192_rtx_disable(struct net_device *dev);
+void rtl8192_rx_enable(struct net_device *dev);
+void rtl8192_tx_enable(struct net_device *dev);
void rtl8192_disassociate(struct net_device *dev);
void rtl8185_set_rf_pins_enable(struct net_device *dev, u32 a);
--
2.13.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Fri, 16 Jun 2017, Joe Perches wrote:
> On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > The header field in struct pd_message is declared as an __le16 type. The
> > data in the message is supposed to be little endian. This means we don't
> > have to go and shift the individual bytes into position when we're
> > filling the buffer, we can just copy the contents right away. As an
> > added benefit we don't get fishy results on big endian systems anymore.
>
> Thanks for pointing this out.
>
> There are several instances of this class of error.
>
> Here's a cocci script to find them.
>
> This is best used with cocci's --all-includes option like:
>
> $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
> [ many defects...]
>
> $ cat lebe_bitshifts.cocci
> @@
> typedef __le16, __le32, __le64, __be16, __be32, __be64;
> { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> expression b;
> @@
>
> * a << b
>
> @@
> { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> expression b;
> @@
>
> * a <<= b
>
> @@
> { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> expression b;
> @@
>
> * a >> b
>
> @@
> { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> expression b;
> @@
>
> * a >>= b
Is this always a problem? Would it be useful to add this to the scripts
in the kernel?
julia___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Sat, 2017-06-17 at 07:23 +0200, Julia Lawall wrote:
> On Fri, 16 Jun 2017, Joe Perches wrote:
> > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > > The header field in struct pd_message is declared as an __le16 type. The
> > > data in the message is supposed to be little endian. This means we don't
> > > have to go and shift the individual bytes into position when we're
> > > filling the buffer, we can just copy the contents right away. As an
> > > added benefit we don't get fishy results on big endian systems anymore.
> >
> > Thanks for pointing this out.
> >
> > There are several instances of this class of error.
> >
> > Here's a cocci script to find them.
> >
> > This is best used with cocci's --all-includes option like:
> >
> > $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
> > [ many defects...]
Probably would have been better as [ many possible defects... ]
> > $ cat lebe_bitshifts.cocci
> > @@
> > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > expression b;
> > @@
> >
> > * a << b
[etc...]
> Is this always a problem?
No, not always.
If the CPU is the equivalent endian, the bitshift is fine.
It can't be known if the code is only compiled on a
single cpu type. It is rather odd though to use endian
notation if the code is compiled for a single cpu type.
> Would it be useful to add this to the scripts
> in the kernel?
Maybe.
btw: is there a way for the operators to be surrounded by
some \( \| \) or some other bracket style so it could
be written with a single test?
Something like:
@@
typedef __le16, __le32, __le64, __be16, __be32, __be64;
{ __le16, __le32, __le64, __be16, __be32, __be64 } a;
expression b;
@@
* a [<<|<<=|>>|>>=] b
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Fri, 16 Jun 2017, Joe Perches wrote:
> On Sat, 2017-06-17 at 07:23 +0200, Julia Lawall wrote:
> > On Fri, 16 Jun 2017, Joe Perches wrote:
> > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > > > The header field in struct pd_message is declared as an __le16 type. The
> > > > data in the message is supposed to be little endian. This means we don't
> > > > have to go and shift the individual bytes into position when we're
> > > > filling the buffer, we can just copy the contents right away. As an
> > > > added benefit we don't get fishy results on big endian systems anymore.
> > >
> > > Thanks for pointing this out.
> > >
> > > There are several instances of this class of error.
> > >
> > > Here's a cocci script to find them.
> > >
> > > This is best used with cocci's --all-includes option like:
> > >
> > > $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
> > > [ many defects...]
>
> Probably would have been better as [ many possible defects... ]
OK
> > > $ cat lebe_bitshifts.cocci
> > > @@
> > > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > > expression b;
> > > @@
> > >
> > > * a << b
>
> [etc...]
>
> > Is this always a problem?
>
> No, not always.
>
> If the CPU is the equivalent endian, the bitshift is fine.
> It can't be known if the code is only compiled on a
> single cpu type. It is rather odd though to use endian
> notation if the code is compiled for a single cpu type.
Is there some way to know from the code if it is compiled for a single cou
type?
> > Would it be useful to add this to the scripts
> > in the kernel?
>
> Maybe.
If there are a lot of false positives, it could be a nuisance...
> btw: is there a way for the operators to be surrounded by
> some \( \| \) or some other bracket style so it could
> be written with a single test?
>
> Something like:
>
> @@
> typedef __le16, __le32, __le64, __be16, __be32, __be64;
> { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> expression b;
> @@
>
> * a [<<|<<=|>>|>>=] b
Partly. You can define
binary operator bop = {<<,>>};
or
assignment operator aop = {<<=,>>=};
to make two rules instead of four.
julia___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Fri, 16 Jun 2017, Joe Perches wrote:
> On Sat, 2017-06-17 at 08:00 +0200, Julia Lawall wrote:
> > On Fri, 16 Jun 2017, Joe Perches wrote:
> > > On Sat, 2017-06-17 at 07:23 +0200, Julia Lawall wrote:
> > > > On Fri, 16 Jun 2017, Joe Perches wrote:
> > > > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > > > > > The header field in struct pd_message is declared as an __le16
> > > > > > type. The
> > > > > > data in the message is supposed to be little endian. This means we
> > > > > > don't
> > > > > > have to go and shift the individual bytes into position when we're
> > > > > > filling the buffer, we can just copy the contents right away. As an
> > > > > > added benefit we don't get fishy results on big endian systems
> > > > > > anymore.
> > > > >
> > > > > Thanks for pointing this out.
> > > > >
> > > > > There are several instances of this class of error.
> > > > >
> > > > > Here's a cocci script to find them.
> > > > >
> > > > > This is best used with cocci's --all-includes option like:
> > > > >
> > > > > $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
> > > > > [ many defects...]
> > >
> > > Probably would have been better as [ many possible defects... ]
> >
> > OK
> >
> > > > > $ cat lebe_bitshifts.cocci
> > > > > @@
> > > > > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > > > > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > > > > expression b;
> > > > > @@
> > > > >
> > > > > * a << b
> > >
> > > [etc...]
> > >
> > > > Is this always a problem?
> > >
> > > No, not always.
> > >
> > > If the CPU is the equivalent endian, the bitshift is fine.
> > > It can't be known if the code is only compiled on a
> > > single cpu type. It is rather odd though to use endian
> > > notation if the code is compiled for a single cpu type.
> >
> > Is there some way to know from the code if it is compiled for a single cou
> > type?
>
> No easy way as far as I can tell.
> I believe it'd require parsing Kconfig.
>
> > > > Would it be useful to add this to the scripts
> > > > in the kernel?
> > >
> > > Maybe.
> >
> > If there are a lot of false positives, it could be a nuisance...
>
> I believe the most likely false positives would be in arch/ code
>
> > > btw: is there a way for the operators to be surrounded by
> > > some \( \| \) or some other bracket style so it could
> > > be written with a single test?
> > >
> > > Something like:
> > >
> > > @@
> > > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > > expression b;
> > > @@
> > >
> > > * a [<<|<<=|>>|>>=] b
> >
> > Partly. You can define
> >
> > binary operator bop = {<<,>>};
>
> thanks.
>
> btw: After a couple hours with this script, I got a segmentation fault
>
> Here's the output I got running
>
> $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
Weird. I will try it.
thanks,
julia
> diff -u -p ./net/dsa/tag_qca.c /tmp/nothing/net/dsa/tag_qca.c
> --- ./net/dsa/tag_qca.c
> +++ /tmp/nothing/net/dsa/tag_qca.c
> @@ -84,7 +84,6 @@ static struct sk_buff *qca_tag_rcv(struc
> hdr = ntohs(*phdr);
>
> /* Make sure the version is correct */
> - ver = (hdr & QCA_HDR_RECV_VERSION_MASK) >> QCA_HDR_RECV_VERSION_S;
> if (unlikely(ver != QCA_HDR_VERSION))
> return NULL;
>
> diff -u -p ./arch/mips/pci/pci-lantiq.c
> /tmp/nothing/arch/mips/pci/pci-lantiq.c
> --- ./arch/mips/pci/pci-lantiq.c
> +++ /tmp/nothing/arch/mips/pci/pci-lantiq.c
> @@ -151,7 +151,6 @@ static int ltq_pci_startup(struct platfo
> /* setup the request mask */
> req_mask = of_get_property(node, "req-mask", NULL);
> if (req_mask)
> - temp_buffer &= ~((*req_mask & 0xf) << 16);
> else
> temp_buffer &= ~0xf;
> /* enable internal arbiter */
> diff -u -p ./arch/powerpc/platforms/powernv/opal-lpc.c
> /tmp/nothing/arch/powerpc/platforms/powernv/opal-lpc.c
> --- ./arch/powerpc/platforms/powernv/opal-lpc.c
> +++ /tmp/nothing/arch/powerpc/platforms/powernv/opal-lpc.c
> @@ -44,7 +44,6 @@ static __le16 __opal_lpc_inw(unsigned lo
> if (opal_lpc_chip_id < 0 || port > 0xfffe)
> return 0x;
> if (port & 1)
> - return (__le16)opal_lpc_inb(port) << 8 | opal_lpc_inb(port + 1);
> rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 2);
> return rc ? 0x : be32_to_cpu(data);
> }
> @@ -61,9 +60,6 @@ static __le32 __opal_lpc_inl(unsigned lo
> if (opal_lpc_chip_id < 0 || port > 0xfffc)
> return 0x;
> if (port & 3)
> - return (__le32)opal_lpc_inb(port) << 24 |
> -(__le32)opal_lpc_inb(port + 1) << 16 |
> -(__le32)opal_lpc_inb(port + 2) << 8 |
> opal_lpc_inb(port + 3);
> rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 4);
> return rc ? 0x : be32_to_cpu(data);
Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]
On Sat, 2017-06-17 at 08:00 +0200, Julia Lawall wrote:
> On Fri, 16 Jun 2017, Joe Perches wrote:
> > On Sat, 2017-06-17 at 07:23 +0200, Julia Lawall wrote:
> > > On Fri, 16 Jun 2017, Joe Perches wrote:
> > > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > > > > The header field in struct pd_message is declared as an __le16 type.
> > > > > The
> > > > > data in the message is supposed to be little endian. This means we
> > > > > don't
> > > > > have to go and shift the individual bytes into position when we're
> > > > > filling the buffer, we can just copy the contents right away. As an
> > > > > added benefit we don't get fishy results on big endian systems
> > > > > anymore.
> > > >
> > > > Thanks for pointing this out.
> > > >
> > > > There are several instances of this class of error.
> > > >
> > > > Here's a cocci script to find them.
> > > >
> > > > This is best used with cocci's --all-includes option like:
> > > >
> > > > $ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
> > > > [ many defects...]
> >
> > Probably would have been better as [ many possible defects... ]
>
> OK
>
> > > > $ cat lebe_bitshifts.cocci
> > > > @@
> > > > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > > > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > > > expression b;
> > > > @@
> > > >
> > > > * a << b
> >
> > [etc...]
> >
> > > Is this always a problem?
> >
> > No, not always.
> >
> > If the CPU is the equivalent endian, the bitshift is fine.
> > It can't be known if the code is only compiled on a
> > single cpu type. It is rather odd though to use endian
> > notation if the code is compiled for a single cpu type.
>
> Is there some way to know from the code if it is compiled for a single cou
> type?
No easy way as far as I can tell.
I believe it'd require parsing Kconfig.
> > > Would it be useful to add this to the scripts
> > > in the kernel?
> >
> > Maybe.
>
> If there are a lot of false positives, it could be a nuisance...
I believe the most likely false positives would be in arch/ code
> > btw: is there a way for the operators to be surrounded by
> > some \( \| \) or some other bracket style so it could
> > be written with a single test?
> >
> > Something like:
> >
> > @@
> > typedef __le16, __le32, __le64, __be16, __be32, __be64;
> > { __le16, __le32, __le64, __be16, __be32, __be64 } a;
> > expression b;
> > @@
> >
> > * a [<<|<<=|>>|>>=] b
>
> Partly. You can define
>
> binary operator bop = {<<,>>};
thanks.
btw: After a couple hours with this script, I got a segmentation fault
Here's the output I got running
$ spatch --all-includes --very-quiet --sp-file lebe_bitshifts.cocci .
diff -u -p ./net/dsa/tag_qca.c /tmp/nothing/net/dsa/tag_qca.c
--- ./net/dsa/tag_qca.c
+++ /tmp/nothing/net/dsa/tag_qca.c
@@ -84,7 +84,6 @@ static struct sk_buff *qca_tag_rcv(struc
hdr = ntohs(*phdr);
/* Make sure the version is correct */
- ver = (hdr & QCA_HDR_RECV_VERSION_MASK) >> QCA_HDR_RECV_VERSION_S;
if (unlikely(ver != QCA_HDR_VERSION))
return NULL;
diff -u -p ./arch/mips/pci/pci-lantiq.c /tmp/nothing/arch/mips/pci/pci-lantiq.c
--- ./arch/mips/pci/pci-lantiq.c
+++ /tmp/nothing/arch/mips/pci/pci-lantiq.c
@@ -151,7 +151,6 @@ static int ltq_pci_startup(struct platfo
/* setup the request mask */
req_mask = of_get_property(node, "req-mask", NULL);
if (req_mask)
- temp_buffer &= ~((*req_mask & 0xf) << 16);
else
temp_buffer &= ~0xf;
/* enable internal arbiter */
diff -u -p ./arch/powerpc/platforms/powernv/opal-lpc.c
/tmp/nothing/arch/powerpc/platforms/powernv/opal-lpc.c
--- ./arch/powerpc/platforms/powernv/opal-lpc.c
+++ /tmp/nothing/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -44,7 +44,6 @@ static __le16 __opal_lpc_inw(unsigned lo
if (opal_lpc_chip_id < 0 || port > 0xfffe)
return 0x;
if (port & 1)
- return (__le16)opal_lpc_inb(port) << 8 | opal_lpc_inb(port + 1);
rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 2);
return rc ? 0x : be32_to_cpu(data);
}
@@ -61,9 +60,6 @@ static __le32 __opal_lpc_inl(unsigned lo
if (opal_lpc_chip_id < 0 || port > 0xfffc)
return 0x;
if (port & 3)
- return (__le32)opal_lpc_inb(port) << 24 |
- (__le32)opal_lpc_inb(port + 1) << 16 |
- (__le32)opal_lpc_inb(port + 2) << 8 |
opal_lpc_inb(port + 3);
rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 4);
return rc ? 0x : be32_to_cpu(data);
@@ -86,7 +82,6 @@ static void __opal_lpc_outw(__le16 val,
if (opal_lpc_chip_id < 0 || port > 0xfffe)
return;
if (port & 1) {
- opal_lpc_outb(val >> 8, port);
opal_lpc_outb(val , port + 1);
