From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352AbcGMVnu (ORCPT ); Wed, 13 Jul 2016 17:43:50 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33496 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbcGMVnm (ORCPT ); Wed, 13 Jul 2016 17:43:42 -0400 MIME-Version: 1.0 In-Reply-To: <20160713210857.GA9500@roeck-us.net> References: <1468432402-4872-1-git-send-email-fu.wei@linaro.org> <1468432402-4872-5-git-send-email-fu.wei@linaro.org> <20160713210857.GA9500@roeck-us.net> From: "Rafael J. Wysocki" Date: Wed, 13 Jul 2016 23:43:39 +0200 X-Google-Sender-Auth: acoF1Q5rH0qh39tFG6hyP7Ua4h0 Message-ID: Subject: Re: [PATCH v7 4/9] acpi/arm64: Add GTDT table parse driver To: Guenter Roeck Cc: "Rafael J. Wysocki" , Fu Wei , "Rafael J. Wysocki" , Len Brown , Daniel Lezcano , Thomas Gleixner , Marc Zyngier , Lorenzo Pieralisi , Sudeep Holla , Hanjun Guo , "linux-arm-kernel@lists.infradead.org" , "linaro-acpi@lists.linaro.org" , Linux Kernel Mailing List , ACPI Devel Maling List , rruigrok@codeaurora.org, harba@codeaurora.org, Christopher Covington , Timur Tabi , G Gregory , Al Stone , Jon Masters , wei@redhat.com, Arnd Bergmann , Wim Van Sebroeck , Catalin Marinas , Will Deacon , Suravee Suthikulanit , Leo Duran , "linux-watchdog@vger.kernel.org" , David Miller , Andrew Morton , Greg Kroah-Hartman , kvalo@codeaurora.org, mchehab@kernel.org, Jiri Slaby , christoffer.dall@linaro.org, julien.grall@arm.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 13, 2016 at 11:08 PM, Guenter Roeck wrote: > On Wed, Jul 13, 2016 at 10:30:37PM +0200, Rafael J. Wysocki wrote: >> On Wed, Jul 13, 2016 at 7:53 PM, wrote: >> > From: Fu Wei >> > >> > This patch adds support for parsing arch timer in GTDT, >> > provides some kernel APIs to parse all the PPIs and >> > always-on info in GTDT and export them. >> > >> > By this driver, we can simplify arm_arch_timer drivers, and >> > separate the ACPI GTDT knowledge from it. >> > >> > Signed-off-by: Fu Wei >> > Signed-off-by: Hanjun Guo >> > --- >> > drivers/acpi/Kconfig | 5 ++ >> > drivers/acpi/Makefile | 1 + >> > drivers/acpi/arm64/Kconfig | 15 ++++ >> > drivers/acpi/arm64/Makefile | 1 + >> > drivers/acpi/arm64/acpi_gtdt.c | 170 +++++++++++++++++++++++++++++++++++++++++ >> > include/linux/acpi.h | 6 ++ >> > 6 files changed, 198 insertions(+) >> > >> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> > index b7e2e77..1cdc7d2 100644 >> > --- a/drivers/acpi/Kconfig >> > +++ b/drivers/acpi/Kconfig >> > @@ -521,4 +521,9 @@ config XPOWER_PMIC_OPREGION >> > >> > endif >> > >> > +if ARM64 >> > +source "drivers/acpi/arm64/Kconfig" >> > + >> > +endif >> > + >> > endif # ACPI >> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile >> > index 251ce85..1a94ff7 100644 >> > --- a/drivers/acpi/Makefile >> > +++ b/drivers/acpi/Makefile >> > @@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o >> > obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o >> > obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o >> > obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o >> > +obj-$(CONFIG_ARM64) += arm64/ >> > >> > video-objs += acpi_video.o video_detect.o >> > diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig >> > new file mode 100644 >> > index 0000000..ff5c253 >> > --- /dev/null >> > +++ b/drivers/acpi/arm64/Kconfig >> > @@ -0,0 +1,15 @@ >> > +# >> > +# ACPI Configuration for ARM64 >> > +# >> > + >> > +menu "The ARM64-specific ACPI Support" >> > + >> > +config ACPI_GTDT >> > + bool "ACPI GTDT table Support" >> >> This should depend on ARM64. >> >> Also I wonder if it needs to be user-selectable? Wouldn't it be >> better to enable it by default when building for ARM64 with ACPI? >> > It is currently selected in patch 9, in the watchdog driver's Kconfig > entry. Well, it still doesn't have to be user-selectable for that. :-) > Not sure if I like that; maybe the watchdog driver should depend > on it instead ? If the watchdog is not the only user of it (and I don't think it is), it would be better to arrange things this way. Thanks, Rafael