urgent response this your beneficiary for inheritance fund

[SM85 SMITH]

compliment of the season

I know that you will be surprised to receive this mail from me today.
I consider it imperative to introduce
myself: . I am Mr Roland Max.
I work with Turks Bank groups

This letter is highly privileged and it requires your immediate attention
because we lost one of our big customer who happens to be from your country
also has the same family name as yours for the help Microsoft fine out
both have similar Email address.
That is why i can reach up you on Email and he had a fixed-term Deposit
worth of (US$7.5M) with our Bank before his death.

This fund has been order by our late customer to move his fund to nationality
Any organization - charity  or Anyone from his country as beneficiary
inheritance willed fund.
I want to present you to the bank for the beneficiary inheritance fund.

DISBURSEMENT/SHARING OF THE MONEY.
I will have 60% while you will keep 40% as your personal commission.
once the money is transferred into your account.

This is a very safe and 100% risk-free involvement
As its  AM  next to his account officer of our late customer.

if you receive this message in spam, kindly know that it is network problem.

Don't Forget To Reply This Email Only:  sm85sm...@gmail.com

TNKS IN MILLION FOR YOUR URGENT RESPONSE


Best regards.
Mr Roland Max
Happy new week.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

I need your prompt response

[Ingram Olivia]

Hello Dear I am Mrs. Ingram Olivia, I have decided to donate what I
have to  Motherless babies/ Less privileged/ Widows' because I am
dying and diagnosed for cancer for about 10 years ago. I have been
touched by God Almighty to donate from what I have inherited from my
late husband to you for good work of God Almighty. I have asked
Almighty God to forgive me and believe he has, because he is a
Merciful God, I'm presently suffering from Leukemia.

My health condition has gotten worse and just two weeks ago my doctor
informed me that my condition has reach a critical stage, that I have
just 5 months left. This confirmation from my doctor was and still is
devastating news; it is hard to know that you have just a little time
left to live here.

After the doctor’s medical pronunciation that I have just few months
to live, I decided to divide my wealth to contribute to your country.
I want to assist you with the funds to do great charity works in your
country, this is my last wish. I selected you after searching few
websites; I prayed and was led to you. I am willing to donate the sum
of ($8.1million ) to the less privileged through you.

Please I want to transfer this money to you, If you can handle this
fund and very sure to do charity works on my behalf and from there I
will travel to meet a specialist as I want to be buried alongside my
late husband when I passed on.

Note that this fund is in the financial institution and upon my
instruction; I will file in an application for the transfer of the
money into your account for the said purpose.

Lastly, I honestly pray that this money when transferred will be used
for the said purpose even though I might be late then. I have come to
find out that wealth is vanity and I made a promise to God that my
wealth will be used to support the poor and the assist the sick. Do
let me know

if you will be able to handle this fund and use it for the said
purpose so that I will inform my bank on my decision, If you are
interested in carrying out this task, get back to me for more details
on this noble project of mine.
1: Full name:
2: Country:
3:Occupation/position:
4:Phone/s:
5: Age:
6: Sex:
7: Address:
I am waiting soonest to hear from you reply via : oliviaingra...@gmail.com
God bless you
Mrs.Ingram Olivia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

I await your urgent response. My present internet connection is very slow in case you received this mail in your spam.

[Mr James Larry]

Attention, Beneficiary:


