linux-kernel - Re: [PATCH v1 11/11] mmc: mmci: Add Qcom specific pio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 May 2014 10:34:27 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:	Russell King <linux@....linux.org.uk>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Chris Ball <chris@...ntf.net>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	agross@...cinc.com,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v1 11/11] mmc: mmci: Add Qcom specific pio_read function.

On Tue, Apr 29, 2014 at 10:21 AM,  <srinivas.kandagatla@...aro.org> wrote:

> From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>
> MCIFIFOCNT register behaviour on Qcom chips is very different than the other
> pl180 integrations. MCIFIFOCNT register contains the number of
> words that are still waiting to be transferred through the FIFO. It keeps
> decrementing once the host CPU reads the MCIFIFO. With the existing logic and
> the MCIFIFOCNT behaviour, mmci_pio_read will loop forever, as the FIFOCNT
> register will always return transfer size before reading the FIFO.
>
> Also the data sheet states that "This register is only useful for debug
> purposes and should not be used for normal operation since it does not reflect
> data which may or may not be in the pipeline".
>
> This patch implements qcom_pio_read function so as existing mmci_pio_read is
> not suitable for Qcom SOCs.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
(...)

> +static int mmci_qcom_pio_read(struct mmci_host *host, char *buffer,
> +                        unsigned int remain)
> +{
> +       uint32_t        *ptr = (uint32_t *) buffer;

Just use u32 for this.

> +       int             count = 0;
> +       struct variant_data *variant = host->variant;
> +       int             fifo_size = variant->fifosize;
> +
> +       if (remain % 4)
> +               remain = ((remain >> 2) + 1) << 2;

Explain in a comment exactly what is happening here or noone will
understand the code.

> +       while (readl(host->base + MMCISTATUS) & MCI_RXDATAAVLBL) {
> +               *ptr = readl(host->base + MMCIFIFO + (count % fifo_size));
> +               ptr++;
> +               count += sizeof(uint32_t);
> +               remain -=  sizeof(uint32_t);


sizeof(u32) or just 4 works for these...

count += 4;
remain -= 4;

Is easier to parse and understand I think.

> +               if (remain == 0)
> +                       break;

if (!remain)
  break;

> +       }
> +       return count;
> +}

> -               if (status & MCI_RXACTIVE)
> -                       len = mmci_pio_read(host, buffer, remain);
> +               if (status & MCI_RXACTIVE) {
> +                       if (host->hw_designer == AMBA_VENDOR_QCOM)
> +                               len = mmci_qcom_pio_read(host, buffer, remain);
> +                       else
> +                               len = mmci_pio_read(host, buffer, remain);
> +               }

Use something like bool qcom_fifo; in vendor data instead.

Yours,
Linus Walleij
--
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/