linux-stable.git/drivers/net/can, branch v4.2.4 Linux kernel stable tree can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters 2015-08-25T06:50:00+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-08-06T07:48:34+00:00 06b23f7fbbf26a025fd68395c7586949db586b47 The CAN FD data bittiming constants are provided via netlink only when there are valid CAN FD constants available in priv->data_bittiming_const. Due to the indirection of pointer assignments in the peak_usb driver the priv->data_bittiming_const never becomes NULL - not even for non-FD adapters. The data_bittiming_const points to zero'ed data which leads to this result when running 'ip -details link show can0': 35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can state STOPPED restart-ms 0 pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1 : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0 <== BROKEN! clock 8000000 This patch changes the struct peak_usb_adapter::bittiming_const and struct peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt problems. Cc: linux-stable <stable@vger.kernel.org> # >= 4.0 Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
The CAN FD data bittiming constants are provided via netlink only when there
are valid CAN FD constants available in priv->data_bittiming_const.

Due to the indirection of pointer assignments in the peak_usb driver the
priv->data_bittiming_const never becomes NULL - not even for non-FD adapters.

The data_bittiming_const points to zero'ed data which leads to this result
when running 'ip -details link show can0':

35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state STOPPED restart-ms 0
	  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
	  : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0  <== BROKEN!
	  clock 8000000

This patch changes the struct peak_usb_adapter::bittiming_const and struct
peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt
problems.

Cc: linux-stable <stable@vger.kernel.org> # >= 4.0
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: mcp251x: get regulators optionally 2015-07-16T07:04:22+00:00 Stefan Agner stefan@agner.ch 2015-05-18T16:33:28+00:00 69da3f2ac528642acbd06ed14564ac1b9a918394 The regulators power and transceiver are optional. If those are not present, the pointer (or error pointer) is correctly handled by the driver, hence we can use devm_regulator_get_optional safely, which avoids regulators getting created. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
The regulators power and transceiver are optional. If those are not
present, the pointer (or error pointer) is correctly handled by the
driver, hence we can use devm_regulator_get_optional safely, which
avoids regulators getting created.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: mcp251x: fix resume when device is down 2015-07-16T07:04:21+00:00 Stefan Agner stefan@agner.ch 2015-05-18T16:33:27+00:00 25b401c1816ae64bcc5dcb1d39ab41812522a0ce If a valid power regulator or a dummy regulator is used (which happens to be the case when no regulator is specified), restart_work is queued no matter whether the device was running or not at suspend time. Since work queues get initialized in the ndo_open callback, resuming leads to a NULL pointer exception. Reverse exactly the steps executed at suspend time: - Enable the power regulator in any case - Enable the transceiver regulator if the device was running, even in case we have a power regulator - Queue restart_work only in case the device was running Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Stefan Agner <stefan@agner.ch> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
If a valid power regulator or a dummy regulator is used (which
happens to be the case when no regulator is specified), restart_work
is queued no matter whether the device was running or not at suspend
time. Since work queues get initialized in the ndo_open callback,
resuming leads to a NULL pointer exception.

Reverse exactly the steps executed at suspend time:
- Enable the power regulator in any case
- Enable the transceiver regulator if the device was running, even in
  case we have a power regulator
- Queue restart_work only in case the device was running

Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: pcan_usb: don't touch skb after netif_rx() 2015-07-15T07:04:28+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 1c0ee046957648106b415df79038e4e62b144c19 There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: usb_8dev: don't touch skb after netif_rx() 2015-07-15T07:04:28+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 9b721a4cefcbdedadbe72b5ec405046c139cf8ad There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Bernd Krumboeck <b.krumboeck@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Bernd Krumboeck <b.krumboeck@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: ems_usb: don't touch skb after netif_rx() 2015-07-15T07:04:28+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 43c021e8d6844c4b0f5cc9eda10d232e7b87a456 There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: esd_usb2: don't touch skb after netif_rx() 2015-07-15T07:04:28+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 296decb6931fca0bbc0bfb26865837d52e287599 There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Thomas Körper <thomas.koerper@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: sja1000: don't touch skb after netif_rx() 2015-07-15T07:04:28+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 889dd06e107d816fe63ff65e5dd3466949878439 There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: cc770: don't touch skb after netif_rx() 2015-07-15T07:04:27+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 ef934e89f5e68535c447789b74de42cf389e55de There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: ti_heccn: don't touch skb after netif_rx() 2015-07-15T07:04:27+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 05c4456538e9551b8ac47762b21127bf9cf6cc8e There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Anant Gole <anantgole@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 
There is no guarantee that the skb is in the same state after calling
net_receive_skb() or netif_rx(). It might be freed or reused. Not really
harmful as its a read access, except you turn on the proper debugging options
which catch a use after free.

Cc: Anant Gole <anantgole@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>