| Age | Commit message (Collapse) | Author |
|---|
|
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
|
The current SocketCAN implementation for the Bosch c_can cell doesn't
account the TX bytes correctly, because it calls
c_can_inval_msg_object() (which clears the msg ctrl register) before
reading the DLC value:
for (/* nix */; (priv->tx_next - priv->tx_echo) > 0; priv->tx_echo++) {
msg_obj_no = get_tx_echo_msg_obj(priv);
c_can_inval_msg_object(dev, 0, msg_obj_no);
val = c_can_read_reg32(priv, &priv->regs->txrqst1);
if (!(val & (1 << msg_obj_no))) {
can_get_echo_skb(dev,
msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
stats->tx_bytes += priv->read_reg(priv,
&priv->regs->ifregs[0].msg_cntrl)
& IF_MCONT_DLC_MASK;
stats->tx_packets++;
}
}
So, we will always read 0 for the DLC value and "ifconfig" will report
*0* TX Bytes.
The fix is quite easy: Just move c_can_inval_msg_object() to the end of
the if() statement. So:
* We only call c_can_inval_msg_object() if the message was
actually transmitted
* We read out the DLC value _before_ clearing the msg ctrl
register
Signed-off-by: Jan Altenberg <jan@linutronix.de>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch fixes the check in the probe function whether a IRQ was supplied
to the driver. The original driver check the irq "struct resource *" against
<= 0. Use "platform_get_irq" instead.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch disables the one shot mode, until the driver has been fixed and
tested to support it.
> I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be
> pending, while msg_obj 18 and 19 already have been transmitted. But
> in that case, I enabled ONESHOT for the can interface, which enables
> the DA mode (automatic retransmission is disabled).
Reported-by: Jan Altenberg <jan@linutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I ran into some trouble while testing the SocketCAN driver for the BOSCH
C_CAN controller. The interface is not correctly initialized, if I put
some CAN traffic on the line, _while_ the interface is being started
(which means: the interface doesn't come up correcty, if there's some RX
traffic while doing 'ifconfig can0 up').
The current implementation enables the controller interrupts _before_
doing the basic c_can configuration. I think, this should be done the
other way round.
The patch below fixes things for me.
Signed-off-by: Jan Altenberg <jan@linutronix.de>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Bosch C_CAN controller is a full-CAN implementation which is compliant
to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be
obtained from:
http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/c_can/users_manual_c_can.pdf
This patch adds the support for this controller.
The following are the design choices made while writing the controller
driver:
1. Interface Register set IF1 has be used only in the current design.
2. Out of the 32 Message objects available, 16 are kept aside for RX
purposes and the rest for TX purposes.
3. NAPI implementation is such that both the TX and RX paths function
in polling mode.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
