The spec mentions there may be a delay until the value written to
INIT can be read back due to the synchronization mechanism between the
two clock domains. But it does not indicate the exact clock cycles needed.
The 5us delay is a test value and seems ok.
Without the delay, CCCR.CCE bit may fail to be set and then the
initialization fail sometimes when do repeatly up and down.
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 1 +
1 file changed, 1 insertion(+)
The spec mentions there may be a delay until the value written to
INIT can be read back due to the synchronization mechanism between the
two clock domains. But it does not indicate the exact clock cycles needed.
The 5us delay is a test value and seems ok.
Without the delay, CCCR.CCE bit may fail to be set and then the
initialization fail sometimes when do repeatly up and down.
Signed-off-by: Dong Aisheng <redacted>
Applied to can/master.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.
This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/dev.c | 1 +
1 file changed, 1 insertion(+)
Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.
This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.
Oliver, what do you think of this patch? It will introduce a subtle
change to the userspace.
Marc
Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.
This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.
Oliver, what do you think of this patch? It will introduce a subtle
change to the userspace.
Hi Marc,
indeed the current policy is that ifdown/ifup doesn't change any setting.
When we start to clear priv->ctrlmode when setting the interface down the
question arises whether the bitrate(s) has/have to be wiped too.
Setting the interface down/up can be done with ip or ifconfig without changing
the controller settings.
So IMO we can not assume that people always use the 'all-in-one'
ip link set can0 up type can0 bitrate 1000000
command as given in the example above.
You might also do it like this:
ip link set can0 up type can0 bitrate 1000000 loopback on
ip link set can0 down
ip link set can0 type can0 loopback off
ip link set can0 up
Finally I would vote to reject this patch to stay consistent.
When users like to fiddle with options like loopback they need to take care
about their 'expert' settings too.
Regards,
Oliver
Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.
This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.
Signed-off-by: Dong Aisheng <redacted>
NACK, as discussed with Oliver.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
On Mon, Nov 03, 2014 at 09:47:22PM +0100, Marc Kleine-Budde wrote:
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
quoted
Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.
This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.
Signed-off-by: Dong Aisheng <redacted>
NACK, as discussed with Oliver.
Okay, i'm fine with it.
Regards
Dong Aisheng
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Bosch M_CAN is CAN FD capable device.
This patch implements the CAN FD features include up to 64 bytes
payload and bitrate switch function.
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 138 +++++++++++++++++++++++++++++++++---------
1 file changed, 110 insertions(+), 28 deletions(-)
@@ -327,11 +357,12 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)m_can_write(priv,M_CAN_ILE,0x0);}-staticvoidm_can_read_fifo(conststructnet_device*dev,structcan_frame*cf,+staticvoidm_can_read_fifo(conststructnet_device*dev,structcanfd_frame*cf,u32rxfs){structm_can_priv*priv=netdev_priv(dev);u32id,fgi;+inti;/* calculate the fifo get index for where to read data */fgi=(rxfs&RXFS_FGI_MASK)>>RXFS_FGI_OFF;
@@ -778,8 +840,8 @@ static void m_can_chip_config(struct net_device *dev)m_can_config_endisable(priv,true);-/* RX Buffer/FIFO Element Size 8 bytes data field */-m_can_write(priv,M_CAN_RXESC,M_CAN_RXESC_8BYTES);+/* RX Buffer/FIFO Element Size 64 bytes data field */+m_can_write(priv,M_CAN_RXESC,M_CAN_RXESC_64BYTES);/* Accept Non-matching Frames Into FIFO 0 */m_can_write(priv,M_CAN_GFC,0x0);
@@ -788,8 +850,8 @@ static void m_can_chip_config(struct net_device *dev)m_can_write(priv,M_CAN_TXBC,(1<<TXBC_NDTB_OFF)|priv->mcfg[MRAM_TXB].off);-/* only support 8 bytes firstly */-m_can_write(priv,M_CAN_TXESC,TXESC_TBDS_8BYTES);+/* support 64 bytes payload */+m_can_write(priv,M_CAN_TXESC,TXESC_TBDS_64BYTES);m_can_write(priv,M_CAN_TXEFC,(1<<TXEFC_EFS_OFF)|priv->mcfg[MRAM_TXE].off);
Hello Dong,
thanks for your update to support CAN FD with the 3.0.x M_CAN IP core.
AFAIK from the last CAN in Automation (CiA) Plugfest which took place in
Nuremberg yesterday, there are two more IP cores on the way:
v3.0.1 / v3.0.2 (the current spec from the Bosch website)
v3.1.0 which will support per-frame CAN/CANFD switching in the tx path
(the FDF/(former)EDL bit and the BRS bit appear in the TX buffer element at
the bit position you know from reading the RX FIFO element)
v3.2.0 which will support the final(?) ISO specification with a bitstuffing
counter before the CRC in the frame on the wire.
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
Regarding the CAN FD support in this patch I have some remarks in the text ...
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
@@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota) if (rxfs & RXFS_RFL) netdev_warn(dev, "Rx FIFO 0 Message Lost\n");- skb = alloc_can_skb(dev, &frame);+ skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
Hello Dong,
thanks for your update to support CAN FD with the 3.0.x M_CAN IP core.
AFAIK from the last CAN in Automation (CiA) Plugfest which took place in
Nuremberg yesterday, there are two more IP cores on the way:
v3.0.1 / v3.0.2 (the current spec from the Bosch website)
v3.1.0 which will support per-frame CAN/CANFD switching in the tx path
(the FDF/(former)EDL bit and the BRS bit appear in the TX buffer element at
the bit position you know from reading the RX FIFO element)
v3.2.0 which will support the final(?) ISO specification with a bitstuffing
counter before the CRC in the frame on the wire.
Sounds good.
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
One question is that if v3.1.0 and v3.2.0 will be backward compatible with
v3.0.1, if yes, how about let the driver still work for them instead of
simply quit?
And then we can add new features according new released IP version.
Regarding the CAN FD support in this patch I have some remarks in the text ...
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
@@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota) if (rxfs & RXFS_RFL) netdev_warn(dev, "Rx FIFO 0 Message Lost\n");- skb = alloc_can_skb(dev, &frame);+ skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Yes, currently it is.
The test seemed ok using CAN FD frames even receive normal frame.
The issue i know is that candump seemed can not recognize remote frame reported
by the driver.
Not sure if it's caused by canfd_frame used.
Will test and check.
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
Yes, i think it's good to do that.
One obvious benefit is it saves memory at least.
On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
quoted
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
One question is that if v3.1.0 and v3.2.0 will be backward compatible with
v3.0.1, if yes, how about let the driver still work for them instead of
simply quit?
There are several important differences between 3.0.x and 3.1.x.
E.g. the CCCR, BTP, PSR and others are changed and a register for the
transmitter delay compensation is added.
I assume from 3.1.x to 3.2.x the controller registers will only change in
small details as the main update will be on the wire and not in the functionality.
And then we can add new features according new released IP version.
Yes. We probably can wait for 3.[12].x to become available before adding the
special code that behaves according the core release register content.
quoted
quoted
@@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota) if (rxfs & RXFS_RFL) netdev_warn(dev, "Rx FIFO 0 Message Lost\n");- skb = alloc_can_skb(dev, &frame);+ skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Yes, currently it is.
The test seemed ok using CAN FD frames even receive normal frame.
When you put CAN frame content into a CAN FD skb it becomes a CAN FD frame -
which is wrong.
CAN 2.0 frame (EDL is clear) -> alloc_can_skb()
CAN FD frame (EDL is set) -> alloc_canfd_skb()
You can have a CAN FD frame with a DLC of 8, which does *not* mean that you
have a CAN 2.0 frame.
The issue i know is that candump seemed can not recognize remote frame reported
by the driver.
Do you use the latest candump from
https://gitorious.org/linux-can/can-utils/
??
The latest candump switches the CAN_RAW socket into the mode to accept both
CAN *and* CAN FD frames and displays the frames correctly.
Not sure if it's caused by canfd_frame used.
Yes. CAN FD frames do not have a RTR bit.
Will test and check.
quoted
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
Yes, i think it's good to do that.
One obvious benefit is it saves memory at least.
The main point is that CAN frames and CAN FD frames are separated by this
(MTU) length information. It's not about saving memory.
A CAN FD frame with DLC 8 still has 64 data bytes inside it's data structure.
Regards,
Oliver
On Thu, Oct 30, 2014 at 09:32:49PM +0100, Oliver Hartkopp wrote:
On 10/30/2014 03:42 AM, Dong Aisheng wrote:
quoted
On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
quoted
quoted
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
One question is that if v3.1.0 and v3.2.0 will be backward compatible with
v3.0.1, if yes, how about let the driver still work for them instead of
simply quit?
There are several important differences between 3.0.x and 3.1.x.
E.g. the CCCR, BTP, PSR and others are changed and a register for the
transmitter delay compensation is added.
I assume from 3.1.x to 3.2.x the controller registers will only change in
small details as the main update will be on the wire and not in the functionality.
quoted
And then we can add new features according new released IP version.
Yes. We probably can wait for 3.[12].x to become available before adding the
special code that behaves according the core release register content.
Okay
quoted
quoted
quoted
@@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota) if (rxfs & RXFS_RFL) netdev_warn(dev, "Rx FIFO 0 Message Lost\n");- skb = alloc_can_skb(dev, &frame);+ skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Yes, currently it is.
The test seemed ok using CAN FD frames even receive normal frame.
When you put CAN frame content into a CAN FD skb it becomes a CAN FD frame -
which is wrong.
CAN 2.0 frame (EDL is clear) -> alloc_can_skb()
CAN FD frame (EDL is set) -> alloc_canfd_skb()
You can have a CAN FD frame with a DLC of 8, which does *not* mean that you
have a CAN 2.0 frame.
quoted
The issue i know is that candump seemed can not recognize remote frame reported
by the driver.
Do you use the latest candump from
Yes, i'm using latest candump.
https://gitorious.org/linux-can/can-utils/
??
The latest candump switches the CAN_RAW socket into the mode to accept both
CAN *and* CAN FD frames and displays the frames correctly.
quoted
Not sure if it's caused by canfd_frame used.
Yes. CAN FD frames do not have a RTR bit.
You're right.
It's indeed caused by using the CAN FD frames to receive RTR frame.
After switch to normal frame, candump showed it well.
quoted
Will test and check.
quoted
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
Yes, i think it's good to do that.
One obvious benefit is it saves memory at least.
The main point is that CAN frames and CAN FD frames are separated by this
(MTU) length information. It's not about saving memory.
A CAN FD frame with DLC 8 still has 64 data bytes inside it's data structure.
For normal can frame, the CAN_MAX_DLEN is 8 while CANFD_MAX_DLEN is 64.
So i meant using struct canfd_frame to receive normal frame is a bit waste memory.
And besides, actually it's wrong as you already indicated.
I will send out the updated patch with this changed in v2 soon.
Thanks for pointing out this.
Regards
Dong Aisheng
We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,m_can_fifo_write(priv,0,M_CAN_FIFO_ID,id);m_can_fifo_write(priv,0,M_CAN_FIFO_DLC,can_len2dlc(cf->len)<<16);-for(i=0;i<cf->len;i+=4)+for(i=0;i<cf->len;i+=4){m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4),*(u32*)(cf->data+i));+/* FIXME: we meet an IC issue that we have to write the full 8+*bytes(whatevervalueforthesecondword)inMessageRAMto+*avoidbiterrorfortransmitdatalessthan4bytes+*/+if(cf->len<=4)+m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4+1),+0x0);+}+can_put_echo_skb(skb,dev,0);if(priv->can.ctrlmode&CAN_CTRLMODE_FD){
We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.
Is this a SoC or a m_can problem? Are all versions of the SoC/m_can
affected? Is there a m_can version register somewhere?
quoted hunk
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,m_can_fifo_write(priv,0,M_CAN_FIFO_ID,id);m_can_fifo_write(priv,0,M_CAN_FIFO_DLC,can_len2dlc(cf->len)<<16);-for(i=0;i<cf->len;i+=4)+for(i=0;i<cf->len;i+=4){m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4),*(u32*)(cf->data+i));+/* FIXME: we meet an IC issue that we have to write the full 8
FIXME usually indicates that the driver needs some work here. Just
describe your hardware bug, you might add a reference to an errata if
available, though.
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes
+ */
+ if (cf->len <= 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4 + 1),
+ 0x0);
This workaround doesn't handle the dlc == 0 case, your error description
isn't completely if this is a problem, too.
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
On Mon, Nov 03, 2014 at 05:48:17PM +0100, Marc Kleine-Budde wrote:
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
quoted
We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.
Is this a SoC or a m_can problem? Are all versions of the SoC/m_can
affected? Is there a m_can version register somewhere?
I'm still not sure it's SoC or m_can problem.
Our IC guys ran the simulation code and found this issue.
But due to some reasons, it may be very slow for they to investigate
and get the conclusion.
quoted
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,m_can_fifo_write(priv,0,M_CAN_FIFO_ID,id);m_can_fifo_write(priv,0,M_CAN_FIFO_DLC,can_len2dlc(cf->len)<<16);-for(i=0;i<cf->len;i+=4)+for(i=0;i<cf->len;i+=4){m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4),*(u32*)(cf->data+i));+/* FIXME: we meet an IC issue that we have to write the full 8
FIXME usually indicates that the driver needs some work here. Just
describe your hardware bug, you might add a reference to an errata if
available, though.
We don't have an errata for it now.
Because i'm not sure this is the final workaround and also not sure if other
SoC vendors having the same issue, so i used FIXME here firstly.
Since the code is harmless, so i wish we could put it here first
until we find evidence no need for other SoC or only belong to specific
IP version.
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes
+ */
+ if (cf->len <= 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4 + 1),
+ 0x0);
This workaround doesn't handle the dlc == 0 case, your error description
isn't completely if this is a problem, too.
You're right.
I just checked the dlc == 0 case also had such issue and it also needs
the extra 8 bytes write to avoid such issue.
BTW the issue only happened on the first time when you send a frame with no
data(dlc == 0) at the first time.
e.g.
root@imx6sxsabresd:~# ip link set can0 up type can bitrate 1000000
[ 62.326014] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6sxsabresd:~# cansend can0 123#R
[ 69.233645] m_can 20e8000.can can0: Bit Error Uncorrected
[ 69.239167] m_can 20e8000.can can0: Bit Error Corrected
If we send a frame success first (e.g. 5 bytes data), it will not fail
again even you send no data frame (dlc == 0) later.
The former failure of sending data less than 4 bytes is similar.
Looks like the first 8 bytes of message ram has to be initialised
for the first using.
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
Yes, i tried to fix it as follows.
/* FIXME: we meet an IC issue that we have to write the full 8
* bytes (whatever value for the second word) in Message RAM to
* avoid bit error for transmit data less than 4 bytes
*/
if (cf->len <= 4) {
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
*(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
*(u32 *)(cf->data + 4));
} else {
for (i = 0; i < cf->len; i += 4)
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
*(u32 *)(cf->data + i));
Will update the patch.
Regards
Dong Aisheng
We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.
Is this a SoC or a m_can problem? Are all versions of the SoC/m_can
affected? Is there a m_can version register somewhere?
I'm still not sure it's SoC or m_can problem.
Our IC guys ran the simulation code and found this issue.
But due to some reasons, it may be very slow for they to investigate
and get the conclusion.
Let's hope they will find the root cause of this problem.
quoted
quoted
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,m_can_fifo_write(priv,0,M_CAN_FIFO_ID,id);m_can_fifo_write(priv,0,M_CAN_FIFO_DLC,can_len2dlc(cf->len)<<16);-for(i=0;i<cf->len;i+=4)+for(i=0;i<cf->len;i+=4){m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4),*(u32*)(cf->data+i));+/* FIXME: we meet an IC issue that we have to write the full 8
FIXME usually indicates that the driver needs some work here. Just
describe your hardware bug, you might add a reference to an errata if
available, though.
We don't have an errata for it now.
Because i'm not sure this is the final workaround and also not sure if other
SoC vendors having the same issue, so i used FIXME here firstly.
Since the code is harmless, so i wish we could put it here first
until we find evidence no need for other SoC or only belong to specific
IP version.
It's better to write this in the comment than a FIXME, which is much
harder to interpret....
quoted
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes
+ */
+ if (cf->len <= 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4 + 1),
+ 0x0);
This workaround doesn't handle the dlc == 0 case, your error description
isn't completely if this is a problem, too.
You're right.
I just checked the dlc == 0 case also had such issue and it also needs
the extra 8 bytes write to avoid such issue.
BTW the issue only happened on the first time when you send a frame with no
data(dlc == 0) at the first time.
e.g.
root@imx6sxsabresd:~# ip link set can0 up type can bitrate 1000000
[ 62.326014] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6sxsabresd:~# cansend can0 123#R
[ 69.233645] m_can 20e8000.can can0: Bit Error Uncorrected
[ 69.239167] m_can 20e8000.can can0: Bit Error Corrected
If we send a frame success first (e.g. 5 bytes data), it will not fail
again even you send no data frame (dlc == 0) later.
The former failure of sending data less than 4 bytes is similar.
Looks like the first 8 bytes of message ram has to be initialised
for the first using.
What about putting
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
into the open() function? Can you ask the hardware colleges if this is a
functional workaround.
quoted
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
Yes, i tried to fix it as follows.
/* FIXME: we meet an IC issue that we have to write the full 8
* bytes (whatever value for the second word) in Message RAM to
* avoid bit error for transmit data less than 4 bytes
*/
if (cf->len <= 4) {
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
*(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
*(u32 *)(cf->data + 4));
} else {
for (i = 0; i < cf->len; i += 4)
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
*(u32 *)(cf->data + i));
Will update the patch.
Both branches of the above if are doing the same thing, I think you can
replace the while if ... else ... for with this:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
However if writing to DATA(0) and DATA(1) once in the open() function is
enough this code should stay as it is.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
On Tue, Nov 04, 2014 at 10:22:16AM +0100, Marc Kleine-Budde wrote:
On 11/04/2014 09:25 AM, Dong Aisheng wrote:
quoted
quoted
quoted
We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.
Is this a SoC or a m_can problem? Are all versions of the SoC/m_can
affected? Is there a m_can version register somewhere?
quoted
I'm still not sure it's SoC or m_can problem.
Our IC guys ran the simulation code and found this issue.
But due to some reasons, it may be very slow for they to investigate
and get the conclusion.
Let's hope they will find the root cause of this problem.
quoted
quoted
quoted
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <redacted>
---
drivers/net/can/m_can/m_can.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,m_can_fifo_write(priv,0,M_CAN_FIFO_ID,id);m_can_fifo_write(priv,0,M_CAN_FIFO_DLC,can_len2dlc(cf->len)<<16);-for(i=0;i<cf->len;i+=4)+for(i=0;i<cf->len;i+=4){m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(i/4),*(u32*)(cf->data+i));+/* FIXME: we meet an IC issue that we have to write the full 8
FIXME usually indicates that the driver needs some work here. Just
describe your hardware bug, you might add a reference to an errata if
available, though.
We don't have an errata for it now.
Because i'm not sure this is the final workaround and also not sure if other
SoC vendors having the same issue, so i used FIXME here firstly.
Since the code is harmless, so i wish we could put it here first
until we find evidence no need for other SoC or only belong to specific
IP version.
It's better to write this in the comment than a FIXME, which is much
harder to interpret....
quoted
quoted
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes
+ */
+ if (cf->len <= 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4 + 1),
+ 0x0);
This workaround doesn't handle the dlc == 0 case, your error description
isn't completely if this is a problem, too.
quoted
You're right.
I just checked the dlc == 0 case also had such issue and it also needs
the extra 8 bytes write to avoid such issue.
BTW the issue only happened on the first time when you send a frame with no
data(dlc == 0) at the first time.
e.g.
root@imx6sxsabresd:~# ip link set can0 up type can bitrate 1000000
[ 62.326014] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6sxsabresd:~# cansend can0 123#R
[ 69.233645] m_can 20e8000.can can0: Bit Error Uncorrected
[ 69.239167] m_can 20e8000.can can0: Bit Error Corrected
If we send a frame success first (e.g. 5 bytes data), it will not fail
again even you send no data frame (dlc == 0) later.
The former failure of sending data less than 4 bytes is similar.
Looks like the first 8 bytes of message ram has to be initialised
for the first using.
What about putting
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
into the open() function? Can you ask the hardware colleges if this is a
functional workaround.
quoted
quoted
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
Yes, i tried to fix it as follows.
/* FIXME: we meet an IC issue that we have to write the full 8
* bytes (whatever value for the second word) in Message RAM to
* avoid bit error for transmit data less than 4 bytes
*/
if (cf->len <= 4) {
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
*(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
*(u32 *)(cf->data + 4));
} else {
for (i = 0; i < cf->len; i += 4)
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
*(u32 *)(cf->data + i));
Will update the patch.
Both branches of the above if are doing the same thing, I think you can
replace the while if ... else ... for with this:
Not the same thing.
The later one will cover payload up to 64 bytes.
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
However if writing to DATA(0) and DATA(1) once in the open() function is
enough this code should stay as it is.
I tried put them into open() function and the quick test showed it worked.
Do you think it's ok to put things into open() function for this issue
as follows?
@@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)/* set bittiming params */m_can_set_bittiming(dev);+/* We meet an IC issue that we have to write the full 8+*bytes(whatevervalueforthesecondword)inMessageRAMto+*avoidbiterrorfortransmitdatalessthan4bytesatthefirst+*time.Byinitializingthefirst8bytesoftxbufferbeforeusing+*itcanavoidsuchissue.+*/+m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(0),0x0);+m_can_fifo_write(priv,0,M_CAN_FIFO_DATA(1),0x0);+m_can_config_endisable(priv,false);}
Regards
Dong Aisheng
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
Yes, i tried to fix it as follows.
/* FIXME: we meet an IC issue that we have to write the full 8
* bytes (whatever value for the second word) in Message RAM to
* avoid bit error for transmit data less than 4 bytes
*/
if (cf->len <= 4) {
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
*(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
*(u32 *)(cf->data + 4));
} else {
for (i = 0; i < cf->len; i += 4)
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
*(u32 *)(cf->data + i));
Will update the patch.
Both branches of the above if are doing the same thing, I think you can
replace the while if ... else ... for with this:
Not the same thing.
The later one will cover payload up to 64 bytes.
Doh! I'm not used to CAN-FD, yet :) However, I'll apply this fix before
adding the CAN-FD support.
quoted hunk
quoted
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
However if writing to DATA(0) and DATA(1) once in the open() function is
enough this code should stay as it is.
I tried put them into open() function and the quick test showed it worked.
Do you think it's ok to put things into open() function for this issue
as follows?
@@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)/* set bittiming params */m_can_set_bittiming(dev);+/* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes at the first
+ * time. By initializing the first 8 bytes of tx buffer before using
+ * it can avoid such issue.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
+ /* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
Yes. Also put the current IP revision (3.0.x) into the comment.
Did inform the Bosch guys from this issue - or is it already in some errata sheet?
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes at the first
+ * time. By initializing the first 8 bytes of tx buffer before using
+ * it can avoid such issue.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
+ /* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
Yes. Also put the current IP revision (3.0.x) into the comment.
Good idea - also add the SoC's mask revision.
Did inform the Bosch guys from this issue - or is it already in some
errata sheet?
quoted
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes at the
first
+ * time. By initializing the first 8 bytes of tx buffer
before using
+ * it can avoid such issue.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
On Tue, Nov 04, 2014 at 02:13:30PM +0100, Oliver Hartkopp wrote:
On 04.11.2014 11:33, Marc Kleine-Budde wrote:
quoted
On 11/04/2014 10:27 AM, Dong Aisheng wrote:
quoted
quoted
+ /* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
Yes. Also put the current IP revision (3.0.x) into the comment.
Did inform the Bosch guys from this issue - or is it already in some errata sheet?
Good idea, will add it.
I will try if we can talk Bosch guys about this issue.
Regards
Dong Aisheng
quoted
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes at the first
+ * time. By initializing the first 8 bytes of tx buffer before using
+ * it can avoid such issue.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
On Tue, Nov 04, 2014 at 11:33:09AM +0100, Marc Kleine-Budde wrote:
On 11/04/2014 10:27 AM, Dong Aisheng wrote:
quoted
quoted
quoted
quoted
It should be possible to change the for loop to go always to 8, or
simply unroll the loop:
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
Yes, i tried to fix it as follows.
/* FIXME: we meet an IC issue that we have to write the full 8
* bytes (whatever value for the second word) in Message RAM to
* avoid bit error for transmit data less than 4 bytes
*/
if (cf->len <= 4) {
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
*(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
*(u32 *)(cf->data + 4));
} else {
for (i = 0; i < cf->len; i += 4)
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
*(u32 *)(cf->data + i));
Will update the patch.
Both branches of the above if are doing the same thing, I think you can
replace the while if ... else ... for with this:
Not the same thing.
The later one will cover payload up to 64 bytes.
Doh! I'm not used to CAN-FD, yet :) However, I'll apply this fix before
adding the CAN-FD support.
quoted
quoted
/* errata description goes here */
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
However if writing to DATA(0) and DATA(1) once in the open() function is
enough this code should stay as it is.
I tried put them into open() function and the quick test showed it worked.
Do you think it's ok to put things into open() function for this issue
as follows?
@@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)/* set bittiming params */m_can_set_bittiming(dev);+/* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
Looks good.
Will do like that.
quoted
+ * bytes (whatever value for the second word) in Message RAM to
+ * avoid bit error for transmit data less than 4 bytes at the first
+ * time. By initializing the first 8 bytes of tx buffer before using
+ * it can avoid such issue.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
No, i did not see the issue with dlc > 8 && dlc < 64.
Regards
Dong Aisheng
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Hey Dong Aisheng,
the state of the patches are:
1: can/master + stable
2: can/mster
3: can/mster
4: can/master + stable
5: waiting for Oliver's opinion due to the user space change
6: waiting for your input
7: waiting for your input
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Hello Marc,
you can omit the 'stable' tag as this driver just emerged in 3.18 - which is
currently in 3.18-rc3 state.
If possible I would suggest to push all 7 patches via can/master as it is
pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
working since 3.19".
This will produce confusion as the M_CAN core has built-in CAN FD support.
Regards,
Oliver
On 11/03/2014 06:02 PM, Marc Kleine-Budde wrote:
Hey Dong Aisheng,
the state of the patches are:
1: can/master + stable
2: can/mster
3: can/mster
4: can/master + stable
5: waiting for Oliver's opinion due to the user space change
6: waiting for your input
7: waiting for your input
Marc
you can omit the 'stable' tag as this driver just emerged in 3.18 - which is
currently in 3.18-rc3 state.
Thanks! fixed.
If possible I would suggest to push all 7 patches via can/master as it is
pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
working since 3.19".
Sorry, probably not, as CAN FD is a new feature. However we may talk to
David, as the m_can driver was introduced in 3.18 anyways, so it's
unlikely to break anything with this patch.
This will produce confusion as the M_CAN core has built-in CAN FD support.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
If possible I would suggest to push all 7 patches via can/master as it is
pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
working since 3.19".
Sorry, probably not, as CAN FD is a new feature. However we may talk to
David, as the m_can driver was introduced in 3.18 anyways, so it's
unlikely to break anything with this patch.
Yes. It's just to be 'feature complete' for the FD enabled M_CAN driver.
Hopefully it's ok for Dave ...
Thanks,
Oliver