On Tuesday 10 June 2014 23:31:37 Rickard Strandqvist wrote:
> I guess it's ok to do the patches?
Right, you got some feedback from me and another person. You can
send patches whenever you like.
> But then again, I will then send them one by one, with the cover
> letter? +35 email?
Have you seen
On Tuesday 10 June 2014 23:31:37 Rickard Strandqvist wrote:
I guess it's ok to do the patches?
Right, you got some feedback from me and another person. You can
send patches whenever you like.
But then again, I will then send them one by one, with the cover
letter? +35 email?
Have you seen my
On 06/08/2014 05:43 AM, Peter Wu wrote:
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Well, Larry is the
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
> Then we use MSR_MASK instead, new patch then. But I will wait a day?
> Or what is long enough to be sure that nobody else have any
> objections? How is this usually resolved?
Well, Larry is the maintainer, so he will ultimately pick up
Hi
Damn, there I was bit too fast :-(
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Sure, I can send a patch for all the files instead. However, earlier
received
On Saturday 07 June 2014 19:01:20 Larry Finger wrote:
> As you have learned here, automatically making changes suggested by some tool
> may convert a visible bug into one that is invisible, and only found by a
> detailed line-by-line examination of the code, and that is unlikely to
> happen.
>
On Saturday 07 June 2014 19:01:20 Larry Finger wrote:
As you have learned here, automatically making changes suggested by some tool
may convert a visible bug into one that is invisible, and only found by a
detailed line-by-line examination of the code, and that is unlikely to
happen.
Hi
Damn, there I was bit too fast :-(
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Sure, I can send a patch for all the files instead. However, earlier
received
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Well, Larry is the maintainer, so he will ultimately pick up
On 06/08/2014 05:43 AM, Peter Wu wrote:
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Well, Larry is the
Hi all
Good. New patches are on the way :)
Best regards
Rickard Strandqvist
2014-06-08 2:01 GMT+02:00 Larry Finger :
> On 06/07/2014 10:24 AM, Rickard Strandqvist wrote:
>>
>> Hi!
>>
>> Yes, 0x3 was one of the most likely :)
>> But wanted someone who knows the code better would be heard.
>>
On 06/07/2014 10:24 AM, Rickard Strandqvist wrote:
Hi!
Yes, 0x3 was one of the most likely :)
But wanted someone who knows the code better would be heard.
All agreed? Then I do a new patch.
Looks like it is the same error in the files below, I'll fix them all them to.
rtl8192cu/hw.c:1363:
On Saturday 07 June 2014 16:30:19 Rickard Strandqvist wrote:
> Expression '(X & 0xfc) == 0x3' is always false
While this is true, I believe that some other mistake is made.
> I chose to remove this code, because it will not make any difference.
> But obviously it is rather a properly designed if
Hi!
Yes, 0x3 was one of the most likely :)
But wanted someone who knows the code better would be heard.
All agreed? Then I do a new patch.
Looks like it is the same error in the files below, I'll fix them all them to.
rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP)
rtl8192ce/hw.c:1209:
Expression '(X & 0xfc) == 0x3' is always false
I chose to remove this code, because it will not make any difference.
But obviously it is rather a properly designed if statement that is needed.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard
Expression '(X 0xfc) == 0x3' is always false
I chose to remove this code, because it will not make any difference.
But obviously it is rather a properly designed if statement that is needed.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard
Hi!
Yes, 0x3 was one of the most likely :)
But wanted someone who knows the code better would be heard.
All agreed? Then I do a new patch.
Looks like it is the same error in the files below, I'll fix them all them to.
rtl8192cu/hw.c:1363:if ((bt_msr 0xfc) == MSR_AP)
rtl8192ce/hw.c:1209:
On Saturday 07 June 2014 16:30:19 Rickard Strandqvist wrote:
Expression '(X 0xfc) == 0x3' is always false
While this is true, I believe that some other mistake is made.
I chose to remove this code, because it will not make any difference.
But obviously it is rather a properly designed if
On 06/07/2014 10:24 AM, Rickard Strandqvist wrote:
Hi!
Yes, 0x3 was one of the most likely :)
But wanted someone who knows the code better would be heard.
All agreed? Then I do a new patch.
Looks like it is the same error in the files below, I'll fix them all them to.
rtl8192cu/hw.c:1363:
Hi all
Good. New patches are on the way :)
Best regards
Rickard Strandqvist
2014-06-08 2:01 GMT+02:00 Larry Finger larry.fin...@lwfinger.net:
On 06/07/2014 10:24 AM, Rickard Strandqvist wrote:
Hi!
Yes, 0x3 was one of the most likely :)
But wanted someone who knows the code better would
20 matches
Mail list logo
