[0/5] PCI: mt7621: remove specific MIPS code from driver

Message

Sergio Paracuellos Nov. 15, 2021, 7:08 a.m. UTC

Hi all,

MIPS specific code can be removed from driver and put into ralink mt7621
instead which is a more accurate place to do this. To make this possible
we need to have access to 'bridge->windows' in 'pcibios_root_bridge_prepare()'
which has been implemented for ralink mt7621 platform (there is no real 
need to implement this for any other platforms since those ones haven't got
I/O coherency units). This also allow us to properly enable this driver to
completely be enabled for COMPILE_TEST. This patchset appoarch:
- Move windows list splice in 'pci_register_host_bridge()' after function 
  'pcibios_root_bridge_prepare()' is called.
- Implement 'pcibios_root_bridge_prepare()' for ralink mt7621.
- Avoid custom MIPs code in pcie-mt7621 driver.
- Add missing 'MODULE_LICENSE()' to pcie-mt7621 driver to avoid compile test 
  module compilation to complain (already sent patch from Yanteng Si that
  I have rewrite commit message and long description a bit.
- Remove MIPS conditional code from Kconfig.

This patchset also fix some errors reported by Kernel Test Robot about
implicit mips functions used in driver code and fix errors in driver when
is compiled as a module [1] (mips:allmodconfig).

There was an ongoing discussion about this here [0] but I preferred to send
my proposal for better review and understanding:

[0]: https://lore.kernel.org/linux-mips/CAMhs-H8ShoaYiFOOzJaGC68nZz=V365RXN_Kjuj=[e-mail]/T/#t
[1]: https://lkml.org/lkml/2021/11/14/436

Thanks in advance for your time.

Best regards,
   Sergio Paracuellos

Sergio Paracuellos (5):
  PCI: let 'pcibios_root_bridge_prepare()' access to 'bridge->windows'
  MIPS: ralink: implement 'pcibios_root_bridge_prepare()'
  PCI: mt7621: avoid custom MIPS code in driver code
  PCI: mt7621: Add missing 'MODULE_LICENSE()' definition
  PCI: mt7621: Kconfig: completely enable driver for 'COMPILE_TEST'

 arch/mips/ralink/mt7621.c            | 30 +++++++++++++++++++++
 drivers/pci/controller/Kconfig       |  2 +-
 drivers/pci/controller/pcie-mt7621.c | 39 ++--------------------------
 drivers/pci/probe.c                  |  4 +--
 4 files changed, 35 insertions(+), 40 deletions(-)

Comments

Thomas Bogendoerfer Nov. 17, 2021, 12:41 p.m. UTC | #1

On Mon, Nov 15, 2021 at 08:08:04AM +0100, Sergio Paracuellos wrote:
> Hi all,
> 
> MIPS specific code can be removed from driver and put into ralink mt7621
> instead which is a more accurate place to do this. To make this possible
> we need to have access to 'bridge->windows' in 'pcibios_root_bridge_prepare()'
> which has been implemented for ralink mt7621 platform (there is no real 
> need to implement this for any other platforms since those ones haven't got
> I/O coherency units). This also allow us to properly enable this driver to
> completely be enabled for COMPILE_TEST. This patchset appoarch:
> - Move windows list splice in 'pci_register_host_bridge()' after function 
>   'pcibios_root_bridge_prepare()' is called.
> - Implement 'pcibios_root_bridge_prepare()' for ralink mt7621.
> - Avoid custom MIPs code in pcie-mt7621 driver.
> - Add missing 'MODULE_LICENSE()' to pcie-mt7621 driver to avoid compile test 
>   module compilation to complain (already sent patch from Yanteng Si that
>   I have rewrite commit message and long description a bit.
> - Remove MIPS conditional code from Kconfig.
> 
> This patchset also fix some errors reported by Kernel Test Robot about
> implicit mips functions used in driver code and fix errors in driver when
> is compiled as a module [1] (mips:allmodconfig).
> 
> There was an ongoing discussion about this here [0] but I preferred to send
> my proposal for better review and understanding:

so what's the plan with this patchset ? Going in as fix, probably via
pci tree ? Or is material for next release ? If the latter can we first
fix the allmodconfig by making the Kconfig symbol bool ?

Thomas.

Sergio Paracuellos Nov. 17, 2021, 12:48 p.m. UTC | #2

On Wed, Nov 17, 2021 at 1:41 PM Thomas Bogendoerfer
<[e-mail]> wrote:
>
> On Mon, Nov 15, 2021 at 08:08:04AM +0100, Sergio Paracuellos wrote:
> > Hi all,
> >
> > MIPS specific code can be removed from driver and put into ralink mt7621
> > instead which is a more accurate place to do this. To make this possible
> > we need to have access to 'bridge->windows' in 'pcibios_root_bridge_prepare()'
> > which has been implemented for ralink mt7621 platform (there is no real
> > need to implement this for any other platforms since those ones haven't got
> > I/O coherency units). This also allow us to properly enable this driver to
> > completely be enabled for COMPILE_TEST. This patchset appoarch:
> > - Move windows list splice in 'pci_register_host_bridge()' after function
> >   'pcibios_root_bridge_prepare()' is called.
> > - Implement 'pcibios_root_bridge_prepare()' for ralink mt7621.
> > - Avoid custom MIPs code in pcie-mt7621 driver.
> > - Add missing 'MODULE_LICENSE()' to pcie-mt7621 driver to avoid compile test
> >   module compilation to complain (already sent patch from Yanteng Si that
> >   I have rewrite commit message and long description a bit.
> > - Remove MIPS conditional code from Kconfig.
> >
> > This patchset also fix some errors reported by Kernel Test Robot about
> > implicit mips functions used in driver code and fix errors in driver when
> > is compiled as a module [1] (mips:allmodconfig).
> >
> > There was an ongoing discussion about this here [0] but I preferred to send
> > my proposal for better review and understanding:
>
> so what's the plan with this patchset ? Going in as fix, probably via
> pci tree ? Or is material for next release ? If the latter can we first
> fix the allmodconfig by making the Kconfig symbol bool ?

If the approach is considered valid I guess it should go as a fix to
avoid changing first to 'bool' the Kconfig symbol. If it is not a
valid approach I will send patches with a possible new requested
approach or just making the symbol bool and adding specific mips
includes to driver code to avoid mips implicit functions errors.

Best regards,
    Sergio Paracuellos
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]