renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2025-01-03 11:13:56 +08:00
Code

linux-can-fixes-for-3.15-20140519

Browse Source 
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iEYEABECAAYFAlN5r54ACgkQjTAFq1RaXHMB4ACbBiaiexMd4I86W/dClGc+XGkl
 ilMAnRjiukvQJyNjpM8oZ+7eAGMy5MSX
 =vR48
 -----END PGP SIGNATURE-----

Merge tag 'linux-can-fixes-for-3.15-20140519' of git://gitorious.org/linux-can/linux-can

Marc Kleine-Budde says:

====================
pull-request: can 2014-05-19

this is a pull request for net/master, for the v3.15 release cycle,
with a single patch.

Oliver Hartkopp's patch removes a Kconfig option in the c_can driver,
which was added as a workaround during the v3.15 development. With all
cleanup patches this workaround is not needed anymore.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
David S. Miller 2014-05-21 01:58:30 -04:00
commit d8d33c3b8a
2 changed files with 0 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
drivers/net/can/c_can/Kconfig
View File

@ -14,13 +14,6 @@ config CAN_C_CAN_PLATFORM
SPEAr1310 and SPEAr320 evaluation boards & TI (www.ti.com)
boards like am335x, dm814x, dm813x and dm811x.
config CAN_C_CAN_STRICT_FRAME_ORDERING
bool "Force a strict RX CAN frame order (may cause frame loss)"
---help---
The RX split buffer prevents packet reordering but can cause packet
loss. Only enable this option when you accept to lose CAN frames
in favour of getting the received CAN frames in the correct order.
config CAN_C_CAN_PCI
tristate "Generic PCI Bus based C_CAN/D_CAN driver"
depends on PCI

36
drivers/net/can/c_can/c_can.c
View File

@ -732,26 +732,12 @@ static u32 c_can_adjust_pending(u32 pend)
static inline void c_can_rx_object_get(struct net_device *dev,
struct c_can_priv *priv, u32 obj)
{
#ifdef CONFIG_CAN_C_CAN_STRICT_FRAME_ORDERING
if (obj < C_CAN_MSG_RX_LOW_LAST)
c_can_object_get(dev, IF_RX, obj, IF_COMM_RCV_LOW);
else
#endif
c_can_object_get(dev, IF_RX, obj, priv->comm_rcv_high);
}
static inline void c_can_rx_finalize(struct net_device *dev,
struct c_can_priv *priv, u32 obj)
{
#ifdef CONFIG_CAN_C_CAN_STRICT_FRAME_ORDERING
if (obj < C_CAN_MSG_RX_LOW_LAST)
priv->rxmasked |= BIT(obj - 1);
else if (obj == C_CAN_MSG_RX_LOW_LAST) {
priv->rxmasked = 0;
/* activate all lower message objects */
c_can_activate_all_lower_rx_msg_obj(dev, IF_RX);
}
#endif
if (priv->type != BOSCH_D_CAN)
c_can_object_get(dev, IF_RX, obj, IF_COMM_CLR_NEWDAT);
}
@ -799,9 +785,6 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
{
u32 pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
#ifdef CONFIG_CAN_C_CAN_STRICT_FRAME_ORDERING
pend &= ~priv->rxmasked;
#endif
return pend;
}
@ -814,25 +797,6 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
* has arrived. To work-around this issue, we keep two groups of message
* objects whose partitioning is defined by C_CAN_MSG_OBJ_RX_SPLIT.
*
* If CONFIG_CAN_C_CAN_STRICT_FRAME_ORDERING = y
*
* To ensure in-order frame reception we use the following
* approach while re-activating a message object to receive further
* frames:
* - if the current message object number is lower than
* C_CAN_MSG_RX_LOW_LAST, do not clear the NEWDAT bit while clearing
* the INTPND bit.
* - if the current message object number is equal to
* C_CAN_MSG_RX_LOW_LAST then clear the NEWDAT bit of all lower
* receive message objects.
* - if the current message object number is greater than
* C_CAN_MSG_RX_LOW_LAST then clear the NEWDAT bit of
* only this message object.
*
* This can cause packet loss!
*
* If CONFIG_CAN_C_CAN_STRICT_FRAME_ORDERING = n
*
* We clear the newdat bit right away.
*
* This can result in packet reordering when the readout is slow.