linux-kernel - Re: [PATCH v2 RESEND 1/3] clocksource/vt8500: Use MIN_OSCR

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] [day] [month] [year] [list]

Date:	Fri, 01 Jan 2016 21:23:48 +0100
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Thomas Gleixner <tglx@...utronix.de>, Roman Volkov <v1ron@...l.ru>
Cc:	arm@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Alexey Charkov <alchark@...il.com>,
	Roman Volkov <rvolkov@...os.org>,
	Tony Prisk <linux@...sktech.co.nz>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Bill Gatliff <bgat@...lgatliff.com>
Subject: Re: [PATCH v2 RESEND 1/3] clocksource/vt8500: Use MIN_OSCR_DELTA from PXA

Roman Volkov <v1ron@...l.ru> writes:

> В Thu, 31 Dec 2015 23:33:45 +0100 (CET)
> Thomas Gleixner <tglx@...utronix.de> пишет:
>
>> Roman,
>> 
>> On Thu, 31 Dec 2015, Roman Volkov wrote:
>> > Since vt8500 and PXA timers are identical, use MIN_OSCR_DELTA from
>> > PXA, which is bigger than existing value. It is required to
>> > determine the minimum delay which hardware can generate.  
>> 
>> Now that brings up the obvious question:
>> 
>> If the vt8500 and PXA timers are identical why has vt8500 it's own
>> slightly different implementation and does not use the PXA timer?
>
> Thomas,
>
> I occasionally noticed that the PXA can be reused, when working on the
> bugfix for vt8500. Another good question would be how exactly this code
> can be reused. We may rework PXA driver to make it working under
> vt8500, or include the C code from the vt8500 and get two slightly
> different modules. You may look at our previous discussion with Alexey:
>
> https://lkml.org/lkml/2015/12/21/437
>
> Adding Robert and Bill to get more opinions. At this step, fixing the
> vt8500 nanosleep bug is a priority.

Personnaly I'm not very thrilled by combining pxa and vt8500 drivers into one.

The rationale I have behind is that :
 - the new driver will have new ifs to switch form vt8500 to pxa
   For example, suspend/resume functions will be different.
   Moreover in order to not impact the pxa runtime some ifs will be necessary
   (will that be if (IS_ENABLED(CONFIG_ARCH_PXA) && ...)
 - the IPs do not look that similar to me
   They seems inter-operable, but that seems to me to be just because of the 3
   common register placement : register at match (@0x00), counter (@0x10) and
   interrupt enabled (@0x1c).
   The register acces semantics are different (vt8500 needs a bit to access),
   the input clock seems different.

For ~140 lines of code, I prefer the simplicity brought by drivers
separation. The diffstat should be pretty equivalent between 2 drivers and 1
combined driver with many ifs.

Cheers.

-- 
Robert
--
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/