| Message ID | 20210128063035.15674-1-bmeng.cn@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/sd: Support block read/write in SPI mode | expand |
On Thu, Jan 28, 2021 at 2:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > From: Bin Meng <bin.meng@windriver.com> > > This includes the previously v3 series [1], and one single patch [2]. > > Compared to v3, this fixed the following issue in patch [v3,6/6]: > - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > receiving the STOP_TRAN token per the spec > > All software tested so far (U-Boot/Linux/VxWorks) do work without > the fix, but it is better to comform with the spec. > > In addition to [2], one more issue was exposed when testing with > VxWorks driver related to STOP_TRANSMISSION (CMD12) response. > > [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 > [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ > > Changes in v4: > - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > receiving the STOP_TRAN token per the spec > - new patch: fix STOP_TRANSMISSION (CMD12) response > - new patch: handle the rest commands with R1b response type > Ping?
Hi Philippe, On Thu, Feb 4, 2021 at 2:02 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Thu, Jan 28, 2021 at 2:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > From: Bin Meng <bin.meng@windriver.com> > > > > This includes the previously v3 series [1], and one single patch [2]. > > > > Compared to v3, this fixed the following issue in patch [v3,6/6]: > > - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > > receiving the STOP_TRAN token per the spec > > > > All software tested so far (U-Boot/Linux/VxWorks) do work without > > the fix, but it is better to comform with the spec. > > > > In addition to [2], one more issue was exposed when testing with > > VxWorks driver related to STOP_TRANSMISSION (CMD12) response. > > > > [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 > > [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ > > > > Changes in v4: > > - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > > receiving the STOP_TRAN token per the spec > > - new patch: fix STOP_TRANSMISSION (CMD12) response > > - new patch: handle the rest commands with R1b response type > > > > Ping? Will a PR be sent soon to include this series so that the SiFive SPI series can follow? Regards, Bin
On 2/9/21 3:32 PM, Bin Meng wrote: > Hi Philippe, > > On Thu, Feb 4, 2021 at 2:02 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> On Thu, Jan 28, 2021 at 2:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> From: Bin Meng <bin.meng@windriver.com> >>> >>> This includes the previously v3 series [1], and one single patch [2]. >>> >>> Compared to v3, this fixed the following issue in patch [v3,6/6]: >>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after >>> receiving the STOP_TRAN token per the spec >>> >>> All software tested so far (U-Boot/Linux/VxWorks) do work without >>> the fix, but it is better to comform with the spec. >>> >>> In addition to [2], one more issue was exposed when testing with >>> VxWorks driver related to STOP_TRANSMISSION (CMD12) response. >>> >>> [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 >>> [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ >>> >>> Changes in v4: >>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after >>> receiving the STOP_TRAN token per the spec >>> - new patch: fix STOP_TRANSMISSION (CMD12) response >>> - new patch: handle the rest commands with R1b response type >>> >> >> Ping? > > Will a PR be sent soon to include this series so that the SiFive SPI > series can follow? I had it planned for yesterday but had problems with the mails from the list, + the CVE (you fixed) took priority. Missing review is patch #8 "Fix STOP_TRANSMISSION (CMD12) response" for which I don't have test yet.
On Wed, Feb 10, 2021 at 1:36 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 2/9/21 3:32 PM, Bin Meng wrote: > > Hi Philippe, > > > > On Thu, Feb 4, 2021 at 2:02 PM Bin Meng <bmeng.cn@gmail.com> wrote: > >> > >> On Thu, Jan 28, 2021 at 2:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: > >>> > >>> From: Bin Meng <bin.meng@windriver.com> > >>> > >>> This includes the previously v3 series [1], and one single patch [2]. > >>> > >>> Compared to v3, this fixed the following issue in patch [v3,6/6]: > >>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > >>> receiving the STOP_TRAN token per the spec > >>> > >>> All software tested so far (U-Boot/Linux/VxWorks) do work without > >>> the fix, but it is better to comform with the spec. > >>> > >>> In addition to [2], one more issue was exposed when testing with > >>> VxWorks driver related to STOP_TRANSMISSION (CMD12) response. > >>> > >>> [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 > >>> [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ > >>> > >>> Changes in v4: > >>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after > >>> receiving the STOP_TRAN token per the spec > >>> - new patch: fix STOP_TRANSMISSION (CMD12) response > >>> - new patch: handle the rest commands with R1b response type > >>> > >> > >> Ping? > > > > Will a PR be sent soon to include this series so that the SiFive SPI > > series can follow? > > I had it planned for yesterday but had problems with the mails from > the list, + the CVE (you fixed) took priority. > > Missing review is patch #8 "Fix STOP_TRANSMISSION (CMD12) response" > for which I don't have test yet. Ping? If there is any comment for patch #8? Regards, Bin
On 2/16/21 12:53 PM, Bin Meng wrote: > On Wed, Feb 10, 2021 at 1:36 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> On 2/9/21 3:32 PM, Bin Meng wrote: >>> Hi Philippe, >>> >>> On Thu, Feb 4, 2021 at 2:02 PM Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>>> On Thu, Jan 28, 2021 at 2:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> >>>>> From: Bin Meng <bin.meng@windriver.com> >>>>> >>>>> This includes the previously v3 series [1], and one single patch [2]. >>>>> >>>>> Compared to v3, this fixed the following issue in patch [v3,6/6]: >>>>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after >>>>> receiving the STOP_TRAN token per the spec >>>>> >>>>> All software tested so far (U-Boot/Linux/VxWorks) do work without >>>>> the fix, but it is better to comform with the spec. >>>>> >>>>> In addition to [2], one more issue was exposed when testing with >>>>> VxWorks driver related to STOP_TRANSMISSION (CMD12) response. >>>>> >>>>> [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 >>>>> [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ >>>>> >>>>> Changes in v4: >>>>> - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after >>>>> receiving the STOP_TRAN token per the spec >>>>> - new patch: fix STOP_TRANSMISSION (CMD12) response >>>>> - new patch: handle the rest commands with R1b response type >>>>> >>>> >>>> Ping? >>> >>> Will a PR be sent soon to include this series so that the SiFive SPI >>> series can follow? >> >> I had it planned for yesterday but had problems with the mails from >> the list, + the CVE (you fixed) took priority. >> >> Missing review is patch #8 "Fix STOP_TRANSMISSION (CMD12) response" >> for which I don't have test yet. > > Ping? If there is any comment for patch #8? No more comment, series applied to sdmmc-next tree. Thanks, Phil.
From: Bin Meng <bin.meng@windriver.com> This includes the previously v3 series [1], and one single patch [2]. Compared to v3, this fixed the following issue in patch [v3,6/6]: - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after receiving the STOP_TRAN token per the spec All software tested so far (U-Boot/Linux/VxWorks) do work without the fix, but it is better to comform with the spec. In addition to [2], one more issue was exposed when testing with VxWorks driver related to STOP_TRANSMISSION (CMD12) response. [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226136 [2] http://patchwork.ozlabs.org/project/qemu-devel/patch/1611636214-52427-1-git-send-email-bmeng.cn@gmail.com/ Changes in v4: - Keep the card state to SSI_SD_CMD instead of SSI_SD_RESPONSE after receiving the STOP_TRAN token per the spec - new patch: fix STOP_TRANSMISSION (CMD12) response - new patch: handle the rest commands with R1b response type Bin Meng (9): hw/sd: ssi-sd: Support multiple block read hw/sd: sd: Remove duplicated codes in single/multiple block read/write hw/sd: sd: Allow single/multiple block write for SPI mode hw/sd: Introduce receive_ready() callback hw/sd: ssi-sd: Support single block write hw/sd: ssi-sd: Support multiple block write hw/sd: ssi-sd: Fix SEND_IF_COND (CMD8) response hw/sd: ssi-sd: Fix STOP_TRANSMISSION (CMD12) response hw/sd: ssi-sd: Handle the rest commands with R1b response type include/hw/sd/sd.h | 2 + hw/sd/core.c | 13 +++++ hw/sd/sd.c | 56 ++----------------- hw/sd/ssi-sd.c | 136 ++++++++++++++++++++++++++++++++++++++------- 4 files changed, 137 insertions(+), 70 deletions(-)