<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/net/can/ifi_canfd, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/net/can/ifi_canfd?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/net/can/ifi_canfd?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-07T13:00:27Z</updated>
<entry>
<title>can: dev: fix skb drop check</title>
<updated>2022-11-07T13:00:27Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-11-02T09:54:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ae64438be1923e3c1102d90fd41db7afcfaf54cc'/>
<id>urn:sha1:ae64438be1923e3c1102d90fd41db7afcfaf54cc</id>
<content type='text'>
In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only
mode") the priv-&gt;ctrlmode element is read even on virtual CAN
interfaces that do not create the struct can_priv at startup. This
out-of-bounds read may lead to CAN frame drops for virtual CAN
interfaces like vcan and vxcan.

This patch mainly reverts the original commit and adds a new helper
for CAN interface drivers that provide the required information in
struct can_priv.

Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode")
Reported-by: Dariusz Stojaczyk &lt;Dariusz.Stojaczyk@opensynergy.com&gt;
Cc: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Cc: Max Staudt &lt;max@enpas.org&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Acked-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/all/20221102095431.36831-1-socketcan@hartkopp.net
Cc: stable@vger.kernel.org # 6.0.x
[mkl: patch pch_can, too]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>net: drop the weight argument from netif_napi_add</title>
<updated>2022-09-29T01:57:14Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-09-27T13:27:53Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b48b89f9c189d24eb5e2b4a0ac067da5a24ee86d'/>
<id>urn:sha1:b48b89f9c189d24eb5e2b4a0ac067da5a24ee86d</id>
<content type='text'>
We tell driver developers to always pass NAPI_POLL_WEIGHT
as the weight to netif_napi_add(). This may be confusing
to newcomers, drop the weight argument, those who really
need to tweak the weight can use netif_napi_add_weight().

Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt; # for CAN
Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: tree-wide: advertise software timestamping capabilities</title>
<updated>2022-07-28T09:44:01Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-27T10:16:32Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=409c188c57cdb5cb1dfcac79e72b5169f0463fe4'/>
<id>urn:sha1:409c188c57cdb5cb1dfcac79e72b5169f0463fe4</id>
<content type='text'>
Currently, some CAN drivers support hardware timestamping, some do
not. But userland has no method to query which features are supported
(aside maybe of getting RX messages and observe whether or not
hardware timestamps stay at zero).

The canonical way for a network driver to advertised what kind of
timestamping it supports is to implement ethtool_ops::get_ts_info().

This patch only targets the CAN drivers which *do not* support
hardware timestamping.  For each of those CAN drivers, implement the
get_ts_info() using the generic ethtool_op_get_ts_info().

This way, userland can do:

| $ ethtool --show-time-stamping canX

to confirm the device timestamping capacities.

N.B. the drivers which support hardware timestamping will be migrated
in separate patches.

Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr
[mkl: mscan: add missing mscan_ethtool_ops]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: add CAN_ERR_CNT flag to notify availability of error counter</title>
<updated>2022-07-20T07:27:37Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-19T14:35:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3e5c291c7942d0909a48bc5ec1b9bba136465166'/>
<id>urn:sha1:3e5c291c7942d0909a48bc5ec1b9bba136465166</id>
<content type='text'>
Add a dedicated flag in uapi/linux/can/error.h to notify the userland
that fields data[6] and data[7] of the CAN error frame were
respectively populated with the tx and rx error counters.

For all driver tree-wide, set up this flags whenever needed.

Link: https://lore.kernel.org/all/20220719143550.3681-12-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: can-dev: remove obsolete CAN LED support</title>
<updated>2022-05-19T20:15:51Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-05-18T15:45:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6c1e423a3c84953edcf91ff03ab97829b287184a'/>
<id>urn:sha1:6c1e423a3c84953edcf91ff03ab97829b287184a</id>
<content type='text'>
Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the
CAN specific LED support was disabled and marked as BROKEN. As the
common LED support with CONFIG_LEDS_TRIGGER_NETDEV should do this work
now the code can be removed as preparation for a CAN netdevice Kconfig
rework.

Link: https://lore.kernel.org/all/20220518154527.29046-1-socketcan@hartkopp.net
Suggested-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
[mkl: remove led.h from MAINTAINERS]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: do not increase rx_bytes statistics for RTR frames</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:30Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8e674ca74244eac1cd85c6e9a89b588a03c55ff7'/>
<id>urn:sha1:8e674ca74244eac1cd85c6e9a89b588a03c55ff7</id>
<content type='text'>
The actual payload length of the CAN Remote Transmission Request (RTR)
frames is always 0, i.e. no payload is transmitted on the wire.
However, those RTR frames still use the DLC to indicate the length of
the requested frame.

As such, net_device_stats::rx_bytes should not be increased for the
RTR frames.

