Fix: Assign bitrate and loopback on for Socketcan

[baconYao]

Description

Two changes are made in this commit.

1. For most of devices with Can hardware component, the Can interface cannot be brought up if the bitrate is not given. Therefore, I assign the bitrate for eff and sff local socketcan tests like what the remote socketcan tests do.
2. For local Socketcan test, loopback is the must need parameter be assigned before bringing the Can interface up.

Resolved issues

No Bitrate & No Loopback on:

• Limeric Project

  • Submission: https://certification.canonical.com/hardware/202304-31517/submission/323234/test-results/fail/?term=socketcan
    • FD mode is not supported which be confirmed by customer (LP#2022014), so please ignore the failed result of local fd mode
    • Customer mentioned that bitrate and loopback on are needed before bringing up (LP#2025450)

• Baoshan Project

  • Submission: https://certification.canonical.com/hardware/202307-31858/submission/326108/test-results/fail/?term=socketcan
    • For local eff and sff Socketcan test, the can0 interface cannot be brought up if there's no bitrate be assigned.
    • For local fd Socketcan test, timeout occurs if the loopback on isn't given.

With Bitrate and Loopback on:

• Baoshan Project

  • Sideload result: https://certification.canonical.com/hardware/202307-31858/submission/326402/test-results/?term=local

• Baytown Project

  • Submission: https://certification.canonical.com/hardware/202212-30955/submission/309730/test-results/?term=packet_local

• Limeric Project

  • VCK190 Submission: https://certification.canonical.com/hardware/202210-30706/submission/305486/test-results/?term=socket
  • ZCU106 Submission: https://certification.canonical.com/hardware/202210-30688/submission/290344/test-results/?term=socket

Documentation

N/A

Tests

[pieqq]

I don't have much knowledge on the topic, so it's hard for me to review this, but thankfully you provide some submissions!

Where do the values you provide come from? For some of the commands, you issue a bitrate of 100,000 while for another one you set it to 1,000,000. Is this expected, or is it a typo?

If you have a source for the numbers you are using, could you add it in the commit message so that we know why we have these numbers?

Also, was this tested on the devices that were running these socketcan tests previously?

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (main@9f16d82). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             main    #662   +/-   ##
======================================
  Coverage        ?   1.95%           
======================================
  Files           ?     126           
  Lines           ?   14950           
  Branches        ?    2583           
======================================
  Hits            ?     292           
  Misses          ?   14595           
  Partials        ?      63           

Flag	Coverage Δ
provider-base	1.93% <0.00%> (?)
providers	1.93% <0.00%> (?)
unittests	1.93% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[baconYao]

I don't have much knowledge on the topic, so it's hard for me to review this, but thankfully you provide some submissions!

Where do the values you provide come from? For some of the commands, you issue a bitrate of 100,000 while for another one you set it to 1,000,000. Is this expected, or is it a typo?

If you have a source for the numbers you are using, could you add it in the commit message so that we know why we have these numbers?

Also, was this tested on the devices that were running these socketcan tests previously?

The value 100,000 was used in lots of Project Checkbox like I listed above (Baoshan, Limeric, Baytwon and others). But to be honest, I have no idea why they were 100,000 instead of 1,000,000.

The value 1,000,000 is referenced from socketcan remote job.

• The following link is the sideload test result after setting the bitrate is 1,000,000 in Baoshan project
  • https://certification.canonical.com/hardware/202307-31858/submission/328874/test-results/

[pieqq]

These changes have been verified on different devices from different projects using socketcan and are known to work, so all good.

+1