From: Stephen Boyd <sboyd@codeaurora.org>
To: Hauke Mehrtens <hauke@hauke-m.de>
Cc: "Aaro Koskinen" <aaro.koskinen@iki.fi>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy
Date: Wed, 23 Mar 2016 15:00:12 -0700 [thread overview]
Message-ID: <20160323220012.GB18567@codeaurora.org> (raw)
In-Reply-To: <56F30E1F.5020108@hauke-m.de>
On 03/23, Hauke Mehrtens wrote:
> On 03/16/2016 12:06 AM, Aaro Koskinen wrote:
> > Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use
> > __ioread32_copy() instead of open-coding") switched to use a generic copy
> > function, but failed to notice that the header pointer is updated between
> > the two copies, resulting in bogus data being copied in the latter one.
> > Fix by keeping the old header pointer.
> >
> > The patch fixes totally broken networking on WRT54GL router (both LAN
> > and WLAN interfaces fail to probe).
> >
> > Fixes: 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use __ioread32_copy() instead of open-coding")
> > Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > ---
> >
> > v2: Avoid using the device memory after the first copy when
> > checking the nvram length, suggested by Stephen Boyd.
> >
> > v1: http://marc.info/?t=145807850800003&r=1&w=2
> >
> > drivers/firmware/broadcom/bcm47xx_nvram.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c b/drivers/firmware/broadcom/bcm47xx_nvram.c
> > index 0c2f0a6..0b631e5 100644
> > --- a/drivers/firmware/broadcom/bcm47xx_nvram.c
> > +++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
> > @@ -94,15 +94,14 @@ static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
> >
> > found:
> > __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
> > - header = (struct nvram_header *)nvram_buf;
> > - nvram_len = header->len;
> > + nvram_len = ((struct nvram_header *)(nvram_buf))->len;
>
> I do not understand why this change is needed? Doesn't the old code do
> exactly the same as the new one?
>
> The old code updated the header pointer and then accesses a member, the
> new one directly accesses this member without updating this pointer.
>
> I assume, I am missing something. ;-)
The goal is to access 'nvram_buf' which is a copy of 'header'.
This is to avoid any problems with accessing device memory, i.e.
'header', without using the appropriate I/O accessors (readl,
readw, readb).
The bug that's being fixed though is to make sure 'header'
doesn't get overwritten with the pointer to the in-memory copy
that we just made. Further down in this function we copy the
second 'header' that lives in device memory, and repointing
'header' to the in-memory copy breaks that.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
prev parent reply other threads:[~2016-03-23 22:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 23:06 [PATCH v2] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy Aaro Koskinen
2016-03-15 23:13 ` Stephen Boyd
2016-03-23 21:43 ` Hauke Mehrtens
2016-03-23 22:00 ` Stephen Boyd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160323220012.GB18567@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=aaro.koskinen@iki.fi \
--cc=akpm@linux-foundation.org \
--cc=hauke@hauke-m.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.