This patch fixes all the CAN drivers.

Link: https://lore.kernel.org/all/20211207121531.42941-5-mailhol.vincent@wanadoo.fr
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Cc: Chandrasekar Ramakrishnan &lt;rcsekar@samsung.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Chen-Yu Tsai &lt;wens@csie.org&gt;
Cc: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Cc: Yasushi SHOJI &lt;yashi@spacecubics.com&gt;
Cc: Appana Durga Kedareswara rao &lt;appana.durga.rao@xilinx.com&gt;
Cc: Naga Sureshkumar Relli &lt;naga.sureshkumar.relli@xilinx.com&gt;
Cc: Michal Simek &lt;michal.simek@xilinx.com&gt;
Cc: Stephane Grosjean &lt;s.grosjean@peak-system.com&gt;
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt; # kvaser
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Acked-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Tested-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: do not increase rx statistics when generating a CAN rx error message frame</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=676068db69b847f06fe054fca15bf6b107bd24da'/>
<id>urn:sha1:676068db69b847f06fe054fca15bf6b107bd24da</id>
<content type='text'>
The CAN error message frames (i.e. error skb) are an interface
specific to socket CAN. The payload of the CAN error message frames
does not correspond to any actual data sent on the wire. Only an error
flag and a delimiter are transmitted when an error occurs (c.f. ISO
11898-1 section 10.4.4.2 "Error flag").

For this reason, it makes no sense to increment the rx_packets and
rx_bytes fields of struct net_device_stats because no actual payload
were transmitted on the wire.

This patch fixes all the CAN drivers.

Link: https://lore.kernel.org/all/20211207121531.42941-2-mailhol.vincent@wanadoo.fr
CC: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
CC: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
CC: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
CC: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
CC: Chandrasekar Ramakrishnan &lt;rcsekar@samsung.com&gt;
CC: Maxime Ripard &lt;mripard@kernel.org&gt;
CC: Chen-Yu Tsai &lt;wens@csie.org&gt;
CC: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
CC: Appana Durga Kedareswara rao &lt;appana.durga.rao@xilinx.com&gt;
CC: Naga Sureshkumar Relli &lt;naga.sureshkumar.relli@xilinx.com&gt;
CC: Michal Simek &lt;michal.simek@xilinx.com&gt;
CC: Stephane Grosjean &lt;s.grosjean@peak-system.com&gt;
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt; # kvaser
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Acked-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Tested-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_get_echo_skb(): extend to return can frame length</title>
<updated>2021-01-14T07:43:43Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2021-01-11T14:19:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9420e1d495e2a3b5f673148b7e3ebc861b1441f7'/>
<id>urn:sha1:9420e1d495e2a3b5f673148b7e3ebc861b1441f7</id>
<content type='text'>
In order to implement byte queue limits (bql) in CAN drivers, the length of the
CAN frame needs to be passed into the networking stack after queueing and after
transmission completion.

To avoid to calculate this length twice, extend can_get_echo_skb() to return
that value. Convert all users of this function, too.

Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20210111141930.693847-14-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_put_echo_skb(): extend to handle frame_len</title>
<updated>2021-01-14T07:43:43Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-01-11T14:19:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1dcb6e57db833419483d0df2d956b1cc2a802683'/>
<id>urn:sha1:1dcb6e57db833419483d0df2d956b1cc2a802683</id>
<content type='text'>
Add a frame_len argument to can_put_echo_skb() which is used to save length of
the CAN frame into field frame_len of struct can_skb_priv so that it can be
later used after transmission completion. Convert all users of this function,
too.

Drivers which implement BQL call can_put_echo_skb() with the output of
can_skb_get_frame_len(skb) and drivers which do not simply pass zero as an
input (in the same way that NULL would be given to can_get_echo_skb()). This
way, we have a nice symmetry between the two echo functions.

Link: https://lore.kernel.org/r/20210111061335.39983-1-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20210111141930.693847-13-mkl@pengutronix.de
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
</content>
</entry>
<entry>
<title>can: rename CAN FD related can_len2dlc and can_dlc2len helpers</title>
<updated>2020-11-20T11:05:14Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-11-10T10:18:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3ab4ce0d6fa8c93d41df4a74ec8d2c9198be2109'/>
<id>urn:sha1:3ab4ce0d6fa8c93d41df4a74ec8d2c9198be2109</id>
<content type='text'>
The helper functions can_len2dlc and can_dlc2len are only relevant for
CAN FD data length code (DLC) conversion.

To fit the introduced can_cc_dlc2len for Classical CAN we rename:

can_dlc2len -&gt; can_fd_dlc2len to get the payload length from the DLC
can_len2dlc -&gt; can_fd_len2dlc to get the DLC from the payload length

Suggested-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/r/20201110101852.1973-6-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
