Thread (20 messages) 20 messages, 4 authors, 2021-11-15

Re: [PATCH v2 2/3] MIPS: cm/cpc: export some missing symbols to be able to use them from driver code

From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Date: 2021-10-29 05:30:59
Also in: linux-arm-kernel, linux-mediatek, linux-next, linux-pci

On Thu, Oct 28, 2021 at 10:47 PM Bjorn Helgaas [off-list ref] wrote:
On Thu, Oct 28, 2021 at 11:59:17AM +0200, Sergio Paracuellos wrote:
quoted
On Thu, Oct 28, 2021 at 11:34 AM Sergio Paracuellos
[off-list ref] wrote:
quoted
On Thu, Oct 28, 2021 at 11:24 AM Thomas Bogendoerfer
[off-list ref] wrote:
quoted
On Thu, Oct 28, 2021 at 06:11:18AM +0200, Sergio Paracuellos wrote:
quoted
On Thu, Oct 28, 2021 at 6:05 AM Yanteng Si [off-list ref] wrote:
quoted
Since commit 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
the MT7621 PCIe host controller driver is built as a module but modpost complains once these
drivers become modules.

ERROR: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!

Let's just export them.

Signed-off-by: Yanteng Si <redacted>
---
 arch/mips/kernel/mips-cm.c  | 5 +++++
 arch/mips/kernel/mips-cpc.c | 1 +
 2 files changed, 6 insertions(+)
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
could we instead make the pcie-mt761 driver non modular ? Exporting
all MIPS specific stuff for just making an essential driver modular
doesn't IMHO make much sense.
The driver is modular because I have been advised other times that new
drivers should be able to be compiled as modules and we should avoid
using 'bool' in Kconfig for new drivers. That's the only reason. I am
also always including as 'y' the driver since for me not having pci in
my boards has no sense... I am ok in changing Kconfig to be 'bool'
instead of 'tristate', but I don't know what should be the correct
thing to do in this case. Thoughts?
I guess we also want the driver to at least be compile tested in
'allmodconfig' and other similars...15692a80d949
Sounds like the systems that actually use this driver require it to be
built-in, and the only benefit of exporting these symbols is that we
would get better compile test coverage.

If that's the case, I agree that it's better to just make it
non-modular.
I agree and that was my reasoning for sending a patch to also convert
to bool the phy driver that this PCIe controller uses. When the pull
request was sent from Vinod to Greg, Greg refused to take it because
of that commit and the commit was reverted and a new pull request was
sent including this revert. This is commit 15692a80d949 ("phy: Revert
"phy: ralink: Kconfig: convert mt7621-pci-phy into 'bool'""). Because
of this I also changed the PCIe controller Kconfig from bool to
tristate when I sent v3 of the series which at the end were the ones
that was finally taken. There are also other ralink related symbols
that have been exported to allow to compile other drivers as a
modules, like the watchdog. See the commit fef532ea0cd8 ("MIPS:
ralink: export rt_sysc_membase for rt2880_wdt.c"). So, as I said, I
agree and I am using the driver as if it were a bool and also ralink
systems normally require all drivers built-in, but I think we have to
take into account also the "historical facts" here. In any case,
Bjorn, let me know if you want me to send whatever patch might be
needed.

Best regards,
    Sergio Paracuellos
Bjorn
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help