Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
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 FainelliApplied to l2-mtd.git
Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
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 Applied to l2-mtd.git
Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
On Sat, Jul 9, 2016 at 9:30 PM, Brian Norriswrote: > 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 > > Acked-by: Brian Norris > Reviewed-by: Kamal Dasu >> --- >> 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 >> -- Kamal Dasu Principal Engineer | Broadcom Ltd. 200 Brickstone Sq Andover | 978-719-1405
Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris 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 > > Acked-by: Brian Norris > Reviewed-by: Kamal Dasu >> --- >> 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 >> -- Kamal Dasu Principal Engineer | Broadcom Ltd. 200 Brickstone Sq Andover | 978-719-1405
Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
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 FainelliAcked-by: Brian Norris > --- > 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 >
Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd
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 Acked-by: Brian Norris > --- > 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 >