0 as "rom-size" doesn't make much sense, let's use the smallest 24cXX
which has 128 byte.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 hw/nvram/eeprom_at24c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
index d82710e1df..de988f8d07 100644
--- a/hw/nvram/eeprom_at24c.c
+++ b/hw/nvram/eeprom_at24c.c
@@ -168,7 +168,7 @@ void at24c_eeprom_reset(DeviceState *state)
 }
 
 static Property at24c_eeprom_props[] = {
-    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
+    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 128),
     DEFINE_PROP_BOOL("writable", EEPROMState, writable, true),
     DEFINE_PROP_DRIVE("drive", EEPROMState, blk),
     DEFINE_PROP_END_OF_LIST()
-- 
2.11.0

Hi Wolfram,

On 03/12/2018 10:42 PM, Wolfram Sang wrote:
> 0 as "rom-size" doesn't make much sense, let's use the smallest 24cXX
> which has 128 byte.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>  hw/nvram/eeprom_at24c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> index d82710e1df..de988f8d07 100644
> --- a/hw/nvram/eeprom_at24c.c
> +++ b/hw/nvram/eeprom_at24c.c
> @@ -168,7 +168,7 @@ void at24c_eeprom_reset(DeviceState *state)
>  }
>  
>  static Property at24c_eeprom_props[] = {
> -    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
> +    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 128),

This patch should goes before your 2/3 in your series.

Can you add a #define for this value? Such AT24C_ROMSIZE_MIN.

With a #define you can add:
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

>      DEFINE_PROP_BOOL("writable", EEPROMState, writable, true),
>      DEFINE_PROP_DRIVE("drive", EEPROMState, blk),
>      DEFINE_PROP_END_OF_LIST()
> 

Hi Philippe,

> >  static Property at24c_eeprom_props[] = {
> > -    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
> > +    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 128),
> 
> This patch should goes before your 2/3 in your series.

I don't mind much, but why? My reasoning was "let's first fix the cause
and then the symptom"?

> Can you add a #define for this value? Such AT24C_ROMSIZE_MIN.

Can do, of course. But won't that give room for regressions because
people are already using it with lower values?

Ideally, we would have a "model" variable. The model type would define
the size of the memory. The "rom-size" variable could then be kept as is
(except for the 0 bugfix) or deprecated?

Thanks for the review,

   Wolfram

Hi Wolfram,

On 03/13/2018 09:16 PM, Wolfram Sang wrote:
> Hi Philippe,
> 
>>>  static Property at24c_eeprom_props[] = {
>>> -    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
>>> +    DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 128),
>>
>> This patch should goes before your 2/3 in your series.
> 
> I don't mind much, but why? My reasoning was "let's first fix the cause
> and then the symptom"?

The '0' case is worst than incorrect, it segfaults, so you are right :)

> 
>> Can you add a #define for this value? Such AT24C_ROMSIZE_MIN.
> 
> Can do, of course. But won't that give room for regressions because
> people are already using it with lower values?

Your patch already introduce the regression :)

I prefer self-explanatory #defines than magic value, but I see your
point, so if we can not decide a value, can you add a comment to explain
the magic value? I think the clearer is to add a #define with a comment.

> 
> Ideally, we would have a "model" variable. The model type would define
> the size of the memory. The "rom-size" variable could then be kept as is
> (except for the 0 bugfix) or deprecated?

IMO there are too many AT24C eeproms to model, so the "rom-size"
variable is the easiest way. Your patch #2 is simple enough to avoid the
#DIV/0!

> 
> Thanks for the review,
> 
>    Wolfram
> 

Hi Philippe,

> > I don't mind much, but why? My reasoning was "let's first fix the cause
> > and then the symptom"?
> 
> The '0' case is worst than incorrect, it segfaults, so you are right :)

Ok, thanks.

> >> Can you add a #define for this value? Such AT24C_ROMSIZE_MIN.
> > 
> > Can do, of course. But won't that give room for regressions because
> > people are already using it with lower values?
> 
> Your patch already introduce the regression :)

Not really. The current default setting (0) segfaults. This is how I
discovered it. So, there can't be any active user of that.

> I prefer self-explanatory #defines than magic value, but I see your
> point, so if we can not decide a value, can you add a comment to explain
> the magic value? I think the clearer is to add a #define with a comment.

I wouldn't mind a macro AT24C_ROMSIZE_DEFAULT and a comment explaining
why we chose this value. This is totally fine with me.

It was just the MIN value I saw potential usage regressions with.

> IMO there are too many AT24C eeproms to model, so the "rom-size"
> variable is the easiest way. Your patch #2 is simple enough to avoid the
> #DIV/0!

Fine with me, too. I will update my series accordingly.

Thanks,

   Wolfram