Re: [PATCH 3/3] staging: dgnc: improve the coding style in unlocking part of dgnc_tty_write()
On Tue, Apr 07, 2015 at 11:19:53AM +0300, Dan Carpenter wrote: > On Tue, Apr 07, 2015 at 11:17:48AM +0300, Dan Carpenter wrote: > > This patch changes the lock ordering (behavior change) and it's not > > described in the changelog. Please figure out which way is the correct > > ordering and resend. > > Actually the original ordering was obviously correct. You can't take > a mutex if you are holding a spinlock. So it always has to be: > > mutex_lock(); > spin_lock(); > > spin_unlock(); > mutext_unlock(); > Oh, hm... You could take a mutex with trylock I suppose. That would be safe. Anyway, I just saw that you sent a v2 patch. When you send a v2 patch, then you *must* send a reply to the original thread. Greg has thousands and thousands of messages in his inbox and he applies patches in chronological order. So he will apply this one because it has not responses then get to the v2 patch and try to apply that one as well which will fail. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: panel: remove duplicate code
both the misc_deregister(), parport_release() and
parport_unregister_device() is there in the module_exit function also.
detach is called from parport_unregister_driver() and by the time
detach executes misc_deregister(), parport_release() and
parport_unregister_device() has already executed marking
keypad_initialized and lcd.initialized as false. so this part of the
code will never execute.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/panel/panel.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index ea54fb4..1d8ed8b 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -2252,20 +2252,6 @@ static void panel_detach(struct parport *port)
}
unregister_reboot_notifier(&panel_notifier);
-
- if (keypad.enabled && keypad_initialized) {
- misc_deregister(&keypad_dev);
- keypad_initialized = 0;
- }
-
- if (lcd.enabled && lcd.initialized) {
- misc_deregister(&lcd_dev);
- lcd.initialized = false;
- }
-
- parport_release(pprt);
- parport_unregister_device(pprt);
- pprt = NULL;
}
static struct parport_driver panel_driver = {
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > both the misc_deregister(), parport_release() and > parport_unregister_device() is there in the module_exit function also. > detach is called from parport_unregister_driver() and by the time > detach executes misc_deregister(), parport_release() and > parport_unregister_device() has already executed marking > keypad_initialized and lcd.initialized as false. so this part of the > code will never execute. > > Signed-off-by: Sudip Mukherjee Reviewed-by: Dan Carpenter A better subject might have been "remove dead code" but that was explained pretty well in the patch desription. I hadn't looked at this driver much before. It sucks that parport_driver ->attach() functions can't fail... I think we don't need the "keypad_initialized" and "lcd.initialized" variables because "if (pprt)" is enough to tell us whether or not the attach function succeeded. TODO: Staging: panel: remove some redundent variables. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > I hadn't looked at this driver much before. It sucks that > parport_driver ->attach() functions can't fail... then maybe, we can change the code of parport. currently attach and parport_register_driver never fails. we can modify it so that if attach fails then parport_register_driver will also fail. will not be that much difficult as it has been used only in 13 places. your views ? and since we are discussing parallel ports, few days back i saw one post in ubuntuforums that his scanner is not working because of lack of ppscsi.I mailed Tim Waugh, but he is not interested to work with ppscsi anymore. parallel port scanners are almost a thing of the past now. do you think it is worth that i pick up the code and modify it for our latest kernel and submit to Greg ? regards sudip > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: Make cfs_sched_rehash static
On Mon, Apr 06, 2015 at 10:02:27PM -0400, Nickolaus Woodruff wrote: > This patch fixes the following sparse warning: > > CHECK drivers/staging/lustre/lustre/libcfs/hash.c > drivers/staging/lustre/lustre/libcfs/hash.c:119:21: warning: symbol > 'cfs_sched_rehash' was not declared. Should it be static? you have not build tested your patch. WARNING: "cfs_sched_rehash" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! it has been used in lustre/lustre/libcfs/module.c regards sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > I hadn't looked at this driver much before. It sucks that > > parport_driver ->attach() functions can't fail... > > then maybe, we can change the code of parport. currently attach and > parport_register_driver never fails. we can modify it so that if attach > fails then parport_register_driver will also fail. will not be that much > difficult as it has been used only in 13 places. > your views ? > > and since we are discussing parallel ports, few days back i saw one > post in ubuntuforums that his scanner is not working because of > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > with ppscsi anymore. parallel port scanners are almost a thing of the past > now. do you think it is worth that i pick up the code and modify > it for our latest kernel and submit to Greg ? If you have some parport hardware, and want to take it on, that would be great. The code needs a maintainer, and the apis are _really_ old and messy, as you have found out. I'll be glad to shephard parport patches to Linus, as I've been doing that semi-regularly for a few years now, through my char-misc git tree. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > I hadn't looked at this driver much before. It sucks that > > parport_driver ->attach() functions can't fail... > > then maybe, we can change the code of parport. currently attach and > parport_register_driver never fails. we can modify it so that if attach > fails then parport_register_driver will also fail. will not be that much > difficult as it has been used only in 13 places. > your views ? If you write the patch then I will review it. :) > > and since we are discussing parallel ports, few days back i saw one > post in ubuntuforums that his scanner is not working because of > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > with ppscsi anymore. parallel port scanners are almost a thing of the past > now. do you think it is worth that i pick up the code and modify > it for our latest kernel and submit to Greg ? If you want to do the work, I won't say no! :P regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 11:44:29AM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > > > I hadn't looked at this driver much before. It sucks that > > > parport_driver ->attach() functions can't fail... > > > > then maybe, we can change the code of parport. currently attach and > > parport_register_driver never fails. we can modify it so that if attach > > fails then parport_register_driver will also fail. will not be that much > > difficult as it has been used only in 13 places. > > your views ? > > > > and since we are discussing parallel ports, few days back i saw one > > post in ubuntuforums that his scanner is not working because of > > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > > with ppscsi anymore. parallel port scanners are almost a thing of the past > > now. do you think it is worth that i pick up the code and modify > > it for our latest kernel and submit to Greg ? > > If you have some parport hardware, and want to take it on, that would be > great. The code needs a maintainer, and the apis are _really_ old and > messy, as you have found out. what kind of parport hardware will you suggest? regards sudip > > I'll be glad to shephard parport patches to Linus, as I've been doing > that semi-regularly for a few years now, through my char-misc git tree. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 03:26:58PM +0530, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 11:44:29AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > > > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > > > > > I hadn't looked at this driver much before. It sucks that > > > > parport_driver ->attach() functions can't fail... > > > > > > then maybe, we can change the code of parport. currently attach and > > > parport_register_driver never fails. we can modify it so that if attach > > > fails then parport_register_driver will also fail. will not be that much > > > difficult as it has been used only in 13 places. > > > your views ? > > > > > > and since we are discussing parallel ports, few days back i saw one > > > post in ubuntuforums that his scanner is not working because of > > > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > > > with ppscsi anymore. parallel port scanners are almost a thing of the past > > > now. do you think it is worth that i pick up the code and modify > > > it for our latest kernel and submit to Greg ? > > > > If you have some parport hardware, and want to take it on, that would be > > great. The code needs a maintainer, and the apis are _really_ old and > > messy, as you have found out. > what kind of parport hardware will you suggest? No idea, go look at the drivers and code to figure that out. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
kzalloc() could fail so add a check and return -ENOMEM if it does that gets propogated to the pci layer Signed-off-by: Giedrius Statkevičius --- drivers/staging/dgnc/dgnc_tty.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index 61d5a8e..23337da 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -311,6 +311,8 @@ int dgnc_tty_init(struct dgnc_board *brd) * interrupt context, and there are no locks held. */ brd->channels[i] = kzalloc(sizeof(*brd->channels[i]), GFP_KERNEL); + if (!brd->channels[i]) + return -ENOMEM; } } -- 2.3.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 12:45:23PM +0300, Dan Carpenter wrote: > On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > > If you write the patch then I will review it. :) sure, I am on it. > > > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > > with ppscsi anymore. parallel port scanners are almost a thing of the past > > now. do you think it is worth that i pick up the code and modify > > it for our latest kernel and submit to Greg ? > > If you want to do the work, I won't say no! :P and, can you please suggest what kind of hardware should i try to find to work with ppscsi. i saw parallel port scanners or zip drives will be using that module. any other hardware apart from these? regards sudip > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, Apr 07, 2015 at 01:26:32PM +0300, Giedrius Statkevičius wrote: > kzalloc() could fail so add a check and return -ENOMEM if it does that gets > propogated to the pci layer > > Signed-off-by: Giedrius Statkevičius > --- > drivers/staging/dgnc/dgnc_tty.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c > index 61d5a8e..23337da 100644 > --- a/drivers/staging/dgnc/dgnc_tty.c > +++ b/drivers/staging/dgnc/dgnc_tty.c > @@ -311,6 +311,8 @@ int dgnc_tty_init(struct dgnc_board *brd) >* interrupt context, and there are no locks held. >*/ > brd->channels[i] = kzalloc(sizeof(*brd->channels[i]), > GFP_KERNEL); > + if (!brd->channels[i]) > + return -ENOMEM; won't this create memory leak ? suppose you have brd->nasync = 3 and kzalloc fails when i=2, and you return -ENOMEM, then what happens to the memory already allocated to brd->channels[0] and brd->channels[1] ? regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, 7 Apr 2015, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 01:26:32PM +0300, Giedrius Statkevičius wrote: > > kzalloc() could fail so add a check and return -ENOMEM if it does that gets > > propogated to the pci layer > > > > Signed-off-by: Giedrius Statkevičius > > --- > > drivers/staging/dgnc/dgnc_tty.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/staging/dgnc/dgnc_tty.c > > b/drivers/staging/dgnc/dgnc_tty.c > > index 61d5a8e..23337da 100644 > > --- a/drivers/staging/dgnc/dgnc_tty.c > > +++ b/drivers/staging/dgnc/dgnc_tty.c > > @@ -311,6 +311,8 @@ int dgnc_tty_init(struct dgnc_board *brd) > > * interrupt context, and there are no locks held. > > */ > > brd->channels[i] = kzalloc(sizeof(*brd->channels[i]), > > GFP_KERNEL); > > + if (!brd->channels[i]) > > + return -ENOMEM; > won't this create memory leak ? > suppose you have brd->nasync = 3 > and kzalloc fails when i=2, and you return -ENOMEM, > then what happens to the memory already allocated to brd->channels[0] > and brd->channels[1] ? > > regards > sudip > Didn't think about that, sorry. It will cause a memory leak indeed. I'll send a v2 that creates a label that frees all successful kzalloc() before returning -ENOMEM. Su pagarba / Regards, Giedrius___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
If one of the allocations of memory for storing a channel information struct
fails then free all the successful allocations and return -ENOMEM that gets
propogated to the pci layer. Also, remove a bogus skipping in the next part of
the initiation if a previous memory allocation failed because we won't execute
that if any of the allocations failed.
Signed-off-by: Giedrius Statkevičius
---
v2: Only returning -ENOMEM if an allocation failed isn't enough as it was
spotted by Sudip so create a new label that frees all successfully allocated
stuff and only then returns -ENOMEM. Also, remove a unnecessary check in the
next loop.
drivers/staging/dgnc/dgnc_tty.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ce4187f..60d7e49 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -316,6 +316,8 @@ int dgnc_tty_init(struct dgnc_board *brd)
* interrupt context, and there are no locks held.
*/
brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
GFP_KERNEL);
+ if (!brd->channels[i])
+ goto err_free_channels;
}
}
@@ -324,10 +326,6 @@ int dgnc_tty_init(struct dgnc_board *brd)
/* Set up channel variables */
for (i = 0; i < brd->nasync; i++, ch = brd->channels[i]) {
-
- if (!brd->channels[i])
- continue;
-
spin_lock_init(&ch->ch_lock);
/* Store all our magic numbers */
@@ -375,6 +373,11 @@ int dgnc_tty_init(struct dgnc_board *brd)
}
return 0;
+
+err_free_channels:
+ for (i = i - 1; i >= 0; --i)
+ kfree(brd->channels[i]);
+ return -ENOMEM;
}
--
2.3.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, Apr 07, 2015 at 03:40:17PM +0300, Giedrius Statkevičius wrote: > If one of the allocations of memory for storing a channel information struct > fails then free all the successful allocations and return -ENOMEM that gets > propogated to the pci layer. Also, remove a bogus skipping in the next part > of > the initiation if a previous memory allocation failed because we won't execute > that if any of the allocations failed. > > Signed-off-by: Giedrius Statkevičius > --- > v2: Only returning -ENOMEM if an allocation failed isn't enough as it was > spotted by Sudip so create a new label that frees all successfully allocated > stuff and only then returns -ENOMEM. Also, remove a unnecessary check in the > next loop. > > drivers/staging/dgnc/dgnc_tty.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c > index ce4187f..60d7e49 100644 > --- a/drivers/staging/dgnc/dgnc_tty.c > +++ b/drivers/staging/dgnc/dgnc_tty.c > @@ -316,6 +316,8 @@ int dgnc_tty_init(struct dgnc_board *brd) >* interrupt context, and there are no locks held. >*/ > brd->channels[i] = kzalloc(sizeof(*brd->channels[i]), > GFP_KERNEL); > + if (!brd->channels[i]) > + goto err_free_channels; The comments here say that sometimes brd->channels[] are allocated earlier. If that's true then the error handling is not correct. But I don't think it is true... Could you investigate and delete the comments and unnecessary "if (!brd->channels[i])" NULL check. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/6] Revert "staging: board: disable as it breaks the build"
On Mon, Apr 6, 2015 at 2:40 AM, Simon Horman wrote:
> On Fri, Apr 03, 2015 at 02:41:58PM +0200, Geert Uytterhoeven wrote:
>> This reverts commit d13778d537a0ed6115d2a79a942af999cfb8eec6.
>>
>> Commit 13c11072536f2613 ("staging:board: remove unnecessary function")
>> fixed the build of drivers/staging/board/board.c.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> Signed-off-by: Simon Horman
Acked-by? Reviewed-by? Tested-by? Rejected-by?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, 7 Apr 2015, Dan Carpenter wrote: > On Tue, Apr 07, 2015 at 03:40:17PM +0300, Giedrius Statkevičius wrote: > > If one of the allocations of memory for storing a channel information struct > > fails then free all the successful allocations and return -ENOMEM that gets > > propogated to the pci layer. Also, remove a bogus skipping in the next > > part of > > the initiation if a previous memory allocation failed because we won't > > execute > > that if any of the allocations failed. > > > > Signed-off-by: Giedrius Statkevičius > > --- > > v2: Only returning -ENOMEM if an allocation failed isn't enough as it was > > spotted by Sudip so create a new label that frees all successfully allocated > > stuff and only then returns -ENOMEM. Also, remove a unnecessary check in the > > next loop. > > > > drivers/staging/dgnc/dgnc_tty.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/dgnc/dgnc_tty.c > > b/drivers/staging/dgnc/dgnc_tty.c > > index ce4187f..60d7e49 100644 > > --- a/drivers/staging/dgnc/dgnc_tty.c > > +++ b/drivers/staging/dgnc/dgnc_tty.c > > @@ -316,6 +316,8 @@ int dgnc_tty_init(struct dgnc_board *brd) > > * interrupt context, and there are no locks held. > > */ > > brd->channels[i] = kzalloc(sizeof(*brd->channels[i]), > > GFP_KERNEL); > > + if (!brd->channels[i]) > > + goto err_free_channels; > > The comments here say that sometimes brd->channels[] are allocated > earlier. If that's true then the error handling is not correct. But > I don't think it is true... Could you investigate and delete the > comments and unnecessary "if (!brd->channels[i])" NULL check. > > regards, > dan carpenter > I've checked this earlier and now looked over again and I didn't find any other place where this is allocated. My thought was that deleting that comment and that check could be too much for one patch. I'll send a v3. Su pagarba / Regards, Giedrius___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
commit reverted in staging/sm750fb
Hi Greg, I saw that you have reveretd one commit <6ad6b5ed3e2472b399b567a2f036006bf25df467> "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. I was trying to search for that patch, but it seems I am not able to find that in my personal mails nor in lkml. can you please let me know when it was sent.. And I must say sorry for missing a new file creation in a patch. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 7, 2015 at 10:56 AM, Sudip Mukherjee wrote: > Hi Greg, > I saw that you have reveretd one commit > <6ad6b5ed3e2472b399b567a2f036006bf25df467> > "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. > I was trying to search for that patch, but it seems I am not able to > find that in my personal mails nor in lkml. can you please let me know > when it was sent.. Just run 'git show 6ad6b5ed3e247' in linux-next and you can see such commit. Regards, Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 07, 2015 at 11:01:57AM -0300, Fabio Estevam wrote: > On Tue, Apr 7, 2015 at 10:56 AM, Sudip Mukherjee > wrote: > > Hi Greg, > > I saw that you have reveretd one commit > > <6ad6b5ed3e2472b399b567a2f036006bf25df467> > > "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. > > I was trying to search for that patch, but it seems I am not able to > > find that in my personal mails nor in lkml. can you please let me know > > when it was sent.. > > Just run 'git show 6ad6b5ed3e247' in linux-next and you can see such commit. I have already seen the patch. But being the maintainer of that driver i hold myself responsible for missing a new file creation in a patch. So i was trying to search for that patch in my mails and also in lkml, but i could not find it, so thought of mailing and asking. :( regards sudip > > Regards, > > Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
If one of the allocations of memory for storing a channel information struct
fails then free all the successful allocations and return -ENOMEM that gets
propogated to the pci layer. Also, remove a bogus skipping in the next part of
the initiation if a previous memory allocation failed because we won't execute
that if any of the allocations failed. Next, remove the misleading comment that
allocation could happen elsewhere. Finally, remove all (except in the ioctl
which can try to get information about a board that failed to probe) checks if
->channels[foo] is NULL or not because probe failing if we can't allocate enough
memory means that this scenario isn't possible.
Signed-off-by: Giedrius Statkevičius
---
v3: Remove the wrong comment at dgnc_tty_init() that says the allocation could
happen somewhere else before this and remove the check if (!brd->channels[i]).
Also, remove all checks where ->channels[i] is checked if it's NULL or not
because if probe fails then that means that this scenario isn't possible (except
in the ioctl).
v2: Only returning -ENOMEM if an allocation failed isn't enough as it was
spotted by Sudip so create a new label that frees all successfully allocated
stuff and only then returns -ENOMEM. Also, remove a unnecessary check in the
next loop.
drivers/staging/dgnc/dgnc_cls.c | 4 +---
drivers/staging/dgnc/dgnc_neo.c | 2 +-
drivers/staging/dgnc/dgnc_tty.c | 29 +
3 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index e3564d2..a629a78 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -379,7 +379,7 @@ static inline void cls_parse_isr(struct dgnc_board *brd,
uint port)
return;
ch = brd->channels[port];
- if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
+ if (ch->magic != DGNC_CHANNEL_MAGIC)
return;
/* Here we try to figure out what caused the interrupt to happen */
@@ -714,8 +714,6 @@ static void cls_tasklet(unsigned long data)
/* Loop on each port */
for (i = 0; i < ports; i++) {
ch = bd->channels[i];
- if (!ch)
- continue;
/*
* NOTE: Remember you CANNOT hold any channel
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index f5a4d36..1e583c2 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -395,7 +395,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
return;
ch = brd->channels[port];
- if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
+ if (ch->magic != DGNC_CHANNEL_MAGIC)
return;
/* Here we try to figure out what caused the interrupt to happen */
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ce4187f..d1a2c0f 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -304,19 +304,15 @@ int dgnc_tty_init(struct dgnc_board *brd)
brd->nasync = brd->maxports;
- /*
-* Allocate channel memory that might not have been allocated
-* when the driver was first loaded.
-*/
for (i = 0; i < brd->nasync; i++) {
- if (!brd->channels[i]) {
-
- /*
-* Okay to malloc with GFP_KERNEL, we are not at
-* interrupt context, and there are no locks held.
-*/
- brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
GFP_KERNEL);
- }
+ /*
+* Okay to malloc with GFP_KERNEL, we are not at
+* interrupt context, and there are no locks held.
+*/
+ brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
+ GFP_KERNEL);
+ if (!brd->channels[i])
+ goto err_free_channels;
}
ch = brd->channels[0];
@@ -324,10 +320,6 @@ int dgnc_tty_init(struct dgnc_board *brd)
/* Set up channel variables */
for (i = 0; i < brd->nasync; i++, ch = brd->channels[i]) {
-
- if (!brd->channels[i])
- continue;
-
spin_lock_init(&ch->ch_lock);
/* Store all our magic numbers */
@@ -375,6 +367,11 @@ int dgnc_tty_init(struct dgnc_board *brd)
}
return 0;
+
+err_free_channels:
+ for (i = i - 1; i >= 0; --i)
+ kfree(brd->channels[i]);
+ return -ENOMEM;
}
--
2.3.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 12:12:06PM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 07, 2015 at 03:26:58PM +0530, Sudip Mukherjee wrote: > > On Tue, Apr 07, 2015 at 11:44:29AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > > > > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > > > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > > > > > > > I hadn't looked at this driver much before. It sucks that > > > > > parport_driver ->attach() functions can't fail... > > > > > > > > then maybe, we can change the code of parport. currently attach and > > > > parport_register_driver never fails. we can modify it so that if attach > > > > fails then parport_register_driver will also fail. will not be that much > > > > difficult as it has been used only in 13 places. > > > > your views ? > > > > > > > > and since we are discussing parallel ports, few days back i saw one > > > > post in ubuntuforums that his scanner is not working because of > > > > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > > > > with ppscsi anymore. parallel port scanners are almost a thing of the > > > > past > > > > now. do you think it is worth that i pick up the code and modify > > > > it for our latest kernel and submit to Greg ? > > > > > > If you have some parport hardware, and want to take it on, that would be > > > great. The code needs a maintainer, and the apis are _really_ old and > > > messy, as you have found out. > > what kind of parport hardware will you suggest? > > No idea, go look at the drivers and code to figure that out. Not-so-old laptops used to have parport connectors for a while, and can be found at a very cheap price or even for free by now with dead batteries. I've been using mine as a JTAG connector exclusively until I replaced this laptop. A number of old mini-itx boards used to have a parallell port and were easy to hack on (eg: those with a jack power connector, onboard video and a PXE capable NIC to boot the freshly built kernel over the network). They're less easy to find though. If you want to run on your PC, you'll have to order a PCIe parallel port NIC I guess. Cheers, Willy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 04:14:59PM +0200, Willy Tarreau wrote: > > > > > now. do you think it is worth that i pick up the code and modify > > > > > it for our latest kernel and submit to Greg ? > > > > > > > > If you have some parport hardware, and want to take it on, that would be > > > > great. The code needs a maintainer, and the apis are _really_ old and > > > > messy, as you have found out. > > > what kind of parport hardware will you suggest? > > > > No idea, go look at the drivers and code to figure that out. > > Not-so-old laptops used to have parport connectors for a while, and can be > found at a very cheap price or even for free by now with dead batteries. free laptop sounds good.. :) where can i get some? > > A number of old mini-itx boards used to have a parallell port and were easy > to hack on (eg: those with a jack power connector, onboard video and a PXE > capable NIC to boot the freshly built kernel over the network). They're less > easy to find though. > > If you want to run on your PC, you'll have to order a PCIe parallel port NIC > I guess. i already have pc with parallel port, and on that i check your panel codes before sending. but here we were discussing about the required hardware to test ppscsi module. regards sudip > > Cheers, > Willy > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, Apr 07, 2015 at 05:11:15PM +0300, Giedrius Statkevičius wrote: > If one of the allocations of memory for storing a channel information struct > fails then free all the successful allocations and return -ENOMEM that gets > propogated to the pci layer. Also, remove a bogus skipping in the next part > of > the initiation if a previous memory allocation failed because we won't execute > that if any of the allocations failed. Next, remove the misleading comment > that > allocation could happen elsewhere. Finally, remove all (except in the ioctl > which can try to get information about a board that failed to probe) checks if > ->channels[foo] is NULL or not because probe failing if we can't allocate > enough > memory means that this scenario isn't possible. i think now it became too many changes for a single patch.. regards sudip > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8188eu: Replaced kzalloc and memcpy combination with kmemdup
This change was detected with the help of coccinelle tool.
It performs the same function as kzalloc amd memcpy.
Signed-off-by: Chaitanya Dhere
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 86d955f..07ae6cf 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -5431,15 +5431,14 @@ u8 set_tx_beacon_cmd(struct adapter *padapter)
goto exit;
}
- ptxBeacon_parm = kzalloc(sizeof(struct wlan_bssid_ex), GFP_KERNEL);
+ ptxBeacon_parm = kmemdup(&(pmlmeinfo->network),
+sizeof(struct wlan_bssid_ex), GFP_KERNEL);
if (ptxBeacon_parm == NULL) {
kfree(ph2c);
res = _FAIL;
goto exit;
}
- memcpy(ptxBeacon_parm, &(pmlmeinfo->network), sizeof(struct
wlan_bssid_ex));
-
len_diff = update_hidden_ssid(ptxBeacon_parm->IEs+_BEACON_IE_OFFSET_,
ptxBeacon_parm->IELength-_BEACON_IE_OFFSET_,
pmlmeinfo->hidden_ssid_mode);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 7, 2015 at 11:08 AM, Sudip Mukherjee wrote: >> Just run 'git show 6ad6b5ed3e247' in linux-next and you can see such commit. > I have already seen the patch. But being the maintainer of that driver > i hold myself responsible for missing a new file creation in a patch. > So i was trying to search for that patch in my mails and also in lkml, > but i could not find it, so thought of mailing and asking. :( The problem with commit 6ad6b5ed3e247 is this hunk: diff --git a/ret.ou b/ret.ou new file mode 100644 index 000..e69de29 Regards, Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 07, 2015 at 11:24:43AM -0300, Fabio Estevam wrote: > On Tue, Apr 7, 2015 at 11:08 AM, Sudip Mukherjee > wrote: > > >> Just run 'git show 6ad6b5ed3e247' in linux-next and you can see such > >> commit. > > I have already seen the patch. But being the maintainer of that driver > > i hold myself responsible for missing a new file creation in a patch. > > So i was trying to search for that patch in my mails and also in lkml, > > but i could not find it, so thought of mailing and asking. :( > > The problem with commit 6ad6b5ed3e247 is this hunk: > > diff --git a/ret.ou b/ret.ou > new file mode 100644 > index 000..e69de29 that also I have seen.but what I am trying to say is that I am not finding any reference of that patch in my mails or in lkml.org, regards sudip > > Regards, > > Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 07:51:17PM +0530, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 04:14:59PM +0200, Willy Tarreau wrote: > > Not-so-old laptops used to have parport connectors for a while, and can be > > found at a very cheap price or even for free by now with dead batteries. > free laptop sounds good.. :) > where can i get some? Friends replacing theirs in general, or your employer's dead stock :-) > > If you want to run on your PC, you'll have to order a PCIe parallel port NIC s/NIC/card above > > I guess. > i already have pc with parallel port, and on that i check your panel > codes before sending. but here we were discussing about the required > hardware to test ppscsi module. Ah sorry for being out of topic then, I missed this point, I thought it was for PP in general. Regards, Willy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, 7 Apr 2015, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 05:11:15PM +0300, Giedrius Statkevičius wrote: > > If one of the allocations of memory for storing a channel information struct > > fails then free all the successful allocations and return -ENOMEM that gets > > propogated to the pci layer. Also, remove a bogus skipping in the next > > part of > > the initiation if a previous memory allocation failed because we won't > > execute > > that if any of the allocations failed. Next, remove the misleading comment > > that > > allocation could happen elsewhere. Finally, remove all (except in the ioctl > > which can try to get information about a board that failed to probe) checks > > if > > ->channels[foo] is NULL or not because probe failing if we can't allocate > > enough > > memory means that this scenario isn't possible. > > i think now it became too many changes for a single patch.. > > regards > sudip If I split this into two patches then they both would have to be applied and Greg or someone else could miss that one patch depended on another and leave the kernel in a partial state so I think it's best to keep it in one. Lets see what other people have to say. Su pagarba / Regards, Giedrius___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: panel: remove duplicate code
On Tue, Apr 07, 2015 at 12:12:06PM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 07, 2015 at 03:26:58PM +0530, Sudip Mukherjee wrote: > > On Tue, Apr 07, 2015 at 11:44:29AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Apr 07, 2015 at 02:55:02PM +0530, Sudip Mukherjee wrote: > > > > On Tue, Apr 07, 2015 at 11:49:30AM +0300, Dan Carpenter wrote: > > > > > On Tue, Apr 07, 2015 at 01:55:01PM +0530, Sudip Mukherjee wrote: > > > > > > > > > > I hadn't looked at this driver much before. It sucks that > > > > > parport_driver ->attach() functions can't fail... > > > > > > > > then maybe, we can change the code of parport. currently attach and > > > > parport_register_driver never fails. we can modify it so that if attach > > > > fails then parport_register_driver will also fail. will not be that much > > > > difficult as it has been used only in 13 places. > > > > your views ? > > > > > > > > and since we are discussing parallel ports, few days back i saw one > > > > post in ubuntuforums that his scanner is not working because of > > > > lack of ppscsi.I mailed Tim Waugh, but he is not interested to work > > > > with ppscsi anymore. parallel port scanners are almost a thing of the > > > > past > > > > now. do you think it is worth that i pick up the code and modify > > > > it for our latest kernel and submit to Greg ? > > > > > > If you have some parport hardware, and want to take it on, that would be > > > great. The code needs a maintainer, and the apis are _really_ old and > > > messy, as you have found out. > > what kind of parport hardware will you suggest? > > No idea, go look at the drivers and code to figure that out. i guess i asked the question in a wrong way. i already have pc with parport. what i wanted to ask was do i need any other hardware (like parallel port scanner) to start with ppscsi? regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 07, 2015 at 07:26:53PM +0530, Sudip Mukherjee wrote: > Hi Greg, > I saw that you have reveretd one commit > <6ad6b5ed3e2472b399b567a2f036006bf25df467> > "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. > I was trying to search for that patch, but it seems I am not able to > find that in my personal mails nor in lkml. can you please let me know > when it was sent.. It came in through the Outreachy mailing list, as part of the intern application process. Sorry about the extra file, I missed it, it was my fault. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
You will need to update the subject to reflect the new patch.
The original code did check for kzalloc() failure but it had lots of
checks scattered around instead nicely at the point where the memory
was allocated.
The old code and the new code are both buggy though and will crash in
dgnc_tty_uninit(). dgnc_found_board() does "One Err" style error
handling so it's obviously buggy like the underside of a rock.
https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
It's becoming a difficult thing to fix this because every time we look
there are more things which don't make sense.
I believe that if you do:
> +err_free_channels:
> + for (i = i - 1; i >= 0; --i) {
> + kfree(brd->channels[i]);
brd->channels[i] = NULL;
}
> + return -ENOMEM;
> }
And add some NULL checks in dgnc_tty_uninit() to see if ->channels[i] is
NULL before doing:
dgnc_remove_tty_sysfs(brd->channels[i]->ch_tun.un_sysfs);
and
dgnc_remove_tty_sysfs(brd->channels[i]->ch_pun.un_sysfs);
Then it will fix the bug.
Eventually we will want to clean up dgnc_found_board() error handling
and get rid of brd->dgnc_Major_TransparentPrint_Registered etc.
TODO: dgnc: cleanup dgnc_found_board().
> diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
> index e3564d2..a629a78 100644
> --- a/drivers/staging/dgnc/dgnc_cls.c
> +++ b/drivers/staging/dgnc/dgnc_cls.c
> @@ -379,7 +379,7 @@ static inline void cls_parse_isr(struct dgnc_board *brd,
> uint port)
> return;
>
> ch = brd->channels[port];
> - if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
> + if (ch->magic != DGNC_CHANNEL_MAGIC)
> return;
>
> /* Here we try to figure out what caused the interrupt to happen */
> @@ -714,8 +714,6 @@ static void cls_tasklet(unsigned long data)
> /* Loop on each port */
> for (i = 0; i < ports; i++) {
> ch = bd->channels[i];
> - if (!ch)
> - continue;
>
> /*
>* NOTE: Remember you CANNOT hold any channel
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
> index f5a4d36..1e583c2 100644
> --- a/drivers/staging/dgnc/dgnc_neo.c
> +++ b/drivers/staging/dgnc/dgnc_neo.c
> @@ -395,7 +395,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
> uint port)
> return;
>
> ch = brd->channels[port];
> - if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
> + if (ch->magic != DGNC_CHANNEL_MAGIC)
> return;
>
Do these in a separate patch. I'm looking for ways we can make this
patch minimal. Deleting the comments and the NULL check in
dgnc_tty_init() is essential for the patch because otherwise the cleanup
doesn't make sense.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
If you send a patch series then it's ok that later patches depend on the earlier patches. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 07, 2015 at 04:34:54PM +0200, Greg KH wrote: > On Tue, Apr 07, 2015 at 07:26:53PM +0530, Sudip Mukherjee wrote: > > Hi Greg, > > I saw that you have reveretd one commit > > <6ad6b5ed3e2472b399b567a2f036006bf25df467> > > "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. > > I was trying to search for that patch, but it seems I am not able to > > find that in my personal mails nor in lkml. can you please let me know > > when it was sent.. > > It came in through the Outreachy mailing list, as part of the intern > application process. Sorry about the extra file, I missed it, it was my > fault. can i, in any way, help in the Outreachy? regards sudip > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: commit reverted in staging/sm750fb
On Tue, Apr 07, 2015 at 08:31:44PM +0530, Sudip Mukherjee wrote: > On Tue, Apr 07, 2015 at 04:34:54PM +0200, Greg KH wrote: > > On Tue, Apr 07, 2015 at 07:26:53PM +0530, Sudip Mukherjee wrote: > > > Hi Greg, > > > I saw that you have reveretd one commit > > > <6ad6b5ed3e2472b399b567a2f036006bf25df467> > > > "Staging: sm750fb: Fix C99 Comments" in staging/sm750fb. > > > I was trying to search for that patch, but it seems I am not able to > > > find that in my personal mails nor in lkml. can you please let me know > > > when it was sent.. > > > > It came in through the Outreachy mailing list, as part of the intern > > application process. Sorry about the extra file, I missed it, it was my > > fault. > can i, in any way, help in the Outreachy? The application process is all over now, so thanks for the offer. Next round of applications will happen in 6 months, and we can always use review help for the patches that come in. Just let me know then and I'll be glad to point you at the proper lists. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, 7 Apr 2015, Dan Carpenter wrote:
> You will need to update the subject to reflect the new patch.
>
> The original code did check for kzalloc() failure but it had lots of
> checks scattered around instead nicely at the point where the memory
> was allocated.
>
There are a lot missing too. For example in dgnc_sysfs.c there are no checks on
any _show() methods if ->channels[i] is NULL or not. And in some other places.
> The old code and the new code are both buggy though and will crash in
> dgnc_tty_uninit(). dgnc_found_board() does "One Err" style error
> handling so it's obviously buggy like the underside of a rock.
> https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
>
> It's becoming a difficult thing to fix this because every time we look
> there are more things which don't make sense.
>
> I believe that if you do:
>
> > +err_free_channels:
> > + for (i = i - 1; i >= 0; --i) {
> > + kfree(brd->channels[i]);
> brd->channels[i] = NULL;
> }
> > + return -ENOMEM;
> > }
>
> And add some NULL checks in dgnc_tty_uninit() to see if ->channels[i] is
> NULL before doing:
>
> dgnc_remove_tty_sysfs(brd->channels[i]->ch_tun.un_sysfs);
>
> and
> dgnc_remove_tty_sysfs(brd->channels[i]->ch_pun.un_sysfs);
>
> Then it will fix the bug.
>
Missed this. Yep, I agree.
> Do these in a separate patch. I'm looking for ways we can make this
> patch minimal. Deleting the comments and the NULL check in
> dgnc_tty_init() is essential for the patch because otherwise the cleanup
> doesn't make sense.
Well, the point of the patch is to put alloc and checks in one place to make the
code less error and bug prone and fix some of bugs where ->channels[i] isn't
checked. Ok, I'll send a v5 that's split into two patches.
>
> regards,
> dan carpenter
>
>
Su pagarba / Regards,
Giedrius
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: check if kzalloc fails in dgnc_tty_init()
On Tue, Apr 07, 2015 at 06:35:51PM +0300, Giedrius Statkevičius wrote: > Well, the point of the patch is to put alloc and checks in one place to make > the > code less error and bug prone and fix some of bugs where ->channels[i] isn't > checked. Fine, fine. I can accept that. One patch is also ok. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] staging: lustre: Make cfs_sched_rehash static
If you checked the code, you would see that it's used in
drivers/staging/lustre/lustre/libcfs/module.c too.
drivers/staging/lustre/lustre/libcfs/module.c:extern struct cfs_wi_sched
*cfs_sched_rehash;
drivers/staging/lustre/lustre/libcfs/module.c: rc,
&cfs_sched_rehash);
drivers/staging/lustre/lustre/libcfs/module.c: if (cfs_sched_rehash != NULL) {
drivers/staging/lustre/lustre/libcfs/module.c:
cfs_wi_sched_destroy(cfs_sched_rehash);
drivers/staging/lustre/lustre/libcfs/module.c: cfs_sched_rehash = NULL;
On Apr 6, 2015, at 10:02 PM, Nickolaus Woodruff wrote:
> This patch fixes the following sparse warning:
>
> CHECK drivers/staging/lustre/lustre/libcfs/hash.c
> drivers/staging/lustre/lustre/libcfs/hash.c:119:21: warning: symbol
> 'cfs_sched_rehash' was not declared. Should it be static?
>
> Signed-off-by: Nickolaus Woodruff
> ---
> drivers/staging/lustre/lustre/libcfs/hash.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c
> b/drivers/staging/lustre/lustre/libcfs/hash.c
> index a55567e..a4920a2 100644
> --- a/drivers/staging/lustre/lustre/libcfs/hash.c
> +++ b/drivers/staging/lustre/lustre/libcfs/hash.c
> @@ -116,7 +116,7 @@ module_param(warn_on_depth, uint, 0644);
> MODULE_PARM_DESC(warn_on_depth, "warning when hash depth is high.");
> #endif
>
> -struct cfs_wi_sched *cfs_sched_rehash;
> +static struct cfs_wi_sched *cfs_sched_rehash;
>
> static inline void
> cfs_hash_nl_lock(union cfs_hash_lock *lock, int exclusive) {}
> --
> 1.9.1
>
> ___
> HPDD-discuss mailing list
> hpdd-disc...@lists.01.org
> https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/3] staging: dgnc: clean up allocation of ->channels[i]
Check if kzalloc fails in dgnc_tty_init() and if it does then free all
previously allocated ->channels[i] and set them to NULL. This makes the code
less error/bug prone because instead of needing programmers attention to add
checks everywhere we do that in one place. Also, remove a bogus comment and
check in the same loop because ->channels[i] isn't allocated anywhere else.
Finally, remove a unnecessary check if ->channels[i] is NULL in the next loop
because it can't be.
Signed-off-by: Giedrius Statkevičius
---
v4: Make this patch only for dgnc_tty.c and only for this thing. Split into 3
patches (1 patch fixes a bug reported by Dan Carpenter)
v3: Remove the wrong comment at dgnc_tty_init() that says the allocation could
happen somewhere else before this and remove the check if (!brd->channels[i]).
Also, remove all checks where ->channels[i] is checked if it's NULL or not
because if probe fails then that means that this scenario isn't possible (except
in the ioctl).
v2: Only returning -ENOMEM if an allocation failed isn't enough as it was
spotted by Sudip so create a new label that frees all successfully allocated
stuff and only then returns -ENOMEM. Also, remove a unnecessary check in the
next loop.
drivers/staging/dgnc/dgnc_tty.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ce4187f..0e48f95 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -304,19 +304,15 @@ int dgnc_tty_init(struct dgnc_board *brd)
brd->nasync = brd->maxports;
- /*
-* Allocate channel memory that might not have been allocated
-* when the driver was first loaded.
-*/
for (i = 0; i < brd->nasync; i++) {
- if (!brd->channels[i]) {
-
- /*
-* Okay to malloc with GFP_KERNEL, we are not at
-* interrupt context, and there are no locks held.
-*/
- brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
GFP_KERNEL);
- }
+ /*
+* Okay to malloc with GFP_KERNEL, we are not at
+* interrupt context, and there are no locks held.
+*/
+ brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
+ GFP_KERNEL);
+ if (!brd->channels[i])
+ goto err_free_channels;
}
ch = brd->channels[0];
@@ -324,10 +320,6 @@ int dgnc_tty_init(struct dgnc_board *brd)
/* Set up channel variables */
for (i = 0; i < brd->nasync; i++, ch = brd->channels[i]) {
-
- if (!brd->channels[i])
- continue;
-
spin_lock_init(&ch->ch_lock);
/* Store all our magic numbers */
@@ -375,6 +367,13 @@ int dgnc_tty_init(struct dgnc_board *brd)
}
return 0;
+
+err_free_channels:
+ for (i = i - 1; i >= 0; --i) {
+ kfree(brd->channels[i]);
+ brd->channels[i] = NULL;
+ }
+ return -ENOMEM;
}
--
2.3.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 3/3] staging: dgnc: remove redundant !ch checks
Remove checks that are redundant since we don't have boards with partially initialized ->channels[i]. Signed-off-by: Giedrius Statkevičius --- v4: splitted this from the one patch. drivers/staging/dgnc/dgnc_cls.c | 4 ++-- drivers/staging/dgnc/dgnc_neo.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c index e3564d2..82e8680 100644 --- a/drivers/staging/dgnc/dgnc_cls.c +++ b/drivers/staging/dgnc/dgnc_cls.c @@ -379,7 +379,7 @@ static inline void cls_parse_isr(struct dgnc_board *brd, uint port) return; ch = brd->channels[port]; - if (!ch || ch->magic != DGNC_CHANNEL_MAGIC) + if (ch->magic != DGNC_CHANNEL_MAGIC) return; /* Here we try to figure out what caused the interrupt to happen */ @@ -691,7 +691,7 @@ static void cls_tasklet(unsigned long data) int state = 0; int ports = 0; - if (!bd || bd->magic != DGNC_BOARD_MAGIC) + if (bd->magic != DGNC_BOARD_MAGIC) return; /* Cache a couple board values */ diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c index f5a4d36..1e583c2 100644 --- a/drivers/staging/dgnc/dgnc_neo.c +++ b/drivers/staging/dgnc/dgnc_neo.c @@ -395,7 +395,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd, uint port) return; ch = brd->channels[port]; - if (!ch || ch->magic != DGNC_CHANNEL_MAGIC) + if (ch->magic != DGNC_CHANNEL_MAGIC) return; /* Here we try to figure out what caused the interrupt to happen */ -- 2.3.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 2/3] staging: dgnc: don't forget to check if ->channels[i] is NULL in dgnc_tty_uninit()
Add a check if ->channels[i] is NULL because a NULL pointer may be dereferenced
in case one of the allocations failed
Reported-by: Dan Carpenter
Signed-off-by: Giedrius Statkevičius
---
v4: new patch that fixes a bug reported by Dan Carpenter
drivers/staging/dgnc/dgnc_tty.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 0e48f95..785eb6c 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -403,7 +403,9 @@ void dgnc_tty_uninit(struct dgnc_board *brd)
dgnc_BoardsByMajor[brd->SerialDriver.major] = NULL;
brd->dgnc_Serial_Major = 0;
for (i = 0; i < brd->nasync; i++) {
-
dgnc_remove_tty_sysfs(brd->channels[i]->ch_tun.un_sysfs);
+ if (brd->channels[i])
+ dgnc_remove_tty_sysfs(brd->channels[i]->
+ ch_tun.un_sysfs);
tty_unregister_device(&brd->SerialDriver, i);
}
tty_unregister_driver(&brd->SerialDriver);
@@ -414,7 +416,9 @@ void dgnc_tty_uninit(struct dgnc_board *brd)
dgnc_BoardsByMajor[brd->PrintDriver.major] = NULL;
brd->dgnc_TransparentPrint_Major = 0;
for (i = 0; i < brd->nasync; i++) {
-
dgnc_remove_tty_sysfs(brd->channels[i]->ch_pun.un_sysfs);
+ if (brd->channels[i])
+ dgnc_remove_tty_sysfs(brd->channels[i]->
+ ch_pun.un_sysfs);
tty_unregister_device(&brd->PrintDriver, i);
}
tty_unregister_driver(&brd->PrintDriver);
--
2.3.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: fix all print warnings reported by sparse
Signed-off-by: Marcus Folkesson
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
drivers/staging/fbtft/fbtft-io.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 37dcf7e..b82870b 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1000,7 +1000,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
fbtft_sysfs_init(par);
if (par->txbuf.buf)
- sprintf(text1, ", %d KiB %sbuffer memory",
+ sprintf(text1, ", %zu KiB %sbuffer memory",
par->txbuf.len >> 10, par->txbuf.dma ? "DMA " : "");
if (spi)
sprintf(text2, ", spi%d.%d at %d MHz", spi->master->bus_num,
diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c
index 32155a7..9b2f8cf 100644
--- a/drivers/staging/fbtft/fbtft-io.c
+++ b/drivers/staging/fbtft/fbtft-io.c
@@ -59,7 +59,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void
*buf, size_t len)
}
if ((len % 8) != 0) {
dev_err(par->info->device,
- "%s: error: len=%d must be divisible by 8\n",
+ "%s: error: len=%zu must be divisible by 8\n",
__func__, len);
return -EINVAL;
}
@@ -106,7 +106,7 @@ int fbtft_read_spi(struct fbtft_par *par, void *buf, size_t
len)
if (par->startbyte) {
if (len > 32) {
dev_err(par->info->device,
- "%s: len=%d can't be larger than 32 when using
'startbyte'\n",
+ "%s: len=%zu can't be larger than 32 when using
'startbyte'\n",
__func__, len);
return -EINVAL;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,1/3] hv_netvsc: Clean up two unused variables
From: Haiyang Zhang Date: Mon, 6 Apr 2015 15:22:52 -0700 > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,2/3] hv_netvsc: Define a macro RNDIS_AND_PPI_SIZE
From: Haiyang Zhang Date: Mon, 6 Apr 2015 15:22:53 -0700 > The sum of RNDIS msg and PPI struct sizes is used in multiple places, so we > define > a macro for them. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,3/3] hv_netvsc: Fix the packet free when it is in skb headroom
From: Haiyang Zhang Date: Mon, 6 Apr 2015 15:22:54 -0700 > In the two places changed, we now use netvsc_xmit_completion() which properly > frees hv_netvsc_packet in or not in skb headroom. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/8] staging: rtl8192e: Fix more checkpatch.pl warnings
This series of patches fixes another set of checkpatch.pl warnings. Most of the patches are trivial, with the exception of #8, #7 and #5; Driver logic should not be affected. Some of the patches cause LONG_LINE warnings, but fix has to wait until I do more driver refactorings (It's hard to keep line length when variable names have 30 characters). Series should apply to staging-next/testing (c610f7f7). Smoke tested on rtl8192e card vs staging-next: - Module load/unload - Interface up/down Mateusz Kulikowski (8): staging: rtl8192e: Fix SPACE_BEFORE_TAB warnings staging: rtl8192e: Copy comments from r819XE_phyreg.h to r8192E_phyreg.h staging: rtl8192e: remove r819xE_phyreg.h staging: rtl8192e: Fix SPACING errors staging: rtl8192e: Remove bb tx gains from r8192_priv staging: rtl8192e: Fix LINE_SPACING warning staging: rtl8192e: Fix DEEP_INDENTATION warnings in rtllib_parse_info_param() staging: rtl8192e: Fix DEEP_INDENTATION warnings in rtl_dm.c drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c|5 +- drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c|2 +- drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h | 1496 +++-- drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h | 908 - drivers/staging/rtl8192e/rtl8192e/rtl_core.c |6 +- drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 20 +- drivers/staging/rtl8192e/rtl8192e/rtl_dm.c| 821 +++ drivers/staging/rtl8192e/rtl8192e/rtl_dm.h|9 + drivers/staging/rtl8192e/rtllib_debug.h |3 +- drivers/staging/rtl8192e/rtllib_rx.c | 23 +- 10 files changed, 1014 insertions(+), 2279 deletions(-) delete mode 100644 drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h -- 1.8.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/8] staging: rtl8192e: Fix SPACE_BEFORE_TAB warnings
Reformat r8192E_phyreg.h to make checkpatch happy. Signed-off-by: Mateusz Kulikowski --- drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h | 1442 ++--- 1 file changed, 721 insertions(+), 721 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h b/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h index 7899dd5..d080876 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h @@ -3,7 +3,7 @@ * * This program is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * * You should have received a copy of the GNU General Public License along with @@ -20,48 +20,48 @@ #define _R819XU_PHYREG_H -#define RF_DATA 0x1d4 - -#define rPMAC_Reset0x100 -#define rPMAC_TxStart 0x104 -#define rPMAC_TxLegacySIG 0x108 -#define rPMAC_TxHTSIG1 0x10c -#define rPMAC_TxHTSIG2 0x110 -#define rPMAC_PHYDebug 0x114 -#define rPMAC_TxPacketNum 0x118 -#define rPMAC_TxIdle 0x11c -#define rPMAC_TxMACHeader0 0x120 -#define rPMAC_TxMACHeader1 0x124 -#define rPMAC_TxMACHeader2 0x128 -#define rPMAC_TxMACHeader3 0x12c -#define rPMAC_TxMACHeader4 0x130 -#define rPMAC_TxMACHeader5 0x134 -#define rPMAC_TxDataType 0x138 -#define rPMAC_TxRandomSeed 0x13c -#define rPMAC_CCKPLCPPreamble 0x140 -#define rPMAC_CCKPLCPHeader0x144 -#define rPMAC_CCKCRC16 0x148 -#define rPMAC_OFDMRxCRC32OK0x170 -#define rPMAC_OFDMRxCRC32Er0x174 -#define rPMAC_OFDMRxParityEr 0x178 -#define rPMAC_OFDMRxCRC8Er 0x17c -#define rPMAC_CCKCRxRC16Er 0x180 -#define rPMAC_CCKCRxRC32Er 0x184 -#define rPMAC_CCKCRxRC32OK 0x188 -#define rPMAC_TxStatus 0x18c - -#defineMCS_TXAGC 0x340 -#defineCCK_TXAGC 0x348 +#define RF_DATA0x1d4 + +#define rPMAC_Reset0x100 +#define rPMAC_TxStart 0x104 +#define rPMAC_TxLegacySIG 0x108 +#define rPMAC_TxHTSIG1 0x10c +#define rPMAC_TxHTSIG2 0x110 +#define rPMAC_PHYDebug 0x114 +#define rPMAC_TxPacketNum 0x118 +#define rPMAC_TxIdle 0x11c +#define rPMAC_TxMACHeader0 0x120 +#define rPMAC_TxMACHeader1 0x124 +#define rPMAC_TxMACHeader2 0x128 +#define rPMAC_TxMACHeader3 0x12c +#define rPMAC_TxMACHeader4 0x130 +#define rPMAC_TxMACHeader5 0x134 +#define rPMAC_TxDataType 0x138 +#define rPMAC_TxRandomSeed 0x13c +#define rPMAC_CCKPLCPPreamble 0x140 +#define rPMAC_CCKPLCPHeader0x144 +#define rPMAC_CCKCRC16 0x148 +#define rPMAC_OFDMRxCRC32OK0x170 +#define rPMAC_OFDMRxCRC32Er0x174 +#define rPMAC_OFDMRxParityEr 0x178 +#define rPMAC_OFDMRxCRC8Er 0x17c +#define rPMAC_CCKCRxRC16Er 0x180 +#define rPMAC_CCKCRxRC32Er 0x184 +#define rPMAC_CCKCRxRC32OK 0x188 +#define rPMAC_TxStatus 0x18c + +#define MCS_TXAGC 0x340 +#define CCK_TXAGC 0x348 /*-0x400~0x4ff--*/ -#defineMacBlkCtrl 0x403 - -#define rFPGA0_RFMOD 0x800 -#define rFPGA0_TxInfo 0x804 -#define rFPGA0_PSDFunction 0x808 -#define rFPGA0_TxGainStage 0x80c -#define rFPGA0_RFTiming1 0x810 -#define rFPGA0_RFTiming2 0x814 +#define MacBlkCtrl 0x403 + +#define rFPGA0_RFMOD 0x800 +#define rFPGA0_TxInfo 0x804 +#define rFPGA0_PSDFunction 0x808 +#define rFPGA0_TxGainStage 0x80c +#define rFPGA0_RFTiming1 0x810 +#define rFPGA0_RFTiming2 0x814 #define rFPGA0_XA_HSSIParameter1 0x820 #define rFPGA0_XA_HSSIParameter2 0x824 #define rFPGA0_XB_HSSIParameter1 0x828 @@ -94,49 +94,49 @@ #define rFPGA0_XB_LSSIReadBack 0x8a4 #define rFPGA0_XC_LSSIReadBack 0x8a8 #define rFPGA0_XD_LSSIReadBack 0x8ac -#define rFPGA0_PSDReport 0x8b4 +#define rFPGA0_PSDReport 0x8b4 #define rFPGA0_XAB_RFInterfaceRB 0x8e0 #define rFPGA0_XCD_RFInterfaceRB 0x8e4 -#define rFPGA1_RFMOD 0x900 -#de
[PATCH 2/8] staging: rtl8192e: Copy comments from r819XE_phyreg.h to r8192E_phyreg.h
Both files have the same contents (with the exception of comments). One of them will not survive future commits. Signed-off-by: Mateusz Kulikowski --- drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h | 92 --- 1 file changed, 65 insertions(+), 27 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h b/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h index d080876..8a1d91e 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h @@ -53,10 +53,10 @@ #define MCS_TXAGC 0x340 #define CCK_TXAGC 0x348 -/*-0x400~0x4ff--*/ +/* Mac block on/off control register */ #define MacBlkCtrl 0x403 -#define rFPGA0_RFMOD 0x800 +#define rFPGA0_RFMOD 0x800 /* RF mode & CCK TxSC */ #define rFPGA0_TxInfo 0x804 #define rFPGA0_PSDFunction 0x808 #define rFPGA0_TxGainStage 0x80c @@ -98,6 +98,7 @@ #define rFPGA0_XAB_RFInterfaceRB 0x8e0 #define rFPGA0_XCD_RFInterfaceRB 0x8e4 +/* Page 9 - RF mode & OFDM TxSC */ #define rFPGA1_RFMOD 0x900 #define rFPGA1_TxBlock 0x904 #define rFPGA1_DebugSelect 0x908 @@ -106,14 +107,16 @@ #define rCCK0_System 0xa00 #define rCCK0_AFESetting 0xa04 #define rCCK0_CCA 0xa08 +/* AGC default value, saturation level */ #define rCCK0_RxAGC1 0xa0c -#define rCCK0_RxAGC2 0xa10 +#define rCCK0_RxAGC2 0xa10 /* AGC & DAGC */ #define rCCK0_RxHP 0xa14 +/* Timing recovery & channel estimation threshold */ #define rCCK0_DSPParameter10xa18 -#define rCCK0_DSPParameter20xa1c +#define rCCK0_DSPParameter20xa1c /* SQ threshold */ #define rCCK0_TxFilter10xa20 #define rCCK0_TxFilter20xa24 -#define rCCK0_DebugPort0xa28 +#define rCCK0_DebugPort0xa28 /* Debug port and TX filter 3 */ #define rCCK0_FalseAlarmReport 0xa2c #define rCCK0_TRSSIReport 0xa50 #define rCCK0_RxReport 0xa54 @@ -124,22 +127,24 @@ #define rOFDM0_TRxPathEnable 0xc04 #define rOFDM0_TRMuxPar0xc08 #define rOFDM0_TRSWIsolation 0xc0c +/* RxIQ DC offset, Rx digital filter, DC notch filter */ #define rOFDM0_XARxAFE 0xc10 -#define rOFDM0_XARxIQImbalance 0xc14 +#define rOFDM0_XARxIQImbalance 0xc14 /* RxIQ imbalance matrix */ #define rOFDM0_XBRxAFE 0xc18 #define rOFDM0_XBRxIQImbalance 0xc1c #define rOFDM0_XCRxAFE 0xc20 #define rOFDM0_XCRxIQImbalance 0xc24 #define rOFDM0_XDRxAFE 0xc28 #define rOFDM0_XDRxIQImbalance 0xc2c -#define rOFDM0_RxDetector1 0xc30 -#define rOFDM0_RxDetector2 0xc34 -#define rOFDM0_RxDetector3 0xc38 +#define rOFDM0_RxDetector1 0xc30 /* PD, BW & SBD */ +#define rOFDM0_RxDetector2 0xc34 /* SBD */ +#define rOFDM0_RxDetector3 0xc38 /* Frame Sync */ +/* PD, SBD, Frame Sync & Short-GI */ #define rOFDM0_RxDetector4 0xc3c -#define rOFDM0_RxDSP 0xc40 -#define rOFDM0_CFOandDAGC 0xc44 +#define rOFDM0_RxDSP 0xc40 /* Rx Sync Path */ +#define rOFDM0_CFOandDAGC 0xc44 /* CFO & DAGC */ #define rOFDM0_CCADropThreshold0xc48 -#define rOFDM0_ECCAThreshold 0xc4c +#define rOFDM0_ECCAThreshold 0xc4c /* Energy CCA */ #define rOFDM0_XAAGCCore1 0xc50 #define rOFDM0_XAAGCCore2 0xc54 #define rOFDM0_XBAGCCore1 0xc58 @@ -184,9 +189,9 @@ #define rOFDM1_PseudoNoiseStateAB 0xd50 #define rOFDM1_PseudoNoiseStateCD 0xd54 #define rOFDM1_RxPseudoNoiseWgt0xd58 -#define rOFDM_PHYCounter1 0xda0 -#define rOFDM_PHYCounter2 0xda4 -#define rOFDM_PHYCounter3 0xda8 +#define rOFDM_PHYCounter1 0xda0 /* cca, parity fail */ +#define rOFDM_PHYCounter2 0xda4 /* rate illegal, crc8 fail */ +#define rOFDM_PHYCounter3 0xda8 /* MCS not supported */ #define rOFDM_ShortCFOAB 0xdac #define rOFDM_ShortCFOCD 0xdb0 #define rOFDM_LongCFOAB0xdb4 @@ -221,14 +226,17 @@ #define rZebra1_RxLPF 0xb #define rZebra1_RxHPFCorner0xc +/* Zebra 4 */ #define rGlobalCtrl0 #define rRTL8256_TxLPF 19 #define rRTL8256_RxLPF 11 +/* RTL8258 */ #define rRTL8258_TxLPF 0x11 #define rRTL8258_RxLPF 0x13 #define rRTL8258_RSSILPF 0xa
[PATCH 6/8] staging: rtl8192e: Fix LINE_SPACING warning
Trivial fix - add newline in dm_InitializeTXPowerTracking_TSSI()
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index c99d584..9de5846 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -941,6 +941,7 @@ static void dm_InitializeTXPowerTracking_TSSI(struct
net_device *dev)
{
struct r8192_priv *priv = rtllib_priv(dev);
+
priv->btxpower_tracking = true;
priv->txpower_count = 0;
priv->btxpower_trackingInit = false;
--
1.8.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/8] staging: rtl8192e: Remove bb tx gains from r8192_priv
r8192_priv structure had 2 big arrays with tx gain register values:
- cck_txbbgain_table
- cck_txbbgain_ch14_table
- txbbgain_table
This arrays were read-only - filled in driver init code and look
like firmware/chip-specific.
This patch removes them from r8192_priv and puts them in (global) variables.
tx_bb_gain is also flattened - register values are stored in array;
Amplification value can be calculated using dm_tx_bb_gain_idx_to_amplify().
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 5 +-
drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 14 -
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 674 +
drivers/staging/rtl8192e/rtl8192e/rtl_dm.h | 9 +
4 files changed, 151 insertions(+), 551 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index 2869602..aad5cc9 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -918,8 +918,7 @@ start:
tmpRegC = rtl8192_QueryBBReg(dev,
rOFDM0_XCTxIQImbalance, bMaskDWord);
for (i = 0; i < TxBBGainTableLength; i++) {
- if (tmpRegA ==
- priv->txbbgain_table[i].txbbgain_value) {
+ if (tmpRegA == dm_tx_bb_gain[i]) {
priv->rfa_txpowertrackingindex = (u8)i;
priv->rfa_txpowertrackingindex_real =
(u8)i;
@@ -933,7 +932,7 @@ start:
rCCK0_TxFilter1, bMaskByte2);
for (i = 0; i < CCKTxBBGainTableLength; i++) {
- if (TempCCk ==
priv->cck_txbbgain_table[i].ccktxbb_valuearray[0]) {
+ if (TempCCk == dm_cck_tx_bb_gain[i][0]) {
priv->CCKPresentAttentuation_20Mdefault
= (u8)i;
break;
}
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
index a6279e7..0640e76 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
@@ -451,15 +451,6 @@ enum two_port_status {
TWO_PORT_STATUS__WITHOUT_ANY_ASSOCIATE
};
-struct txbbgain_struct {
- longtxbb_iq_amplifygain;
- u32 txbbgain_value;
-};
-
-struct ccktxbbgain {
- u8 ccktxbb_valuearray[8];
-};
-
struct init_gain {
u8 xaagccore1;
u8 xbagccore1;
@@ -567,11 +558,6 @@ struct r8192_priv {
struct bb_reg_definition PHYRegDef[4];
struct rate_adaptive rate_adaptive;
- struct ccktxbbgain cck_txbbgain_table[CCKTxBBGainTableLength];
- struct ccktxbbgain cck_txbbgain_ch14_table[CCKTxBBGainTableLength];
-
- struct txbbgain_struct txbbgain_table[TxBBGainTableLength];
-
enum acm_method AcmMethod;
struct rt_firmware *pFirmware;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index df4bbcf..c99d584 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -60,6 +60,99 @@ static u32 edca_setting_UL[HT_IOT_PEER_MAX] = {
#define RTK_UL_EDCA 0xa44f
#define RTK_DL_EDCA 0x5e4322
+
+const u32 dm_tx_bb_gain[TxBBGainTableLength] = {
+ 0x7f8001fe, /* 12 dB */
+ 0x788001e2, /* 11 dB */
+ 0x71c001c7,
+ 0x6b8001ae,
+ 0x65400195,
+ 0x5fc0017f,
+ 0x5a400169,
+ 0x55400155,
+ 0x50800142,
+ 0x4c000130,
+ 0x47c0011f,
+ 0x43c0010f,
+ 0x4100,
+ 0x3c8000f2,
+ 0x39e4,
+ 0x35c000d7,
+ 0x32c000cb,
+ 0x30c0,
+ 0x2d4000b5,
+ 0x2ac000ab,
+ 0x288000a2,
+ 0x2698,
+ 0x2490,
+ 0x2288,
+ 0x2080,
+ 0x1a6c,
+ 0x1c800072,
+ 0x1860,
+ 0x19800066,
+ 0x15800056,
+ 0x26c0005b,
+ 0x14400051,
+ 0x24400051,
+ 0x134c,
+ 0x1248,
+ 0x1144,
+ 0x1040, /* -24 dB */
+};
+
+const u8 dm_cck_tx_bb_gain[CCKTxBBGainTableLength][8] = {
+ {0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04},
+ {0x33, 0x32, 0x2b, 0x23, 0x1a, 0x11, 0x08, 0x04},
+ {0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03},
+ {0x2d, 0x2d, 0x27, 0x1f, 0x18, 0x0f, 0x08, 0x03},
+ {0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03},
+ {0x28, 0x28, 0x22, 0x1c, 0x15, 0x0d, 0x07, 0x03},
+ {0x26, 0x25, 0x21, 0x1b, 0x14, 0x0d, 0x06, 0x03},
+ {0x24, 0x23, 0x1f, 0x19, 0x13, 0x0c, 0x06, 0x03},
+ {0x22, 0x21, 0x1d, 0x18, 0x11, 0x0b, 0x06, 0x02},
+ {0x20, 0x
[PATCH 3/8] staging: rtl8192e: remove r819xE_phyreg.h
This file is not used and its contents are duplicated in r8192E_phyreg.h. Signed-off-by: Mateusz Kulikowski --- drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h | 908 -- 1 file changed, 908 deletions(-) delete mode 100644 drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h diff --git a/drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h b/drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h deleted file mode 100644 index 03eee3d..000 --- a/drivers/staging/rtl8192e/rtl8192e/r819xE_phyreg.h +++ /dev/null @@ -1,908 +0,0 @@ -#ifndef _R819XU_PHYREG_H -#define _R819XU_PHYREG_H - - -#define RF_DATA 0x1d4 // FW will write RF data in the register. - -//Register //duplicate register due to connection: RF_Mode, TRxRN, NumOf L-STF -//page 1 -#define rPMAC_Reset0x100 -#define rPMAC_TxStart 0x104 -#define rPMAC_TxLegacySIG 0x108 -#define rPMAC_TxHTSIG1 0x10c -#define rPMAC_TxHTSIG2 0x110 -#define rPMAC_PHYDebug 0x114 -#define rPMAC_TxPacketNum 0x118 -#define rPMAC_TxIdle 0x11c -#define rPMAC_TxMACHeader0 0x120 -#define rPMAC_TxMACHeader1 0x124 -#define rPMAC_TxMACHeader2 0x128 -#define rPMAC_TxMACHeader3 0x12c -#define rPMAC_TxMACHeader4 0x130 -#define rPMAC_TxMACHeader5 0x134 -#define rPMAC_TxDataType 0x138 -#define rPMAC_TxRandomSeed 0x13c -#define rPMAC_CCKPLCPPreamble 0x140 -#define rPMAC_CCKPLCPHeader0x144 -#define rPMAC_CCKCRC16 0x148 -#define rPMAC_OFDMRxCRC32OK0x170 -#define rPMAC_OFDMRxCRC32Er0x174 -#define rPMAC_OFDMRxParityEr 0x178 -#define rPMAC_OFDMRxCRC8Er 0x17c -#define rPMAC_CCKCRxRC16Er 0x180 -#define rPMAC_CCKCRxRC32Er 0x184 -#define rPMAC_CCKCRxRC32OK 0x188 -#define rPMAC_TxStatus 0x18c - -//90P -#defineMCS_TXAGC 0x340 // MCS AGC -#defineCCK_TXAGC 0x348 // CCK AGC - -#defineMacBlkCtrl 0x403 // Mac block on/off control register - -//page8 -#define rFPGA0_RFMOD 0x800 //RF mode & CCK TxSC -#define rFPGA0_TxInfo 0x804 -#define rFPGA0_PSDFunction 0x808 -#define rFPGA0_TxGainStage 0x80c -#define rFPGA0_RFTiming1 0x810 -#define rFPGA0_RFTiming2 0x814 -//#define rFPGA0_XC_RFTiming 0x818 -//#define rFPGA0_XD_RFTiming 0x81c -#define rFPGA0_XA_HSSIParameter1 0x820 -#define rFPGA0_XA_HSSIParameter2 0x824 -#define rFPGA0_XB_HSSIParameter1 0x828 -#define rFPGA0_XB_HSSIParameter2 0x82c -#define rFPGA0_XC_HSSIParameter1 0x830 -#define rFPGA0_XC_HSSIParameter2 0x834 -#define rFPGA0_XD_HSSIParameter1 0x838 -#define rFPGA0_XD_HSSIParameter2 0x83c -#define rFPGA0_XA_LSSIParameter0x840 -#define rFPGA0_XB_LSSIParameter0x844 -#define rFPGA0_XC_LSSIParameter0x848 -#define rFPGA0_XD_LSSIParameter0x84c -#define rFPGA0_RFWakeUpParameter 0x850 -#define rFPGA0_RFSleepUpParameter 0x854 -#define rFPGA0_XAB_SwitchControl 0x858 -#define rFPGA0_XCD_SwitchControl 0x85c -#define rFPGA0_XA_RFInterfaceOE0x860 -#define rFPGA0_XB_RFInterfaceOE0x864 -#define rFPGA0_XC_RFInterfaceOE0x868 -#define rFPGA0_XD_RFInterfaceOE0x86c -#define rFPGA0_XAB_RFInterfaceSW 0x870 -#define rFPGA0_XCD_RFInterfaceSW 0x874 -#define rFPGA0_XAB_RFParameter 0x878 -#define rFPGA0_XCD_RFParameter 0x87c -#define rFPGA0_AnalogParameter10x880 -#define rFPGA0_AnalogParameter20x884 -#define rFPGA0_AnalogParameter30x888 -#define rFPGA0_AnalogParameter40x88c -#define rFPGA0_XA_LSSIReadBack 0x8a0 -#define rFPGA0_XB_LSSIReadBack 0x8a4 -#define rFPGA0_XC_LSSIReadBack 0x8a8 -#define rFPGA0_XD_LSSIReadBack 0x8ac -#define rFPGA0_PSDReport 0x8b4 -#define rFPGA0_XAB_RFInterfaceRB 0x8e0 -#define rFPGA0_XCD_RFInterfaceRB 0x8e4 - -/* Page 9 - RF mode & OFDM TxSC */ -#define rFPGA1_RFMOD 0x900 -#define rFPGA1_TxBlock 0x904 -#define rFPGA1_DebugSelect 0x908 -#define rFPGA1_TxInfo 0x90c - -/* Page a */ -#define rCCK0_System 0xa00 -#define rCCK0_AFESetting 0xa04 -#define rCCK0_CCA 0xa08 -/* AGC default value, sat
[PATCH 7/8] staging: rtl8192e: Fix DEEP_INDENTATION warnings in rtllib_parse_info_param()
- Replace ?: with min_t
- Remove condition that is always true
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib_rx.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 95cd17e..bb789cc 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1924,13 +1924,12 @@ int rtllib_parse_info_param(struct rtllib_device *ieee,
info_element->data[2] == 0x4c &&
info_element->data[3] == 0x033) {
- tmp_htcap_len = min_t(u8,
info_element->len, MAX_IE_LEN);
- if (tmp_htcap_len != 0) {
-
network->bssht.bdHTSpecVer = HT_SPEC_VER_EWC;
-
network->bssht.bdHTCapLen = tmp_htcap_len > sizeof(network->bssht.bdHTCapBuf) ?
-
sizeof(network->bssht.bdHTCapBuf) : tmp_htcap_len;
-
memcpy(network->bssht.bdHTCapBuf, info_element->data,
network->bssht.bdHTCapLen);
- }
+ tmp_htcap_len = min_t(u8,
info_element->len, MAX_IE_LEN);
+ if (tmp_htcap_len != 0) {
+ network->bssht.bdHTSpecVer =
HT_SPEC_VER_EWC;
+ network->bssht.bdHTCapLen =
min_t(u16, tmp_htcap_len, sizeof(network->bssht.bdHTCapBuf));
+
memcpy(network->bssht.bdHTCapBuf, info_element->data,
network->bssht.bdHTCapLen);
+ }
}
if (tmp_htcap_len != 0) {
network->bssht.bdSupportHT = true;
@@ -1951,12 +1950,8 @@ int rtllib_parse_info_param(struct rtllib_device *ieee,
tmp_htinfo_len = min_t(u8,
info_element->len, MAX_IE_LEN);
if (tmp_htinfo_len != 0) {
network->bssht.bdHTSpecVer =
HT_SPEC_VER_EWC;
- if (tmp_htinfo_len) {
-
network->bssht.bdHTInfoLen = tmp_htinfo_len >
sizeof(network->bssht.bdHTInfoBuf) ?
-
sizeof(network->bssht.bdHTInfoBuf) : tmp_htinfo_len;
-
memcpy(network->bssht.bdHTInfoBuf, info_element->data,
network->bssht.bdHTInfoLen);
- }
-
+ network->bssht.bdHTInfoLen =
min_t(u16, tmp_htinfo_len, sizeof(network->bssht.bdHTInfoBuf));
+
memcpy(network->bssht.bdHTInfoBuf, info_element->data,
network->bssht.bdHTInfoLen);
}
}
--
1.8.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/8] staging: rtl8192e: Fix DEEP_INDENTATION warnings in rtl_dm.c
Separate parts of dm_TXPowerTrackingCallback_TSSI() into two new functions:
- dm_tx_update_tssi_weak_signal()
- dm_tx_update_tssi_strong_signal()
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 176 +++--
1 file changed, 93 insertions(+), 83 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 9de5846..66baed80 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -542,6 +542,97 @@ static u8 CCKSwingTable_Ch14[CCK_Table_length][8] = {
#defineTssi_Report_Value2 0x13e
#defineFW_Busy_Flag0x13f
+static void dm_tx_update_tssi_weak_signal(struct net_device *dev, u8 RF_Type)
+{
+ struct r8192_priv *p = rtllib_priv(dev);
+
+ if (RF_Type == RF_2T4R) {
+ if ((p->rfa_txpowertrackingindex > 0) &&
+ (p->rfc_txpowertrackingindex > 0)) {
+ p->rfa_txpowertrackingindex--;
+ if (p->rfa_txpowertrackingindex_real > 4) {
+ p->rfa_txpowertrackingindex_real--;
+ rtl8192_setBBreg(dev, rOFDM0_XATxIQImbalance,
+bMaskDWord,
+
dm_tx_bb_gain[p->rfa_txpowertrackingindex_real]);
+ }
+
+ p->rfc_txpowertrackingindex--;
+ if (p->rfc_txpowertrackingindex_real > 4) {
+ p->rfc_txpowertrackingindex_real--;
+ rtl8192_setBBreg(dev,
+rOFDM0_XCTxIQImbalance,
+bMaskDWord,
+
dm_tx_bb_gain[p->rfc_txpowertrackingindex_real]);
+ }
+ } else {
+ rtl8192_setBBreg(dev, rOFDM0_XATxIQImbalance,
+bMaskDWord,
+dm_tx_bb_gain[4]);
+ rtl8192_setBBreg(dev,
+rOFDM0_XCTxIQImbalance,
+bMaskDWord, dm_tx_bb_gain[4]);
+ }
+ } else {
+ if (p->rfa_txpowertrackingindex > 0) {
+ p->rfa_txpowertrackingindex--;
+ if (p->rfa_txpowertrackingindex_real > 4) {
+ p->rfa_txpowertrackingindex_real--;
+ rtl8192_setBBreg(dev,
+rOFDM0_XATxIQImbalance,
+bMaskDWord,
+
dm_tx_bb_gain[p->rfa_txpowertrackingindex_real]);
+ }
+ } else {
+ rtl8192_setBBreg(dev, rOFDM0_XATxIQImbalance,
+bMaskDWord, dm_tx_bb_gain[4]);
+ }
+ }
+}
+
+static void dm_tx_update_tssi_strong_signal(struct net_device *dev, u8 RF_Type)
+{
+ struct r8192_priv *p = rtllib_priv(dev);
+
+ if (RF_Type == RF_2T4R) {
+ if ((p->rfa_txpowertrackingindex < TxBBGainTableLength - 1) &&
+ (p->rfc_txpowertrackingindex < TxBBGainTableLength - 1)) {
+ p->rfa_txpowertrackingindex++;
+ p->rfa_txpowertrackingindex_real++;
+ rtl8192_setBBreg(dev,
+rOFDM0_XATxIQImbalance,
+bMaskDWord,
+
dm_tx_bb_gain[p->rfa_txpowertrackingindex_real]);
+ p->rfc_txpowertrackingindex++;
+ p->rfc_txpowertrackingindex_real++;
+ rtl8192_setBBreg(dev,
+rOFDM0_XCTxIQImbalance,
+bMaskDWord,
+
dm_tx_bb_gain[p->rfc_txpowertrackingindex_real]);
+ } else {
+ rtl8192_setBBreg(dev,
+rOFDM0_XATxIQImbalance,
+bMaskDWord,
+dm_tx_bb_gain[TxBBGainTableLength - 1]);
+ rtl8192_setBBreg(dev, rOFDM0_XCTxIQImbalance,
+bMaskDWord,
+dm_tx_bb_gain[TxBBGainTableLength -
1]);
+ }
+ } else {
+ if (p->rfa_txpowertrackingindex < (TxBBGainTableLength - 1)) {
+ p->rfa_txpowertrackingindex++;
+ p->rfa_txpowertrackingindex_real++;
+ rtl8192_setBBreg(dev, rOFDM0_XATxIQImbalance,
+
[PATCH 4/8] staging: rtl8192e: Fix SPACING errors
Fix several SPACING errors to make checkpatch happy.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +-
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++---
drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 6 +++---
drivers/staging/rtl8192e/rtllib_debug.h| 3 +--
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
5 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
index 4664a4f..eea2e39 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
@@ -1002,7 +1002,7 @@ void rtl8192_SwChnl_WorkItem(struct net_device *dev)
RT_TRACE(COMP_TRACE, "=>--%s(), set chan:%d, priv:%p\n", __func__,
priv->chan, priv);
- rtl8192_phy_FinishSwChnlNow(dev , priv->chan);
+ rtl8192_phy_FinishSwChnlNow(dev, priv->chan);
RT_TRACE(COMP_TRACE, "<== SwChnlCallback819xUsbWorkItem()\n");
}
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 352d381..3ce7676 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1533,7 +1533,7 @@ RESET_START:
SEM_UP_IEEE_WX(&ieee->wx_sem);
} else {
netdev_info(dev, "ieee->state is NOT LINKED\n");
- rtllib_softmac_stop_protocol(priv->rtllib, 0 , true);
+ rtllib_softmac_stop_protocol(priv->rtllib, 0, true);
}
dm_backup_dynamic_mechanism_state(dev);
@@ -2102,7 +2102,7 @@ static short rtl8192_alloc_rx_desc_ring(struct net_device
*dev)
entry->OWN = 1;
}
- if(entry)
+ if (entry)
entry->EOR = 1;
}
return 0;
@@ -2519,7 +2519,7 @@ void rtl8192_commit(struct net_device *dev)
if (priv->up == 0)
return;
- rtllib_softmac_stop_protocol(priv->rtllib, 0 , true);
+ rtllib_softmac_stop_protocol(priv->rtllib, 0, true);
rtl8192_irq_disable(dev);
priv->ops->stop_adapter(dev, true);
_rtl8192_up(dev, false);
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
index d365af6..a6279e7 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
@@ -84,7 +84,7 @@
#define RTL_PCI_DEVICE(vend, dev, cfg) \
.vendor = (vend), .device = (dev), \
- .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID , \
+ .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, \
.driver_data = (kernel_ulong_t)&(cfg)
#define RTL_MAX_SCAN_SIZE 128
@@ -303,9 +303,9 @@ enum pci_bridge_vendor {
PCI_BRIDGE_VENDOR_INTEL = 0x0,
PCI_BRIDGE_VENDOR_ATI,
PCI_BRIDGE_VENDOR_AMD,
- PCI_BRIDGE_VENDOR_SIS ,
+ PCI_BRIDGE_VENDOR_SIS,
PCI_BRIDGE_VENDOR_UNKNOWN,
- PCI_BRIDGE_VENDOR_MAX ,
+ PCI_BRIDGE_VENDOR_MAX,
};
struct buffer {
diff --git a/drivers/staging/rtl8192e/rtllib_debug.h
b/drivers/staging/rtl8192e/rtllib_debug.h
index 119729d..6df8df1 100644
--- a/drivers/staging/rtl8192e/rtllib_debug.h
+++ b/drivers/staging/rtl8192e/rtllib_debug.h
@@ -73,8 +73,7 @@ enum RTL_DEBUG {
#define RT_TRACE(component, x, args...)\
do { \
if (rt_global_debug_component & component) \
- printk(KERN_DEBUG DRV_NAME ":" x "\n" , \
- ##args);\
+ printk(KERN_DEBUG DRV_NAME ":" x "\n", ##args);\
} while (0)
#define assert(expr) \
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index fe3e7e12..95cd17e 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -469,7 +469,7 @@ static bool AddReorderEntry(struct rx_ts_record *pTS,
void rtllib_indicate_packets(struct rtllib_device *ieee, struct rtllib_rxb
**prxbIndicateArray, u8 index)
{
struct net_device_stats *stats = &ieee->stats;
- u8 i = 0 , j = 0;
+ u8 i = 0, j = 0;
u16 ethertype;
for (j = 0; j < index; j++) {
--
1.8.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/6] Revert "staging: board: disable as it breaks the build"
On Tue, Apr 07, 2015 at 03:16:54PM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 6, 2015 at 2:40 AM, Simon Horman wrote:
> > On Fri, Apr 03, 2015 at 02:41:58PM +0200, Geert Uytterhoeven wrote:
> >> This reverts commit d13778d537a0ed6115d2a79a942af999cfb8eec6.
> >>
> >> Commit 13c11072536f2613 ("staging:board: remove unnecessary function")
> >> fixed the build of drivers/staging/board/board.c.
> >>
> >> Signed-off-by: Geert Uytterhoeven
> >
> > Signed-off-by: Simon Horman
>
> Acked-by? Reviewed-by? Tested-by? Rejected-by?
To be honest I was flipping between Signed-off-by and Acked-by.
But it seems you don't think either of those would be appropriate.
So how about:
Reviewed-by: Simon Horman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8188eu: Replaced kzalloc and memcpy combination with kmemdup
On Tue, Apr 07, 2015 at 02:25:39PM +, Dhere, Chaitanya (C.) wrote: > This change was detected with the help of coccinelle tool. > It performs the same function as kzalloc amd memcpy. > > Signed-off-by: Chaitanya Dhere your From: name and this name does not match. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Последно предупреждение !!
Вашият имейл квота е почти надхвърлен. Като се започне от 05 април, ние мигриране към нов имейл интерфейс. Така че ние сме в момента прави поддръжката на нашия сървър. Моля, кликнете на линка по-долу, за да въведете и актуализирате профила си и да се избегне загубата на вашата пощенска кутия. = >> http://michelgaudreau112.wix.com/webmaster-bg Desk, като връчването Team HELPDESK Webmaster Актуализация ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: sm750fb: Remove extra parentheses around right bit shift operation
Some people like to put parenthesis around stuff. It's harmless here. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3] staging: dgnc: improve the coding style in unlocking part of dgnc_tty_write()
This patch changes the lock ordering (behavior change) and it's not described in the changelog. Please figure out which way is the correct ordering and resend. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3] staging: dgnc: improve the coding style in unlocking part of dgnc_tty_write()
On Tue, Apr 07, 2015 at 11:17:48AM +0300, Dan Carpenter wrote: > This patch changes the lock ordering (behavior change) and it's not > described in the changelog. Please figure out which way is the correct > ordering and resend. Actually the original ordering was obviously correct. You can't take a mutex if you are holding a spinlock. So it always has to be: mutex_lock(); spin_lock(); spin_unlock(); mutext_unlock(); regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
