[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7295cafaf6da34e31390fe621198205d18eac525.camel@linux.intel.com>
Date: Mon, 27 Sep 2021 10:27:28 -0700
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: lee.jones@...aro.org, hdegoede@...hat.com, mgross@...ux.intel.com,
andriy.shevchenko@...ux.intel.com, srinivas.pandruvada@...el.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 2/2] platform/x86: Add Intel Software Defined Silicon
driver
On Mon, 2021-09-27 at 06:04 +0200, Greg KH wrote:
> On Sun, Sep 26, 2021 at 06:15:16PM -0700, David E. Box wrote:
> > > > +static struct platform_driver sdsi_driver = {
> > > > + .driver = {
> > > > + .name = SDSI_DEV_NAME,
> > > > + .dev_groups = sdsi_groups,
> > > > + },
> > > > + .probe = sdsi_probe,
> > > > + .remove = sdsi_remove,
> > > > +};
> > > > +module_platform_driver(sdsi_driver);
> > >
> > > What causes the platform to know to register, and enable, this platform
> > > driver? Shouldn't there be some hardware involved that is discoverable
> > > to enable it to load dynamically?
> >
> > Ah. The patch that adds the SDSi platform device string was added to a series for the intel_pmt
> > MFD
> > driver and it's still waiting review. I see that complicates things. I can combine the two series
> > together.
>
> Do you have a pointer to the lore.kernel.org location of that series?
https://lore.kernel.org/all/20210922213007.2738388-1-david.e.box@linux.intel.com/
>
> Your code right here will bind to any system that it is loaded on, a
> very dangerous thing...
It won't. It uses module alias to load against the SDSi specific MFD cell.
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists