{Spam?} YOU HAVE WON

[juan . arias]

LOTTO.NL,
2391  Beds 152 Koningin Julianaplein 21,
Den Haag-Netherlands.
(Lotto affiliate with Subscriber Agents).
From: Susan Console
(Lottery Coordinator)
Website: www.lotto.nl

Sir/Madam,

CONGRATULATIONS!!!

We are pleased to inform you of the result of the Lotto NL Winners 
International programs held on the 13th of December 2020.  Your e-mail address 
attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 
which was first in the 2nd class of the draws. you are to receive €1,000,000.00 
(One Million Euros). Because of mix up in cash
pay-outs, we ask that you keep your winning information confidential until your 
money (€1,000,000.00) has been fully remitted to you by our accredited 
pay-point bank. 

This measure must be adhere to  avoid loss of your cash prize-winners of our 
cash prizes are advised to adhere to these instructions to forestall the abuse 
of this program by other participants.  

It's important to note that this draws were conducted formally, and winners are 
selected through an internet ballot system from 60,000 individual and companies 
e-mail addresses - the draws are conducted around the world through our 
internet based ballot system. The promotion is sponsored and promoted Lotto NL. 

We congratulate you once again. We hope you will use part of it in our next 
draws; the jackpot winning is €85million.  Remember, all winning must be 
claimed not later than 20 days. After this date all unclaimed cash prize will 
be forfeited and included in the next sweepstake.  Please, in order to avoid 
unnecessary delays and complications remember to quote personal and winning 
numbers in all correspondence with us.

Congratulations once again from all members of Lotto NL. Thank you for being 
part of our promotional program.

To file for the release of your winnings you are advice to contact our Foreign 
Transfer Manager:

MR. WILSON WARREN JOHNSON

Tel: +31-620-561-787

Fax: +31-84-438-5342

Email: johnsonwilson...@gmail.com

{Spam?} YOU HAVE WON

[juan . arias]

LOTTO.NL,
2391  Beds 152 Koningin Julianaplein 21,
Den Haag-Netherlands.
(Lotto affiliate with Subscriber Agents).
From: Susan Console
(Lottery Coordinator)
Website: www.lotto.nl

Sir/Madam,

CONGRATULATIONS!!!

We are pleased to inform you of the result of the Lotto NL Winners 
International programs held on the 13th of December 2020.  Your e-mail address 
attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 
which was first in the 2nd class of the draws. you are to receive €1,000,000.00 
(One Million Euros). Because of mix up in cash
pay-outs, we ask that you keep your winning information confidential until your 
money (€1,000,000.00) has been fully remitted to you by our accredited 
pay-point bank. 

This measure must be adhere to  avoid loss of your cash prize-winners of our 
cash prizes are advised to adhere to these instructions to forestall the abuse 
of this program by other participants.  

It's important to note that this draws were conducted formally, and winners are 
selected through an internet ballot system from 60,000 individual and companies 
e-mail addresses - the draws are conducted around the world through our 
internet based ballot system. The promotion is sponsored and promoted Lotto NL. 

We congratulate you once again. We hope you will use part of it in our next 
draws; the jackpot winning is €85million.  Remember, all winning must be 
claimed not later than 20 days. After this date all unclaimed cash prize will 
be forfeited and included in the next sweepstake.  Please, in order to avoid 
unnecessary delays and complications remember to quote personal and winning 
numbers in all correspondence with us.

Congratulations once again from all members of Lotto NL. Thank you for being 
part of our promotional program.

To file for the release of your winnings you are advice to contact our Foreign 
Transfer Manager:

MR. WILSON WARREN JOHNSON

Tel: +31-620-561-787

Fax: +31-84-438-5342

Email: johnsonwilson...@gmail.com

{Spam?} YOU HAVE WON

[juan . arias]

LOTTO.NL,
2391  Beds 152 Koningin Julianaplein 21,
Den Haag-Netherlands.
(Lotto affiliate with Subscriber Agents).
From: Susan Console
(Lottery Coordinator)
Website: www.lotto.nl

Sir/Madam,

CONGRATULATIONS!!!

We are pleased to inform you of the result of the Lotto NL Winners 
International programs held on the 13th of December 2020.  Your e-mail address 
attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 
which was first in the 2nd class of the draws. you are to receive €1,000,000.00 
(One Million Euros). Because of mix up in cash
pay-outs, we ask that you keep your winning information confidential until your 
money (€1,000,000.00) has been fully remitted to you by our accredited 
pay-point bank. 

This measure must be adhere to  avoid loss of your cash prize-winners of our 
cash prizes are advised to adhere to these instructions to forestall the abuse 
of this program by other participants.  

It's important to note that this draws were conducted formally, and winners are 
selected through an internet ballot system from 60,000 individual and companies 
e-mail addresses - the draws are conducted around the world through our 
internet based ballot system. The promotion is sponsored and promoted Lotto NL. 

We congratulate you once again. We hope you will use part of it in our next 
draws; the jackpot winning is €85million.  Remember, all winning must be 
claimed not later than 20 days. After this date all unclaimed cash prize will 
be forfeited and included in the next sweepstake.  Please, in order to avoid 
unnecessary delays and complications remember to quote personal and winning 
numbers in all correspondence with us.

Congratulations once again from all members of Lotto NL. Thank you for being 
part of our promotional program.

To file for the release of your winnings you are advice to contact our Foreign 
Transfer Manager:

MR. WILSON WARREN JOHNSON

Tel: +31-620-561-787

Fax: +31-84-438-5342

Email: johnsonwilson...@gmail.com

[PATCH v2] staging: trivial: hikey9xx: fix be32<->u32 casting warnings

[Juan Antonio Aldea-Armenteros]

This patch fixes the following warnings reported by sparse, by adding
missing __force annotations.

drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32

drivers/staging/hikey9xx/hisi-spmi-controller.c:239:25: warning: cast from 
restricted __be32

Rationale for #164:
data is declared as u32, and it is read and then converted by means of
be32_to_cpu(). Said function expects a __be32 but data is u32, therefore
there's a type missmatch here.

Rationale for #239:
Is the dual of #164. This time data going to be  written so it
needs to be converted from cpu to __be32, but writel() expects u32 and the
output of cpu_to_be32 returns a __be32.

Signed-off-by: Juan Antonio Aldea-Armenteros 
---
 Changes in V2:
- Fix typo in commit message.

 drivers/staging/hikey9xx/hisi-spmi-controller.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c 
b/drivers/staging/hikey9xx/hisi-spmi-controller.c
index f831c43f4783..861aedd5de48 100644
--- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
+++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
@@ -161,7 +161,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
 SPMI_SLAVE_OFFSET * slave_id +
 SPMI_APB_SPMI_RDATA0_BASE_ADDR +
 i * SPMI_PER_DATAREG_BYTE);
-   data = be32_to_cpu((__be32)data);
+   data = be32_to_cpu((__be32 __force)data);
if ((bc - i * SPMI_PER_DATAREG_BYTE) >> 2) {
memcpy(buf, , sizeof(data));
buf += sizeof(data);
@@ -236,7 +236,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
buf += (bc % SPMI_PER_DATAREG_BYTE);
}
 
-   writel((u32)cpu_to_be32(data),
+   writel((u32 __force)cpu_to_be32(data),
   spmi_controller->base + chnl_ofst +
   SPMI_APB_SPMI_WDATA0_BASE_ADDR +
   SPMI_PER_DATAREG_BYTE * i);
-- 
2.28.0

[PATCH v1] staging: trivial: hikey9xx: fix be32<->u32 casting warnings

[Juan Antonio Aldea-Armenteros]

This patch fixes the following warnings reported by sparse by adding
missing __force annotations.

drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
restricted __be32

drivers/staging/hikey9xx/hisi-spmi-controller.c:239:25: warning: cast from 
restricted __be32

Rationale for #164:
data is declared as u32, and it read then converted by means of
be32_to_cpu(). Said function expects a __be32 but data is u32, therefore
there's a type missmatch here.

Rationale for #293:
Is the dualof #164. This time data going to be  written so it
needs to be converted from cpu to be32, but writel() expects u32 and the
output of cpu_to_be32 returns a __be32.

Signed-off-by: Juan Antonio Aldea-Armenteros 
---
 drivers/staging/hikey9xx/hisi-spmi-controller.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c 
b/drivers/staging/hikey9xx/hisi-spmi-controller.c
index f831c43f4783..861aedd5de48 100644
--- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
+++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
@@ -161,7 +161,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
 SPMI_SLAVE_OFFSET * slave_id +
 SPMI_APB_SPMI_RDATA0_BASE_ADDR +
 i * SPMI_PER_DATAREG_BYTE);
-   data = be32_to_cpu((__be32)data);
+   data = be32_to_cpu((__be32 __force)data);
if ((bc - i * SPMI_PER_DATAREG_BYTE) >> 2) {
memcpy(buf, , sizeof(data));
buf += sizeof(data);
@@ -236,7 +236,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
buf += (bc % SPMI_PER_DATAREG_BYTE);
}
 
-   writel((u32)cpu_to_be32(data),
+   writel((u32 __force)cpu_to_be32(data),
   spmi_controller->base + chnl_ofst +
   SPMI_APB_SPMI_WDATA0_BASE_ADDR +
   SPMI_PER_DATAREG_BYTE * i);
-- 
2.28.0

Re: [PATCH] media: atomisp-mt9m114: replace fixed function names

[Juan Antonio Aldea-Armenteros]

No I didn't intent to. I have sent another version.

Thank you very much, Dan.

Juan Antonio Aldea-Armenteros

[PATCH v3] media: atomisp-mt9m114: replace fixed function names

[Juan Antonio Aldea-Armenteros]

There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.

Replace them:

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");

Signed-off-by: Juan Antonio Aldea-Armenteros 
---
PATCH V2:
* Restored word "error" as pointed out by Dan Carpenter 


PATCH V3: 
* Fix V2 changelog message.

 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 0d60918a9b19..f5de81132177 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -212,7 +212,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_read_reg(client, data_length, reg, );
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
+   v4l2_err(client, "%s error exit, read failed\n", __func__);
return -EINVAL;
}
 
@@ -233,7 +233,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_write_reg(client, data_length, reg, val);
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
+   v4l2_err(client, "%s error exit, write failed\n", __func__);
return -EINVAL;
}
 
-- 
2.27.0

[PATCH v2] media: atomisp-mt9m114: replace fixed function names

[Juan Antonio Aldea-Armenteros]

There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.

Replace them:

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");

Signed-off-by: Juan Antonio Aldea-Armenteros 

PATCH V2:
* Restored word "error" as pointed out by Dan Carpenter 


---
 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 0d60918a9b19..f5de81132177 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -212,7 +212,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_read_reg(client, data_length, reg, );
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
+   v4l2_err(client, "%s error exit, read failed\n", __func__);
return -EINVAL;
}
 
@@ -233,7 +233,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_write_reg(client, data_length, reg, val);
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
+   v4l2_err(client, "%s error exit, write failed\n", __func__);
return -EINVAL;
}
 
-- 
2.27.0

[PATCH] media: atomisp-mt9m114: replace fixed function names

[Juan Antonio Aldea-Armenteros]

There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.

Replace them:

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this 
function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");

Signed-off-by: Juan Antonio Aldea-Armenteros 
---
 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 0d60918a9b19..54c24bc2061d 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -212,7 +212,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_read_reg(client, data_length, reg, );
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
+   v4l2_err(client, "%s exit, read failed\n", __func__);
return -EINVAL;
}
 
@@ -233,7 +233,7 @@ misensor_rmw_reg(struct i2c_client *client, u16 
data_length, u16 reg,
 
err = mt9m114_write_reg(client, data_length, reg, val);
if (err) {
-   v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
+   v4l2_err(client, "%s error exit, write failed\n", __func__);
return -EINVAL;
}
 
-- 
2.27.0

[PATCH] staging: wilc1000: define wilc_get_stats_async as static

[Juan Manuel Torres Palma]

Declare wilc_get_stats_async as static since it's only
used within the definition file scope.

Signed-off-by: Juan Manuel Torres Palma 
---
 drivers/staging/wilc1000/host_interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 70c854d939ce..5dae6e7155d3 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1992,7 +1992,7 @@ int wilc_get_rssi(struct wilc_vif *vif, s8 *rssi_level)
return result;
 }
 
-int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats)
+static int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats)
 {
int result;
struct host_if_msg *msg;
-- 
2.20.1

Request for Partnership-

[Juan Carlos]

Sir/Madam,
 
I have access to very vital information that can be used to move huge amount of 
money. I have done my homework very well and i have the machineries in place to 
get it done since I am still in active service. If it was possible for me to do 
it alone I would not have bothered contacting you. Ultimately I need you to 
play an important role in the completion of this business transaction.
 
Reply if you are willing to do the business.
 
Regards,
Juan Carlos

Request for Partnership-

[Juan Carlos]

Sir/Madam,
 
I have access to very vital information that can be used to move huge amount of 
money. I have done my homework very well and i have the machineries in place to 
get it done since I am still in active service. If it was possible for me to do 
it alone I would not have bothered contacting you. Ultimately I need you to 
play an important role in the completion of this business transaction.
 
Reply if you are willing to do the business.
 
Regards,
Juan Carlos

[SUSPECTED SPAM] INVESTOR

[Mr. Juan Colombas]

Greetings;

I'm Mr Juan Colombas from Lloyds banking Group United Kingdom. I want to invest 
in your country with you. You can view my website and contact me for more 
details

http://www.lloydsbankinggroup.com/our-group/directors/executive-directors/

Mr. Juan Colombas
Email:jcolomb...@gmail.com 
Mobile: +447872219425
www.lloydsbankinggroup.com

Email seguro - Secretaria Adjunta de Tecnologia do Maranhão - SEATI

[SUSPECTED SPAM] INVESTOR

[Mr. Juan Colombas]

Greetings;

I'm Mr Juan Colombas from Lloyds banking Group United Kingdom. I want to invest 
in your country with you. You can view my website and contact me for more 
details

http://www.lloydsbankinggroup.com/our-group/directors/executive-directors/

Mr. Juan Colombas
Email:jcolomb...@gmail.com 
Mobile: +447872219425
www.lloydsbankinggroup.com

Email seguro - Secretaria Adjunta de Tecnologia do Maranhão - SEATI

[PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea <juan@qindel.com>
---
 tools/usb/usbip/src/utils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..3d7b42e 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+   int cmd_size;
 
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
 "%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
 attr_name);
 
if (add)
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+   busid);
else
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+   busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
-- 
2.7.4

[PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea 
---
 tools/usb/usbip/src/utils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..3d7b42e 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+   int cmd_size;
 
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
 "%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
 attr_name);
 
if (add)
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+   busid);
else
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+   busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
-- 
2.7.4

Re: [PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

> Why not use the return value from snprintf() for length, instead of calling
strlen(command)?

Yes, that makes sense. Something like this?

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..3d7b42e 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+   int cmd_size;
 
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
 "%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
 attr_name);
 
if (add)
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+   busid);
else
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+   busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;


Regards,
Juan

Re: [PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

> Why not use the return value from snprintf() for length, instead of calling
strlen(command)?

Yes, that makes sense. Something like this?

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..3d7b42e 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+   int cmd_size;
 
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
 "%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
 attr_name);
 
if (add)
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+   busid);
else
-   snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+   cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+   busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;


Regards,
Juan

[PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea <juan@qindel.com>
---
 tools/usb/usbip/src/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..ea1a1af 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -42,7 +42,7 @@ int modify_match_busid(char *busid, int add)
snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  strlen(command));
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
-- 
2.7.4

[PATCH] usbip: fix usbip bind writing random string after command in match_busid

[Juan Zea]

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea 
---
 tools/usb/usbip/src/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..ea1a1af 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -42,7 +42,7 @@ int modify_match_busid(char *busid, int add)
snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
 
rc = write_sysfs_attribute(match_busid_attr_path, command,
-  sizeof(command));
+  strlen(command));
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
-- 
2.7.4

Beratungsstelle

[Escuela 113, Juan Agustin Ortiz Estrada]

Ihr Postfach hat den von unserem E-Mail-Administrator festgelegten 
Speicherlimit überschritten und Sie können keine neue Mail-Unit erhalten, die 
Sie erneut validieren.
 
Klick hier  
 
um Ihr E-Mail-Konto erneut zu validieren.
 
Vielen Dank
 
Beratungsstelle
Systemadministrator-Team

Beratungsstelle

[Escuela 113, Juan Agustin Ortiz Estrada]

Ihr Postfach hat den von unserem E-Mail-Administrator festgelegten 
Speicherlimit überschritten und Sie können keine neue Mail-Unit erhalten, die 
Sie erneut validieren.
 
Klick hier  
 
um Ihr E-Mail-Konto erneut zu validieren.
 
Vielen Dank
 
Beratungsstelle
Systemadministrator-Team

[PATCH] staging: media: atomisp: fix non static symbol warnings

[Juan Antonio Pedreira Martos]

Fix a couple of sparse warnings:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c:59:14: warning: 
symbol 'repool_pgnr' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c:387:6: warning: 
symbol 'punit_ddr_dvfs_enable' was not declared. Should it be static?

Mark these symbols as static, so they are no longer incorrectly exported.

Signed-off-by: Juan Antonio Pedreira Martos <juan...@gmail.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index e3fdbdba0b34..14d32174c869 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -56,7 +56,7 @@ module_param(skip_fwload, uint, 0644);
 MODULE_PARM_DESC(skip_fwload, "Skip atomisp firmware load");
 
 /* set reserved memory pool size in page */
-unsigned int repool_pgnr;
+static unsigned int repool_pgnr;
 module_param(repool_pgnr, uint, 0644);
 MODULE_PARM_DESC(repool_pgnr,
"Set the reserved memory pool size in page (default:0)");
@@ -384,7 +384,7 @@ static int atomisp_mrfld_pre_power_down(struct 
atomisp_device *isp)
  * WA for DDR DVFS enable/disable
  * By default, ISP will force DDR DVFS 1600MHz before disable DVFS
  */
-void punit_ddr_dvfs_enable(bool enable)
+static void punit_ddr_dvfs_enable(bool enable)
 {
int reg = intel_mid_msgbus_read32(PUNIT_PORT, MRFLD_ISPSSDVFS);
int door_bell = 1 << 8;
-- 
2.13.0

[PATCH] staging: media: atomisp: fix non static symbol warnings

[Juan Antonio Pedreira Martos]

Fix a couple of sparse warnings:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c:59:14: warning: 
symbol 'repool_pgnr' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c:387:6: warning: 
symbol 'punit_ddr_dvfs_enable' was not declared. Should it be static?

Mark these symbols as static, so they are no longer incorrectly exported.

Signed-off-by: Juan Antonio Pedreira Martos 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index e3fdbdba0b34..14d32174c869 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -56,7 +56,7 @@ module_param(skip_fwload, uint, 0644);
 MODULE_PARM_DESC(skip_fwload, "Skip atomisp firmware load");
 
 /* set reserved memory pool size in page */
-unsigned int repool_pgnr;
+static unsigned int repool_pgnr;
 module_param(repool_pgnr, uint, 0644);
 MODULE_PARM_DESC(repool_pgnr,
"Set the reserved memory pool size in page (default:0)");
@@ -384,7 +384,7 @@ static int atomisp_mrfld_pre_power_down(struct 
atomisp_device *isp)
  * WA for DDR DVFS enable/disable
  * By default, ISP will force DDR DVFS 1600MHz before disable DVFS
  */
-void punit_ddr_dvfs_enable(bool enable)
+static void punit_ddr_dvfs_enable(bool enable)
 {
int reg = intel_mid_msgbus_read32(PUNIT_PORT, MRFLD_ISPSSDVFS);
int door_bell = 1 << 8;
-- 
2.13.0

[PATCH] staging: atomisp: fix non static symbol warnings

[Juan Antonio Pedreira Martos]

Fix some unneeded exported symbols by marking them as static.
This was found with the 'sparse' tool.

Signed-off-by: Juan Antonio Pedreira Martos <juan...@gmail.com>
---
 .../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..15409e96449d 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -436,7 +436,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int 
on)
return -EINVAL;
 }
 
-int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
@@ -455,7 +455,8 @@ int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 
return -EINVAL;
 }
-int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
+
+static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -491,7 +492,7 @@ int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -527,7 +528,7 @@ int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
 {
int ret = 0;
struct gmin_subdev *gs = find_gmin_subdev(subdev);
-- 
2.13.0

[PATCH] staging: atomisp: fix non static symbol warnings

[Juan Antonio Pedreira Martos]

Fix some unneeded exported symbols by marking them as static.
This was found with the 'sparse' tool.

Signed-off-by: Juan Antonio Pedreira Martos 
---
 .../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..15409e96449d 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -436,7 +436,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int 
on)
return -EINVAL;
 }
 
-int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
@@ -455,7 +455,8 @@ int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 
return -EINVAL;
 }
-int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
+
+static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -491,7 +492,7 @@ int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -527,7 +528,7 @@ int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
 {
int ret = 0;
struct gmin_subdev *gs = find_gmin_subdev(subdev);
-- 
2.13.0

[PATCH] staging: vt6656: use tabs instead of spaces

[Juan Antonio Pedreira Martos]

Fix a checkpatch error: CODE_INDENT (code indent should use tabs where
possible).

Signed-off-by: Juan Antonio Pedreira Martos <juan...@gmail.com>
---
 drivers/staging/vt6656/rxtx.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 1835cd13ef49..63413492e61d 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -114,7 +114,7 @@ static __le16 vnt_time_stamp_off(struct vnt_private *priv, 
u16 rate)
 }
 
 static u32 vnt_get_rsvtime(struct vnt_private *priv, u8 pkt_type,
-   u32 frame_length, u16 rate, int need_ack)
+   u32 frame_length, u16 rate, int need_ack)
 {
u32 data_time, ack_time;
 
@@ -135,14 +135,14 @@ static u32 vnt_get_rsvtime(struct vnt_private *priv, u8 
pkt_type,
 }
 
 static __le16 vnt_rxtx_rsvtime_le16(struct vnt_private *priv, u8 pkt_type,
-u32 frame_length, u16 rate, int need_ack)
+u32 frame_length, u16 rate, int need_ack)
 {
return cpu_to_le16((u16)vnt_get_rsvtime(priv, pkt_type,
frame_length, rate, need_ack));
 }
 
 static __le16 vnt_get_rtscts_rsvtime_le(struct vnt_private *priv,
-u8 rsv_type, u8 pkt_type, u32 
frame_length, u16 current_rate)
+u8 rsv_type, u8 pkt_type, u32 
frame_length, u16 current_rate)
 {
u32 rrv_time, rts_time, cts_time, ack_time, data_time;
 
@@ -160,19 +160,19 @@ static __le16 vnt_get_rtscts_rsvtime_le(struct 
vnt_private *priv,
rts_time = vnt_get_frame_time(priv->preamble_type,
pkt_type, 20, priv->top_cck_basic_rate);
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_cck_basic_rate);
+ 14, priv->top_cck_basic_rate);
ack_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_ofdm_basic_rate);
+ 14, priv->top_ofdm_basic_rate);
} else if (rsv_type == 2) {
rts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 20, priv->top_ofdm_basic_rate);
+ 20, priv->top_ofdm_basic_rate);
cts_time = ack_time = vnt_get_frame_time(priv->preamble_type,
pkt_type, 14, priv->top_ofdm_basic_rate);
} else if (rsv_type == 3) {
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_cck_basic_rate);
+ 14, priv->top_cck_basic_rate);
ack_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_ofdm_basic_rate);
+ 14, priv->top_ofdm_basic_rate);
 
rrv_time = cts_time + ack_time + data_time + 2 * priv->sifs;
 
@@ -227,7 +227,7 @@ static __le16 vnt_get_rtscts_duration_le(struct 
vnt_usb_send_context *context,
case RTSDUR_AA_F0:
case RTSDUR_AA_F1:
cts_time = vnt_get_frame_time(priv->preamble_type,
- pkt_type, 14, 
priv->top_ofdm_basic_rate);
+ pkt_type, 14, 
priv->top_ofdm_basic_rate);
dur_time = cts_time + 2 * priv->sifs +
vnt_get_rsvtime(priv, pkt_type,
frame_length, rate, need_ack);
@@ -410,7 +410,7 @@ static u16 vnt_rxtx_rts_g_head(struct vnt_usb_send_context 
*tx_context,
u16 current_rate = tx_context->tx_rate;
 
vnt_get_phy_field(priv, rts_frame_len, priv->top_cck_basic_rate,
- PK_TYPE_11B, >b);
+ PK_TYPE_11B, >b);
vnt_get_phy_field(priv, rts_frame_len, priv->top_ofdm_basic_rate,
  tx_context->pkt_type, >a);
 
@@ -437,7 +437,7 @@ static u16 vnt_rxtx_rts_g_fb_head(struct 
vnt_usb_send_context *tx_context,
u16 rts_frame_len = 20;
 
vnt_get_phy_field(priv, rts_frame_len, priv->top_cck_basic_rate,
- PK_TYPE_11B, >b);
+ PK_TYPE_11B, >b);
vnt_get_phy_field(priv, rts_frame_len, priv->top_ofdm_basic_rate,
  tx_context->pkt_type, >a);
 
@@ -683,9 +683,9 @@ static u16 vnt_rxtx_ab(struct vnt_usb_send_context 
*tx_context,
 }
 
 static u16 vnt_generate_tx_parameter(struct vnt_usb_send_context *tx_context

[PATCH] staging: vt6656: use tabs instead of spaces

[Juan Antonio Pedreira Martos]

Fix a checkpatch error: CODE_INDENT (code indent should use tabs where
possible).

Signed-off-by: Juan Antonio Pedreira Martos 
---
 drivers/staging/vt6656/rxtx.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 1835cd13ef49..63413492e61d 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -114,7 +114,7 @@ static __le16 vnt_time_stamp_off(struct vnt_private *priv, 
u16 rate)
 }
 
 static u32 vnt_get_rsvtime(struct vnt_private *priv, u8 pkt_type,
-   u32 frame_length, u16 rate, int need_ack)
+   u32 frame_length, u16 rate, int need_ack)
 {
u32 data_time, ack_time;
 
@@ -135,14 +135,14 @@ static u32 vnt_get_rsvtime(struct vnt_private *priv, u8 
pkt_type,
 }
 
 static __le16 vnt_rxtx_rsvtime_le16(struct vnt_private *priv, u8 pkt_type,
-u32 frame_length, u16 rate, int need_ack)
+u32 frame_length, u16 rate, int need_ack)
 {
return cpu_to_le16((u16)vnt_get_rsvtime(priv, pkt_type,
frame_length, rate, need_ack));
 }
 
 static __le16 vnt_get_rtscts_rsvtime_le(struct vnt_private *priv,
-u8 rsv_type, u8 pkt_type, u32 
frame_length, u16 current_rate)
+u8 rsv_type, u8 pkt_type, u32 
frame_length, u16 current_rate)
 {
u32 rrv_time, rts_time, cts_time, ack_time, data_time;
 
@@ -160,19 +160,19 @@ static __le16 vnt_get_rtscts_rsvtime_le(struct 
vnt_private *priv,
rts_time = vnt_get_frame_time(priv->preamble_type,
pkt_type, 20, priv->top_cck_basic_rate);
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_cck_basic_rate);
+ 14, priv->top_cck_basic_rate);
ack_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_ofdm_basic_rate);
+ 14, priv->top_ofdm_basic_rate);
} else if (rsv_type == 2) {
rts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 20, priv->top_ofdm_basic_rate);
+ 20, priv->top_ofdm_basic_rate);
cts_time = ack_time = vnt_get_frame_time(priv->preamble_type,
pkt_type, 14, priv->top_ofdm_basic_rate);
} else if (rsv_type == 3) {
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_cck_basic_rate);
+ 14, priv->top_cck_basic_rate);
ack_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
- 14, priv->top_ofdm_basic_rate);
+ 14, priv->top_ofdm_basic_rate);
 
rrv_time = cts_time + ack_time + data_time + 2 * priv->sifs;
 
@@ -227,7 +227,7 @@ static __le16 vnt_get_rtscts_duration_le(struct 
vnt_usb_send_context *context,
case RTSDUR_AA_F0:
case RTSDUR_AA_F1:
cts_time = vnt_get_frame_time(priv->preamble_type,
- pkt_type, 14, 
priv->top_ofdm_basic_rate);
+ pkt_type, 14, 
priv->top_ofdm_basic_rate);
dur_time = cts_time + 2 * priv->sifs +
vnt_get_rsvtime(priv, pkt_type,
frame_length, rate, need_ack);
@@ -410,7 +410,7 @@ static u16 vnt_rxtx_rts_g_head(struct vnt_usb_send_context 
*tx_context,
u16 current_rate = tx_context->tx_rate;
 
vnt_get_phy_field(priv, rts_frame_len, priv->top_cck_basic_rate,
- PK_TYPE_11B, >b);
+ PK_TYPE_11B, >b);
vnt_get_phy_field(priv, rts_frame_len, priv->top_ofdm_basic_rate,
  tx_context->pkt_type, >a);
 
@@ -437,7 +437,7 @@ static u16 vnt_rxtx_rts_g_fb_head(struct 
vnt_usb_send_context *tx_context,
u16 rts_frame_len = 20;
 
vnt_get_phy_field(priv, rts_frame_len, priv->top_cck_basic_rate,
- PK_TYPE_11B, >b);
+ PK_TYPE_11B, >b);
vnt_get_phy_field(priv, rts_frame_len, priv->top_ofdm_basic_rate,
  tx_context->pkt_type, >a);
 
@@ -683,9 +683,9 @@ static u16 vnt_rxtx_ab(struct vnt_usb_send_context 
*tx_context,
 }
 
 static u16 vnt_generate_tx_parameter(struct vnt_usb_send_context *tx_context,
-  

[PATCH] staging: android: ion: fix QUOTED_WHITESPACE_BEFORE_NEWLINE

[Juan Antonio Pedreira Martos]

Fix checkpatch warning: unnecessary whitespace before a quoted newline.

Signed-off-by: Juan Antonio Pedreira Martos <juan...@gmail.com>
---
 drivers/staging/android/ion/ion_chunk_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 9c257c7a2ba0..102c09398317 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -150,7 +150,7 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-   pr_debug("%s: base %pa size %zu \n", __func__,
+   pr_debug("%s: base %pa size %zu\n", __func__,
 _heap->base, heap_data->size);
 
return _heap->heap;
-- 
2.12.2

[PATCH] staging: android: ion: fix QUOTED_WHITESPACE_BEFORE_NEWLINE

[Juan Antonio Pedreira Martos]

Fix checkpatch warning: unnecessary whitespace before a quoted newline.

Signed-off-by: Juan Antonio Pedreira Martos 
---
 drivers/staging/android/ion/ion_chunk_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 9c257c7a2ba0..102c09398317 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -150,7 +150,7 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-   pr_debug("%s: base %pa size %zu \n", __func__,
+   pr_debug("%s: base %pa size %zu\n", __func__,
 _heap->base, heap_data->size);
 
return _heap->heap;
-- 
2.12.2

[PATCH] spi: use sg_next for walking through the allocated scatterlist table

[Juan Gutierrez]

A null dereference or Oops exception might occurs when reading at once the
whole content of an spi-nor of big enough size that requires an scatterlist
table that does not fit into one single page.

The spi_map_buf function is ignoring the chained sg case by dereferenceing
the scatterlist elements in an array fashion. This wrongly assumes that
the allocation of the scatterlist elements are contiguous. This is true as
long as the scatterlist table fits within a PAGE_SIZE. However, for
allocation where the scatter table is bigger than that, the pages allocated
by sg_alloc might not be contigous.

The sg table can be properly walked by sg_next instead of using an array.

Signed-off-by: Juan Gutierrez <juan.gutier...@nxp.com>
---
 drivers/spi/spi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 838783c..6435548 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -720,6 +720,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
int desc_len;
int sgs;
struct page *vm_page;
+   struct scatterlist *sg;
void *sg_buf;
size_t min;
int i, ret;
@@ -738,6 +739,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
if (ret != 0)
return ret;
 
+   sg = >sgl[0];
for (i = 0; i < sgs; i++) {
 
if (vmalloced_buf || kmap_buf) {
@@ -751,16 +753,17 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
sg_free_table(sgt);
return -ENOMEM;
}
-   sg_set_page(>sgl[i], vm_page,
+   sg_set_page(sg, vm_page,
min, offset_in_page(buf));
} else {
min = min_t(size_t, len, desc_len);
sg_buf = buf;
-   sg_set_buf(>sgl[i], sg_buf, min);
+   sg_set_buf(sg, sg_buf, min);
}
 
buf += min;
len -= min;
+   sg = sg_next(sg);
}
 
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-- 
2.7.4

[PATCH] spi: use sg_next for walking through the allocated scatterlist table

[Juan Gutierrez]

A null dereference or Oops exception might occurs when reading at once the
whole content of an spi-nor of big enough size that requires an scatterlist
table that does not fit into one single page.

The spi_map_buf function is ignoring the chained sg case by dereferenceing
the scatterlist elements in an array fashion. This wrongly assumes that
the allocation of the scatterlist elements are contiguous. This is true as
long as the scatterlist table fits within a PAGE_SIZE. However, for
allocation where the scatter table is bigger than that, the pages allocated
by sg_alloc might not be contigous.

The sg table can be properly walked by sg_next instead of using an array.

Signed-off-by: Juan Gutierrez 
---
 drivers/spi/spi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 838783c..6435548 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -720,6 +720,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
int desc_len;
int sgs;
struct page *vm_page;
+   struct scatterlist *sg;
void *sg_buf;
size_t min;
int i, ret;
@@ -738,6 +739,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
if (ret != 0)
return ret;
 
+   sg = >sgl[0];
for (i = 0; i < sgs; i++) {
 
if (vmalloced_buf || kmap_buf) {
@@ -751,16 +753,17 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
sg_free_table(sgt);
return -ENOMEM;
}
-   sg_set_page(>sgl[i], vm_page,
+   sg_set_page(sg, vm_page,
min, offset_in_page(buf));
} else {
min = min_t(size_t, len, desc_len);
sg_buf = buf;
-   sg_set_buf(>sgl[i], sg_buf, min);
+   sg_set_buf(sg, sg_buf, min);
}
 
buf += min;
len -= min;
+   sg = sg_next(sg);
}
 
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-- 
2.7.4

[PATCH] spi: use sg_next for walking through the allocated scatterlist table

[Juan Gutierrez]

A null dereference or Oops exception might occurs when reading at once the
whole content of an spi-nor of big enough size that requires an scatterlist
table that does not fit into one single page.

The spi_map_buf function is ignoring the chained sg case by dereferenceing
the scatterlist elements in an array fashion. This wrongly assumes that
the allocation of the scatterlist elements are contiguous. This is true as
long as the scatterlist table fits within a PAGE_SIZE. However, for
allocation where the scatter table is bigger than that, the pages allocated
by sg_alloc might not be contigous.

The sg table can be properly walked by sg_next instead of using an array.

Signed-off-by: Juan Gutierrez <juan.gutier...@nxp.com>
---
 drivers/spi/spi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 838783c..6435548 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -720,6 +720,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
int desc_len;
int sgs;
struct page *vm_page;
+   struct scatterlist *sg;
void *sg_buf;
size_t min;
int i, ret;
@@ -738,6 +739,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
if (ret != 0)
return ret;
 
+   sg = >sgl[0];
for (i = 0; i < sgs; i++) {
 
if (vmalloced_buf || kmap_buf) {
@@ -751,16 +753,17 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
sg_free_table(sgt);
return -ENOMEM;
}
-   sg_set_page(>sgl[i], vm_page,
+   sg_set_page(sg, vm_page,
min, offset_in_page(buf));
} else {
min = min_t(size_t, len, desc_len);
sg_buf = buf;
-   sg_set_buf(>sgl[i], sg_buf, min);
+   sg_set_buf(sg, sg_buf, min);
}
 
buf += min;
len -= min;
+   sg = sg_next(sg);
}
 
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-- 
2.7.4

[PATCH] spi: use sg_next for walking through the allocated scatterlist table

[Juan Gutierrez]

A null dereference or Oops exception might occurs when reading at once the
whole content of an spi-nor of big enough size that requires an scatterlist
table that does not fit into one single page.

The spi_map_buf function is ignoring the chained sg case by dereferenceing
the scatterlist elements in an array fashion. This wrongly assumes that
the allocation of the scatterlist elements are contiguous. This is true as
long as the scatterlist table fits within a PAGE_SIZE. However, for
allocation where the scatter table is bigger than that, the pages allocated
by sg_alloc might not be contigous.

The sg table can be properly walked by sg_next instead of using an array.

Signed-off-by: Juan Gutierrez 
---
 drivers/spi/spi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 838783c..6435548 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -720,6 +720,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
int desc_len;
int sgs;
struct page *vm_page;
+   struct scatterlist *sg;
void *sg_buf;
size_t min;
int i, ret;
@@ -738,6 +739,7 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
if (ret != 0)
return ret;
 
+   sg = >sgl[0];
for (i = 0; i < sgs; i++) {
 
if (vmalloced_buf || kmap_buf) {
@@ -751,16 +753,17 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
sg_free_table(sgt);
return -ENOMEM;
}
-   sg_set_page(>sgl[i], vm_page,
+   sg_set_page(sg, vm_page,
min, offset_in_page(buf));
} else {
min = min_t(size_t, len, desc_len);
sg_buf = buf;
-   sg_set_buf(>sgl[i], sg_buf, min);
+   sg_set_buf(sg, sg_buf, min);
}
 
buf += min;
len -= min;
+   sg = sg_next(sg);
}
 
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-- 
2.7.4

Hallo

[Juan]

Hallo
Mrs. Liliane picked you. For details email her
directly:lbettencou...@hotmail.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hallo

[Juan]

Hallo
Mrs. Liliane picked you. For details email her
directly:lbettencou...@hotmail.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenliche E-mail

[Herr Juan Sebastian Morato]

Guten Tag, 

Ich bin Herr Juan Sebastian Morato, der Auditor General von Unicaja Bank 
Madrid. Im Zuge meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds 
auf einem Konto, das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz 
von Unicaja Gruppe gekauft wurde, ich bin der Abschlusspruefer der einem toten 
Auslaender Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede 
Anstrengung, ein Mitglied seiner Familie oder einen naechsten Angehoerigen zu 
Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass 
Sie zu den  naechsten Angehoerigen gehoeren, da Sie den gleichen Nachnamen 
tragen. Er verstarb ohne Nachkommen oder einen Testament.

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Sebastian Morato
Fax 00 34 917 692 656
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenliche E-mail

[Herr Juan Sebastian Morato]

Guten Tag, 

Ich bin Herr Juan Sebastian Morato, der Auditor General von Unicaja Bank 
Madrid. Im Zuge meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds 
auf einem Konto, das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz 
von Unicaja Gruppe gekauft wurde, ich bin der Abschlusspruefer der einem toten 
Auslaender Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede 
Anstrengung, ein Mitglied seiner Familie oder einen naechsten Angehoerigen zu 
Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass 
Sie zu den  naechsten Angehoerigen gehoeren, da Sie den gleichen Nachnamen 
tragen. Er verstarb ohne Nachkommen oder einen Testament.

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Sebastian Morato
Fax 00 34 917 692 656
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenlichen Brief

[Herr Juan Sebastian Morato]

Guten Tag, 

Ich bin Herr Juan Sebastian Morato, der Auditor General von Unicaja Bank 
Madrid. Im Zuge meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds 
auf einem Konto, das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz 
von Unicaja Gruppe gekauft wurde, ich bin der Abschlusspruefer der einem toten 
Auslaender Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede 
Anstrengung, ein Mitglied seiner Familie oder einen naechsten Angehoerigen zu 
Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass 
Sie zu den  naechsten Angehoerigen gehoeren, da Sie den gleichen Nachnamen 
tragen. Er verstarb ohne Nachkommen oder einen Testament.

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Sebastian Morato
Fax 00 34 917 692 656

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenlichen Brief

[Herr Juan Sebastian Morato]

Guten Tag, 

Ich bin Herr Juan Sebastian Morato, der Auditor General von Unicaja Bank 
Madrid. Im Zuge meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds 
auf einem Konto, das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz 
von Unicaja Gruppe gekauft wurde, ich bin der Abschlusspruefer der einem toten 
Auslaender Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede 
Anstrengung, ein Mitglied seiner Familie oder einen naechsten Angehoerigen zu 
Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass 
Sie zu den  naechsten Angehoerigen gehoeren, da Sie den gleichen Nachnamen 
tragen. Er verstarb ohne Nachkommen oder einen Testament.

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Sebastian Morato
Fax 00 34 917 692 656

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Confidential Letter

[Mr. Juan Sebastian Morato]

Dear Friend, 

I am Mr. Juan Sebastian Morato, the Auditor General of Unicaja Bank Madrid. In 
the course of my auditing, I discovered a floating fund in an account, which 
was opened in 1990 at Cam Bank before it was bought over by Unicaja Group which 
I am the auditor belonging to a dead foreigner Mr. Kenny who died in 2004. 
Every effort made to track any member of his family or next of kin has since 
failed; hence I got in contact with you to stand as his next of kin since you 
bear the same last name. He died leaving no heir or a will.

My intention is to transfer this sum of 5.5M in the aforementioned account to a 
safe account. I am therefore proposing that you quietly partner with me and 
provide an account or set up a new one that will serve the purpose of receiving 
this fund. For your assistance in this venture, I am ready to part with a good 
percentage of the entire funds. After going through the deceased person's 
records and files, I discovered that:

(1) No one has operated this account since 2004
(2) He died without an heir; hence the money has been floating.
(3) No other person knows about this account and there was no known beneficiary.

If I do not remit this money urgently, it would be forfeited and subsequently 
converted to company's funds, which will benefit only the directors of my firm. 
This money can be approved to you legally as with all the necessary documentary 
approvals in your name. However, you would be required to show some proof of 
claim, which I will provide you with and also guide you on how to make your 
applications.

Please do give me a reply on my private e-mail juan.mora...@1email.eu or fax 00 
34 917 692 656 so that I can send you detailed information on the modalities of 
my proposition. I completely trust you to keep this proposition absolutely 
confidential. Kindly forward your telephone number where I can reach you 
easily. I look forward to your prompt response.

Best Regards,
Mr. Juan Sebastian Morato
Fax: 00 34 917 692 656
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Confidential Letter

[Mr. Juan Sebastian Morato]

Dear Friend, 

I am Mr. Juan Sebastian Morato, the Auditor General of Unicaja Bank Madrid. In 
the course of my auditing, I discovered a floating fund in an account, which 
was opened in 1990 at Cam Bank before it was bought over by Unicaja Group which 
I am the auditor belonging to a dead foreigner Mr. Kenny who died in 2004. 
Every effort made to track any member of his family or next of kin has since 
failed; hence I got in contact with you to stand as his next of kin since you 
bear the same last name. He died leaving no heir or a will.

My intention is to transfer this sum of 5.5M in the aforementioned account to a 
safe account. I am therefore proposing that you quietly partner with me and 
provide an account or set up a new one that will serve the purpose of receiving 
this fund. For your assistance in this venture, I am ready to part with a good 
percentage of the entire funds. After going through the deceased person's 
records and files, I discovered that:

(1) No one has operated this account since 2004
(2) He died without an heir; hence the money has been floating.
(3) No other person knows about this account and there was no known beneficiary.

If I do not remit this money urgently, it would be forfeited and subsequently 
converted to company's funds, which will benefit only the directors of my firm. 
This money can be approved to you legally as with all the necessary documentary 
approvals in your name. However, you would be required to show some proof of 
claim, which I will provide you with and also guide you on how to make your 
applications.

Please do give me a reply on my private e-mail juan.mora...@1email.eu or fax 00 
34 917 692 656 so that I can send you detailed information on the modalities of 
my proposition. I completely trust you to keep this proposition absolutely 
confidential. Kindly forward your telephone number where I can reach you 
easily. I look forward to your prompt response.

Best Regards,
Mr. Juan Sebastian Morato
Fax: 00 34 917 692 656
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nbd] NBD Maintainer

[Juan Antonio Martinez]

El mié, 14-01-2015 a las 07:33 +, Tuomas Räsänen escribió:
> Hi
> 
> On Tue Jan 13 21:26:01 2015 GMT+0200, Paul Clements wrote:
> > On Tue, Jan 13, 2015 at 11:14 AM, Andrey Utkin
> >  wrote:
> > > Hi Paul,
> > > could you please describe
> > > - how wide is NBD usage today (any estimation is ok),

We at Universidad Politécnica de Madrid (Spain) have 7 clustered NBD
servers, 200+ nbd clients and about 3500 users ( teachers & students )

AFAIK NBD based LTSP installations are very common in educational
environments

Juan Antonio

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nbd] NBD Maintainer

[Juan Antonio Martinez]

El mié, 14-01-2015 a las 07:33 +, Tuomas Räsänen escribió:
 Hi
 
 On Tue Jan 13 21:26:01 2015 GMT+0200, Paul Clements wrote:
  On Tue, Jan 13, 2015 at 11:14 AM, Andrey Utkin
  andrey.krieger.ut...@gmail.com wrote:
   Hi Paul,
   could you please describe
   - how wide is NBD usage today (any estimation is ok),

We at Universidad Politécnica de Madrid (Spain) have 7 clustered NBD
servers, 200+ nbd clients and about 3500 users ( teachers  students )

AFAIK NBD based LTSP installations are very common in educational
environments

Juan Antonio

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenlichen Brief: /

[Herr Juan Morato]

Guten Tag, 

Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank Madrid. Im Zuge 
meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds auf einem Konto, 
das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz von Unicaja Gruppe 
gekauft wurde,  ich bin der Abschlusspruefer der einem toten Auslaender Herr 
Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede Anstrengung , ein Mitglied 
seiner Familie oder einen naechsten Angehoerigen zu Ermitteln sind gescheitert 
.Bei meinen Ermittlungen habe ich festgestellt , dass Sie zu den  naechsten 
Angehoerigen gehoeren , da Sie den gleichen Nachnamen tragen. Er verstarb ohne 
Nachkommen oder einen Testament .

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Morato
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Persoenlichen Brief: /

[Herr Juan Morato]

Guten Tag, 

Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank Madrid. Im Zuge 
meiner Abschlusspruefung, entdeckte ich eine schwimmende Fonds auf einem Konto, 
das 1990 bei der Cam Bank eroeffnet wurde, bevor der Besitz von Unicaja Gruppe 
gekauft wurde,  ich bin der Abschlusspruefer der einem toten Auslaender Herr 
Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede Anstrengung , ein Mitglied 
seiner Familie oder einen naechsten Angehoerigen zu Ermitteln sind gescheitert 
.Bei meinen Ermittlungen habe ich festgestellt , dass Sie zu den  naechsten 
Angehoerigen gehoeren , da Sie den gleichen Nachnamen tragen. Er verstarb ohne 
Nachkommen oder einen Testament .

Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf 
ein sicheres Konto  zu ueberweisen. Ich schlage daher vor, dass ich Sie als 
stillen Teilhaber eintrage und Sie mir ein Konto zur Verfuegung stellen, oder 
ein neues Konto eroeffnen um dieses Geld dorthin zu ueberweisen. Fuer Ihre 
Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz 
des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der 
verstorbenen Person, entdeckte ich dass 

(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiss und auch kein 
Empfaenger eingetragen ist 

Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld 
verfallen und anschliessend in Gesellschaftsmitteln fliessen, von denen nur die 
Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld 
rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen, die auf 
Ihren Namen zugelassen sind ausfuellen, wobei ich Ihnen selbstverstaendlich 
behilflich sein werde.

Bitte geben Sie mir eine Antwort auf meine private E-Mail 
juan.mora...@1email.eu oder Fax 00 34 917 692 656, so dass ich Ihnen 
detaillierte Informationen ueber die Modalitäten meines Vorschlages zu senden 
kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu 
behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu 
erreichen sind. Ich freue mich auf Ihre baldige Antwort.

Mit freundlichen Gruessen
Herr Juan Morato
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Confidential Email-v

[Mr. Juan Morato]

Dear Friend, 

I am Mr. Juan Morato, the Auditor General of Unicaja Bank Madrid. In the course 
of my auditing, I discovered a floating fund in an account, which was opened in 
1990 at Cam Bank before it was bought over by Unicaja Group which I am the 
auditor belonging to a dead foreigner Mr. Kenny who died in 2004. Every effort 
made to track any member of his family or next of kin has since failed; hence I 
got in contact with you to stand as his next of kin since you bear the same 
last name. He died leaving no heir or a will.

My intention is to transfer this sum of 5.5M in the aforementioned account to a 
safe account. I am therefore proposing that you quietly partner with me and 
provide an account or set up a new one that will serve the purpose of receiving 
this fund. For your assistance in this venture, I am ready to part with a good 
percentage of the entire funds. After going through the deceased person's 
records and files, I discovered that:

(1) No one has operated this account since 2004
(2) He died without an heir; hence the money has been floating.
(3) No other person knows about this account and there was no known beneficiary.

If I do not remit this money urgently, it would be forfeited and subsequently 
converted to company's funds, which will benefit only the directors of my firm. 
This money can be approved to you legally as with all the necessary documentary 
approvals in your name. However, you would be required to show some proof of 
claim, which I will provide you with and also guide you on how to make your 
applications.

Please do give me a reply on my private e-mail juan.mora...@1email.eu or fax 00 
34 917 692 656 so that I can send you detailed information on the modalities of 
my proposition. I completely trust you to keep this proposition absolutely 
confidential. Kindly forward your telephone number where I can reach you 
easily. I look forward to your prompt response.

Best Regards,
Mr. Juan Morato
Tel: 00 34 634 031 280
Fax: 00 34 917 692 656
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Confidential Email-v

[Mr. Juan Morato]

Dear Friend, 

I am Mr. Juan Morato, the Auditor General of Unicaja Bank Madrid. In the course 
of my auditing, I discovered a floating fund in an account, which was opened in 
1990 at Cam Bank before it was bought over by Unicaja Group which I am the 
auditor belonging to a dead foreigner Mr. Kenny who died in 2004. Every effort 
made to track any member of his family or next of kin has since failed; hence I 
got in contact with you to stand as his next of kin since you bear the same 
last name. He died leaving no heir or a will.

My intention is to transfer this sum of 5.5M in the aforementioned account to a 
safe account. I am therefore proposing that you quietly partner with me and 
provide an account or set up a new one that will serve the purpose of receiving 
this fund. For your assistance in this venture, I am ready to part with a good 
percentage of the entire funds. After going through the deceased person's 
records and files, I discovered that:

(1) No one has operated this account since 2004
(2) He died without an heir; hence the money has been floating.
(3) No other person knows about this account and there was no known beneficiary.

If I do not remit this money urgently, it would be forfeited and subsequently 
converted to company's funds, which will benefit only the directors of my firm. 
This money can be approved to you legally as with all the necessary documentary 
approvals in your name. However, you would be required to show some proof of 
claim, which I will provide you with and also guide you on how to make your 
applications.

Please do give me a reply on my private e-mail juan.mora...@1email.eu or fax 00 
34 917 692 656 so that I can send you detailed information on the modalities of 
my proposition. I completely trust you to keep this proposition absolutely 
confidential. Kindly forward your telephone number where I can reach you 
easily. I look forward to your prompt response.

Best Regards,
Mr. Juan Morato
Tel: 00 34 634 031 280
Fax: 00 34 917 692 656
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: i.MX27 pca100: remove deprecated IRQF_DISABLED

[Juan Solano]

This flag is a NOOP and can be removed now.

Signed-off-by: Juan Solano 
---
 arch/arm/mach-imx/mach-pca100.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index bf3ac51..20e7c33 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -245,8 +245,7 @@ static int pca100_sdhc2_init(struct device *dev, 
irq_handler_t detect_irq,
int ret;
 
ret = request_irq(gpio_to_irq(IMX_GPIO_NR(3, 29)), detect_irq,
- IRQF_DISABLED | IRQF_TRIGGER_FALLING,
- "imx-mmc-detect", data);
+ IRQF_TRIGGER_FALLING, "imx-mmc-detect", data);
if (ret)
printk(KERN_ERR
"pca100: Failed to request irq for sd/mmc detection\n");
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: i.MX27 pca100: remove deprecated IRQF_DISABLED

[Juan Solano]

This flag is a NOOP and can be removed now.

Signed-off-by: Juan Solano j...@jsolano.com
---
 arch/arm/mach-imx/mach-pca100.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index bf3ac51..20e7c33 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -245,8 +245,7 @@ static int pca100_sdhc2_init(struct device *dev, 
irq_handler_t detect_irq,
int ret;
 
ret = request_irq(gpio_to_irq(IMX_GPIO_NR(3, 29)), detect_irq,
- IRQF_DISABLED | IRQF_TRIGGER_FALLING,
- imx-mmc-detect, data);
+ IRQF_TRIGGER_FALLING, imx-mmc-detect, data);
if (ret)
printk(KERN_ERR
pca100: Failed to request irq for sd/mmc detection\n);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Vertraulich //

[Herr Juan Morato]

Guten Abend,

Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank-  
Madrid. Im Zuge meiner Abschlussprüfung, entdeckte ich eine  
schwimmende Fonds auf einem Konto, das 1990 bei der Cam Bank eröffnet  
wurde, bevor der Besitz von Unicaja Gruppe gekauft wurde,  ich bin der  
Abschlussprüfer der einem toten Ausländer Herr Kenny, der im Jahr 2004  
starb, zugeteilt wurde. Jede Anstrengung, ein Mitglied seiner Familie  
oder einen nächsten Angehörigen zu Ermitteln sind gescheitert. Bei  
meinen Ermittlungen habe ich festgestellt, dass Sie zu den  nächsten  
Angehörigen gehören, da Sie den gleichen Nachnamen tragen. Er verstarb  
ohne Nachkommen oder einen Testament.


Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten  
Konto auf ein sicheres Konto  zu überweisen. Ich schlage daher vor,  
dass ich Sie als stillen Teilhaber eintrage und Sie mir ein Konto zur  
Verfügung stellen, oder ein neues Konto eröffnen um dieses Geld  
dorthin zu überweisen. Für Ihre Unterstützung bei diesem Vorhaben, bin  
ich bereit, mit einem guten Prozentsatz des gesamten Fonds zu trennen.  
Beim durchsehen der Aufzeichnungen und Akten der verstorbenen Person,  
entdeckte ich, dass:


(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiß und auch kein  
Empfänger eingetragen ist 


Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird  
dieses Geld verfallen und anschließend in Gesellschaftsmitteln  
fließen, von denen nur die Regisseure meiner Firma profitieren  
 werden.  Ich kann Ihnen dieses Geld rechtlich zukommen lassen, wenn  
Sie einige notwendigen Genehmigungen ,die auf  Ihren Namen zugelassen  
sind ausfüllen,wobei ich Ihnen selbstverständlich behilflich sein werde.


Bitte geben Sie mir eine Antwort auf meine private E -Mail-  
juan.mora...@1email.eu oder Fax + 34 917 692 656, so dass ich Ihnen  
detaillierte Informationen über die Modalitäten meines Vorschlages  zu  
senden kann. Ich bitte Sie eingehend dieses Schreiben absolut  
vertraulich zu behandeln. Bitte senden Sie mir Ihre Telefonnummer auf  
der sie leicht zu erreichen sind. Ich freue mich auf Ihre baldige  
Antwort.


Mit freundlichen Grüßen
Herr Juan Morato
Tel.: + 34 631 178 660

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Vertraulich //

[Herr Juan Morato]

Guten Abend,

Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank-  
Madrid. Im Zuge meiner Abschlussprüfung, entdeckte ich eine  
schwimmende Fonds auf einem Konto, das 1990 bei der Cam Bank eröffnet  
wurde, bevor der Besitz von Unicaja Gruppe gekauft wurde,  ich bin der  
Abschlussprüfer der einem toten Ausländer Herr Kenny, der im Jahr 2004  
starb, zugeteilt wurde. Jede Anstrengung, ein Mitglied seiner Familie  
oder einen nächsten Angehörigen zu Ermitteln sind gescheitert. Bei  
meinen Ermittlungen habe ich festgestellt, dass Sie zu den  nächsten  
Angehörigen gehören, da Sie den gleichen Nachnamen tragen. Er verstarb  
ohne Nachkommen oder einen Testament.


Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten  
Konto auf ein sicheres Konto  zu überweisen. Ich schlage daher vor,  
dass ich Sie als stillen Teilhaber eintrage und Sie mir ein Konto zur  
Verfügung stellen, oder ein neues Konto eröffnen um dieses Geld  
dorthin zu überweisen. Für Ihre Unterstützung bei diesem Vorhaben, bin  
ich bereit, mit einem guten Prozentsatz des gesamten Fonds zu trennen.  
Beim durchsehen der Aufzeichnungen und Akten der verstorbenen Person,  
entdeckte ich, dass:


(1) Niemand dieses Konto seit 2004 betrieben hat
(2) Er starb ohne Erben, daher das Geld weiter floss.
(3) Keine andere Person über dieses Konto bescheid weiß und auch kein  
Empfänger eingetragen ist 


Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird  
dieses Geld verfallen und anschließend in Gesellschaftsmitteln  
fließen, von denen nur die Regisseure meiner Firma profitieren  
 werden.  Ich kann Ihnen dieses Geld rechtlich zukommen lassen, wenn  
Sie einige notwendigen Genehmigungen ,die auf  Ihren Namen zugelassen  
sind ausfüllen,wobei ich Ihnen selbstverständlich behilflich sein werde.


Bitte geben Sie mir eine Antwort auf meine private E -Mail-  
juan.mora...@1email.eu oder Fax + 34 917 692 656, so dass ich Ihnen  
detaillierte Informationen über die Modalitäten meines Vorschlages  zu  
senden kann. Ich bitte Sie eingehend dieses Schreiben absolut  
vertraulich zu behandeln. Bitte senden Sie mir Ihre Telefonnummer auf  
der sie leicht zu erreichen sind. Ich freue mich auf Ihre baldige  
Antwort.


Mit freundlichen Grüßen
Herr Juan Morato
Tel.: + 34 631 178 660

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

[Juan Manuel Cabo]

Just tested with 3.13.7 which contains the EC fix, and I get the same
discarded event as your pastbin shows, but instead my LID status is
correctly reported as "open" always.

So now I'm sure it boils down to your _WAK method not rechecking the LID state 
(mine
does, I have a Samsung Series 5 NP530U3C).
If it did recheck the LID state and issue, then it wouldn't have mattered 
whether
an accumulated LID event was discarded.


So I see two possible fixes:
1) Modify the EC fix so that it doesn't discard events and instead 
processes them.
or
2) Restrict the models to which the EC fix applies, as in Lan Tianyu patch, 
but
it needs to be broather.


Lan Tianyu patch contains just these DMI_PRODUCT_NAME matches:

530U3BI/530U4BI/530U4BH
530U3C/530U4C/532U3C

These two should at least be added:
530U3C/530U4C   (reported by my laptop)
535U3C (reported by D. G. Jansen laptop)

and also, at least all the ones needed for:

Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B, NP550P5C)
Samsung Series 9 (models NP900X3F, NP900X4B, NP900X4C, NP900X4D, NP900X3C)


I hope this helped,

Cheers!
--
Juan Manuel Cabo



On 03/25/2014 05:41 PM, Juan Manuel Cabo wrote:
> I can see a LID event being discarded here on resume:
>
>   [  728.861983] ACPI : EC: <--- command = 0x84
>   [  728.864062] ACPI : EC: ---> status = 0x09
>   [  728.864070] ACPI : EC: ---> data = 0x5f
>   [  728.864075] ACPI : EC: <--- command = 0x84
>   [  728.868054] ACPI : EC: ---> status = 0x09
>   [  728.868061] ACPI : EC: ---> data = 0x00
>   [  728.868066] ACPI : EC: 1 stale EC events cleared
>   [  728.868079] ACPI: Waking up from system sleep state S3
>
> the 0x5F event means it's a LID change event (both in your dsdt and mine, 
> look for: Q5F)
>
> But there is still something I'm not sure of. So I will test that RC8 kernel 
> tonight on my
> laptop and let you all know. If RC8 still works on my laptop, then I guess 
> the best would be
> to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not 
> affected anymore.
> Thank you so much Stefan for your in-depth tests!
>
> Cheers!
> --
> Juan Manuel Cabo
>
>
>
> On 03/25/2014 05:24 PM, Stefan Biereigel wrote:
>> Alright - as I have some spare time tonight, here is the dmesg of one
>> sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
>> dynamic debug enabled. After resuming, lid state was still "closed", so
>> the bug was triggered (and the stale event is removed as stated).
>>
>> http://pastebin.ca/2679209
>>
>> You can find the "EC: 1 stale EC events cleared" Line @ Line 316. I
>> really did not expect that much traffic from the EC, interesting to get
>> some insight into that!
>>
>> Regarding other actions: The system notices removal of the AC cord when
>> in sleep (xfce4-power-manager reports the correct symbol after the
>> wakeup), so I guess this is working as it should (as it is handled by
>> the _WAK-Routine??).
>>
>> Hope that helps!
>> Stefan
>>
>>
>> Am 25.03.2014 14:23, schrieb Kieran Clancy:
>>> On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu  wrote:
>>>> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel :
>>>>> Hi,
>>>>> thank you for the suggestion. The patch resolves the issue on my N150
>>>>> when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
>>>>> problems to mine now exist on the Samsung Series 7/9 notebooks?
>>>>>
>>>>> Is any further action from my part required?
>>>> Do you have these machines? If yes, please provide the output of
>>>> dmidecode command.
>>>>
>>>> Cc guys  of commit ad332c8a.
>>> Hi guys,
>>>
>>> That's a surprising side-effect, although I guess I shouldn't be
>>> surprised by Samsung ACPI weirdness anymore.
>>>
>>> If we can, I'd like to get to the bottom of this rather than just turn
>>> off this fix (which we know works for series 5, 7 and 9 without
>>> problems).
>>>
>>>>>> 2014-03-24 15:50 GMT+08:00 Stefan Biereigel :
>>>>>>> Hi,
>>>>>>>
>>>>>>> starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
>>>>>>> system is set up, so that it should suspend to RAM as soon as the lid is
>>>>>>> closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed"
>>>>>>> correctly the first time (and the syst

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

[Juan Manuel Cabo]

I can see a LID event being discarded here on resume:

  [  728.861983] ACPI : EC: <--- command = 0x84
  [  728.864062] ACPI : EC: ---> status = 0x09
  [  728.864070] ACPI : EC: ---> data = 0x5f
  [  728.864075] ACPI : EC: <--- command = 0x84
  [  728.868054] ACPI : EC: ---> status = 0x09
  [  728.868061] ACPI : EC: ---> data = 0x00
  [  728.868066] ACPI : EC: 1 stale EC events cleared
  [  728.868079] ACPI: Waking up from system sleep state S3

the 0x5F event means it's a LID change event (both in your dsdt and mine, look 
for: Q5F)

But there is still something I'm not sure of. So I will test that RC8 kernel 
tonight on my
laptop and let you all know. If RC8 still works on my laptop, then I guess the 
best would be
to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not 
affected anymore.
Thank you so much Stefan for your in-depth tests!

Cheers!
--
Juan Manuel Cabo



On 03/25/2014 05:24 PM, Stefan Biereigel wrote:
> Alright - as I have some spare time tonight, here is the dmesg of one
> sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
> dynamic debug enabled. After resuming, lid state was still "closed", so
> the bug was triggered (and the stale event is removed as stated).
>
> http://pastebin.ca/2679209
>
> You can find the "EC: 1 stale EC events cleared" Line @ Line 316. I
> really did not expect that much traffic from the EC, interesting to get
> some insight into that!
>
> Regarding other actions: The system notices removal of the AC cord when
> in sleep (xfce4-power-manager reports the correct symbol after the
> wakeup), so I guess this is working as it should (as it is handled by
> the _WAK-Routine??).
>
> Hope that helps!
> Stefan
>
>
> Am 25.03.2014 14:23, schrieb Kieran Clancy:
>> On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu  wrote:
>>> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel :
>>>> Hi,
>>>> thank you for the suggestion. The patch resolves the issue on my N150
>>>> when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
>>>> problems to mine now exist on the Samsung Series 7/9 notebooks?
>>>>
>>>> Is any further action from my part required?
>>> Do you have these machines? If yes, please provide the output of
>>> dmidecode command.
>>>
>>> Cc guys  of commit ad332c8a.
>> Hi guys,
>>
>> That's a surprising side-effect, although I guess I shouldn't be
>> surprised by Samsung ACPI weirdness anymore.
>>
>> If we can, I'd like to get to the bottom of this rather than just turn
>> off this fix (which we know works for series 5, 7 and 9 without
>> problems).
>>
>>>>> 2014-03-24 15:50 GMT+08:00 Stefan Biereigel :
>>>>>> Hi,
>>>>>>
>>>>>> starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
>>>>>> system is set up, so that it should suspend to RAM as soon as the lid is
>>>>>> closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed"
>>>>>> correctly the first time (and the system suspends), but after resuming
>>>>>> from standby (by opening the lid), the lid does not change to "open" 
>>>>>> again.
>>>>>> Of course, closing the lid again does not induce suspend to RAM then.
>>>>>> Opening the lid now (while not sleeping), makes ACPI notify the opening,
>>>>>> so I guess ACPI "misses" or discards the lid open event from the EC when
>>>>>> coming from sleep.
>>>>>> Now, closing the lid again does induce suspend to RAM. This behaviour is
>>>>>> reproducible: every other time, suspending works.
>>>>>>
>>>>>> This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
>>>>>> Clear stale EC events on Samsung systems.
>>>>>> Which was introduced after 3.14-rc5.
>>>>>>
>>>>>> When opening the lid to resume from standby, i see in dmesg:
>>>>>> Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
>>>>>> events cleared
>>>>>> (which comes from drivers/acpi/ec.c)
>>>>>>
>>>>>> Seems to me, that the "open" event is cleared from the EC, but also
>>>>>> discarded instead of passed on. Shouldn't the correct behaviour be to
>>>>>> report all the pending events, read from the EC, as ACPI events? Can you
>>>>>> point me in a direction for fixing the

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

[Juan Manuel Cabo]

I bet that his _WAK dsdt method isn't re-checking the lid state on resume
(maybe I'm wrong).

I retested on my system just to make sure, and the lid is correctly reported 
open
always after resume from a sleep by closing the lid, using a different kernel 
with that same patch.

My system is the Samsung Series 5 NP530U3C in which the patch works fine:
  
   Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
   Product Name: 530U3C/530U4C

"sudo acpi_listen" shows the following on resume:

  video GFX0 0080 
  button/lid LID0 0080 0001
  button/lid LID0 0080 0002

"cat /proc/acpi/button/lid/LID0/state" shows its open always on resume. I 
suspended
several times, and on each time it was open.

I bet that that system's _WAK method doesn't recheck the lid, I might be wrong.
*Stefan*: Can you extract that method and send it? Something like this:

   sudo cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.bin
   cd /tmp/dsdt.bin
   iasl -d dsdt.bin
   # AND EDIT the resulting dsdt.dsl and search for and send us the 
_WAK method

Also, on my system, the DSDT Q event for lid state change reads it from the EC 
to the LIDS var,
instead of just toggling the "LIDS" variable (Lid Status). My own dsdt is 
downloadable from my
blog, at 
http://zenstep.com.ar/files/DSDT_SamsungSeries5-NP530U3c-AB1_WithBios_P14AAJ.dsl

Cheers!
--
Juan Manuel Cabo


On 03/25/2014 10:23 AM, Kieran Clancy wrote:
> On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu  wrote:
>> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel :
>>> Hi,
>>> thank you for the suggestion. The patch resolves the issue on my N150
>>> when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
>>> problems to mine now exist on the Samsung Series 7/9 notebooks?
>>>
>>> Is any further action from my part required?
>> Do you have these machines? If yes, please provide the output of
>> dmidecode command.
>>
>> Cc guys  of commit ad332c8a.
> Hi guys,
>
> That's a surprising side-effect, although I guess I shouldn't be
> surprised by Samsung ACPI weirdness anymore.
>
> If we can, I'd like to get to the bottom of this rather than just turn
> off this fix (which we know works for series 5, 7 and 9 without
> problems).
>
>>>> 2014-03-24 15:50 GMT+08:00 Stefan Biereigel :
>>>>> Hi,
>>>>>
>>>>> starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
>>>>> system is set up, so that it should suspend to RAM as soon as the lid is
>>>>> closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed"
>>>>> correctly the first time (and the system suspends), but after resuming
>>>>> from standby (by opening the lid), the lid does not change to "open" 
>>>>> again.
>>>>> Of course, closing the lid again does not induce suspend to RAM then.
>>>>> Opening the lid now (while not sleeping), makes ACPI notify the opening,
>>>>> so I guess ACPI "misses" or discards the lid open event from the EC when
>>>>> coming from sleep.
>>>>> Now, closing the lid again does induce suspend to RAM. This behaviour is
>>>>> reproducible: every other time, suspending works.
>>>>>
>>>>> This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
>>>>> Clear stale EC events on Samsung systems.
>>>>> Which was introduced after 3.14-rc5.
>>>>>
>>>>> When opening the lid to resume from standby, i see in dmesg:
>>>>> Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
>>>>> events cleared
>>>>> (which comes from drivers/acpi/ec.c)
>>>>>
>>>>> Seems to me, that the "open" event is cleared from the EC, but also
>>>>> discarded instead of passed on. Shouldn't the correct behaviour be to
>>>>> report all the pending events, read from the EC, as ACPI events? Can you
>>>>> point me in a direction for fixing the issue cleanly, then I will try to
>>>>> find a solution and prepare a patch for this issue.
> Stefan, thank you for reporting this issue.
>
> Our rationale for discarding the events was that events queued during
> sleep are probably no longer relevant. There could also be other
> unwanted side-effects of blindly executing all of the old
> instructions. But in your case, this assumption might be wrong.
>
> What command are you using to check if the lid is "open" or "closed"?
> Is it because the screen is not w

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not open after suspend to RAM.

[Juan Manuel Cabo]

I bet that his _WAK dsdt method isn't re-checking the lid state on resume
(maybe I'm wrong).

I retested on my system just to make sure, and the lid is correctly reported 
open
always after resume from a sleep by closing the lid, using a different kernel 
with that same patch.

My system is the Samsung Series 5 NP530U3C in which the patch works fine:
  
   Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
   Product Name: 530U3C/530U4C

sudo acpi_listen shows the following on resume:

  video GFX0 0080 
  button/lid LID0 0080 0001
  button/lid LID0 0080 0002

cat /proc/acpi/button/lid/LID0/state shows its open always on resume. I 
suspended
several times, and on each time it was open.

I bet that that system's _WAK method doesn't recheck the lid, I might be wrong.
*Stefan*: Can you extract that method and send it? Something like this:

   sudo cat /sys/firmware/acpi/tables/DSDT  /tmp/dsdt.bin
   cd /tmp/dsdt.bin
   iasl -d dsdt.bin
   # AND EDIT the resulting dsdt.dsl and search for and send us the 
_WAK method

Also, on my system, the DSDT Q event for lid state change reads it from the EC 
to the LIDS var,
instead of just toggling the LIDS variable (Lid Status). My own dsdt is 
downloadable from my
blog, at 
http://zenstep.com.ar/files/DSDT_SamsungSeries5-NP530U3c-AB1_WithBios_P14AAJ.dsl

Cheers!
--
Juan Manuel Cabo


On 03/25/2014 10:23 AM, Kieran Clancy wrote:
 On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu lantianyu1...@gmail.com wrote:
 2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,
 thank you for the suggestion. The patch resolves the issue on my N150
 when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
 problems to mine now exist on the Samsung Series 7/9 notebooks?

 Is any further action from my part required?
 Do you have these machines? If yes, please provide the output of
 dmidecode command.

 Cc guys  of commit ad332c8a.
 Hi guys,

 That's a surprising side-effect, although I guess I shouldn't be
 surprised by Samsung ACPI weirdness anymore.

 If we can, I'd like to get to the bottom of this rather than just turn
 off this fix (which we know works for series 5, 7 and 9 without
 problems).

 2014-03-24 15:50 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,

 starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
 system is set up, so that it should suspend to RAM as soon as the lid is
 closed. Beginning with 3.14-rc6, the lid goes from open to closed
 correctly the first time (and the system suspends), but after resuming
 from standby (by opening the lid), the lid does not change to open 
 again.
 Of course, closing the lid again does not induce suspend to RAM then.
 Opening the lid now (while not sleeping), makes ACPI notify the opening,
 so I guess ACPI misses or discards the lid open event from the EC when
 coming from sleep.
 Now, closing the lid again does induce suspend to RAM. This behaviour is
 reproducible: every other time, suspending works.

 This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
 Clear stale EC events on Samsung systems.
 Which was introduced after 3.14-rc5.

 When opening the lid to resume from standby, i see in dmesg:
 Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
 events cleared
 (which comes from drivers/acpi/ec.c)

 Seems to me, that the open event is cleared from the EC, but also
 discarded instead of passed on. Shouldn't the correct behaviour be to
 report all the pending events, read from the EC, as ACPI events? Can you
 point me in a direction for fixing the issue cleanly, then I will try to
 find a solution and prepare a patch for this issue.
 Stefan, thank you for reporting this issue.

 Our rationale for discarding the events was that events queued during
 sleep are probably no longer relevant. There could also be other
 unwanted side-effects of blindly executing all of the old
 instructions. But in your case, this assumption might be wrong.

 What command are you using to check if the lid is open or closed?
 Is it because the screen is not waking up, or some other effect, or
 just because it won't suspend again when it's re-closed?

 Do other events like AC plug/unplug affect any of this if you do them
 during this bad state?

 I'd like to see exactly which EC command byte is being thrown away
 here. If you do something like this (with dynamic debug enabled)

 echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control

 You should get massively verbose EC stuff filling your dmesg, but I am
 just interested in the EC read/write bytes just before and around the
 1 stale EC events cleared message. Grab this out of dmesg before it
 fills with other stuff.

 This will tell us what command we are being asked to run. If you can,
 please do it a few times to see if it's the same command each time or
 something different.

 You can turn the debug output off again

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not open after suspend to RAM.

[Juan Manuel Cabo]

I can see a LID event being discarded here on resume:

  [  728.861983] ACPI : EC: --- command = 0x84
  [  728.864062] ACPI : EC: --- status = 0x09
  [  728.864070] ACPI : EC: --- data = 0x5f
  [  728.864075] ACPI : EC: --- command = 0x84
  [  728.868054] ACPI : EC: --- status = 0x09
  [  728.868061] ACPI : EC: --- data = 0x00
  [  728.868066] ACPI : EC: 1 stale EC events cleared
  [  728.868079] ACPI: Waking up from system sleep state S3

the 0x5F event means it's a LID change event (both in your dsdt and mine, look 
for: Q5F)

But there is still something I'm not sure of. So I will test that RC8 kernel 
tonight on my
laptop and let you all know. If RC8 still works on my laptop, then I guess the 
best would be
to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not 
affected anymore.
Thank you so much Stefan for your in-depth tests!

Cheers!
--
Juan Manuel Cabo



On 03/25/2014 05:24 PM, Stefan Biereigel wrote:
 Alright - as I have some spare time tonight, here is the dmesg of one
 sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
 dynamic debug enabled. After resuming, lid state was still closed, so
 the bug was triggered (and the stale event is removed as stated).

 http://pastebin.ca/2679209

 You can find the EC: 1 stale EC events cleared Line @ Line 316. I
 really did not expect that much traffic from the EC, interesting to get
 some insight into that!

 Regarding other actions: The system notices removal of the AC cord when
 in sleep (xfce4-power-manager reports the correct symbol after the
 wakeup), so I guess this is working as it should (as it is handled by
 the _WAK-Routine??).

 Hope that helps!
 Stefan


 Am 25.03.2014 14:23, schrieb Kieran Clancy:
 On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu lantianyu1...@gmail.com wrote:
 2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,
 thank you for the suggestion. The patch resolves the issue on my N150
 when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
 problems to mine now exist on the Samsung Series 7/9 notebooks?

 Is any further action from my part required?
 Do you have these machines? If yes, please provide the output of
 dmidecode command.

 Cc guys  of commit ad332c8a.
 Hi guys,

 That's a surprising side-effect, although I guess I shouldn't be
 surprised by Samsung ACPI weirdness anymore.

 If we can, I'd like to get to the bottom of this rather than just turn
 off this fix (which we know works for series 5, 7 and 9 without
 problems).

 2014-03-24 15:50 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,

 starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
 system is set up, so that it should suspend to RAM as soon as the lid is
 closed. Beginning with 3.14-rc6, the lid goes from open to closed
 correctly the first time (and the system suspends), but after resuming
 from standby (by opening the lid), the lid does not change to open 
 again.
 Of course, closing the lid again does not induce suspend to RAM then.
 Opening the lid now (while not sleeping), makes ACPI notify the opening,
 so I guess ACPI misses or discards the lid open event from the EC when
 coming from sleep.
 Now, closing the lid again does induce suspend to RAM. This behaviour is
 reproducible: every other time, suspending works.

 This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
 Clear stale EC events on Samsung systems.
 Which was introduced after 3.14-rc5.

 When opening the lid to resume from standby, i see in dmesg:
 Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
 events cleared
 (which comes from drivers/acpi/ec.c)

 Seems to me, that the open event is cleared from the EC, but also
 discarded instead of passed on. Shouldn't the correct behaviour be to
 report all the pending events, read from the EC, as ACPI events? Can you
 point me in a direction for fixing the issue cleanly, then I will try to
 find a solution and prepare a patch for this issue.
 Stefan, thank you for reporting this issue.

 Our rationale for discarding the events was that events queued during
 sleep are probably no longer relevant. There could also be other
 unwanted side-effects of blindly executing all of the old
 instructions. But in your case, this assumption might be wrong.

 What command are you using to check if the lid is open or closed?
 Is it because the screen is not waking up, or some other effect, or
 just because it won't suspend again when it's re-closed?

 Do other events like AC plug/unplug affect any of this if you do them
 during this bad state?

 I'd like to see exactly which EC command byte is being thrown away
 here. If you do something like this (with dynamic debug enabled)

 echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control

 You should get massively verbose EC stuff filling your dmesg, but I am
 just interested in the EC read/write bytes just before and around the
 1 stale

Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not open after suspend to RAM.

[Juan Manuel Cabo]

Just tested with 3.13.7 which contains the EC fix, and I get the same
discarded event as your pastbin shows, but instead my LID status is
correctly reported as open always.

So now I'm sure it boils down to your _WAK method not rechecking the LID state 
(mine
does, I have a Samsung Series 5 NP530U3C).
If it did recheck the LID state and issue, then it wouldn't have mattered 
whether
an accumulated LID event was discarded.


So I see two possible fixes:
1) Modify the EC fix so that it doesn't discard events and instead 
processes them.
or
2) Restrict the models to which the EC fix applies, as in Lan Tianyu patch, 
but
it needs to be broather.


Lan Tianyu patch contains just these DMI_PRODUCT_NAME matches:

530U3BI/530U4BI/530U4BH
530U3C/530U4C/532U3C

These two should at least be added:
530U3C/530U4C   (reported by my laptop)
535U3C (reported by D. G. Jansen laptop)

and also, at least all the ones needed for:

Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B, NP550P5C)
Samsung Series 9 (models NP900X3F, NP900X4B, NP900X4C, NP900X4D, NP900X3C)


I hope this helped,

Cheers!
--
Juan Manuel Cabo



On 03/25/2014 05:41 PM, Juan Manuel Cabo wrote:
 I can see a LID event being discarded here on resume:

   [  728.861983] ACPI : EC: --- command = 0x84
   [  728.864062] ACPI : EC: --- status = 0x09
   [  728.864070] ACPI : EC: --- data = 0x5f
   [  728.864075] ACPI : EC: --- command = 0x84
   [  728.868054] ACPI : EC: --- status = 0x09
   [  728.868061] ACPI : EC: --- data = 0x00
   [  728.868066] ACPI : EC: 1 stale EC events cleared
   [  728.868079] ACPI: Waking up from system sleep state S3

 the 0x5F event means it's a LID change event (both in your dsdt and mine, 
 look for: Q5F)

 But there is still something I'm not sure of. So I will test that RC8 kernel 
 tonight on my
 laptop and let you all know. If RC8 still works on my laptop, then I guess 
 the best would be
 to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not 
 affected anymore.
 Thank you so much Stefan for your in-depth tests!

 Cheers!
 --
 Juan Manuel Cabo



 On 03/25/2014 05:24 PM, Stefan Biereigel wrote:
 Alright - as I have some spare time tonight, here is the dmesg of one
 sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
 dynamic debug enabled. After resuming, lid state was still closed, so
 the bug was triggered (and the stale event is removed as stated).

 http://pastebin.ca/2679209

 You can find the EC: 1 stale EC events cleared Line @ Line 316. I
 really did not expect that much traffic from the EC, interesting to get
 some insight into that!

 Regarding other actions: The system notices removal of the AC cord when
 in sleep (xfce4-power-manager reports the correct symbol after the
 wakeup), so I guess this is working as it should (as it is handled by
 the _WAK-Routine??).

 Hope that helps!
 Stefan


 Am 25.03.2014 14:23, schrieb Kieran Clancy:
 On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu lantianyu1...@gmail.com wrote:
 2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,
 thank you for the suggestion. The patch resolves the issue on my N150
 when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
 problems to mine now exist on the Samsung Series 7/9 notebooks?

 Is any further action from my part required?
 Do you have these machines? If yes, please provide the output of
 dmidecode command.

 Cc guys  of commit ad332c8a.
 Hi guys,

 That's a surprising side-effect, although I guess I shouldn't be
 surprised by Samsung ACPI weirdness anymore.

 If we can, I'd like to get to the bottom of this rather than just turn
 off this fix (which we know works for series 5, 7 and 9 without
 problems).

 2014-03-24 15:50 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
 Hi,

 starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
 system is set up, so that it should suspend to RAM as soon as the lid is
 closed. Beginning with 3.14-rc6, the lid goes from open to closed
 correctly the first time (and the system suspends), but after resuming
 from standby (by opening the lid), the lid does not change to open 
 again.
 Of course, closing the lid again does not induce suspend to RAM then.
 Opening the lid now (while not sleeping), makes ACPI notify the opening,
 so I guess ACPI misses or discards the lid open event from the EC when
 coming from sleep.
 Now, closing the lid again does induce suspend to RAM. This behaviour is
 reproducible: every other time, suspending works.

 This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
 Clear stale EC events on Samsung systems.
 Which was introduced after 3.14-rc5.

 When opening the lid to resume from standby, i see in dmesg:
 Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
 events cleared
 (which comes from drivers/acpi/ec.c

Re: [PATCH v2] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

Beware, the context line:
 static struct dmi_system_id ec_dmi_table[] __initdata = {
has changed in recent kernels, so that line of the patch would need
to be different for it to apply older kernels.
It used to be this:
 static struct dmi_system_id __initdata ec_dmi_table[] = {
until 3.11 I guess.

It is just a context line and is not important for the patch itself.

See:
http://lxr.free-electrons.com/source/drivers/acpi/ec.c?v=3.11
http://lxr.free-electrons.com/source/drivers/acpi/ec.c?v=3.12

Cheers!
--Juan Manuel Cabo


On 03/05/2014 10:24 PM, Kieran Clancy wrote:
> On Thu, Mar 6, 2014 at 11:22 AM, Rafael J. Wysocki  wrote:
>> On Thursday, March 06, 2014 11:04:14 AM Kieran Clancy wrote:
>>> Rafael, is it a separate process to get this in the stable tree or
>>> will it naturally happen after being merged into the mainline?
>> I need to add a proper "CC stable" tag to your patch for this to happen.
>>
>> Which -stable kernels should it go to?
> 3.2 and 3.10 seem like natural choices (3.4?), but I don't know the
> norm for this kind of fix. Would there be any reason not to include it
> in some particular stable kernels?
>
> Cheers,
> Kieran.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

Beware, the context line:
 static struct dmi_system_id ec_dmi_table[] __initdata = {
has changed in recent kernels, so that line of the patch would need
to be different for it to apply older kernels.
It used to be this:
 static struct dmi_system_id __initdata ec_dmi_table[] = {
until 3.11 I guess.

It is just a context line and is not important for the patch itself.

See:
http://lxr.free-electrons.com/source/drivers/acpi/ec.c?v=3.11
http://lxr.free-electrons.com/source/drivers/acpi/ec.c?v=3.12

Cheers!
--Juan Manuel Cabo


On 03/05/2014 10:24 PM, Kieran Clancy wrote:
 On Thu, Mar 6, 2014 at 11:22 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Thursday, March 06, 2014 11:04:14 AM Kieran Clancy wrote:
 Rafael, is it a separate process to get this in the stable tree or
 will it naturally happen after being merged into the mainline?
 I need to add a proper CC stable tag to your patch for this to happen.

 Which -stable kernels should it go to?
 3.2 and 3.10 seem like natural choices (3.4?), but I don't know the
 norm for this kind of fix. Would there be any reason not to include it
 in some particular stable kernels?

 Cheers,
 Kieran.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hello Kieran

[Juan Manuel Cabo]

Hello Kieran!!

Dennis has an AMD laptop, NP535U3C-A04DE, and found it to be 9
(which I guess was an off by one in his modification
of the userspace workaround and was really 8):
https://bugzilla.kernel.org/show_bug.cgi?id=44161#c146

I found it to be 8 for me, both in the patch and in my new userspace workaround
(which doesn't ask for the same event twice now that it pauses for 1ms,
as the kernel does too):
  https://bugzilla.kernel.org/show_bug.cgi?id=44161#c162

ANd I think I saw someone else with 8 too but don't remember where.

BUT, there might be more laptops existing or future, samsung or other,
that might queue more than 8. Li Guang (lig.f...@cn.fujitsu.com)
said that he saw EC firmware's with 32, and that true maximum is 255.


So in my opinion it's best to put max. iters. at 255.

Cheers!
--jm

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hello Kieran

[Juan Manuel Cabo]

Hello Kieran!!

Dennis has an AMD laptop, NP535U3C-A04DE, and found it to be 9
(which I guess was an off by one in his modification
of the userspace workaround and was really 8):
https://bugzilla.kernel.org/show_bug.cgi?id=44161#c146

I found it to be 8 for me, both in the patch and in my new userspace workaround
(which doesn't ask for the same event twice now that it pauses for 1ms,
as the kernel does too):
  https://bugzilla.kernel.org/show_bug.cgi?id=44161#c162

ANd I think I saw someone else with 8 too but don't remember where.

BUT, there might be more laptops existing or future, samsung or other,
that might queue more than 8. Li Guang (lig.f...@cn.fujitsu.com)
said that he saw EC firmware's with 32, and that true maximum is 255.


So in my opinion it's best to put max. iters. at 255.

Cheers!
--jm

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

On 02/27/2014 12:14 AM, Li Guang wrote:
> oh, sorry, I'm referring internal EC firmware code
> for Q event queuing, not ACPI SPEC, ;-)
> for machine you tested, 8 is the queue size,
> but for some unknown also nasty EC firmwares(let's suppose it exists),
> it may queue more Q events.
> and I saw several firmwares queued 32 events by default,
> then, let's say, they be used for some samsung products,
> and also they also forgot to deal with sleep/resume state,
> then, we'll also leave stale Q event there.
>
> Thanks!
>

We tested each on our different samsung models (intel, amd), and it
was 8 across. But you're right, there might be more in the future.

 I even saw a bug report in ubuntu's launchpad of an HP with a similar
sounding problem, ( 
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860 )
which I have no idea if it was caused by the same issue, but if in the future,
the flag ec_clear_on_resume is used to match other DMI's, it might
be a good idea to make the max iteration count bigger.

  The only reason that there is a max iteration count, was to prevent
an unexpected case in which an unknown EC never returns 0 after
queue emptied. So far it hasn't been the case. Can we count on it?.
The loop currently does finish early when there are no more events.

I guess changing it 255 or 1000 would be enough, right?

Cheers!
-- 
Juan Manuel Cabo



>>  For us, a query is just: send 0x84 through EC CMD port, and read status
>> from CMD port and event type from EC DATA port. This is done with
>> the usual ec.c functions that would handle a query after a GPE interrupt,
>> but using them instead to poll (not GPE initiated) at awake. The EC would
>> then return status without 0x20 mask and 'event type'==0 when no more left.
>>
>> -- 
>> Juan Manuel Cabo
>>
>>
>>
>>   
>>>>enum {
>>>>EC_FLAGS_QUERY_PENDING,/* Query is pending */
>>>> @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
>>>>static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
>>>>static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be 
>>>> validated */
>>>>static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
>>>> scan */
>>>> +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on 
>>>> boot/resume */
>>>>
>>>>
>>> seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
>>> seems too long :-)
>>>
>>> 
>>>>/* 
>>>> --
>>>> Transaction Management
>>>> @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)
>>>>
>>>>EXPORT_SYMBOL(ec_get_handle);
>>>>
>>>> +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
>>>> +
>>>> +/* run with locked ec mutex */
>>>> +static void acpi_ec_clear(struct acpi_ec *ec)
>>>> +{
>>>> +int i, status;
>>>> +u8 value = 0;
>>>> +
>>>> +for (i = 0; i<   ACPI_EC_CLEAR_MAX; i++) {
>>>> +status = acpi_ec_query_unlocked(ec,);
>>>> +if (status || !value)
>>>> +break;
>>>> +}
>>>> +
>>>> +if (i == ACPI_EC_CLEAR_MAX)
>>>> +pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
>>>> +else
>>>> +pr_info("%d stale EC events cleared\n", i);
>>>> +}
>>>> +
>>>>void acpi_ec_block_transactions(void)
>>>>{
>>>>struct acpi_ec *ec = first_ec;
>>>> @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
>>>>mutex_lock(>mutex);
>>>>/* Allow transactions to be carried out again */
>>>>clear_bit(EC_FLAGS_BLOCKED,>flags);
>>>> +
>>>> +if (EC_FLAGS_CLEAR_ON_RESUME)
>>>> +acpi_ec_clear(ec);
>>>> +
>>>>mutex_unlock(>mutex);
>>>>}
>>>>
>>>> @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)
>>>>
>>>>/* EC is fully operational, allow queries */
>>>>clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
>>>> +
>>>> +/* Some hardware may need the EC to be cleared before use */
>>>>
>>>>
>>> description is implicit, should s

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

 
> that's really nasty EC firmware!

Yes!
And this bug has been unsolved for about two years.

> 20 is enough?
> the query index is length of a byte.
>
According to our humble tests, 8 is the maximum number of
accumulated events. For instance, if the one plugs or unplugs the PSU
16 times, (or battery % changes 16 times) during S3 sleep, then the
EC returns no more than 8 events when polled by this patch or by
my userspace util.
And having reached 8 events, it won't produce its GPE until queried.

> the query index is length of a byte.

There is no query index, unless you refer to something else (I'm sorry if its
something that escapes me).
For us, a query is just: send 0x84 through EC CMD port, and read status
from CMD port and event type from EC DATA port. This is done with
the usual ec.c functions that would handle a query after a GPE interrupt,
but using them instead to poll (not GPE initiated) at awake. The EC would
then return status without 0x20 mask and 'event type'==0 when no more left.

--
Juan Manuel Cabo 



>>
>>   enum {
>>   EC_FLAGS_QUERY_PENDING,/* Query is pending */
>> @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
>>   static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
>>   static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
>>   static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
>> scan */
>> +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on boot/resume 
>> */
>>
>
> seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
> seems too long :-)
>
>>
>>   /* 
>> --
>>Transaction Management
>> @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)
>>
>>   EXPORT_SYMBOL(ec_get_handle);
>>
>> +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
>> +
>> +/* run with locked ec mutex */
>> +static void acpi_ec_clear(struct acpi_ec *ec)
>> +{
>> +int i, status;
>> +u8 value = 0;
>> +
>> +for (i = 0; i<  ACPI_EC_CLEAR_MAX; i++) {
>> +status = acpi_ec_query_unlocked(ec,);
>> +if (status || !value)
>> +break;
>> +}
>> +
>> +if (i == ACPI_EC_CLEAR_MAX)
>> +pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
>> +else
>> +pr_info("%d stale EC events cleared\n", i);
>> +}
>> +
>>   void acpi_ec_block_transactions(void)
>>   {
>>   struct acpi_ec *ec = first_ec;
>> @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
>>   mutex_lock(>mutex);
>>   /* Allow transactions to be carried out again */
>>   clear_bit(EC_FLAGS_BLOCKED,>flags);
>> +
>> +if (EC_FLAGS_CLEAR_ON_RESUME)
>> +acpi_ec_clear(ec);
>> +
>>   mutex_unlock(>mutex);
>>   }
>>
>> @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)
>>
>>   /* EC is fully operational, allow queries */
>>   clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
>> +
>> +/* Some hardware may need the EC to be cleared before use */
>>
>
> description is implicit, should specify what we clear is Q event, not EC.
>
> Thanks!
> Li Guang
>
>> +if (EC_FLAGS_CLEAR_ON_RESUME) {
>> +mutex_lock(>mutex);
>> +acpi_ec_clear(ec);
>> +mutex_unlock(>mutex);
>> +}
>>   return ret;
>>   }
>>
>> @@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
>> dmi_system_id *id)
>>   return 0;
>>   }
>>
>> +/*
>> + * On some hardware it is necessary to clear events accumulated by the EC 
>> during
>> + * sleep. These ECs stop reporting GPEs until they are manually polled, if 
>> too
>> + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
>> + *
>> + * https://bugzilla.kernel.org/show_bug.cgi?id=44161
>> + *
>> + * Ideally, the EC should also be instructed not to accumulate events during
>> + * sleep (which Windows seems to do somehow), but the interface to control 
>> this
>> + * behaviour is not known at this time.
>> + *
>> + * Models known to be affected are Samsung 
>> 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
>> + * however it is very likely that other Samsung models are affected.
>> + *
>> + * On systems which don't accumulate EC events during sleep, this extra 
>> check
>> + * should be harmless.
>> + */
>> +static i

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

 
 that's really nasty EC firmware!

Yes!
And this bug has been unsolved for about two years.

 20 is enough?
 the query index is length of a byte.

According to our humble tests, 8 is the maximum number of
accumulated events. For instance, if the one plugs or unplugs the PSU
16 times, (or battery % changes 16 times) during S3 sleep, then the
EC returns no more than 8 events when polled by this patch or by
my userspace util.
And having reached 8 events, it won't produce its GPE until queried.

 the query index is length of a byte.

There is no query index, unless you refer to something else (I'm sorry if its
something that escapes me).
For us, a query is just: send 0x84 through EC CMD port, and read status
from CMD port and event type from EC DATA port. This is done with
the usual ec.c functions that would handle a query after a GPE interrupt,
but using them instead to poll (not GPE initiated) at awake. The EC would
then return status without 0x20 mask and 'event type'==0 when no more left.

--
Juan Manuel Cabo juanmanuel.c...@gmail.com




   enum {
   EC_FLAGS_QUERY_PENDING,/* Query is pending */
 @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
   static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
   static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
   static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
 scan */
 +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on boot/resume 
 */


 seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
 seems too long :-)


   /* 
 --
Transaction Management
 @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)

   EXPORT_SYMBOL(ec_get_handle);

 +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
 +
 +/* run with locked ec mutex */
 +static void acpi_ec_clear(struct acpi_ec *ec)
 +{
 +int i, status;
 +u8 value = 0;
 +
 +for (i = 0; i  ACPI_EC_CLEAR_MAX; i++) {
 +status = acpi_ec_query_unlocked(ec,value);
 +if (status || !value)
 +break;
 +}
 +
 +if (i == ACPI_EC_CLEAR_MAX)
 +pr_warn(Warning: Maximum of %d stale EC events cleared\n, i);
 +else
 +pr_info(%d stale EC events cleared\n, i);
 +}
 +
   void acpi_ec_block_transactions(void)
   {
   struct acpi_ec *ec = first_ec;
 @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
   mutex_lock(ec-mutex);
   /* Allow transactions to be carried out again */
   clear_bit(EC_FLAGS_BLOCKED,ec-flags);
 +
 +if (EC_FLAGS_CLEAR_ON_RESUME)
 +acpi_ec_clear(ec);
 +
   mutex_unlock(ec-mutex);
   }

 @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)

   /* EC is fully operational, allow queries */
   clear_bit(EC_FLAGS_QUERY_PENDING,ec-flags);
 +
 +/* Some hardware may need the EC to be cleared before use */


 description is implicit, should specify what we clear is Q event, not EC.

 Thanks!
 Li Guang

 +if (EC_FLAGS_CLEAR_ON_RESUME) {
 +mutex_lock(ec-mutex);
 +acpi_ec_clear(ec);
 +mutex_unlock(ec-mutex);
 +}
   return ret;
   }

 @@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
 dmi_system_id *id)
   return 0;
   }

 +/*
 + * On some hardware it is necessary to clear events accumulated by the EC 
 during
 + * sleep. These ECs stop reporting GPEs until they are manually polled, if 
 too
 + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
 + *
 + * https://bugzilla.kernel.org/show_bug.cgi?id=44161
 + *
 + * Ideally, the EC should also be instructed not to accumulate events during
 + * sleep (which Windows seems to do somehow), but the interface to control 
 this
 + * behaviour is not known at this time.
 + *
 + * Models known to be affected are Samsung 
 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
 + * however it is very likely that other Samsung models are affected.
 + *
 + * On systems which don't accumulate EC events during sleep, this extra 
 check
 + * should be harmless.
 + */
 +static int ec_clear_on_resume(const struct dmi_system_id *id)
 +{
 +pr_debug(Detected system needing EC poll on resume.\n);
 +EC_FLAGS_CLEAR_ON_RESUME = 1;
 +return 0;
 +}
 +
   static struct dmi_system_id ec_dmi_table[] __initdata = {
   {
   ec_skip_dsdt_scan, Compal JFL92, {
 @@ -965,6 +1023,9 @@ static struct dmi_system_id ec_dmi_table[] __initdata = 
 {
   ec_validate_ecdt, ASUS hardware, {
   DMI_MATCH(DMI_SYS_VENDOR, ASUSTek Computer Inc.),
   DMI_MATCH(DMI_PRODUCT_NAME, L4R),}, NULL},
 +{
 +ec_clear_on_resume, Samsung hardware, {
 +DMI_MATCH(DMI_SYS_VENDOR, SAMSUNG ELECTRONICS CO., LTD.)}, NULL},
   {},
   };





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

On 02/27/2014 12:14 AM, Li Guang wrote:
 oh, sorry, I'm referring internal EC firmware code
 for Q event queuing, not ACPI SPEC, ;-)
 for machine you tested, 8 is the queue size,
 but for some unknown also nasty EC firmwares(let's suppose it exists),
 it may queue more Q events.
 and I saw several firmwares queued 32 events by default,
 then, let's say, they be used for some samsung products,
 and also they also forgot to deal with sleep/resume state,
 then, we'll also leave stale Q event there.

 Thanks!


We tested each on our different samsung models (intel, amd), and it
was 8 across. But you're right, there might be more in the future.

 I even saw a bug report in ubuntu's launchpad of an HP with a similar
sounding problem, ( 
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860 )
which I have no idea if it was caused by the same issue, but if in the future,
the flag ec_clear_on_resume is used to match other DMI's, it might
be a good idea to make the max iteration count bigger.

  The only reason that there is a max iteration count, was to prevent
an unexpected case in which an unknown EC never returns 0 after
queue emptied. So far it hasn't been the case. Can we count on it?.
The loop currently does finish early when there are no more events.

I guess changing it 255 or 1000 would be enough, right?

Cheers!
-- 
Juan Manuel Cabojuanmanuel.c...@gmail.com



  For us, a query is just: send 0x84 through EC CMD port, and read status
 from CMD port and event type from EC DATA port. This is done with
 the usual ec.c functions that would handle a query after a GPE interrupt,
 but using them instead to poll (not GPE initiated) at awake. The EC would
 then return status without 0x20 mask and 'event type'==0 when no more left.

 -- 
 Juan Manuel Cabojuanmanuel.c...@gmail.com



   
enum {
EC_FLAGS_QUERY_PENDING,/* Query is pending */
 @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be 
 validated */
static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
 scan */
 +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on 
 boot/resume */


 seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
 seems too long :-)

 
/* 
 --
 Transaction Management
 @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)

EXPORT_SYMBOL(ec_get_handle);

 +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
 +
 +/* run with locked ec mutex */
 +static void acpi_ec_clear(struct acpi_ec *ec)
 +{
 +int i, status;
 +u8 value = 0;
 +
 +for (i = 0; i   ACPI_EC_CLEAR_MAX; i++) {
 +status = acpi_ec_query_unlocked(ec,value);
 +if (status || !value)
 +break;
 +}
 +
 +if (i == ACPI_EC_CLEAR_MAX)
 +pr_warn(Warning: Maximum of %d stale EC events cleared\n, i);
 +else
 +pr_info(%d stale EC events cleared\n, i);
 +}
 +
void acpi_ec_block_transactions(void)
{
struct acpi_ec *ec = first_ec;
 @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
mutex_lock(ec-mutex);
/* Allow transactions to be carried out again */
clear_bit(EC_FLAGS_BLOCKED,ec-flags);
 +
 +if (EC_FLAGS_CLEAR_ON_RESUME)
 +acpi_ec_clear(ec);
 +
mutex_unlock(ec-mutex);
}

 @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)

/* EC is fully operational, allow queries */
clear_bit(EC_FLAGS_QUERY_PENDING,ec-flags);
 +
 +/* Some hardware may need the EC to be cleared before use */


 description is implicit, should specify what we clear is Q event, not EC.

 Thanks!
 Li Guang

 
 +if (EC_FLAGS_CLEAR_ON_RESUME) {
 +mutex_lock(ec-mutex);
 +acpi_ec_clear(ec);
 +mutex_unlock(ec-mutex);
 +}
return ret;
}

 @@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
 dmi_system_id *id)
return 0;
}

 +/*
 + * On some hardware it is necessary to clear events accumulated by the EC 
 during
 + * sleep. These ECs stop reporting GPEs until they are manually polled, 
 if too
 + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
 + *
 + * https://bugzilla.kernel.org/show_bug.cgi?id=44161
 + *
 + * Ideally, the EC should also be instructed not to accumulate events 
 during
 + * sleep (which Windows seems to do somehow), but the interface to 
 control this
 + * behaviour is not known at this time.
 + *
 + * Models known to be affected are Samsung 
 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
 + * however it is very likely that other Samsung models are affected.
 + *
 + * On systems which don't accumulate EC events during sleep, this extra 
 check
 + * should be harmless.
 + */
 +static int

RE: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8] FMC: add core bus driver

[Juan David Gonzalez Cobas]

On Tue, Jun 18, 2013 at 1:38 AM, Alessandro Rubini  wrote:
>>> + * Released according to the GNU GPL, version 2 or any later version.
[...]
> I think we want to allow for proprietary FMC drivers. I personally
> don't feel this is a core kernel technology.  But I'll let David Cobas
> expand on CERN policies, as I'm only a consultant.

After some discussion, we think Alessandro's arguments about keeping
EXPORT_SYMBOL are sound. As mentioned, CERN policies are
non-restrictive in this sense, hence we consider correct to leave
EXPORT_SYMBOLs as they are currently. The BSD licencing for
the other, "public domain" examples is also OK.

Hope this helps,

david
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8] FMC: add core bus driver

[Juan David Gonzalez Cobas]

On Tue, Jun 18, 2013 at 1:38 AM, Alessandro Rubini rub...@gnudd.com wrote:
 + * Released according to the GNU GPL, version 2 or any later version.
[...]
 I think we want to allow for proprietary FMC drivers. I personally
 don't feel this is a core kernel technology.  But I'll let David Cobas
 expand on CERN policies, as I'm only a consultant.

After some discussion, we think Alessandro's arguments about keeping
EXPORT_SYMBOL are sound. As mentioned, CERN policies are
non-restrictive in this sense, hence we consider correct to leave
EXPORT_SYMBOLs as they are currently. The BSD licencing for
the other, public domain examples is also OK.

Hope this helps,

david
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] n_gsm: prevent crash due to dereferencing NULL gsm->tty

[Guillaume Juan]

Le 29/10/2012 17:29, Alan Cox a écrit :

> 
> More important is fixing the bug completely. I agree there is a bug I
> don't think your fix is sufficient however.
>

It may not fix all cases but I think it improves things both from a
practical and theoretical point of view.
In particular the part in gsmtty_hangup: the crash was systematic if the
user space released the virtual ttys fds only after the N_GSM line
discipline was removed (with ioctl).
I explained all the crashes I had, and did not reproduced crashes after
my patch. Note that I don't have use-cases where the DCE itself opens
some DLCIs, which certainly can cause a lot more trouble.


> 
> You no longer set dlci->dead before doing the dlci release

Yes I do, see line 2036:
+   if (dlci)
+   dlci->dead = 1;
I do it only for DLCI#0 but this is the same as what the previous code
was doing (I don't understand why but I thought that was another topic).
I was not sure that this dlci->dead was really efficient, but I decided
to keep it because addressing the relevance of dlci->dead was not the
purpose of my patch.

> Also moving the gsm_dlci_release seems to have no value at all because
> there is no locking in the code concerned so viewed from any other thread
> you've changed nothing but timings. Yes its probably way harder to hit.
> 

I don't really see your point, or I think you may be speaking of a
different matter. Once gsm_dlci_release has done its job, the T2 timer
should no longer be rearmed by anything the user-space could do, because
the tty will be hung up (tty_vhangup is synchronous isn't it ?). At
least tty_port_close_start would not call tty_port_lower_dtr_rts
anymore. So then the comment /* Now we are sure T2 has stopped */ after
del_timer_sync will be true.
Do you see any other paths that may lead to relaunch the T2 timer
afterwards? Don't you agree that gsmtty_release should be done before
del_timer_sync?

> I can see two ways of tackling it both of which basically come down to
> the same thing. In gsmld_detach_gsm after the gsm_cleanup_mux we need to
> 
> - be sure the thing cannot re-open

If you talk about reopening from the other side, I agree with you that
dlci->dead does not seem to protect enough. However I can read in the
description of gsmld_close that "the function will not be called while
other ldisc methods are in progress". If this is true, the concurrence
of gsmld_receive_buf should not be possible ?

> - wait until all the DLCIs are dead

I am not sure what you mean by this:
- gsm_cleanup_mux already waits for the answer to CLD command and to the
closure of DLCI#0. As I reported previously, it will never see the
answers coming because of the line-discipline life-cycle design, but
this is yet another topic.
- or maybe you mean wait until we are sure there are no longer
references to the virtual ttys. This seems to me impossible to achieve
because the user-space closes them at its own pace.

> then do the tty_kref_put and gsm->tty = NULL
> 
> Thoughts ?
> 
> Alan


Guillaume

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."


   **

" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] n_gsm: prevent crash due to dereferencing NULL gsm-tty

[Guillaume Juan]

Le 29/10/2012 17:29, Alan Cox a écrit :

 
 More important is fixing the bug completely. I agree there is a bug I
 don't think your fix is sufficient however.


It may not fix all cases but I think it improves things both from a
practical and theoretical point of view.
In particular the part in gsmtty_hangup: the crash was systematic if the
user space released the virtual ttys fds only after the N_GSM line
discipline was removed (with ioctl).
I explained all the crashes I had, and did not reproduced crashes after
my patch. Note that I don't have use-cases where the DCE itself opens
some DLCIs, which certainly can cause a lot more trouble.


 
 You no longer set dlci-dead before doing the dlci release

Yes I do, see line 2036:
+   if (dlci)
+   dlci-dead = 1;
I do it only for DLCI#0 but this is the same as what the previous code
was doing (I don't understand why but I thought that was another topic).
I was not sure that this dlci-dead was really efficient, but I decided
to keep it because addressing the relevance of dlci-dead was not the
purpose of my patch.

 Also moving the gsm_dlci_release seems to have no value at all because
 there is no locking in the code concerned so viewed from any other thread
 you've changed nothing but timings. Yes its probably way harder to hit.
 

I don't really see your point, or I think you may be speaking of a
different matter. Once gsm_dlci_release has done its job, the T2 timer
should no longer be rearmed by anything the user-space could do, because
the tty will be hung up (tty_vhangup is synchronous isn't it ?). At
least tty_port_close_start would not call tty_port_lower_dtr_rts
anymore. So then the comment /* Now we are sure T2 has stopped */ after
del_timer_sync will be true.
Do you see any other paths that may lead to relaunch the T2 timer
afterwards? Don't you agree that gsmtty_release should be done before
del_timer_sync?

 I can see two ways of tackling it both of which basically come down to
 the same thing. In gsmld_detach_gsm after the gsm_cleanup_mux we need to
 
 - be sure the thing cannot re-open

If you talk about reopening from the other side, I agree with you that
dlci-dead does not seem to protect enough. However I can read in the
description of gsmld_close that the function will not be called while
other ldisc methods are in progress. If this is true, the concurrence
of gsmld_receive_buf should not be possible ?

 - wait until all the DLCIs are dead

I am not sure what you mean by this:
- gsm_cleanup_mux already waits for the answer to CLD command and to the
closure of DLCI#0. As I reported previously, it will never see the
answers coming because of the line-discipline life-cycle design, but
this is yet another topic.
- or maybe you mean wait until we are sure there are no longer
references to the virtual ttys. This seems to me impossible to achieve
because the user-space closes them at its own pace.

 then do the tty_kref_put and gsm-tty = NULL
 
 Thoughts ?
 
 Alan


Guillaume

#
 Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés.


   **

 This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system.
#

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] n_gsm: prevent crash due to dereferencing NULL gsm->tty

[Guillaume Juan]

Le 26/10/2012 17:20, Greg Kroah-Hartman a écrit :

> On Fri, Oct 26, 2012 at 10:11:45AM +0200, Guillaume Juan wrote:
>> From: Guillaume Juan 
>>
>> If gsm->tty happens to be NULL in gsmld_output, avoid crashing the kernel 
>> (the crash is replaced by a warning dump).
> 
> How can ->tty be NULL here?
> 

I had some crashes and identified 2 causes: this is what I tried to explain in 
the 2nd part of the changelog ("Prevent at earlier level such situation: 
[...]"). Basically it is because the T1 and T2 timers may be rearmed while 
gsm_cleanup_mux executes (T1 is rearmed by gsmtty_hangup called by 
gsm_cleanup_mux itself via gsm_dlci_release, whereas T2 may be rearmed by a 
concurrent call to gsmtty_close).

My patch is intended to remove theses causes, but I thought safer to avoid the 
crash in gsmld_output if ever there are other causes remaining. Do you mean I 
should let the crash happen for these unproven cases?

>> Prevent at earlier level such situation:
>> - gsmtty_hangup does no longer call gsm_dlci_begin_close when called 
>> synchronously from gsm_cleanup_mux, because this would arm a timer that will 
>> asynchronously lead to use gms->tty, potentially after it is nullified.
>> - in gsm_cleanup_mux, release DLCIs (other than DLCI#0 which is the control 
>> one) before closing mux. Else, it can happen that the T2 timer is rearmed by 
>> another thread scheduled between del_timer_sync and gsm_dlci release
>> (for example by the following call-stack: fput => tty_release => 
>> tty_port_close_start => tty_port_lower_dtr_rts => gsm_dtr_rts => 
>> gsmtty_modem_update)
> 
> Please wrap your changelog comments at 72 columns.
>

Sorry, I didn't know this rule (it is the 1st time I post a patch and the 1st 
time I use git). I will when I re-send.


>>
>> Signed-off-by: Guillaume Juan 
>> ---
>>  drivers/tty/n_gsm.c |   35 ++-
>>  1 files changed, 26 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
>> index 1e8e8ce..fe3c6ad 100644
>> --- a/drivers/tty/n_gsm.c
>> +++ b/drivers/tty/n_gsm.c
>> @@ -1510,8 +1510,8 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
>>  }
>>  
>>  /**
>> - *  gsm_dlci_begin_close-   start channel open procedure
>> - *  @dlci: DLCI to open
>> + *  gsm_dlci_begin_close-   start channel close procedure
>> + *  @dlci: DLCI to close
>>   *
>>   *  Commence closing a DLCI from the Linux side. We issue DISC messages
>>   *  to the modem which should then reply with a UA, at which point we
>> @@ -2031,6 +2031,13 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
>>  spin_unlock(_mux_lock);
>>  WARN_ON(i == MAX_MUX);
>>  
>> +/* Free up any link layer users */
>> +if (dlci)
>> +dlci->dead = 1;
>> +for (i = 1; i < NUM_DLCI; i++)
>> +if (gsm->dlci[i])
>> +gsm_dlci_release(gsm->dlci[i]);
>> +
>>  /* In theory disconnecting DLCI 0 is sufficient but for some
>> modems this is apparently not the case. */
>>  if (dlci) {
>> @@ -2041,15 +2048,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
>>  del_timer_sync(>t2_timer);
>>  /* Now we are sure T2 has stopped */
>>  if (dlci) {
>> -dlci->dead = 1;
>>  gsm_dlci_begin_close(dlci);
>>  wait_event_interruptible(gsm->event,
>>  dlci->state == DLCI_CLOSED);
>> +gsm_dlci_release(dlci);
>>  }
>> -/* Free up any link layer users */
>> -for (i = 0; i < NUM_DLCI; i++)
>> -if (gsm->dlci[i])
>> -gsm_dlci_release(gsm->dlci[i]);
>>  /* Now wipe the queues */
>>  list_for_each_entry_safe(txq, ntxq, >tx_list, list)
>>  kfree(txq);
>> @@ -2192,6 +2195,10 @@ EXPORT_SYMBOL_GPL(gsm_alloc_mux);
>>  
>>  static int gsmld_output(struct gsm_mux *gsm, u8 *data, int len)
>>  {
>> +if (gsm->tty == NULL) {
>> +WARN(1, "NULL gsm->tty pointer in gsmld_output\n");
>> +return -EINVAL;
>> +}
>>  if (tty_write_room(gsm->tty) < len) {
>>  set_bit(TTY_DO_WRITE_WAKEUP, >tty->flags);
>>  return -ENOSPC;
>> @@ -2323,7 +2330,7 @@ static void gsmld_flush_buffer(struct tty_struct *tty)
>>   *  @tty: device
>>   *
>>   *  Called from the terminal layer when this line discipline is
>> - *  being shut down

[PATCH] n_gsm: prevent crash due to dereferencing NULL gsm->tty

[Guillaume Juan]

From: Guillaume Juan 

If gsm->tty happens to be NULL in gsmld_output, avoid crashing the kernel (the 
crash is replaced by a warning dump).
Prevent at earlier level such situation:
- gsmtty_hangup does no longer call gsm_dlci_begin_close when called 
synchronously from gsm_cleanup_mux, because this would arm a timer that will 
asynchronously lead to use gms->tty, potentially after it is nullified.
- in gsm_cleanup_mux, release DLCIs (other than DLCI#0 which is the control 
one) before closing mux. Else, it can happen that the T2 timer is rearmed by 
another thread scheduled between del_timer_sync and gsm_dlci release
(for example by the following call-stack: fput => tty_release => 
tty_port_close_start => tty_port_lower_dtr_rts => gsm_dtr_rts => 
gsmtty_modem_update)

Signed-off-by: Guillaume Juan 
---
 drivers/tty/n_gsm.c |   35 ++-
 1 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 1e8e8ce..fe3c6ad 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1510,8 +1510,8 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
 }
 
 /**
- * gsm_dlci_begin_close-   start channel open procedure
- * @dlci: DLCI to open
+ * gsm_dlci_begin_close-   start channel close procedure
+ * @dlci: DLCI to close
  *
  * Commence closing a DLCI from the Linux side. We issue DISC messages
  * to the modem which should then reply with a UA, at which point we
@@ -2031,6 +2031,13 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
spin_unlock(_mux_lock);
WARN_ON(i == MAX_MUX);
 
+   /* Free up any link layer users */
+   if (dlci)
+   dlci->dead = 1;
+   for (i = 1; i < NUM_DLCI; i++)
+   if (gsm->dlci[i])
+   gsm_dlci_release(gsm->dlci[i]);
+
/* In theory disconnecting DLCI 0 is sufficient but for some
   modems this is apparently not the case. */
if (dlci) {
@@ -2041,15 +2048,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
del_timer_sync(>t2_timer);
/* Now we are sure T2 has stopped */
if (dlci) {
-   dlci->dead = 1;
gsm_dlci_begin_close(dlci);
wait_event_interruptible(gsm->event,
dlci->state == DLCI_CLOSED);
+   gsm_dlci_release(dlci);
}
-   /* Free up any link layer users */
-   for (i = 0; i < NUM_DLCI; i++)
-   if (gsm->dlci[i])
-   gsm_dlci_release(gsm->dlci[i]);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, >tx_list, list)
kfree(txq);
@@ -2192,6 +2195,10 @@ EXPORT_SYMBOL_GPL(gsm_alloc_mux);
 
 static int gsmld_output(struct gsm_mux *gsm, u8 *data, int len)
 {
+   if (gsm->tty == NULL) {
+   WARN(1, "NULL gsm->tty pointer in gsmld_output\n");
+   return -EINVAL;
+   }
if (tty_write_room(gsm->tty) < len) {
set_bit(TTY_DO_WRITE_WAKEUP, >tty->flags);
return -ENOSPC;
@@ -2323,7 +2330,7 @@ static void gsmld_flush_buffer(struct tty_struct *tty)
  * @tty: device
  *
  * Called from the terminal layer when this line discipline is
- * being shut down, either because of a close or becsuse of a
+ * being shut down, either because of a close or because of a
  * discipline change. The function will not be called while other
  * ldisc methods are in progress.
  */
@@ -2954,6 +2961,15 @@ static void gsmtty_close(struct tty_struct *tty, struct 
file *filp)
gsm = dlci->gsm;
if (tty_port_close_start(>port, tty, filp) == 0)
goto out;
+   /* Should not happen because the DLCI ttys are hung up (which causes
+  tty_port_close_start to return 0) by gsm_dlci_release before setting
+  gsm->tty to NULL */
+   if (gsm->tty == NULL) {
+   WARN(1, "NULL gsm->tty pointer in gsmtty_close for %s\n",
+   tty->name);
+   goto out;
+   }
+
gsm_dlci_begin_close(dlci);
tty_port_close_end(>port, tty);
tty_port_tty_set(>port, NULL);
@@ -2967,7 +2983,8 @@ static void gsmtty_hangup(struct tty_struct *tty)
 {
struct gsm_dlci *dlci = tty->driver_data;
tty_port_hangup(>port);
-   gsm_dlci_begin_close(dlci);
+   if (!dlci->gsm->dead)
+   gsm_dlci_begin_close(dlci);
 }
 
 static int gsmtty_write(struct tty_struct *tty, const unsigned char *buf,
-- 
1.7.0.4



#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser d

[PATCH] n_gsm: prevent crash due to dereferencing NULL gsm-tty

[Guillaume Juan]

From: Guillaume Juan guillaume.j...@sagemcom.com

If gsm-tty happens to be NULL in gsmld_output, avoid crashing the kernel (the 
crash is replaced by a warning dump).
Prevent at earlier level such situation:
- gsmtty_hangup does no longer call gsm_dlci_begin_close when called 
synchronously from gsm_cleanup_mux, because this would arm a timer that will 
asynchronously lead to use gms-tty, potentially after it is nullified.
- in gsm_cleanup_mux, release DLCIs (other than DLCI#0 which is the control 
one) before closing mux. Else, it can happen that the T2 timer is rearmed by 
another thread scheduled between del_timer_sync and gsm_dlci release
(for example by the following call-stack: fput = tty_release = 
tty_port_close_start = tty_port_lower_dtr_rts = gsm_dtr_rts = 
gsmtty_modem_update)

Signed-off-by: Guillaume Juan guillaume.j...@sagemcom.com
---
 drivers/tty/n_gsm.c |   35 ++-
 1 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 1e8e8ce..fe3c6ad 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1510,8 +1510,8 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
 }
 
 /**
- * gsm_dlci_begin_close-   start channel open procedure
- * @dlci: DLCI to open
+ * gsm_dlci_begin_close-   start channel close procedure
+ * @dlci: DLCI to close
  *
  * Commence closing a DLCI from the Linux side. We issue DISC messages
  * to the modem which should then reply with a UA, at which point we
@@ -2031,6 +2031,13 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
spin_unlock(gsm_mux_lock);
WARN_ON(i == MAX_MUX);
 
+   /* Free up any link layer users */
+   if (dlci)
+   dlci-dead = 1;
+   for (i = 1; i  NUM_DLCI; i++)
+   if (gsm-dlci[i])
+   gsm_dlci_release(gsm-dlci[i]);
+
/* In theory disconnecting DLCI 0 is sufficient but for some
   modems this is apparently not the case. */
if (dlci) {
@@ -2041,15 +2048,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
del_timer_sync(gsm-t2_timer);
/* Now we are sure T2 has stopped */
if (dlci) {
-   dlci-dead = 1;
gsm_dlci_begin_close(dlci);
wait_event_interruptible(gsm-event,
dlci-state == DLCI_CLOSED);
+   gsm_dlci_release(dlci);
}
-   /* Free up any link layer users */
-   for (i = 0; i  NUM_DLCI; i++)
-   if (gsm-dlci[i])
-   gsm_dlci_release(gsm-dlci[i]);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, gsm-tx_list, list)
kfree(txq);
@@ -2192,6 +2195,10 @@ EXPORT_SYMBOL_GPL(gsm_alloc_mux);
 
 static int gsmld_output(struct gsm_mux *gsm, u8 *data, int len)
 {
+   if (gsm-tty == NULL) {
+   WARN(1, NULL gsm-tty pointer in gsmld_output\n);
+   return -EINVAL;
+   }
if (tty_write_room(gsm-tty)  len) {
set_bit(TTY_DO_WRITE_WAKEUP, gsm-tty-flags);
return -ENOSPC;
@@ -2323,7 +2330,7 @@ static void gsmld_flush_buffer(struct tty_struct *tty)
  * @tty: device
  *
  * Called from the terminal layer when this line discipline is
- * being shut down, either because of a close or becsuse of a
+ * being shut down, either because of a close or because of a
  * discipline change. The function will not be called while other
  * ldisc methods are in progress.
  */
@@ -2954,6 +2961,15 @@ static void gsmtty_close(struct tty_struct *tty, struct 
file *filp)
gsm = dlci-gsm;
if (tty_port_close_start(dlci-port, tty, filp) == 0)
goto out;
+   /* Should not happen because the DLCI ttys are hung up (which causes
+  tty_port_close_start to return 0) by gsm_dlci_release before setting
+  gsm-tty to NULL */
+   if (gsm-tty == NULL) {
+   WARN(1, NULL gsm-tty pointer in gsmtty_close for %s\n,
+   tty-name);
+   goto out;
+   }
+
gsm_dlci_begin_close(dlci);
tty_port_close_end(dlci-port, tty);
tty_port_tty_set(dlci-port, NULL);
@@ -2967,7 +2983,8 @@ static void gsmtty_hangup(struct tty_struct *tty)
 {
struct gsm_dlci *dlci = tty-driver_data;
tty_port_hangup(dlci-port);
-   gsm_dlci_begin_close(dlci);
+   if (!dlci-gsm-dead)
+   gsm_dlci_begin_close(dlci);
 }
 
 static int gsmtty_write(struct tty_struct *tty, const unsigned char *buf,
-- 
1.7.0.4



#
 Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en

Re: [PATCH] n_gsm: prevent crash due to dereferencing NULL gsm-tty

[Guillaume Juan]

Le 26/10/2012 17:20, Greg Kroah-Hartman a écrit :

 On Fri, Oct 26, 2012 at 10:11:45AM +0200, Guillaume Juan wrote:
 From: Guillaume Juan guillaume.j...@sagemcom.com

 If gsm-tty happens to be NULL in gsmld_output, avoid crashing the kernel 
 (the crash is replaced by a warning dump).
 
 How can -tty be NULL here?
 

I had some crashes and identified 2 causes: this is what I tried to explain in 
the 2nd part of the changelog (Prevent at earlier level such situation: 
[...]). Basically it is because the T1 and T2 timers may be rearmed while 
gsm_cleanup_mux executes (T1 is rearmed by gsmtty_hangup called by 
gsm_cleanup_mux itself via gsm_dlci_release, whereas T2 may be rearmed by a 
concurrent call to gsmtty_close).

My patch is intended to remove theses causes, but I thought safer to avoid the 
crash in gsmld_output if ever there are other causes remaining. Do you mean I 
should let the crash happen for these unproven cases?

 Prevent at earlier level such situation:
 - gsmtty_hangup does no longer call gsm_dlci_begin_close when called 
 synchronously from gsm_cleanup_mux, because this would arm a timer that will 
 asynchronously lead to use gms-tty, potentially after it is nullified.
 - in gsm_cleanup_mux, release DLCIs (other than DLCI#0 which is the control 
 one) before closing mux. Else, it can happen that the T2 timer is rearmed by 
 another thread scheduled between del_timer_sync and gsm_dlci release
 (for example by the following call-stack: fput = tty_release = 
 tty_port_close_start = tty_port_lower_dtr_rts = gsm_dtr_rts = 
 gsmtty_modem_update)
 
 Please wrap your changelog comments at 72 columns.


Sorry, I didn't know this rule (it is the 1st time I post a patch and the 1st 
time I use git). I will when I re-send.



 Signed-off-by: Guillaume Juan guillaume.j...@sagemcom.com
 ---
  drivers/tty/n_gsm.c |   35 ++-
  1 files changed, 26 insertions(+), 9 deletions(-)

 diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
 index 1e8e8ce..fe3c6ad 100644
 --- a/drivers/tty/n_gsm.c
 +++ b/drivers/tty/n_gsm.c
 @@ -1510,8 +1510,8 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
  }
  
  /**
 - *  gsm_dlci_begin_close-   start channel open procedure
 - *  @dlci: DLCI to open
 + *  gsm_dlci_begin_close-   start channel close procedure
 + *  @dlci: DLCI to close
   *
   *  Commence closing a DLCI from the Linux side. We issue DISC messages
   *  to the modem which should then reply with a UA, at which point we
 @@ -2031,6 +2031,13 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
  spin_unlock(gsm_mux_lock);
  WARN_ON(i == MAX_MUX);
  
 +/* Free up any link layer users */
 +if (dlci)
 +dlci-dead = 1;
 +for (i = 1; i  NUM_DLCI; i++)
 +if (gsm-dlci[i])
 +gsm_dlci_release(gsm-dlci[i]);
 +
  /* In theory disconnecting DLCI 0 is sufficient but for some
 modems this is apparently not the case. */
  if (dlci) {
 @@ -2041,15 +2048,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
  del_timer_sync(gsm-t2_timer);
  /* Now we are sure T2 has stopped */
  if (dlci) {
 -dlci-dead = 1;
  gsm_dlci_begin_close(dlci);
  wait_event_interruptible(gsm-event,
  dlci-state == DLCI_CLOSED);
 +gsm_dlci_release(dlci);
  }
 -/* Free up any link layer users */
 -for (i = 0; i  NUM_DLCI; i++)
 -if (gsm-dlci[i])
 -gsm_dlci_release(gsm-dlci[i]);
  /* Now wipe the queues */
  list_for_each_entry_safe(txq, ntxq, gsm-tx_list, list)
  kfree(txq);
 @@ -2192,6 +2195,10 @@ EXPORT_SYMBOL_GPL(gsm_alloc_mux);
  
  static int gsmld_output(struct gsm_mux *gsm, u8 *data, int len)
  {
 +if (gsm-tty == NULL) {
 +WARN(1, NULL gsm-tty pointer in gsmld_output\n);
 +return -EINVAL;
 +}
  if (tty_write_room(gsm-tty)  len) {
  set_bit(TTY_DO_WRITE_WAKEUP, gsm-tty-flags);
  return -ENOSPC;
 @@ -2323,7 +2330,7 @@ static void gsmld_flush_buffer(struct tty_struct *tty)
   *  @tty: device
   *
   *  Called from the terminal layer when this line discipline is
 - *  being shut down, either because of a close or becsuse of a
 + *  being shut down, either because of a close or because of a
   *  discipline change. The function will not be called while other
   *  ldisc methods are in progress.
   */
 @@ -2954,6 +2961,15 @@ static void gsmtty_close(struct tty_struct *tty, 
 struct file *filp)
  gsm = dlci-gsm;
  if (tty_port_close_start(dlci-port, tty, filp) == 0)
  goto out;
 +/* Should not happen because the DLCI ttys are hung up (which causes
 +   tty_port_close_start to return 0) by gsm_dlci_release before setting
 +   gsm-tty to NULL */
 +if (gsm-tty == NULL) {
 +WARN(1, NULL gsm-tty pointer in gsmtty_close for %s\n,
 +tty-name

Re: [2.6 patch] make stk_camera_{suspend,resume}() static

[Jaime Velasco Juan]

El mar. 19 de feb. de 2008, a las 21:29:08 +0200, Adrian Bunk escribió:
> This patch makes the needlessly global stk_camera_{suspend,resume}() 
> static.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
Acked-by: Jaime Velasco Juan <[EMAIL PROTECTED]>

thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make stk_camera_{suspend,resume}() static

[Jaime Velasco Juan]

El mar. 19 de feb. de 2008, a las 21:29:08 +0200, Adrian Bunk escribió:
 This patch makes the needlessly global stk_camera_{suspend,resume}() 
 static.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
Acked-by: Jaime Velasco Juan [EMAIL PROTECTED]

thanks
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make stk_camera_cleanup() static

[Jaime Velasco Juan]

El mar. 29 de ene. de 2008, a las 00:11:01 +0200, Adrian Bunk escribió:
> stk_camera_cleanup() can become static.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
Acked-by: Jaime Velasco Juan <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] stk-sensor.c: make 2 functions static

[Jaime Velasco Juan]

El mar. 29 de ene. de 2008, a las 00:10:58 +0200, Adrian Bunk escribió:
> This patch makes the following needlessly global functions static:
> - stk_sensor_outb()
> - stk_sensor_inb()
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
Acked-by: Jaime Velasco Juan <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make stk_camera_cleanup() static

[Jaime Velasco Juan]

El mar. 29 de ene. de 2008, a las 00:11:01 +0200, Adrian Bunk escribió:
 stk_camera_cleanup() can become static.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
Acked-by: Jaime Velasco Juan [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] stk-sensor.c: make 2 functions static

[Jaime Velasco Juan]

El mar. 29 de ene. de 2008, a las 00:10:58 +0200, Adrian Bunk escribió:
 This patch makes the following needlessly global functions static:
 - stk_sensor_outb()
 - stk_sensor_inb()
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
Acked-by: Jaime Velasco Juan [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: option: Bind to the correct interface of the Huawei E220

[Jaime Velasco Juan]

Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Jaime Velasco Juan <[EMAIL PROTECTED]>
---

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
S620 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin 
EX720 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: option: Bind to the correct interface of the Huawei E220

[Jaime Velasco Juan]

Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
Signed-off-by: Jaime Velasco Juan [EMAIL PROTECTED]
---

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
S620 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin 
EX720 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add the infamous Huawei E220 to option.c

[Jaime Velasco Juan]

Hi,

El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> If everything's working please also add code to also support the other E220 
> device... so both PID 0x1003 and 0x1004 should be treaded the same way...
>
> to test the device with the 0x1004-PID maybe Jaime Velasco 
> <[EMAIL PROTECTED]> could be asked.. he initialy added the lines for 
> this device in option.c
>

The following patch works for me (on kernel 2.6.23).


diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
S620 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin 
EX720 */

> 73
>
> Zitat von Oliver Neukum <[EMAIL PROTECTED]>:
>
>> Am Donnerstag 29 November 2007 schrieb Rui Santos:
>>> >> Just to remember that that specific flag was one SET and, was removed,
>>> >> in part, because of what I state. Of course we aim at perfection but, if
>>> >> the benefits are only for a few situations and, will cause all this
>>> >> problems for all other, perhaps the reinsert of that flag would be a
>>> >> positive action.
>>> >>
>>> >
>>> > OK, can you provide "lsusb -v" for the device in the CD mode and in
>>> > the modem mode?
>>> >
>>> Of course. Heri it is.
>>
>> Thanks. Please try this patch.
>>
>>  Regards
>>  Oliver
>>
>> 
>>
>> --- a/drivers/usb/serial/option.c2007-11-29 12:35:09.0 +0100
>> +++ b/drivers/usb/serial/option.c2007-11-29 12:47:34.0 +0100
>> @@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
>>  { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
>>  { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
>>  { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
>> -{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
>> +{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
>> 0xff, 0xff, 0xff) },
>>  { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
>>  { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
>> XS620/S640 */
>>  { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
>> S620 */
>>
>>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add the infamous Huawei E220 to option.c

[Jaime Velasco Juan]

Hi,

El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
 If everything's working please also add code to also support the other E220 
 device... so both PID 0x1003 and 0x1004 should be treaded the same way...

 to test the device with the 0x1004-PID maybe Jaime Velasco 
 [EMAIL PROTECTED] could be asked.. he initialy added the lines for 
 this device in option.c


The following patch works for me (on kernel 2.6.23).


diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-   { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
S620 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin 
EX720 */

 73

 Zitat von Oliver Neukum [EMAIL PROTECTED]:

 Am Donnerstag 29 November 2007 schrieb Rui Santos:
  Just to remember that that specific flag was one SET and, was removed,
  in part, because of what I state. Of course we aim at perfection but, if
  the benefits are only for a few situations and, will cause all this
  problems for all other, perhaps the reinsert of that flag would be a
  positive action.
 
 
  OK, can you provide lsusb -v for the device in the CD mode and in
  the modem mode?
 
 Of course. Heri it is.

 Thanks. Please try this patch.

  Regards
  Oliver

 

 --- a/drivers/usb/serial/option.c2007-11-29 12:35:09.0 +0100
 +++ b/drivers/usb/serial/option.c2007-11-29 12:47:34.0 +0100
 @@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
  { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
  { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
  { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
 -{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
 +{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
 0xff, 0xff, 0xff) },
  { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
  { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
 XS620/S640 */
  { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin 
 S620 */



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] IA64/perfmon: kill dead code, clean irq handling

[Villacis, Juan]

Hi,

The VTune sampling driver currently uses this hook for cases where it
needs to do its own handling of the PMU on platforms that Perfmon2 may
not yet (fully, correctly) recognize at the time of the kernel's
release.

-juan 

-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 25, 2007 1:52 AM
To: [EMAIL PROTECTED]
Cc: Luck, Tony; [EMAIL PROTECTED]; Andrew Morton; LKML; Stone,
Joshua I; Villacis, Juan
Subject: Re: [PATCH] IA64/perfmon: kill dead code, clean irq handling

Stephane Eranian wrote:
> Jeff,
> 
> On Tue, Oct 23, 2007 at 07:09:08PM -0400, Jeff Garzik wrote:
>> By deleting unused code, this makes perfmon irq handling more
efficient,
>> as well as reducing code size.
>>
>> * remove unused pfm_install_alt_pmu_interrupt()
>> * remove unused pfm_remove_alt_pmu_interrupt()
>>
> I have not problem with the patch except maybe for those two
functions.
> How do you know they are not used?
> Have you checked the VTUNE open-source driver?
> I thought at some point they were using this hook.

I was hoping some IA-64 person could speak authoritatively on the
subject :)

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] IA64/perfmon: kill dead code, clean irq handling

[Villacis, Juan]

Hi,

The VTune sampling driver currently uses this hook for cases where it
needs to do its own handling of the PMU on platforms that Perfmon2 may
not yet (fully, correctly) recognize at the time of the kernel's
release.

-juan 

-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 25, 2007 1:52 AM
To: [EMAIL PROTECTED]
Cc: Luck, Tony; [EMAIL PROTECTED]; Andrew Morton; LKML; Stone,
Joshua I; Villacis, Juan
Subject: Re: [PATCH] IA64/perfmon: kill dead code, clean irq handling

Stephane Eranian wrote:
 Jeff,
 
 On Tue, Oct 23, 2007 at 07:09:08PM -0400, Jeff Garzik wrote:
 By deleting unused code, this makes perfmon irq handling more
efficient,
 as well as reducing code size.

 * remove unused pfm_install_alt_pmu_interrupt()
 * remove unused pfm_remove_alt_pmu_interrupt()

 I have not problem with the patch except maybe for those two
functions.
 How do you know they are not used?
 Have you checked the VTUNE open-source driver?
 I thought at some point they were using this hook.

I was hoping some IA-64 person could speak authoritatively on the
subject :)

Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ppdev - libieee1284.so conflicts with 2.6.21

[Juan Antonio Martinez]

El lun, 02-07-2007 a las 19:13 -0400, Chuck Ebbert escribió:
> On 07/02/2007 06:47 PM, Andrew Morton wrote:
[...]
> > --- a/drivers/char/ppdev.c~a
> > +++ a/drivers/char/ppdev.c
> 
> He's reporting the bug against kernel 2.6.21, which does not have the
> patch you are reverting applied.
> 
> ppdev hasn't changed in the six months prior to 2.6.21...

Your'e right: seems that fedora kernel is based in 2.6.21-git5 and
latest changes in ppdev and parport layer starts at 2.6.21-git10. 
So need to look at other changes...

What does mean this report received in my working kernel?

"ppdev0: negotiated back to compatibility mode because user-space
forgot"

Juan Antonio

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ppdev - libieee1284.so conflicts with 2.6.21

[Juan Antonio Martinez]

El lun, 02-07-2007 a las 19:13 -0400, Chuck Ebbert escribió:
 On 07/02/2007 06:47 PM, Andrew Morton wrote:
[...]
  --- a/drivers/char/ppdev.c~a
  +++ a/drivers/char/ppdev.c
 
 He's reporting the bug against kernel 2.6.21, which does not have the
 patch you are reverting applied.
 
 ppdev hasn't changed in the six months prior to 2.6.21...

Your'e right: seems that fedora kernel is based in 2.6.21-git5 and
latest changes in ppdev and parport layer starts at 2.6.21-git10. 
So need to look at other changes...

What does mean this report received in my working kernel?

ppdev0: negotiated back to compatibility mode because user-space
forgot

Juan Antonio

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ppdev - libieee1284.so conflicts with 2.6.21

[Juan Antonio Martinez]

I've reported this error to Fedora Bugzilla:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246406

In sort: to use libieee1284 I need to disable ppdev usage with
kernel 2.6.21. Kernel 2.6.20 works fine

[EMAIL PROTECTED] char]# uname -a
Linux drake.micasa.es 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT
2007 i686 athlon i386 GNU/Linux

By doing "echo disallow method ppdev > /etc/ieee1284.conf" everything
works fine on both kernels

Seems affect several distributions, not Fedora specific:
http://bugs.archlinux.org/task/7438
http://sourceforge.net/tracker/index.php?func=detail=1739643_id=29314=395778
http://www.digipedia.pl/man/libieee1284.3.html

Not sure if a kernel bug or a library one, so my apologizes if
this is not the propper list

Juan Antonio


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ppdev - libieee1284.so conflicts with 2.6.21

[Juan Antonio Martinez]

I've reported this error to Fedora Bugzilla:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246406

In sort: to use libieee1284 I need to disable ppdev usage with
kernel 2.6.21. Kernel 2.6.20 works fine

[EMAIL PROTECTED] char]# uname -a
Linux drake.micasa.es 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT
2007 i686 athlon i386 GNU/Linux

By doing echo disallow method ppdev  /etc/ieee1284.conf everything
works fine on both kernels

Seems affect several distributions, not Fedora specific:
http://bugs.archlinux.org/task/7438
http://sourceforge.net/tracker/index.php?func=detailaid=1739643group_id=29314atid=395778
http://www.digipedia.pl/man/libieee1284.3.html

Not sure if a kernel bug or a library one, so my apologizes if
this is not the propper list

Juan Antonio


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

On Sun, 25 Feb 2007, [utf-8] Jörn Engel wrote:


On Sun, 25 February 2007 03:41:40 +0100, Juan Piernas Canovas wrote:


Well, our experimental results say another thing. As I have said, the
greatest part of the files are written at once, so their meta-data blocks
are together on disk. This allows DualFS to implement an explicit
prefetching of meta-data blocks which is quite effective, specially when
there are several processes reading from disk at the same time.

On the other hand, DualFS also implements an on-line meta-data relocation
mechanism which can help to improve meta-data prefetching, and garbage
collection.

Obviously, there can be some slow-growing files that can produce some
garbage, but they do not hurt the overall performance of the file system.


Well, my concerns about the design have gone.  There remain some
concerns about the source code and I hope they will disappear just as
fast. :)


This is a bit more complicated ;)


Obviously, a patch against 2.4.x is fairly useless.  Iirc, you claimed
somewhere to have a patch against 2.6.11, but I was unable to find that.
Porting 2.6.11 to 2.6.20 should be simple enough.


I'm working on a public patch of DualFS for Linux 2.6.x. It's a matter of 
time.




Then there is some assembly code inside the patch that you seem to have
copied from some other project.  I would be surprised if that is really
required.  If you can replace it with C code, please do.

If the assembly actually is a performance gain (and I consider it your
duty to prove that), you can have a two-patch series with the first
introducing DualFS and the second adding the assembly as a config option
for one architecture.


No problem. I will see if the assembly code can be replaced with bare C.

Regards,

Juan.
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

On Sun, 25 Feb 2007, [utf-8] Jörn Engel wrote:


On Sun, 25 February 2007 03:41:40 +0100, Juan Piernas Canovas wrote:


Well, our experimental results say another thing. As I have said, the
greatest part of the files are written at once, so their meta-data blocks
are together on disk. This allows DualFS to implement an explicit
prefetching of meta-data blocks which is quite effective, specially when
there are several processes reading from disk at the same time.

On the other hand, DualFS also implements an on-line meta-data relocation
mechanism which can help to improve meta-data prefetching, and garbage
collection.

Obviously, there can be some slow-growing files that can produce some
garbage, but they do not hurt the overall performance of the file system.


Well, my concerns about the design have gone.  There remain some
concerns about the source code and I hope they will disappear just as
fast. :)


This is a bit more complicated ;)


Obviously, a patch against 2.4.x is fairly useless.  Iirc, you claimed
somewhere to have a patch against 2.6.11, but I was unable to find that.
Porting 2.6.11 to 2.6.20 should be simple enough.


I'm working on a public patch of DualFS for Linux 2.6.x. It's a matter of 
time.




Then there is some assembly code inside the patch that you seem to have
copied from some other project.  I would be surprised if that is really
required.  If you can replace it with C code, please do.

If the assembly actually is a performance gain (and I consider it your
duty to prove that), you can have a two-patch series with the first
introducing DualFS and the second adding the assembly as a config option
for one architecture.


No problem. I will see if the assembly code can be replaced with bare C.

Regards,

Juan.
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.esop=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

On Fri, 23 Feb 2007, [utf-8] Jörn Engel wrote:


On Thu, 22 February 2007 20:57:12 +0100, Juan Piernas Canovas wrote:


I do not agree with this picture, because it does not show that all the
indirect blocks which point to a direct block are along with it in the
same segment. That figure should look like:

Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1  D2  ] [more data]

where D0, DA, and DB are datablocks, D1 and D2 indirect blocks which
point to the datablocks, and D1' and D2' obsolete copies of those
indirect blocks. By using this figure, is is clear that if you need to
move D0 to clean the segment 2, you will need only one free segment at
most, and not more. You will get:

Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [free]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..
Segment n: [ D0 D1 D2 ] [ empty ]

That is, D0 needs in the new segment the same space that it needs in the
previous one.

The differences are subtle but important.


Ah, now I see.  Yes, that is deadlock-free.  If you are not accounting
the bytes of used space but the number of used segments, and you count
each partially used segment the same as a 100% used segment, there is no
deadlock.

Some people may consider this to be cheating, however.  It will cause
more than 50% wasted space.  All obsolete copies are garbage, after all.
With a maximum tree height of N, you can have up to (N-1) / N of your
filesystem occupied by garbage.


I do not agree. Fortunately, the greatest part of the files are written at 
once, so what you usually have is:


Segment 1: [  data  ]
Segment 2: [some data] [ D0 DA DB D1 D2 ] [more data]
Segment 3: [  data  ]
..

On the other hand, the DualFS cleaner tries to clean several segments 
everytime it runs. Therefore, if you have the following case:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..

after cleaning, you can have this one:

Segment 3: [  free  ]
Segment 3: [  free  ]
Segment 3: [  free  ]
..
Segment i: [D0 DA DB D1 D2 ] [   more data  ]

Moreover, if the cleaner starts running when the free space drops below a 
specific threshold, it is very difficult to waste more than 50% of disk 
space, specially with meta-data (actually, I am unable to imagine that 
situation :).



Another downside is that with large amounts of garbage between otherwise
useful data, your disk cache hit rate goes down.  Read performance is
suffering.  But that may be a fair tradeoff and will only show up in
large metadata reads in the uncached (per Linux) case.  Seems fair.


Well, our experimental results say another thing. As I have said, the 
greatest part of the files are written at once, so their meta-data blocks 
are together on disk. This allows DualFS to implement an explicit 
prefetching of meta-data blocks which is quite effective, specially when 
there are several processes reading from disk at the same time.


On the other hand, DualFS also implements an on-line meta-data relocation 
mechanism which can help to improve meta-data prefetching, and garbage 
collection.


Obviously, there can be some slow-growing files that can produce some 
garbage, but they do not hurt the overall performance of the file system.




Quite interesting, actually.  The costs of your design are disk space,
depending on the amount and depth of your metadata, and metadata read
performance.  Disk space is cheap and metadata reads tend to be slow for
most filesystems, in comparison to data reads.  You gain faster metadata
writes and loss of journal overhead.  I like the idea.



Yeah :) If you have taken a look to my presentation at LFS07, the disk 
traffic of meta-data blocks is dominated by writes.



Jörn



Juan.
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

On Fri, 23 Feb 2007, [utf-8] Jörn Engel wrote:


On Thu, 22 February 2007 20:57:12 +0100, Juan Piernas Canovas wrote:


I do not agree with this picture, because it does not show that all the
indirect blocks which point to a direct block are along with it in the
same segment. That figure should look like:

Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1  D2  ] [more data]

where D0, DA, and DB are datablocks, D1 and D2 indirect blocks which
point to the datablocks, and D1' and D2' obsolete copies of those
indirect blocks. By using this figure, is is clear that if you need to
move D0 to clean the segment 2, you will need only one free segment at
most, and not more. You will get:

Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [free]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..
Segment n: [ D0 D1 D2 ] [ empty ]

That is, D0 needs in the new segment the same space that it needs in the
previous one.

The differences are subtle but important.


Ah, now I see.  Yes, that is deadlock-free.  If you are not accounting
the bytes of used space but the number of used segments, and you count
each partially used segment the same as a 100% used segment, there is no
deadlock.

Some people may consider this to be cheating, however.  It will cause
more than 50% wasted space.  All obsolete copies are garbage, after all.
With a maximum tree height of N, you can have up to (N-1) / N of your
filesystem occupied by garbage.


I do not agree. Fortunately, the greatest part of the files are written at 
once, so what you usually have is:


Segment 1: [  data  ]
Segment 2: [some data] [ D0 DA DB D1 D2 ] [more data]
Segment 3: [  data  ]
..

On the other hand, the DualFS cleaner tries to clean several segments 
everytime it runs. Therefore, if you have the following case:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..

after cleaning, you can have this one:

Segment 3: [  free  ]
Segment 3: [  free  ]
Segment 3: [  free  ]
..
Segment i: [D0 DA DB D1 D2 ] [   more data  ]

Moreover, if the cleaner starts running when the free space drops below a 
specific threshold, it is very difficult to waste more than 50% of disk 
space, specially with meta-data (actually, I am unable to imagine that 
situation :).



Another downside is that with large amounts of garbage between otherwise
useful data, your disk cache hit rate goes down.  Read performance is
suffering.  But that may be a fair tradeoff and will only show up in
large metadata reads in the uncached (per Linux) case.  Seems fair.


Well, our experimental results say another thing. As I have said, the 
greatest part of the files are written at once, so their meta-data blocks 
are together on disk. This allows DualFS to implement an explicit 
prefetching of meta-data blocks which is quite effective, specially when 
there are several processes reading from disk at the same time.


On the other hand, DualFS also implements an on-line meta-data relocation 
mechanism which can help to improve meta-data prefetching, and garbage 
collection.


Obviously, there can be some slow-growing files that can produce some 
garbage, but they do not hurt the overall performance of the file system.




Quite interesting, actually.  The costs of your design are disk space,
depending on the amount and depth of your metadata, and metadata read
performance.  Disk space is cheap and metadata reads tend to be slow for
most filesystems, in comparison to data reads.  You gain faster metadata
writes and loss of journal overhead.  I like the idea.



Yeah :) If you have taken a look to my presentation at LFS07, the disk 
traffic of meta-data blocks is dominated by writes.



Jörn



Juan.
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.esop=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

On Thu, 22 Feb 2007, [utf-8] Jörn Engel wrote:


A partial segment is a transaction unit, and contains "all" the blocks
modified by a file system operation, including indirect blocks and i-nodes
(actually, it contains the blocks modified by several file system
operations, but let us assume that every partial segment only contains the
blocks modified by a single file system operation).

So, the above figure is as follows in DualFS:

 Before:
 Segment 1: [some data] [ D0 D1 D2 I ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [   empty]

If the datablock D0 is modified, what you get is:

 Segment 1: [some data] [  garbage   ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [ D0 D1 D2 I ] [   empty ]


You have fairly strict assumptions about the "Before:" picture.  But


The "Before" figure is intentionally simple because it is enough to 
understand how the meta-data device of DualFS works, and why the cleaner 
is deadlock-free ;-)



what happens if those assumptions fail.  To give you an example, imagine
the following small script:

$ for i in `seq 100`; do touch $i; done

This will create a million dentries in one directory.  It will also
create a million inodes, but let us ignore those for a moment.  It is
fairly unlikely that you can fit a million dentries into [D0], so you
will need more than one block.  Let's call them [DA], [DB], [DC], etc.
So you have to write out the first block [DA].

Before:
Segment 1: [some data] [ DA D1 D2 I ] [more data]
Segment 2: [ some data  ]
Segment 3: [   empty]

If the datablock D0 is modified, what you get is:

Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA D1 D2 I ] [   empty ]

That is exactly your picture.  Fine.  Next you write [DB].

Before: see above
After:
Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB D1 D2 I ] [ empty]

You write [DC].  Note that Segment 3 does not have enough space for
another partial segment:

Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC D1 D2 I ] [   empty ]

You write [DD] and [DE]:
Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC][garbage] [ DD][garbage] [wasted]
Segment 5: [ DE D1 D2 I ] [   empty ]

And some time later you even have to switch to a new indirect block, so
you get before:

Segment n  : [ DX D1 D2 I ] [   empty ]

After:

Segment n  : [ DX D1][garb] [ DY DI D2 I ] [ empty]

What you end up with after all this is quite unlike you "Before"
picture.  Instead of this:


 Segment 1: [some data] [ D0 D1 D2 I ] [more data]




I agree with all the above, althoug it displays the wort case because a 
partial segment usually contains several datablocks, and a few indirect 
blocks. But it is fine for our purposes.



You may have something closer to this:


Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]




I do not agree with this picture, because it does not show that all the 
indirect blocks which point to a direct block are along with it in the 
same segment. That figure should look like:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1  D2  ] [more data]

where D0, DA, and DB are datablocks, D1 and D2 indirect blocks which 
point to the datablocks, and D1' and D2' obsolete copies of those 
indirect blocks. By using this figure, is is clear that if you need to 
move D0 to clean the segment 2, you will need only one free segment at 
most, and not more. You will get:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [free]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..
Segment n: [ D0 D1 D2 ] [ empty ]

That is, D0 needs in the new segment the same space that it needs in the 
previous one.


The differences are subtle but important.

Regards,

Juan.


You should try the testcase and look at a dump of your filesystem
afterwards.  I usually just read the raw device in a hex editor.

Jörn




--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

On Thu, 22 Feb 2007, [utf-8] Jörn Engel wrote:


A partial segment is a transaction unit, and contains all the blocks
modified by a file system operation, including indirect blocks and i-nodes
(actually, it contains the blocks modified by several file system
operations, but let us assume that every partial segment only contains the
blocks modified by a single file system operation).

So, the above figure is as follows in DualFS:

 Before:
 Segment 1: [some data] [ D0 D1 D2 I ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [   empty]

If the datablock D0 is modified, what you get is:

 Segment 1: [some data] [  garbage   ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [ D0 D1 D2 I ] [   empty ]


You have fairly strict assumptions about the Before: picture.  But


The Before figure is intentionally simple because it is enough to 
understand how the meta-data device of DualFS works, and why the cleaner 
is deadlock-free ;-)



what happens if those assumptions fail.  To give you an example, imagine
the following small script:

$ for i in `seq 100`; do touch $i; done

This will create a million dentries in one directory.  It will also
create a million inodes, but let us ignore those for a moment.  It is
fairly unlikely that you can fit a million dentries into [D0], so you
will need more than one block.  Let's call them [DA], [DB], [DC], etc.
So you have to write out the first block [DA].

Before:
Segment 1: [some data] [ DA D1 D2 I ] [more data]
Segment 2: [ some data  ]
Segment 3: [   empty]

If the datablock D0 is modified, what you get is:

Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA D1 D2 I ] [   empty ]

That is exactly your picture.  Fine.  Next you write [DB].

Before: see above
After:
Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB D1 D2 I ] [ empty]

You write [DC].  Note that Segment 3 does not have enough space for
another partial segment:

Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC D1 D2 I ] [   empty ]

You write [DD] and [DE]:
Segment 1: [some data] [  garbage   ] [more data]
Segment 2: [ some data  ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC][garbage] [ DD][garbage] [wasted]
Segment 5: [ DE D1 D2 I ] [   empty ]

And some time later you even have to switch to a new indirect block, so
you get before:

Segment n  : [ DX D1 D2 I ] [   empty ]

After:

Segment n  : [ DX D1][garb] [ DY DI D2 I ] [ empty]

What you end up with after all this is quite unlike you Before
picture.  Instead of this:


 Segment 1: [some data] [ D0 D1 D2 I ] [more data]




I agree with all the above, althoug it displays the wort case because a 
partial segment usually contains several datablocks, and a few indirect 
blocks. But it is fine for our purposes.



You may have something closer to this:


Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]




I do not agree with this picture, because it does not show that all the 
indirect blocks which point to a direct block are along with it in the 
same segment. That figure should look like:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [some data] [ D0 D1' D2' ] [more data]
Segment 3: [some data] [ DB D1  D2  ] [more data]

where D0, DA, and DB are datablocks, D1 and D2 indirect blocks which 
point to the datablocks, and D1' and D2' obsolete copies of those 
indirect blocks. By using this figure, is is clear that if you need to 
move D0 to clean the segment 2, you will need only one free segment at 
most, and not more. You will get:


Segment 1: [some data] [ DA D1' D2' ] [more data]
Segment 2: [free]
Segment 3: [some data] [ DB D1' D2' ] [more data]
..
Segment n: [ D0 D1 D2 ] [ empty ]

That is, D0 needs in the new segment the same space that it needs in the 
previous one.


The differences are subtle but important.

Regards,

Juan.


You should try the testcase and look at a dump of your filesystem
afterwards.  I usually just read the raw device in a hex editor.

Jörn




--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.esop=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

I have been thinking about the problem that you describe, and, 
definitively, DualFS does not have that problem. I could be wrong, but, 
I actually believe that the GC implemented by DualFS is deadlock-free. 
The key is the design of the log-structured file system used by DualFS for 
the meta-data device, which is different to the design that you propose.


On Wed, 21 Feb 2007, [utf-8] Jörn Engel wrote:


On Wed, 21 February 2007 19:31:40 +0100, Juan Piernas Canovas wrote:


I do not understand. Do you mean that if I have 10 segments, 5 busy and 5
free, after cleaning I could need 6 segments? How? Where the extra blocks
come from?


This is a fairly complicated subject and I have trouble explaining it to
people - even though I hope that maybe one or two dozen understand it by
now.  So let me try to give you an example:

In LogFS, inodes are stored in an inode file.  There are no B-Trees yet,
so the regular unix indirect blocks are used.  My example will be
writing to a directory, so that should only involve metadata by your
definition and be a valid example for DualFS as well.  If it is not,
please tell me where the difference lies.

The directory is large, so appending to it involves writing a datablock
(D0), and indirect block (D1) and a doubly indirect block (D2).

Before:
Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]
Segment 4: [ empty ]
...


DualFS writes meta-blocks in variable-sized chunks that we call partial 
segments. The meta-data device, however, is divided into segments, which 
have the same size. A partial segment can be as large a a segment, but a 
segment usually has more that one partial segment. Besides, a partial 
segment can not cross a segment boundary.


A partial segment is a transaction unit, and contains "all" the blocks 
modified by a file system operation, including indirect blocks and i-nodes 
(actually, it contains the blocks modified by several file system 
operations, but let us assume that every partial segment only contains the 
blocks modified by a single file system operation).


So, the above figure is as follows in DualFS:

 Before:
 Segment 1: [some data] [ D0 D1 D2 I ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [   empty]

If the datablock D0 is modified, what you get is:

 Segment 1: [some data] [  garbage   ] [more data]
 Segment 2: [ some data  ]
 Segment 3: [ D0 D1 D2 I ] [   empty ]

This is very similar to what the cleaner does. Therefore, moving a direct 
datablock (D0) to a new segment does not require more space than in the 
original segment. That is, cleaning a segment in DualFS requires just one 
free segment, and not more.


The result is that you can use all the free segments in DualFS, and its 
cleaner is simple and deadlock-free. Probably the design is not the most 
space-efficient in the world, but it removes some other serious problems.


And, remember, we are talking about meta-data (which is a small part of 
the file system), and disk space (which is quite inexpensive).


Regards,

    Juan.



After:
Segment 1: [some data] [garbage] [more data]
Segment 2: [some data] [garbage] [more data]
Segment 3: [some data] [garbage] [more data]
Segment 4: [D0][D1][D2][  empty]
...

Ok.  After this, the position of D2 on the medium has changed.  So we
need to update the inode and write that as well.  If the inode number
for this directory is high, we will need to write the inode (I0), an
indirect block (I1) and a doubly indirect block (I2).  The picture
becomes a bit more complicates.

Before:
Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]
Segment 4: [ empty ]
Segment 5: [some data] [   I1  ] [more data]
Segment 6: [some data] [   I0  ] [more data]
Segment 7: [some data] [   I2  ] [more data]
...

After:
Segment 1: [some data] [garbage] [more data]
Segment 2: [some data] [garbage] [more data]
Segment 3: [some data] [garbage] [more data]
Segment 4: [D0][D1][D2][I0][I1][I2][ empty ]
Segment 5: [some data] [garbage] [more data]
Segment 6: [some data] [garbage] [more data]
Segment 7: [some data] [garbage] [more data]
...

So what has just happened?  The user did a single "touch foo" in a large
directory and has caused six objects to move.  Unless some of those
objects were in the same segment before, we now have six segments
containing a tiny amount of garbage.

And there is almost no way how you can squeeze that garbage back out.
The cleaner will fundamentally do the same thing as a regular write - it
will move objects.  So if you want to clean a segment containing the
block of a different directory, you may again have to move five
additional objects, the indirect blocks, inode and ifile indirect
bl

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Juan Piernas Canovas]

Hi Jörn,

On Wed, 21 Feb 2007, [utf-8] Jörn Engel wrote:


On Wed, 21 February 2007 05:36:22 +0100, Juan Piernas Canovas wrote:


I don't see how you can guarantee 50% free segments.  Can you explain
that bit?

It is quite simple. If 50% of your segments are busy, and the other 50%
are free, and the file system needs a new segment, the cleaner starts
freeing some of busy ones. If the cleaner is unable to free one segment at
least, your file system gets "full" (and it returns a nice ENOSPC error).
This solution wastes the half of your storage device, but it is
deadlock-free. Obviously, there are better approaches.


Ah, ok.  It is deadlock free, if the maximal height of your tree is 2.
It is not 100% deadlock free if the height is 3 or more.

Also, I strongly suspect that your tree is higher than 2.  A medium
sized directory will have data blocks, indirect blocks and the inode
proper, which gives you a height of 3.  Your inodes need to get accessed
somehow and unless they have fixed positions like in ext2, you need a
further tree structure of some sorts, so you're more likely looking at a
height of 5.

With a height of 5, you would need to keep 80% of you metadata free.
That is starting to get wasteful.

So I suspect that my proposed alternate cleaner mechanism or the even
better "hole plugging" mechanism proposed in the paper a few posts above
would be a better path to follow.


I do not understand. Do you mean that if I have 10 segments, 5 busy and 5 
free, after cleaning I could need 6 segments? How? Where the extra blocks 
come from?


    Juan.

--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***