[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

For data writes <= 8 bytes, HW flow control was disabled but
never re-enabled when the transfer was completed. This meant
that a following read request would give buffer overrun errors.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edc3e9b..877079e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -654,9 +654,29 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 
 	/* The ST Micro variants has a special bit to enable SDIO */
 	if (variant->sdio && host->mmc->card)
-		if (mmc_card_sdio(host->mmc->card))
+		if (mmc_card_sdio(host->mmc->card)) {
+			/*
+			 * The ST Micro variants has a special bit
+			 * to enable SDIO.
+			 */
+			u32 clk;
+
 			datactrl |= MCI_ST_DPSM_SDIOEN;
 
+			/*
+			 * The ST Micro variant for SDIO transfer sizes
+			 * less then 8 bytes should have clock H/W flow
+			 * control disabled.
+			 */
+			if ((host->size < 8) &&
+			    (data->flags & MMC_DATA_WRITE))
+				clk = host->clk_reg & ~variant->clkreg_enable;
+			else
+				clk = host->clk_reg | variant->clkreg_enable;
+
+			mmci_write_clkreg(host, clk);
+		}
+
 	/*
 	 * Attempt to use DMA operation mode, if this
 	 * should fail, fall back to PIO mode
@@ -877,22 +897,6 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
 		count = min(remain, maxcnt);
 
 		/*
-		 * The ST Micro variant for SDIO transfer sizes
-		 * less then 8 bytes should have clock H/W flow
-		 * control disabled.
-		 */
-		if (variant->sdio &&
-		    mmc_card_sdio(host->mmc->card)) {
-			u32 clk;
-			if (count < 8)
-				clk = host->clk_reg & ~variant->clkreg_enable;
-			else
-				clk = host->clk_reg | variant->clkreg_enable;
-
-			mmci_write_clkreg(host, clk);
-		}
-
-		/*
 		 * SDIO especially may want to send something that is
 		 * not divisible by 4 (as opposed to card sectors
 		 * etc), and the FIFO only accept full 32-bit writes.
-- 
1.7.10

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

For data writes <= 8 bytes, HW flow control was disabled but
never re-enabled when the transfer was completed. This meant
that a following read request would give buffer overrun errors.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edc3e9b..877079e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -654,9 +654,29 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 
 	/* The ST Micro variants has a special bit to enable SDIO */
 	if (variant->sdio && host->mmc->card)
-		if (mmc_card_sdio(host->mmc->card))
+		if (mmc_card_sdio(host->mmc->card)) {
+			/*
+			 * The ST Micro variants has a special bit
+			 * to enable SDIO.
+			 */
+			u32 clk;
+
 			datactrl |= MCI_ST_DPSM_SDIOEN;
 
+			/*
+			 * The ST Micro variant for SDIO transfer sizes
+			 * less then 8 bytes should have clock H/W flow
+			 * control disabled.
+			 */
+			if ((host->size < 8) &&
+			    (data->flags & MMC_DATA_WRITE))
+				clk = host->clk_reg & ~variant->clkreg_enable;
+			else
+				clk = host->clk_reg | variant->clkreg_enable;
+
+			mmci_write_clkreg(host, clk);
+		}
+
 	/*
 	 * Attempt to use DMA operation mode, if this
 	 * should fail, fall back to PIO mode
@@ -877,22 +897,6 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
 		count = min(remain, maxcnt);
 
 		/*
-		 * The ST Micro variant for SDIO transfer sizes
-		 * less then 8 bytes should have clock H/W flow
-		 * control disabled.
-		 */
-		if (variant->sdio &&
-		    mmc_card_sdio(host->mmc->card)) {
-			u32 clk;
-			if (count < 8)
-				clk = host->clk_reg & ~variant->clkreg_enable;
-			else
-				clk = host->clk_reg | variant->clkreg_enable;
-
-			mmci_write_clkreg(host, clk);
-		}
-
-		/*
 		 * SDIO especially may want to send something that is
 		 * not divisible by 4 (as opposed to card sectors
 		 * etc), and the FIFO only accept full 32-bit writes.
-- 
1.7.10

[RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

For writes, HWFC shall be switched off when transfer size <= 8
bytes and when MCLK rate is above 50 MHz. For 50MHz and below
it shall be switched off when transfer size < 8 bytes.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 877079e..cd0fbee 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -664,12 +664,14 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 			datactrl |= MCI_ST_DPSM_SDIOEN;
 
 			/*
-			 * The ST Micro variant for SDIO transfer sizes
-			 * less then 8 bytes should have clock H/W flow
-			 * control disabled.
+			 * The ST Micro variant for SDIO small write transfers
+			 * needs to have clock H/W flow control disabled,
+			 * otherwise the transfer will not start. The threshold
+			 * depends on the rate of MCLK.
 			 */
-			if ((host->size < 8) &&
-			    (data->flags & MMC_DATA_WRITE))
+			if (data->flags & MMC_DATA_WRITE &&
+			    (host->size < 8 ||
+			     (host->size <= 8 && host->mclk > 50000000)))
 				clk = host->clk_reg & ~variant->clkreg_enable;
 			else
 				clk = host->clk_reg | variant->clkreg_enable;
-- 
1.7.10

[RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

For writes, HWFC shall be switched off when transfer size <= 8
bytes and when MCLK rate is above 50 MHz. For 50MHz and below
it shall be switched off when transfer size < 8 bytes.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 877079e..cd0fbee 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -664,12 +664,14 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 			datactrl |= MCI_ST_DPSM_SDIOEN;
 
 			/*
-			 * The ST Micro variant for SDIO transfer sizes
-			 * less then 8 bytes should have clock H/W flow
-			 * control disabled.
+			 * The ST Micro variant for SDIO small write transfers
+			 * needs to have clock H/W flow control disabled,
+			 * otherwise the transfer will not start. The threshold
+			 * depends on the rate of MCLK.
 			 */
-			if ((host->size < 8) &&
-			    (data->flags & MMC_DATA_WRITE))
+			if (data->flags & MMC_DATA_WRITE &&
+			    (host->size < 8 ||
+			     (host->size <= 8 && host->mclk > 50000000)))
 				clk = host->clk_reg & ~variant->clkreg_enable;
 			else
 				clk = host->clk_reg | variant->clkreg_enable;
-- 
1.7.10

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Linus Walleij]

On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Looks correct to me:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

I guess this goes into Russell's patch tracker.

Yours,
Linus Walleij

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Linus Walleij]

On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Looks correct to me:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

I guess this goes into Russell's patch tracker.

Yours,
Linus Walleij

Re: [RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Linus Walleij]

On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For writes, HWFC shall be switched off when transfer size <= 8
> bytes and when MCLK rate is above 50 MHz. For 50MHz and below
> it shall be switched off when transfer size < 8 bytes.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Linus Walleij]

On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For writes, HWFC shall be switched off when transfer size <= 8
> bytes and when MCLK rate is above 50 MHz. For 50MHz and below
> it shall be switched off when transfer size < 8 bytes.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Johan Rudholm]

2012/10/10 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> For writes, HWFC shall be switched off when transfer size <= 8
>> bytes and when MCLK rate is above 50 MHz. For 50MHz and below
>> it shall be switched off when transfer size < 8 bytes.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>

[RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK

[Johan Rudholm]

2012/10/10 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> For writes, HWFC shall be switched off when transfer size <= 8
>> bytes and when MCLK rate is above 50 MHz. For 50MHz and below
>> it shall be switched off when transfer size < 8 bytes.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Johan Rudholm]

2012/10/10 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> For data writes <= 8 bytes, HW flow control was disabled but
>> never re-enabled when the transfer was completed. This meant
>> that a following read request would give buffer overrun errors.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Looks correct to me:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Johan Rudholm]

2012/10/10 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> For data writes <= 8 bytes, HW flow control was disabled but
>> never re-enabled when the transfer was completed. This meant
>> that a following read request would give buffer overrun errors.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Looks correct to me:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
> 
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Both look fine to me too.  Linus' has already said what needs to happen
with these two.  Thanks.

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
> 
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Both look fine to me too.  Linus' has already said what needs to happen
with these two.  Thanks.

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> > 
> > For data writes <= 8 bytes, HW flow control was disabled but
> > never re-enabled when the transfer was completed. This meant
> > that a following read request would give buffer overrun errors.
> > 
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Both look fine to me too.  Linus' has already said what needs to happen
> with these two.  Thanks.

Ulf,

I see you've tried three times to get a replacement password for the
patch system today.  If it's not getting through, you need to complain
to your IT department, and get them to complain to Google:

2012-10-12 11:09:21 1TMcBE-0005ED-VS <= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcBD-00061o-HP@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 11:09:24 1TMcBE-0005ED-VS => ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
2012-10-12 11:25:13 1TMcQb-0005EY-8d <= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcQZ-00066s-2O@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 11:25:17 1TMcQb-0005EY-8d => ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
2012-10-12 12:25:56 1TMdNM-0005IG-8u <= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMdNK-0006XU-SG@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 12:25:59 1TMdNM-0005IG-8u => ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"

You are not the first to encounter this problem.  psmtp.com seems to
put the password reminders into a big black hole, and this is inspite
of them trying to follow every possible RFC concerning auto-generated
mail, and being DKIM signed too.

Unfortunately, what this means is that effectively the spammers have
won the arms race: it is becoming increasingly difficult to get email
through to the intended destination due to all the filtering that
people now impose (not that it ever has been guaranteed.)

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> > 
> > For data writes <= 8 bytes, HW flow control was disabled but
> > never re-enabled when the transfer was completed. This meant
> > that a following read request would give buffer overrun errors.
> > 
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Both look fine to me too.  Linus' has already said what needs to happen
> with these two.  Thanks.

Ulf,

I see you've tried three times to get a replacement password for the
patch system today.  If it's not getting through, you need to complain
to your IT department, and get them to complain to Google:

2012-10-12 11:09:21 1TMcBE-0005ED-VS <= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcBD-00061o-HP at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 11:09:24 1TMcBE-0005ED-VS => ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
2012-10-12 11:25:13 1TMcQb-0005EY-8d <= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcQZ-00066s-2O at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 11:25:17 1TMcQb-0005EY-8d => ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
2012-10-12 12:25:56 1TMdNM-0005IG-8u <= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMdNK-0006XU-SG at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
2012-10-12 12:25:59 1TMdNM-0005IG-8u => ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"

You are not the first to encounter this problem.  psmtp.com seems to
put the password reminders into a big black hole, and this is inspite
of them trying to follow every possible RFC concerning auto-generated
mail, and being DKIM signed too.

Unfortunately, what this means is that effectively the spammers have
won the arms race: it is becoming increasingly difficult to get email
through to the intended destination due to all the filtering that
people now impose (not that it ever has been guaranteed.)

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

On 10/12/2012 01:54 PM, Russell King - ARM Linux wrote:
> On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote:
>> On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
>>> From: Ulf Hansson<ulf.hansson@linaro.org>
>>>
>>> For data writes<= 8 bytes, HW flow control was disabled but
>>> never re-enabled when the transfer was completed. This meant
>>> that a following read request would give buffer overrun errors.
>>>
>>> Signed-off-by: Ulf Hansson<ulf.hansson@linaro.org>
>>
>> Both look fine to me too.  Linus' has already said what needs to happen
>> with these two.  Thanks.
>
> Ulf,
>
> I see you've tried three times to get a replacement password for the
> patch system today.  If it's not getting through, you need to complain
> to your IT department, and get them to complain to Google:
>
> 2012-10-12 11:09:21 1TMcBE-0005ED-VS<= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcBD-00061o-HP@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 11:09:24 1TMcBE-0005ED-VS =>  ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
> 2012-10-12 11:25:13 1TMcQb-0005EY-8d<= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcQZ-00066s-2O@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 11:25:17 1TMcQb-0005EY-8d =>  ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
> 2012-10-12 12:25:56 1TMdNM-0005IG-8u<= apache@arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMdNK-0006XU-SG@n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 12:25:59 1TMdNM-0005IG-8u =>  ulf.hansson@stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
>
> You are not the first to encounter this problem.  psmtp.com seems to
> put the password reminders into a big black hole, and this is inspite
> of them trying to follow every possible RFC concerning auto-generated
> mail, and being DKIM signed too.
>
> Unfortunately, what this means is that effectively the spammers have
> won the arms race: it is becoming increasingly difficult to get email
> through to the intended destination due to all the filtering that
> people now impose (not that it ever has been guaranteed.)

Hi Russell,

Our IT department is slow, too slow. :-)

As an option, would it be possible for you to "manually" send me a new 
password? Another option would be to change the mail for my account to 
ulf.hansson@linaro.org

Any help appreciated!

Kind regards
Ulf Hansson

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

On 10/12/2012 01:54 PM, Russell King - ARM Linux wrote:
> On Fri, Oct 12, 2012 at 10:13:22AM +0100, Russell King - ARM Linux wrote:
>> On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
>>> From: Ulf Hansson<ulf.hansson@linaro.org>
>>>
>>> For data writes<= 8 bytes, HW flow control was disabled but
>>> never re-enabled when the transfer was completed. This meant
>>> that a following read request would give buffer overrun errors.
>>>
>>> Signed-off-by: Ulf Hansson<ulf.hansson@linaro.org>
>>
>> Both look fine to me too.  Linus' has already said what needs to happen
>> with these two.  Thanks.
>
> Ulf,
>
> I see you've tried three times to get a replacement password for the
> patch system today.  If it's not getting through, you need to complain
> to your IT department, and get them to complain to Google:
>
> 2012-10-12 11:09:21 1TMcBE-0005ED-VS<= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:55740 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcBD-00061o-HP at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 11:09:24 1TMcBE-0005ED-VS =>  ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
> 2012-10-12 11:25:13 1TMcQb-0005EY-8d<= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:37918 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMcQZ-00066s-2O at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 11:25:17 1TMcQb-0005EY-8d =>  ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
> 2012-10-12 12:25:56 1TMdNM-0005IG-8u<= apache at arm.linux.org.uk H=n2100.arm.linux.org.uk [2002:4e20:1eda:1:214:fdff:fe10:4f86]:57521 I=[2002:4e20:1eda:1:24c:69ff:fe6e:7578]:25 P=esmtpsa X=TLSv1:AES256-SHA:256 A=cram:n2100.arm.linux.org.uk S=1065 id=E1TMdNK-0006XU-SG at n2100.arm.linux.org.uk T="Your new password" for ulf.hansson@stericsson.com
> 2012-10-12 12:25:59 1TMdNM-0005IG-8u =>  ulf.hansson at stericsson.com R=verp_dnslookup T=verp_smtp S=1097 H=stericsson.com.s200a1.psmtp.com [207.126.147.10] X=TLSv1:AES256-SHA:256 DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" C="250 Thanks"
>
> You are not the first to encounter this problem.  psmtp.com seems to
> put the password reminders into a big black hole, and this is inspite
> of them trying to follow every possible RFC concerning auto-generated
> mail, and being DKIM signed too.
>
> Unfortunately, what this means is that effectively the spammers have
> won the arms race: it is becoming increasingly difficult to get email
> through to the intended destination due to all the filtering that
> people now impose (not that it ever has been guaranteed.)

Hi Russell,

Our IT department is slow, too slow. :-)

As an option, would it be possible for you to "manually" send me a new 
password? Another option would be to change the mail for my account to 
ulf.hansson at linaro.org

Any help appreciated!

Kind regards
Ulf Hansson

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote:
> Hi Russell,
>
> Our IT department is slow, too slow. :-)
>
> As an option, would it be possible for you to "manually" send me a new  
> password? Another option would be to change the mail for my account to  
> ulf.hansson@linaro.org

Updated the email address; that's easier than trying to generate a new
password manually.  Please ask the site for a replacement password using
your linaro address and hopefully you should get it.

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Russell King - ARM Linux]

On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote:
> Hi Russell,
>
> Our IT department is slow, too slow. :-)
>
> As an option, would it be possible for you to "manually" send me a new  
> password? Another option would be to change the mail for my account to  
> ulf.hansson at linaro.org

Updated the email address; that's easier than trying to generate a new
password manually.  Please ask the site for a replacement password using
your linaro address and hopefully you should get it.

Re: [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

On 12 October 2012 14:35, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote:
>> Hi Russell,
>>
>> Our IT department is slow, too slow. :-)
>>
>> As an option, would it be possible for you to "manually" send me a new
>> password? Another option would be to change the mail for my account to
>> ulf.hansson@linaro.org
>
> Updated the email address; that's easier than trying to generate a new
> password manually.  Please ask the site for a replacement password using
> your linaro address and hopefully you should get it.

Thanks a lot for helping out. I got a new pwd now!

Kind regards
Ulf Hansson

[RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO

[Ulf Hansson]

On 12 October 2012 14:35, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 12, 2012 at 02:24:16PM +0200, Ulf Hansson wrote:
>> Hi Russell,
>>
>> Our IT department is slow, too slow. :-)
>>
>> As an option, would it be possible for you to "manually" send me a new
>> password? Another option would be to change the mail for my account to
>> ulf.hansson at linaro.org
>
> Updated the email address; that's easier than trying to generate a new
> password manually.  Please ask the site for a replacement password using
> your linaro address and hopefully you should get it.

Thanks a lot for helping out. I got a new pwd now!

Kind regards
Ulf Hansson