Adrian Hunter | 1 Jul 12:18 2010
Picon

Re: [PATCH V3 4/5] block: Add secure discard

Andrew Morton wrote:
> On Thu, 24 Jun 2010 11:44:23 +0300
> Adrian Hunter <adrian.hunter <at> nokia.com> wrote:
> 
>> >From b25b9a499f255ee5999c219525d82ef40382318c Mon Sep 17 00:00:00 2001
>> From: Adrian Hunter <adrian.hunter <at> nokia.com>
>> Date: Wed, 23 Jun 2010 15:41:38 +0300
>> Subject: [PATCH 4/5] block: Add secure discard
>>
>> Secure discard is the same as discard except that all copies
>> of the discarded sectors (perhaps created by garbage collection)
>> must also be erased.
> 
> That's not an awfully informative changelog.
> 
>>From a quick peek at the code it seems that you took your earlier
> design sketch:
> 
> On Mon, Jun 14, 2010 at 02:10:06PM +0300, Adrian Hunter wrote:
>> Needs a bio flag, a request flag, setup the request flag based on the
>> bio flag, prevent merging secure and non-secure discards, prevent drivers
>> doing non-secure discards for secure discards.
>>
>> Seems like a lot of little changes for something that no one wants.
>> Shouldn't it wait for someone to need it first?
> 
> and changed your mind and implemented it.
> 
> Is that a correct interpretation?
> 
(Continue reading)

Adrian Hunter | 1 Jul 12:49 2010
Picon

Re: [PATCH V3 1/5] mmc: Add erase, secure erase, trim and secure trim operations

Andrew Morton wrote:
> On Thu, 24 Jun 2010 11:44:00 +0300
> Adrian Hunter <adrian.hunter <at> nokia.com> wrote:
> 
>> SD/MMC cards tend to support an erase operation.  In addition,
>> eMMC v4.4 cards can support secure erase, trim and secure trim
>> operations that are all variants of the basic erase command.
> 
> The patch proposes a new userspace interface via sysfs, yes?
,
Just two read-only values

> 
> Please fully describe that interface and its operation in the
> changelog.  It'd also be nice to add permanent documentation for it.
> 

OK

>>From reading the code, it appears that erase_size and
> preferred_erase_size have units in bytes.  But users shouldn't need to
> read the code to find that out.  What are the alignemnt and size
> requirements on these?  What is their position in /sys?  What do they
> actually *do* and what is the difference between them?
> 
> etetera.  People want to review this code and other people actually
> want to use it.  I'm not sure that I want to try to review this code
> when nobody's told me what interface it implements and how it's
> supposed to work.  Seems that whoever implemented BLKDISCARD didn't
> want anyone to use it either.  Sigh.
(Continue reading)

Tony Lindgren | 1 Jul 14:32 2010