This Letter Is from the Federal Ministry of Finance. During Our
Comprehensive Investigations Regarding Your Inability To Receive Your
Over Due Payment We Discovered That You Have Been Dealing With A Set
Of Corrupt Government Officials Who Have Been Making Frantic Efforts
To Divert Your Funds Into Their Personal Accounts To Enrich
Themselves, Now It May Interest You To Know That During Our Meeting
With Officials Of Your Country’s Embassy Here In BENIN REPUBLIC The
Issue Was Extensively Discussed And An Irrevocably Resolution Was
Reached Whereby We Have Been Mandated To Pay You The Sum Of $3.5m
(Three Million Five Hundred Thousand United States Dollars As Part Of
Your Outstanding Contract/Inheritance Payment, In Furtherance To That
You Are Warned To Stop Further Dealings With Any Other Person(s) Or
Office(s) Because Such Illegal Dealings/ Activities May Sabotage This
Latest Efforts In Ensuring A Hitch Free Release Of Your Payment.

In Lieu Of The Above, An ATM Card Valued the Sum Of $3,500,000.00 Will
Be Issued to You by the ATM Department of Payment Release Center Which
You Will Use to Withdraw Your Money from Any Cash Point or ATM Machine
Anywhere in the World and the Maximum Withdrawal Per Day Is $10,000.00
USD pay day until your total amount $3,500,000.00 withdraw completely.

For Further Directives Regarding the Release of Your ATM Card, Contact
Director ATM Department,

Security Mr James Larry,
Email: (mrjameslarry...@yahoo.com)
Telephone: +229 67403221,

You Are Advised to Furnish Them with the Following Information:

Your Name:
Address:
Phone Number:
Age:
Occupation:

Note That Because Of Impostors We Hereby Issue You A Communication
Code (0011), You Are to Use This Code as Your Subject When Contacting
the ATM Department So as to Enable Them Give Your File the Urgent
Attention It Requires.

Best regards
Barr. Paul Fisher
(Permanent Secretary)
FEDERAL MINISTRY OF FINANCE
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your prompt response would be highly appreciated

[Greg Rhodes]

I am Mr Greg Rhodes a supervisor at a gold mining site in Sierra Leone.

Due to Covid-19 some of our customers are not picking up their orders, thus, 
there is a glut of gold bars in our safe.

In view of this, we are seriously looking for buyers. Our prices are favourable 
and the business is profitable.

For a kilogram of gold purchased from us, you are sure to make at between 
$10,000 - $12,000.

We thank you and look forward to a good business relationship.

Best regards,
Greg Rhodes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your response needed:

[Femi Brown]

This mail is been writing to you because we have come to understand that
you have lost a lot of money all because you want to receive your fund
well note that all that have been put to a stop as the federal government of
Nigeria has promised to assist you with the sum of five million American funds 
in other to
compensate you and all you have to do is fill the below information s.
 
1 full name
 
2 home phone and cell phone number
 
3 occupation
 
4 amount that was lost by you
 
Send this and get back at once.
 
Warm regards
 
Femi
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

YOUR URGENT RESPONSE

[Mr. Kim Leang]

Greeting!

I am contacting you to receive and share with me an abandoned fund ( 
$21,537.000.00 ) left in our bank by a deceased customer. I was going through 
the Internet search when I found your email address. My name is Mr. Kim Leang.

I want to utilize this opportunity and make use of this fund if I should 
present your name to the bank to stand as his business associate/ trustee for 
the fund to be released to you via Visa card for easy withdrawals in any VISA 
ATM machine anywhere in the World.

The bank will also give you international online transfer options. With these 
you can transfer the funds without any risk.

Should you be interested in working with me in this project? Please reply back 
and let's benefit from this golden opportunity.You are my first contact.. I 
shall wait a few days and if I do not hear from you, I shall look for another 
person.

Thanks and have a nice day,
Mr. Kim Leang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your Response Please....

[Klen Tindle]

Hello Dear,

I am Klen Tindle  by name, from America and working with the USA
military still on a mission in Afghanistan.  I really need your
assistance that is the reason why I contacted you, I want to go
into a cordial relationship and business partnership with you, as
I don't know how long we would stay in the war zone here, Here in
the military zone we are not allowed to make use of mobile
phones, we only make use of radio message and e-mail
communication.

I want you to know that we are being attacked by insurgents every
day and several bombings. During one of our rescue mission we
came across a safe box that contain huge amount of money that
belongs to the revolutionaries, which I believe they use in
buying weapons and ammunition and it was agreed by all parties
present that the money will be shared among us.

Out of the total fund my share was $5,000,000 (Five Million US
Dollars), I am seeking your assistance to evacuate my share of
the money, which is $5,000,000. out of here to you; in as much as
you can assure me that my own share will be safe in your care
until I complete my service here, This is not stolen money, and
there are no dangers involved.

I have made arrangements with a United Nation Diplomat who
promised to deliver the fund to any of my chosen destination, I
shall be compensating you with 30% of the total fund if you can
help me secure the box, while the balance shall be my investment
capital in your country, One passionate appeal I will make to you
is not to discuss this matter to a third party, if you have
reasons to reject this offer, please destroy this e-mail as any
leakage of this information will be too bad for me, due to my
position as a USAF Lieutenant.

I have chosen to contact you after my prayers and I believe that
you will not betray my trust, but rather take me as your own
sister, Though you may wonder why I am so soon revealing myself
to you without knowing you, well I will say that my mind
convinced me that you are the true person to help me receive and
invest the fund.

I do not know how long we will remain here, and I have survived
two bomb attacks here, which prompted me to search out for a
reliable and trustworthy person to help me receive and invest the
fund in his country.

I wish you send me a reply immediately as soon as you receive
this proposal, Your urgent reply will be highly appreciated. I
hope my explanation is very clear but if you need further
clarification, then send your questions, I wait to hear from you
soonest.

Regards,
USAF Lieutenant Klen Tindle.
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your Response Needed

[Alfredo Gomez]

Dear Sir/Madam,

My Names are Mr.Alfredo Gomez. I am the Administrative manager at a vault 
financial & security Institution here in Madrid. I am contacting you based on a 
financial opportunity I discovered here in my organization. It's about an 
abandoned sum of 25,000,000.00 million US dollars (Twenty five million  United 
State dollars) in a dormant account with our bank and I have been following and 
monitoring this account since the year 2004 when I was appointed the 
Administrative manager of this financial institutions.

The Banking policy can only allow the release of such funds to a benefactor 
through an application as a beneficiary to the account deposit. For the past 
years, the bank has been expecting a possible beneficiary, but no luck, this 
institution has exploited all its ethical possibilities in other to contact the 
possible beneficiaries or inheritors of the account, but to no success since 
nobody has come over for the claim of the funds for the past 10 years.

I have made my own research with the help of a private investigator, it is my 
knowledge that the account has been dormant for the past 17 years. I also 
learnt that, there have not been any movement on the said account within this 
period. I am 100% sure that no one is aware of the existence of these funds.

However, because of the international financial crises, a lot of reform has 
been made within the Spanish financial system, this includes the new law on 
succession of claims which indicates a duration in which such deposit account 
could be tolerated.

The Bank of Spain has mandated our institution to release the funds to a 
possible beneficiary WITHIN A PERIOD OF 1 YEAR. Failure to respond to this 
ultimatum would legally allow the Bank of Spain to confiscate the funds as 
unclaimed funds (Which of course would go straight to the Government's pocket). 
It is therefore upon this entire discovery that I have decided to contact you 
for your kind cooperation.

I want you to know that I am a senior member of this office. As an insider, I 
am equipped with all classified secret information regarding the release of 
these funds. I would dedicate to make sure that I feed you with all possible 
documentation and information required for the approval and release of these 
funds to you.

Upon your acceptance to cooperate, I agree that 40% of this money will be for 
you, 50% for me and 10% goes for the reimbursement of any expenses that we 
might both incur during the short period of the funds transaction. Please note 
that I have ONLY discussed this issue with you alone.

Immediately you acknowledge the receipt of this mail, we shall further proceed 
and you shall be informed on the next step to urge ahead. In conclusion, it's 
my concern to demand your ultimate honesty, co-operation and confidentiality to 
enable us conclude this transaction.  

I fully assured you that this process would be executed under a legitimate 
arrangement that would legally protect you from any breach of law. 

Reply to my private e-mail: alfredogomez9...@outlook.com

With due cooperation, I wait to read from you soon.

Regards,

Mr.Alfredo Gomez
Telephone: +34 612 432 655
Fax:
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WAITING FOR YOUR POSITIVE RESPONSE

[ANNA BLAIR]

My Dear Friend,

Let me first of all inform you, I got your email address from a mail Directory 
and decided to mail you for a permission to go ahead. I am Mrs. Anna Blair from 
United Kingdom, married to Dr. Anthony R. Blair who worked with Texaco Oil 
Company in Malaysia before he died in a plane crash on his way to a Board 
meeting. My Husband and I were married but without any children. Since his 
death I decided not to re-marry and presently I am 79 Years old. When my late 
husband was Alive he deposited the sum of $11.5M. (Eleven Million Five Hundred 
Thousand U.S. Dollars) with a Bank.

Presently this money is still with the Bank and the management just wrote me as 
the beneficiary to come forward to receive the money or rather Issue a letter 
of authority to somebody to receive it on my behalf. I am presently in a 
hospital where I have been undergoing treatment Cancer of the lungs. I have 
since lost my ability to talk and my doctors have told me that I have only a 
few months to live so I think the best thing to do is to use the money for 
charity purposes.

I want a person who is trustworthy that I will make the beneficiary of my late 
Husband's Fund deposited with the bank so that the person can get the money and 
utilize 70% of this money to fund churches, orphanages and widows around the 
world.

As soon as I receive your reply I shall give you the contact details of the 
Bank. I will also issue you a letter of authority that will prove you as the 
new beneficiary of this fund.Please assure me that you will act accordingly as 
I stated here in and Keep this contact confidential till such a time this funds 
get to your Custody. This is  to ensure that nothing jeopardizes my last wish 
on earth.

I await your urgent reply.

Regards,
Mrs. Anna Blair.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

URGENT RESPONSE NEEDED

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 12/29] staging: wilc1000: set default value of cfg response type in wilc_wlan_cfg_indicate_rx()

[Ajay Singh]

Handle the setting of default value for 'wilc_cfg_rsp' type for all
cases in wilc_wlan_cfg_indicate_rx() as the caller make use of this
value to know the type of the received message.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan_cfg.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c 
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 2b5471b..2c463a3 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -507,6 +507,7 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
msg_id = frame[1];  /* seq no */
frame += 4;
size -= 4;
+   rsp->type = 0;
 
/*
 * The valid types of response messages are
@@ -532,7 +533,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
 
case 'N':
wilc_network_info_received(wilc, frame - 4, size + 4);
-   rsp->type = 0;
break;
 
case 'S':
@@ -540,7 +540,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
break;
 
default:
-   rsp->type = 0;
rsp->seq_no = msg_id;
break;
}
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 12/29] staging: wilc1000: set default value of cfg response type in wilc_wlan_cfg_indicate_rx()

[Ajay Singh]

Handle the setting of default value for 'wilc_cfg_rsp' type for all
cases in wilc_wlan_cfg_indicate_rx() as the caller make use of this
value to know the type of the received message.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan_cfg.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c 
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 2b5471b..2c463a3 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -507,6 +507,7 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
msg_id = frame[1];  /* seq no */
frame += 4;
size -= 4;
+   rsp->type = 0;
 
/*
 * The valid types of response messages are
@@ -532,7 +533,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
 
case 'N':
wilc_network_info_received(wilc, frame - 4, size + 4);
-   rsp->type = 0;
break;
 
case 'S':
@@ -540,7 +540,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
break;
 
default:
-   rsp->type = 0;
rsp->seq_no = msg_id;
break;
}
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 12/29] staging: wilc1000: set default value of cfg response type in wilc_wlan_cfg_indicate_rx()

[Ajay Singh]

Handle the setting of default value for 'wilc_cfg_rsp' type for all
cases in wilc_wlan_cfg_indicate_rx() as the caller make use of this
value to know the type of the received message.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan_cfg.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c 
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 2b5471b..2c463a3 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -507,6 +507,7 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
msg_id = frame[1];  /* seq no */
frame += 4;
size -= 4;
+   rsp->type = 0;
 
/*
 * The valid types of response messages are
@@ -532,7 +533,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
 
case 'N':
wilc_network_info_received(wilc, frame - 4, size + 4);
-   rsp->type = 0;
break;
 
case 'S':
@@ -540,7 +540,6 @@ void wilc_wlan_cfg_indicate_rx(struct wilc *wilc, u8 
*frame, int size,
break;
 
default:
-   rsp->type = 0;
rsp->seq_no = msg_id;
break;
}
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 34/34] staging: mt7621-mmc: Find response of SD_APP_OP_COND by default

[Christian Lütke-Stetzkamp]

The response type of the SD_APP_OP_COND command is correctly
determined using the mmc_resp_type macro, because the only use of that
opcode, mmc_send_app_op_cond, correctly places MMC_RSP_R3 in cmd.flags.

So there is no need to treat that opcode separately.

Signed-off-by: Christian Lütke-Stetzkamp 
---
 drivers/staging/mt7621-mmc/sd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 69123cfd7309..04d23cc7cd4a 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -710,9 +710,7 @@ static inline u32 msdc_cmd_find_resp(struct mmc_command 
*cmd)
u32 opcode = cmd->opcode;
u32 resp;
 
-   if (opcode == SD_APP_OP_COND) {
-   resp = RESP_R3;
-   } else if (opcode == MMC_SET_RELATIVE_ADDR) {
+   if (opcode == MMC_SET_RELATIVE_ADDR) {
resp = (mmc_cmd_type(cmd) == MMC_CMD_BCR) ? RESP_R6 : RESP_R1;
} else if (opcode == MMC_FAST_IO) {
resp = RESP_R4;
-- 
2.16.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 33/34] staging: mt7621-mmc: Find response of MMC_SEND_OP_COND by default

[Christian Lütke-Stetzkamp]

The response type of the MMC_SEND_OP_COND command is correctly
determined using the mmc_resp_type macro, because the only use of that
opcode, mmc_send_op_cond, correctly places MMC_RSP_R3 in cmd.flags.

So there is no need to treat that opcode separately.

Signed-off-by: Christian Lütke-Stetzkamp 
---
 drivers/staging/mt7621-mmc/sd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index f7df3221a302..69123cfd7309 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -710,7 +710,7 @@ static inline u32 msdc_cmd_find_resp(struct mmc_command 
*cmd)
u32 opcode = cmd->opcode;
u32 resp;
 
-   if (opcode == MMC_SEND_OP_COND || opcode == SD_APP_OP_COND) {
+   if (opcode == SD_APP_OP_COND) {
resp = RESP_R3;
} else if (opcode == MMC_SET_RELATIVE_ADDR) {
resp = (mmc_cmd_type(cmd) == MMC_CMD_BCR) ? RESP_R6 : RESP_R1;
-- 
2.16.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 34/34] staging: mt7621-mmc: Find response of SD_APP_OP_COND by default

[Christian Lütke-Stetzkamp]

The response type of the SD_APP_OP_COND command is correctly
determined using the mmc_resp_type macro, because the only use of that
opcode, mmc_send_app_op_cond, correctly places MMC_RSP_R3 in cmd.flags.

So there is no need to treat that opcode separately.

Signed-off-by: Christian Lütke-Stetzkamp 
---
 drivers/staging/mt7621-mmc/sd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 3f4de63b25a8..f1b3472b96c3 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -710,9 +710,7 @@ static inline u32 msdc_cmd_find_resp(struct mmc_command cmd)
u32 opcode = cmd->opcode;
u32 resp;
 
-   if (opcode == SD_APP_OP_COND) {
-   resp = RESP_R3;
-   } else if (opcode == MMC_SET_RELATIVE_ADDR) {
+   if (opcode == MMC_SET_RELATIVE_ADDR) {
resp = (mmc_cmd_type(cmd) == MMC_CMD_BCR) ? RESP_R6 : RESP_R1;
} else if (opcode == MMC_FAST_IO) {
resp = RESP_R4;
-- 
2.16.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 33/34] staging: mt7621-mmc: Find response of MMC_SEND_OP_COND by default

[Christian Lütke-Stetzkamp]

The response type of the MMC_SEND_OP_COND command is correctly
determined using the mmc_resp_type macro, because the only use of that
opcode, mmc_send_op_cond, correctly places MMC_RSP_R3 in cmd.flags.

So there is no need to treat that opcode separately.

Signed-off-by: Christian Lütke-Stetzkamp 
---
 drivers/staging/mt7621-mmc/sd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index c02799acb9e4..3f4de63b25a8 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -710,7 +710,7 @@ static inline u32 msdc_cmd_find_resp(struct mmc_command cmd)
u32 opcode = cmd->opcode;
u32 resp;
 
-   if (opcode == MMC_SEND_OP_COND || opcode == SD_APP_OP_COND) {
+   if (opcode == SD_APP_OP_COND) {
resp = RESP_R3;
} else if (opcode == MMC_SET_RELATIVE_ADDR) {
resp = (mmc_cmd_type(cmd) == MMC_CMD_BCR) ? RESP_R6 : RESP_R1;
-- 
2.16.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH V2] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

[Greg KH]

On Sat, Nov 25, 2017 at 01:32:38PM -0600, Larry Finger wrote:
> When not associated with an AP, wifi device drivers should respond to the
> SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
> behavior expected by dhcpcd.
> 
> Currently, this driver returns an error code (-1) from the ioctl call,
> which causes dhcpcd to assume that the device is not a wireless interface
> and therefore it fails to work correctly with it thereafter.
> 
> This problem was reported and tested at
> https://github.com/lwfinger/rtl8188eu/issues/234.
> 
> Signed-off-by: Larry Finger 
> ---
> 
> v2 - completed missing subject

Ah, nevermind, you already did...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

[Larry Finger]

When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.

Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.

This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.

Signed-off-by: Larry Finger 
---

v2 - completed missing subject
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index c0664dc80bf2..446310775e90 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1395,19 +1395,13 @@ static int rtw_wx_get_essid(struct net_device *dev,
if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) {
len = pcur_bss->Ssid.SsidLength;
-
-   wrqu->essid.length = len;
-
memcpy(extra, pcur_bss->Ssid.Ssid, len);
-
-   wrqu->essid.flags = 1;
} else {
-   ret = -1;
-   goto exit;
+   len = 0;
+   *extra = 0;
}
-
-exit:
-
+   wrqu->essid.length = len;
+   wrqu->essid.flags = 1;
 
return ret;
 }
-- 
2.13.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192e: fix spelling mistake: "respose" -> "response"

[Colin King]

From: Colin Ian King <colin.k...@canonical.com>

Trivial fix to spelling mistake in netdev_info message and split
line to clean up an checkpatch line too wide warning.

Signed-off-by: Colin Ian King <colin.k...@canonical.com>
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 3cde5cce7e76..e4be85af31e7 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2300,7 +2300,8 @@ static void rtllib_rx_auth_resp(struct rtllib_device 
*ieee, struct sk_buff *skb)
if (errcode) {
ieee->softmac_stats.rx_auth_rs_err++;
netdev_info(ieee->dev,
-   "Authentication respose status code 0x%x", errcode);
+   "Authentication response status code 0x%x",
+   errcode);
rtllib_associate_abort(ieee);
return;
}
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 01/25] staging: unisys: visorbus: combine response functions into a single one

[David Kershner]

There are several different controlvm response functions, consolidate them
to one so we can simplify error handling.

Signed-off-by: David Kershner <david.kersh...@unisys.com>
Reviewed-by: Tim Sell <timothy.s...@unisys.com>
---
 drivers/staging/unisys/visorbus/visorchipset.c | 53 +++
 1 file changed, 22 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index c370b6d..1249ef6 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -441,7 +441,8 @@ chipset_init(struct controlvm_message *inmsg)
 }
 
 static int
-controlvm_respond(struct controlvm_message_header *msg_hdr, int response)
+controlvm_respond(struct controlvm_message_header *msg_hdr, int response,
+ struct spar_segment_state *state)
 {
struct controlvm_message outmsg;
 
@@ -449,19 +450,11 @@ controlvm_respond(struct controlvm_message_header 
*msg_hdr, int response)
if (outmsg.hdr.flags.test_message == 1)
return -EINVAL;
 
-   return visorchannel_signalinsert(chipset_dev->controlvm_channel,
-CONTROLVM_QUEUE_REQUEST, );
-}
-
-static int controlvm_respond_physdev_changestate(
-   struct controlvm_message_header *msg_hdr, int response,
-   struct spar_segment_state state)
-{
-   struct controlvm_message outmsg;
+   if (state) {
+   outmsg.cmd.device_change_state.state = *state;
+   outmsg.cmd.device_change_state.flags.phys_device = 1;
+   }
 
-   controlvm_init_response(, msg_hdr, response);
-   outmsg.cmd.device_change_state.state = state;
-   outmsg.cmd.device_change_state.flags.phys_device = 1;
return visorchannel_signalinsert(chipset_dev->controlvm_channel,
 CONTROLVM_QUEUE_REQUEST, );
 }
@@ -547,7 +540,7 @@ controlvm_responder(enum controlvm_id cmd_id,
if (pending_msg_hdr->id != (u32)cmd_id)
return -EINVAL;
 
-   return controlvm_respond(pending_msg_hdr, response);
+   return controlvm_respond(pending_msg_hdr, response, NULL);
 }
 
 static int
@@ -1096,9 +1089,9 @@ parahotplug_request_complete(int id, u16 active)
spin_unlock(_request_list_lock);
req->msg.cmd.device_change_state.state.active = active;
if (req->msg.hdr.flags.response_expected)
-   controlvm_respond_physdev_changestate(
-   >msg.hdr, CONTROLVM_RESP_SUCCESS,
-   req->msg.cmd.device_change_state.state);
+   controlvm_respond(
+  >msg.hdr, CONTROLVM_RESP_SUCCESS,
+  >msg.cmd.device_change_state.state);
parahotplug_request_destroy(req);
return 0;
}
@@ -1259,10 +1252,8 @@ parahotplug_process_message(struct controlvm_message 
*inmsg)
err = parahotplug_request_kickoff(req);
if (err)
goto err_respond;
-   controlvm_respond_physdev_changestate
-   (>hdr,
-CONTROLVM_RESP_SUCCESS,
-inmsg->cmd.device_change_state.state);
+   controlvm_respond(>hdr, CONTROLVM_RESP_SUCCESS,
+ >cmd.device_change_state.state);
parahotplug_request_destroy(req);
return 0;
}
@@ -1283,9 +1274,8 @@ parahotplug_process_message(struct controlvm_message 
*inmsg)
return 0;
 
 err_respond:
-   controlvm_respond_physdev_changestate
-   (>hdr, err,
-inmsg->cmd.device_change_state.state);
+   controlvm_respond(>hdr, err,
+ >cmd.device_change_state.state);
return err;
 }
 
@@ -1305,7 +1295,7 @@ chipset_ready_uevent(struct controlvm_message_header 
*msg_hdr)
 KOBJ_ONLINE);
 
if (msg_hdr->flags.response_expected)
-   controlvm_respond(msg_hdr, res);
+   controlvm_respond(msg_hdr, res, NULL);
 
return res;
 }
@@ -1329,7 +1319,7 @@ chipset_selftest_uevent(struct controlvm_message_header 
*msg_hdr)
 KOBJ_CHANGE, envp);
 
if (msg_hdr->flags.response_expected)
-   controlvm_respond(msg_hdr, res);
+   controlvm_respond(msg_hdr, res, NULL);
 
return res;
 }
@@ -1349,7 +1339,7 @@ chipset_notready_uevent(struct controlvm_message_header 
*msg_hdr)
res = kobject_uevent(_dev->acpi_device->dev.kobj,
 KOBJ_OFFLINE);
if (msg_h

[PATCH 11/15] staging: unisys: visorbus: my_device_changestate: add error response

[David Kershner]

The function my_device_changestate was not sending a response if there
was an error with the CONTROLVM message.

Signed-off-by: David Kershner <david.kersh...@unisys.com>
Reported-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Reviewed-by: Tim Sell <timothy.s...@unisys.com>
---
 drivers/staging/unisys/visorbus/visorchipset.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d107121..f8dca04 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1046,15 +1046,22 @@ enum crash_obj_type {
POSTCODE_LINUX_4(DEVICE_CHANGESTATE_FAILURE_PC, dev_no, bus_no,
 POSTCODE_SEVERITY_ERR);
rc = -CONTROLVM_RESP_ERROR_DEVICE_INVALID;
-   } else if (dev_info->state.created == 0) {
+   goto err_respond;
+   }
+   if (dev_info->state.created == 0) {
POSTCODE_LINUX_4(DEVICE_CHANGESTATE_FAILURE_PC, dev_no, bus_no,
 POSTCODE_SEVERITY_ERR);
rc = -CONTROLVM_RESP_ERROR_DEVICE_INVALID;
+   goto err_respond;
}
-   if ((rc >= CONTROLVM_RESP_SUCCESS) && dev_info)
-   device_epilog(dev_info, state,
- CONTROLVM_DEVICE_CHANGESTATE, >hdr, rc,
- inmsg->hdr.flags.response_expected == 1, 1);
+
+   device_epilog(dev_info, state,
+ CONTROLVM_DEVICE_CHANGESTATE, >hdr, rc,
+ inmsg->hdr.flags.response_expected == 1, 1);
+   return;
+
+err_respond:
+   device_responder(inmsg->hdr.id, >hdr, rc);
 }
 
 static void
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 04/15] staging: unisys: visorbus: fix double response

[David Kershner]

This patch addresses the problem that we were sending double responses
back to the s-Par Firmware when processing CONTROLVM Messages. Every
message responds individually and the epilog functions would send a
response as well.

Since a message could delay the response, it was decided to remove the
extra response from the epilog function.

Signed-off-by: David Kershner <david.kersh...@unisys.com>
Reviewed-by: Tim Sell <timothy.s...@unisys.com>
---
 drivers/staging/unisys/visorbus/visorchipset.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 0cd4ae2..7e2004f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -728,12 +728,17 @@ enum crash_obj_type {
if (response == CONTROLVM_RESP_SUCCESS) {
switch (cmd) {
case CONTROLVM_BUS_CREATE:
+   /* chipset_bus_create is responsible to respond */
chipset_bus_create(bus_info);
break;
case CONTROLVM_BUS_DESTROY:
+   /* chipset_bus_destroy is responsible to respond */
chipset_bus_destroy(bus_info);
break;
+   default:
+   goto out_respond;
}
+   return;
}
 
 out_respond:
@@ -779,6 +784,7 @@ enum crash_obj_type {
if (response >= 0) {
switch (cmd) {
case CONTROLVM_DEVICE_CREATE:
+   /* chipset_device_create is responsible to respond */
chipset_device_create(dev_info);
break;
case CONTROLVM_DEVICE_CHANGESTATE:
@@ -786,6 +792,7 @@ enum crash_obj_type {
if (state.alive == segment_state_running.alive &&
state.operating ==
segment_state_running.operating) {
+   /* chipset_device_resume will respond */
chipset_device_resume(dev_info);
}
/* ServerNotReady / ServerLost / SegmentStateStandby */
@@ -794,15 +801,20 @@ enum crash_obj_type {
 segment_state_standby.operating) {
/*
 * technically this is standby case
-* where server is lost
+* where server is lost and
+* chipset_device_pause will respond
 */
chipset_device_pause(dev_info);
}
break;
case CONTROLVM_DEVICE_DESTROY:
+   /* chipset_device_destroy is responsible to respond */
chipset_device_destroy(dev_info);
break;
+   default:
+   goto out_respond;
}
+   return;
}
 
 out_respond:
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/3] staging: greybus: sdio: fix cmd_flags check for none response

[Viresh Kumar]

On Fri, Sep 30, 2016 at 11:54 PM, Rui Miguel Silva <rmf...@gmail.com> wrote:
> When checking for command flags field if response is not available we
> really need to compare it with the right define and not bitwise AND it.
>
> smatch warn:
> drivers/staging/greybus/sdio.c:481 gb_sdio_command()
> warn: bitwise AND condition is false here
>
> Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
> Signed-off-by: Rui Miguel Silva <rmf...@gmail.com>
> ---
>  drivers/staging/greybus/sdio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c
> index c7133b1..5649ef1 100644
> --- a/drivers/staging/greybus/sdio.c
> +++ b/drivers/staging/greybus/sdio.c
> @@ -478,7 +478,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, 
> struct mmc_command *cmd)
> goto out;
>
> /* no response expected */
> -   if (cmd_flags & GB_SDIO_RSP_NONE)
> +   if (cmd_flags == GB_SDIO_RSP_NONE)
> goto out;
>
> /* long response expected */

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/3] staging: greybus: sdio: fix cmd_flags check for none response

