[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100112153657.f3474ab8.akpm@linux-foundation.org>
Date: Tue, 12 Jan 2010 15:36:57 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Chaithrika U S <chaithrika@...com>
Cc: linux-kernel@...r.kernel.org,
davinci-linux-open-source@...ux.davincidsp.com,
khilman@...prootsystems.com
Subject: Re: [PATCH v3 1/2] davinci: MMC: Add a function to control reset
state of the controller
On Fri, 8 Jan 2010 17:08:49 +0530
Chaithrika U S <chaithrika@...com> wrote:
> -static void
> -davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data)
> +static inline void mmc_davinci_reset_ctrl(struct mmc_davinci_host *host,
> + int val)
> {
> u32 temp;
>
> - /* reset command and data state machines */
> temp = readl(host->base + DAVINCI_MMCCTL);
> - writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST,
> - host->base + DAVINCI_MMCCTL);
> + if (val) /* reset */
> + temp |= MMCCTL_CMDRST | MMCCTL_DATRST;
> + else /* enable */
> + temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST);
>
> - temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST);
> - udelay(10);
> writel(temp, host->base + DAVINCI_MMCCTL);
> + udelay(10);
> +}
nit: it's hard for a reader of the code to work out why a udelay() such
as the above was included. Perhaps the data sheet for the hardware
would tell him, if he has access to it.
But generally speaking, the code is better code if it explains the
reasoning to the reader.
--
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