[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e666fa0-2f4d-9958-887e-8830049ccbe8@suse.cz>
Date: Thu, 26 Mar 2020 12:45:57 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: Arnaud POULIQUEN <arnaud.pouliquen@...com>,
Ohad Ben-Cohen <ohad@...ery.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org,
Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Suman Anna <s-anna@...com>,
Fabien DESSENNE <fabien.dessenne@...com>,
linux-stm32@...md-mailman.stormreply.com,
xiang xiao <xiaoxiang781216@...il.com>
Subject: Re: [PATCH v7 2/2] tty: add rpmsg driver
On 26. 03. 20, 12:40, Arnaud POULIQUEN wrote:
>>>>> + /*
>>>>> + * Try to send the message to remote processor, if failed return 0 as
>>>>> + * no data sent
>>>>> + */
>>>>> + ret = rpmsg_trysendto(cport->d_ept, tmpbuf, msg_size, cport->data_dst);
>>>>
>>>> data of rpmsg_trysendto is not const. OK, you seem you need to change
>>>> that first, I see no blocker for that.
>>>
>>> I created a temporary buffer to ensure that buffer to sent does not exceed the
>>> MTU size.
>>> But perhaps this is an useless protection as the rpmsg_tty_write_room already
>>> return the MTU value, and so the 'len' variable can not be higher that value
>>> returned by the write_room?
>>
>> You still can limit it by msg_size without cloning the buffer, right?
> you are right, but in this case i need to cast the buff to suppress compilation
> warning on const and I don't know if all compilers will accept this...
>
> pbuf = (u8 *)buf;
> ret = rpmsg_trysendto(cport->d_ept, pbuf, msg_size, cport->data_dst);
No, don't do that. Read my first message again; in particular:
> data of rpmsg_trysendto is not const. OK, you seem you need to change
> that first, I see no blocker for that.
thanks,
--
js
suse labs
Powered by blists - more mailing lists