linux.git/drivers/net/can, branch v4.2-rc7 Linux kernel source tree 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>
can: slcan: don't touch skb after netif_rx_ni() 2015-07-15T07:04:27+00:00 Marc Kleine-Budde mkl@pengutronix.de 2015-07-11T19:16:08+00:00 a2e78cf7a3f562edca4230b188c8832b6214eccd 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: 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: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>