Re: [PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card detect

* kishore kadiyala <kishorek.kadiyala <at> gmail.com> [100621 09:49]:
> On Fri, Jun 18, 2010 at 1:49 AM, Andrew Morton
> <akpm <at> linux-foundation.org> wrote:
> > On Thu, 17 Jun 2010 20:56:58 +0530 (IST)
> > "kishore kadiyala" <kishore.kadiyala <at> ti.com> wrote:
> >
> >> --- a/arch/arm/plat-omap/include/plat/mmc.h
> >> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> >>  <at>  <at>  -43,6 +43,9  <at>  <at> 
> >>
> >>  #define OMAP_MMC_MAX_SLOTS   2
> >>
> >> +#define NON_GPIO             0
> >> +#define GPIO                 1
> >
> > I'm counting about seven different definitions of "GPIO" in the kernel
> > already.
> >
> > drivers/hwmon/it87.c:
> > #define GPIO    0x07
> >
> > drivers/media/dvb/dvb-usb/ec168.h:
> >        GPIO                 = 0x04,
> >
> > drivers/net/hamachi.c:
> >        GPIO=0x6E
> >
> > drivers/staging/rtl8187se/r8180_hw.h:
> > #define GPIO 0x91
> >
(Continue reading)

Tony Lindgren | 1 Jul 14:33 2010

Re: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller

* Andrew Morton <akpm <at> linux-foundation.org> [100617 23:09]:
> On Thu, 17 Jun 2010 20:57:19 +0530 (IST)
> "kishore kadiyala" <kishore.kadiyala <at> ti.com> wrote:
> 
> > Adding card detect callback function which gives the status of
> > the card .For MMC1 Controller, Card detect interrupt source is
> > twl6030 and card present/absent status is provided by MMCCTRL
> > register of twl6030.
> > 
> > Signed-off-by: Kishore Kadiyala <kishore.kadiyala <at> ti.com>
> > ---
> >  arch/arm/mach-omap2/board-4430sdp.c   |   11 +++++--
> >  arch/arm/mach-omap2/hsmmc.c           |    1 +
> >  arch/arm/plat-omap/include/plat/mmc.h |    1 +
> >  drivers/mfd/twl6030-irq.c             |   23 ++++++++++++++++
> >  drivers/mmc/host/omap_hsmmc.c         |   30 ++++++++++++++++++---
> >  include/linux/i2c/twl.h               |   46 +++++++++++++++++++++++++++++++++
> >  6 files changed, 104 insertions(+), 8 deletions(-)
> 
> I assume this depends on "[PATCH v5 1/2] OMAP HSMMC: Adding a Flag to
> determine the type of Card detect"?
> 
> It's all a bit too remote from my (ever-expanding) work area, so I'll
> assume that Tony or someone will look after these.

Yeah we'll queue these via the omap patches once everybody is
happy with them.

Regards,

(Continue reading)

Lars-Peter Clausen | 1 Jul 17:45 2010
Picon

Re: [PATCH v3] MMC: Add JZ4740 mmc driver


Hi

Andrew Morton wrote:
> On Mon, 28 Jun 2010 03:20:41 +0200
> Lars-Peter Clausen <lars <at> metafoo.de> wrote:
> 
>> This patch adds support for the mmc controller on JZ4740 SoCs.
>>
>> Signed-off-by: Lars-Peter Clausen <lars <at> metafoo.de>
>> Cc: Andrew Morton <akpm <at> linux-foundation.org>
>> Cc: Matt Fleming <matt <at> console-pimps.org>
>> Cc: linux-mmc <at> vger.kernel.org
>>
>> ...
>>
>> +#define JZ4740_MMC_MAX_TIMEOUT 10000000
> 
> That was a really big timeout.  How long do 1e7 readw's take?  Oh well.
> 

Hm, right. It doesn't hurt though. I'll do some tests and to try to come up with a
more realistic value.

>> ...
>>
>> +static void jz4740_mmc_clock_disable(struct jz4740_mmc_host *host)
>> +{
>> +	uint32_t status;
>> +
(Continue reading)

Lars-Peter Clausen | 1 Jul 17:47 2010
Picon

Re: [PATCH v3] MMC: Add JZ4740 mmc driver


Matt Fleming wrote:
> On Mon, 28 Jun 2010 03:20:41 +0200, Lars-Peter Clausen <lars <at> metafoo.de> wrote:
>> This patch adds support for the mmc controller on JZ4740 SoCs.
>>
>> Signed-off-by: Lars-Peter Clausen <lars <at> metafoo.de>
>> Cc: Andrew Morton <akpm <at> linux-foundation.org>
>> Cc: Matt Fleming <matt <at> console-pimps.org>
>> Cc: linux-mmc <at> vger.kernel.org
>>
>> ---
>> Changes since v1
>> - Do not request IRQ with IRQF_DISABLED since it is a noop now
>> - Use a generous slack for the timeout timer. It does not need to be accurate.
>> Changes since v2
>> - Use sg_mapping_to iterate over sg elements in mmc read and write functions
>> - Use bitops instead of a spinlock and a variable for testing whether a request
>>   has been finished.
>> - Rework irq and timeout handling in order to get rid of locking in hot paths
> 
> Acked-by: Matt Fleming <matt <at> console-pimps.org>
> 
> Are you planning on maintaining this driver? If so, it'd be a good idea
> to update MAINTAINERS.

Hi

Thanks for reviewing the patch.
I guess I should send a MAINTAINERS patch which adds entries for all of the JZ4740
drivers.
(Continue reading)

Andrew Morton | 1 Jul 22:48 2010

Re: [PATCH 3/3] sdhci-pltfm: Add support for CNS3xxx SoC devices

On Fri, 25 Jun 2010 22:06:44 +0400
Anton Vorontsov <avorontsov <at> mvista.com> wrote:

> There's nothing special, just SoC-specific ops and quirks.
> 
> ...
>
> +static void sdhci_cns3xxx_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> +	struct device *dev = mmc_dev(host->mmc);
> +	int div = 1;
> +	u16 clk;
> +	unsigned long timeout;
> +
> +	if (clock == host->clock)
> +		return;

I assume that mmc core prevents this function from being exectued twice
at the same time?

> +	sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> +	if (clock == 0)
> +		goto out;
> +
> +	while (host->max_clk / div > clock) {
> +		/*
> +		 * On CNS3xxx divider grows linearly up to 4, and then
> +		 * exponentially up to 256.
> +		 */
(Continue reading)

akpm | 1 Jul 22:51 2010

+ sdhci-pltfm-reorganize-makefile-entries-to-support-soc-devices.patch added to -mm tree


The patch titled
     sdhci-pltfm: reorganize Makefile entries to support SoC devices
has been added to the -mm tree.  Its filename is
     sdhci-pltfm-reorganize-makefile-entries-to-support-soc-devices.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: sdhci-pltfm: reorganize Makefile entries to support SoC devices
From: Anton Vorontsov <avorontsov <at> mvista.com>

Due to build system limitations, intermediate and final objects can't have
the same names.  And as we're going to start building SoC-specific
objects, let's rename the module to sdhci-platform, into which we'll link
sdhci-pltfm and SoC-specifc objects.

There should be no issue in renaming as the driver uses modalias
mechanism.
(Continue reading)

akpm | 1 Jul 22:51 2010

+ sdhci-pltfm-switch-to-module-device-table-matching.patch added to -mm tree


The patch titled
     sdhci-pltfm: switch to module device table matching
has been added to the -mm tree.  Its filename is
     sdhci-pltfm-switch-to-module-device-table-matching.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: sdhci-pltfm: switch to module device table matching
From: Anton Vorontsov <avorontsov <at> mvista.com>

Sometimes want to place SoC-specific parts alongside with the generic
driver, and to do so, we have to switch the driver over to the module
device table matching.

Note that drivers/mmc/host/sdhci-pltfm.h is so far empty, but it'll hold
SoC-specific driver data handlers soon.

(Continue reading)

akpm | 2 Jul 00:31 2010

+ omap-pandora-pass-wl1251-information-to-sdio-core.patch added to -mm tree


The patch titled
     omap: pandora: pass wl1251 information to SDIO core
has been added to the -mm tree.  Its filename is
     omap-pandora-pass-wl1251-information-to-sdio-core.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: omap: pandora: pass wl1251 information to SDIO core
From: Grazvydas Ignotas <notasas <at> gmail.com>

Pandora has TI WL1251 attached on MMC3, which is non-standard SDIO chip.
Make use MMC_QUIRK_NONSTD_SDIO to tell SDIO core about it.

Signed-off-by: Grazvydas Ignotas <notasas <at> gmail.com>
Cc: Adrian Hunter <adrian.hunter <at> nokia.com>
Cc: Tony Lindgren <tony <at> atomide.com>
Cc: Bob Copeland <me <at> bobcopeland.com>
(Continue reading)


Gmane