Messages in this thread | | | Date | Mon, 21 Apr 2014 08:08:43 -0500 | From | Nishanth Menon <> | Subject | Re: [PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation |
| |
On 04/17/2014 05:00 PM, Felipe Balbi wrote: > On Thu, Apr 17, 2014 at 03:49:22PM -0500, Nishanth Menon wrote: >> just simplify derefencing that is equivalent. >> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> V2: just ordering change >> V1: https://patchwork.kernel.org/patch/3984201/ >> drivers/bus/omap_l3_noc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c >> index c8facb0..f7d3bf4 100644 >> --- a/drivers/bus/omap_l3_noc.c >> +++ b/drivers/bus/omap_l3_noc.c >> @@ -76,7 +76,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3) >> err_src = __ffs(err_reg); >> >> /* Read the stderrlog_main_source from clk domain */ >> - l3_targ_base = base + *(l3_targ[i] + err_src); >> + l3_targ_base = base + l3_targ[i][err_src]; > > hmmm, wasn't it so that pointer arithmetic was slightly faster than > array indexing ? In that case would it be best to: > > l3_targ_base = base + *(l3_targ + i + err_src); > Yes, if this was a hot path (example: interrupt handler that gets invoked very often), I would probably have preferred optimization at this point.
However, the patch is just a step away from patches that converts the target information into a structure under flagmux structure allowing us to get rid of multiple array operations.
This patch just makes the further changes a bit readable.
-- Regards, Nishanth Menon
| |