public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andrew Davis <afd@ti.com>
To: Philippe Schenker <dev@pschenker.ch>, <u-boot@lists.denx.de>
Cc: <stefan@embear.ch>, Andrew Goodbody <andrew.goodbody@linaro.org>,
	"Beleswar Padhi" <b-padhi@ti.com>,
	Daniel Schultz <d.schultz@phytec.de>,
	Hari Nagalla <hnagalla@ti.com>,
	Neha Malcom Francis <n-francis@ti.com>,
	Peng Fan <peng.fan@nxp.com>, Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t
Date: Fri, 7 Nov 2025 10:24:45 -0600	[thread overview]
Message-ID: <ca97c8a6-e5bf-4ae4-aede-133c38510321@ti.com> (raw)
In-Reply-To: <f429996a374f31d2d9dcdbcb8f143de18b512549.camel@pschenker.ch>

On 11/7/25 10:00 AM, Philippe Schenker wrote:
> 
> 
> On Fri, 2025-11-07 at 09:24 -0600, Andrew Davis wrote:
>> On 11/7/25 7:01 AM, Philippe Schenker wrote:
>>> From: Philippe Schenker <philippe.schenker@impulsing.ch>
>>>
>>> When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
>>> passing 'size' (ulong) to ti_secure_image_post_process() caused
>>> a type mismatch compiler error.
>>>
>>> Cast 'size' to (size_t *) to fix it.
>>
>> If the size of `size_t` and `ulong` are not the same this doesn't
>> really fix the issue, just silence the compiler warning. If ulong
>> is smaller than size_t on some platform we will read data outside
>> the variable address when de-referencing.
>>
>> Might be more correct to assign size to a variable of the correct
>> size first, then pass a pointer to that.
>>
>> Andrew
> 
> Hi Andrew, Thanks for your comment. If I understand it correctly and
> explained in different words: If size_t is larger than ulong unknown
> memory could be accessed.

Correct. And if size_t is smaller then on big-endian systems you
will read the wrong data.

> Isn't it very unlikely that this ever
> happens?
> 

Also correct, I don't think either scenario is likely, it is
just about formal correctness. And I also didn't think any system
would have ulong and size_t be different sizes, but guess you
found a case (not sure why on R5 they are both not 32bits but
if the compiler is complaining then I guess they aren't).

> At least I did interpret your first comment that way.
> 
> Anyway I will send a v3 to really catch all cases.
> 

Thanks :)

Andrew

>>
>>>
>>> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
>>> Acked-by: Andrew Davis <afd@ti.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Added Andrew's Acked-by
>>>
>>>    drivers/remoteproc/ti_k3_r5f_rproc.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> b/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> index c738607c1092..e7bd97a9088b 100644
>>> --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> @@ -341,7 +341,7 @@ static int k3_r5f_load(struct udevice *dev,
>>> ulong addr, ulong size)
>>>    
>>>     k3_r5f_init_tcm_memories(core, mem_auto_init);
>>>    
>>> - ti_secure_image_post_process(&image_addr, &size);
>>> + ti_secure_image_post_process(&image_addr, (size_t *)&size);
>>>    
>>>     ret = rproc_elf_load_image(dev, addr, size);
>>>     if (ret < 0) {


  reply	other threads:[~2025-11-07 16:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 13:00 [PATCH v2 0/6] remoteproc: k3-r5: Build fixes and security improvements Philippe Schenker
2025-11-07 13:01 ` [PATCH v2 1/6] arm: dts: k3-am642-evm: Remove duplicate node Philippe Schenker
2025-11-10  9:21   ` Anshul Dalal
2025-11-07 13:01 ` [PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t Philippe Schenker
2025-11-07 15:24   ` Andrew Davis
2025-11-07 16:00     ` Philippe Schenker
2025-11-07 16:24       ` Andrew Davis [this message]
2025-11-07 13:01 ` [PATCH v2 3/6] soc: ti: pruss: Fix size ptr type in probe Philippe Schenker
2025-11-07 13:01 ` [PATCH v2 4/6] mach-k3: security: Propagate verified image addr Philippe Schenker
2025-11-07 13:01 ` [PATCH v2 5/6] remoteproc: k3-r5: Use verified image address Philippe Schenker
2025-11-07 13:01 ` [PATCH v2 6/6] remoteproc: k3-r5: Implement is_running operation Philippe Schenker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca97c8a6-e5bf-4ae4-aede-133c38510321@ti.com \
    --to=afd@ti.com \
    --cc=andrew.goodbody@linaro.org \
    --cc=b-padhi@ti.com \
    --cc=d.schultz@phytec.de \
    --cc=dev@pschenker.ch \
    --cc=hnagalla@ti.com \
    --cc=n-francis@ti.com \
    --cc=peng.fan@nxp.com \
    --cc=stefan@embear.ch \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox