[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090918143054.a6cf31f7.akpm@linux-foundation.org>
Date: Fri, 18 Sep 2009 14:30:54 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Frysinger <vapier@...too.org>
Cc: spi-devel-general@...ts.sourceforge.net,
dbrownell@...rs.sourceforge.net, linux-kernel@...r.kernel.org,
yi.li@...log.com
Subject: Re: [PATCH 2/2 v2] mmc_spi: lock the SPI bus when accessing the
card
On Thu, 17 Sep 2009 20:52:14 -0400
Mike Frysinger <vapier@...too.org> wrote:
> From: Yi Li <yi.li@...log.com>
>
> The MMC/SPI spec does not play well with typical SPI design -- it often
> needs to send out a command in one message, read a response, then do some
> other arbitrary step. Since we can't let another SPI client use the bus
> during this time, use the new SPI lock/unlock functions to provide the
> required exclusivity.
>
> Signed-off-by: Yi Li <yi.li@...log.com>
> Signed-off-by: Mike Frysinger <vapier@...too.org>
> ---
> v2
> - drop now unused maybe_count_child as pointed out by H Hartley Sweeten
>
> drivers/mmc/host/mmc_spi.c | 41 ++---------------------------------------
> 1 files changed, 2 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index a461017..c3563a7 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -1084,6 +1084,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
> #endif
>
> /* issue command; then optionally data and stop */
> + spi_lock_bus(host->spi);
> status = mmc_spi_command_send(host, mrq, mrq->cmd, mrq->data != NULL);
> if (status == 0 && mrq->data) {
> mmc_spi_data_do(host, mrq->cmd, mrq->data, mrq->data->blksz);
> @@ -1092,7 +1093,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
> else
> mmc_cs_off(host);
> }
> -
> + spi_unlock_bus(host->spi);
> mmc_request_done(host->mmc, mrq);
I can't find any code anywhere which puts a non-zero value into
spi_master.[un]lock_bus so in my tree at least, neither of these
patches do anything.
This makes it all a bit hard to understand and review.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists