[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160524204542.GB5857@f23x64.localdomain>
Date: Tue, 24 May 2016 13:45:42 -0700
From: Darren Hart <dvhart@...radead.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@...el.com>,
platform-driver-x86@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Olof Johansson <olof@...om.net>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, dbasehore@...gle.com,
vishwanath.somayaji@...el.com
Subject: Re: [PATCH v5] platform:x86: Add PMC Driver for Intel Core SoC
On Tue, May 24, 2016 at 11:10:56PM +0300, Andy Shevchenko wrote:
> On Tue, May 24, 2016 at 10:38 PM, Darren Hart <dvhart@...radead.org> wrote:
> > On Tue, May 24, 2016 at 09:54:36PM +0300, Andy Shevchenko wrote:
...
> >> > +static void intel_pmc_core_remove(struct pci_dev *pdev)
> >> > +{
> >> > + pmc_core_dbgfs_unregister(&pmc);
> >> > +}
> >> > +
> >> > +static struct pci_driver intel_pmc_core_driver = {
> >> > + .name = "intel_pmc_core",
> >> > + .id_table = pmc_pci_ids,
> >> > + .probe = pmc_core_probe,
> >> > + .remove = intel_pmc_core_remove,
> >> > +};
> >> > +module_pci_driver(intel_pmc_core_driver);
> >> > +
> >> > +MODULE_AUTHOR("Rajneesh Bhardwaj <rajneesh.bhardwaj@...el.com>");
> >> > +MODULE_AUTHOR("Vishwanath Somayaji <vishwanath.somayaji@...el.com>");
> >> > +MODULE_DESCRIPTION("Intel CORE SoC Power Management Controller Interface");
> >> > +MODULE_LICENSE("GPL v2");
> >>
> >> So, since you have symbol defined as boolean, most of the above lines
> >> are redundant including ->remove() and module.h inclusion.
> >>
> >> Do we need it as a module? In that case you have to set to false
> >> pmcdev->initialized variable.
> >
> > It was determined best not to build as a module given the it's primary consumer
> > was a built-in. Some of that is still being built, so we'll leave it as built-in
> > until it's in, and we can re-evaluate as needed.
>
> Yeah, I saw several patches floating around that removes module
> support for boolean symbols. Thus my question is how we suppose to
> proceed. In case we might have module support I would rather remove
> extra stuff and apply it later when it would be needed. What do you
> think?
Agreed, if it is to be boolean, then the modular-specific code should be
removed.
--
Darren Hart
Intel Open Source Technology Center
Powered by blists - more mailing lists