On 9 November 2018 at 17:19, Corey Minyard <cminy...@mvista.com> 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