lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141105020322.GA18982@shlinux1.ap.freescale.net>
Date:	Wed, 5 Nov 2014 10:03:25 +0800
From:	Dong Aisheng <b29396@...escale.com>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
CC:	<linux-can@...r.kernel.org>, <wg@...ndegger.com>,
	<varkabhadram@...il.com>, <netdev@...r.kernel.org>,
	<socketcan@...tkopp.net>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 7/7] can: m_can: workaround for transmit data less than
 4 bytes

On Tue, Nov 04, 2014 at 11:33:09AM +0100, Marc Kleine-Budde wrote:
> On 11/04/2014 10:27 AM, Dong Aisheng wrote:
> >>>> 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.
> 
> >> /* 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?
> > 
> > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> > index 065e4f1..ca55988 100644
> > --- a/drivers/net/can/m_can/m_can.c
> > +++ b/drivers/net/can/m_can/m_can.c
> > @@ -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.

> > +        * 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   |
> 


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