From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*
Date: Tue, 15 Dec 2015 15:16:24 +0000 [thread overview]
Message-ID: <20151215151624.GB2772@windriver.com> (raw)
In-Reply-To: <3302340.SIljl1qYTl@wuerfel>
[Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*] On 14/12/2015 (Mon 11:27) Arnd Bergmann wrote:
> On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > > Fixup region is in kernel region and this region if not updated when
> > > loading a module.
> >
> > Interesting, I hadn't thought about that. I suppose this means that the
> > module will end up containing an unused section with the fixup code. It
> > might be useful to add a way for that to trigger a warning at build
> > time.
> >
> > Perhaps to fix this a mechanism could be introduced to add a table of
> > fixups to a host controller driver and that will get applied to all
> > children of the bridge. It could be problematic to cover all of the
> > different fixup stages, though.
> >
>
>
> I think a lot of the fixups shouldn't really be there in the first place,
> they are about stuff that we can fix up in the probe function, or that should
> be fixed up in the probe function with some appropriate core support added.
So, the feedback on this is a bit all over the map, leaving me unsure
what to do next. And is the choice we make on a per board/bsp basis or
ideally across all platforms? I see the choices as:
1) do nothing; which IMHO is least desirable as it leaves the code
misrepresenting itself as modular; one of the key issues I wanted to fix
2) use the patches I've sent ; then as they are genuinely made modular,
the person doing so essentially "patch -R" or reverts the change as
step one. This has the advantage of solving the "we'll get to it
someday" issue if someday never comes.
3) make them all tristate; beat it with a stick until it compiles [M]
and modposts -- leaving the fixups and functional testing to people with
the boards and low level knowledge to make it _work_ as a module. The
downside here is the code is still kind of misrepresenting itself as
modularly functional -- a ban of unloading might mitigate that some.
Paul.
--
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Linux-sh list" <linux-sh@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>,
"Rocketboard Maillist" <rfi@lists.rocketboards.org>,
linux-tegra@vger.kernel.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"Alexandre Courbot" <gnurou@gmail.com>,
"Pratyush Anand" <pratyush.anand@gmail.com>,
"Michal Simek" <michal.simek@xilinx.com>,
"Kishon Vijay Abraham I" <kishon@ti.com>,
"Murali Karicheri" <m-karicheri2@ti.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Jason Cooper" <jason@lakedaemon.net>,
"Stephen Warren" <swarren@wwwdotorg.org>,
"Simon Horman" <horms@verge.net.au>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*
Date: Tue, 15 Dec 2015 10:16:24 -0500 [thread overview]
Message-ID: <20151215151624.GB2772@windriver.com> (raw)
In-Reply-To: <3302340.SIljl1qYTl@wuerfel>
[Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*] On 14/12/2015 (Mon 11:27) Arnd Bergmann wrote:
> On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > > Fixup region is in kernel region and this region if not updated when
> > > loading a module.
> >
> > Interesting, I hadn't thought about that. I suppose this means that the
> > module will end up containing an unused section with the fixup code. It
> > might be useful to add a way for that to trigger a warning at build
> > time.
> >
> > Perhaps to fix this a mechanism could be introduced to add a table of
> > fixups to a host controller driver and that will get applied to all
> > children of the bridge. It could be problematic to cover all of the
> > different fixup stages, though.
> >
>
>
> I think a lot of the fixups shouldn't really be there in the first place,
> they are about stuff that we can fix up in the probe function, or that should
> be fixed up in the probe function with some appropriate core support added.
So, the feedback on this is a bit all over the map, leaving me unsure
what to do next. And is the choice we make on a per board/bsp basis or
ideally across all platforms? I see the choices as:
1) do nothing; which IMHO is least desirable as it leaves the code
misrepresenting itself as modular; one of the key issues I wanted to fix
2) use the patches I've sent ; then as they are genuinely made modular,
the person doing so essentially "patch -R" or reverts the change as
step one. This has the advantage of solving the "we'll get to it
someday" issue if someday never comes.
3) make them all tristate; beat it with a stick until it compiles [M]
and modposts -- leaving the fixups and functional testing to people with
the boards and low level knowledge to make it _work_ as a module. The
downside here is the code is still kind of misrepresenting itself as
modularly functional -- a ban of unloading might mitigate that some.
Paul.
--
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Ley Foon Tan" <lftan@altera.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Linux-sh list" <linux-sh@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>,
"Alexandre Courbot" <gnurou@gmail.com>,
"Pratyush Anand" <pratyush.anand@gmail.com>,
"Michal Simek" <michal.simek@xilinx.com>,
"Kishon Vijay Abraham I" <kishon@ti.com>,
"Murali Karicheri" <m-karicheri2@ti.com>,
"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
"Jason Cooper" <jason@lakedaemon.net>,
"Stephen Warren" <swarren@wwwdotorg.org>,
"Simon Horman" <horms@verge.net.au>,
linux-tegra@vger.kernel.org,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
"Richard Zhu" <Richard.Zhu@freescale.com>,
"Rocketboard Maillist" <rfi@lists.rocketboards.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lucas Stach" <l.stach@pengutronix.de>
Subject: Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*
Date: Tue, 15 Dec 2015 10:16:24 -0500 [thread overview]
Message-ID: <20151215151624.GB2772@windriver.com> (raw)
In-Reply-To: <3302340.SIljl1qYTl@wuerfel>
[Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*] On 14/12/2015 (Mon 11:27) Arnd Bergmann wrote:
> On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > > Fixup region is in kernel region and this region if not updated when
> > > loading a module.
> >
> > Interesting, I hadn't thought about that. I suppose this means that the
> > module will end up containing an unused section with the fixup code. It
> > might be useful to add a way for that to trigger a warning at build
> > time.
> >
> > Perhaps to fix this a mechanism could be introduced to add a table of
> > fixups to a host controller driver and that will get applied to all
> > children of the bridge. It could be problematic to cover all of the
> > different fixup stages, though.
> >
>
>
> I think a lot of the fixups shouldn't really be there in the first place,
> they are about stuff that we can fix up in the probe function, or that should
> be fixed up in the probe function with some appropriate core support added.
So, the feedback on this is a bit all over the map, leaving me unsure
what to do next. And is the choice we make on a per board/bsp basis or
ideally across all platforms? I see the choices as:
1) do nothing; which IMHO is least desirable as it leaves the code
misrepresenting itself as modular; one of the key issues I wanted to fix
2) use the patches I've sent ; then as they are genuinely made modular,
the person doing so essentially "patch -R" or reverts the change as
step one. This has the advantage of solving the "we'll get to it
someday" issue if someday never comes.
3) make them all tristate; beat it with a stick until it compiles [M]
and modposts -- leaving the fixups and functional testing to people with
the boards and low level knowledge to make it _work_ as a module. The
downside here is the code is still kind of misrepresenting itself as
modularly functional -- a ban of unloading might mitigate that some.
Paul.
--
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: paul.gortmaker@windriver.com (Paul Gortmaker)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*
Date: Tue, 15 Dec 2015 10:16:24 -0500 [thread overview]
Message-ID: <20151215151624.GB2772@windriver.com> (raw)
In-Reply-To: <3302340.SIljl1qYTl@wuerfel>
[Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*] On 14/12/2015 (Mon 11:27) Arnd Bergmann wrote:
> On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > > Fixup region is in kernel region and this region if not updated when
> > > loading a module.
> >
> > Interesting, I hadn't thought about that. I suppose this means that the
> > module will end up containing an unused section with the fixup code. It
> > might be useful to add a way for that to trigger a warning at build
> > time.
> >
> > Perhaps to fix this a mechanism could be introduced to add a table of
> > fixups to a host controller driver and that will get applied to all
> > children of the bridge. It could be problematic to cover all of the
> > different fixup stages, though.
> >
>
>
> I think a lot of the fixups shouldn't really be there in the first place,
> they are about stuff that we can fix up in the probe function, or that should
> be fixed up in the probe function with some appropriate core support added.
So, the feedback on this is a bit all over the map, leaving me unsure
what to do next. And is the choice we make on a per board/bsp basis or
ideally across all platforms? I see the choices as:
1) do nothing; which IMHO is least desirable as it leaves the code
misrepresenting itself as modular; one of the key issues I wanted to fix
2) use the patches I've sent ; then as they are genuinely made modular,
the person doing so essentially "patch -R" or reverts the change as
step one. This has the advantage of solving the "we'll get to it
someday" issue if someday never comes.
3) make them all tristate; beat it with a stick until it compiles [M]
and modposts -- leaving the fixups and functional testing to people with
the boards and low level knowledge to make it _work_ as a module. The
downside here is the code is still kind of misrepresenting itself as
modularly functional -- a ban of unloading might mitigate that some.
Paul.
--
>
> Arnd
next prev parent reply other threads:[~2015-12-15 15:16 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-13 1:41 [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci* Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 1:41 ` [PATCH 01/10] drivers/pci: make host/pci-imx6.c driver explicitly non-modular Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-14 8:52 ` Arnd Bergmann
2015-12-14 8:52 ` Arnd Bergmann
2015-12-13 1:41 ` [PATCH 02/10] drivers/pci: make host/pcie-spear13xx.c " Paul Gortmaker
2015-12-13 1:41 ` [PATCH 03/10] drivers/pci: make host/pci-mvebu.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 10:33 ` Thomas Petazzoni
2015-12-13 10:33 ` Thomas Petazzoni
2015-12-14 8:54 ` Arnd Bergmann
2015-12-14 8:54 ` Arnd Bergmann
2015-12-13 1:41 ` [PATCH 04/10] drivers/pci: make host/pci-dra7xx.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 1:41 ` [PATCH 05/10] drivers/pci: make host/pci-rcar-gen2.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 10:59 ` Geert Uytterhoeven
2015-12-13 10:59 ` Geert Uytterhoeven
2015-12-13 18:15 ` Paul Gortmaker
2015-12-13 18:15 ` Paul Gortmaker
2015-12-13 20:37 ` Joe Perches
2015-12-13 20:37 ` Joe Perches
2015-12-14 5:19 ` Simon Horman
2015-12-14 5:19 ` Simon Horman
2015-12-13 1:41 ` [PATCH 06/10] drivers/pci: make host/pci-tegra.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-14 8:15 ` Thierry Reding
2015-12-13 1:41 ` [PATCH 07/10] drivers/pci: make host/pcie-rcar.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 10:58 ` Geert Uytterhoeven
2015-12-13 10:58 ` Geert Uytterhoeven
2015-12-13 18:20 ` Paul Gortmaker
2015-12-13 18:20 ` Paul Gortmaker
2015-12-17 11:32 ` Phil Edworthy
2015-12-17 11:32 ` Phil Edworthy
2015-12-17 11:32 ` Phil Edworthy
2015-12-17 16:06 ` Paul Gortmaker
2015-12-17 16:06 ` Paul Gortmaker
2015-12-14 5:19 ` Simon Horman
2015-12-14 5:19 ` Simon Horman
2015-12-13 1:41 ` [PATCH 08/10] drivers/pci: make host/pcie-xilinx.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-14 7:25 ` Michal Simek
2015-12-14 7:25 ` Michal Simek
2015-12-13 1:41 ` [PATCH 09/10] drivers/pci: make host/pci-keystone.c " Paul Gortmaker
2015-12-13 1:41 ` Paul Gortmaker
2015-12-13 1:41 ` [PATCH 10/10] drivers/pci: make host/pcie-altera.c " Paul Gortmaker
2015-12-14 8:19 ` [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci* Geert Uytterhoeven
2015-12-14 8:19 ` Geert Uytterhoeven
2015-12-14 8:19 ` Geert Uytterhoeven
2015-12-14 8:19 ` Geert Uytterhoeven
2015-12-14 8:24 ` Thierry Reding
2015-12-14 8:24 ` Thierry Reding
2015-12-14 8:24 ` Thierry Reding
2015-12-14 8:24 ` Thierry Reding
2015-12-14 8:26 ` Michal Simek
2015-12-14 8:26 ` Michal Simek
2015-12-14 8:26 ` Michal Simek
2015-12-14 8:26 ` Michal Simek
2015-12-14 8:33 ` Ley Foon Tan
2015-12-14 8:33 ` Ley Foon Tan
2015-12-14 8:33 ` Ley Foon Tan
2015-12-14 8:33 ` Ley Foon Tan
2015-12-14 9:19 ` Thierry Reding
2015-12-14 9:19 ` Thierry Reding
2015-12-14 9:19 ` Thierry Reding
2015-12-14 9:19 ` Thierry Reding
2015-12-14 10:27 ` Arnd Bergmann
2015-12-14 10:27 ` Arnd Bergmann
2015-12-14 10:27 ` Arnd Bergmann
2015-12-14 10:27 ` Arnd Bergmann
2015-12-15 15:16 ` Paul Gortmaker [this message]
2015-12-15 15:16 ` Paul Gortmaker
2015-12-15 15:16 ` Paul Gortmaker
2015-12-15 15:16 ` Paul Gortmaker
2016-01-08 20:31 ` Bjorn Helgaas
2016-01-08 20:31 ` Bjorn Helgaas
2016-01-08 20:31 ` Bjorn Helgaas
2016-01-08 20:31 ` Bjorn Helgaas
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=20151215151624.GB2772@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.