<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/can/c_can, branch linux-4.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-01-30T20:10:42Z</updated>
<entry>
<title>drivers: net: generalize napi_complete_done()</title>
<updated>2017-01-30T20:10:42Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2017-01-30T16:22:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6ad20165d376fa07919a70e4f43dfae564601829'/>
<id>urn:sha1:6ad20165d376fa07919a70e4f43dfae564601829</id>
<content type='text'>
napi_complete_done() allows to opt-in for gro_flush_timeout,
added back in linux-3.19, commit 3b47d30396ba
("net: gro: add a per device gro flush timer")

This allows for more efficient GRO aggregation without
sacrifying latencies.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer</title>
<updated>2017-01-18T11:58:26Z</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=c97c52be78b8463ac5407f1cf1f22f8f6cf93a37'/>
<id>urn:sha1:c97c52be78b8463ac5407f1cf1f22f8f6cf93a37</id>
<content type='text'>
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;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&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-06-20T07:32:40Z</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=427460c83cdf55069eee49799a0caef7dde8df69'/>
<id>urn:sha1:427460c83cdf55069eee49799a0caef7dde8df69</id>
<content type='text'>
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;
</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>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-01-28T00:59:56Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2015-01-28T00:59:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=95f873f2fff96c592c5d863e2a39825bd8bf0500'/>
<id>urn:sha1:95f873f2fff96c592c5d863e2a39825bd8bf0500</id>
<content type='text'>
Conflicts:
	arch/arm/boot/dts/imx6sx-sdb.dts
	net/sched/cls_bpf.c

Two simple sets of overlapping changes.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: c_can: end pending transmission on network stop (ifdown)</title>
<updated>2015-01-21T21:43:14Z</updated>
<author>
<name>Viktor Babrian</name>
</author>
<published>2015-01-18T19:01:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7ffd7b4e169d619e66928fe5d997723f2c6f1056'/>
<id>urn:sha1:7ffd7b4e169d619e66928fe5d997723f2c6f1056</id>
<content type='text'>
Put controller into init mode in network stop to end pending transmissions. The
issue is observed in cases when transmitted frame is not acked.

Signed-off-by: Viktor Babrian &lt;babrian.viktor@renyi.mta.hu&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: move can_stats.bus_off++ from can_bus_off into can_change_state</title>
<updated>2015-01-20T12:56:53Z</updated>
<author>
<name>Andri Yngvason</name>
</author>
<published>2015-01-16T14:30:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=be38a6f9f4093b0f1fa9e7d8cb47d588bc117c21'/>
<id>urn:sha1:be38a6f9f4093b0f1fa9e7d8cb47d588bc117c21</id>
<content type='text'>
In order to be able to move the stats increment from can_bus_off() into
can_change_state(), the increment had to be moved back into code that was using
can_bus_off() but not can_change_state().

As a side-effect, this patch fixes the following bugs:
 * Redundant call to can_bus_off() in c_can.
 * Bus-off counted twice in xilinx_can.

Signed-off-by: Andri Yngvason &lt;andri.yngvason@marel.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: c_can: use regmap_update_bits() to modify RAMINIT register</title>
<updated>2015-01-15T15:58:00Z</updated>
<author>
<name>Roger Quadros</name>
</author>
<published>2015-01-13T14:23:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=47e3485af0a7a65547a3267021851d4ea6474d09'/>
<id>urn:sha1:47e3485af0a7a65547a3267021851d4ea6474d09</id>
<content type='text'>
use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon()
is not safe as the RAMINIT register can be shared between different drivers
at least for TI SoCs.

To make the modification atomic we switch to using regmap_update_bits().

regmap_update_bits() skips writing to the register if it's read content is the
same as what is going to be written. This causes an issue for us when we
need to clear the DONE bit with the initial condition START:0, DONE:1 as
DONE bit must be written with 1 to clear it.

So we defer the clearing of DONE bit to later when we set the START bit.
There we are sure that START bit is changed from 0 to 1 so the write of
1 to already set DONE bit will happen.

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
