<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net/can, branch v3.18.74</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.74</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.74'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-06-26T05:10:50Z</updated>
<entry>
<title>can: gs_usb: fix memory leak in gs_cmd_reset()</title>
<updated>2017-06-26T05:10:50Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2017-06-04T12:03:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2b840ed1b403958f2822adb46ffaf447739e303b'/>
<id>urn:sha1:2b840ed1b403958f2822adb46ffaf447739e303b</id>
<content type='text'>
commit 5cda3ee5138e91ac369ed9d0b55eab0dab077686 upstream.

This patch adds the missing kfree() in gs_cmd_reset() to free the
memory that is not used anymore after usb_control_msg().

Cc: Maximilian Schneider &lt;max@schneidersoft.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: dev: fix deadlock reported after bus-off</title>
<updated>2016-12-23T14:41:16Z</updated>
<author>
<name>Sergei Miroshnichenko</name>
<email>sergeimir@emcraft.com</email>
</author>
<published>2016-09-07T13:51:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5e5920acffa330fabb1a7df2c340d747d2a13e37'/>
<id>urn:sha1:5e5920acffa330fabb1a7df2c340d747d2a13e37</id>
<content type='text'>
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] https://github.com/victronenergy/venus/issues/24

Signed-off-by: Sergei Miroshnichenko &lt;sergeimir@emcraft.com&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>can: flexcan: fix resume function</title>
<updated>2016-10-06T02:40:20Z</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@nxp.com</email>
</author>
<published>2016-08-17T15:41:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0b5f2bd0dfa47e81a2c2104849c27c5be920782e'/>
<id>urn:sha1:0b5f2bd0dfa47e81a2c2104849c27c5be920782e</id>
<content type='text'>
[ Upstream commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 ]

On a imx6ul-pico board the following error is seen during system suspend:

dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device 2090000.flexcan failed to resume: error -110

The reason for this suspend error is because when the CAN interface is not
active the clocks are disabled and then flexcan_chip_enable() will
always fail due to a timeout error.

In order to fix this issue, only call flexcan_chip_enable/disable()
when the CAN interface is active.

Based on a patch from Dong Aisheng in the NXP kernel.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>can: fix oops caused by wrong rtnl dellink usage</title>
<updated>2016-07-12T12:47:02Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T13:45:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2eb6bd4c427ce63e87284d975f79c3e2344de27c'/>
<id>urn:sha1:2eb6bd4c427ce63e87284d975f79c3e2344de27c</id>
<content type='text'>
[ Upstream commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 ]

For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created nor
removed with the ip tool ...

This patch adds a private dellink function for the CAN device driver interface
that does just nothing.

It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
newlink usage") but for dellink.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: fix handling of unmodifiable configuration options fix</title>
<updated>2016-07-12T12:47:01Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T10:14:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ec351072a28a39ec0438e92918c20d5fab62bc22'/>
<id>urn:sha1:ec351072a28a39ec0438e92918c20d5fab62bc22</id>
<content type='text'>
[ Upstream commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a ]

With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
configuration options) a new can_validate() function was introduced.

When invoking 'ip link set can0 type can' without any configuration data
can_validate() tries to validate the content without taking into account that
there's totally no content. This patch adds a check for missing content.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: at91_can: RX queue could get stuck at high bus load</title>
<updated>2016-07-12T12:46:56Z</updated>
<author>
<name>Wolfgang Grandegger</name>
<email>wg@grandegger.com</email>
</author>
<published>2016-06-13T13:44:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5c6fe0bcd209d7b89a7b781c76992b290739cc4e'/>
<id>urn:sha1:5c6fe0bcd209d7b89a7b781c76992b290739cc4e</id>
<content type='text'>
[ Upstream commit 43200a4480cbbe660309621817f54cbb93907108 ]

At high bus load it could happen that "at91_poll()" enters with all RX
message boxes filled up. If then at the end the "quota" is exceeded as
well, "rx_next" will not be reset to the first RX mailbox and hence the
interrupts remain disabled.

Signed-off-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Tested-by: Amr Bekhit &lt;amrbekhit@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access</title>
<updated>2016-07-12T12:46:55Z</updated>
<author>
<name>Thor Thayer</name>
<email>tthayer@opensource.altera.com</email>
</author>
<published>2016-06-16T16:10:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cc7a8303741c5fd9a0c733d69d4fa3a154cbd707'/>
<id>urn:sha1:cc7a8303741c5fd9a0c733d69d4fa3a154cbd707</id>
<content type='text'>
[ Upstream commit 427460c83cdf55069eee49799a0caef7dde8df69 ]

When testing CAN write floods on Altera's CycloneV, the first 2 bytes
are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
observed bytes 4 &amp; 5 were corrupted in some cases.

The D_CAN Data registers are 32 bits and changing from 16 bit writes to
32 bit writes fixes the problem.

Testing performed on Altera CycloneV (D_CAN).  Requesting tests on other
C_CAN &amp; D_CAN platforms.

Reported-by: Richard Andrysek &lt;richard.andrysek@gomtec.de&gt;
Signed-off-by: Thor Thayer &lt;tthayer@opensource.altera.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: fix handling of unmodifiable configuration options</title>
<updated>2016-06-03T15:30:37Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-03-21T19:18:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=85809a369e09fa4662863b045300e2de5e1cc8a5'/>
<id>urn:sha1:85809a369e09fa4662863b045300e2de5e1cc8a5</id>
<content type='text'>
[ Upstream commit bb208f144cf3f59d8f89a09a80efd04389718907 ]

As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
(6cfda7fbebe) it is possible to define fixed configuration options by
setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
This leads to the incovenience that the fixed configuration bits can not be
passed by netlink even when they have the correct values (e.g. non-ISO, FD).

This patch fixes that issue and not only allows fixed set bit values to be set
again but now requires(!) to provide these fixed values at configuration time.
A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
enforced by a new can_validate() function. This fix additionally removed the
inconsistency that was prohibiting the support of 'CANFD-only' controller
drivers, like the RCar CAN FD.

For this reason a new helper can_set_static_ctrlmode() has been introduced to
provide a proper interface to handle static enabled CAN controller options.

Reported-by: Ramesh Shanmugasundaram &lt;ramesh.shanmugasundaram@bp.renesas.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Reviewed-by: Ramesh Shanmugasundaram  &lt;ramesh.shanmugasundaram@bp.renesas.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # &gt;= 3.18
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()</title>
<updated>2016-03-21T02:14:25Z</updated>
<author>
<name>Maximilain Schneider</name>
<email>max@schneidersoft.net</email>
</author>
<published>2016-02-23T01:17:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bb431546329c853234bd5e2c5be83bbbcfbbdf45'/>
<id>urn:sha1:bb431546329c853234bd5e2c5be83bbbcfbbdf45</id>
<content type='text'>
[ Upstream commit e9a2d81b1761093386a0bb8a4f51642ac785ef63 ]

gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is
allocated through alloc_candev() and should instead be freed using
free_candev() alone.

The inappropriate use of kfree() causes the kernel to hang when
gs_destroy_candev() is called.

Only the struct gs_usb * which is allocated through kzalloc() should be freed
using kfree() when the device is disconnected.

Signed-off-by: Maximilian Schneider &lt;max@schneidersoft.net&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>can: ems_usb: Fix possible tx overflow</title>
<updated>2016-03-08T06:13:49Z</updated>
<author>
<name>Gerhard Uttenthaler</name>
<email>uttenthaler@ems-wuensche.com</email>
</author>
<published>2015-12-22T16:29:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2992a0a3323ab300939910f8d8044b467136ea99'/>
<id>urn:sha1:2992a0a3323ab300939910f8d8044b467136ea99</id>
<content type='text'>
[ Upstream commit 90cfde46586d2286488d8ed636929e936c0c9ab2 ]

This patch fixes the problem that more CAN messages could be sent to the
interface as could be send on the CAN bus. This was more likely for slow baud
rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
heavy TX load this produced another bulk transfer without checking the
free_slots variable and hence caused the overflow in the interface.

Signed-off-by: Gerhard Uttenthaler &lt;uttenthaler@ems-wuensche.com&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
</feed>
