can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig option
In 2b9aecdce2
("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: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This commit is contained in:
parent
4f337ed5c0
commit
524369e239
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue