linux-kernel - Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch

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:	Mon, 4 Jul 2016 15:43:50 +0200
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Hanjun Guo <hanjun.guo@...aro.org>, Fu Wei <fu.wei@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Marc Zyngier <marc.zyngier@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	rruigrok@...eaurora.org, harba@...eaurora.org,
	Christopher Covington <cov@...eaurora.org>,
	Timur Tabi <timur@...eaurora.org>,
	G Gregory <graeme.gregory@...aro.org>,
	Al Stone <al.stone@...aro.org>, Jon Masters <jcm@...hat.com>,
	wei@...hat.com, Arnd Bergmann <arnd@...db.de>,
	Wim Van Sebroeck <wim@...ana.be>,
	Suravee Suthikulanit <Suravee.Suthikulpanit@....com>,
	Leo Duran <leo.duran@....com>
Subject: Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT
 support in arm_arch_timer

On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
> On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
>> On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
>>

[ ... ]

>> clocksource-probe which is DT based with different drivers using it in 
>> drivers/clocksource with a pletore of different archs.
> 
> So maybe the GTDT code should be there too?

*maybe*

>> Cstate code which is only used by x86 is in drivers/acpi, it is only 
>> used by x86/ia64 and it isn't a problem.
> 
> It is a problem.  

Can you explain why it is a problem ?

> drivers/acpi/ is not the right place for arch-specific code.

I do not understand this assertion regarding what happened during the
last years with different subsystems where the drivers were moved from
their arch specific directories to the drivers directory (cpufreq,
cpuidle, clockevent, clk, etc ...) and resulted at the end to a code
refactoring and consolidation.

Why ACPI should follow the opposite rule ?

>> There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
>> comprehension of the code.
>>
>> IMHO, having all ACPI code in the same directory will encourage the 
>> consolidation.
> 
> The consolidation of what exactly?

The consolidation of the ACPI code in general which is the
counter-example of self-contained code.

> In particular, how does the GTDT code in drivers/acpi/ help to consolidate
> anything?

If I imagine we group all ACPI code under a common directory, the first
example coming in my mind is the sharing of private headers, reducing
the scope of exported functions and global variables (eg. acpi_disabled).

That say, I can understand grouping all the ACPI into a single directory
will make it fall under a single umbrella's maintainer and that could be
a nightmare to maintain as it covers a lot of different features.
However, I believe that could be solved by clearly identifying who takes
care of what.



-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog