Re: [PATCH 06/11] staging: rtl8192e: Remove dead code: rtl_dm.[ch]
On 04.06.2015 15:52, Dan Carpenter wrote: On Tue, Jun 02, 2015 at 10:48:10PM +0200, Mateusz Kulikowski wrote: - Remove unused fields in dig_t structures. Some of them were only initialized and never accessed. - Remove unused enums/macros/defines in rtl_dm.h - Remove duplicated function declarations - Remove unused dm_change_dynamic_initgain_thresh() function - Remove unused dm_shadow_init() function Could you delete dm_shadow[] in a follow on patch. Will do in v2 How I review these sorts of patches is that: 1) Ignore deleted variables. If those are used then it will cause a compile problem so I don't worry about it. 2) Verify that when we delete initialization, then we also delete the variable. In this case we deleted the initialization of dm_shadow[] but not the variable itself, so I wondered if we were using unitialized data. It turns out that it was just an oversight. Reviewing these means a lot of searching, for each variable. Next time if the patch were split up more it would make it a bit easier. Ok; I assume this applies for next series, not v2. Regards, Mateusz ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/11] staging: rtl8192e: Remove dead code: dig_t::dbg_mode
On 04.06.2015 08:06, Sudip Mukherjee wrote: On Thu, Jun 04, 2015 at 07:50:07AM +0200, Mateusz Kulikowski wrote: On 04.06.2015 07:18, Sudip Mukherjee wrote: On Wed, Jun 03, 2015 at 08:21:02PM +0200, Mateusz Kulikowski wrote: On 03.06.2015 09:26, Sudip Mukherjee wrote: On Tue, Jun 02, 2015 at 10:48:11PM +0200, Mateusz Kulikowski wrote: No, I missed that - this one should also be removed - probably because of similar naming (DbgMode, dbg_mode). Thanks for finding it - I'll fix that in v2. Apart from that - did you had time/courage to analyze rest of the patches (so I can send v2)? at a first glance looked ok to me. I hope you have checked it on the hardware as well. but maybe Dan can find something. better send v2. Of course I have checked it, although - as I wrote in past - this driver has not very good performance. is there any other driver which has better performance on this hardware than this driver? and how are you measuring the performance? What I meant is that this driver (at least on my HW/SW configuration) is not very reliable. It drops a lot of packages and transmission speed is far from declared. But - as far as I checked - it's not due to my changes (I checked that some time ago). Perhaps my hardware has some issues - I have to buy another rtl8192e card and/or test on Windows to be sure (will do both steps probably). As for measurement, I have simple tests on my home network (WPA2/CCMP): - Scan available networks - Download 1MB file, check md5 - Ping router/gateway Regards, Mateusz ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: lustre: question about lov_request.c
Hello!
You are right, set_pga seems to be a dead member. It was alive a once, but
somehow not fully removed now,
so it's safe to drop the whole if and also the struct member itself.
set_oabufs could be dropped as well.
Thanks.
Bye,
Oleg
On Jun 7, 2015, at 4:11 PM, Julia Lawall wrote:
Hello,
The function lov_finish_set in
drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
if (set-set_pga) {
int len = set-set_oabufs * sizeof(*set-set_pga);
OBD_FREE_LARGE(set-set_pga, len);
}
If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful
any more. But actually, at least with grep, I can't find anywhere that
either the set_pga field or the set_oabufs field is set. Am I missing
something, or can the whole if be removed? Can these two fields go too?
thanks,
julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Reply
Dr. Lucas Willmon Operations/Regional Manager Santander Bank Plc, 47-48 Piccadilly PICCADILLY W1J0DT London United Kingdom Hello friend, I am Dr. Lucas Willmon, from Harlesden North West London, Head of Accounting Audit Department and formal senior programmer manager at Deutsche bank, here in England (Santander Bank Plc). I also worked for the Newest Ministers Bank Plc. I am writing you about a business proposal that will be of an immense benefit to both of us. In my department, as the only Operations/Regional Manager Branch Manager Santander Bank Plc. I discovered a Sum of (£21,500,000,00) British Pounds (Twenty one million Five Hundred Thousand British Pounds) in an account that Belongs to one of our foreign customers (Late David McDowell Brown) an American citizen of Arlington Virginia, who unfortunately lost his life on First February 2003 through the southern United States space shuttle Columbia, He died a single man. The choice of contacting you is aroused from the geographical nature of where you live, particularly due to the sensitivity of this transaction and the concealment here-in. Our bank has been waiting for any of the relatives to come-up for the claim but nobody has done that and i personally have been unsuccessful in locating the relatives, I now seek your consent to present you as the next of kin (WILL BENEFICIARY) to the deceased so that the proceeds of this account valued at (£21,500,000,00) British Pounds can be paid to you. Nevertheless, this will be disbursed or shared in these percentages, 50% to me and 40% to you while 10% is for any expenses incurred during the transaction. I have secured all necessary legal documents that can be used to back up this claim we are making. All i need is to fill in your name(s) to the documents and legalize it in the court here to prove you as the legitimate beneficiary. All I require now is your honest Co-operation, Confidentiality and Trust to enable us see this transaction through. I guarantee you that this will be executed under a legitimate arrangement that will protect you from any breach of the law if you will stand as inheritor of this claim, i shall process claim in your name. I only require you send your valid identification details and i will authenticate the claim in your name. Provide me the following below, as we have 7 days to run it through. This is very URGENT. 1. Full Name: 2. Your Direct Mobile Number: 3. Your Contact Address: 4. Occupation: 5. Age: 6. Sex: 7. Nationality: Having gone through a methodical search, I decided to contact you hoping that you will find this proposal interesting. Please on your confirmation of this message and indicating your interest I will furnish you with more information. Please endeavor to let me know your decision rather than keep me waiting. Thanking you in anticipation of your favorable reply. Best Regards, Dr. Lucas Willmon - CONFIDENTIALITY NOTICE: This message may contain any discussion of legal matters, hence should be taken as an authoritative interpretation of the law. - ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
lustre: question about lov_request.c
Hello,
The function lov_finish_set in
drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
if (set-set_pga) {
int len = set-set_oabufs * sizeof(*set-set_pga);
OBD_FREE_LARGE(set-set_pga, len);
}
If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful
any more. But actually, at least with grep, I can't find anywhere that
either the set_pga field or the set_oabufs field is set. Am I missing
something, or can the whole if be removed? Can these two fields go too?
thanks,
julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: lustre: question about lov_request.c
On Sun, 7 Jun 2015, Drokin, Oleg wrote:
Hello!
You are right, set_pga seems to be a dead member. It was alive a once, but
somehow not fully removed now,
so it's safe to drop the whole if and also the struct member itself.
set_oabufs could be dropped as well.
Thanks. I will do that.
julia
Thanks.
Bye,
Oleg
On Jun 7, 2015, at 4:11 PM, Julia Lawall wrote:
Hello,
The function lov_finish_set in
drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
if (set-set_pga) {
int len = set-set_oabufs * sizeof(*set-set_pga);
OBD_FREE_LARGE(set-set_pga, len);
}
If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful
any more. But actually, at least with grep, I can't find anywhere that
either the set_pga field or the set_oabufs field is set. Am I missing
something, or can the whole if be removed? Can these two fields go too?
thanks,
julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] staging: rtl8192e: fix some confusing indenting
On 05.06.2015 11:24, Dan Carpenter wrote:
The indenting here causes a static checker warning:
drivers/staging/rtl8192e/rtllib_rx.c:626 RxReorderIndicatePacket()
warn: curly braces intended?
The code is actually correct, it's just that these lines were pushed in
an extra indent level by mistake in 35e33b0468ab ('staging: rtl8192e:
Fix LONG_LINE warnings').
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 6977f04..2bef1f6 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -623,9 +623,9 @@ static void RxReorderIndicatePacket(struct rtllib_device
*ieee,
else
pTS-RxIndicateSeq = 4095 -
(WinSize - (SeqNum + 1)) + 1;
- netdev_dbg(ieee-dev,
-Window Shift! IndicateSeq: %d, NewSeq:
%d\n,
-pTS-RxIndicateSeq, SeqNum);
+ netdev_dbg(ieee-dev,
+Window Shift! IndicateSeq: %d, NewSeq: %d\n,
+pTS-RxIndicateSeq, SeqNum);
}
/* Indication process.
Ouch, Thanks!
I've missed this one.
M.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: rtl8723au: core: avoid bitwise arithmetic with forced endianness
You're CC'ing all the lustre people on this by mistake. Can we find which patch introduced this bug, and add a Fixes: tag and CC whoever introduced it? Please, resend with the correct CC list. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] staging: rtl8723au: core: remove redundant endianness conversion
On Sat, Jun 06, 2015 at 05:34:00PM -0700, David Decotigny wrote: Source and destination have the same little-endian annotation: this patch removes forced conversion from host byte order to little-endian. The patch seems correct but the changelog is a bit wrong. It will change it from little endian to host endian but we don't want the dest to be host endian, we want it to be little endain. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: rtl8723au: core: avoid bitwise arithmetic with forced endianness
This was introduced by kernel bulk commit 5e93f3520 staging: r8723au: Add source files for new driver - part 1, initially from github according to commit description. On github, this traces back to another bulk commit: 2896bda04353 Add new files in core directory, which is the 1st version of the driver. Not sure where to find the parent repos. PS: sorry for the incorrect To/Cc, going to resend to more appropriate recipients. On Sun, Jun 7, 2015 at 4:20 AM, Dan Carpenter dan.carpen...@oracle.com wrote: You're CC'ing all the lustre people on this by mistake. Can we find which patch introduced this bug, and add a Fixes: tag and CC whoever introduced it? Please, resend with the correct CC list. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] staging: rtl8723au: core: endianness issues
The code shows a couple inconsistencies (described in commit descriptions) which would not be an issue on little-endian cpus, but could cause breakage on non-LE cpus. Note: I could not test on real hardware, these patches created based on sparse reports. Hostory: - resending the same patches to correct recipients, only changed commit descriptions (credits to Dan Carpenter) # Patch Set Summary: David Decotigny (2): staging: rtl8723au: core: avoid bitwise arithmetic with forced endianness staging: rtl8723au: core: remove redundant endianness conversion drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.2.0.rc0.207.ga3a616c ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: rtl8723au: core: remove redundant endianness conversion
Source and destination have the same little-endian annotation: this patch removes incorrect byte-swap on non-LE cpus. This addresses the following sparse warning: drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56: warning: incorrect type in argument 1 (different base types) drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56:expected unsigned short [unsigned] [usertype] val drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56:got restricted __le16 [usertype] BA_timeout_value Signed-off-by: David Decotigny ddeco...@gmail.com --- drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c index 7c3b5dd..142f214 100644 --- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c +++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c @@ -3906,8 +3906,8 @@ void issue_action_BA23a(struct rtw_adapter *padapter, put_unaligned_le16(BA_para_set, mgmt-u.action.u.addba_resp.capab); - put_unaligned_le16(pmlmeinfo-ADDBA_req.BA_timeout_value, - mgmt-u.action.u.addba_resp.timeout); + mgmt-u.action.u.addba_resp.timeout + = pmlmeinfo-ADDBA_req.BA_timeout_value; pattrib-pktlen += 8; break; -- 2.2.0.rc0.207.ga3a616c ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
