<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net/can, branch v4.7-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>can: ifi: Add more detailed error reporting</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5bbd655a8bd000579d135ddf30660f759db89996'/>
<id>5bbd655a8bd000579d135ddf30660f759db89996</id>
<content type='text'>
The updated specification for the IFI CANFD core contains description
of more detailed error reporting capability of the core. Implement
support for this detailed error reporting.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The updated specification for the IFI CANFD core contains description
of more detailed error reporting capability of the core. Implement
support for this detailed error reporting.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: ifi: Increment TX counters only on real transmission</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1acd80fb982728b8bf467184d5ec4c5a77a5601b'/>
<id>1acd80fb982728b8bf467184d5ec4c5a77a5601b</id>
<content type='text'>
Only increment the TX counters in the irq handler if a CAN message
was sent. The current code incremented the counters also if the TX
FIFO empty interrupt happened, which is incorrect.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only increment the TX counters in the irq handler if a CAN message
was sent. The current code incremented the counters also if the TX
FIFO empty interrupt happened, which is incorrect.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: ifi: Treat CAN_CTRLMODE_FD_NON_ISO correctly</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ca79408986bf250c22f3130c333787ec44c4d103'/>
<id>ca79408986bf250c22f3130c333787ec44c4d103</id>
<content type='text'>
The CAN_CTRLMODE_FD flag is set for both ISO and BOSCH CANFD mode,
while the CAN_CTRLMODE_FD_NON_ISO is additional flag which is only
set for CANFD-BOSCH mode. Fix the handling of the flags to reflect
this.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Reviewed-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The CAN_CTRLMODE_FD flag is set for both ISO and BOSCH CANFD mode,
while the CAN_CTRLMODE_FD_NON_ISO is additional flag which is only
set for CANFD-BOSCH mode. Fix the handling of the flags to reflect
this.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Reviewed-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: ifi: Unify timing constants</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=478ad12c9f5a2f5a1d39fc898b098992980d3abc'/>
<id>478ad12c9f5a2f5a1d39fc898b098992980d3abc</id>
<content type='text'>
There is no distinction between bittiming constants for the slow and
fast part of the CANFD operation on this controller, so just use one
single bittiming constant set.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is no distinction between bittiming constants for the slow and
fast part of the CANFD operation on this controller, so just use one
single bittiming constant set.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: ifi: Update timing configuration code</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=be1861320a9ec599b6862ebb71db9bd3ad897150'/>
<id>be1861320a9ec599b6862ebb71db9bd3ad897150</id>
<content type='text'>
The updated documentation regarding the IFI CANFD core from April 2016
adds more details regarding the timing calculation. There is no longer
any distinction in the timing calculation between CANFD and CAN2.0, but
instead there are two timing modes -- 4_12_6_6 and 7_9_8_8 -- where the
numbers mean the width in bits of the SJW/Prescaler/TimeA/TimeB fields.
The code uses 7_9_8_8 mode, which allows more fine-grained control over
the timing.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The updated documentation regarding the IFI CANFD core from April 2016
adds more details regarding the timing calculation. There is no longer
any distinction in the timing calculation between CANFD and CAN2.0, but
instead there are two timing modes -- 4_12_6_6 and 7_9_8_8 -- where the
numbers mean the width in bits of the SJW/Prescaler/TimeA/TimeB fields.
The code uses 7_9_8_8 mode, which allows more fine-grained control over
the timing.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: ifi: Start NAPI poll on bus warning too</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2016-05-07T22:34:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=496c798db0b81af67572a2052ea30504c863235f'/>
<id>496c798db0b81af67572a2052ea30504c863235f</id>
<content type='text'>
Start the NAPI polling in case the bus warning interrupt happens,
since it is the poll function which checks and reports the warning.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Start the NAPI polling in case the bus warning interrupt happens,
since it is the poll function which checks and reports the warning.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: gs_usb: modify the usb device table to use only the first usb interface</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Maximilian Schneider</name>
<email>max@schneidersoft.net</email>
</author>
<published>2016-04-25T08:54:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2fe6c943147c5bb0550f5c3e941de3824986330e'/>
<id>2fe6c943147c5bb0550f5c3e941de3824986330e</id>
<content type='text'>
Modified the USB device table to use only the first USB interface, as is
the case with GS USB devices. This allows other GS USB compatible
devices to be more flexible with their remaining interfaces.

Signed-off-by: Maximilian Schneider &lt;max@schneidersoft.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Modified the USB device table to use only the first USB interface, as is
the case with GS USB devices. This allows other GS USB compatible
devices to be more flexible with their remaining interfaces.

Signed-off-by: Maximilian Schneider &lt;max@schneidersoft.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: janz-ican3: error handling for CAL/CANopen firmware</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Andreas Gröger</name>
<email>andreas24groeger@gmail.com</email>
</author>
<published>2016-05-06T08:04:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b16e368ed6193d8d1774b4cc874d7892d55c4780'/>
<id>b16e368ed6193d8d1774b4cc874d7892d55c4780</id>
<content type='text'>
My patch of May 2015 was missing the changed handling of error
indications. With CAL/CANopen firmware the NMTS-SlaveEventIndication
must be used instead of CAN-EventIndication. An appropriate slave node
must be configured to report the errors.

In our department (about 15 development systems with Janz ICAN3-
modules with firmware 1.48, my system also with firmware ICANOS 1.35)
we use the driver with this patch for about one year: no known problems.

Signed-off-by: Andreas Gröger &lt;andreas24groeger@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
My patch of May 2015 was missing the changed handling of error
indications. With CAL/CANopen firmware the NMTS-SlaveEventIndication
must be used instead of CAN-EventIndication. An appropriate slave node
must be configured to report the errors.

In our department (about 15 development systems with Janz ICAN3-
modules with firmware 1.48, my system also with firmware ICANOS 1.35)
we use the driver with this patch for about one year: no known problems.

Signed-off-by: Andreas Gröger &lt;andreas24groeger@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: fix handling of unmodifiable configuration options</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-03-21T19:18:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bb208f144cf3f59d8f89a09a80efd04389718907'/>
<id>bb208f144cf3f59d8f89a09a80efd04389718907</id>
<content type='text'>
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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: mcp251x: Replace create_freezable_workqueue with alloc_workqueue</title>
<updated>2016-05-09T09:07:28+00:00</updated>
<author>
<name>Amitoj Kaur Chawla</name>
<email>amitoj1606@gmail.com</email>
</author>
<published>2016-04-08T15:32:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b6fd3aba6041922e115bd8e10539b8545f4120ac'/>
<id>b6fd3aba6041922e115bd8e10539b8545f4120ac</id>
<content type='text'>
Replace scheduled to be removed create_freezable_workqueue with
alloc_workqueue.

priv-&gt;wq should be explicitly set as freezable to ensure it is frozen
in the suspend sequence and work items are drained so that no new work
item starts execution until thawed. Thus, use of WQ_FREEZABLE flag
here is required.

WQ_MEM_RECLAIM flag has been set here to ensure forward progress
regardless of memory pressure.

The order of execution is not important so set @max_active as 0.

Signed-off-by: Amitoj Kaur Chawla &lt;amitoj1606@gmail.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace scheduled to be removed create_freezable_workqueue with
alloc_workqueue.

priv-&gt;wq should be explicitly set as freezable to ensure it is frozen
in the suspend sequence and work items are drained so that no new work
item starts execution until thawed. Thus, use of WQ_FREEZABLE flag
here is required.

WQ_MEM_RECLAIM flag has been set here to ensure forward progress
regardless of memory pressure.

The order of execution is not important so set @max_active as 0.

Signed-off-by: Amitoj Kaur Chawla &lt;amitoj1606@gmail.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
