linux-kernel - Re: Linux 5.16-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211129152504.GA2283304@roeck-us.net>
Date:   Mon, 29 Nov 2021 07:25:04 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Sergio Paracuellos <sergio.paracuellos@...il.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: Linux 5.16-rc3

On Mon, Nov 29, 2021 at 01:18:12PM +0100, Sergio Paracuellos wrote:
[ ... ]

> >
> > All proposals I have seen assume that PCIE_MT7621=m. As I said, I think
> > that it is pointless to do that because the driver can only be built
> > as module if COMPILE_TEST=y. We should not [have to] export symbols
> > because of that.
> 
Of course, the above is wrong. Of course a driver can be build as module
if all of its dependencies are built into the kernel. No idea what I was
thinking.

> The proposal I sent when this error was reported in rc1 [0] does not
> need to do any export of symbol at all since moves all MIPS related
> code inside the driver into ralink architecture mt7621 specific site
> making use of core api 'pcibios_root_bridge_prepare()'. The only
> problem that seems to be is with PATCH 1 of the series because it
> seems that nobody remember why already parsed addresses from device
> tree which are stored in 'bridge->windows' are temporary moved into an
> internal 'resources' variable at the beginning of
> 'pci_register_host_bridge()' function and also moved back again at the
> end. I do think the approach in this series is correct and really want
> a reason for why it is not, since for me passing around an incomplete
> 'bridge' pointer to 'pcibios_root_bridge_prepare()' when things are
> supposed to be parsed already is a bit odd, but I don't have all the
> problems of that code along the time... With the approach of this
> series we:
> - avoid MIPS architecture specific code in PCI controller driver.
> - Allow the driver to be compile tested for any single architecture
> for all yes* and mod* configurations.
> 
> Other ralink drivers have also been asked to be compiled as modules.
> See for example, commit fef532ea0cd8 ("MIPS: ralink: export
> rt_sysc_membase for rt2880_wdt.c") (here an export symbol was
> needed...). Also I was advised in the past that new drivers don't have
> to be 'bool' but 'tristate'. See this is commit 15692a80d949 ("phy:
> Revert "phy: ralink: Kconfig: convert mt7621-pci-phy into 'bool'"")
> where my 'bool' was reverted to 'tristate' and phy subsystem pull
> request refused to be applied in first try because of this commit [1].
> 
> [0]: https://marc.info/?l=linux-pci&m=163696011110084&w=3ç
> [1]: https://www.spinics.net/lists/kernel/msg3986821.html
> 
> Thanks in advance for your time.
> 
Guess we'll have to live with the build failure for a while then.

Guenter