[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eepr
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom |
Date: |
Fri, 9 Nov 2018 17:53:28 +0000 |
On 9 November 2018 at 17:19, Corey Minyard <address@hidden> wrote:
> On 11/9/18 9:02 AM, Peter Maydell wrote:
>> The data provided by the caller is only the initialization
>> data. So I think the device should create its own memory
>> to copy that init data into, and migrate that ram, not
>> wherever the initialization data lives. (Currently
>> this "copy the data into our own ram" happens in the
>> smbus_eeprom_init() wrapper, but we should do it in the
>> device realize function instead.)
>
>
> That's what I would like, but should I get rid of the "DEFINE_PROP_PTR"?
> I don't know the value of creating a properly like this, since the user
> can't set it and can't see it. Plus the comments in the code say that
> it should be gotten rid of at some point.
>
> But if I store off the initialization data and keep the actual data in
> a separate memory created by the realize function, that should work
> find.
Well, you still have to pass the init data to the device
somehow, so I think a pointer property is not a terrible
way to do that.
>> Also there seem to be unresolved questions about what happens
>> on reset -- should the EEPROM revert back to the initial
>> contents? We don't do that at the moment, but this breaks
>> the usual QEMU pattern that reset is as if you'd just
>> completely restarted QEMU.
>
>
> I would consider this part of the hardware, like data on a disk drive,
> so it seem better to leave it alone after a reset. But it's not quite
> the same. So I'm not sure.
That would require us to support backing it properly with a block
device, like the pflash flash devices, I think. (This would
be the long term way to be able to dump the pointer property,
in favour of a block backend property.)
thanks
-- PMM
- [Qemu-devel] [PATCH 0/3] Fix/add vmstate handling in some I2C code, minyard, 2018/11/07
- [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, minyard, 2018/11/07
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom,
Peter Maydell <=
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Dr. David Alan Gilbert, 2018/11/12
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/12
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Dr. David Alan Gilbert, 2018/11/12
[Qemu-devel] [PATCH 1/3] i2c:pm_smbus: Fix state transfer, minyard, 2018/11/07
[Qemu-devel] [PATCH 2/3] i2c: Add an SMBus vmstate structure, minyard, 2018/11/07