[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Xd67iw=GXV9i4O5LKnJd20=BkYyfVuxPgxQ5GZRJEy4A@mail.gmail.com>
Date: Mon, 15 Aug 2011 12:52:36 -0700
From: Doug Anderson <dianders@...omium.org>
To: balbi@...com
Cc: Ben Dooks <ben-linux@...ff.org>,
Stephen Warren <swarren@...dia.com>,
Vincent Palatin <vpalatin@...omium.org>,
Rhyland Klein <rklein@...dia.com>,
Jean Delvare <khali@...ux-fr.org>,
Rakesh Iyer <riyer@...dia.com>,
Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] i2c: tegra: Check for overflow errors with BUG_ON.
Felipe,
On Mon, Aug 15, 2011 at 12:17 PM, Felipe Balbi <balbi@...com> wrote:
> so due to a FIFO overflow you lock up the whole system ? Can't you e.g.
> reset the controller and reconfigure it rather than locking up the
> system ?
Certainly we could try to be more proactive and reset / retry / return
the error to the client. However, since the only expected situation
where this BUG_ON should hit is due to a bug in this driver itself
(AKA: i2c clients shouldn't be able to do anything to cause the BUG_ON
to hit), that seems like a lot of added complexity.
Also: if there is an arbitrary software bug that causing an overflow
condition to occur, I'm not sure how stable the system will be.
Specifically, the i2c controller is used (among other things) to talk
to the PMU and adjust voltages in the system. If we just sent it a
random command, I'd rather report the bug right away so we don't get
hard to find/reproduce failures in other parts of the system.
What do others think?
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists