<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/can/c_can, branch linux-4.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-03-30T12:45:00Z</updated>
<entry>
<title>can: c_can: move runtime PM enable/disable to c_can_platform</title>
<updated>2021-03-30T12:45:00Z</updated>
<author>
<name>Tong Zhang</name>
</author>
<published>2021-03-02T02:55:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e6831c854154f4197a27c74c5607a433851bd04'/>
<id>urn:sha1:2e6831c854154f4197a27c74c5607a433851bd04</id>
<content type='text'>
[ Upstream commit 6e2fe01dd6f98da6cae8b07cd5cfa67abc70d97d ]

Currently doing modprobe c_can_pci will make the kernel complain:

    Unbalanced pm_runtime_enable!

this is caused by pm_runtime_enable() called before pm is initialized.

This fix is similar to 227619c3ff7c, move those pm_enable/disable code
to c_can_platform.

Fixes: 4cdd34b26826 ("can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller")
Link: http://lore.kernel.org/r/20210302025542.987600-1-ztong0001@gmail.com
Signed-off-by: Tong Zhang &lt;ztong0001@gmail.com&gt;
Tested-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: c_can_pci: c_can_pci_remove(): fix use-after-free</title>
<updated>2021-03-30T12:45:00Z</updated>
<author>
<name>Tong Zhang</name>
</author>
<published>2021-03-01T02:45:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b1ed9aef2804bd0632d0e7653d2279deaf4f78c5'/>
<id>urn:sha1:b1ed9aef2804bd0632d0e7653d2279deaf4f78c5</id>
<content type='text'>
[ Upstream commit 0429d6d89f97ebff4f17f13f5b5069c66bde8138 ]

There is a UAF in c_can_pci_remove(). dev is released by
free_c_can_dev() and is used by pci_iounmap(pdev, priv-&gt;base) later.
To fix this issue, save the mmio address before releasing dev.

Fixes: 5b92da0443c2 ("c_can_pci: generic module for C_CAN/D_CAN on PCI")
Link: https://lore.kernel.org/r/20210301024512.539039-1-ztong0001@gmail.com
Signed-off-by: Tong Zhang &lt;ztong0001@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: c_can: D_CAN: c_can_chip_config(): perform a sofware reset on open</title>
<updated>2019-12-05T14:26:37Z</updated>
<author>
<name>Jeroen Hofstee</name>
</author>
<published>2019-10-01T21:01:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c9623eb961eccb686f4bba7da835678acfee013'/>
<id>urn:sha1:6c9623eb961eccb686f4bba7da835678acfee013</id>
<content type='text'>
[ Upstream commit 23c5a9488f076bab336177cd1d1a366bd8ddf087 ]

When the CAN interface is closed it the hardwre is put in power down
mode, but does not reset the error counters / state. Reset the D_CAN on
open, so the reported state and the actual state match.

According to [1], the C_CAN module doesn't have the software reset.

[1] http://www.bosch-semiconductors.com/media/ip_modules/pdf_2/c_can_fd8/users_manual_c_can_fd8_r210_1.pdf

Signed-off-by: Jeroen Hofstee &lt;jhofstee@victronenergy.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: c_can: c_can_poll(): only read status register after status IRQ</title>
<updated>2019-11-12T18:13:22Z</updated>
<author>
<name>Kurt Van Dijck</name>
</author>
<published>2019-10-01T07:40:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=def6b03f667bce4b1465644a1d1b325336fddd63'/>
<id>urn:sha1:def6b03f667bce4b1465644a1d1b325336fddd63</id>
<content type='text'>
commit 3cb3eaac52c0f145d895f4b6c22834d5f02b8569 upstream.

When the status register is read without the status IRQ pending, the
chip may not raise the interrupt line for an upcoming status interrupt
and the driver may miss a status interrupt.

It is critical that the BUSOFF status interrupt is forwarded to the
higher layers, since no more interrupts will follow without
intervention.

Thanks to Wolfgang and Joe for bringing up the first idea.

Signed-off-by: Kurt Van Dijck &lt;dev.kurt@vandijck-laurijssen.be&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Cc: Joe Burmeister &lt;joe.burmeister@devtank.co.uk&gt;
Fixes: fa39b54ccf28 ("can: c_can: Get rid of pointless interrupts")
Cc: linux-stable &lt;stable@vger.kernel.org&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: c_can: don't indicate triple sampling support for D_CAN</title>
<updated>2017-11-15T16:13:13Z</updated>
<author>
<name>Richard Schütz</name>
</author>
<published>2017-10-29T12:03:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4df27e6493089c571eeebea0d1475784e6435d18'/>
<id>urn:sha1:4df27e6493089c571eeebea0d1475784e6435d18</id>
<content type='text'>
commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.

The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.

Signed-off-by: Richard Schütz &lt;rschuetz@uni-koblenz.de&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: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer</title>
<updated>2017-02-01T07:30:52Z</updated>
<author>
<name>Einar Jón</name>
</author>
<published>2016-08-12T11:50:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=63fe33a7842883bae9f526b324eb5d807a098ee9'/>
<id>urn:sha1:63fe33a7842883bae9f526b324eb5d807a098ee9</id>
<content type='text'>
commit c97c52be78b8463ac5407f1cf1f22f8f6cf93a37 upstream.

The priv-&gt;device pointer for c_can_pci is never set, but it is used
without a NULL check in c_can_start(). Setting it in c_can_pci_probe()
like c_can_plat_probe() prevents c_can_pci.ko from crashing, with and
without CONFIG_PM.

This might also cause the pm_runtime_*() functions in c_can.c to
actually be executed for c_can_pci devices - they are the only other
place where priv-&gt;device is used, but they all contain a null check.

Signed-off-by: Einar Jón &lt;tolvupostur@gmail.com&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: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access</title>
<updated>2016-08-10T09:49:28Z</updated>
<author>
<name>Thor Thayer</name>
</author>
<published>2016-06-16T16:10:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1cee72ed4856504fd597145ce10b29751c4d27a1'/>
<id>urn:sha1:1cee72ed4856504fd597145ce10b29751c4d27a1</id>
<content type='text'>
commit 427460c83cdf55069eee49799a0caef7dde8df69 upstream.

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;
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: remove obsolete assignment for CAN protocol error type</title>
<updated>2015-11-23T08:37:38Z</updated>
<author>
<name>Oliver Hartkopp</name>
</author>
<published>2015-11-21T17:41:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a2ec19f888f1fb06e2424486423a16f86ad1fcc4'/>
<id>urn:sha1:a2ec19f888f1fb06e2424486423a16f86ad1fcc4</id>
<content type='text'>
The assignment 'cf-&gt;data[2] |= CAN_ERR_PROT_UNSPEC' used at CAN error message
creation time is obsolete as CAN_ERR_PROT_UNSPEC is zero and cf-&gt;data[2] is
initialized with zero in alloc_can_err_skb() anyway.

So we could either assign 'cf-&gt;data[2] = CAN_ERR_PROT_UNSPEC' correctly or we
can remove the obsolete OR operation entirely.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: fix assignment of error location in CAN error messages</title>
<updated>2015-11-23T08:37:34Z</updated>
<author>
<name>Oliver Hartkopp</name>
</author>
<published>2015-11-21T17:41:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ffd461f80d536336811d573f197f3e6d9872d054'/>
<id>urn:sha1:ffd461f80d536336811d573f197f3e6d9872d054</id>
<content type='text'>
As Dan Carpenter reported in http://marc.info/?l=linux-can&amp;m=144793696016187
the assignment of the error location in CAN error messages had some bit wise
overlaps. Indeed the value to be assigned in data[3] is no bitfield but defines
a single value which points to a location inside the CAN frame on the wire.

This patch fixes the assignments for the error locations in error messages.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: c_can: Fix default pinmux glitch at init</title>
<updated>2015-07-12T18:57:42Z</updated>
<author>
<name>J.D. Schroeder</name>
</author>
<published>2015-07-08T11:38:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=033365191136c97f88c81b7bd0011414db28bb4e'/>
<id>urn:sha1:033365191136c97f88c81b7bd0011414db28bb4e</id>
<content type='text'>
The previous change 3973c526ae9c (net: can: c_can: Disable pins when CAN
interface is down) causes a slight glitch on the pinctrl settings when used.
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
the device core will automatically set the default pins. This causes the pins
to be momentarily set to the default and then to the sleep state in
register_c_can_dev(). By adding an optional "enable" state, boards can set the
default pin state to be disabled and avoid the glitch when the switch from
default to sleep first occurs. If the "enable" state is not available
c_can_pinctrl_select_state() falls back to using the "default" pinctrl state.

[Roger Q] - Forward port to v4.2 and use pinctrl_get_select().

Signed-off-by: J.D. Schroeder &lt;jay.schroeder@garmin.com&gt;
Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Reviewed-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
