linux-kernel - Re: [PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5355185B.70003@ti.com>
Date:	Mon, 21 Apr 2014 08:08:43 -0500
From:	Nishanth Menon <nm@...com>
To:	<balbi@...com>
CC:	Tony Lindgren <tony@...mide.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Sricharan R <r.sricharan@...com>, Sekhar Nori <nsekhar@...com>,
	Rajendra Nayak <rnayak@...com>,
	Peter Ujfalusi <peter.ujfalusi@...com>,
	<devicetree@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>
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@...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
--
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/