Re: [PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16
On Mon, 9 Jan 2017 21:25:56 -0600
Eric Salem wrote:
> Fixed the following sparse warning:
>
> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
> cast to restricted __le16
>
> by correcting the variable's type (also updated sizeof).
>
> Signed-off-by: Eric Salem
Acked-by: Christian Gromm
> ---
> drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c
> b/drivers/staging/most/hdm-usb/hdm_usb.c
> index d6db0bd..01e3a31 100644
> --- a/drivers/staging/most/hdm-usb/hdm_usb.c
> +++ b/drivers/staging/most/hdm-usb/hdm_usb.c
> @@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
> static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
> {
> int retval;
> - u16 *dma_buf = kzalloc(sizeof(u16), GFP_KERNEL);
> + __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
> u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
>
> if (!dma_buf)
> @@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16
> reg, u16 *buf)
> retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
>DRCI_READ_REQ, req_type,
>0x,
> - reg, dma_buf, sizeof(u16), 5 * HZ);
> + reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
> *buf = le16_to_cpu(*dma_buf);
> kfree(dma_buf);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH next] rtlwifi: rtl8192de: fix missing curly braces
Restore some curly braces that have been removed in commit c93ac39da006457f
("rtlwifi: Remove some redundant code") while removing redundant messages
and extraneous braces.
This fixes the following smatch warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw()
warn: curly braces intended?
...and the following coccinelle warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:325:2-38: code aligned
with following code on line 326
Fixes: c93ac39da006457f ("rtlwifi: Remove some redundant code")
Signed-off-by: Vincent Stehlé
Cc: Larry Finger
Cc: Kalle Valo
Cc: Joe Perches
Cc: Ping-Ke Shih
---
Hi,
I saw that in Linux next-20170110.
Best regards,
Vincent.
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index aa1e51c871df..bcde4da4e593 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -321,9 +321,10 @@ int rtl92d_download_fw(struct ieee80211_hw *hw)
value &= (~BIT(5));
rtl_write_byte(rtlpriv, 0x1f, value);
spin_unlock_irqrestore(&globalmutex_for_fwdownload, flags);
- if (err)
+ if (err) {
pr_err("fw is not ready to run!\n");
goto exit;
+ }
exit:
err = _rtl92d_fw_init(hw);
return err;
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] vme: Fix wrong pointer utilization in ca91cx42_slave_get
In ca91cx42_slave_get function, the value pointed by vme_base pointer is set through: *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); So it must be dereferenced to be used in calculation of pci_base: *pci_base = (dma_addr_t)*vme_base + pci_offset; This bug was caught thanks to the following gcc warning: drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *pci_base = (dma_addr_t)vme_base + pci_offset; Signed-off-by: Augusto Mecking Caringi --- drivers/vme/bridges/vme_ca91cx42.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vme/bridges/vme_ca91cx42.c b/drivers/vme/bridges/vme_ca91cx42.c index 6b5ee89..7cc5122 100644 --- a/drivers/vme/bridges/vme_ca91cx42.c +++ b/drivers/vme/bridges/vme_ca91cx42.c @@ -464,7 +464,7 @@ static int ca91cx42_slave_get(struct vme_slave_resource *image, int *enabled, vme_bound = ioread32(bridge->base + CA91CX42_VSI_BD[i]); pci_offset = ioread32(bridge->base + CA91CX42_VSI_TO[i]); - *pci_base = (dma_addr_t)vme_base + pci_offset; + *pci_base = (dma_addr_t)*vme_base + pci_offset; *size = (unsigned long long)((vme_bound - *vme_base) + granularity); *enabled = 0; -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/4] hv_util: adjust system time smoothly
Thomas Gleixner writes: > On Wed, 4 Jan 2017, Vitaly Kuznetsov wrote: > >> Changes since v1: >> - do do_settimeofday64() when ICTIMESYNCFLAG_SYNC flag is present in the >> request (Alex Ng) >> - add pr_debug() for the case when do_adjtimex() fails (Alex Ng) >> >> Original description: >> >> With TimeSync version 4 protocol support we started updating system time >> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds >> there is a time sample from the host which triggers do_settimeofday[64](). >> While the time from the host is very accurate such adjustments may cause >> issues: >> - Time is jumping forward and backward, some applications may misbehave. >> - In case an NTP client is run in parallel things may go south, e.g. when >> an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY >> the Hyper-V module will not see this changes and time will oscillate and >> never converge. >> - Systemd starts annoying you by printing "Time has been changed" every 5 >> seconds to the system log. >> >> With this series I suggest to use do_adjtimex() to adjust time. My tests >> show that such method gives equally good time convergence but avoids all >> the drawbacks described above. > > To be honest, I think all of this is just tinkering. > Thank you for your comments, Thomas, > 1) do_adjtimex() is assuming that there is a single client connected which >is responsible for the updates. So I seriously doubt that a NTP client >running in the guest will cooperate nicely with that timesync magic >under all circumstances. True, as Stephen suggested we'll probably need a way to inform (or block) the second NTP client about the ongoing timesync. > > 2) There is still the possibility to force do_settimeofday() calls which >will upset NTP clients and have other side effects. > >Why is this call necessary at all? Just because it's in some spec? ICTIMESYNCFLAG_SYNC flag, demanding us to do so, is only set on the first packet (when our VM boots) and after suspend/resume/migration events. In these cases guest's time can be off by minutes/hours and do_settimeofday() is probably justified. > > 3) What happens if you have a PTP capable network card mapped into your >guest and the guest uses PTP for time synchronization? The outcome is >predictible: CRAP. > > I can see the value for a host wide time synchronization, but please use > mechanisms which do not interfere with the rest of the time eco system in > Linux. > > The timesync thing happens periodically every 5 seconds, which you can feed > nicely into the PPS subsystem and then the guest side NTP daemon can > utilize it (or not). > My understanding is that we have no guarantees from the host that these messages are sent every 5 seconds and even when they are the interval is not very precise. We can probably create a 'fake' pps signal out of these messages (e.g. these messages will just be adjusting the frequency of the signal. I can play with such approach if you think this is the way to go. -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/4] hv_util: adjust system time smoothly
Vitaly, On Tue, 10 Jan 2017, Vitaly Kuznetsov wrote: > Thomas Gleixner writes: > > 1) do_adjtimex() is assuming that there is a single client connected which > >is responsible for the updates. So I seriously doubt that a NTP client > >running in the guest will cooperate nicely with that timesync magic > >under all circumstances. > > True, as Stephen suggested we'll probably need a way to inform (or > block) the second NTP client about the ongoing timesync. I don't see how that's supposed to work. > > 2) There is still the possibility to force do_settimeofday() calls which > >will upset NTP clients and have other side effects. > > > >Why is this call necessary at all? Just because it's in some spec? > > ICTIMESYNCFLAG_SYNC flag, demanding us to do so, is only set on the > first packet (when our VM boots) and after suspend/resume/migration > events. In these cases guest's time can be off by minutes/hours and > do_settimeofday() is probably justified. Usually boot/resume time is pretty accurate through RTC readout, but IIRC then Windows still insists on RTC being set to local time instead of UTC, which does not really work well on Linux. > > > > 3) What happens if you have a PTP capable network card mapped into your > >guest and the guest uses PTP for time synchronization? The outcome is > >predictible: CRAP. > > > > I can see the value for a host wide time synchronization, but please use > > mechanisms which do not interfere with the rest of the time eco system in > > Linux. > > > > The timesync thing happens periodically every 5 seconds, which you can feed > > nicely into the PPS subsystem and then the guest side NTP daemon can > > utilize it (or not). > > > > My understanding is that we have no guarantees from the host that these > messages are sent every 5 seconds and even when they are the interval is > not very precise. We can probably create a 'fake' pps signal out of > these messages (e.g. these messages will just be adjusting the frequency > of the signal. I can play with such approach if you think this is the > way to go. The PPS stuff has some expectations about the interval, but it's a rather solid piece of art and I think it's worth a try. Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: greybus: style fix, permissions as octal
On Mon, Jan 09, 2017 at 02:24:29PM +0100, Johan Hovold wrote:
> On Fri, Jan 06, 2017 at 08:43:57PM +1300, Derek Robson wrote:
> > Changed permissions to be in octal style.
> > Found by checkpatch.
> >
> > Signed-off-by: Derek Robson
> > ---
> >
> > This version of patch also make the file type part of the mask with the
> > permissions, as per recommendation from Greg K-H
> >
> > drivers/staging/greybus/camera.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/staging/greybus/camera.c
> > b/drivers/staging/greybus/camera.c
> > index 0ee291ca2c72..73ddb612953b 100644
> > --- a/drivers/staging/greybus/camera.c
> > +++ b/drivers/staging/greybus/camera.c
> > @@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
> > static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
> > {
> > .name = "capabilities",
> > - .mask = S_IFREG | S_IRUGO,
> > + .mask = 0100444,
>
> This is not readable at all. Octal numbers make sense for the
> permissions bits, but not for the rest.
>
> We have code that mix symbolic macros for the higher bits and octal
> permissions, please do so here too.
Yeah, Johan is right, sorry about that, your first patch was better :(
Derek, can you resend that?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int
From: Christian Bewermeyer
Note that this patch does not fix all checkpatch warnings for
gpio.c
Signed-off-by: Christian Bewermeyer
Signed-off-by: Roman Sommer
---
drivers/staging/greybus/gpio.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 250caa0..0c95bce 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -410,21 +410,21 @@ static int gb_gpio_request_handler(struct gb_operation
*op)
return 0;
}
-static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
return gb_gpio_activate_operation(ggc, (u8)offset);
}
-static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void gb_gpio_free(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
gb_gpio_deactivate_operation(ggc, (u8)offset);
}
-static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -438,22 +438,22 @@ static int gb_gpio_get_direction(struct gpio_chip *chip,
unsigned offset)
return ggc->lines[which].direction ? 1 : 0;
}
-static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
return gb_gpio_direction_in_operation(ggc, (u8)offset);
}
-static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
- int value)
+static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned int
offset,
+ int value)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
return gb_gpio_direction_out_operation(ggc, (u8)offset, !!value);
}
-static int gb_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -467,15 +467,15 @@ static int gb_gpio_get(struct gpio_chip *chip, unsigned
offset)
return ggc->lines[which].value;
}
-static void gb_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void gb_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
}
-static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
- unsigned debounce)
+static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u16 usec;
@@ -593,7 +593,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
{
struct gb_gpio_controller *ggc;
unsigned int offset;
- unsigned irq_base;
+ unsigned int irq_base;
if (!chip || !irqchip)
return -EINVAL;
@@ -625,7 +625,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
return 0;
}
-static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16
On Mon, Jan 09, 2017 at 09:25:56PM -0600, Eric Salem wrote: > Fixed the following sparse warning: > > drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning: > cast to restricted __le16 > > by correcting the variable's type (also updated sizeof). > > Signed-off-by: Eric Salem > Acked-by: Christian Gromm > --- > drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This patch doesn't apply against linux-next, can you refresh it and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int
On Tue, Jan 10, 2017 at 05:21:24PM +0100, Roman Sommer wrote: > From: Christian Bewermeyer > > Note that this patch does not fix all checkpatch warnings for > gpio.c Fair enough, but you are fixing all of these new "unsigned int" warnings in that driver, right? How about fixing the sole remaining instance in the loopback driver so that this is done for the whole subsystem once and for all? Also your Subject should be staging: greybus: gpio: fix checkpatch unsigned warnings unless doing this subsystem-wide, in which case you can drop the "gpio" module prefix. Thanks, Johan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/9] staging: vc04_services: Clean up vchiq driver
On Sun, Jan 08, 2017 at 06:15:09PM +, Stefan Wahren wrote: > This is a loose bunch of clean up patches for the bcm2835 vchiq driver. All now applied, thanks. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] greybus: checkpatch: Change parameter type unsigned to unsigned int
> Fair enough, but you are fixing all of these new "unsigned int" > warnings in that driver, right? > > How about fixing the sole remaining instance in the loopback driver so > that this is done for the whole subsystem once and for all? Thanks for the hint, I will do that. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/18] Drivers: hv: vmbus: Move the definition of hv_x64_msr_hypercall_contents
On Fri, Dec 30, 2016 at 01:35:55PM -0800, k...@exchange.microsoft.com wrote: > From: K. Y. Srinivasan > > As part of the effort to separate out architecture specific code, move the > definition of hv_x64_msr_hypercall_contents to x86 specific header file. > > Signed-off-by: K. Y. Srinivasan > --- > arch/x86/include/asm/mshyperv.h | 12 > drivers/hv/hyperv_vmbus.h | 15 --- > 2 files changed, 12 insertions(+), 15 deletions(-) This series doesn't apply against my tree. Can you please refresh it and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: fix checkpatch block comments warning
Fix the following warnings: Block comments should align the * on each line Signed-off-by: Abdul Rauf --- drivers/staging/unisys/visorbus/visorchipset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/unisys/visorbus/visorchipset.c b/drivers/staging/unisys/visorbus/visorchipset.c index 336af52d43d7..4e630ea527e8 100644 --- a/drivers/staging/unisys/visorbus/visorchipset.c +++ b/drivers/staging/unisys/visorbus/visorchipset.c @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct controlvm_message *inmsg) * * devices are automatically enabled at * initialization. - */ +*/ parahotplug_request_kickoff(req); controlvm_respond_physdev_changestate (&inmsg->hdr, -- 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: unisys: fix checkpatch block comments warning
> -Original Message- > From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com] > Sent: Tuesday, January 10, 2017 6:24 PM > To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer > > Cc: de...@driverdev.osuosl.org > Subject: [PATCH] staging: unisys: fix checkpatch block comments warning This patch has the same subject line as the previous patch? Which one should we use? Or can you make the names unique? David Kershner > > Fix the following warnings: > Block comments should align the * on each line > > Signed-off-by: Abdul Rauf > --- > drivers/staging/unisys/visorbus/visorchipset.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/unisys/visorbus/visorchipset.c > b/drivers/staging/unisys/visorbus/visorchipset.c > index 336af52d43d7..4e630ea527e8 100644 > --- a/drivers/staging/unisys/visorbus/visorchipset.c > +++ b/drivers/staging/unisys/visorbus/visorchipset.c > @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct > controlvm_message *inmsg) >* >* devices are automatically enabled at >* initialization. > - */ > + */ > parahotplug_request_kickoff(req); > controlvm_respond_physdev_changestate > (&inmsg->hdr, > -- > 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: fix checkpatch block comments warning
On 01/10/2017 06:36 PM, Kershner, David A wrote: >> -Original Message- >> From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com] >> Sent: Tuesday, January 10, 2017 6:24 PM >> To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer >> >> Cc: de...@driverdev.osuosl.org >> Subject: [PATCH] staging: unisys: fix checkpatch block comments warning > This patch has the same subject line as the previous patch? Which one > should we use? Or can you make the names unique? > > David Kershner > >> Fix the following warnings: >> Block comments should align the * on each line >> >> Signed-off-by: Abdul Rauf >> --- >> drivers/staging/unisys/visorbus/visorchipset.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c >> b/drivers/staging/unisys/visorbus/visorchipset.c >> index 336af52d43d7..4e630ea527e8 100644 >> --- a/drivers/staging/unisys/visorbus/visorchipset.c >> +++ b/drivers/staging/unisys/visorbus/visorchipset.c >> @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct >> controlvm_message *inmsg) >> * >> * devices are automatically enabled at >> * initialization. >> -*/ >> + */ >> parahotplug_request_kickoff(req); >> controlvm_respond_physdev_changestate >> (&inmsg->hdr, >> -- >> 2.11.0 you should use both of them. I am sending both again by changing their names. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: unisys: fix checkpatch block comments warning
> -Original Message- > From: Abdul Rauf Mujahid [mailto:abdulraufmuja...@gmail.com] > Sent: Tuesday, January 10, 2017 6:51 PM > To: Kershner, David A ; > gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer > > Cc: de...@driverdev.osuosl.org > Subject: Re: [PATCH] staging: unisys: fix checkpatch block comments warning > > > > On 01/10/2017 06:36 PM, Kershner, David A wrote: > >> -Original Message- > >> From: Abdul Rauf [mailto:abdulraufmuja...@gmail.com] > >> Sent: Tuesday, January 10, 2017 6:24 PM > >> To: gre...@linuxfoundation.org; j...@redhat.com; *S-Par-Maintainer > >> > >> Cc: de...@driverdev.osuosl.org > >> Subject: [PATCH] staging: unisys: fix checkpatch block comments warning > > This patch has the same subject line as the previous patch? Which one > > should we use? Or can you make the names unique? > > > > David Kershner > > > >> Fix the following warnings: > >> Block comments should align the * on each line > >> > >> Signed-off-by: Abdul Rauf > >> --- > >> drivers/staging/unisys/visorbus/visorchipset.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c > >> b/drivers/staging/unisys/visorbus/visorchipset.c > >> index 336af52d43d7..4e630ea527e8 100644 > >> --- a/drivers/staging/unisys/visorbus/visorchipset.c > >> +++ b/drivers/staging/unisys/visorbus/visorchipset.c > >> @@ -1409,7 +1409,7 @@ parahotplug_process_message(struct > >> controlvm_message *inmsg) > >> * > >> * devices are automatically enabled at > >> * initialization. > >> - */ > >> + */ > >>parahotplug_request_kickoff(req); > >>controlvm_respond_physdev_changestate > >>(&inmsg->hdr, > >> -- > >> 2.11.0 > you should use both of them. I am sending both again by changing their > names. Thanks! David Kershner ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: fix checkpatch braces not necessary warning
Fix the following warnings:
braces {} are not necessary for any arm of this statement
Signed-off-by: Abdul Rauf
---
drivers/staging/greybus/loopback.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 3184dd3999b5..5ede67fcdd61 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1037,13 +1037,12 @@ static int gb_loopback_fn(void *data)
/* Else operations to perform */
if (gb->async) {
- if (type == GB_LOOPBACK_TYPE_PING) {
+ if (type == GB_LOOPBACK_TYPE_PING)
error = gb_loopback_async_ping(gb);
- } else if (type == GB_LOOPBACK_TYPE_TRANSFER) {
+ else if (type == GB_LOOPBACK_TYPE_TRANSFER)
error = gb_loopback_async_transfer(gb, size);
- } else if (type == GB_LOOPBACK_TYPE_SINK) {
+ else if (type == GB_LOOPBACK_TYPE_SINK)
error = gb_loopback_async_sink(gb, size);
- }
if (error)
gb->error++;
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: loopback_test: fix checkpatch bad function definition error
Fix the following Errors:
Bad function definition - void abort() should probably be void abort(void)
Signed-off-by: Abdul Rauf
---
drivers/staging/greybus/tools/loopback_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/tools/loopback_test.c
b/drivers/staging/greybus/tools/loopback_test.c
index f7f4cd6fb55b..5312b2aa32f1 100644
--- a/drivers/staging/greybus/tools/loopback_test.c
+++ b/drivers/staging/greybus/tools/loopback_test.c
@@ -168,7 +168,7 @@ GET_AVG(latency_avg);
GET_AVG(apbridge_unipro_latency_avg);
GET_AVG(gbphy_firmware_latency_avg);
-void abort()
+void abort(void)
{
_exit(1);
}
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android/ion: Fix coding style issues
Fix following checkpatch warnings:
- Lines over 80 characters
- void function with return statement
- Unaligned comment mark
- Header function prototypes missing variable names
Sent against staging-next.
Signed-off-by: Bogdan Purcareata
---
drivers/staging/android/ion/ion-ioctl.c | 3 ++-
drivers/staging/android/ion/ion_of.c| 1 -
drivers/staging/android/ion/ion_priv.h | 40
-
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..e28fffb 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -111,7 +111,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
struct ion_handle *handle;
mutex_lock(&client->lock);
- handle = ion_handle_get_by_id_nolock(client,
data.handle.handle);
+ handle = ion_handle_get_by_id_nolock(client,
+ data.handle.handle);
if (IS_ERR(handle)) {
mutex_unlock(&client->lock);
return PTR_ERR(handle);
diff --git a/drivers/staging/android/ion/ion_of.c
b/drivers/staging/android/ion/ion_of.c
index 46b2bb9..7791c70 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -161,7 +161,6 @@ static int rmem_ion_device_init(struct reserved_mem
*rmem, struct device *dev)
static void rmem_ion_device_release(struct reserved_mem *rmem,
struct device *dev)
{
- return;
}
static const struct reserved_mem_ops rmem_dma_ops = {
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion_priv.h
index 3c3b324..444a1a1 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -54,7 +54,7 @@
* handle, used for debugging
* @pid: pid of last client to reference this buffer in a
* handle, used for debugging
-*/
+ */
struct ion_buffer {
struct kref ref;
union {
@@ -287,10 +287,10 @@ void ion_device_add_heap(struct ion_device *dev,
struct ion_heap *heap);
* some helpers for common operations on buffers using the sg_table
-void *ion_heap_map_kernel(struct ion_heap *, struct ion_buffer *);
-void ion_heap_unmap_kernel(struct ion_heap *, struct ion_buffer *);
-int ion_heap_map_user(struct ion_heap *, struct ion_buffer *,
- struct vm_area_struct *);
+void *ion_heap_map_kernel(struct ion_heap *heap, struct ion_buffer
*buffer);
+void ion_heap_unmap_kernel(struct ion_heap *heap, struct ion_buffer
*buffer);
+int ion_heap_map_user(struct ion_heap *heap, struct ion_buffer *buffer,
+ struct vm_area_struct *vma);
int ion_heap_buffer_zero(struct ion_buffer *buffer);
int ion_heap_pages_zero(struct page *page, size_t size, pgprot_t pgprot);
@@ -371,21 +371,21 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
* heaps as appropriate.
*/
-struct ion_heap *ion_heap_create(struct ion_platform_heap *);
-void ion_heap_destroy(struct ion_heap *);
-struct ion_heap *ion_system_heap_create(struct ion_platform_heap *);
-void ion_system_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
+void ion_heap_destroy(struct ion_heap *heap);
+struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
+void ion_system_heap_destroy(struct ion_heap *heap);
-struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *);
-void ion_system_contig_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap
*heap);
+void ion_system_contig_heap_destroy(struct ion_heap *heap);
-struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *);
-void ion_carveout_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap
*heap_data);
+void ion_carveout_heap_destroy(struct ion_heap *heap);
-struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *);
-void ion_chunk_heap_destroy(struct ion_heap *);
-struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *);
-void ion_cma_heap_destroy(struct ion_heap *);
+struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap
*heap_data);
+void ion_chunk_heap_destroy(struct ion_heap *heap);
+struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
+void ion_cma_heap_destroy(struct ion_heap *heap);
/**
* functions for creating and destroying a heap pool -- allows you
@@ -427,9 +427,9 @@ struct ion_page_pool {
struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned
int order,
bool cached);
-void ion_page_pool_destroy(struct ion_page_pool *);
-struct page *ion_pag
Re: [PATCH] staging: android/ion: Fix coding style issues
On Tue, Jan 10, 2017 at 11:40:30PM +0200, Bogdan Purcareata wrote: > Fix following checkpatch warnings: > - Lines over 80 characters > - void function with return statement > - Unaligned comment mark > - Header function prototypes missing variable names > > Sent against staging-next. > > Signed-off-by: Bogdan Purcareata > --- > drivers/staging/android/ion/ion-ioctl.c | 3 ++- > drivers/staging/android/ion/ion_of.c| 1 - > drivers/staging/android/ion/ion_priv.h | 40 > - Your patch is line-wrapped and can't be applied :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android/ion: Fix coding style issues
On Tue, 2017-01-10 at 23:40 +0200, Bogdan Purcareata wrote: > Fix following checkpatch warnings: > - Lines over 80 characters > - void function with return statement > - Unaligned comment mark > - Header function prototypes missing variable names Please read Documentation/SubmittingPatches (umm, make that Documentation/process/submitting-patches.rst) Make sure to send the patch to yourself only until you know you can apply it correctly and then send it to the mailing list. btw: This should probably be a series of 4 patches, each single patch doing one of the things listed above. And do please use checkpatch on your proposed patches. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: Correct coding style issues.
Add character '*' in all lines of the block comments. Also remove one unnecessary line. Signed-off-by: Javier Rodriguez --- drivers/staging/rtl8192u/r8180_93cx6.h | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/drivers/staging/rtl8192u/r8180_93cx6.h b/drivers/staging/rtl8192u/r8180_93cx6.h index 9cf7f58..643d465 100644 --- a/drivers/staging/rtl8192u/r8180_93cx6.h +++ b/drivers/staging/rtl8192u/r8180_93cx6.h @@ -1,17 +1,17 @@ /* - This is part of rtl8187 OpenSource driver - Copyright (C) Andrea Merello 2004-2005 - Released under the terms of GPL (General Public Licence) - - Parts of this driver are based on the GPL part of the - official realtek driver - Parts of this driver are based on the rtl8180 driver skeleton - from Patric Schenke & Andres Salomon - Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver - - We want to thank the Authors of such projects and the Ndiswrapper - project Authors. -*/ + * This is part of rtl8187 OpenSource driver + * Copyright (C) Andrea Merello 2004-2005 + * Released under the terms of GPL (General Public Licence) + * + * Parts of this driver are based on the GPL part of the + * official realtek driver + * Parts of this driver are based on the rtl8180 driver skeleton + * from Patric Schenke & Andres Salomon + * Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver + * + * We want to thank the Authors of such projects and the Ndiswrapper + * project Authors. + */ /*This files contains card eeprom (93c46 or 93c56) programming routines*/ /*memory is addressed by WORDS*/ @@ -39,5 +39,4 @@ #define EPROM_TXPW2 0x1b #define EPROM_TXPW1 0x3d - int eprom_read(struct net_device *dev, u32 addr); /* reads a 16 bits word */ -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: most: hdm-usb: Fix mismatch between types used in sizeof operator
Fixed mismatch between types used in sizeof operator.
Signed-off-by: Eric Salem
---
drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c
b/drivers/staging/most/hdm-usb/hdm_usb.c
index 8a6da16..01e3a31 100644
--- a/drivers/staging/most/hdm-usb/hdm_usb.c
+++ b/drivers/staging/most/hdm-usb/hdm_usb.c
@@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
{
int retval;
- __le16 *dma_buf = kzalloc(sizeof(__le16), GFP_KERNEL);
+ __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
if (!dma_buf)
@@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16
reg, u16 *buf)
retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
DRCI_READ_REQ, req_type,
0x,
-reg, dma_buf, sizeof(u16), 5 * HZ);
+reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
*buf = le16_to_cpu(*dma_buf);
kfree(dma_buf);
--
2.9.3
On 01/10/2017 10:40 AM, Greg KH wrote:
> On Mon, Jan 09, 2017 at 09:25:56PM -0600, Eric Salem wrote:
>> Fixed the following sparse warning:
>>
>> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
>> cast to restricted __le16
>>
>> by correcting the variable's type (also updated sizeof).
>>
>> Signed-off-by: Eric Salem
>> Acked-by: Christian Gromm
>> ---
>> drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> This patch doesn't apply against linux-next, can you refresh it and
> resend?
>
> thanks,
>
> greg k-h
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 9/9] treewide: Inline ib_dma_map_*() functions
Almost all changes in this patch except the removal of local variables
that became superfluous and the actual removal of the ib_dma_map_*()
functions have been generated as follows:
git grep -lE 'ib_(sg_|)dma_' |
xargs -d\\n \
sed -i -e
's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\&\([^,]\+\),/\1dma_\2(\3.dma_device,/g' \
-e
's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\([^,]\+\),/\1dma_\2(\3->dma_device,/g' \
-e 's/ib_sg_dma_\(len\|address\)(\([^,]\+\), /sg_dma_\1(/g'
Signed-off-by: Bart Van Assche
Reviewed-by: Christoph Hellwig
Cc: Andreas Dilger
Cc: Anna Schumaker
Cc: David S. Miller
Cc: Eric Van Hensbergen
Cc: James Simmons
Cc: Latchesar Ionkov
Cc: Oleg Drokin
Cc: Ron Minnich
Cc: Trond Myklebust
Cc: de...@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Cc: linux-n...@lists.infradead.org
Cc: linux-r...@vger.kernel.org
Cc: lustre-de...@lists.lustre.org
Cc: net...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Cc: target-de...@vger.kernel.org
Cc: v9fs-develo...@lists.sourceforge.net
---
drivers/infiniband/core/mad.c | 28 +--
drivers/infiniband/core/rw.c | 30 ++-
drivers/infiniband/core/umem.c | 4 +-
drivers/infiniband/core/umem_odp.c | 6 +-
drivers/infiniband/hw/mlx4/cq.c| 2 +-
drivers/infiniband/hw/mlx4/mad.c | 28 +--
drivers/infiniband/hw/mlx4/mr.c| 4 +-
drivers/infiniband/hw/mlx4/qp.c| 10 +-
drivers/infiniband/hw/mlx5/mr.c| 4 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c| 20 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c| 22 +--
drivers/infiniband/ulp/iser/iscsi_iser.c | 6 +-
drivers/infiniband/ulp/iser/iser_initiator.c | 38 ++--
drivers/infiniband/ulp/iser/iser_memory.c | 12 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
drivers/infiniband/ulp/isert/ib_isert.c| 60 +++---
drivers/infiniband/ulp/srp/ib_srp.c| 50 +++--
drivers/infiniband/ulp/srpt/ib_srpt.c | 10 +-
drivers/nvme/host/rdma.c | 22 +--
drivers/nvme/target/rdma.c | 20 +-
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 14 +-
include/rdma/ib_verbs.h| 218 -
net/9p/trans_rdma.c| 12 +-
net/rds/ib.h | 39
net/rds/ib_cm.c| 18 +-
net/rds/ib_fmr.c | 10 +-
net/rds/ib_frmr.c | 8 +-
net/rds/ib_rdma.c | 6 +-
net/rds/ib_recv.c | 14 +-
net/rds/ib_send.c | 28 +--
net/sunrpc/xprtrdma/fmr_ops.c | 6 +-
net/sunrpc/xprtrdma/frwr_ops.c | 6 +-
net/sunrpc/xprtrdma/rpc_rdma.c | 14 +-
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 4 +-
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c| 8 +-
net/sunrpc/xprtrdma/svc_rdma_sendto.c | 14 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 8 +-
net/sunrpc/xprtrdma/verbs.c| 8 +-
38 files changed, 275 insertions(+), 538 deletions(-)
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index a009f7132c73..2d51f0bdc13f 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1152,21 +1152,21 @@ int ib_send_mad(struct ib_mad_send_wr_private
*mad_send_wr)
mad_agent = mad_send_wr->send_buf.mad_agent;
sge = mad_send_wr->sg_list;
- sge[0].addr = ib_dma_map_single(mad_agent->device,
+ sge[0].addr = dma_map_single(mad_agent->device->dma_device,
mad_send_wr->send_buf.mad,
sge[0].length,
DMA_TO_DEVICE);
- if (unlikely(ib_dma_mapping_error(mad_agent->device, sge[0].addr)))
+ if (unlikely(dma_mapping_error(mad_agent->device->dma_device,
sge[0].addr)))
return -ENOMEM;
mad_send_wr->header_mapping = sge[0].addr;
- sge[1].addr = ib_dma_map_single(mad_agent->device,
+ sge[1].addr = dma_map_single(mad_agent->device->dma_device,
ib_get_payload(mad_send_wr),
sge[1].length,
DMA_TO_DEVICE);
- if (unlikely(ib_dma_mapping_error(mad_agent->device, sge[1].addr))) {
- ib_dma_unmap_single(mad_agent->device,
+ if (unlikely(dma_mapping_error(mad_agent->device->dma_device,
sge[1].addr))) {
+ dma_unmap_single(mad_agent->device->dma_device,
mad_send_wr-
Re: [PATCH] staging: greybus: fix checkpatch braces not necessary warning
On Wed, Jan 11, 2017 at 6:25 AM, Abdul Rauf wrote:
> Fix the following warnings:
> braces {} are not necessary for any arm of this statement
>
> Signed-off-by: Abdul Rauf
> ---
> drivers/staging/greybus/loopback.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: loopback_test: fix checkpatch bad function definition error
On Wed, Jan 11, 2017 at 6:59 AM, Abdul Rauf wrote: > Fix the following Errors: > Bad function definition - void abort() should probably be void abort(void) > > Signed-off-by: Abdul Rauf > --- > drivers/staging/greybus/tools/loopback_test.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Viresh Kumar ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:vt6656:mac.c Aligned to match open parenthesis
Fixes checkpatch warning: Alignment should match open parenthesis Signed-off-by: Scott Matheina --- drivers/staging/vt6656/mac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c index 86d98bc..417fdad 100644 --- a/drivers/staging/vt6656/mac.c +++ b/drivers/staging/vt6656/mac.c @@ -169,8 +169,8 @@ void vnt_mac_write_word(struct vnt_private *priv, u8 reg_ofs, u16 word) data[0] = (u8)(word & 0xff); data[1] = (u8)(word >> 8); - vnt_control_out(priv, MESSAGE_TYPE_WRITE, - reg_ofs, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data); + vnt_control_out(priv, MESSAGE_TYPE_WRITE, reg_ofs, + MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data); } void vnt_mac_set_bssid_addr(struct vnt_private *priv, u8 *addr) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: Fix sparse warnings about endianness
Fixed sparse warnings about endianness. E.g.:
warning: cast to restricted __le16
Signed-off-by: Eric Salem
---
drivers/staging/wlan-ng/hfa384x.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 60caf9c3..5f1851c 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1388,13 +1388,13 @@ static inline int hfa384x_drvr_getconfig16(struct
hfa384x *hw, u16 rid, void *va
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
- *((u16 *)val) = le16_to_cpu(*((u16 *)val));
+ le16_to_cpus(val);
return result;
}
static inline int hfa384x_drvr_setconfig16(struct hfa384x *hw, u16 rid, u16
val)
{
- u16 value = cpu_to_le16(val);
+ __le16 value = cpu_to_le16(val);
return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
}
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: Correct coding style issues.
On Tue, Jan 10, 2017 at 11:23:20PM +0100, Javier Rodriguez wrote: > Add character '*' in all lines of the block comments. > Also remove one unnecessary line. When you have to say "also", that's a huge hint that you need to break the patch up into different patches. Please do so here and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
