[Top][All Lists]
[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
signature.asc
Description: OpenPGP digital signature