linux-toradex.git/drivers/net/can, branch v3.0.44

can: janz-ican3: fix support for older hardware revisions

2012-10-02T16:47:37+00:00

commit e21093ef6fb4cbecdf926102286dbe280ae965db upstream.

The Revision 1.0 Janz CMOD-IO Carrier Board does not have support for
the reset registers. To support older hardware, the code is changed to
use the hardware reset register on the Janz VMOD-ICAN3 hardware itself.

Signed-off-by: Ira W. Snyder 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: ti_hecc: fix oops during rmmod

2012-10-02T16:47:36+00:00

commit ab04c8bd423edb03e2148350a091836c196107fc upstream.

This patch fixes an oops which occurs when unloading the driver, while the
network interface is still up. The problem is that first the io mapping is
teared own, then the CAN device is unregistered, resulting in accessing the
hardware's iomem:

[  172.744232] Unable to handle kernel paging request at virtual address c88b0040
[  172.752441] pgd = c7be4000
[  172.755645] [c88b0040] *pgd=87821811, *pte=00000000, *ppte=00000000
[  172.762207] Internal error: Oops: 807 [#1] PREEMPT ARM
[  172.767517] Modules linked in: ti_hecc(-) can_dev
[  172.772430] CPU: 0    Not tainted  (3.5.0alpha-00037-g3554cc0 #126)
[  172.778961] PC is at ti_hecc_close+0xb0/0x100 [ti_hecc]
[  172.784423] LR is at __dev_close_many+0x90/0xc0
[  172.789123] pc : []    lr : []    psr: 60000013
[  172.789123] sp : c5c1de68  ip : 00040081  fp : 00000000
[  172.801025] r10: 00000001  r9 : c5c1c000  r8 : 00100100
[  172.806457] r7 : c5d0a48c  r6 : c5d0a400  r5 : 00000000  r4 : c5d0a000
[  172.813232] r3 : c88b0000  r2 : 00000001  r1 : c5d0a000  r0 : c5d0a000
[  172.820037] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  172.827423] Control: 10c5387d  Table: 87be4019  DAC: 00000015
[  172.833404] Process rmmod (pid: 600, stack limit = 0xc5c1c2f0)
[  172.839447] Stack: (0xc5c1de68 to 0xc5c1e000)
[  172.843994] de60:                   bf00c6b8 c5c1dec8 c5d0a000 c5d0a000 00200200 c033be58
[  172.852478] de80: c5c1de44 c5c1dec8 c5c1dec8 c033bf2c c5c1de90 c5c1de90 c5d0a084 c5c1de44
[  172.860992] dea0: c5c1dec8 c033c098 c061d3dc c5d0a000 00000000 c05edf28 c05edb34 c000d724
[  172.869476] dec0: 00000000 c033c2f8 c5d0a084 c5d0a084 00000000 c033c370 00000000 c5d0a000
[  172.877990] dee0: c05edb00 c033c3b8 c5d0a000 bf00d3ac c05edb00 bf00d7c8 bf00d7c8 c02842dc
[  172.886474] df00: c02842c8 c0282f90 c5c1c000 c05edb00 bf00d7c8 c0283668 bf00d7c8 00000000
[  172.894989] df20: c0611f98 befe2f80 c000d724 c0282d10 bf00d804 00000000 00000013 c0068a8c
[  172.903472] df40: c5c538e8 685f6974 00636365 c61571a8 c5cb9980 c61571a8 c6158a20 c00c9bc4
[  172.911987] df60: 00000000 00000000 c5cb9980 00000000 c5cb9980 00000000 c7823680 00000006
[  172.920471] df80: bf00d804 00000880 c5c1df8c 00000000 000d4267 befe2f80 00000001 b6d90068
[  172.928985] dfa0: 00000081 c000d5a0 befe2f80 00000001 befe2f80 00000880 b6d90008 00000008
[  172.937469] dfc0: befe2f80 00000001 b6d90068 00000081 00000001 00000000 befe2eac 00000000
[  172.945983] dfe0: 00000000 befe2b18 00023ba4 b6e6addc 60000010 befe2f80 a8e00190 86d2d344
[  172.954498] [] (ti_hecc_close+0xb0/0x100 [ti_hecc]) from [] (__dev__registered_many+0xc0/0x2a0)
[  172.984161] [] (rollback_registered_many+0xc0/0x2a0) from [] (rollback_registered+0x20/0x30)
[  172.994750] [] (rollback_registered+0x20/0x30) from [] (unregister_netdevice_queue+0x68/0x98)
[  173.005401] [] (unregister_netdevice_queue+0x68/0x98) from [] (unregister_netdev+0x18/0x20)
[  173.015899] [] (unregister_netdev+0x18/0x20) from [] (ti_hecc_remove+0x60/0x80 [ti_hecc])
[  173.026245] [] (ti_hecc_remove+0x60/0x80 [ti_hecc]) from [] (platform_drv_remove+0x14/0x18)
[  173.036712] [] (platform_drv_remove+0x14/0x18) from [] (__device_release_driver+0x7c/0xbc)

Tested-by: Jan Luebbe 
Cc: Anant Gole 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: mcp251x: avoid repeated frame bug

2012-10-02T16:47:26+00:00

commit cab32f39dcc5b35db96497dc0a026b5dea76e4e7 upstream.

The MCP2515 has a silicon bug causing repeated frame transmission, see section
5 of MCP2515 Rev. B Silicon Errata Revision G (March 2007).

Basically, setting TXBnCTRL.TXREQ in either SPI mode (00 or 11) will eventually
cause the bug. The workaround proposed by Microchip is to use mode 00 and send
a RTS command on the SPI bus to initiate the transmission.

Signed-off-by: Benoît Locher 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: c_can: precedence error in c_can_chip_config()

2012-07-16T15:47:48+00:00

commit d9cb9bd63eb27ac19f26a8547128c053f43a5da8 upstream.

(CAN_CTRLMODE_LISTENONLY & CAN_CTRLMODE_LOOPBACK) is (0x02 & 0x01) which
is zero so the condition is never true.  The intent here was to test
that both flags were set.

Signed-off-by: Dan Carpenter 
Acked-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

can: c_can: fix race condition in c_can_open()

2012-06-17T18:23:11+00:00

commit f461f27a4436dbe691908fe08b867ef888848cc3 upstream.

Fix the issue of C_CAN interrupts getting disabled forever when canconfig
utility is used multiple times. According to NAPI usage we disable all
the hardware interrupts in ISR and re-enable them in poll(). Current
implementation calls napi_enable() after hardware interrupts are enabled.
If we get any interrupts between these two steps then we do not process
those interrupts because napi is not enabled. Mostly these interrupts
come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
happens before HW interrupts enabled then c_can_poll() function will be
called eventual re-enabling.

This patch moves the napi_enable() call before interrupts enabled.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: c_can: fix an interrupt thrash issue with c_can driver

2012-06-17T18:23:11+00:00

commit 148c87c89e1a8863d3d965179f3ab1a06490569e upstream.

This patch fixes an interrupt thrash issue with c_can driver.

In c_can_isr() function interrupts are disabled and enabled only in
c_can_poll() function. c_can_isr() & c_can_poll() both read the
irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
because all C_CAN interrupts are disabled in c_can_isr(). This causes
all interrupts to be re-enabled in c_can_poll() which in turn causes
another interrupt since the event is not really handled. This keeps
happening causing a flood of interrupts.

To fix this, read the irqstatus register in isr and use the same cached
value in the poll function.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: c_can: fix "BUG! echo_skb is occupied!" during transmit

2012-06-17T18:23:11+00:00

commit 617caccebe451716df21c069b079d5936ed7b0f3 upstream.

This patch fixes an issue with transmit routine, which causes
"can_put_echo_skb: BUG! echo_skb is occupied!" message when
using "cansequence -p" on D_CAN controller.

In c_can driver, while transmitting packets tx_echo flag holds
the no of can frames put for transmission into the hardware.

As the comment above c_can_do_tx() indicates, if we find any packet
which is not transmitted then we should stop looking for more.
In the current implementation this is not taken care of causing the
said message.

Also, fix the condition used to find if the packet is transmitted
or not. Current code skips the first tx message object and ends up
checking one extra invalid object.

While at it, fix the comment on top of c_can_do_tx() to use the
terminology "packet" instead of "package" since it is more
standard.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

net/can: activate bit-timing calculation and netlink based drivers by default

2011-06-29T12:58:42+00:00

The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".

Signed-off-by: Marc Kleine-Budde 
Acked-by: Wolfgang Grandegger 
Acked-by: Kurt Van Dijck 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

2011-06-04T14:16:00+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (40 commits)
  tg3: Fix tg3_skb_error_unmap()
  net: tracepoint of net_dev_xmit sees freed skb and causes panic
  drivers/net/can/flexcan.c: add missing clk_put
  net: dm9000: Get the chip in a known good state before enabling interrupts
  drivers/net/davinci_emac.c: add missing clk_put
  af-packet: Add flag to distinguish VID 0 from no-vlan.
  caif: Fix race when conditionally taking rtnl lock
  usbnet/cdc_ncm: add missing .reset_resume hook
  vlan: fix typo in vlan_dev_hard_start_xmit()
  net/ipv4: Check for mistakenly passed in non-IPv4 address
  iwl4965: correctly validate temperature value
  bluetooth l2cap: fix locking in l2cap_global_chan_by_psm
  ath9k: fix two more bugs in tx power
  cfg80211: don't drop p2p probe responses
  Revert "net: fix section mismatches"
  drivers/net/usb/catc.c: Fix potential deadlock in catc_ctrl_run()
  sctp: stop pending timers and purge queues when peer restart asoc
  drivers/net: ks8842 Fix crash on received packet when in PIO mode.
  ip_options_compile: properly handle unaligned pointer
  iwlagn: fix incorrect PCI subsystem id for 6150 devices
  ...

Revert "tty: make receive_buf() return the amout of bytes received"

2011-06-03T21:33:24+00:00

This reverts commit b1c43f82c5aa265442f82dba31ce985ebb7aa71c.

It was broken in so many ways, and results in random odd pty issues.

It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41af6a: "tty: fix endless
work loop when the buffer fills up").

It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.

And it didn't actually work at all.  BenH bisected down odd tty behavior
to it:
  "It looks like the patch is causing some major malfunctions of the X
   server for me, possibly related to PTYs.  For example, cat'ing a
   large file in a gnome terminal hangs the kernel for -minutes- in a
   loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
   data in the quoted bits further down).

   ...

   Some more data: It -looks- like what happens is that the
   flush_to_ldisc work queue entry constantly re-queues itself (because
   the PTY is full ?) and the workqueue thread will basically loop
   forver calling it without ever scheduling, thus starving the consumer
   process that could have emptied the PTY."

which is pretty much exactly the problem we fixed in a5660b41af6a.

Milton Miller pointed out the 'unsigned int' issue.

Reported-by: Benjamin Herrenschmidt 
Reported-by: Milton Miller 
Cc: Stefan Bigler 
Cc: Toby Gray 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Alan Cox 
Signed-off-by: Linus Torvalds