Hello Ricardo,
On Wed, Dec 1, 2021 at 9:14 AM Martinez, Ricardo
<ricardo.martinez@xxxxxxxxxxxxxxx> wrote:
> On 11/9/2021 4:06 AM, Sergey Ryazanov wrote:
>> On Mon, Nov 1, 2021 at 6:57 AM Ricardo Martinez wrote:
>>> ...
>>> static struct t7xx_port md_ccci_ports[] = {
>>> + {CCCI_UART2_TX, CCCI_UART2_RX, DATA_AT_CMD_Q, DATA_AT_CMD_Q, 0xff,
>>> + 0xff, ID_CLDMA1, PORT_F_RX_CHAR_NODE, &wwan_sub_port_ops, 0, "ttyC0", WWAN_PORT_AT},
>>> + {CCCI_MBIM_TX, CCCI_MBIM_RX, 2, 2, 0, 0, ID_CLDMA1,
>>> + PORT_F_RX_CHAR_NODE, &wwan_sub_port_ops, 10, "ttyCMBIM0", WWAN_PORT_MBIM},
>>> ...
>>> + if (count + CCCI_H_ELEN > txq_mtu &&
>>> + (port_ccci->tx_ch == CCCI_MBIM_TX ||
>>> + (port_ccci->tx_ch >= CCCI_DSS0_TX && port_ccci->tx_ch <= CCCI_DSS7_TX)))
>>> + multi_packet = DIV_ROUND_UP(count, txq_mtu - CCCI_H_ELEN);
>>
>> I am just wondering, the chip does support MBIM message fragmentation,
>> but does not support AT commands stream (CCCI_UART2_TX) fragmentation.
>> Is that the correct conclusion from the code above?
>
> Yes, that is correct.
Are you sure that the modem does not support AT command fragmentation?
The AT commands interface is a stream of chars by its nature. It is
designed to work over serial lines. Some modem configuration software
even writes commands to a port in a char-by-char manner, i.e. it
writes no more than one char at a time to the port.
The mechanism that is implemented in the driver to split user input
into individual messages is not a true fragmentation mechanism since
it does not preserve the original user input length. It just cuts the
user input into individual messages and sends them to the modem
independently. So, the modem firmware has no way to distinguish
whether the user input has been "fragmented" by the user or the
driver. How, then, does the modem firmware deal with an AT command
"fragmented" by a user? Will the modem firmware ignore the AT command
that is received in the char-by-char manner?
--
Sergey
