Re: [driver-core:debugfs_remove_return_value 2/8] drivers/net/wireless/broadcom/b43/debugfs.c:661:28: error: void value not ignored as it ought to be
On Thu, Feb 18, 2021 at 05:58:41AM +0800, kernel test robot wrote: > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > debugfs_remove_return_value > head: 5187c2360ee1d023078e4302dad32fda1e895772 > commit: 72f2bf74b31aae983fb200aa7e84a05943bf27fc [2/8] debugfs: remove return > value of debugfs_create_bool() > config: x86_64-randconfig-c002-20210216 (attached as .config) > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 > reproduce (this is a W=1 build): > # > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=72f2bf74b31aae983fb200aa7e84a05943bf27fc > git remote add driver-core > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > git fetch --no-tags driver-core debugfs_remove_return_value > git checkout 72f2bf74b31aae983fb200aa7e84a05943bf27fc > # save the attached .config to linux build tree > make W=1 ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot You are working with an old tree, this was fixed 2 days ago, no need to keep emailing me about this :( greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: cast to (void __user *)
On Thu, Feb 18, 2021 at 08:10:28AM +0100, Greg KH wrote: > On Thu, Feb 18, 2021 at 11:58:40AM +0530, Atul Gopinathan wrote: > > Resolve the following sparse warning: > > drivers/staging//comedi/comedi_fops.c:2983:41: warning: incorrect type in > > argument 1 (different address spaces) > > drivers/staging//comedi/comedi_fops.c:2983:41:expected void [noderef] > > *uptr > > drivers/staging//comedi/comedi_fops.c:2983:41:got unsigned int *chanlist > > > > cmd->chanlist is of type (unsigned int *) as defined in > > "struct comedi_cmd" in file drivers/staging/comedi/comedi.h > > > > The function "ptr_to_compat()" expects argument of type > > (void __user *) as defined in include/linux/compat.h > > > > Signed-off-by: Atul Gopinathan > > --- > > drivers/staging/comedi/comedi_fops.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Is this different from your previous patch: > https://lore.kernel.org/r/20210217165907.9777-1-atulgopinat...@gmail.com > > if so, you might need a better subject line here, and for that one, as > they look alike at a quick glance. > > Which one goes first? > > Can you resend both of these as a patch series with better subjects as a > v2 patch set? Sure! That subject line was a terrible result of me trying really hard to make it concise and fit within git's recommended 50 character limit for commit headings. I will make sure to prioritize on quality more. :D Thanks for the feedback! Atul ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
Fix the following warning generated by sparse: drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in assignment (different address spaces) drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int *chanlist drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef] * compat_ptr() has a return type of "void __user *" as defined in "include/linux/compat.h" cmd->chanlist is of type "unsigned int *" as defined in drivers/staging/comedi/comedi.h" in struct comedi_cmd. Signed-off-by: Atul Gopinathan --- drivers/staging/comedi/comedi_fops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index e85a99b68f31..fc4ec38012b4 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd, cmd->scan_end_arg = v32.scan_end_arg; cmd->stop_src = v32.stop_src; cmd->stop_arg = v32.stop_arg; - cmd->chanlist = compat_ptr(v32.chanlist); + cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist); cmd->chanlist_len = v32.chanlist_len; cmd->data = compat_ptr(v32.data); cmd->data_len = v32.data_len; -- 2.27.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: comedi: cast function argument to expected type (void __user *)
Resolve the following sparse warning: drivers/staging//comedi/comedi_fops.c:2983:41: warning: incorrect type in argument 1 (different address spaces) drivers/staging//comedi/comedi_fops.c:2983:41:expected void [noderef] *uptr drivers/staging//comedi/comedi_fops.c:2983:41:got unsigned int *chanlist cmd->chanlist is of type (unsigned int *) as defined in "struct comedi_cmd" in file drivers/staging/comedi/comedi.h The function "ptr_to_compat()" expects argument of type (void __user *) as defined in include/linux/compat.h Signed-off-by: Atul Gopinathan --- drivers/staging/comedi/comedi_fops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index fc4ec38012b4..8b2672c3c408 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -2980,7 +2980,7 @@ static int put_compat_cmd(struct comedi32_cmd_struct __user *cmd32, v32.stop_src = cmd->stop_src; v32.stop_arg = cmd->stop_arg; /* Assume chanlist pointer is unchanged. */ - v32.chanlist = ptr_to_compat(cmd->chanlist); + v32.chanlist = ptr_to_compat((void __user *)cmd->chanlist); v32.chanlist_len = cmd->chanlist_len; v32.data = ptr_to_compat(cmd->data); v32.data_len = cmd->data_len; -- 2.27.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax/i2400m: don't change the endianness of one byte variable
It is wrong to change the endianness of a variable which has just one
byte size.
Sparse warnings fixed:
drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
__le32
drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
__le32
drivers/staging//wimax/i2400m/op-rfkill.c:159:14: warning: cast to restricted
__le32
drivers/staging//wimax/i2400m/op-rfkill.c:160:14: warning: cast to restricted
__le32
Signed-off-by: Muhammad Usama Anjum
---
drivers/staging/wimax/i2400m/control.c | 4 ++--
drivers/staging/wimax/i2400m/op-rfkill.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/control.c
b/drivers/staging/wimax/i2400m/control.c
index 1e270b2101e8..b6b2788af162 100644
--- a/drivers/staging/wimax/i2400m/control.c
+++ b/drivers/staging/wimax/i2400m/control.c
@@ -452,8 +452,8 @@ void i2400m_report_state_parse_tlv(struct i2400m *i2400m,
d_printf(2, dev, "%s: RF status TLV "
"found (0x%04x), sw 0x%02x hw 0x%02x\n",
tag, I2400M_TLV_RF_STATUS,
-le32_to_cpu(rfss->sw_rf_switch),
-le32_to_cpu(rfss->hw_rf_switch));
+rfss->sw_rf_switch,
+rfss->hw_rf_switch);
i2400m_report_tlv_rf_switches_status(i2400m, rfss);
}
if (0 == i2400m_tlv_match(tlv, I2400M_TLV_MEDIA_STATUS, sizeof(*ms))) {
diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c
b/drivers/staging/wimax/i2400m/op-rfkill.c
index fbddf2e18c14..a159808f0ec2 100644
--- a/drivers/staging/wimax/i2400m/op-rfkill.c
+++ b/drivers/staging/wimax/i2400m/op-rfkill.c
@@ -156,8 +156,8 @@ void i2400m_report_tlv_rf_switches_status(
enum i2400m_rf_switch_status hw, sw;
enum wimax_st wimax_state;
- sw = le32_to_cpu(rfss->sw_rf_switch);
- hw = le32_to_cpu(rfss->hw_rf_switch);
+ sw = rfss->sw_rf_switch;
+ hw = rfss->hw_rf_switch;
d_fnstart(3, dev, "(i2400m %p rfss %p [hw %u sw %u])\n",
i2400m, rfss, hw, sw);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vc04_services: Fixed address type mismatch in vchiq_arm.c
On Thu, Feb 18, 2021 at 02:40:15PM +0530, Pritthijit Nath wrote: > This change fixes a sparse address type mismatch warning "incorrect type > in assignment (different address spaces)". > > Signed-off-by: Pritthijit Nath > --- > .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > index 59e45dc03a97..3c715b926a57 100644 > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > @@ -1214,11 +1214,7 @@ static int vchiq_ioc_await_completion(struct > vchiq_instance *instance, > !instance->use_close_delivered) > unlock_service(service); > > - /* > - * FIXME: address space mismatch, does bulk_userdata > - * actually point to user or kernel memory? > - */ > - user_completion.bulk_userdata = completion->bulk_userdata; > + user_completion.bulk_userdata = (void __user > *)completion->bulk_userdata; So, this pointer really is user memory? How did you determine that? If so, why isn't this a __user * in the first place? You can't just paper over the FIXME by doing a cast without doing the real work here, otherwise someone wouldn't have written the FIXME :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax/i2400m: don't change the endianness of one byte variable
On Thu, Feb 18, 2021 at 02:21:54PM +0500, Muhammad Usama Anjum wrote:
> It is wrong to change the endianness of a variable which has just one
> byte size.
>
> Sparse warnings fixed:
> drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
> __le32
> drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
> __le32
> drivers/staging//wimax/i2400m/op-rfkill.c:159:14: warning: cast to restricted
> __le32
> drivers/staging//wimax/i2400m/op-rfkill.c:160:14: warning: cast to restricted
> __le32
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> drivers/staging/wimax/i2400m/control.c | 4 ++--
> drivers/staging/wimax/i2400m/op-rfkill.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/wimax/i2400m/control.c
> b/drivers/staging/wimax/i2400m/control.c
> index 1e270b2101e8..b6b2788af162 100644
> --- a/drivers/staging/wimax/i2400m/control.c
> +++ b/drivers/staging/wimax/i2400m/control.c
> @@ -452,8 +452,8 @@ void i2400m_report_state_parse_tlv(struct i2400m *i2400m,
> d_printf(2, dev, "%s: RF status TLV "
>"found (0x%04x), sw 0x%02x hw 0x%02x\n",
>tag, I2400M_TLV_RF_STATUS,
> - le32_to_cpu(rfss->sw_rf_switch),
> - le32_to_cpu(rfss->hw_rf_switch));
> + rfss->sw_rf_switch,
> + rfss->hw_rf_switch);
What do you mean by "one byte"? This is a le32 sized variable, right?
If not, why isn't the le32_to_cpu() call complaining?
> i2400m_report_tlv_rf_switches_status(i2400m, rfss);
> }
> if (0 == i2400m_tlv_match(tlv, I2400M_TLV_MEDIA_STATUS, sizeof(*ms))) {
> diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c
> b/drivers/staging/wimax/i2400m/op-rfkill.c
> index fbddf2e18c14..a159808f0ec2 100644
> --- a/drivers/staging/wimax/i2400m/op-rfkill.c
> +++ b/drivers/staging/wimax/i2400m/op-rfkill.c
> @@ -156,8 +156,8 @@ void i2400m_report_tlv_rf_switches_status(
> enum i2400m_rf_switch_status hw, sw;
> enum wimax_st wimax_state;
>
> - sw = le32_to_cpu(rfss->sw_rf_switch);
> - hw = le32_to_cpu(rfss->hw_rf_switch);
> + sw = rfss->sw_rf_switch;
> + hw = rfss->hw_rf_switch;
Same here.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
World Covid-19 Support Program (WCSP).
World Covid-19 Support Program (WCSP). Covid Award Number: #865443009766COVID Approval Number: RU/USA/COVID/097666 Batch Number: #8776/20990976/COVID OFFICIAL NOTIFICATION: Because of the corona-virus pandemic accelerates, killing thousands of people everyday, Russian and United States Of America, brought out EUR.955 billion for its urgent push to reduce the risk and help to impact on COVID-19 outbreaks in the world. We wish to officially announce to you that your name was selected as a beneficiary, You have been awarded the sum of EUR.5,000,000.00 (Five Million Euro), For the 2021 Russian/USA World Covid-19 Global Humanitarian support program. Your personal Covid Award Number is: #865443009766COVID. General Payment Terms And Conditions (GPTCs): Your fund will be released to you through any of our regional payment banks within Europe, your file will be processed simultaneously, as directed by the authority. You are to contact the procession department through the Coordinator, Email: coordinatorad...@yahoo.com You have to send these following information's to the procession department, through the General Coordinator (Prof.Adrik Tolinyev) for further procession: ** Full Name: ** Address: ** Date of birth: ** Age: ** Tel No: ** Occupation: ** Sex: ** Country: ** Covid Award Number: #865443009766COVID Be assured that your award fund of EUR.5,000,000.00 (Five Million Euro), is available to be released to you. Thanks for keeping your social distance ! Yours in service, Prof.Adrik Tolinyev. Email: coordinatorad...@yahoo.com (General Coordinator). ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax/i2400m: don't change the endianness of one byte variable
On Thu, 2021-02-18 at 10:40 +0100, Greg KH wrote:
> On Thu, Feb 18, 2021 at 02:21:54PM +0500, Muhammad Usama Anjum wrote:
> > It is wrong to change the endianness of a variable which has just one
> > byte size.
> >
> > Sparse warnings fixed:
> > drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
> > __le32
> > drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to restricted
> > __le32
> > drivers/staging//wimax/i2400m/op-rfkill.c:159:14: warning: cast to
> > restricted __le32
> > drivers/staging//wimax/i2400m/op-rfkill.c:160:14: warning: cast to
> > restricted __le32
> >
> > Signed-off-by: Muhammad Usama Anjum
> > ---
> > drivers/staging/wimax/i2400m/control.c | 4 ++--
> > drivers/staging/wimax/i2400m/op-rfkill.c | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/wimax/i2400m/control.c
> > b/drivers/staging/wimax/i2400m/control.c
> > index 1e270b2101e8..b6b2788af162 100644
> > --- a/drivers/staging/wimax/i2400m/control.c
> > +++ b/drivers/staging/wimax/i2400m/control.c
> > @@ -452,8 +452,8 @@ void i2400m_report_state_parse_tlv(struct i2400m
> > *i2400m,
> > d_printf(2, dev, "%s: RF status TLV "
> > "found (0x%04x), sw 0x%02x hw 0x%02x\n",
> > tag, I2400M_TLV_RF_STATUS,
> > -le32_to_cpu(rfss->sw_rf_switch),
> > -le32_to_cpu(rfss->hw_rf_switch));
> > +rfss->sw_rf_switch,
> > +rfss->hw_rf_switch);
>
> What do you mean by "one byte"? This is a le32 sized variable, right?
> If not, why isn't the le32_to_cpu() call complaining?
These two variables are of type _u8, one byte.
__u8 sw_rf_switch;
__u8 hw_rf_switch;
They aren't of type __le32. le32_to_cpu() macro should have
complained. But it isn't complaining. It seems like whatever we pass
to this macro, it casts it to __le32 forcefully (it seems like wrong).
So we'll never get any complain from this macro directly. But we are
getting complain from the sparse.
For big endian:
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
For little endian:
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
> > i2400m_report_tlv_rf_switches_status(i2400m, rfss);
> > }
> > if (0 == i2400m_tlv_match(tlv, I2400M_TLV_MEDIA_STATUS, sizeof(*ms))) {
> > diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c
> > b/drivers/staging/wimax/i2400m/op-rfkill.c
> > index fbddf2e18c14..a159808f0ec2 100644
> > --- a/drivers/staging/wimax/i2400m/op-rfkill.c
> > +++ b/drivers/staging/wimax/i2400m/op-rfkill.c
> > @@ -156,8 +156,8 @@ void i2400m_report_tlv_rf_switches_status(
> > enum i2400m_rf_switch_status hw, sw;
> > enum wimax_st wimax_state;
> >
> > - sw = le32_to_cpu(rfss->sw_rf_switch);
> > - hw = le32_to_cpu(rfss->hw_rf_switch);
> > + sw = rfss->sw_rf_switch;
> > + hw = rfss->hw_rf_switch;
>
> Same here.
Same here.
> thanks,
>
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: comedi: Fixed side effects from macro definition.
On 17/02/2021 14:20, chakravarthikulkarni wrote:
Warning found by checkpatch.pl script.
Signed-off-by: chakravarthikulkarni
---
drivers/staging/comedi/comedi.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index b5d00a006dbb..b2af6a88d389 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -1103,9 +1103,12 @@ enum ni_common_signal_names {
/* *** END GLOBALLY-NAMED NI TERMINALS/SIGNALS *** */
-#define NI_USUAL_PFI_SELECT(x) (((x) < 10) ? (0x1 + (x)) : (0xb + (x)))
-#define NI_USUAL_RTSI_SELECT(x)(((x) < 7) ? (0xb + (x)) : 0x1b)
-
+#define NI_USUAL_PFI_SELECT(x) \
+ ({ typeof(x) _x = x; \
+(((_x) < 10) ? (0x1 + (_x)) : (0xb + (_x))); })
+#define NI_USUAL_RTSI_SELECT(x)\
+ ({ typeof(x) _x = x; \
+(((_x) < 7) ? (0xb + (_x)) : 0x1b); })
/*
* mode bits for NI general-purpose counters, set with
* INSN_CONFIG_SET_COUNTER_MODE
I'd rather not do that because this is intended to be a userspace
header. This change adds GCC extensions and prohibits the use of the
macros in constant expressions.
--
-=( Ian Abbott || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fwserial: Fix alignment of function parameters
This patch fixes the following checkpatch.pl check:
CHECK: Alignment should match open parenthesis
Signed-off-by: Prakash Dubey
---
drivers/staging/fwserial/fwserial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index c368082aae1a..a92741b8b6c6 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -1318,8 +1318,8 @@ static int fwtty_break_ctl(struct tty_struct *tty, int
state)
if (state == -1) {
set_bit(STOP_TX, &port->flags);
ret = wait_event_interruptible_timeout(port->wait_tx,
- !test_bit(IN_TX, &port->flags),
- 10);
+ !test_bit(IN_TX,
&port->flags),
+ 10);
if (ret == 0 || ret == -ERESTARTSYS) {
clear_bit(STOP_TX, &port->flags);
fwtty_restart_tx(port);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On 18/02/2021 08:44, Atul Gopinathan wrote:
Fix the following warning generated by sparse:
drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in
assignment (different address spaces)
drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
*chanlist
drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef] *
compat_ptr() has a return type of "void __user *"
as defined in "include/linux/compat.h"
cmd->chanlist is of type "unsigned int *" as defined
in drivers/staging/comedi/comedi.h" in struct
comedi_cmd.
Signed-off-by: Atul Gopinathan
---
drivers/staging/comedi/comedi_fops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index e85a99b68f31..fc4ec38012b4 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
cmd->scan_end_arg = v32.scan_end_arg;
cmd->stop_src = v32.stop_src;
cmd->stop_arg = v32.stop_arg;
- cmd->chanlist = compat_ptr(v32.chanlist);
+ cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
cmd->chanlist_len = v32.chanlist_len;
cmd->data = compat_ptr(v32.data);
cmd->data_len = v32.data_len;
This patch and the other one in your series clash with commit
9d5d041eebe3 ("staging: comedi: comedi_fops.c: added casts to get rid of
sparse warnings") by B K Karthik.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5d041eebe3dcf7591ff7004896c329eb841ca6
--
-=( Ian Abbott || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> On 18/02/2021 08:44, Atul Gopinathan wrote:
> > Fix the following warning generated by sparse:
> >
> > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in
> > assignment (different address spaces)
> > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
> > *chanlist
> > drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef]
> > *
> >
> > compat_ptr() has a return type of "void __user *"
> > as defined in "include/linux/compat.h"
> >
> > cmd->chanlist is of type "unsigned int *" as defined
> > in drivers/staging/comedi/comedi.h" in struct
> > comedi_cmd.
> >
> > Signed-off-by: Atul Gopinathan
> > ---
> > drivers/staging/comedi/comedi_fops.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/comedi/comedi_fops.c
> > b/drivers/staging/comedi/comedi_fops.c
> > index e85a99b68f31..fc4ec38012b4 100644
> > --- a/drivers/staging/comedi/comedi_fops.c
> > +++ b/drivers/staging/comedi/comedi_fops.c
> > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
> > cmd->scan_end_arg = v32.scan_end_arg;
> > cmd->stop_src = v32.stop_src;
> > cmd->stop_arg = v32.stop_arg;
> > - cmd->chanlist = compat_ptr(v32.chanlist);
> > + cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
> > cmd->chanlist_len = v32.chanlist_len;
> > cmd->data = compat_ptr(v32.data);
> > cmd->data_len = v32.data_len;
> >
>
> This patch and the other one in your series clash with commit 9d5d041eebe3
> ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> warnings") by B K Karthik.
Oh I see. Not sure if this is the right place to ask, but which tree and
branch should one work with when messing with the code in staging/
directory? (wanted to avoid such clashes in future)
Thanks,
Atul
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: cast to (unsigned int *)
On 17/02/2021 18:26, Greg KH wrote:
On Wed, Feb 17, 2021 at 11:40:00PM +0530, Atul Gopinathan wrote:
On Wed, Feb 17, 2021 at 06:35:15PM +0100, Greg KH wrote:
On Wed, Feb 17, 2021 at 10:29:08PM +0530, Atul Gopinathan wrote:
Resolve the following warning generated by sparse:
drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in
assignment (different address spaces)
drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
*chanlist
drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef] *
compat_ptr() has a return type of "void __user *"
as defined in "include/linux/compat.h"
cmd->chanlist is of type "unsigned int *" as defined
in drivers/staging/comedi/comedi.h" in struct
comedi_cmd.
Signed-off-by: Atul Gopinathan
---
drivers/staging/comedi/comedi_fops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index e85a99b68f31..fc4ec38012b4 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
cmd->scan_end_arg = v32.scan_end_arg;
cmd->stop_src = v32.stop_src;
cmd->stop_arg = v32.stop_arg;
- cmd->chanlist = compat_ptr(v32.chanlist);
+ cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
__force? That feels wrong, something is odd if that is ever needed.
Are you _sure_ this is correct?
The same file has instances of "(usigned int __force *)" cast being
used on the same "cmd->chanlist". For reference:
At line 1797 of comedi_fops.c:
1796 /* restore chanlist pointer before copying back */
1797 cmd->chanlist = (unsigned int __force *)user_chanlist;
1798 cmd->data = NULL;
At line 1880:
1879 /* restore chanlist pointer before copying back */
1880 cmd->chanlist = (unsigned int __force *)user_chanlist;
1881 *copy = true;
Here "user_chanlist" is of type "unsigned int __user *".
Or perhaps, I shouldn't be relying on them?
I don't know, it still feels wrong.
Ian, any thoughts?
It's kind of moot anyway because the patch is outdated. But the reason
for the ___force is that the same `struct comedi_cmd` is used in both
user and kernel contexts. In user contexts, the `chanlist` member
points to user memory and in kernel contexts it points to kernel memory
(copied from userspace).
The sparse tagging of this member has flip-flopped a bit over the years:
* commit 92d0127c9d24 ("Staging: comedi: __user markup on
comedi_fops.c") (May 2010) tagged it as `__user`.
* commit 9be56c643263 ("staging: comedi: comedi.h: remove __user tag
from chanlist") (Sep 2012) removed the `__user` tag.
It is mostly used in a kernel context, for example all the low-level
drivers with `do_cmd` and `do_cmdtest` handlers use it in kernel context.
The alternative would be to have a separate kernel version of this
struct, but it would be mostly identical to the user version apart from
the sparse tagging of this member and perhaps the removal of the unused
`data` and `data_len` members (which need to be kept in the user version
of the struct for compatibility reasons).
--
-=( Ian Abbott || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Fixed incorrect type warning in p80211netdev.c
On Wed, Feb 17, 2021 at 09:12:55PM +0530, Pritthijit Nath wrote: > This change fixes a sparse warning "incorrect type in argument 1 > (different address spaces)". > > Signed-off-by: Pritthijit Nath > --- > drivers/staging/wlan-ng/p80211netdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c > b/drivers/staging/wlan-ng/p80211netdev.c > index 6f9666dc0277..70570e8a5ad2 100644 > --- a/drivers/staging/wlan-ng/p80211netdev.c > +++ b/drivers/staging/wlan-ng/p80211netdev.c > @@ -569,7 +569,7 @@ static int p80211knetdev_do_ioctl(struct net_device *dev, > goto bail; > } > > - msgbuf = memdup_user(req->data, req->len); > + msgbuf = memdup_user((void __user *)req->data, req->len); Probably the correct fix is to just change the type of (struct p80211ioctl_req)->data from caddr_t to "void __user *data;". I haven't looked at this though, so double check. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > Fix the following warning generated by sparse:
> > >
> > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in
> > > assignment (different address spaces)
> > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
> > > *chanlist
> > > drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef]
> > > *
> > >
> > > compat_ptr() has a return type of "void __user *"
> > > as defined in "include/linux/compat.h"
> > >
> > > cmd->chanlist is of type "unsigned int *" as defined
> > > in drivers/staging/comedi/comedi.h" in struct
> > > comedi_cmd.
> > >
> > > Signed-off-by: Atul Gopinathan
> > > ---
> > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > b/drivers/staging/comedi/comedi_fops.c
> > > index e85a99b68f31..fc4ec38012b4 100644
> > > --- a/drivers/staging/comedi/comedi_fops.c
> > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
> > > cmd->scan_end_arg = v32.scan_end_arg;
> > > cmd->stop_src = v32.stop_src;
> > > cmd->stop_arg = v32.stop_arg;
> > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > + cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
> > > cmd->chanlist_len = v32.chanlist_len;
> > > cmd->data = compat_ptr(v32.data);
> > > cmd->data_len = v32.data_len;
> > >
> >
> > This patch and the other one in your series clash with commit 9d5d041eebe3
> > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > warnings") by B K Karthik.
>
> Oh I see. Not sure if this is the right place to ask, but which tree and
> branch should one work with when messing with the code in staging/
> directory? (wanted to avoid such clashes in future)
staging-next is the best one to use from the staging.git tree. But as
the above commit was merged in 5.9-rc1, way back in July of last year, I
have no idea what tree you are currently using to not hit that...
You should always be able to find the subsystem git trees in the
MAINTAINERS file, or if not, just work off of what is in linux-next as
that should have all subsystem's trees merged into it.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > Fix the following warning generated by sparse:
> > > >
> > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type
> > > > in assignment (different address spaces)
> > > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
> > > > *chanlist
> > > > drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef]
> > > > *
> > > >
> > > > compat_ptr() has a return type of "void __user *"
> > > > as defined in "include/linux/compat.h"
> > > >
> > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > in drivers/staging/comedi/comedi.h" in struct
> > > > comedi_cmd.
> > > >
> > > > Signed-off-by: Atul Gopinathan
> > > > ---
> > > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > > b/drivers/staging/comedi/comedi_fops.c
> > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
> > > > cmd->scan_end_arg = v32.scan_end_arg;
> > > > cmd->stop_src = v32.stop_src;
> > > > cmd->stop_arg = v32.stop_arg;
> > > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > > + cmd->chanlist = (unsigned int __force
> > > > *)compat_ptr(v32.chanlist);
> > > > cmd->chanlist_len = v32.chanlist_len;
> > > > cmd->data = compat_ptr(v32.data);
> > > > cmd->data_len = v32.data_len;
> > > >
> > >
> > > This patch and the other one in your series clash with commit 9d5d041eebe3
> > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > warnings") by B K Karthik.
> >
> > Oh I see. Not sure if this is the right place to ask, but which tree and
> > branch should one work with when messing with the code in staging/
> > directory? (wanted to avoid such clashes in future)
>
> staging-next is the best one to use from the staging.git tree. But as
> the above commit was merged in 5.9-rc1, way back in July of last year, I
> have no idea what tree you are currently using to not hit that...
I'm using the staging tree alright, cloned it yesterday. Except I used the
--depth parameter. I believe that is the culprit. How bad a mistake is
that?
(Why depth? I'm currently staying in a remote area where internet
download speeds are less than 100Kbps. I tried a normal git clone of
the staging tree and it's estimated time was more than half a day. Not
to mention, it fails due to loss of connection midway every time)
Thanks!
Atul
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vc04_services: Fixed address type mismatch in vchiq_arm.c
This change fixes a sparse address type mismatch warning "incorrect type
in assignment (different address spaces)".
Signed-off-by: Pritthijit Nath
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 59e45dc03a97..3c715b926a57 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1214,11 +1214,7 @@ static int vchiq_ioc_await_completion(struct
vchiq_instance *instance,
!instance->use_close_delivered)
unlock_service(service);
- /*
-* FIXME: address space mismatch, does bulk_userdata
-* actually point to user or kernel memory?
-*/
- user_completion.bulk_userdata = completion->bulk_userdata;
+ user_completion.bulk_userdata = (void __user
*)completion->bulk_userdata;
if (vchiq_put_completion(args->buf, &user_completion, ret)) {
if (ret == 0)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 06:22:20PM +0530, Atul Gopinathan wrote:
> On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> > On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > > On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > > Fix the following warning generated by sparse:
> > > > >
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect
> > > > > type in assignment (different address spaces)
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned
> > > > > int *chanlist
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef]
> > > > > *
> > > > >
> > > > > compat_ptr() has a return type of "void __user *"
> > > > > as defined in "include/linux/compat.h"
> > > > >
> > > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > > in drivers/staging/comedi/comedi.h" in struct
> > > > > comedi_cmd.
> > > > >
> > > > > Signed-off-by: Atul Gopinathan
> > > > > ---
> > > > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > > > b/drivers/staging/comedi/comedi_fops.c
> > > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd
> > > > > *cmd,
> > > > > cmd->scan_end_arg = v32.scan_end_arg;
> > > > > cmd->stop_src = v32.stop_src;
> > > > > cmd->stop_arg = v32.stop_arg;
> > > > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > > > + cmd->chanlist = (unsigned int __force
> > > > > *)compat_ptr(v32.chanlist);
> > > > > cmd->chanlist_len = v32.chanlist_len;
> > > > > cmd->data = compat_ptr(v32.data);
> > > > > cmd->data_len = v32.data_len;
> > > > >
> > > >
> > > > This patch and the other one in your series clash with commit
> > > > 9d5d041eebe3
> > > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > > warnings") by B K Karthik.
> > >
> > > Oh I see. Not sure if this is the right place to ask, but which tree and
> > > branch should one work with when messing with the code in staging/
> > > directory? (wanted to avoid such clashes in future)
> >
> > staging-next is the best one to use from the staging.git tree. But as
> > the above commit was merged in 5.9-rc1, way back in July of last year, I
> > have no idea what tree you are currently using to not hit that...
>
> I'm using the staging tree alright, cloned it yesterday. Except I used the
> --depth parameter. I believe that is the culprit. How bad a mistake is
> that?
I do not know, I do not use that option, sorry.
> (Why depth? I'm currently staying in a remote area where internet
> download speeds are less than 100Kbps. I tried a normal git clone of
> the staging tree and it's estimated time was more than half a day. Not
> to mention, it fails due to loss of connection midway every time)
If you already have a copy of the kernel git tree, there is never a need
to download the whole thing again. Just add another remote banch and do
a pull, the difference should be very tiny now compared to what is in
Linus's tree.
Or, to seed the whole thing, download a "git bundle" as described here:
https://www.kernel.org/best-way-to-do-linux-clones-for-your-ci.html
which you can use to work off of locally, and should be easier to handle
over slow and flaky download connections.
hope this helps,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 02:46:48PM +0100, Greg KH wrote:
> On Thu, Feb 18, 2021 at 06:22:20PM +0530, Atul Gopinathan wrote:
> > On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> > > On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > > > On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > > > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > > > Fix the following warning generated by sparse:
> > > > > >
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect
> > > > > > type in assignment (different address spaces)
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned
> > > > > > int *chanlist
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23:got void
> > > > > > [noderef] *
> > > > > >
> > > > > > compat_ptr() has a return type of "void __user *"
> > > > > > as defined in "include/linux/compat.h"
> > > > > >
> > > > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > > > in drivers/staging/comedi/comedi.h" in struct
> > > > > > comedi_cmd.
> > > > > >
> > > > > > Signed-off-by: Atul Gopinathan
> > > > > > ---
> > > > > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > > > > b/drivers/staging/comedi/comedi_fops.c
> > > > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd
> > > > > > *cmd,
> > > > > > cmd->scan_end_arg = v32.scan_end_arg;
> > > > > > cmd->stop_src = v32.stop_src;
> > > > > > cmd->stop_arg = v32.stop_arg;
> > > > > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > > > > + cmd->chanlist = (unsigned int __force
> > > > > > *)compat_ptr(v32.chanlist);
> > > > > > cmd->chanlist_len = v32.chanlist_len;
> > > > > > cmd->data = compat_ptr(v32.data);
> > > > > > cmd->data_len = v32.data_len;
> > > > > >
> > > > >
> > > > > This patch and the other one in your series clash with commit
> > > > > 9d5d041eebe3
> > > > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > > > warnings") by B K Karthik.
> > > >
> > > > Oh I see. Not sure if this is the right place to ask, but which tree and
> > > > branch should one work with when messing with the code in staging/
> > > > directory? (wanted to avoid such clashes in future)
> > >
> > > staging-next is the best one to use from the staging.git tree. But as
> > > the above commit was merged in 5.9-rc1, way back in July of last year, I
> > > have no idea what tree you are currently using to not hit that...
> >
> > I'm using the staging tree alright, cloned it yesterday. Except I used the
> > --depth parameter. I believe that is the culprit. How bad a mistake is
> > that?
>
> I do not know, I do not use that option, sorry.
>
> > (Why depth? I'm currently staying in a remote area where internet
> > download speeds are less than 100Kbps. I tried a normal git clone of
> > the staging tree and it's estimated time was more than half a day. Not
> > to mention, it fails due to loss of connection midway every time)
>
> If you already have a copy of the kernel git tree, there is never a need
> to download the whole thing again. Just add another remote banch and do
> a pull, the difference should be very tiny now compared to what is in
> Linus's tree.
>
> Or, to seed the whole thing, download a "git bundle" as described here:
> https://www.kernel.org/best-way-to-do-linux-clones-for-your-ci.html
> which you can use to work off of locally, and should be easier to handle
> over slow and flaky download connections.
>
> hope this helps,
Oh this is great! Will definitely help me. Thanks a lot!
Regards,
Atul
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: comedi: Replaced strlcpy to strscpy
Warning found by checkpath.pl script. Signed-off-by: chakravarthikulkarni --- drivers/staging/comedi/comedi_fops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index 80d74cce2a01..df77b6bf5c64 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -939,8 +939,8 @@ static int do_devinfo_ioctl(struct comedi_device *dev, /* fill devinfo structure */ devinfo.version_code = COMEDI_VERSION_CODE; devinfo.n_subdevs = dev->n_subdevices; - strlcpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN); - strlcpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN); + strscpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN); + strscpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN); s = comedi_file_read_subdevice(file); if (s) -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 11/18] media: hantro: Add helper function for auxiliary buffers allocation
Le 17/02/2021 à 21:42, Ezequiel Garcia a écrit :
Hi Benjamin,
On Wed, 2021-02-17 at 09:02 +0100, Benjamin Gaignard wrote:
Add helper functions to allocate and free auxiliary buffers.
These buffers aren't for frames but are needed by the hardware
to store scaling matrix, tiles size, border filters etc...
Signed-off-by: Benjamin Gaignard
Signed-off-by: Ezequiel Garcia
Signed-off-by: Adrian Ratiu
---
drivers/staging/media/hantro/hantro.h | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/media/hantro/hantro.h
b/drivers/staging/media/hantro/hantro.h
index a9b80b2c9124..7f842edbc341 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -446,6 +446,30 @@ hantro_get_dec_buf(struct hantro_ctx *ctx, struct
vb2_buffer *vb)
return vb2_plane_vaddr(vb, 0);
}
+static inline int
+hantro_aux_buf_alloc(struct hantro_dev *vpu,
+ struct hantro_aux_buf *buf, size_t size)
+{
Can you add convert the dma_alloc_ calls in the driver,
and squash it in this patch?
I.e. hantro_h264_dec_init, hantro_vp8_dec_init, etc.
Sure I will that in v2.
Benjamin
Thanks!
Ezequiel
+ buf->cpu = dma_alloc_coherent(vpu->dev, size, &buf->dma, GFP_KERNEL);
+ if (!buf->cpu)
+ return -ENOMEM;
+
+ buf->size = size;
+ return 0;
+}
+
+static inline void
+hantro_aux_buf_free(struct hantro_dev *vpu,
+ struct hantro_aux_buf *buf)
+{
+ if (buf->cpu)
+ dma_free_coherent(vpu->dev, buf->size, buf->cpu, buf->dma);
+
+ buf->cpu = NULL;
+ buf->dma = 0;
+ buf->size = 0;
+}
+
void hantro_postproc_disable(struct hantro_ctx *ctx);
void hantro_postproc_enable(struct hantro_ctx *ctx);
void hantro_postproc_free(struct hantro_ctx *ctx);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 06:22:20PM +0530, Atul Gopinathan wrote:
> On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> > On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > > On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > > Fix the following warning generated by sparse:
> > > > >
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect
> > > > > type in assignment (different address spaces)
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned
> > > > > int *chanlist
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:got void [noderef]
> > > > > *
> > > > >
> > > > > compat_ptr() has a return type of "void __user *"
> > > > > as defined in "include/linux/compat.h"
> > > > >
> > > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > > in drivers/staging/comedi/comedi.h" in struct
> > > > > comedi_cmd.
> > > > >
> > > > > Signed-off-by: Atul Gopinathan
> > > > > ---
> > > > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > > > b/drivers/staging/comedi/comedi_fops.c
> > > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd
> > > > > *cmd,
> > > > > cmd->scan_end_arg = v32.scan_end_arg;
> > > > > cmd->stop_src = v32.stop_src;
> > > > > cmd->stop_arg = v32.stop_arg;
> > > > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > > > + cmd->chanlist = (unsigned int __force
> > > > > *)compat_ptr(v32.chanlist);
> > > > > cmd->chanlist_len = v32.chanlist_len;
> > > > > cmd->data = compat_ptr(v32.data);
> > > > > cmd->data_len = v32.data_len;
> > > > >
> > > >
> > > > This patch and the other one in your series clash with commit
> > > > 9d5d041eebe3
> > > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > > warnings") by B K Karthik.
> > >
> > > Oh I see. Not sure if this is the right place to ask, but which tree and
> > > branch should one work with when messing with the code in staging/
> > > directory? (wanted to avoid such clashes in future)
> >
> > staging-next is the best one to use from the staging.git tree. But as
> > the above commit was merged in 5.9-rc1, way back in July of last year, I
> > have no idea what tree you are currently using to not hit that...
>
> I'm using the staging tree alright, cloned it yesterday. Except I used the
> --depth parameter. I believe that is the culprit. How bad a mistake is
> that?
>
> (Why depth? I'm currently staying in a remote area where internet
> download speeds are less than 100Kbps. I tried a normal git clone of
> the staging tree and it's estimated time was more than half a day. Not
> to mention, it fails due to loss of connection midway every time)
I live in Africa and used to have this problem before Africa got
connected to fibre optic. Greg's suggestion of using `wget -c` to
download a git bundle is a good one. However, in my experience
`wget -c` is not 100% accurate on super flakey internet. Then if it
fails the verify will fail and you'll have to re-download the entire
thing.
If you want I have a different option. What I made a clone of Linus's
tree. Then I did:
tar cvvf linux.tar linux/.git
for i in $(seq 0 116) ; do dd if=linux.tar of=linux.tar.${i} ibs=1M count=20
skip=$((20 * $i)) ; done
Now I have put those on a private webserver I have. You can download
them by doing:
for i in $(seq 0 116) ; do wget -c
http://51.158.124.72/kernel_split/linux.tar.${i} ; done
md5sum * > my_md5s
wget http://51.158.124.72/kernel_split/md5sums
diff -u md5sum my_md5s
Re-download files which don't match
for i in $(seq 0 116) ; do cat linux.tar.${i} >> linux.tar ; done
cat linux.tar | tar xv
cd linux
git reset --hard
Let me know if this works for you. I will leave the source up for a
week or two before I delete it.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] fix comparisons - put constant on right side- eudyptula
On Thu, Feb 18, 2021 at 03:54:29PM +, Kurt Manucredo wrote: > > Dear linux kernel developers, > > for my eudyptula challenge it is required of me to fix a coding style > issue in the staging area in linux-next. I am aware that it is in > general frowned upon when submitting these sorts of patches. However, to > finish my 10th challenge I was tasked to do exactly that. So I ask you > kindly to pull this patch if possible. > > Thank you for your time, These patches are fine in staging. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] fix comparisons - put constant on right side- eudyptula challenge 10
Fix the subject. Don't mention eudyptula. [PATCH] Staging: rtl8723bs: put constant on right side of comparison Add a commit message: Checkpatch complains that the constant needs to be on the right hand side of the comparion. On Thu, Feb 18, 2021 at 03:54:40PM +, Kurt Manucredo wrote: > Signed-off-by: Kurt Manucredo > --- > drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c > b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c > index 975f2830e29e..089c6ec19373 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c > +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c > @@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8 > *pcur_dot11txpn, u8 *StaAddr) > struct security_priv *psecpriv = &padapter->securitypriv; > > memset(pcur_dot11txpn, 0, 8); > - if (NULL == StaAddr) > + if (StaAddr == NULL) The prefered format for this is actually: if (!StaAddr) return; regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Fix comments typos
On Wed, Feb 10, 2021 at 03:59:52PM +0100, Mairo Paul Rufus wrote: > Signed-off-by: Mairo Paul Rufus No commit message. It should say something like: Checkpatch complained about the accidental repeated words like "our our" so I fixed it. > diff --git a/drivers/staging/wlan-ng/prism2sta.c > b/drivers/staging/wlan-ng/prism2sta.c > index 8f25496188aa..e6dcb687e7a1 100644 > --- a/drivers/staging/wlan-ng/prism2sta.c > +++ b/drivers/staging/wlan-ng/prism2sta.c > @@ -461,7 +461,7 @@ u32 prism2sta_ifstate(struct wlandevice *wlandev, u32 > ifstate) > case WLAN_MSD_FWLOAD: > wlandev->msdstate = WLAN_MSD_RUNNING_PENDING; > /* Initialize the device+driver for full > - * operation. Note that this might me an FWLOAD to > + * operation. Note that this might me an FWLOAD This probably should be "might be". >* to RUNNING transition so we must not do a chip >* or board level reset. Note that on failure, >* the MSD state is set to HWPRESENT because we regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Thu, Feb 18, 2021 at 06:51:59PM +0300, Dan Carpenter wrote:
> On Thu, Feb 18, 2021 at 06:22:20PM +0530, Atul Gopinathan wrote:
> > On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> > > On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > > > On Thu, Feb 18, 2021 at 10:31:15AM +, Ian Abbott wrote:
> > > > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > > > Fix the following warning generated by sparse:
> > > > > >
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect
> > > > > > type in assignment (different address spaces)
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned
> > > > > > int *chanlist
> > > > > > drivers/staging//comedi/comedi_fops.c:2956:23:got void
> > > > > > [noderef] *
> > > > > >
> > > > > > compat_ptr() has a return type of "void __user *"
> > > > > > as defined in "include/linux/compat.h"
> > > > > >
> > > > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > > > in drivers/staging/comedi/comedi.h" in struct
> > > > > > comedi_cmd.
> > > > > >
> > > > > > Signed-off-by: Atul Gopinathan
> > > > > > ---
> > > > > > drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/staging/comedi/comedi_fops.c
> > > > > > b/drivers/staging/comedi/comedi_fops.c
> > > > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd
> > > > > > *cmd,
> > > > > > cmd->scan_end_arg = v32.scan_end_arg;
> > > > > > cmd->stop_src = v32.stop_src;
> > > > > > cmd->stop_arg = v32.stop_arg;
> > > > > > - cmd->chanlist = compat_ptr(v32.chanlist);
> > > > > > + cmd->chanlist = (unsigned int __force
> > > > > > *)compat_ptr(v32.chanlist);
> > > > > > cmd->chanlist_len = v32.chanlist_len;
> > > > > > cmd->data = compat_ptr(v32.data);
> > > > > > cmd->data_len = v32.data_len;
> > > > > >
> > > > >
> > > > > This patch and the other one in your series clash with commit
> > > > > 9d5d041eebe3
> > > > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > > > warnings") by B K Karthik.
> > > >
> > > > Oh I see. Not sure if this is the right place to ask, but which tree and
> > > > branch should one work with when messing with the code in staging/
> > > > directory? (wanted to avoid such clashes in future)
> > >
> > > staging-next is the best one to use from the staging.git tree. But as
> > > the above commit was merged in 5.9-rc1, way back in July of last year, I
> > > have no idea what tree you are currently using to not hit that...
> >
> > I'm using the staging tree alright, cloned it yesterday. Except I used the
> > --depth parameter. I believe that is the culprit. How bad a mistake is
> > that?
> >
> > (Why depth? I'm currently staying in a remote area where internet
> > download speeds are less than 100Kbps. I tried a normal git clone of
> > the staging tree and it's estimated time was more than half a day. Not
> > to mention, it fails due to loss of connection midway every time)
>
> I live in Africa and used to have this problem before Africa got
> connected to fibre optic. Greg's suggestion of using `wget -c` to
> download a git bundle is a good one. However, in my experience
> `wget -c` is not 100% accurate on super flakey internet. Then if it
> fails the verify will fail and you'll have to re-download the entire
> thing.
>
> If you want I have a different option. What I made a clone of Linus's
> tree. Then I did:
>
> tar cvvf linux.tar linux/.git
> for i in $(seq 0 116) ; do dd if=linux.tar of=linux.tar.${i} ibs=1M count=20
> skip=$((20 * $i)) ; done
>
> Now I have put those on a private webserver I have. You can download
> them by doing:
>
> for i in $(seq 0 116) ; do wget -c
> http://51.158.124.72/kernel_split/linux.tar.${i} ; done
> md5sum * > my_md5s
> wget http://51.158.124.72/kernel_split/md5sums
> diff -u md5sum my_md5s
>
> Re-download files which don't match
>
> for i in $(seq 0 116) ; do cat linux.tar.${i} >> linux.tar ; done
> cat linux.tar | tar xv
> cd linux
> git reset --hard
>
> Let me know if this works for you. I will leave the source up for a
> week or two before I delete it.
Hi Dan!
That's a great work you did there. Thank you for trying to help,
really appreciate it. :D
As of now, I digged into my old backup partitions and found an image
of an ubuntu VM that I used to mess with linux source a couple of weeks
ago and luckily I had a clone of both linux-mainline and linux-next
trees in it. So I have updated those and using them currently.
My internet problems are temporary, as I will move back to my original
location, which has good internet speeds, next month.
Again, thank you for trying to help me! I will definitely contact you
if I ever
Re: [PATCH] Staging: comedi: Replaced strlcpy to strscpy
On 18/02/2021 14:31, chakravarthikulkarni wrote: > Warning found by checkpath.pl script. > > Signed-off-by: chakravarthikulkarni > --- > drivers/staging/comedi/comedi_fops.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/comedi/comedi_fops.c > b/drivers/staging/comedi/comedi_fops.c > index 80d74cce2a01..df77b6bf5c64 100644 > --- a/drivers/staging/comedi/comedi_fops.c > +++ b/drivers/staging/comedi/comedi_fops.c > @@ -939,8 +939,8 @@ static int do_devinfo_ioctl(struct comedi_device *dev, > /* fill devinfo structure */ > devinfo.version_code = COMEDI_VERSION_CODE; > devinfo.n_subdevs = dev->n_subdevices; > - strlcpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN); > - strlcpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN); > + strscpy(devinfo.driver_name, dev->driver->driver_name, COMEDI_NAMELEN); > + strscpy(devinfo.board_name, dev->board_name, COMEDI_NAMELEN); > > s = comedi_file_read_subdevice(file); > if (s) > Thanks, but you are too late. It has already been fixed in linux-next. -- -=( Ian Abbott || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vc04_services: Fixed address type mismatch in vchiq_arm.c
On Thu, Feb 18, 2021 at 10:39 AM Greg KH wrote: > > On Thu, Feb 18, 2021 at 02:40:15PM +0530, Pritthijit Nath wrote: > > This change fixes a sparse address type mismatch warning "incorrect type > > in assignment (different address spaces)". > > > > Signed-off-by: Pritthijit Nath > > --- > > .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > index 59e45dc03a97..3c715b926a57 100644 > > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > @@ -1214,11 +1214,7 @@ static int vchiq_ioc_await_completion(struct > > vchiq_instance *instance, > > !instance->use_close_delivered) > > unlock_service(service); > > > > - /* > > - * FIXME: address space mismatch, does bulk_userdata > > - * actually point to user or kernel memory? > > - */ > > - user_completion.bulk_userdata = completion->bulk_userdata; > > + user_completion.bulk_userdata = (void __user > > *)completion->bulk_userdata; > > So, this pointer really is user memory? > > How did you determine that? > > If so, why isn't this a __user * in the first place? > > You can't just paper over the FIXME by doing a cast without doing the > real work here, otherwise someone wouldn't have written the FIXME :) Agreed. I added the FIXME as part of a cleanup work I did last year. The obvious step is to mark the corresponding field in vchiq_completion_data_kernel as a __user pointer, and then check all assignments *to* that members to ensure they all refer to __user pointers as well. At some point I gave up here, as far as I recall there were certain assignments that were clearly kernel data, in particular the vchiq_service_params_kernel->callback() argument seems to sometimes come from kmalloc() and must not be passed down to user space. The alternative would be to look at the user space side to figure out how the returned data is actually used. If user space doesn't rely on it, it can simply get set to NULL, and if it does use it, then the question is which code path in the kernel correctly assigns it. Arnd ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: Align block comments
This patch fixes the checkpatch.pl warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Block comments should align the * on each line
Signed-off-by: Suryashankar Das
---
drivers/staging/rtl8188eu/core/rtw_security.c | 82 +--
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 46ba55a8952a..73b78740093b 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -127,8 +127,8 @@ static __le32 getcrc32(u8 *buf, int len)
}
/*
- Need to consider the fragment situation
-*/
+ * Need to consider the fragment situation
+ */
void rtw_wep_encrypt(struct adapter *padapter, struct xmit_frame *pxmitframe)
{
int curfragnum, length;
@@ -465,23 +465,23 @@ static const unsigned short Sbox1[2][256] = { /* Sbox
for hash (can be in ROM)
}
};
- /*
-**
-* Routine: Phase 1 -- generate P1K, given TA, TK, IV32
-*
-* Inputs:
-* tk[] = temporal key [128 bits]
-* ta[] = transmitter's MAC address[ 48 bits]
-* iv32 = upper 32 bits of IV[ 32 bits]
-* Output:
-* p1k[] = Phase 1 key[ 80 bits]
-*
-* Note:
-* This function only needs to be called every 2**16 packets,
-* although in theory it could be called every packet.
-*
-**
-*/
+/*
+ **
+ * Routine: Phase 1 -- generate P1K, given TA, TK, IV32
+ *
+ * Inputs:
+ * tk[] = temporal key [128 bits]
+ * ta[] = transmitter's MAC address [ 48 bits]
+ * iv32 = upper 32 bits of IV [ 32 bits]
+ * Output:
+ * p1k[] = Phase 1 key [ 80 bits]
+ *
+ * Note:
+ * This function only needs to be called every 2**16 packets,
+ * although in theory it could be called every packet.
+ *
+ **
+ */
static void phase1(u16 *p1k, const u8 *tk, const u8 *ta, u32 iv32)
{
int i;
@@ -505,28 +505,28 @@ static void phase1(u16 *p1k, const u8 *tk, const u8 *ta,
u32 iv32)
}
/*
-**
-* Routine: Phase 2 -- generate RC4KEY, given TK, P1K, IV16
-*
-* Inputs:
-* tk[] = Temporal key [128 bits]
-* p1k[] = Phase 1 output key [ 80 bits]
-* iv16 = low 16 bits of IV counter[ 16 bits]
-* Output:
-* rc4key[] = the key used to encrypt the packet [128 bits]
-*
-* Note:
-* The value {TA, IV32, IV16} for Phase1/Phase2 must be unique
-* across all packets using the same key TK value. Then, for a
-* given value of TK[], this TKIP48 construction guarantees that
-* the final RC4KEY value is unique across all packets.
-*
-* Suggested implementation optimization: if PPK[] is "overlaid"
-* appropriately on RC4KEY[], there is no need for the final
-* for loop below that copies the PPK[] result into RC4KEY[].
-*
-**
-*/
+ **
+ * Routine: Phase 2 -- generate RC4KEY, given TK, P1K, IV16
+ *
+ * Inputs:
+ * tk[] = Temporal key [128 bits]
+ * p1k[] = Phase 1 output key [ 80 bits]
+ * iv16 = low 16 bits of IV counter [ 16 bits]
+ * Output:
+ * rc4key[] = the key used to encrypt the packet [128 bits]
+ *
+ * Note:
+ * The value {TA, IV32, IV16} for Phase1/Phase2 must be unique
+ * across all packets using the same key TK value. Then, for a
+ * given value of TK[], this TKIP48 construction guarantees that
+ * the final RC4KEY value is unique across all packets.
+ *
+ * Suggested implementation optimization: if PPK[] is "overlaid"
+ * appropriately on RC4KEY[], there is no need for the final
+ * for loop below that copies the PPK[] result into RC4KEY[].
+ *
+ **
+ */
static void phase2(u8 *rc4key, const u8 *tk, const u16 *p1k, u16 iv16)
{
int i;
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8723bs: code-style fix
On Thu, Feb 18, 2021 at 04:33:10PM +, Kurt Manucredo wrote:
> Signed-off-by: Kurt Manucredo
> ---
>
> Checkpatch complains the constant needs to be on the right side of the
> comparison. The preferred way is:
>
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> index 089c6ec19373..96feced698ac 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8
> *pcur_dot11txpn, u8 *StaAddr)
> struct security_priv *psecpriv = &padapter->securitypriv;
>
> memset(pcur_dot11txpn, 0, 8);
> - if (StaAddr == NULL)
> + if (!StaAddr)
> return;
> psta = rtw_get_stainfo(&padapter->stapriv, StaAddr);
> DBG_871X("%s(): StaAddr: %02x %02x %02x %02x %02x %02x\n",
> --
> 2.20.1
>
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: Align block comments
On Thu, Feb 18, 2021 at 10:50:43PM +0530, Suryashankar Das wrote:
> This patch fixes the checkpatch.pl warnings:
> WARNING: Block comments use * on subsequent lines
> WARNING: Block comments should align the * on each line
>
> Signed-off-by: Suryashankar Das
> ---
> drivers/staging/rtl8188eu/core/rtw_security.c | 82 +--
> 1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
> b/drivers/staging/rtl8188eu/core/rtw_security.c
> index 46ba55a8952a..73b78740093b 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_security.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_security.c
> @@ -127,8 +127,8 @@ static __le32 getcrc32(u8 *buf, int len)
> }
>
> /*
> - Need to consider the fragment situation
> -*/
> + * Need to consider the fragment situation
> + */
> void rtw_wep_encrypt(struct adapter *padapter, struct xmit_frame *pxmitframe)
> {
> int curfragnum, length;
> @@ -465,23 +465,23 @@ static const unsigned short Sbox1[2][256] = { /* Sbox
> for hash (can be in ROM)
>}
> };
>
> - /*
> -**
> -* Routine: Phase 1 -- generate P1K, given TA, TK, IV32
> -*
> -* Inputs:
> -* tk[] = temporal key[128 bits]
> -* ta[] = transmitter's MAC address [ 48 bits]
> -* iv32 = upper 32 bits of IV [ 32 bits]
> -* Output:
> -* p1k[] = Phase 1 key [ 80 bits]
> -*
> -* Note:
> -* This function only needs to be called every 2**16 packets,
> -* although in theory it could be called every packet.
> -*
> -**
> -*/
> +/*
> + **
> + * Routine: Phase 1 -- generate P1K, given TA, TK, IV32
> + *
> + * Inputs:
> + * tk[] = temporal key [128 bits]
> + * ta[] = transmitter's MAC address [ 48 bits]
> + * iv32 = upper 32 bits of IV [ 32 bits]
> + * Output:
> + * p1k[] = Phase 1 key [ 80 bits]
> + *
> + * Note:
> + * This function only needs to be called every 2**16 packets,
> + * although in theory it could be called every packet.
> + *
> + **
> + */
For these, please convert them to the kerneldoc format, don't create a
custom one as that's not needed and would only require someone else to
go back and fix it up again.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: Format comments
This patch fixes the checkpatch.pl warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Block comments should align the * on each line
Signed-off-by: Suryashankar Das
---
drivers/staging/rtl8188eu/core/rtw_security.c | 72 ---
1 file changed, 29 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 46ba55a8952a..da26a3c705f8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -126,9 +126,7 @@ static __le32 getcrc32(u8 *buf, int len)
return cpu_to_le32(~crc);/* transmit complement, per CRC-32 spec */
}
-/*
- Need to consider the fragment situation
-*/
+/* Need to consider the fragment situation */
void rtw_wep_encrypt(struct adapter *padapter, struct xmit_frame *pxmitframe)
{
int curfragnum, length;
@@ -465,23 +463,17 @@ static const unsigned short Sbox1[2][256] = { /* Sbox
for hash (can be in ROM)
}
};
- /*
-**
-* Routine: Phase 1 -- generate P1K, given TA, TK, IV32
-*
-* Inputs:
-* tk[] = temporal key [128 bits]
-* ta[] = transmitter's MAC address[ 48 bits]
-* iv32 = upper 32 bits of IV[ 32 bits]
-* Output:
-* p1k[] = Phase 1 key[ 80 bits]
-*
-* Note:
-* This function only needs to be called every 2**16 packets,
-* although in theory it could be called every packet.
-*
-**
-*/
+/**
+ * phase1() - generate P1K, given TA, TK, IV32
+ * @tk[]: temporal key [128 bits]
+ * @ta[]: transmitter's MAC address [ 48 bits]
+ * @iv32: upper 32 bits of IV [ 32 bits]
+ *
+ * This function only needs to be called every 2**16 packets,
+ * although in theory it could be called every packet.
+ *
+ * Return: p1k[] - Phase 1 key [ 80 bits]
+ */
static void phase1(u16 *p1k, const u8 *tk, const u8 *ta, u32 iv32)
{
int i;
@@ -504,29 +496,23 @@ static void phase1(u16 *p1k, const u8 *tk, const u8 *ta,
u32 iv32)
}
}
-/*
-**
-* Routine: Phase 2 -- generate RC4KEY, given TK, P1K, IV16
-*
-* Inputs:
-* tk[] = Temporal key [128 bits]
-* p1k[] = Phase 1 output key [ 80 bits]
-* iv16 = low 16 bits of IV counter[ 16 bits]
-* Output:
-* rc4key[] = the key used to encrypt the packet [128 bits]
-*
-* Note:
-* The value {TA, IV32, IV16} for Phase1/Phase2 must be unique
-* across all packets using the same key TK value. Then, for a
-* given value of TK[], this TKIP48 construction guarantees that
-* the final RC4KEY value is unique across all packets.
-*
-* Suggested implementation optimization: if PPK[] is "overlaid"
-* appropriately on RC4KEY[], there is no need for the final
-* for loop below that copies the PPK[] result into RC4KEY[].
-*
-**
-*/
+/**
+ * phase2() - generate RC4KEY, given TK, P1K, IV16
+ * @tk[]: Temporal key [128 bits]
+ * @p1k[]: Phase 1 output key [ 80 bits]
+ * @iv16: low 16 bits of IV counter [ 16 bits]
+ *
+ * The value {TA, IV32, IV16} for Phase1/Phase2 must be unique
+ * across all packets using the same key TK value. Then, for a
+ * given value of TK[], this TKIP48 construction guarantees that
+ * the final RC4KEY value is unique across all packets.
+ *
+ * Suggested implementation optimization: if PPK[] is "overlaid"
+ * appropriately on RC4KEY[], there is no need for the final
+ * for loop below that copies the PPK[] result into RC4KEY[].
+ *
+ * Return: rc4key[] - the key used to encrypt the packet [128 bits]
+ */
static void phase2(u8 *rc4key, const u8 *tk, const u16 *p1k, u16 iv16)
{
int i;
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] ks7010: enclose non-trivial defines in parentheses
Hi,
I wanted to check the status on the following patch.
I wanted the result for eudyptula task 10 submission.
It would be great if i can check if the mail is being
processed or rejected. I appologise for any troubles.
On Mon, Feb 15, 2021 at 6:57 pm, shivang upadhyay
wrote:
Checkpatch complains that parentheses are missing:
"Macros with complex values should be enclosed in parentheses".
Fixed that.
Signed-off-by: shivang upadhyay
---
Previous versions of the patch were rejected due to lack of
discription in patch emails.
drivers/staging/ks7010/ks_hostif.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 39138191a556..c62a494ed6bb 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
#define TX_RATE_FIXED 5
/* 11b rate */
-#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
-#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
-#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
-#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
+#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
+#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
/* 11g rate */
-#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
-#define TX_RATE_12M(u8)(120 / 5) /* 11g basic rate */
-#define TX_RATE_24M(u8)(240 / 5) /* 11g basic rate */
-#define TX_RATE_9M (u8)(90 / 5)
-#define TX_RATE_18M(u8)(180 / 5)
-#define TX_RATE_36M(u8)(360 / 5)
-#define TX_RATE_48M(u8)(480 / 5)
-#define TX_RATE_54M(u8)(540 / 5)
+#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
+#define TX_RATE_12M((u8)(120 / 5)) /* 11g basic rate */
+#define TX_RATE_24M((u8)(240 / 5)) /* 11g basic rate */
+#define TX_RATE_9M ((u8)(90 / 5))
+#define TX_RATE_18M((u8)(180 / 5))
+#define TX_RATE_36M((u8)(360 / 5))
+#define TX_RATE_48M((u8)(480 / 5))
+#define TX_RATE_54M((u8)(540 / 5))
static inline bool is_11b_rate(u8 rate)
{
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax/i2400m: don't change the endianness of one byte variable
On Thu, Feb 18, 2021 at 10:54 AM Muhammad Usama Anjum wrote: > > On Thu, 2021-02-18 at 10:40 +0100, Greg KH wrote: > > On Thu, Feb 18, 2021 at 02:21:54PM +0500, Muhammad Usama Anjum wrote: > > > It is wrong to change the endianness of a variable which has just one > > > byte size. > > > > > > Sparse warnings fixed: > > > drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to > > > restricted __le32 > > > drivers/staging//wimax/i2400m/control.c:452:17: warning: cast to > > > restricted __le32 > > > drivers/staging//wimax/i2400m/op-rfkill.c:159:14: warning: cast to > > > restricted __le32 > > > drivers/staging//wimax/i2400m/op-rfkill.c:160:14: warning: cast to > > > restricted __le32 > > > > > > Signed-off-by: Muhammad Usama Anjum > > > --- > > > drivers/staging/wimax/i2400m/control.c | 4 ++-- > > > drivers/staging/wimax/i2400m/op-rfkill.c | 4 ++-- > > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/staging/wimax/i2400m/control.c > > > b/drivers/staging/wimax/i2400m/control.c > > > index 1e270b2101e8..b6b2788af162 100644 > > > --- a/drivers/staging/wimax/i2400m/control.c > > > +++ b/drivers/staging/wimax/i2400m/control.c > > > @@ -452,8 +452,8 @@ void i2400m_report_state_parse_tlv(struct i2400m > > > *i2400m, > > > d_printf(2, dev, "%s: RF status TLV " > > > "found (0x%04x), sw 0x%02x hw 0x%02x\n", > > > tag, I2400M_TLV_RF_STATUS, > > > -le32_to_cpu(rfss->sw_rf_switch), > > > -le32_to_cpu(rfss->hw_rf_switch)); > > > +rfss->sw_rf_switch, > > > +rfss->hw_rf_switch); > > > > What do you mean by "one byte"? This is a le32 sized variable, right? > > If not, why isn't the le32_to_cpu() call complaining? > > These two variables are of type _u8, one byte. > __u8 sw_rf_switch; > __u8 hw_rf_switch; > They aren't of type __le32. le32_to_cpu() macro should have > complained. But it isn't complaining. It seems like whatever we pass > to this macro, it casts it to __le32 forcefully (it seems like wrong). > So we'll never get any complain from this macro directly. But we are > getting complain from the sparse. > > For big endian: > #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) > For little endian: > #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) Right, it seems this driver has been broken on big-endian ever since it was first merged in 2008. Arnd ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] ks7010: enclose non-trivial defines in parentheses
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Feb 18, 2021 at 11:59:34PM +0530, roz wrote: > Hi, > > I wanted to check the status on the following patch. > I wanted the result for eudyptula task 10 submission. There's no deadlines here, and the first rule of the eudyptula challenge is that you can not talk about the eudyptula challenge without getting in trouble :( > It would be great if i can check if the mail is being > processed or rejected. I appologise for any troubles. I rejected it a while ago, you got the email from my patch bot, right? See here: https://lore.kernel.org/r/ycy2ftmycppyx...@kroah.com Why did you resend it if you didn't do what that email said to do? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: Fix alignment style issue in sta.c
This change fixes a checkpatch error for "Alignment should match
open parenthesis".
Signed-off-by: Rajat Asthana
---
drivers/staging/wfx/sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index 5585f9e876e1..8c57338efc71 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -193,7 +193,7 @@ int wfx_update_pm(struct wfx_vif *wvif)
}
int wfx_conf_tx(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- u16 queue, const struct ieee80211_tx_queue_params *params)
+ u16 queue, const struct ieee80211_tx_queue_params *params)
{
struct wfx_dev *wdev = hw->priv;
struct wfx_vif *wvif = (struct wfx_vif *)vif->drv_priv;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fwserial: match alignment with open parenthesis
fwserial.c:
fix CHECK: Alignment should match open parenthesis
Signed-off-by: Nikolay Kyx
---
drivers/staging/fwserial/fwserial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index c368082aae1a..137e97c9406c 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -1318,8 +1318,8 @@ static int fwtty_break_ctl(struct tty_struct *tty, int
state)
if (state == -1) {
set_bit(STOP_TX, &port->flags);
ret = wait_event_interruptible_timeout(port->wait_tx,
- !test_bit(IN_TX, &port->flags),
- 10);
+ !test_bit(IN_TX,
&port->flags),
+ 10);
if (ret == 0 || ret == -ERESTARTSYS) {
clear_bit(STOP_TX, &port->flags);
fwtty_restart_tx(port);
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] fix comparisons - put constant on right side- eudyptula
Dear linux kernel developers, for my eudyptula challenge it is required of me to fix a coding style issue in the staging area in linux-next. I am aware that it is in general frowned upon when submitting these sorts of patches. However, to finish my 10th challenge I was tasked to do exactly that. So I ask you kindly to pull this patch if possible. Thank you for your time, kind regards ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] fix comparisons - put constant on right side- eudyptula challenge 10
Signed-off-by: Kurt Manucredo
---
drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 975f2830e29e..089c6ec19373 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8
*pcur_dot11txpn, u8 *StaAddr)
struct security_priv *psecpriv = &padapter->securitypriv;
memset(pcur_dot11txpn, 0, 8);
- if (NULL == StaAddr)
+ if (StaAddr == NULL)
return;
psta = rtw_get_stainfo(&padapter->stapriv, StaAddr);
DBG_871X("%s(): StaAddr: %02x %02x %02x %02x %02x %02x\n",
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: make if-statement checkpatch.pl conform
On Thu, Feb 18, 2021 at 07:50:27PM +, Kurt Manucredo wrote:
> Signed-off-by: Kurt Manucredo
> ---
>
> The preferred coding style is:
> if (!StaAddr)
> return;
>
> thank you mr. dan carpenter
>
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> index 975f2830e29e..96feced698ac 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8
> *pcur_dot11txpn, u8 *StaAddr)
> struct security_priv *psecpriv = &padapter->securitypriv;
>
> memset(pcur_dot11txpn, 0, 8);
> - if (NULL == StaAddr)
> + if (!StaAddr)
> return;
> psta = rtw_get_stainfo(&padapter->stapriv, StaAddr);
> DBG_871X("%s(): StaAddr: %02x %02x %02x %02x %02x %02x\n",
> --
> 2.20.1
>
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for what needs to be done
here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: kpc2000: code style: fix alignment issues
kpc2000_i2c.c:
fix WARNING: line length of 124 exceeds 100 columns
fix CHECK: Alignment should match open parenthesis
kpc2000_spi.c:
fix CHECK: Alignment should match open parenthesis
Signed-off-by: Nikolay Kyx
---
drivers/staging/kpc2000/kpc2000_i2c.c | 6 --
drivers/staging/kpc2000/kpc2000_spi.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_i2c.c
b/drivers/staging/kpc2000/kpc2000_i2c.c
index 25bb5c97dd21..14f7940fa4fb 100644
--- a/drivers/staging/kpc2000/kpc2000_i2c.c
+++ b/drivers/staging/kpc2000/kpc2000_i2c.c
@@ -200,7 +200,9 @@ static int i801_check_post(struct kpc_i2c *priv, int
status, int timeout)
outb_p(status & STATUS_FLAGS, SMBHSTSTS(priv));
status = inb_p(SMBHSTSTS(priv)) & STATUS_FLAGS;
if (status)
- dev_warn(&priv->adapter.dev, "Failed clearing status
flags at end of transaction (%02x)\n", status);
+ dev_warn(&priv->adapter.dev,
+"Failed clearing status flags at end of
transaction (%02x)\n",
+status);
}
return result;
@@ -269,7 +271,7 @@ static int i801_block_transaction_by_block(struct kpc_i2c
*priv,
}
status = i801_transaction(priv,
- I801_BLOCK_DATA | ENABLE_INT9 | I801_PEC_EN * hwpec);
+ I801_BLOCK_DATA | ENABLE_INT9 | I801_PEC_EN *
hwpec);
if (status)
return status;
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index 44017d523da5..16ca18b8aa15 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -465,7 +465,7 @@ kp_spi_probe(struct platform_device *pldev)
}
kpspi->base = devm_ioremap(&pldev->dev, r->start,
- resource_size(r));
+ resource_size(r));
status = spi_register_master(master);
if (status < 0) {
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8723bs: code-style fix
Signed-off-by: Kurt Manucredo
---
Checkpatch complains the constant needs to be on the right side of the
comparison. The preferred way is:
drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 089c6ec19373..96feced698ac 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8
*pcur_dot11txpn, u8 *StaAddr)
struct security_priv *psecpriv = &padapter->securitypriv;
memset(pcur_dot11txpn, 0, 8);
- if (StaAddr == NULL)
+ if (!StaAddr)
return;
psta = rtw_get_stainfo(&padapter->stapriv, StaAddr);
DBG_871X("%s(): StaAddr: %02x %02x %02x %02x %02x %02x\n",
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: kpc2000: code style: fix alignment issues
On Thu, Feb 18, 2021 at 11:28:14PM +0300, Nikolay Kyx wrote: > kpc2000_i2c.c: > fix WARNING: line length of 124 exceeds 100 columns > fix CHECK: Alignment should match open parenthesis > > kpc2000_spi.c: > fix CHECK: Alignment should match open parenthesis This changelog is a bit odd. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fix alignment of function args
Align function arguments to fix checkpatch.pl CHECK message and rewrap to match the file's style. Signed-off-by: Florian Ziegler --- drivers/staging/vt6656/card.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c index 10f3dfda83b5..396736eee690 100644 --- a/drivers/staging/vt6656/card.c +++ b/drivers/staging/vt6656/card.c @@ -375,7 +375,8 @@ int vnt_radio_power_off(struct vnt_private *priv) case RF_VT3226D0: case RF_VT3342A0: ret = vnt_mac_reg_bits_off(priv, MAC_REG_SOFTPWRCTL, - (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3)); + (SOFTPWRCTL_SWPE2 | + SOFTPWRCTL_SWPE3)); break; } -- 2.30.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: make if-statement checkpatch.pl conform
Signed-off-by: Kurt Manucredo
---
The preferred coding style is:
if (!StaAddr)
return;
thank you mr. dan carpenter
drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 975f2830e29e..96feced698ac 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -2146,7 +2146,7 @@ void rtw_get_sec_iv(struct adapter *padapter, u8
*pcur_dot11txpn, u8 *StaAddr)
struct security_priv *psecpriv = &padapter->securitypriv;
memset(pcur_dot11txpn, 0, 8);
- if (NULL == StaAddr)
+ if (!StaAddr)
return;
psta = rtw_get_stainfo(&padapter->stapriv, StaAddr);
DBG_871X("%s(): StaAddr: %02x %02x %02x %02x %02x %02x\n",
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] use explicit host byte-order types in comparison
convert le32 types to host byte-order types before
comparison
Signed-off-by: karthik alapati
---
i wonder how these could be false-positives
drivers/staging/wimax/i2400m/fw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m/fw.c
index edb5eba0898b..13207c985a87 100644
--- a/drivers/staging/wimax/i2400m/fw.c
+++ b/drivers/staging/wimax/i2400m/fw.c
@@ -191,7 +191,7 @@ void i2400m_bm_cmd_prepare(struct i2400m_bootrom_header
*cmd)
int i;
u32 checksum = 0;
const u32 *checksum_ptr = (void *) cmd->payload;
- for (i = 0; i < cmd->data_size / 4; i++)
+ for (i = 0; i < le32_to_cpu(cmd->data_size) / 4; i++)
checksum += cpu_to_le32(*checksum_ptr++);
checksum += cmd->command + cmd->target_addr + cmd->data_size;
cmd->block_checksum = cpu_to_le32(checksum);
@@ -506,7 +506,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int
opcode,
opcode, i2400m_brh_get_response(ack));
goto error_ack_failed;
}
- if (ack_size < ack->data_size + sizeof(*ack)) {
+ if (ack_size < le32_to_cpu(ack->data_size) + sizeof(*ack)) {
dev_err(dev, "boot-mode cmd %d: SW BUG "
"driver provided only %zu bytes for %zu bytes "
"of data\n", opcode, ack_size,
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: i2400m: use explicit host byte-order types in comparison
convert le32 types to host byte-order types before
comparison
Signed-off-by: karthik alapati
---
i wonder how these could be false-positives
drivers/staging/wimax/i2400m/fw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m/fw.c
index edb5eba0898b..13207c985a87 100644
--- a/drivers/staging/wimax/i2400m/fw.c
+++ b/drivers/staging/wimax/i2400m/fw.c
@@ -191,7 +191,7 @@ void i2400m_bm_cmd_prepare(struct i2400m_bootrom_header
*cmd)
int i;
u32 checksum = 0;
const u32 *checksum_ptr = (void *) cmd->payload;
- for (i = 0; i < cmd->data_size / 4; i++)
+ for (i = 0; i < le32_to_cpu(cmd->data_size) / 4; i++)
checksum += cpu_to_le32(*checksum_ptr++);
checksum += cmd->command + cmd->target_addr + cmd->data_size;
cmd->block_checksum = cpu_to_le32(checksum);
@@ -506,7 +506,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int
opcode,
opcode, i2400m_brh_get_response(ack));
goto error_ack_failed;
}
- if (ack_size < ack->data_size + sizeof(*ack)) {
+ if (ack_size < le32_to_cpu(ack->data_size) + sizeof(*ack)) {
dev_err(dev, "boot-mode cmd %d: SW BUG "
"driver provided only %zu bytes for %zu bytes "
"of data\n", opcode, ack_size,
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: emxx_udc: remove unused variable driver_desc
Signed-off-by: Sean Behan --- drivers/staging/emxx_udc/emxx_udc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c index 3536c03ff523..741147a4f0fe 100644 --- a/drivers/staging/emxx_udc/emxx_udc.c +++ b/drivers/staging/emxx_udc/emxx_udc.c @@ -38,7 +38,6 @@ static struct gpio_desc *vbus_gpio; static int vbus_irq; static const char driver_name[] = "emxx_udc"; -static const char driver_desc[] = DRIVER_DESC; /*===*/ /* Prototype */ -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: emxx_udc: remove unused variable driver_desc
On Thu, Feb 18, 2021 at 10:41:07PM -0500, Sean Behan wrote: > Signed-off-by: Sean Behan > --- > drivers/staging/emxx_udc/emxx_udc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c > b/drivers/staging/emxx_udc/emxx_udc.c > index 3536c03ff523..741147a4f0fe 100644 > --- a/drivers/staging/emxx_udc/emxx_udc.c > +++ b/drivers/staging/emxx_udc/emxx_udc.c > @@ -38,7 +38,6 @@ static struct gpio_desc *vbus_gpio; > static int vbus_irq; > > static const chardriver_name[] = "emxx_udc"; > -static const chardriver_desc[] = DRIVER_DESC; > > > /*===*/ > /* Prototype */ > -- > 2.29.2 Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2400m: use explicit host byte-order types in comparison
On Fri, Feb 19, 2021 at 06:00:47AM +0530, karthik alapati wrote: > convert le32 types to host byte-order types before > comparison That says what you did, but not _why_ you did it. Please fix up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
No problem. These days I have fibre to my house, but I still remember trying to clone the kernel when I could only buy 20MB of data at a time. :P regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8723bs: code-style fix
The subject is too vague. On Thu, Feb 18, 2021 at 04:33:10PM +, Kurt Manucredo wrote: > Signed-off-by: Kurt Manucredo > --- > > Checkpatch complains the constant needs to be on the right side of the > comparison. The preferred way is: > The commit message isn't complete and it has to go above the Signed-off-by line. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: make if-statement checkpatch.pl conform
On Thu, Feb 18, 2021 at 07:50:27PM +, Kurt Manucredo wrote: > Signed-off-by: Kurt Manucredo > --- > > The preferred coding style is: > if (!StaAddr) > return; Above the Signed-off-by line. Also indenting is wrong. And it's hard to understand what you're saying. > > thank you mr. dan carpenter You're welcome. (These sorts of comments do go below the --- cut off line so that's fine.) regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Fixed incorrect type warning in p80211netdev.c
On 2/17/21 6:42 PM, pritthijit.nath at icloud.com (Pritthijit Nath) wrote:
This change fixes a sparse warning "incorrect type in argument 1
(different address spaces)".
Signed-off-by: Pritthijit Nath
---
drivers/staging/wlan-ng/p80211netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/p80211netdev.c
b/drivers/staging/wlan-ng/p80211netdev.c
index 6f9666dc0277..70570e8a5ad2 100644
--- a/drivers/staging/wlan-ng/p80211netdev.c
+++ b/drivers/staging/wlan-ng/p80211netdev.c
@@ -569,7 +569,7 @@ static int p80211knetdev_do_ioctl(struct net_device *dev,
goto bail;
}
- msgbuf = memdup_user(req->data, req->len);
+ msgbuf = memdup_user((void __user *)req->data, req->len);
if (IS_ERR(msgbuf)) {
result = PTR_ERR(msgbuf);
goto bail;
Reviewed-by: Ivan Safonov
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
On Fri, Feb 19, 2021 at 09:55:14AM +0300, Dan Carpenter wrote: > No problem. These days I have fibre to my house, but I still remember > trying to clone the kernel when I could only buy 20MB of data at a > time. :P Whoaa, that's tough! Respect to you for still trying to contribute to the kernel. Hope no one gets such a situation. :D Regards, Atul ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
