linux-kernel - Re: [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI

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]

Message-ID: <20140124120815.GH814@e106331-lin.cambridge.arm.com>
Date:	Fri, 24 Jan 2014 12:08:15 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Hanjun Guo <hanjun.guo@...aro.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Olof Johansson <olof@...om.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Rob Herring <robh@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Patch Tracking <patches@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
	Amit Daniel Kachhap <amit.daniel@...sung.com>
Subject: Re: [PATCH 18/20] clocksource / acpi: Add macro
 CLOCKSOURCE_ACPI_DECLARE

On Fri, Jan 24, 2014 at 12:20:46AM +0000, Hanjun Guo wrote:
> On 2014年01月22日 19:45, Mark Rutland wrote:
> > On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
> >> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@...aro.org> wrote:
> >>
> >>> From: Amit Daniel Kachhap <amit.daniel@...sung.com>
> >>>
> >>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> >>> name from the ACPI timer table is matched with all the registered
> >>> timer controllers and matching initialisation routine is invoked.
> >>>
> >>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@...sung.com>
> >>> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
> >> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> >> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> >> be named TIMER_ACPI_DECLARE().
> >>
> >> The reason is that "clocksource" is a Linux-internal name and this
> >> macro pertains to the hardware name in respective system
> >> description type.
> >>
> >>> +#ifdef CONFIG_ACPI
> >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)                     \
> >>> +       static const struct acpi_device_id __clksrc_acpi_table_##name   \
> >>> +               __used __section(__clksrc_acpi_table)                   \
> >>> +                = { .id = compat,                              \
> >>> +                    .driver_data = (kernel_ulong_t)fn }
> >>> +#else
> >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> >>> +#endif
> >> This hammers down the world to compile one binary for ACPI
> >> and one binary for device tree. Maybe that's fine, I don't know.
> > How does it do that?
> >
> > As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
> > exclusive, and this just means that we only build the datastructures for
> > matching from ACPI when CONFIG_ACPI is enabled.
> >
> > Have I missed something?
> >
> > I definitely don't want to see mutually exclusive ACPI and DT support.
> 
> ACPI and DT did the same job so I think they should mutually exclusive.
> if we enable both DT and ACPI in one system, this will leading confusions.

ACPI and DT do similar jobs, and we should be mutually exclusive at
runtime. However, they should not be mutually exclusive at compile-time.

Being mutually exclusive at compile-time is just broken. It creates more
work for distributions (who need to ship double the number of kernels),
it increases the number of configurations requiring testing, and it
makes it easier for bugs to be introduced. It's just painful, and
there's no reason for it.

At boot time the kernel needs to decide which to use for hardware
description, and completely ignore the other (which should not be
present, but lets not assume that or inevitably someone will break that
assumption for a quick hack).

The same kernel should boot on a system that has a DTB or a system that
has ACPI tables. On a system that's provided both it should use one or
the other, but not both.

Thanks,
Mark.
--
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/