[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190912094651.GH2036@sirena.org.uk>
Date: Thu, 12 Sep 2019 10:46:51 +0100
From: Mark Brown <broonie@...nel.org>
To: Amit Kucheria <amit.kucheria@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
arm@...nel.org, Bartosz Golaszewski <bgolaszewski@...libre.com>,
Catalin Marinas <catalin.marinas@....com>,
Kishon Vijay Abraham I <kishon@...com>,
Liam Girdwood <lgirdwood@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Michael Turquette <mturquette@...libre.com>,
Sebastian Reichel <sre@...nel.org>,
Stephen Boyd <sboyd@...nel.org>, Will Deacon <will@...nel.org>,
linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-pci@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/4] Cleanup arm64 driver dependencies
On Thu, Sep 12, 2019 at 03:48:44AM +0530, Amit Kucheria wrote:
> I was using initcall_debugging on a QCOM platform and ran across a bunch of
> driver initcalls that are enabled even if their SoC support is disabled.
What exactly is the problem you're trying to fix here? For the
drivers I looked at these were bog standard register the driver
with the subsystem type initcalls on optional drivers so not
doing anything particularly disruptive or anything like that.
For any given system that's going to be an issue for the
overwhelming majority of drivers on the tree, including those
that aren't associated with any particular architecture.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists