Re: flexcan driver: tx_bytes counter never incremented when CAN_RAW_LOOPBACK removed?

[Wolfgang Grandegger <wg@grandegger.com>]

On 04/29/2013 02:37 PM, Stephane Grosjean wrote:
> 
> Le 29/04/2013 12:53, Marc Kleine-Budde a écrit :
>> On 04/29/2013 12:40 PM, Stephane Grosjean wrote:
>>> Hi Marc,
>>>
>>> Playing with the flexcan driver, I've seen that the tx_bytes counter
>>> always equals 0 while tx_packets increases.
>>> I simply removed the CAN_RAW_LOOPBACK option from my CAN socket, so I
>>> suppose that:
>>>
>>> stats->tx_bytes += can_get_echo_skb(dev, 0);
>>>
>>> doesn't do what it should.
>>> Am I wrong?
>> Let me see. Yes you're right. can_put_echo_skb() only queues the CAN
>> frame if CAN_RAW_LOOPBACK is set.
>>
>> We either can change that can_put_echo_skb() always queues the CAN frame
>> or that can_get_echo_skb() returns the correct number of bytes even if
>> the CAN frame is not queued or put the mechanism in each driver.

Or we read it from "regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl".

>>
>> Marc
>>
> 
> Why not handling tx_bytes and tx_packets in "flexcan_start_xmit()"
> instead? Easier and faster change, wouldn't be it?

Ony messages going really out to the bus sould be counted, if possible.

> I also have seen that the flexcan ctrlr (iMx25) behaves oddly when rx
> overrun occurs: each time I get such an OVR INT., I also get some

OVR INT? What error do you mean?

> spurious TX INT. too, while I never sent anything on the CAN. So, for
> me, handling tx_bytes/tx_packets stats when sending the data would fix
> everything!

See above. What has the handling of tx_bytes/tx_packets stats to do with
spurious TX INT or the OVR INT?

Wolfgang.