linux-kernel - Re: [PATCH 7/9] ARM: OMAP2+: SmartReflex: Use per-OPP data structure

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]

Date:	Wed, 18 Apr 2012 22:52:31 +0200
From:	Jean Pihet <jean.pihet@...oldbits.com>
To:	Kevin Hilman <khilman@...com>
Cc:	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>, Jean Pihet <j-pihet@...com>,
	Paul Walmsley <paul@...an.com>, Thara Gopinath <thara@...com>,
	Nishanth Menon <nm@...com>
Subject: Re: [PATCH 7/9] ARM: OMAP2+: SmartReflex: Use per-OPP data structure

On Wed, Apr 18, 2012 at 8:21 PM, Kevin Hilman <khilman@...com> wrote:
> jean.pihet@...oldbits.com writes:
>
>> From: Jean Pihet <j-pihet@...com>
>>
>> The SmartReflex driver incorrectly treats some per-OPP data as data
>> common to all OPPs (e.g., ERRMINLIMIT).  Move this data into a per-OPP
>> data structure.
>
> OK
>
>> The SmartReflex driver should not be dependent on whether the host SoC
>> uses eFuses to store SmartReflex parameters or not.  (Even SoCs that
>> do store SR data in eFuses often need to override that data with
>> software-defined values.)  So, convert sr_retrieve_nvalue() to look up
>> per-OPP data by the OPP's nominal voltage, rather than by the eFuse
>> offset.
>
> Right.
>
>> While at it:
>>  . tidy up the code wrt default values in the data tables,
>>  . remove the global errminlimit debugfs entry and create per-voltage
>>    entries from the data tables.
>
> OK
>
>> Furthermore, in order to make the SmartReflex implementation ready for
>> the move to drivers/, remove the dependency from the SR driver code
>> to the voltage layer by querying the data tables only from the SR device
>> init code.
>
> So that's 4 relatively independent things going on in this patch which
> makes it somewhat difficult to review and understand.
>
> I'd suggest breaking it up into smaller parts if possible.  If not, fix
> up the changelog to describe why all of these need to go together, and
> why it's necessary to do them before the move.
Those changes are not independent from each other.
However for improved readability the patch can be split up (e.g.
efuse->opp, debugfs ...) and the changelog updated accordingly.

>
> Thanks,
>
> Kevin
>

Thanks,
Jean
--
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/