Re: [PATCH 2/3] can: m_can: Enable M_CAN IP version dependent initialization

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 03/21/2017 11:30 AM, Marc Kleine-Budde wrote:
> On 03/19/2017 09:33 PM, Wolfgang Grandegger wrote:
>> Am 19.03.2017 um 21:16 schrieb Oliver Hartkopp:
>>>
>>>
>>> On 03/19/2017 08:12 PM, Wolfgang Grandegger wrote:
>>>> Am 19.03.2017 um 18:43 schrieb Oliver Hartkopp:
>>>
>>>>>>>> If I understood the frame flow correctly the 'non originating' socket
>>>>>>>> receives two frames:
>>>>>>>>
>>>>>>>> 1. the frame from the completed TX operation (echo_skb / IFF_ECHO)
>>>>>>>> 2. the frame received from the RX path from the hw loopback shortcut
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>>>> I would suggest to drop the frame coming from the RX path (case 2)
>>>>>>>> when
>>>>>>>> the CAN_CTRLMODE_LOOPBACK gets enabled.
>>>>>>
>>>>>> Why? Mario, what is you motivation/use case?
>>>>>
>>>>> This was just my (Olivers) suggestion.
>>>>>
>>>>> The effect with CAN_CTRLMODE_LOOPBACK enabled would then be similar to
>>>>> using a virtual CAN interface.
>>>>>
>>>>>>> Do we have an agreement on this?
>>>>>>> Did we ever discuss this topic in this detailed manner before?
>>>>>>
>>>>>> As I see it, the CAN_CTRLMODE_LOOPBACK provides a internal hardware
>>>>>> loopback to test the send and receive software (including echo skb). It
>>>>>> has noting to to with echo skbs.
>>>>>
>>>>> Agreed.
>>>>>
>>>>> But the question is what happens to the IFF_ECHO 'mechanism' when the
>>>>> CAN controller is switched into CAN_CTRLMODE_LOOPBACK?
>>>>
>>>> Nothing special. The software does *not* known that the message was
>>>> looped back by the hardware. The TX and RX is treated a usual.
>>>>
>>>>> Do we get a virtual CAN behavior (from IFF_ECHO on driver level) or do
>>>>> we get IFF_ECHO AND a reception due to the controllers loopback?
>>>>
>>>> The latter: The echoed message when TX is done and the RX (from the
>>>> hardware loopback).
>>>
>>> But this would be different to normal operation then!
>>
>> Depends on the intended usage. For testing if TX and RX software works
>> that's just fine.
>>
>>> When you have a second CAN interface on a real CAN bus that only ACKs
>>> your frames but doesn't send own traffic, you only see your echo'ed
>>> frames in the system (due to successful TX irq notification) - but no RX
>>> frames.
>>
>> Using the loopback as a virtual CAN device came never into my mind.
>>
>>>>>> The loopback mode never got big
>>>>>> attention. I think it's rarely used and if, then just for testing
>>>>>> purposes. That's maybe the reason why this issue was never discussed.
>>>
>>> So you vote for "The echoed message when TX is done and the RX (from the
>>> hardware loopback)." - which reflects the current implementation in
>>> SJA1000 and M_CAN.
>>>
>>> But my question is:
>>>
>>> Are developers using CAN_CTRLMODE_LOOPBACK to
>>>
>>> 1. Run their CAN controller without a working CAN bus hardware
>>> 2. To test the hardware loopback mode of the controller
>>>
>>> For case 1 the RX frames should be dropped and only the echo'ed frames
>>> should be provided to the system.
>>
>> Yes, feedback would really be useful.
>>
>> In the past I used it for the following purpose. After configuring and
>> starting the controller, I'm not able to get messages out to the bus or
>> receive from it. To understand if it's a software or hardware problem, I
>> switch to loopback mode. If it still doesn't work, it's software.
>
> From my point of view, the CAN_CTRLMODE_LOOPBACK mode should behave like
> an external loopback connector, but controllable by software. Like a
> short-circuit between RX and TX for RS232.
>
> So you would receive the echo packges on TX and the "real" packages on
> "RX". If you want a virtual CAN interface, make use of a vcan interace.

Ok. Then the posted implementation from Mario remains correct.

But it's good to have a common understanding about CAN_CTRLMODE_LOOPBACK 
now.

Regards,
Oliver