Probably dropped because I complained about two things, 1) The patch doesnt check what the hardware is underneath before arbitrarily changing the parameters relied on by some hardware 2) Removing a comment I put there for a good reason without explaining why. "It works on my hardware" is not a good enough excuse. -- Ian Molton Linux, Automotive, and other hacking: http://www.mnementh.co.uk/ On 25 August 2010 23:05, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 25 Aug 2010 22:52:08 +0100 > Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote: > >> On Tue, 13 Jul 2010 11:32:33 +0900 >> Yusuke Goda <yusuke.goda.sx@xxxxxxxxxxx> wrote: >> >> > Hi Andrew >> > >> > Andrew Morton wrote: >> > > On Wed, 07 Jul 2010 11:01:20 +0900 >> > > Yusuke Goda <yusuke.goda.sx@xxxxxxxxxxx> wrote: >> > > >> > >> Signed-off-by: Yusuke Goda <yusuke.goda.sx@xxxxxxxxxxx> >> > >> --- >> > >> drivers/mmc/host/tmio_mmc.c | 2 +- >> > >> 1 files changed, 1 insertions(+), 1 deletions(-) >> > >> >> > >> diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c >> > >> index ee7d0a5..cac1c97 100644 >> > >> --- a/drivers/mmc/host/tmio_mmc.c >> > >> +++ b/drivers/mmc/host/tmio_mmc.c >> > >> @@ -661,7 +661,7 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host, >> > >> data->blksz, data->blocks); >> > >> >> > >> /* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */ >> > >> - if (data->blksz < 4 && host->mmc->ios.bus_width == MMC_BUS_WIDTH_4) { >> > >> + if (data->blksz < 2 && host->mmc->ios.bus_width == MMC_BUS_WIDTH_4) { >> > >> pr_err("%s: %d byte block unsupported in 4 bit mode\n", >> > >> mmc_hostname(host->mmc), data->blksz); >> > >> return -EINVAL; >> > > >> > > Again, please provide a suitable description for this change. >> > I think the data size is not limited by MMC_BUS_WIDTH_x. >> > I confirmed that data transmission of 2Byte was performed without a problem. >> >> This patch hasn't been picked up. I'm assuming that's because Andrew is >> still unhappy with the changelog. > > Actually I don't know what happened with this. I merged it on July 8 > and appear to have dropped it on July 27, but I can't find its > removed-from-mm email so I don't know why I dropped it. Weird. > > Oh well, I merged it again. Is 2.6.37 an appropriate merge schedule? > > Also, I tend not to handle tmio_mmc patches - usually Paul patches that > driver. > >> Andrew, how about something like, >> >> "When running in 4-bit bus width mode, it is entirely possible to >> transfer data in block sizes of 2 bytes and larger. Relax the >> conditional check to allow 2-byte data block transfers which were >> previously disallowed." > > thanks. > >> Yusuke, have I interpreted your changelog correctly? Also note that >> your patch should remove the comment above the conditional that says, >> "Hardware cannot perform 1 and 2 byte requests in 4 bit mode". > > this? > > --- a/drivers/mmc/host/tmio_mmc.c~tmio_mmc-revise-a-limit-of-the-data-size-fix > +++ a/drivers/mmc/host/tmio_mmc.c > @@ -660,7 +660,6 @@ static int tmio_mmc_start_data(struct tm > pr_debug("setup data transfer: blocksize %08x nr_blocks %d\n", > data->blksz, data->blocks); > > - /* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */ > if (data->blksz < 2 && host->mmc->ios.bus_width == MMC_BUS_WIDTH_4) { > pr_err("%s: %d byte block unsupported in 4 bit mode\n", > mmc_hostname(host->mmc), data->blksz); > _ > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
