From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
Date: Mon, 4 Jul 2016 15:43:50 +0200 [thread overview]
Message-ID: <577A6816.3050709@linaro.org> (raw)
In-Reply-To: <1643662.QIDsTbCMZg@vostro.rjw.lan>
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
next prev parent reply other threads:[~2016-07-04 13:43 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 18:15 [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei at linaro.org
2016-06-30 2:54 ` Hanjun Guo
2016-07-07 16:12 ` Fu Wei
2016-06-29 18:15 ` [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver fu.wei at linaro.org
2016-06-29 21:24 ` Rafael J. Wysocki
2016-06-30 1:17 ` Fu Wei
2016-06-30 1:26 ` Rafael J. Wysocki
2016-06-30 1:32 ` Fu Wei
2016-06-30 4:13 ` Timur Tabi
2016-06-29 18:15 ` [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 07/10] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver fu.wei at linaro.org
2016-06-29 21:32 ` [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Rafael J. Wysocki
2016-06-30 1:29 ` Fu Wei
2016-06-30 1:37 ` Rafael J. Wysocki
2016-06-30 2:10 ` Hanjun Guo
2016-06-30 13:27 ` Rafael J. Wysocki
2016-06-30 13:48 ` Hanjun Guo
2016-07-01 15:23 ` Will Deacon
2016-07-01 21:04 ` Rafael J. Wysocki
2016-07-04 12:53 ` Rafael J. Wysocki
2016-07-05 14:18 ` Graeme Gregory
2016-07-06 0:00 ` Rafael J. Wysocki
2016-07-07 11:12 ` Hanjun Guo
2016-07-07 12:03 ` Rafael J. Wysocki
2016-07-07 13:40 ` Lorenzo Pieralisi
2016-07-07 13:58 ` Rafael J. Wysocki
2016-07-07 15:21 ` Fu Wei
2016-07-08 13:22 ` Lorenzo Pieralisi
2016-07-08 13:50 ` Sudeep Holla
2016-07-09 3:44 ` Hanjun Guo
2016-07-10 1:26 ` Rafael J. Wysocki
2016-07-09 3:00 ` Hanjun Guo
2016-07-01 14:00 ` Daniel Lezcano
2016-07-01 21:01 ` Rafael J. Wysocki
2016-07-04 13:43 ` Daniel Lezcano [this message]
2016-07-04 14:19 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=577A6816.3050709@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).