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
| ||
|
Date: Fri, 7 Nov 2014 18:21:35 +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 V4 3/3] can: m_can: add missing message RAM initialization On Fri, Nov 07, 2014 at 11:30:38AM +0100, Marc Kleine-Budde wrote: > On 11/07/2014 09:45 AM, Dong Aisheng wrote: > > The M_CAN message RAM is usually equipped with a parity or ECC functionality. > > But RAM cells suffer a hardware reset and can therefore hold arbitrary > > content at startup - including parity and/or ECC bits. > > > > To prevent the M_CAN controller detecting checksum errors when reading > > potentially uninitialized TX message RAM content to transmit CAN > > frames the TX message RAM has to be written with (any kind of) initial > > data. > > > > Signed-off-by: Dong Aisheng <b29396@...escale.com> > > --- > > ChangeLog: > > v3-v4: > > * initialize the entire Message RAM in use instead of only 8 bytes > > since this is a valid and needed initialization process. > > Patch title also changed. > > --- > > drivers/net/can/m_can/m_can.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c > > index eee1533..de742d0 100644 > > --- a/drivers/net/can/m_can/m_can.c > > +++ b/drivers/net/can/m_can/m_can.c > > @@ -1114,7 +1114,7 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > > struct resource *res; > > void __iomem *addr; > > u32 out_val[MRAM_CFG_LEN]; > > - int ret; > > + int i, start, end, ret; > > > > /* message ram could be shared */ > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram"); > > @@ -1165,6 +1165,15 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > > priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num, > > priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num); > > > > + /* initialize the entire Message RAM in use to avoid possible > > + * ECC/parity checksum errors when reading an uninitialized buffer > > + */ > > + start = priv->mcfg[MRAM_SIDF].off; > > + end = priv->mcfg[MRAM_TXB].off + > > + priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE; > > + for (i = start; i < end; i += 4) > > + writel(0x0, priv->mram_base + i); > > Can we access the mram without turning on the clock? > Yes, we can. Since it's CPU access, it seems it does not depend on M_CAN clocks. What i see from M_CAN subsystem block diagram of MX6SX, it requires CPU clock which should always be enabled. 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