linux-kernel - Re: [PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bb575aba-3f5c-c27c-6421-6ae4d4564271@theobroma-systems.com>
Date:   Mon, 9 Apr 2018 18:43:28 +0200
From:   Martin Elshuber <martin.elshuber@...obroma-systems.com>
To:     Wolfgang Grandegger <wg@...ndegger.com>
Cc:     Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-systems.com>,
        Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN
 devices

Hallo Wolfgang,

thank you for the review, we have the update ready but we will test a
while it before sending V5.

Regarding your question on the firmware behavior, find the answer inline
below.
> Hello Jacob,
>
> just a few minor issues and a question about bus-off handling...
>
> Am 03.04.2018 um 16:35 schrieb Jakob Unterwurzacher:
>> The UCAN driver supports the microcontroller-based USB/CAN
>> adapters from Theobroma Systems. There are two form-factors
>> that run essentially the same firmware:
>>
>> * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )
>>
>> * Mule: integrated on the PCB of various System-on-Modules from
>>   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
>>   ( https://www.theobroma-systems.com/rk3399-q7 )
>>
[..snip..]
>> +
>> +	/* we switched into a worse state */
>> +	up->can.state = new_state;
>> +	switch (new_state) {
>> +	case CAN_STATE_BUS_OFF:
>> +		can_stats->bus_off++;
>> +		can_bus_off(up->netdev);
> How does the CAN controller firmware handle bus-off? Does it recover
> automatically? "can_bus_off()" will restart the CAN controller after
> "restart-ms" or manually via netlink "restart" command by calling
> "ucan_set_mode(CAN_START_MODE)":
>
>   # ip link set canX type can restart-ms 100
>   # ip link set canX type can restart
>
> See also:
>
>   https://elixir.bootlin.com/linux/latest/source/drivers/net/can/dev.c#L597
1) Once a bus-off condition is detected, the device sends an error
   message do indicate the bus state change (the same happens
   also for bus state changes into ERROR_ACTIVE/WARNING/PASSIVE).
2) The device will not restart the bus itself (to give application
   control how to handle this event).
3) The device initiates a bus of recovery upon receiving the control
   message UCAN_COMMAND_RESTART (see ucan_set_mode())
4) The Linux CAN framework handles sending a CAN_ERR_RESTARTED message
   and calling ucan_set_mode().
5) Once the device completes the recovery, it sends a state change
   message indicating that it is in ERROR_ACTIVE state (see 1).
6) During BUS-OFF no error frames or normal frames are set from the
   device to the host.
7) If the device receives a frame from the host when in bus-off (e.g.:
   just after detecting the condition) the device confirms reception by
   sending an TX_COMPLETE with and error indicator and drops the frame.
   Finally the driver calls can_free_echo_skb() upon reception of the
   TX_COMPLETE message (see ucan_tx_complete_msg()).

The protocol documentation will be updated accordingly

[..snip..]
> Thanks for your contribution!
>
> Wolfgang.
>
Best regards
Martin

-- 
Martin Elshuber
Theobroma Systems Design und Consulting GmbH
Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
Phone: +43 1 236 98 93-405, Fax: +43 1 236 98 93-9
http://www.theobroma-systems.com