All of lore.kernel.org
 help / color / mirror / Atom feed
From: paul.gortmaker@windriver.com (Paul Gortmaker)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support
Date: Tue, 9 Aug 2016 12:00:39 -0400	[thread overview]
Message-ID: <20160809160039.GX29630@windriver.com> (raw)
In-Reply-To: <CAAtXAHev2Dytadp-_Hs0agcSXUTyrFhJQxHcsFd7faOReHzr9Q@mail.gmail.com>

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 (Mon 13:44) Moritz Fischer wrote:

> Hi Alan,
> 
> On Mon, Aug 8, 2016 at 12:18 PM, atull <atull@opensource.altera.com> wrote:
> 
> >> Please don't use module.h in drivers controlled by a bool
> >> Kconfig setting.
> >>
> >> THanks,
> >> Paul.
> >>
> >
> > Thanks for the feedback.  Can you provide an example of what you
> > would consider to be proper usage in the kernel?
> 
> 
> I think Paul is suggesting to use
> 
> static int __init alt_fpga_bridge_init(void)
> {
>         platform_driver_register(&alt_fpga_bridge_driver);
> }
> 
> device_initcall(alt_fpga_bridge_init);
> 
> or better:
> 
> builtin_platform_driver(&alt_fpga_bridge_driver);
> 
> Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Yes, pretty much that -- if you have a bool Kconfig, you should be using
builtin registration functions, and have no need for module.h or
anything MODULE_<xyz> or any module_init/module_exit calls.

An empty file containing nothing but #include <linux/module.h> will
cause cpp to emit about 750k of goop, so we really should only be using
it for drivers that are genuinely modular; i.e. tristate Kconfig.

Thanks,
Paul.
--

> 
> Cheers,
> 
> Moritz

WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Moritz Fischer <moritz.fischer@ettus.com>
Cc: atull <atull@opensource.altera.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Dinh Nguyen <dinguyen@opensource.altera.com>,
	Devicetree List <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Alan Tull <delicious.quinoa@gmail.com>,
	Matthew Gerlach <mgerlach@altera.com>
Subject: Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support
Date: Tue, 9 Aug 2016 12:00:39 -0400	[thread overview]
Message-ID: <20160809160039.GX29630@windriver.com> (raw)
In-Reply-To: <CAAtXAHev2Dytadp-_Hs0agcSXUTyrFhJQxHcsFd7faOReHzr9Q@mail.gmail.com>

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 (Mon 13:44) Moritz Fischer wrote:

> Hi Alan,
> 
> On Mon, Aug 8, 2016 at 12:18 PM, atull <atull@opensource.altera.com> wrote:
> 
> >> Please don't use module.h in drivers controlled by a bool
> >> Kconfig setting.
> >>
> >> THanks,
> >> Paul.
> >>
> >
> > Thanks for the feedback.  Can you provide an example of what you
> > would consider to be proper usage in the kernel?
> 
> 
> I think Paul is suggesting to use
> 
> static int __init alt_fpga_bridge_init(void)
> {
>         platform_driver_register(&alt_fpga_bridge_driver);
> }
> 
> device_initcall(alt_fpga_bridge_init);
> 
> or better:
> 
> builtin_platform_driver(&alt_fpga_bridge_driver);
> 
> Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Yes, pretty much that -- if you have a bool Kconfig, you should be using
builtin registration functions, and have no need for module.h or
anything MODULE_<xyz> or any module_init/module_exit calls.

An empty file containing nothing but #include <linux/module.h> will
cause cpp to emit about 750k of goop, so we really should only be using
it for drivers that are genuinely modular; i.e. tristate Kconfig.

Thanks,
Paul.
--

> 
> Cheers,
> 
> Moritz

  reply	other threads:[~2016-08-09 16:00 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12 19:36 [PATCH v18 0/6] Device Tree support for FPGA Programming Alan Tull
2016-07-12 19:36 ` Alan Tull
2016-07-12 19:36 ` Alan Tull
2016-07-12 19:36 ` [PATCH v18 1/6] fpga: add bindings document for fpga region Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-21 19:39   ` Rob Herring
2016-07-21 19:39     ` Rob Herring
2016-07-12 19:36 ` [PATCH v18 2/6] ARM: socfpga: add bindings document for fpga bridge drivers Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-08-01 16:18   ` Rob Herring
2016-08-01 16:18     ` Rob Herring
2016-08-01 16:18     ` Rob Herring
2016-08-03 18:44     ` atull
2016-08-03 18:44       ` atull
2016-08-03 18:44       ` atull
2016-07-12 19:36 ` [PATCH v18 3/6] add sysfs document for fpga bridge class Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36 ` [PATCH v18 4/6] fpga: add fpga bridge framework Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-14 20:54   ` Paul Gortmaker
2016-07-14 20:54     ` Paul Gortmaker
2016-07-15 16:58     ` Alan Tull
2016-07-15 16:58       ` Alan Tull
2016-07-15 16:58       ` Alan Tull
2016-07-12 19:36 ` [PATCH v18 5/6] fpga: fpga-region: device tree control for FPGA Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36 ` [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-12 19:36   ` Alan Tull
2016-07-14 20:47   ` Paul Gortmaker
2016-07-14 20:47     ` Paul Gortmaker
2016-08-08 19:18     ` atull
2016-08-08 19:18       ` atull
2016-08-08 19:18       ` atull
2016-08-08 20:44       ` Moritz Fischer
2016-08-08 20:44         ` Moritz Fischer
2016-08-08 20:44         ` Moritz Fischer
2016-08-09 16:00         ` Paul Gortmaker [this message]
2016-08-09 16:00           ` Paul Gortmaker
2016-09-22 19:53           ` atull
2016-09-22 19:53             ` atull
2016-09-22 19:53             ` atull
2016-09-23 14:13   ` Steffen Trumtrar
2016-09-23 14:13     ` Steffen Trumtrar
2016-07-12 19:43 ` [PATCH v18 0/6] Device Tree support for FPGA Programming atull
2016-07-12 19:43   ` atull
2016-07-12 19:43   ` atull

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=20160809160039.GX29630@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=linux-arm-kernel@lists.infradead.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.