linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: Linux 5.16-rc3
Date: Mon, 29 Nov 2021 13:23:46 +0100	[thread overview]
Message-ID: <CAMhs-H-_HZQipStBoUtE+bu2QHDTksHytCVTu60+Yju+iqLVsQ@mail.gmail.com> (raw)
In-Reply-To: <20211129110202.GA23795@lpieralisi>

On Mon, Nov 29, 2021 at 12:02 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Sun, Nov 28, 2021 at 08:17:33PM -0800, Guenter Roeck wrote:
> > On 11/28/21 7:07 PM, Randy Dunlap wrote:
> > >
> > >
> > > On 11/28/21 17:59, Guenter Roeck wrote:
> > > > On Sun, Nov 28, 2021 at 02:21:20PM -0800, Linus Torvalds wrote:
> > > > > So rc3 is usually a bit larger than rc2 just because people had some
> > > > > time to start finding things.
> > > > >
> > > > > So too this time, although it's not like this is a particularly big
> > > > > rc3. Possibly partly due to the past week having been Thanksgiving
> > > > > week here in the US. But the size is well within the normal range, so
> > > > > if that's a factor, it's not been a big one.
> > > > >
> > > > > The diff for rc3 is mostly drivers, although part of that is just
> > > > > because of the removal of a left-over MIPS Netlogic driver which makes
> > > > > the stats look a bit wonky, and is over a third of the whole diff just
> > > > > in itself.
> > > > >
> > > > > If you ignore that part, the statistics look a bit more normal, but
> > > > > drivers still dominate (network drivers, sound and gpu are the big
> > > > > ones, but there is noise all over). Other than that there's once again
> > > > > a fair amount of selftest (mostly networking), along with core
> > > > > networking, some arch updates - the bulk of it from a single arm64
> > > > > uaccess patch, although that's mostly because it's all pretty small -
> > > > > and random other changes.
> > > > >
> > > > > Full shortlog below.
> > > > >
> > > > > Please test,
> > > > >
> > > >
> > > > Build results:
> > > >     total: 153 pass: 152 fail: 1
> > > > Failed builds:
> > > >     mips:allmodconfig
> > > > Qemu test results:
> > > >     total: 482 pass: 482 fail: 0
> > > >
> > > > Building mips:allmodconfig ... failed
> > > > --------------
> > > > Error log:
> > > > ERROR: modpost: missing MODULE_LICENSE() in drivers/pci/controller/pcie-mt7621.o
> > > > 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!
> > > >
> > > > There is still no fix for the mips:allmodconfig build problem as far
> > > > as I can see. It is a bit odd, because the fix would be as simple as
> > > >
> > > >   config PCIE_MT7621
> > > > -    tristate "MediaTek MT7621 PCIe Controller"
> > > > -    depends on (RALINK && SOC_MT7621) || (MIPS && COMPILE_TEST)
> > > > +    bool "MediaTek MT7621 PCIe Controller"
> > > > +    depends on SOC_MT7621 || (MIPS && COMPILE_TEST)
> > > >       select PHY_MT7621_PCI
> > > >       default SOC_MT7621
> > > >       help
> > > >
> > > > Context: tristate doesn't make sense here because both RALINK and
> > > > SOC_MT7621 are bool. Also, RALINK is redundant because SOC_MT7621
> > > > already depends on it. The compile failure is due to missing exported
> > > > symbols, and it is only seen if PCIE_MT7621=m - which is only possible
> > > > if COMPILE_TEST=y. In other words, the dependencies above are set such
> > > > that test builds, and only test builds, fail.
> > > >
> > > > The problem was introduced with commit 2bdd5238e756 ("PCI: mt7621:
> > > > Add MediaTek MT7621 PCIe host controller driver"). Copying some of
> > > > those responsible to see if we can expect a solution sometime soon.
> > >
> > >
> > > I sent a patch for this a couple of weeks ago and Sergio replied to it
> > > here:
> > >
> > > https://lore.kernel.org/linux-pci/CAMhs-H8TA0S23FjSRKGKeKAWWdUxET6YnivLQoFuy_fSVJOPXw@mail.gmail.com/
> > >
> > > saying that is a different patch out there but that it had not
> > > been reviewed yet.
> > >
> >
> > 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.
>
> Hi Sergio,

Hi Lorenzo,

>
> can we converge to a fix with this thread background in mind please ?

I have just answered Guenter's mail with my reasoning of the already
proposed patch series fix. Don't worry, I will send any patch if
necessary to fix this but I'd like to know why the current proposal is
not valid since it really looks like the correct thing to do...

Best regards,
   Sergio Paracuellos

> Thanks,
> Lorenzo

  reply	other threads:[~2021-11-29 13:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 22:21 Linux 5.16-rc3 Linus Torvalds
2021-11-29  1:59 ` Guenter Roeck
2021-11-29  3:07   ` Randy Dunlap
2021-11-29  4:17     ` Guenter Roeck
2021-11-29 11:02       ` Lorenzo Pieralisi
2021-11-29 12:23         ` Sergio Paracuellos [this message]
2021-11-29 12:18       ` Sergio Paracuellos
2021-11-29 15:25         ` Guenter Roeck
2021-12-01 20:38         ` Bjorn Helgaas
2021-12-01 20:50           ` Guenter Roeck
2021-12-01 21:38             ` Sergio Paracuellos

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=CAMhs-H-_HZQipStBoUtE+bu2QHDTksHytCVTu60+Yju+iqLVsQ@mail.gmail.com \
    --to=sergio.paracuellos@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).