[Rui Miguel Silva]

When checking for command flags field if response is not available we
really need to compare it with the right define and not bitwise AND it.

smatch warn:
drivers/staging/greybus/sdio.c:481 gb_sdio_command()
warn: bitwise AND condition is false here

Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Rui Miguel Silva <rmf...@gmail.com>
---
 drivers/staging/greybus/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c
index c7133b1..5649ef1 100644
--- a/drivers/staging/greybus/sdio.c
+++ b/drivers/staging/greybus/sdio.c
@@ -478,7 +478,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, 
struct mmc_command *cmd)
goto out;
 
    /* no response expected */
-   if (cmd_flags & GB_SDIO_RSP_NONE)
+   if (cmd_flags == GB_SDIO_RSP_NONE)
goto out;
 
/* long response expected */
-- 
2.10.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: greybus: sdio: fix cmd_flags check for none response

[Rui Miguel Silva]

When checking for command flags field if response is not available we
really need to compare it with the right define and not bitwise AND it.

smatch warn:
drivers/staging/greybus/sdio.c:481 gb_sdio_command()
warn: bitwise AND condition is false here

Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Rui Miguel Silva <rmf...@gmail.com>
---
 drivers/staging/greybus/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c
index c7133b1..5649ef1 100644
--- a/drivers/staging/greybus/sdio.c
+++ b/drivers/staging/greybus/sdio.c
@@ -478,7 +478,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, 
struct mmc_command *cmd)
goto out;
 
    /* no response expected */
