On Thu, Jun 24, 2021 at 10:28 PM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
Reviewed-by: Bin Meng
On Thu, Jun 24, 2021 at 10:29 PM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
Reviewed-by: Bin Meng
On Thu, Jun 24, 2021 at 10:23 PM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
Reviewed-by: Bin Meng
On Thu, Jun 24, 2021 at 10:28 PM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 0215bdb3689..2647fd26566 100644
> --- a/hw/s
enable(SDState *sd, bool enable)
>
> static const SDProto sd_proto_spi = {
> .name = "SPI",
> +.cmd = {
> +[2 ... 4] = sd_cmd_illegal,
> +[5] = sd_cmd_illegal,
Above 2 can be merged into [2 ... 5]
> +[7] = sd_cmd_illegal,
> +[15]= sd_cmd_illegal,
> +[26]= sd_cmd_illegal,
> +[52 ... 54] = sd_cmd_illegal,
> +},
> };
>
> static const SDProto sd_proto_sd = {
> .name = "SD",
> +.cmd = {
> +[1] = sd_cmd_illegal,
> +[5] = sd_cmd_illegal,
> +[52 ... 54] = sd_cmd_illegal,
> +[58]= sd_cmd_illegal,
> +[59]= sd_cmd_illegal,
> +},
> };
>
> static void sd_instance_init(Object *obj)
Otherwise LGTM:
Reviewed-by: Bin Meng
rrent code base.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 13 +
> 1 file changed, 13 insertions(+)
>
Reviewed-by: Bin Meng
+++
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
Reviewed-by: Bin Meng
dé
> ---
> hw/sd/sd.c | 32
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
Reviewed-by: Bin Meng
reuse this code, extract as sd_invalid_state_for_cmd()
> helper.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sd.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
On Wed, Jun 23, 2021 at 4:55 PM Cédric Le Goater wrote:
>
> On 6/23/21 10:39 AM, Bin Meng wrote:
> > On Wed, Jun 23, 2021 at 4:30 PM Cédric Le Goater wrote:
> >>
> >> The number of blocks is defined in the lower bits [15:0]
> >
> > I checked the physi
On Wed, Jun 23, 2021 at 4:52 PM Philippe Mathieu-Daudé wrote:
>
> On 6/23/21 10:39 AM, Bin Meng wrote:
> > On Wed, Jun 23, 2021 at 4:30 PM Cédric Le Goater wrote:
> >>
> >> The number of blocks is defined in the lower bits [15:0]
> >
> > I checked the
On Wed, Jun 23, 2021 at 4:30 PM Cédric Le Goater wrote:
>
> The number of blocks is defined in the lower bits [15:0]
I checked the physical spec v8.00 and it says bits [31:0] for CMD23 argument.
>
> Signed-off-by: Cédric Le Goater
> ---
> hw/sd/sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Daudé
> ---
> hw/ide/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Hi Cédric,
On Tue, Apr 27, 2021 at 10:32 PM Cédric Le Goater wrote:
>
> Hello,
>
> On 4/27/21 10:54 AM, Francisco Iglesias wrote:
> > On [2021 Apr 27] Tue 15:56:10, Alistair Francis wrote:
> >> On Fri, Apr 23, 2021 at 4:46 PM Bin Meng wrote:
> >>>
> &g
On Mon, Feb 8, 2021 at 10:41 PM Bin Meng wrote:
>
> On Thu, Jan 21, 2021 at 10:18 PM Francisco Iglesias
> wrote:
> >
> > Hi Bin,
> >
> > On [2021 Jan 21] Thu 16:59:51, Bin Meng wrote:
> > > Hi Francisco,
> > >
> > > On
On Tue, Mar 16, 2021 at 9:39 AM Bin Meng wrote:
>
> On Thu, Mar 11, 2021 at 4:18 PM Bin Meng wrote:
> >
> > On Sat, Mar 6, 2021 at 2:01 PM Bin Meng wrote:
> > >
> > > From: Bin Meng
> > >
> > > Per SST25VF016B datasheet [1], SST flash req
On Thu, Mar 11, 2021 at 4:18 PM Bin Meng wrote:
>
> On Sat, Mar 6, 2021 at 2:01 PM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > Per SST25VF016B datasheet [1], SST flash requires a dummy byte after
> > the address bytes. Note only SPI mode is supported by
On Sat, Mar 6, 2021 at 2:01 PM Bin Meng wrote:
>
> From: Bin Meng
>
> Per SST25VF016B datasheet [1], SST flash requires a dummy byte after
> the address bytes. Note only SPI mode is supported by SST flashes.
>
> [1] http://ww1.microchip.com/downloads/en/devicedoc/s71271_04.
+++---
> hw/block/trace-events | 41 -
> 3 files changed, 95 insertions(+), 105 deletions(-)
>
Reviewed-by: Bin Meng
oracle.com>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi01.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
k/pflash_cfi02.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
Reviewed-by: Bin Meng
On Thu, Mar 11, 2021 at 1:22 AM Philippe Mathieu-Daudé
wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi02.c | 8
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Bin Meng
On Thu, Mar 11, 2021 at 1:37 AM Philippe Mathieu-Daudé
wrote:
>
> The same pattern is used when setting the flash in READ_ARRAY mode:
> - Set the state machine command to READ_ARRAY
> - Reset the write_cycle counter
> - Reset the memory region in ROMD
>
> Refactor the current code by extracting th
se' case.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi02.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
On Wed, Mar 10, 2021 at 7:55 AM Philippe Mathieu-Daudé
wrote:
>
> There is multiple places doing a device reset. Factor that
> out in a common method which matches the DeviceReset prototype,
> so we can also remove the reset code from the DeviceRealize()
> handler. Explicit the device is set in "r
lash_cfi01.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
t; hw/block/pflash_cfi02.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
athieu-Daudé
> ---
> hw/block/pflash_cfi02.c | 18 +-
> hw/block/trace-events | 1 +
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
Reviewed-by: Bin Meng
---
> 1 file changed, 73 insertions(+), 67 deletions(-)
>
Reviewed-by: Bin Meng
---
> 1 file changed, 99 insertions(+), 94 deletions(-)
>
Reviewed-by: Bin Meng
--
> 2 files changed, 30 insertions(+), 15 deletions(-)
>
Reviewed-by: Bin Meng
Hi Philippe,
On Sat, Feb 20, 2021 at 4:58 PM Bin Meng wrote:
>
> From: Bin Meng
>
> At present the sd_erase() does not erase the requested range of card
> data to 0xFFs. Let's make the erase operation actually happen.
>
> Signed-off-by: Bin Meng
>
> ---
>
From: Bin Meng
Per SST25VF016B datasheet [1], SST flash requires a dummy byte after
the address bytes. Note only SPI mode is supported by SST flashes.
[1] http://ww1.microchip.com/downloads/en/devicedoc/s71271_04.pdf
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
---
Changes in v2
; ---
> Based-on: <1613447214-81951-1-git-send-email-bmeng...@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sd/sdhci.c | 9 ++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
zilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
---
(no changes since v2)
Changes in v2:
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
hw/sd/sdhci.c | 12
1 file changed, 12
The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Daudé
---
(no changes since v2)
Changes in v2:
- new patch: sdhci: Limit block size only when SDHC_BLKSIZE
-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Daudé
Reported-by: Sergej Schumilo (Ruhr-University Bochum)
Reported-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Tested-by: Alexander Bulekov
Tested-by: Philippe Mathieu-Daudé
---
(no changes since v1)
hw/sd/sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 9acf4467a3..f72d76c178 100644
-
the duplicated SoB email address
Changes in v3:
- Embed the reproducer in the commit message
Changes in v2:
- new patch: sdhci: Limit block size only when SDHC_BLKSIZE register is writable
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Bin Meng
---
(no changes since v2)
Changes in v2:
- new patch: sdhci: Limit block size
Reported-by: Sergej Schumilo (Ruhr-University Bochum)
Reported-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
reproducer in the commit message
Changes in v2:
- new patch: sdhci: Limit block size only when SDHC_BLKSIZE register is writable
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
Bin Meng (5):
hw/sd: sdhci: Don't transfer any data when
-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Dau
zilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Signed-off-by: Bin Meng
---
(no changes since v2)
Changes in v2:
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
hw/sd/sdhci.c | 12 +
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Tested-by: Alexander Bulekov
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Bin Meng
---
(no changes since v1)
hw/sd/sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 9acf44
From: Bin Meng
"qemu-common.h" should be included to provide the forward declaration
of qemu_hexdump() when DEBUG_SD is on.
Signed-off-by: Bin Meng
---
hw/sd/sd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 8b397effbc..7b09ce9c2e 100644
--- a/
From: Bin Meng
At present the sd_erase() does not erase the requested range of card
data to 0xFFs. Let's make the erase operation actually happen.
Signed-off-by: Bin Meng
---
Changes in v3:
- fix the skip erase logic for SDSC cards
Changes in v2:
- honor the write protection bits for
Hi Philippe,
On Fri, Feb 19, 2021 at 2:03 AM Philippe Mathieu-Daudé wrote:
>
> On 2/18/21 6:09 PM, Philippe Mathieu-Daudé wrote:
> > On 2/16/21 4:46 AM, Bin Meng wrote:
> >> The codes to limit the maximum block size is only necessary when
> >> SDHC_BLKSIZE reg
Hi Philippe,
On Fri, Feb 19, 2021 at 2:06 AM Philippe Mathieu-Daudé wrote:
>
> Hi Bin,
>
> On 2/16/21 4:46 AM, Bin Meng wrote:
> > If the block size is programmed to a different value from the
> > previous one, reset the data pointer of s->fifo_buffer[] so that
> &g
On Sat, Feb 20, 2021 at 6:28 AM Philippe Mathieu-Daudé wrote:
>
> On 2/16/21 4:02 PM, Bin Meng wrote:
> > From: Bin Meng
> >
> > At present the sd_erase() does not erase the requested range of card
> > data to 0xFFs. Let's make the erase operation actually happ
Hi Philippe,
On Fri, Feb 19, 2021 at 12:25 AM Philippe Mathieu-Daudé wrote:
>
> On 2/16/21 4:46 AM, Bin Meng wrote:
> > At the end of sdhci_send_command(), it starts a data transfer if the
> > command register indicates data is associated. But the data transfer
> > shoul
From: Bin Meng
At present the sd_erase() does not erase the requested range of card
data to 0xFFs. Let's make the erase operation actually happen.
Signed-off-by: Bin Meng
---
Changes in v2:
- honor the write protection bits for SDSC cards
hw/sd/sd.c | 22 ++
1
From: Bin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26
(SD mode) and table 7-3 (SPI mode) command descriptions, CMD30
response type is R1, not R1b.
Fixes: a1bb27b1e98a ("SD card emulation initial implementation")
Signed-off-by: Bin Meng
---
Change
From: Bin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26
(SD mode) and table 7-3 (SPI mode) command descriptions, the
following commands:
- CMD28 (SET_WRITE_PROT)
- CMD29 (CLR_WRITE_PROT)
- CMD30 (SEND_WRITE_PROT)
are only supported by SDSC cards.
Signed-off-by
From: Bin Meng
High capacity cards don't support write protection hence we should
not preform the write protect groups check in CMD24/25 for them.
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch: sd: Skip write protect groups check in CMD24/25 for high capacity
cards
hw/sd
From: Bin Meng
These APIs and macros may be referenced by functions that are
currently before them. Move them ahead a little bit.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
---
(no changes since v1)
hw/sd/sd.c | 42 +-
1 file changed
From: Bin Meng
Unlike SD mode, when SD card is working in SPI mode, the argument
of CMD13 is stuff bits. Hence we should bypass the RCA check.
See "Physical Layer Specification Version 8.00", chapter 7.3.1.3
Detailed Command Description (SPI mode):
"The card shall ignore
From: Bin Meng
High capacity cards don't support write protection hence we should
not preform the write protect groups check in sd_erase() for them.
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch: sd: Skip write protect groups check in sd_erase() for high
capacity card
hw/sd
From: Bin Meng
For high capacity memory cards, the erase start address and end
address are multiplied by 512, but the address check is still
based on the original block number in sd->erase_{start, end}.
Fixes: 1bd6fd8ed593 ("hw/sd/sdcard: Do not attempt to erase out of range
addresses&
From: Bin Meng
This includes several fixes related to erase operation of a SD card.
Currently sd_erase() does not perform the actual erase operation to
reset the requested block contents to 0xFFs. When trying to add such
functionality, one issue was spotted that the write protection is
only
On Tue, Feb 16, 2021 at 9:28 PM Philippe Mathieu-Daudé wrote:
>
> There is new interest in the SD/MMC device emulation, so it
> would be good to have more than only one maintainer / reviewer
> for it.
>
> Bin Meng proved by his contributions a deep understanding of the
> S
On Wed, Feb 10, 2021 at 1:36 AM Philippe Mathieu-Daudé wrote:
>
> On 2/9/21 3:32 PM, Bin Meng wrote:
> > Hi Philippe,
> >
> > On Thu, Feb 4, 2021 at 2:02 PM Bin Meng wrote:
> >>
> >> On Thu, Jan 28, 2021 at 2:30 PM Bin Meng wrote:
> >>&g
-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
---
(no changes since v1)
hw/sd/sdhci.c | 3 +++
1 file
The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch: sdhci: Limit block size only when SDHC_BLKSIZE register is writable
hw/sd/sdhci.c | 14 +++---
1 file changed, 7 insertions
s->prnsts is updated in both branches of the if () else () statement.
Move the common bits outside so that it is cleaner.
Signed-off-by: Bin Meng
---
(no changes since v1)
hw/sd/sdhci.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhc
zilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
hw/sd/sdhci.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/sd/sdhci.c b/hw/sd/sd
Ramdhan
Reported-by: Sergej Schumilo (Ruhr-University Bochum)
Reported-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Me
: sdhci: Limit block size only when SDHC_BLKSIZE register is writable
- new patch: sdhci: Reset the data pointer of s->fifo_buffer[] when a different
block size is programmed
Bin Meng (6):
hw/sd: sdhci: Don't transfer any data when command time out
hw/sd: sdhci: Don't write to SDHC_S
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Tested-by: Alexander Bulekov
Tested-by: Philippe Mathieu-Daudé
---
(no changes since v1)
hw/sd/sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 8ffa539..1c5ab26 100644
--- a/hw/
Hi Alex,
On Tue, Feb 16, 2021 at 12:48 AM Alexander Bulekov wrote:
>
> Hi Bin,
> Thank you for this. I ran through the OSS-Fuzz tests again, and it found
> one thing:
Thanks for testing. Are there instructions to run OSS-Fuzz tests myself?
> Maybe this is already much better than the current st
s->prnsts is updated in both branches of the if () else () statement.
Move the common bits outside so that it is cleaner.
Signed-off-by: Bin Meng
---
hw/sd/sdhci.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 0b0ca6f..7a20
From: Bin Meng
This series includes several fixes to CVE-2020-17380, CVE-2020-25085
and CVE-2021-3409 that are heap-based buffer overflow issues existing
in the sdhci model.
These CVEs are pretty much similar, and were filed using different
reproducers. With this series, current known
Ramdhan
Reported-by: Sergej Schumilo (Ruhr-University Bochum)
Reported-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Tested-by: Alexander Bulekov
Tested-by: Philippe Mathieu-Daudé
---
hw/sd/sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 8ffa539..1c5ab26 100644
--- a/hw/sd/sdhci.c
+++ b/hw/
-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Signed-off-by: Bin Meng
---
hw/sd/sdhci.c | 3 +++
1 file changed, 3 insertions(+)
di
On Sun, Feb 14, 2021 at 1:56 PM Bin Meng wrote:
>
> Hi Alexander,
>
> On Fri, Feb 12, 2021 at 5:25 AM Alexander Bulekov wrote:
> >
> > On 210211 1154, Alexander Bulekov wrote:
> > ...
> > > I applied this along with <20210208193450.2689517-1-f4...@am
Hi Alexander,
On Fri, Feb 12, 2021 at 5:25 AM Alexander Bulekov wrote:
>
> On 210211 1154, Alexander Bulekov wrote:
> ...
> > I applied this along with <20210208193450.2689517-1-f4...@amsat.org>
> > "hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress"
> >
> > I ran through th
From: Bin Meng
Current QEMU HEAD nvme.c does not compile with the default GCC 5.4
on a Ubuntu 16.04 host:
hw/block/nvme.c:3242:9: error: ‘result’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
trace_pci_nvme_getfeat_vwcache(result ? "enabled" :
Hi Philippe,
On Wed, Feb 10, 2021 at 7:15 PM Philippe Mathieu-Daudé
wrote:
>
> On 2/10/21 12:12 PM, Philippe Mathieu-Daudé wrote:
> > Hi Bin,
> >
> > On 2/10/21 11:23 AM, Bin Meng wrote:
> >> From: Bin Meng
> >>
> >> Current QEMU HEAD nvme.c d
Hi Philippe,
On Wed, Feb 10, 2021 at 7:12 PM Philippe Mathieu-Daudé
wrote:
>
> Hi Bin,
>
> On 2/10/21 11:23 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > Current QEMU HEAD nvme.c does not compile:
> >
> > hw/block/nvme.c:3242:9: error: ‘result’ may b
On Wed, Feb 10, 2021 at 6:23 PM Klaus Jensen wrote:
>
> On Feb 10 18:15, Bin Meng wrote:
> > On Wed, Feb 10, 2021 at 5:54 PM Bin Meng wrote:
> > >
> > > From: Bin Meng
> > >
> > > Current QEMU HEAD nvme.c does not compile:
> > &
From: Bin Meng
Current QEMU HEAD nvme.c does not compile:
hw/block/nvme.c:3242:9: error: ‘result’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
trace_pci_nvme_getfeat_vwcache(result ? "enabled" : "disabled");
^
hw/block/
On Wed, Feb 10, 2021 at 5:54 PM Bin Meng wrote:
>
> From: Bin Meng
>
> Current QEMU HEAD nvme.c does not compile:
>
> hw/block/nvme.c: In function ‘nvme_process_sq’:
Not sure why compiler reports this error happens in nvme_process_sq()?
But it should be in nvme_get_featur
From: Bin Meng
Current QEMU HEAD nvme.c does not compile:
hw/block/nvme.c: In function ‘nvme_process_sq’:
hw/block/nvme.c:3242:9: error: ‘result’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
trace_pci_nvme_getfeat_vwcache(result ? "enabled" :
Hi Philippe,
On Thu, Feb 4, 2021 at 2:02 PM Bin Meng wrote:
>
> On Thu, Jan 28, 2021 at 2:30 PM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > This includes the previously v3 series [1], and one single patch [2].
> >
> > Compared to v3, this
: Alexander Bulekov
Reported-by: Sergej Schumilo (Ruhr-University Bochum)
Reported-by: Cornelius Aschermann (Ruhr-University Bochum)
Reported-by: Simon Wrner (Ruhr-University Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Signed-off-by: Bin Meng
---
hw/sd/sdhci.c | 4 +++-
1 file
Oops, hitting "send" by mistake ...
On Tue, Feb 9, 2021 at 5:42 PM Bin Meng wrote:
>
> Hi Philippe,
>
> On Tue, Feb 9, 2021 at 5:38 PM Philippe Mathieu-Daudé wrote:
> >
> > On 2/9/21 9:28 AM, Bin Meng wrote:
> > > Hi Philippe,
> > >
> &g
Hi Philippe,
On Tue, Feb 9, 2021 at 5:38 PM Philippe Mathieu-Daudé wrote:
>
> On 2/9/21 9:28 AM, Bin Meng wrote:
> > Hi Philippe,
> >
> > On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Per the "SD Host Contro
Hi Philippe,
On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé wrote:
>
> Per the "SD Host Controller Simplified Specification Version 2.00"
> spec. 'Table 2-4 : Block Size Register':
>
> Transfer Block Size [...] can be accessed only if no
> transaction is executing (i.e., after a transa
On Thu, Jan 21, 2021 at 10:18 PM Francisco Iglesias
wrote:
>
> Hi Bin,
>
> On [2021 Jan 21] Thu 16:59:51, Bin Meng wrote:
> > Hi Francisco,
> >
> > On Thu, Jan 21, 2021 at 4:50 PM Francisco Iglesias
> > wrote:
> > >
> > > Dear Bin,
>
HI Philippe,
On Mon, Feb 8, 2021 at 10:27 PM Philippe Mathieu-Daudé wrote:
>
> On Mon, Feb 8, 2021 at 3:20 PM Bin Meng wrote:
> >
> > Hi Philippe,
> >
> > On Mon, Feb 8, 2021 at 10:08 PM Philippe Mathieu-Daudé
> > wrote:
> > >
> > > On 1
On Mon, Feb 8, 2021 at 9:55 PM Bin Meng wrote:
>
> Hi Philippe,
>
> On Mon, Feb 8, 2021 at 9:08 PM Philippe Mathieu-Daudé wrote:
> >
> > On 1/30/21 11:20 AM, Bin Meng wrote:
> > > Hi Philippe,
> > >
> > > On Fri, Jan 29, 2021 at 10:11 PM Philipp
Hi Philippe,
On Mon, Feb 8, 2021 at 9:08 PM Philippe Mathieu-Daudé wrote:
>
> On 1/30/21 11:20 AM, Bin Meng wrote:
> > Hi Philippe,
> >
> > On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Hi Bin,
> >>
>
Hi Philippe,
On Mon, Feb 8, 2021 at 10:08 PM Philippe Mathieu-Daudé wrote:
>
> On 1/28/21 7:30 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > Besides CMD12, the following command's reponse type is R1b:
> >
> > - SET_WRITE_PROT (CMD28)
> &
On Thu, Jan 28, 2021 at 2:43 PM Bin Meng wrote:
>
> From: Bin Meng
>
> This includes several fixes related to erase operation of a SD card.
>
> Based-on:
> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226785
>
>
> Bin Meng (3):
> hw/sd: sd: Fix a
On Thu, Jan 28, 2021 at 2:30 PM Bin Meng wrote:
>
> From: Bin Meng
>
> 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_RESPONS
Hi Philippe,
On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé wrote:
>
> Hi Bin,
>
> On 1/29/21 9:51 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > Unlike SD mode, when SD card is working in SPI mode, the argument
> > of CMD13 is stuff bits. Hence we
From: Bin Meng
Unlike SD mode, when SD card is working in SPI mode, the argument
of CMD13 is stuff bits. Hence we should bypass the RCA check.
Signed-off-by: Bin Meng
---
Based-on: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226787
hw/sd/sd.c | 3 ++-
1 file changed, 2
From: Bin Meng
These APIs and macros may be referenced by functions that are
currently before them. Move them ahead a little bit.
Signed-off-by: Bin Meng
---
hw/sd/sd.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/hw/sd/sd.c
101 - 200 of 345 matches
Mail list logo
