On 08.08.22 16:40, Sascha Hauer wrote:
> On Mon, Aug 08, 2022 at 02:12:01PM +0200, Ahmad Fatoum wrote:
>> Hello Sascha,
>>
>> On 08.08.22 14:03, Sascha Hauer wrote:
>>> On Mon, Aug 08, 2022 at 01:38:28PM +0200, Ahmad Fatoum wrote:
>>>> Hello Sascha,
>>>>
>>>> On 08.08.22 13:11, Sascha Hauer wrote:
>>>>> On Mon, Aug 08, 2022 at 08:56:48AM +0200, Ahmad Fatoum wrote:
>>>>>> + /* associate buffer with FIT, so it's not leaked */
>>>>>> + data = dataprop->value = uc_data;
>>>>>> + dataprop->length = data_len;
>>>>>
>>>>> Why are you fiddling with struct property fields directly?
>>>>> of_get_property() and of_set_property() should do what you want.
>>>>
>>>> of_set_property copies the data into a new buffer, which I want
>>>> to avoid doing again.
>>>
>>> Ah, yes. Ok then.
>>>
>>> Still the
>>>
>>> if (!dataprop->value) {
>>> ...
>>> }
>>>
>>> part confuses me. With the current code it won't be set. If it will be
>>> set due to future changes then your code won't uncompress the buffer and
>>> silently continues. I think this should rather be
>>>
>>> free(dataprop->value);
>>> dataprop->value = uc_data;
>>>
>>> As a bonus you'll save an indention level.
>>
>> I don't want to free dataprop->value. I want to cache the uncompressed
>> data alongside the FIT, so a renewed call to fit_open_image()
>> doesn't decompress again. I haven't checked if this can happen currently,
>> but it feels natural to keep value_const for the uncompressed data
>> and populate value with the compressed data and do the uncompression
>> only once on first fit_open_image().
>
> IMO the fields in struct property should only be used inside the core OF
> code. In the core OF code "value" and "value_const" hold the same data,
> once allocated dynamically and once allocated externally. "value_const"
> purely exists to optimize memory usage for FIT images.
>
> We shouldn't overload this and now start to store an uncompressed
> version of "value_const" in "value". It also doesn't look very useful as
> fit_open_image() isn't called multiple times for the same image. If that
> becomes a usecase, then we should cache the data in some other data
> structure, not in the device tree property.
We need to link the uncompressed data buffer with the FIT image,
so it doesn't leak. Any of the multiple images can be compressed, so we need
to hold multiple buffers. Storing this as a property in the device tree node
is quite elegant IMO. I agree now that the value/value_const dichotomy
is not the best way, so I added a new uncompressed-data property in v2.
Cheers,
Ahmad
>
> Sascha
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
