From: Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "James Liao"
<jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
"Arnd Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>,
"Sascha Hauer" <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"Matthias Brugger"
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Eddie Huang (黃智傑)"
<eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver
Date: Tue, 22 Dec 2015 10:48:08 -0500 [thread overview]
Message-ID: <20151222154808.GC12458@windriver.com> (raw)
In-Reply-To: <CAGS+omDrZO8PteeFZMes0QRjG2KLhMG=qacFrho+UFPVAG=YXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[Re: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver] On 22/12/2015 (Tue 21:36) Daniel Kurtz wrote:
> Hi Matthias,
>
> One thing below is missing from this version of the patch...
>
> > On Fri, Dec 18, 2015 at 7:19 PM, Matthias Brugger
> > <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> SCPSYS can't be built as module. Use builtin_platform_driver instead.
> >> For this probe must not be __init and the data accessed can't be
> >> __initconst. Remove this macros. To make the impact as small as possible,
> >> fold scp_domain_data into scp_domain via a pointer.
>
> [snip]
>
> >> @@ -542,10 +533,11 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
> >> };
> >>
> >> static struct platform_driver scpsys_drv = {
> >> + .probe = scpsys_probe,
> >> .driver = {
> >> .name = "mtk-scpsys",
>
> This was in Sascha's version of the patch:
>
> .suppress_bind_attrs = true,
Unless you've got a very specific use case where an unbind makes sense
(like a quad port ethernet card, where you unbind one port and then do
PCI pass through of it to a kvm guest for example) then yes, you should
suppress unbind. So for most drivers aimed at a single device, or where
being built in but unbinding just makes no sense for any possible use
case, then yes you should set the above.
Paul.
--
>
> Do we still need it now that we use "builtin_platform_driver"?
>
> >> .owner = THIS_MODULE,
> >> .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> >> },
> >> };
> >> -builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
> >> +builtin_platform_driver(scpsys_drv);
> >> --
> >> 2.6.2
> >>
WARNING: multiple messages have this Message-ID (diff)
From: paul.gortmaker@windriver.com (Paul Gortmaker)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver
Date: Tue, 22 Dec 2015 10:48:08 -0500 [thread overview]
Message-ID: <20151222154808.GC12458@windriver.com> (raw)
In-Reply-To: <CAGS+omDrZO8PteeFZMes0QRjG2KLhMG=qacFrho+UFPVAG=YXg@mail.gmail.com>
[Re: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver] On 22/12/2015 (Tue 21:36) Daniel Kurtz wrote:
> Hi Matthias,
>
> One thing below is missing from this version of the patch...
>
> > On Fri, Dec 18, 2015 at 7:19 PM, Matthias Brugger
> > <matthias.bgg@gmail.com> wrote:
> >> SCPSYS can't be built as module. Use builtin_platform_driver instead.
> >> For this probe must not be __init and the data accessed can't be
> >> __initconst. Remove this macros. To make the impact as small as possible,
> >> fold scp_domain_data into scp_domain via a pointer.
>
> [snip]
>
> >> @@ -542,10 +533,11 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
> >> };
> >>
> >> static struct platform_driver scpsys_drv = {
> >> + .probe = scpsys_probe,
> >> .driver = {
> >> .name = "mtk-scpsys",
>
> This was in Sascha's version of the patch:
>
> .suppress_bind_attrs = true,
Unless you've got a very specific use case where an unbind makes sense
(like a quad port ethernet card, where you unbind one port and then do
PCI pass through of it to a kvm guest for example) then yes, you should
suppress unbind. So for most drivers aimed at a single device, or where
being built in but unbinding just makes no sense for any possible use
case, then yes you should set the above.
Paul.
--
>
> Do we still need it now that we use "builtin_platform_driver"?
>
> >> .owner = THIS_MODULE,
> >> .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> >> },
> >> };
> >> -builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
> >> +builtin_platform_driver(scpsys_drv);
> >> --
> >> 2.6.2
> >>
WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: "Matthias Brugger" <matthias.bgg@gmail.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Arnd Bergmann" <arnd@arndb.de>,
"Eddie Huang (黃智傑)" <eddie.huang@mediatek.com>,
"James Liao" <jamesjj.liao@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver
Date: Tue, 22 Dec 2015 10:48:08 -0500 [thread overview]
Message-ID: <20151222154808.GC12458@windriver.com> (raw)
In-Reply-To: <CAGS+omDrZO8PteeFZMes0QRjG2KLhMG=qacFrho+UFPVAG=YXg@mail.gmail.com>
[Re: [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver] On 22/12/2015 (Tue 21:36) Daniel Kurtz wrote:
> Hi Matthias,
>
> One thing below is missing from this version of the patch...
>
> > On Fri, Dec 18, 2015 at 7:19 PM, Matthias Brugger
> > <matthias.bgg@gmail.com> wrote:
> >> SCPSYS can't be built as module. Use builtin_platform_driver instead.
> >> For this probe must not be __init and the data accessed can't be
> >> __initconst. Remove this macros. To make the impact as small as possible,
> >> fold scp_domain_data into scp_domain via a pointer.
>
> [snip]
>
> >> @@ -542,10 +533,11 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
> >> };
> >>
> >> static struct platform_driver scpsys_drv = {
> >> + .probe = scpsys_probe,
> >> .driver = {
> >> .name = "mtk-scpsys",
>
> This was in Sascha's version of the patch:
>
> .suppress_bind_attrs = true,
Unless you've got a very specific use case where an unbind makes sense
(like a quad port ethernet card, where you unbind one port and then do
PCI pass through of it to a kvm guest for example) then yes, you should
suppress unbind. So for most drivers aimed at a single device, or where
being built in but unbinding just makes no sense for any possible use
case, then yes you should set the above.
Paul.
--
>
> Do we still need it now that we use "builtin_platform_driver"?
>
> >> .owner = THIS_MODULE,
> >> .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> >> },
> >> };
> >> -builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
> >> +builtin_platform_driver(scpsys_drv);
> >> --
> >> 2.6.2
> >>
next prev parent reply other threads:[~2015-12-22 15:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1450437573-32079-1-git-send-email-matthias.bgg@gmail.com>
2015-12-22 13:31 ` [PATCH] soc: mediatek: SCPSYS: use builtin_platform_driver Daniel Kurtz
2015-12-22 13:31 ` Daniel Kurtz
2015-12-22 13:36 ` Daniel Kurtz
2015-12-22 13:36 ` Daniel Kurtz
[not found] ` <CAGS+omDrZO8PteeFZMes0QRjG2KLhMG=qacFrho+UFPVAG=YXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-22 15:48 ` Paul Gortmaker [this message]
2015-12-22 15:48 ` Paul Gortmaker
2015-12-22 15:48 ` Paul Gortmaker
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=20151222154808.GC12458@windriver.com \
--to=paul.gortmaker-cwa4wttnnzf54taoqtywwq@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
/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.