-   if (cmd_flags & GB_SDIO_RSP_NONE)
+   if (cmd_flags == GB_SDIO_RSP_NONE)
goto out;
 
/* long response expected */
-- 
2.10.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Response

[Mr Daniel H.William]

Hello !
 
accept my sincere apologies for my mode of contacting you out of the blues like 
this but something very urgent and important has come to my notice and I 
strongly believe it’s important we seek your consent for the mutual interest of 
all.

I am  Daniel H.William  Auditor General of HSBC Bank Plc West London during the 
course of our auditing I discovered a floating fund in an account opened in the 
bank in 1990 and since 1993 nobody nobody has operated on this account again, 
after going through some old files in the records I discovered that the owner 
of the account died without a [heir] hence the money is floating and if I do 
not remit this f I do not remit this money out urgently it will be forfeited 
for nothing. the owner of this account is Mr.Alber P.schmidt, a foreigner, and 
an industrialist, and he died, since 1996. and no other person knows about this 
account or any thing concerning it, the account has no other beneficiary and my 
investigation proved to me  he left behind the sum of Nine million, five 
hundred thousand British pounds sterling (£9,500,000.00) deposited in our Bank, 
but unfortunately he did not specify his Heir (Next of Kin) before his sudden 
death. 

The British inheritance Law permits any Bank to confiscate the deceased's fund, 
in case the fund is left unclaimed for over a period of 68 months after the 
death of the account owner. However, the reason why I have contacted you so 
that I will legally recommend you as the heir because. I have all the legal 
documentations to complete this transaction successfully without any problems 
with the government in Britain and in your country, this transaction is 100% 
risk free, I will guide and direct you on what to do at any given time and once 
the fund is transferred into your account I will travel to meet you in your 
country so that we share the funds in the proportion of 40% for you, 40% for me 
and 20% set aside for expenses both parties might incur (if any) during or 
after the transaction.
 
This inheritance claims will be legally completed, all I need from you is your 
total cooperation and honesty. If you are interested to work with me kindly 
forward below information.  to my Private Email:(danielwill...@mynet.com) 
 
Your Full Names:.,……
Your Mobile or Cell Phone Numbers: …….
Your telephone (Office and Home) Numbers:…….
Your fax Number:…….
Your occupation:……..
Your age: 
Your nationality:……..
I look forward to your prompt reply. 

Yours truly, 
Daniel H. William
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/7] staging: unisys: Process more than one response per check

[Benjamin Romer]

From: David Kershner david.kersh...@unisys.com

When s-Par is in polling mode it checks every 2 ms to see if there is
a response from the IO service partition in the queue. Currently it
just reads one entry per 2 ms, this needs to be changed so it drains
the queue on each check.

Signed-off-by: David Kershner david.kersh...@unisys.com
Signed-off-by: Benjamin Romer benjamin.ro...@unisys.com
---
 drivers/staging/unisys/visornic/visornic_main.c | 164 
 1 file changed, 83 insertions(+), 81 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 6ce3fc2..8d600fa 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -1617,93 +1617,95 @@ service_resp_queue(struct uiscmdrsp *cmdrsp, struct 
visornic_devdata *devdata)
 
/* TODO: CLIENT ACQUIRE -- Don't really need this at the
 * moment */
-   if (!visorchannel_signalremove(devdata-dev-visorchannel,
-  IOCHAN_FROM_IOPART,
-  cmdrsp))
-   return; /* queue empty */
-
-   switch (cmdrsp-net.type) {
-   case NET_RCV:
-   devdata-chstat.got_rcv++;
-   /* process incoming packet */
-   visornic_rx(cmdrsp);
-   break;
-   case NET_XMIT_DONE:
-   spin_lock_irqsave(devdata-priv_lock, flags);
-   devdata-chstat.got_xmit_done++;
-   if (cmdrsp-net.xmtdone.xmt_done_result)
-   devdata-chstat.xmit_fail++;
-   /* only call queue wake if we stopped it */
-   netdev = ((struct sk_buff *)cmdrsp-net.buf)-dev;
-   /* ASSERT netdev == vnicinfo-netdev; */
-   if ((netdev == devdata-netdev) 
-   netif_queue_stopped(netdev)) {
-   /* check to see if we have crossed
-* the lower watermark for
-* netif_wake_queue()
-*/
-   if (((devdata-chstat.sent_xmit =
-   devdata-chstat.got_xmit_done) 
-   (devdata-chstat.sent_xmit -
-   devdata-chstat.got_xmit_done =
-   devdata-lower_threshold_net_xmits)) ||
-   ((devdata-chstat.sent_xmit 
-   devdata-chstat.got_xmit_done) 
-   (ULONG_MAX - devdata-chstat.got_xmit_done
-   + devdata-chstat.sent_xmit =
-   devdata-lower_threshold_net_xmits))) {
-   /* enough NET_XMITs completed
-* so can restart netif queue
+   for (;;) {
+   if (!visorchannel_signalremove(devdata-dev-visorchannel,
+  IOCHAN_FROM_IOPART,
+  cmdrsp))
+   break; /* queue empty */
+
+   switch (cmdrsp-net.type) {
+   case NET_RCV:
+   devdata-chstat.got_rcv++;
+   /* process incoming packet */
+   visornic_rx(cmdrsp);
+   break;
+   case NET_XMIT_DONE:
+   spin_lock_irqsave(devdata-priv_lock, flags);
+   devdata-chstat.got_xmit_done++;
+   if (cmdrsp-net.xmtdone.xmt_done_result)
+   devdata-chstat.xmit_fail++;
+   /* only call queue wake if we stopped it */
+   netdev = ((struct sk_buff *)cmdrsp-net.buf)-dev;
+   /* ASSERT netdev == vnicinfo-netdev; */
+   if ((netdev == devdata-netdev) 
+   netif_queue_stopped(netdev)) {
+   /* check to see if we have crossed
+* the lower watermark for
+* netif_wake_queue()
 */
-   netif_wake_queue(netdev);
-   devdata-flow_control_lower_hits++;
+   if (((devdata-chstat.sent_xmit =
+   devdata-chstat.got_xmit_done) 
+   (devdata-chstat.sent_xmit -
+   devdata-chstat.got_xmit_done =
+   devdata-lower_threshold_net_xmits)) ||
+   ((devdata-chstat.sent_xmit 
+   devdata-chstat.got_xmit_done) 
+   (ULONG_MAX - devdata-chstat.got_xmit_done
+   + devdata-chstat.sent_xmit =
+   devdata-lower_threshold_net_xmits

Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

[Vitaly Kuznetsov]

KY Srinivasan k...@microsoft.com writes:

 -Original Message-
 From: Christoph Hellwig [mailto:h...@infradead.org]
 Sent: Friday, July 3, 2015 9:19 AM
 To: Vitaly Kuznetsov
 Cc: linux-s...@vger.kernel.org; Long Li; KY Srinivasan; Haiyang Zhang; James
 E.J. Bottomley; de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
 Subject: Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant
 
 On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote:
  SPC-2/3/4 specs state that The standard INQUIRY data (see table ...)
  shall contain at least 36 bytes. Hyper-V host doesn't always honor this
  requirement, e.g. when there is no physical device present at a particular
  LUN host sets Peripheral qualifier to 011b and Additional length to 0
  (thus making the reply 5-bytes long). Upper level SCSI stack complains
  with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling
  Additional length field in host's reply at the driver level.
 
 This looks like a big mess, and usage of phys_to_virt is not generally
 safe to start with.
 
 If HyperV really is that broken the warning seems correct, but if you
 really have to get rid of it we could add a blist flag to not issue
 the warning in the core code instead of hacking around it in the driver.

 Agreed. We have fixed this issue in win10 and I am trying to get the fix 
 backported.

In case this is fixed in future Hyper-V versions introducing new blist
flags looks like an overkill, let's leave things as they are.

Thanks,

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

[KY Srinivasan]

 -Original Message-
 From: Christoph Hellwig [mailto:h...@infradead.org]
 Sent: Friday, July 3, 2015 9:19 AM
 To: Vitaly Kuznetsov
 Cc: linux-s...@vger.kernel.org; Long Li; KY Srinivasan; Haiyang Zhang; James
 E.J. Bottomley; de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
 Subject: Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant
 
 On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote:
  SPC-2/3/4 specs state that The standard INQUIRY data (see table ...)
  shall contain at least 36 bytes. Hyper-V host doesn't always honor this
  requirement, e.g. when there is no physical device present at a particular
  LUN host sets Peripheral qualifier to 011b and Additional length to 0
  (thus making the reply 5-bytes long). Upper level SCSI stack complains
  with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling
  Additional length field in host's reply at the driver level.
 
 This looks like a big mess, and usage of phys_to_virt is not generally
 safe to start with.
 
 If HyperV really is that broken the warning seems correct, but if you
 really have to get rid of it we could add a blist flag to not issue
 the warning in the core code instead of hacking around it in the driver.

Agreed. We have fixed this issue in win10 and I am trying to get the fix 
backported.

Regards,

K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

[Christoph Hellwig]

On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote:
 SPC-2/3/4 specs state that The standard INQUIRY data (see table ...)
 shall contain at least 36 bytes. Hyper-V host doesn't always honor this
 requirement, e.g. when there is no physical device present at a particular
 LUN host sets Peripheral qualifier to 011b and Additional length to 0
 (thus making the reply 5-bytes long). Upper level SCSI stack complains
 with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling
 Additional length field in host's reply at the driver level.

This looks like a big mess, and usage of phys_to_virt is not generally
safe to start with.

If HyperV really is that broken the warning seems correct, but if you
really have to get rid of it we could add a blist flag to not issue
the warning in the core code instead of hacking around it in the driver.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

[Vitaly Kuznetsov]

SPC-2/3/4 specs state that The standard INQUIRY data (see table ...)
shall contain at least 36 bytes. Hyper-V host doesn't always honor this
requirement, e.g. when there is no physical device present at a particular
LUN host sets Peripheral qualifier to 011b and Additional length to 0
(thus making the reply 5-bytes long). Upper level SCSI stack complains
with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling
Additional length field in host's reply at the driver level.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
This is a hack, the proper fix should probably be done in Hyper-V.
---
 drivers/scsi/storvsc_drv.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3c6584f..bca31af 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1153,6 +1153,7 @@ static void storvsc_on_io_completion(struct hv_device 
*device,
 {
struct storvsc_device *stor_device;
struct vstor_packet *stor_pkt;
+   struct vmbus_packet_mpb_array *payload = request-payload;
 
stor_device = hv_get_drvdata(device);
stor_pkt = request-vstor_packet;
@@ -1174,6 +1175,24 @@ static void storvsc_on_io_completion(struct hv_device 
*device,
vstor_packet-vm_srb.srb_status = SRB_STATUS_SUCCESS;
}
 
+   /*
+* When there is no physical device attached to a LUN Hyper-V host
+* sets Peripheral qualifier to 011b and Additional length to 0. SPC
+* spec, however, says that The standard INQUIRY data ... shall
+* contain at least 36 bytes. Upper level SCSI stack complains with
+* 'INQUIRY result too short (5), using 36'. Mangle host's reply here.
+*/
+   if (stor_pkt-vm_srb.cdb[0] == INQUIRY  payload) {
+   u8 *buf, per_qual, data_len;
+   int range_len = payload-range.len;
+
+   buf = phys_to_virt(payload-range.pfn_array[0]  PAGE_SHIFT) +
+   payload-range.offset;
+   per_qual = (buf[0]  5)  7;
+   data_len = buf[4] + 5;
+   if (per_qual == 3  data_len  min(range_len, 36))
+   buf[4] = min(range_len, 36) - 5;
+   }
 
/* Copy over the status...etc */
stor_pkt-vm_srb.scsi_status = vstor_packet-vm_srb.scsi_status;
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your response is appreciated

[Mr Mahmoud Zayak]

I am Eng. Mahmoud Zayak from Syria. I am looking for a possible tie up with a 
business or individual in your country so that I can do some investments there.

Kindly, reply me so that we can discuss further.

Best Regards
Eng.Mahmoud Zayak
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Your response is appreciated

[Mr Mahmoud Zayak]

I am Eng. Mahmoud Zayak from Syria. I am looking for a possible tie up with a 
business or individual in your country so that I can do some investments there.

Kindly, reply me so that we can discuss further.

Best Regards
Eng.Mahmoud Zayak
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Urgent Response, Mr. GOODWILL KOFI BISSUE

[Mr. GOODWILL KOFI BISSUE]

Dear Sir,

I need your assistance in transferring the sum of (10 Million United State
Dollars) into your account with immediate effect this fund is deposited in
my Bank in Ghana the sharing ration will be 40% for me and 40% for you and
20% for the less privilege once you make this transfer a successful.
please I need your cooperation to get this funds into your account, I am
the bank manager of my bank I want to move out this money into your
account for an investment in your country, Nelson Mandela former president
of south Africa I help him to  deposited this money in my bank in Ghana
and I have be helping him to deposit some of his money in some of the
banks in Africa I have know him for the past 14years I call him on 4th of
June 2013 and I told him since you are sick what I m going to do with your
money be deposited in my bank and he told me if anything happens to him I
should fine away to take this fund and help myself and I should give the
less privilege 20% out of this fund.

First I will pay the sum of $10,000 to open a dollar account on your
behalf in my bank and ATM card will be issue on your name and I will
transfer the fund into your ATM card and the ATM card will be send to you
by DHL so you can use it to withdraw money in any ATM machine in your
country or in any bank in your country, as soon as you receive this card I
will come over to your country so we can use this fund for an investment
and I want to invest my own share of the money in properties.

I don't want you to disclose this to anybody, I will provide you with any
information you need to make this transaction successful I have already
made an arrangement with the foreign remittance department in my bank
regarding this transfer get back to me I will send you the bank contact so
you will contact the bank and the foreign remittance department will open
the dollar account for you and transfer the fund into your ATM card, and
the ATM card will be send to you by DHL and the pin number will be send to
you to enable you to withdraw your funds  from any ATM machine in your
country and the DHL tracking number will be send to you as well.

Please forward to me your vital details in other for us to conclude this
transaction with immediate effect

I wait for your immediate response once you received this email.

Thanks,

MR. GOODWILL KOFI BISSUE

Email: goodwill_kofi_bissue2...@yahoo.com



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response

[Ulf Hansson]

On 15 August 2014 08:06,  rogera...@realtek.com wrote:
 From: Roger Tseng rogera...@realtek.com

 Current code erroneously fill the last byte of R2 response with an undefined
 value. In addition, the controller actually 'offloads' the last byte
 (CRC7, end bit) while receiving R2 response and thus it's impossible to get 
 the
 actual value. This could cause mmc stack to obtain inconsistent CID from the
 same card after resume and misidentify it as a different card.

 Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of 
 R2.

Thanks! Applied for next.

Kind regards
Uffe


 Cc: sta...@vger.kernel.org # v3.8+
 Fixes: ff984e57d36e (mmc: Add realtek pcie sdmmc host driver)
 Signed-off-by: Roger Tseng rogera...@realtek.com
 ---
  drivers/mmc/host/rtsx_pci_sdmmc.c |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
 b/drivers/mmc/host/rtsx_pci_sdmmc.c
 index dfde4a210238..b2537e2f26b1 100644
 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
 +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
 @@ -412,6 +412,13 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
 *host,
 }

 if (rsp_type == SD_RSP_TYPE_R2) {
 +   /*
 +* The controller offloads the last byte {CRC-7, end bit 1'b1}
 +* of response type R2. Assign dummy CRC, 0, and end bit to 
 the
 +* byte(ptr[16], goes into the LSB of resp[3] later).
 +*/
 +   ptr[16] = 1;
 +
 for (i = 0; i  4; i++) {
 cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
 dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
 --
 1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response

[Ulf Hansson]

On 15 August 2014 08:06,  rogera...@realtek.com wrote:
 From: Roger Tseng rogera...@realtek.com

 Current code erroneously fill the last byte of R2 response with an undefined
 value. In addition, the controller actually 'offloads' the last byte
 (CRC7, end bit) while receiving R2 response and thus it's impossible to get 
 the
 actual value. This could cause mmc stack to obtain inconsistent CID from the
 same card after resume and misidentify it as a different card.

 Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of 
 R2.

 Cc: sta...@vger.kernel.org # v3.16+
 Fixes: c7f6558d84af (mmc: Add realtek USB sdmmc host driver)
 Signed-off-by: Roger Tseng rogera...@realtek.com

Thanks! Applied for next.

Kind regards
Uffe


 ---
  drivers/mmc/host/rtsx_usb_sdmmc.c |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
 b/drivers/mmc/host/rtsx_usb_sdmmc.c
 index 5d3766e792f0..d9153a7d160d 100644
 --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
 +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
 @@ -435,6 +435,13 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc 
 *host,
 }

 if (rsp_type == SD_RSP_TYPE_R2) {
 +   /*
 +* The controller offloads the last byte {CRC-7, end bit 1'b1}
 +* of response type R2. Assign dummy CRC, 0, and end bit to 
 the
 +* byte(ptr[16], goes into the LSB of resp[3] later).
 +*/
 +   ptr[16] = 1;
 +
 for (i = 0; i  4; i++) {
 cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
 dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
 --
 1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response

[rogerable]

From: Roger Tseng rogera...@realtek.com

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.

Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.

Cc: sta...@vger.kernel.org # v3.8+
Fixes: ff984e57d36e (mmc: Add realtek pcie sdmmc host driver)
Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a210238..b2537e2f26b1 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,13 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, end bit 1'b1}
+* of response type R2. Assign dummy CRC, 0, and end bit to the
+* byte(ptr[16], goes into the LSB of resp[3] later).
+*/
+   ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response

[rogerable]

From: Roger Tseng rogera...@realtek.com

(The original patch for PCI and USB was splitted here to make it easier for
stable tree.)

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.

Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.

Roger Tseng (2):
  mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
  mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response

 drivers/mmc/host/rtsx_pci_sdmmc.c |7 +++
 drivers/mmc/host/rtsx_usb_sdmmc.c |7 +++
 2 files changed, 14 insertions(+)

-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response

[rogerable]

From: Roger Tseng rogera...@realtek.com

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.

Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.

Cc: sta...@vger.kernel.org # v3.16+
Fixes: c7f6558d84af (mmc: Add realtek USB sdmmc host driver)
Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/host/rtsx_usb_sdmmc.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e792f0..d9153a7d160d 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,6 +435,13 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc 
*host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, end bit 1'b1}
+* of response type R2. Assign dummy CRC, 0, and end bit to the
+* byte(ptr[16], goes into the LSB of resp[3] later).
+*/
+   ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Roger Tseng]

On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote:
 On 11 August 2014 10:32,  rogera...@realtek.com wrote:
  From: Roger Tseng rogera...@realtek.com
 
  Current code erroneously fill the last byte of R2 response with an undefined
  value. In addition, it is impossible to obtain the real values since the
  controller actually 'offloads' the last byte(CRC7, end bit) while receiving 
  R2
  response. This could cause mmc stack to obtain inconsistent CID from the 
  same
  card after resume and misidentify it as a different card.
 
  Fix by assigning a dummy value 0x01 to the last byte of R2 response.
 
  Signed-off-by: Roger Tseng rogera...@realtek.com
 
 Thanks! Queued for 3.18.
 
 I guess this should go for stable as well?
Yes. However, since rtsx_usb* is present in 3.16 and later, this patch
will not apply on 3.15.y or older. Should I separately send an adapted
version to stable?

By the way, according to Dan's comment I would like to add a few word
to explain the code. Would you help fix it up by following diff?

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 54849d8..ca31279 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,7 +412,13 @@ static void sd_send_cmd_get_rsp(struct
realtek_pci_sdmmc *host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, stop bit 1'b1}
+* of response type R2. Assign a dummy CRC, 0, and stop bit to
+* the byte(ptr[16], goes into the LSB of resp[3] later).
+*/
ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index ca08df1..727a88d 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,7 +435,13 @@ static void sd_send_cmd_get_rsp(struct
rtsx_usb_sdmmc *host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, stop bit 1'b1}
+* of response type R2. Assign a dummy CRC, 0, and stop bit to
+* the byte(ptr[16], goes into the LSB of resp[3] later).
+*/
ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,

-- 
Best regards,
Roger Tseng
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Ulf Hansson]

On 14 August 2014 08:06, Roger Tseng rogera...@realtek.com wrote:
 On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote:
 On 11 August 2014 10:32,  rogera...@realtek.com wrote:
  From: Roger Tseng rogera...@realtek.com
 
  Current code erroneously fill the last byte of R2 response with an 
  undefined
  value. In addition, it is impossible to obtain the real values since the
  controller actually 'offloads' the last byte(CRC7, end bit) while 
  receiving R2
  response. This could cause mmc stack to obtain inconsistent CID from the 
  same
  card after resume and misidentify it as a different card.
 
  Fix by assigning a dummy value 0x01 to the last byte of R2 response.
 
  Signed-off-by: Roger Tseng rogera...@realtek.com

 Thanks! Queued for 3.18.

 I guess this should go for stable as well?
 Yes. However, since rtsx_usb* is present in 3.16 and later, this patch
 will not apply on 3.15.y or older. Should I separately send an adapted
 version to stable?

I haven't pushed this externally yet. I will drop the patch from my 3.18 branch.

Then, let's split the patch into two, one for usb and one for pci -
that should simplify patch management.

Additionally, you should include a Cc tag with proper hashmark telling
which kernel each patch should be included into.

Kind regards
Uffe
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Dan Carpenter]

On Tue, Aug 12, 2014 at 03:19:12PM +0800, Roger wrote:
 I can remove the unused rsp_len in this function. But I'm afraid the
 loop is still required. The destination cmd-resp is cpu-endian, but
 the raw response from SD card in the buffer (pointed by ptr) is
 big-endian.

Oh, yes.  Of course.  Sorry for the noise.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Ulf Hansson]

On 11 August 2014 10:32,  rogera...@realtek.com wrote:
 From: Roger Tseng rogera...@realtek.com

 Current code erroneously fill the last byte of R2 response with an undefined
 value. In addition, it is impossible to obtain the real values since the
 controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
 response. This could cause mmc stack to obtain inconsistent CID from the same
 card after resume and misidentify it as a different card.

 Fix by assigning a dummy value 0x01 to the last byte of R2 response.

 Signed-off-by: Roger Tseng rogera...@realtek.com

Thanks! Queued for 3.18.

I guess this should go for stable as well?

Kind regards
Uffe


 ---
  drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
  drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
  2 files changed, 2 insertions(+)

 diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
 b/drivers/mmc/host/rtsx_pci_sdmmc.c
 index dfde4a2..54849d8 100644
 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
 +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
 @@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
 *host,
 }

 if (rsp_type == SD_RSP_TYPE_R2) {
 +   ptr[16] = 1;
 for (i = 0; i  4; i++) {
 cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
 dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
 diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
 b/drivers/mmc/host/rtsx_usb_sdmmc.c
 index 5d3766e..ca08df1 100644
 --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
 +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
 @@ -435,6 +435,7 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc 
 *host,
 }

 if (rsp_type == SD_RSP_TYPE_R2) {
 +   ptr[16] = 1;
 for (i = 0; i  4; i++) {
 cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
 dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
 --
 1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Roger]

On 08/11/2014 09:02 PM, Dan Carpenter wrote:

On Mon, Aug 11, 2014 at 04:32:16PM +0800, rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, it is impossible to obtain the real values since the
controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
response. This could cause mmc stack to obtain inconsistent CID from the same
card after resume and misidentify it as a different card.

Fix by assigning a dummy value 0x01 to the last byte of R2 response.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
  drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a2..54849d8 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
}

if (rsp_type == SD_RSP_TYPE_R2) {
+   ptr[16] = 1;


Avoid magic numbers like 16 and 0x1.

This is subtle enough that it deserves a comment.

ptr[stat_idx] = 0x1 /* 0x1 chosen randomly */

The 0x1 consists of 7-bit dummy zero CRC and stop bit 1, described in SD 
card. Anyway, I'll give a comment to this in the next version.

for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,


There are a lot of magic numbers in this function.  We could get rid
of this i  4 loop but doing:

memcpy(cmd-resp, ptr + 1, resp_len);

Currently we don't use resp_len and the resp_len = 5 assignment is off
by one...  It should be resp_len = 4.  This function is quite ugly.


I can remove the unused rsp_len in this function. But I'm afraid the 
loop is still required. The destination cmd-resp is cpu-endian, but the 
raw response from SD card in the buffer (pointed by ptr) is big-endian.



regards,
dan carpenter


--Please consider the environment before printing this e-mail.
.



Best regards,
Roger Tseng
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[rogerable]

From: Roger Tseng rogera...@realtek.com

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, it is impossible to obtain the real values since the
controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
response. This could cause mmc stack to obtain inconsistent CID from the same
card after resume and misidentify it as a different card.

Fix by assigning a dummy value 0x01 to the last byte of R2 response.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a2..54849d8 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   ptr[16] = 1;
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e..ca08df1 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,6 +435,7 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc *host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   ptr[16] = 1;
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Dan Carpenter]

On Mon, Aug 11, 2014 at 04:32:16PM +0800, rogera...@realtek.com wrote:
 From: Roger Tseng rogera...@realtek.com
 
 Current code erroneously fill the last byte of R2 response with an undefined
 value. In addition, it is impossible to obtain the real values since the
 controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
 response. This could cause mmc stack to obtain inconsistent CID from the same
 card after resume and misidentify it as a different card.
 
 Fix by assigning a dummy value 0x01 to the last byte of R2 response.
 
 Signed-off-by: Roger Tseng rogera...@realtek.com
 ---
  drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
  drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
  2 files changed, 2 insertions(+)
 
 diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
 b/drivers/mmc/host/rtsx_pci_sdmmc.c
 index dfde4a2..54849d8 100644
 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
 +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
 @@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
 *host,
   }
  
   if (rsp_type == SD_RSP_TYPE_R2) {
 + ptr[16] = 1;

Avoid magic numbers like 16 and 0x1.

This is subtle enough that it deserves a comment.

ptr[stat_idx] = 0x1 /* 0x1 chosen randomly */

   for (i = 0; i  4; i++) {
   cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
   dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,

There are a lot of magic numbers in this function.  We could get rid
of this i  4 loop but doing:

memcpy(cmd-resp, ptr + 1, resp_len);

Currently we don't use resp_len and the resp_len = 5 assignment is off
by one...  It should be resp_len = 4.  This function is quite ugly.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Still waiting for your response

[Mrs. Supini Thrunkul]

Hello,

I am Mrs. Supini Thrunkul from Tai Yau Bank Hong Kong, I need your cooperation 
to transfer $ 47.3 million US Dollars to any trusted account within your 
control.

Contact me for more details.  

Mrs. Supini Thrunkul
Tel: +85 2580 848 65



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel