| Message ID | 1349885000-22887-1-git-send-email-ulf.hansson@stericsson.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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>
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.
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.)
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
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.
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
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.