AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
register data for both.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.

To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.

To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.

Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

We want to have more data than just can_dev_id to be present
in the driver data e.g. TI platforms need RAMINIT register
description. Introduce the c_can_driver_data structure and move
the can_dev_id into it.

Tidy up the way it is used on probe().
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

TI's RAMINIT DONE mechanism is buggy on AM43xx SoC and may not always
be set after the START bit is set. Although it seems to work fine even
in that case. So add a timeout mechanism to c_can_hw_raminit_wait_ti().
Don't bail out in that failure case but just print an error message.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). They
seem to have been swapped in the usage instances.
Reported-by: NJay Schroeder <jay.schroeder@garmin.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

devm_ioremap() returns NULL on error, not an ERR_PTR().

Fixes: 33cf7565 ('can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource()')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: linux-stable <stable@vger.kernel.org> # >= v3.11
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

No need to manually copy debug settings into subdir Makefiles. kbuild
has a mechanism for inheriting, so let's use it.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to
meet kernel coding style guidelines.  This issue was reported by checkpatch.

A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):

// <smpl>

@@
identifier i;
declarer name DEFINE_PCI_DEVICE_TABLE;
initializer z;
@@

- DEFINE_PCI_DEVICE_TABLE(i)
+ const struct pci_device_id i[]
= z;

// </smpl>

[bhelgaas: add semantic patch]
Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The raminit register is shared register for both can0 and can1. Since commit:

    32766fff net: can: Convert to use devm_ioremap_resource

devm_ioremap_resource() is used to map raminit register. When using both
interfaces the mapping for the can1 interface fails, leading to a non
functional can interface.
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Cc: linux-stable <stable@vger.kernel.org> # >= v3.11
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch uses devm_* APIs as they are device managed and make code simpler.
Signed-off-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Non-TI chips (including socfpga) needs different raminit sequence. Implement
it.
Tested-by: NThor Thayer <tthayer@altera.com>
Signed-off-by: NThor Thayer <tthayer@altera.com>
Signed-off-by: NPavel Machek <pavel@denx.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add helpers for 32-bit accesses and replace open-coded 32-bit access
with calls to helpers. Minimum changes are done to the pci case, as I
don't have access to that hardware.
Tested-by: NThor Thayer <tthayer@altera.com>
Signed-off-by: NThor Thayer <tthayer@altera.com>
Signed-off-by: NPavel Machek <pavel@denx.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch makes the {read,write}_reg functions const, this is a preparation to
make use of {read,write}_reg in the hwinit callback.
Signed-off-by: NThor Thayer <tthayer@altera.com>
Signed-off-by: NPavel Machek <pavel@denx.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

In 2b9aecdc ("can: c_can: Disable rx split as workaround") a new Kconfig
option was introduced as a workaround. The tests performed by Alexander Stein
confirmed this option to be obsolete with all the other cleanups and fixes
that had been discussed that time:
http://marc.info/?l=linux-can&m=139746476821294&w=2

Both (author and tester) agreed to remove this Kconfig option again:
http://marc.info/?l=linux-can&m=139883820714229&w=2

As some more cleanups took place since then a simple revert is not possible.
This patch removes the entire option as it would behave when disabled.
Further beautification’s can be done later.
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Coverity complains that c_can_pci_probe() calls pci_enable_msi() without
checking the result:

CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return:
Calling pci_enable_msi_block without checking return value (as is done
elsewhere 88 out of 105 times).
 88        pci_enable_msi(pdev);

This is CID 712278.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
Reported-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Commit 6439fbce (can: c_can: fix error checking of priv->instance in
probe()) found the warning but applied a suboptimal solution. Since, both
pdev->id and of_alias_get_id() return integers, it makes sense to convert the
variable to an integer and avoid the cast.
Signed-off-by: NWolfram Sang <wsa@sang-engineering.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

It's suffcient to kill the TXIE bit in the message control register
even if the documentation of C and D CAN says that it's not allowed to
do that while MSGVAL is set. Reality tells a different story and this
change gives us another 2% of CPU back for not waiting on I/O.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Mark suggested to use one IF for the softirq and the other for the
xmit function to avoid the xmit lock.

That requires to write the frame into the interface first, then handle
the echo skb and store the dlc before committing the TX request to the
message ram.

We use an atomic to handle the active buffers instead of reading the
MSGVAL register as thats way faster especially on PCH/x86.
Suggested-by: NMark <mark5@del-llc.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Instead of obfuscating the code by artificial 16 bit splits use the
proper 32 bit assignments and split the result when writing to the
interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Remove the MASK from the TX transfer side.

Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT
macros which are just obfuscating the code.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Sigh!
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Alexander reported that the new optimized handling of the RX fifo
causes random packet loss on Intel PCH C_CAN hardware.

After a few fruitless debugging sessions I got hold of a PCH (eg20t)
afflicted system. That machine does not have the CAN interface wired
up, but it was possible to reproduce the issue with the HW loopback
mode.

