All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sherry Sun <sherry.sun@nxp.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "sudeep.dutt@intel.com" <sudeep.dutt@intel.com>,
	"ashutosh.dixit@intel.com" <ashutosh.dixit@intel.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"masahiroy@kernel.org" <masahiroy@kernel.org>,
	"michal.lkml@markovi.net" <michal.lkml@markovi.net>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"rikard.falkeborn@gmail.com" <rikard.falkeborn@gmail.com>,
	"mst@redhat.co" <mst@redhat.co>, "bp@suse.de" <bp@suse.de>,
	"jhugo@codeaurora.org" <jhugo@codeaurora.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"manivannan.sadhasivam@linaro.org"
	<manivannan.sadhasivam@linaro.org>,
	"mgross@linux.intel.com" <mgross@linux.intel.com>,
	"pierre-louis.bossart@linux.intel.com" 
	<pierre-louis.bossart@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [PATCH 1/3] mic: vop: fix a written error in MODULE_DEVICE_TABLE
Date: Sun, 27 Sep 2020 12:50:26 +0000	[thread overview]
Message-ID: <VI1PR04MB4960F0C06833769A095F176A92340@VI1PR04MB4960.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200927123155.GA205468@kroah.com>

Hi Greg,

> On Sun, Sep 27, 2020 at 12:19:50PM +0000, Sherry Sun wrote:
> > Hi Greg,
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh@linuxfoundation.org>
> > > Sent: 2020年9月27日 18:29
> > > To: Sherry Sun <sherry.sun@nxp.com>
> > > Cc: sudeep.dutt@intel.com; ashutosh.dixit@intel.com; arnd@arndb.de;
> > > masahiroy@kernel.org; michal.lkml@markovi.net; lee.jones@linaro.org;
> > > rikard.falkeborn@gmail.com; mst@redhat.co; bp@suse.de;
> > > jhugo@codeaurora.org; tglx@linutronix.de;
> > > manivannan.sadhasivam@linaro.org; mgross@linux.intel.com; pierre-
> > > louis.bossart@linux.intel.com; linux-kernel@vger.kernel.org; linux-
> > > kbuild@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH 1/3] mic: vop: fix a written error in
> > > MODULE_DEVICE_TABLE
> > >
> > > On Fri, Sep 25, 2020 at 03:31:56PM +0800, Sherry Sun wrote:
> > > > For vop bus, the first parameter should be vop in
> MODULE_DEVICE_TABLE.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > > ---
> > > >  drivers/misc/mic/vop/vop_main.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/misc/mic/vop/vop_main.c
> > > > b/drivers/misc/mic/vop/vop_main.c index
> d609f0dc6124..589425fa78d4
> > > > 100644
> > > > --- a/drivers/misc/mic/vop/vop_main.c
> > > > +++ b/drivers/misc/mic/vop/vop_main.c
> > > > @@ -796,7 +796,7 @@ static struct vop_driver vop_driver = {
> > > >
> > > >  module_vop_driver(vop_driver);
> > > >
> > > > -MODULE_DEVICE_TABLE(mbus, id_table);
> > > > +MODULE_DEVICE_TABLE(vop, id_table);
> > > >  MODULE_AUTHOR("Intel Corporation");
> > > >  MODULE_DESCRIPTION("Intel(R) Virtio Over PCIe (VOP) driver");
> > > > MODULE_LICENSE("GPL v2");
> > >
> > > Doesn't this have to go _after_ the MODULE_DEVICE_TABLE(vop...)
> > > support, which you add in patch 2 of this series?
> >
> > Yes, this patch must be used in conjunction with Patch2.
> > But I think here may be a small bug, in order to distinguish it from
> > the driver autoloading support, make this a separate patch.
> >
> > I can put this patch together with Patch2 if you think it might look more
> reasonable.
> 
> How about _after_ patch 2, otherwise this patch will break the build, right?

This change won't break the build, actually no matter what the first parameter
of MODULE_DEVICE_TABLE is, it won’t cause any build errors.

> 
> > > Does this patch here break the build?  If not, how is it working?
> > >
> > > And if you only have one vop driver, why do you need autoloading for it?
> > >
> > No, it doesn't break the build. But actually it won't work(autoloaded) when
> kernel boot and vop device appears.
> >
> > Although we may only have one vop driver, but in the mic Kconfig, the
> > intel mic/vop/cosm/scif drivers all recommended to be built as
> > modules, if we don't add autoloading for them, we may need modprobe
> them one by one manually both on EP and RC side.
> >
> > Obviously, for our use case, driver autoloading is more convenient.
> 
> Why are these all not "mic_SUFFIX" type drivers?  Why "vop" and "cosm"
> and "scif"?
> 

For VOP driver, it is designed to be a hardware independent Virtio Over PCIe (VOP) driver.
This is why we want to reuse it on i.MX platform. In theory, it can be applied to any platform.
With some changes, cosm driver also can be hardware independent.
So the names of them don’t use "mic_SUFFIX".

> And if you only have 1 driver, then what would cause autoloading?

As I understand it, if we add support for the driver autoloading like patch2,
driver will be autoloaded when the matched device appears.
Please correct me if I'm wrong.

Regards
Sherry

> 
> thanks,
> 
> greg k-h

  reply	other threads:[~2020-09-27 12:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25  7:31 [PATCH 0/3] Add module autoprobing support for vop and cosm driver Sherry Sun
2020-09-25  7:31 ` [PATCH 1/3] mic: vop: fix a written error in MODULE_DEVICE_TABLE Sherry Sun
2020-09-27 10:28   ` Greg KH
2020-09-27 12:19     ` Sherry Sun
2020-09-27 12:31       ` Greg KH
2020-09-27 12:50         ` Sherry Sun [this message]
2020-09-25  7:31 ` [PATCH 2/3] mic: vop: module autoprobing support for vop drivers Sherry Sun
2020-09-25  7:31 ` [PATCH 3/3] mic: cosm: module autoprobing support for cosm driver Sherry Sun
2020-09-27 10:29   ` Greg KH
2020-09-27 13:04     ` Sherry Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR04MB4960F0C06833769A095F176A92340@VI1PR04MB4960.eurprd04.prod.outlook.com \
    --to=sherry.sun@nxp.com \
    --cc=arnd@arndb.de \
    --cc=ashutosh.dixit@intel.com \
    --cc=bp@suse.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhugo@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=masahiroy@kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=michal.lkml@markovi.net \
    --cc=mst@redhat.co \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rikard.falkeborn@gmail.com \
    --cc=sudeep.dutt@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.