qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] hw/pflash_cfi02: Fix lazy reset of ROMD mode


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] hw/pflash_cfi02: Fix lazy reset of ROMD mode
Date: Sun, 10 Apr 2011 10:38:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-04-03 22:16, Jordan Justen wrote:
> When checking pfl->rom_mode for when to lazily reenter ROMD mode,
> the value was check was the opposite of what it should have been.
> This prevent the part from returning to ROMD mode after a write
> was made to the CFI rom region.
> 
> Signed-off-by: Jordan Justen <address@hidden>
> ---
>  hw/pflash_cfi02.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
> index 30c8aa4..370c5ee 100644
> --- a/hw/pflash_cfi02.c
> +++ b/hw/pflash_cfi02.c
> @@ -112,7 +112,7 @@ static uint32_t pflash_read (pflash_t *pfl, 
> target_phys_addr_t offset,
>  
>      DPRINTF("%s: offset " TARGET_FMT_plx "\n", __func__, offset);
>      ret = -1;
> -    if (pfl->rom_mode) {
> +    if (!pfl->rom_mode) {
>          /* Lazy reset of to ROMD mode */
>          if (pfl->wcycle == 0)
>              pflash_register_memory(pfl, 1);

Indeed, that block looks weird to its author today as well. But
inverting the logic completely defeats the purpose of lazy mode
switching (will likely file a patch to remove the block). We should
instead switch back using the timer.

So the question is: Did you actually see a problem that the flash was
stuck in write mode, or did you just stumble over this strange code? In
the former case, please explain the sequence or provide a trace.

Thanks,
Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]