| 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
| ||
|
Message-ID: <CAAfSe-vWDFw3zr-MyKhmbAEBAz1XZpOM3icyKdPiKj_SFFsK=g@mail.gmail.com>
Date: Wed, 4 Jul 2018 11:03:05 +0800
From: Chunyan Zhang <zhang.lyra@...il.com>
To: Adrian Hunter <adrian.hunter@...el.com>
Cc: Chunyan Zhang <zhang.chunyan@...aro.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
linux-mmc@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...aro.org>,
Billows Wu <billows.wu@...eadtrum.com>
Subject: Re: [PATCH V2 3/7] mmc: sdhci: add ADMA2 64-bit addressing support
for V4 mode
On 21 June 2018 at 21:20, Adrian Hunter <adrian.hunter@...el.com> wrote:
> On 15/06/18 05:04, Chunyan Zhang wrote:
>> ADMA2 64-bit addressing support is divided into V3 mode and V4 mode.
>> So there are two kinds of descriptors for ADMA2 64-bit addressing
>> i.e. 96-bit Descriptor for V3 mode, and 128-bit Descriptor for V4
>> mode. 128-bit Descriptor is aligned to 8-byte.
>>
>> For V4 mode, ADMA2 64-bit addressing is enabled via Host Control 2
>> register.
>>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@...aro.org>
>> ---
>> drivers/mmc/host/sdhci.c | 50 +++++++++++++++++++++++++++++++++++-------------
>> drivers/mmc/host/sdhci.h | 23 +++++++++++++++++-----
>> 2 files changed, 55 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index f57201f..5d3b0d8 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -585,6 +585,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>> void *desc, *align;
>> char *buffer;
>> int len, offset, i;
>> + unsigned int adma2_align = SDHCI_ADMA2_ALIGN(host);
>> + unsigned int adma2_mask = SDHCI_ADMA2_MASK(host);
>>
>> /*
>> * The spec does not specify endianness of descriptor table.
>> @@ -608,8 +610,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>> * buffer for the (up to three) bytes that screw up the
>> * alignment.
>> */
>> - offset = (SDHCI_ADMA2_ALIGN - (addr & SDHCI_ADMA2_MASK)) &
>> - SDHCI_ADMA2_MASK;
>> + offset = (adma2_align - (addr & adma2_align)) &
>> + adma2_mask;
>> if (offset) {
>> if (data->flags & MMC_DATA_WRITE) {
>> buffer = sdhci_kmap_atomic(sg, &flags);
>> @@ -623,8 +625,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>>
>> BUG_ON(offset > 65536);
>>
>> - align += SDHCI_ADMA2_ALIGN;
>> - align_addr += SDHCI_ADMA2_ALIGN;
>> + align += adma2_align;
>> + align_addr += adma2_align;
>>
>> desc += host->desc_sz;
>>
>> @@ -668,13 +670,15 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
>> void *align;
>> char *buffer;
>> unsigned long flags;
>> + unsigned int adma2_align = SDHCI_ADMA2_ALIGN(host);
>> + unsigned int adma2_mask = SDHCI_ADMA2_MASK(host);
>>
>> if (data->flags & MMC_DATA_READ) {
>> bool has_unaligned = false;
>>
>> /* Do a quick scan of the SG list for any unaligned mappings */
>> for_each_sg(data->sg, sg, host->sg_count, i)
>> - if (sg_dma_address(sg) & SDHCI_ADMA2_MASK) {
>> + if (sg_dma_address(sg) & adma2_mask) {
>> has_unaligned = true;
>> break;
>> }
>> @@ -686,15 +690,15 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
>> align = host->align_buffer;
>>
>> for_each_sg(data->sg, sg, host->sg_count, i) {
>> - if (sg_dma_address(sg) & SDHCI_ADMA2_MASK) {
>> - size = SDHCI_ADMA2_ALIGN -
>> - (sg_dma_address(sg) & SDHCI_ADMA2_MASK);
>> + if (sg_dma_address(sg) & adma2_mask) {
>> + size = adma2_align -
>> + (sg_dma_address(sg) & adma2_mask);
>>
>> buffer = sdhci_kmap_atomic(sg, &flags);
>> memcpy(buffer, align, size);
>> sdhci_kunmap_atomic(buffer, &flags);
>>
>> - align += SDHCI_ADMA2_ALIGN;
>> + align += adma2_align;
>> }
>> }
>> }
>> @@ -3400,6 +3404,26 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host *host)
>> return 0;
>> }
>>
>> +static inline bool sdhci_use_64bit_dma(struct sdhci_host *host)
>> +{
>> + u32 addr64bit_en;
>> +
>> + /*
>> + * According to SD Host Controller spec v4.10, bit[27] added from
>> + * version 4.10 in Capabilities Register is used as 64-bit System
>> + * Address support for V4 mode, 64-bit DMA Addressing for V4 mode
>> + * is enabled only if 64-bit Addressing =1 in the Host Control 2
>> + * register.
>> + */
>> + if (host->version == SDHCI_SPEC_410 && host->v4_mode) {
>> + addr64bit_en = (sdhci_readw(host, SDHCI_HOST_CONTROL2) &
>> + SDHCI_CTRL_64BIT_ADDR);
>
> This seems the wrong way around. SDHCI_CTRL_64BIT_ADDR should be set based
> on the driver's requirements, not read to determine what the driver will do.
It was actually set based on the host controller driver's
configuration, the driver can determine by setting bit[13] (i.e.
SDHCI_CTRL_64BIT_ADDR) in the register SDHCI_HOST_CONTROL2 or not.
I probably have got your point, but why don't we leave this register
for vender's controller driver to set?
>From what I noticed (maybe missing something), whether use 64bit or
not is determined in the initialization (set SDHCI_USE_64_BIT_DMA to
host->flags) and could not be changed afterward, but every time send
data, the register SDHCI_HOST_CONTROL (in case of v4.10
SDHCI_HOST_CONTROL2 it is) would be set, my question is what was the
reason we chose to do in this way rather than letting drivers to set
this register before sdhci_setup_host(), since in the latter way,
there's no need to write this register every time before sending
command.
>
> Can you clarify what SDHCI_CTRL_64BIT_ADDR is for?
bit[13] in the register SDHCI_HOST_CONTROL2.
>
>
>> + return addr64bit_en && (host->caps & SDHCI_CAN_64BIT_V4);
>> + }
>> +
>> + return host->caps & SDHCI_CAN_64BIT;
>> +}
>> +
>> int sdhci_setup_host(struct sdhci_host *host)
>> {
>> struct mmc_host *mmc;
>> @@ -3471,7 +3495,7 @@ int sdhci_setup_host(struct sdhci_host *host)
>> * SDHCI_QUIRK2_BROKEN_64_BIT_DMA must be left to the drivers to
>> * implement.
>> */
>> - if (host->caps & SDHCI_CAN_64BIT)
>> + if (sdhci_use_64bit_dma(host))
>> host->flags |= SDHCI_USE_64_BIT_DMA;
>>
>> if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
>> @@ -3505,15 +3529,15 @@ int sdhci_setup_host(struct sdhci_host *host)
>> */
>> if (host->flags & SDHCI_USE_64_BIT_DMA) {
>> host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
>> - SDHCI_ADMA2_64_DESC_SZ;
>> - host->desc_sz = SDHCI_ADMA2_64_DESC_SZ;
>> + SDHCI_ADMA2_64_DESC_SZ(host);
>> + host->desc_sz = SDHCI_ADMA2_64_DESC_SZ(host);
>> } else {
>> host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
>> SDHCI_ADMA2_32_DESC_SZ;
>> host->desc_sz = SDHCI_ADMA2_32_DESC_SZ;
>> }
>>
>> - host->align_buffer_sz = SDHCI_MAX_SEGS * SDHCI_ADMA2_ALIGN;
>> + host->align_buffer_sz = SDHCI_MAX_SEGS * SDHCI_ADMA2_ALIGN(host);
>> buf = dma_alloc_coherent(mmc_dev(mmc), host->align_buffer_sz +
>> host->adma_table_sz, &dma, GFP_KERNEL);
>
> This needs to be dma_zalloc_coherent to ensure that the unused 4-bytes in
> each 16-byte descriptor is zero.
Oh right, I will address.
>
>> if (!buf) {
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 128b0ba..820a863 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -185,6 +185,7 @@
>> #define SDHCI_CTRL_EXEC_TUNING 0x0040
>> #define SDHCI_CTRL_TUNED_CLK 0x0080
>> #define SDHCI_CTRL_V4_MODE 0x1000
>> +#define SDHCI_CTRL_64BIT_ADDR 0x2000
>> #define SDHCI_CTRL_PRESET_VAL_ENABLE 0x8000
>>
>> #define SDHCI_CAPABILITIES 0x40
>> @@ -206,6 +207,7 @@
>> #define SDHCI_CAN_VDD_300 0x02000000
>> #define SDHCI_CAN_VDD_180 0x04000000
>> #define SDHCI_CAN_64BIT 0x10000000
>> +#define SDHCI_CAN_64BIT_V4 0x8000000
>
> Please make it 8 digits and put it in the right numerical order
Ok.
>
>>
>> #define SDHCI_SUPPORT_SDR50 0x00000001
>> #define SDHCI_SUPPORT_SDR104 0x00000002
>> @@ -297,9 +299,14 @@ struct sdhci_adma2_32_desc {
>> __le32 addr;
>> } __packed __aligned(4);
>>
>> -/* ADMA2 data alignment */
>> -#define SDHCI_ADMA2_ALIGN 4
>> -#define SDHCI_ADMA2_MASK (SDHCI_ADMA2_ALIGN - 1)
>> +/*
>> + * ADMA2 data alignment
>> + * According to SD Host Controller spec v4.10, if Host Version 4 Enable is set
>> + * in the Host Control 2 register, 128-bit Descriptor will be selected which
>> + * shall be aligned 8-byte address boundary.
>> + */
>> +#define SDHCI_ADMA2_ALIGN(host) ((host)->v4_mode ? 8 : 4)
>> +#define SDHCI_ADMA2_MASK(host) (SDHCI_ADMA2_ALIGN(host) - 1)
>
> Are you really sure about that, because it reads like it is still 4-byte
> alignment for data and 8-byte alignment for descriptors, which is what we
> already do.
Oh, right, my mistake.
Thanks for your review,
Chunyan
>
>>
>> /*
>> * ADMA2 descriptor alignment. Some controllers (e.g. Intel) require 8 byte
>> @@ -308,8 +315,14 @@ struct sdhci_adma2_32_desc {
>> */
>> #define SDHCI_ADMA2_DESC_ALIGN 8
>>
>> -/* ADMA2 64-bit DMA descriptor size */
>> -#define SDHCI_ADMA2_64_DESC_SZ 12
>> +/*
>> + * ADMA2 64-bit DMA descriptor size
>> + * According to SD Host Controller spec v4.10, there are two kinds of
>> + * descriptors for 64-bit addressing mode: 96-bit Descriptor and 128-bit
>> + * Descriptor, if Host Version 4 Enable is set in the Host Control 2
>> + * register, 128-bit Descriptor will be selected.
>> + */
>> +#define SDHCI_ADMA2_64_DESC_SZ(host) ((host)->v4_mode ? 16 : 12)
>>
>> /*
>> * ADMA2 64-bit descriptor. Note 12-byte descriptor can't always be 8-byte
>>
>
Powered by blists - more mailing lists