As Alexander observed correctly, clearing the NewDat flag along with
reading out the message buffer causes that issue on C_CAN, while D_CAN
handles that correctly.

Instead of restoring the original message buffer handling horror the
following workaround solves the issue:

    transfer buffer to IF without clearing the NewDat
    handle the message
    clear NewDat bit

That's similar to the original code but conditional for C_CAN.

I really wonder why all user manuals (C_CAN, Intel PCH and some more)
recommend to clear the NewDat bit right away. The knows it all Oracle
operated by Gurgle does not unearth any useful information either. I
simply cannot believe that we are the first to uncover that HW issue.
Reported-and-tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The RX buffer split causes packet loss in the hardware:

What happens is:

RX Packet 1 --> message buffer 1 (newdat bit is not cleared)
RX Packet 2 --> message buffer 2 (newdat bit is not cleared)
RX Packet 3 --> message buffer 3 (newdat bit is not cleared)
RX Packet 4 --> message buffer 4 (newdat bit is not cleared)
RX Packet 5 --> message buffer 5 (newdat bit is not cleared)
RX Packet 6 --> message buffer 6 (newdat bit is not cleared)
RX Packet 7 --> message buffer 7 (newdat bit is not cleared)
RX Packet 8 --> message buffer 8 (newdat bit is not cleared)

Clear newdat bit in message buffer 1
Clear newdat bit in message buffer 2
Clear newdat bit in message buffer 3
Clear newdat bit in message buffer 4
Clear newdat bit in message buffer 5
Clear newdat bit in message buffer 6
Clear newdat bit in message buffer 7
Clear newdat bit in message buffer 8

Now if during that clearing of newdat bits, a new message comes in,
the HW gets confused and drops it.

It does not matter how many of them you clear. I put a delay between
clear of buffer 1 and buffer 2 which was long enough that the message
should have been queued either in buffer 1 or buffer 9. But it did not
show up anywhere. The next message ended up in buffer 1. So the
hardware lost a packet of course without telling it via one of the
error handlers.

That does not happen on all clear newdat bit events. I see one of 10k
packets dropped in the scenario which allows us to reproduce. But the
trace looks always the same.

Not splitting the RX Buffer avoids the packet loss but can cause
reordering. It's hard to trigger, but it CAN happen.

With that mode we use the HW as it was probably designed for. We read
from the buffer 1 upwards and clear the buffer as we get the
message. That's how all microcontrollers use it. So I assume that the
way we handle the buffers was never really tested. According to the
public documentation it should just work :)

Let the user decide which evil is the lesser one.

[ Oliver Hartkopp: Provided a sane config option and help text and
  made me switch to favour potential and unlikely reordering over
  packet loss ]
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The driver handles pointlessly TWO interrupts per packet. The reason
is that it enables the status interrupt which fires for each rx and tx
packet and it enables the per message object interrupts as well.

The status interrupt merily acks or in case of D_CAN ignores the TX/RX
state and then the message object interrupt fires.

The message objects interrupts are only useful if all message objects
have hardware filters activated.

But we don't have that and its not simple to implement in that driver
without rewriting it completely.

So we can ditch the message object interrupts and handle the RX/TX
right away from the status interrupt. Instead of TWO we handle ONE.

Note: We must keep the TXIE/RXIE bits in the message buffers because
the status interrupt alone is not reliable enough in corner cases.

If we ever have the need for HW filtering, then this code needs a
complete overhaul and we can think about it then. For now we prefer a
lower interrupt load.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

On D_CAN the RXOK, TXOK and LEC bits are cleared/set on read of the
status register. No need to update them.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Instead of writing to the message object we can simply clear the
NewDat bit with the get method.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

If the allocation of the error skb fails, we still want to see the
error statistics.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Reading the LEC type with

  return (mode & ENABLED) && (status & LEC_MASK);

is not guaranteed to return (status & LEC_MASK) if the enabled bit in
mode is set. It's guaranteed to return 0 or !=0.

Remove the inline function and call unconditionally into the
berr_handling code and return early when the reporting is disabled.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

If the allocation of an error skb fails, the state change handling
returns w/o doing any work. That leaves the interface in a wreckaged
state as the internal status is wrong.

Split the interface handling and the skb handling.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

There is no guarantee that the skb is in the same state after calling
net_receive_skb(). 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.

The whole can subsystem is full of this. Copy and paste ....
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The state change handler is called with device interrupts disabled
already. So no point in disabling them again when we enter bus off
state.

But what's worse is that we reenable the interrupts at the end of NAPI
poll unconditionally. So c_can_start() which is called from the
restart timer can trigger interrupts which confuse the hell out of the
half reinitialized driver/hw.

Remove the pointless device interrupt disable in the BUS_OFF handler
and prevent reenabling the device interrupts at the end of the poll
routine when the current state is BUS_OFF.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>