| Message ID | 1467999399-22288-1-git-send-email-f.fainelli@gmail.com |
|---|---|
| State | Accepted |
| Commit | 422485da15e7e9e6f71a5efd1aa2248595cb486d |
| Headers | show |
On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote: > Change the BUG_ON() condition in brcmnand_send_cmd() which checks for > the interrupt status "controller ready" bit to a WARN_ON. > > There is no good reason to kill the system when this condition occur > because we could have systems which listed the NAND controller as > available (e.g: from Device Tree), but the NAND chip could be > malfunctioning and not responding. > > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Brian Norris <computersforpeace@gmail.com> > --- > Note that I even hesitated to remove that completely, but there is > some value in knowing about this condition since it helps figuring > out what could be wrong. > > drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c > index b6062a2f3dfd..72bdc283778d 100644 > --- a/drivers/mtd/nand/brcmnand/brcmnand.c > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c > @@ -1165,7 +1165,7 @@ static void brcmnand_send_cmd(struct brcmnand_host *host, int cmd) > ctrl->cmd_pending = cmd; > > intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS); > - BUG_ON(!(intfc & INTFC_CTLR_READY)); > + WARN_ON(!(intfc & INTFC_CTLR_READY)); > > mb(); /* flush previous writes */ > brcmnand_write_reg(ctrl, BRCMNAND_CMD_START, > -- > 2.7.4 >
On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris <computersforpeace@gmail.com> wrote: > On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote: >> Change the BUG_ON() condition in brcmnand_send_cmd() which checks for >> the interrupt status "controller ready" bit to a WARN_ON. >> >> There is no good reason to kill the system when this condition occur >> because we could have systems which listed the NAND controller as >> available (e.g: from Device Tree), but the NAND chip could be >> malfunctioning and not responding. >> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > > Acked-by: Brian Norris <computersforpeace@gmail.com> > Reviewed-by: Kamal Dasu <kdasu.kdev@gmail.com> >> --- >> Note that I even hesitated to remove that completely, but there is >> some value in knowing about this condition since it helps figuring >> out what could be wrong. >> >> drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c >> index b6062a2f3dfd..72bdc283778d 100644 >> --- a/drivers/mtd/nand/brcmnand/brcmnand.c >> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c >> @@ -1165,7 +1165,7 @@ static void brcmnand_send_cmd(struct brcmnand_host *host, int cmd) >> ctrl->cmd_pending = cmd; >> >> intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS); >> - BUG_ON(!(intfc & INTFC_CTLR_READY)); >> + WARN_ON(!(intfc & INTFC_CTLR_READY)); >> >> mb(); /* flush previous writes */ >> brcmnand_write_reg(ctrl, BRCMNAND_CMD_START, >> -- >> 2.7.4 >>
On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote: > Change the BUG_ON() condition in brcmnand_send_cmd() which checks for > the interrupt status "controller ready" bit to a WARN_ON. > > There is no good reason to kill the system when this condition occur > because we could have systems which listed the NAND controller as > available (e.g: from Device Tree), but the NAND chip could be > malfunctioning and not responding. > > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Applied to l2-mtd.git
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c index b6062a2f3dfd..72bdc283778d 100644 --- a/drivers/mtd/nand/brcmnand/brcmnand.c +++ b/drivers/mtd/nand/brcmnand/brcmnand.c @@ -1165,7 +1165,7 @@ static void brcmnand_send_cmd(struct brcmnand_host *host, int cmd) ctrl->cmd_pending = cmd; intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS); - BUG_ON(!(intfc & INTFC_CTLR_READY)); + WARN_ON(!(intfc & INTFC_CTLR_READY)); mb(); /* flush previous writes */ brcmnand_write_reg(ctrl, BRCMNAND_CMD_START,
Change the BUG_ON() condition in brcmnand_send_cmd() which checks for the interrupt status "controller ready" bit to a WARN_ON. There is no good reason to kill the system when this condition occur because we could have systems which listed the NAND controller as available (e.g: from Device Tree), but the NAND chip could be malfunctioning and not responding. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- Note that I even hesitated to remove that completely, but there is some value in knowing about this condition since it helps figuring out what could be wrong. drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)