From: Marc Zyngier <maz@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Marek Behún" <kabel@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 06/13] PCI: aardvark: Do not clear status bits of masked interrupts
Date: Tue, 05 Oct 2021 16:42:29 +0100 [thread overview]
Message-ID: <87lf37qxzu.wl-maz@kernel.org> (raw)
In-Reply-To: <20211005131545.ol3rb3zzgzze67uf@pali>
On Tue, 05 Oct 2021 14:15:45 +0100,
Pali Rohár <pali@kernel.org> wrote:
>
> Hello!
>
> I dislike this approach. It adds another magic number which is just
> causing issues. Please read commit message for patch 11/13 where we
> describe why such magic constants are bad and already caused lot of
> issues in this driver.
As I said, feel free to write something better.
>
> > > > /* Process MSI interrupts */
> > > > if (isr0_status & PCIE_ISR0_MSI_INT_PENDING)
> > > > advk_pcie_handle_msi(pcie);
> > > >
> > > > /* Process legacy interrupts */
> > > > - for (i = 0; i < PCI_NUM_INTX; i++) {
> > > > - if (!(isr1_status & PCIE_ISR1_INTX_ASSERT(i)))
> > > > - continue;
> > > > -
> > > > + for_each_set_bit(i, &isr1_status, PCI_NUM_INTX) {
> > > > advk_writel(pcie, PCIE_ISR1_INTX_ASSERT(i),
> > > > PCIE_ISR1_REG);
> > >
> > > 1. what you are doing here is code cleanup. We are currently in the
> > > state where we have lots of fixes for this driver, which we are
> > > hoping will go also to stable.
> >
> > Yes, it is code cleanup. Because I don't find this patch to be very
> > good, TBH. As for going into stable, that's not relevant for this
> > discussion.
> >
> > > Some of them depend on these changes.
> > > Can we please first apply those fixes (we want to send them in
> > > batches to avoid sending 60 patchs in one series, since last time
> > > nobody wanted to review all of that) and do this afterwards?
> >
> > It would be better to start with patches that are in a better
> > shape. After all, this is what the code review process is about. This
> > isn't "just take my patches".
> >
> > > 2. you are throwing away lower 8 bits of isr1_status. We have follow-up
> > > patches (not in this series, but in another batch which we want to
> > > send after this) that will be using those lower 8 bits, so we do not
> > > want to throw away them now.
> >
> > I'm discarding these bits because *in isolation*, that's the correct
> > thing to do. Feel free to propose a better patch that doesn't discard
> > these bits and still makes the code more palatable.
>
> The code pattern in this function is: compose irs*_status variable and
> then compare it with register macros defined at the top of driver. Each
> bit in this register represent some event and for each event there is
> simple macro to match.
>
> So with your proposed change it would break all macros (as they are
> going to be shifted by magic constant) and then this code disallow
> access to events represented by low bits. And also it makes code pattern
> different for isr0_status and isr1_status variables which is very
> confusing and probably source for introduction of new bugs.
Read what I have said: I'm suggesting changes based on this patch *in
isolation*. I don't see any other related patch in my inbox (nor do I
want to receive any). Feel free to suggest something better (that's
the third time I write this...).
> Also the whole early-return optimization can be removed as it does not
> change functionality. So we will do so.
>
> But we do not agree with the lower 8 bit discard of the isr1_status
> variable as explained above.
>
> So if we add the explanation to commit message and drop the early
> return, would it be ok?
Do what you want. I have no interest in this particular piece of code,
and only replied to Lorenzo's request. It doesn't change what I think
of this patch, but I have too much on my plate to get dragged into
sterile arguments.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-10-05 15:42 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 19:58 [PATCH 00/13] PCI: aardvark controller fixes Marek Behún
2021-10-01 19:58 ` [PATCH 01/13] PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros Marek Behún
2021-10-02 16:05 ` Bjorn Helgaas
2021-10-04 8:43 ` Lorenzo Pieralisi
2021-10-04 9:32 ` Marek Behún
2021-10-04 9:35 ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 02/13] PCI: aardvark: Fix PCIe Max Payload Size setting Marek Behún
2021-10-03 17:44 ` Marek Behún
2021-10-01 19:58 ` [PATCH 03/13] PCI: aardvark: Don't spam about PIO Response Status Marek Behún
2021-10-01 19:58 ` [PATCH 04/13] PCI: aardvark: Fix preserving PCI_EXP_RTCTL_CRSSVE flag on emulated bridge Marek Behún
2021-10-01 19:58 ` [PATCH 05/13] PCI: aardvark: Fix configuring Reference clock Marek Behún
2021-10-01 19:58 ` [PATCH 06/13] PCI: aardvark: Do not clear status bits of masked interrupts Marek Behún
2021-10-04 14:06 ` Lorenzo Pieralisi
2021-10-04 15:18 ` Marek Behún
2021-10-04 15:31 ` Marc Zyngier
2021-10-05 12:13 ` Marek Behún
2021-10-05 12:42 ` Marc Zyngier
2021-10-05 13:15 ` Pali Rohár
2021-10-05 15:42 ` Marc Zyngier [this message]
2021-10-05 18:48 ` Pali Rohár
2021-10-05 16:04 ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 07/13] PCI: aardvark: Do not unmask unused interrupts Marek Behún
2021-10-01 19:58 ` [PATCH 08/13] PCI: aardvark: Deduplicate code in advk_pcie_rd_conf() Marek Behún
2021-10-01 19:58 ` [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response Marek Behún
2021-10-02 16:35 ` Bjorn Helgaas
2021-10-04 7:21 ` Marek Behún
2021-10-04 8:53 ` Lorenzo Pieralisi
2021-10-04 10:19 ` Marek Behún
2021-10-05 19:28 ` Bjorn Helgaas
2021-10-05 22:45 ` Marek Behún
2021-10-11 18:15 ` Usage of PCBIOS_* macros (Was: Re: [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response) Pali Rohár
2021-10-11 20:58 ` Bjorn Helgaas
2021-10-06 16:29 ` [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response Lorenzo Pieralisi
2021-10-06 20:13 ` Bjorn Helgaas
2021-10-07 11:51 ` Lorenzo Pieralisi
2021-10-07 12:36 ` Marek Behún
2021-10-07 19:25 ` Bjorn Helgaas
2021-10-01 19:58 ` [PATCH 10/13] PCI: aardvark: Simplify initialization of rootcap on virtual bridge Marek Behún
2021-10-04 9:44 ` Lorenzo Pieralisi
2021-10-04 9:56 ` Marek Behún
2021-10-04 10:10 ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 11/13] PCI: aardvark: Fix link training Marek Behún
2021-10-01 19:58 ` [PATCH 12/13] PCI: aardvark: Fix checking for link up via LTSSM state Marek Behún
2021-10-04 13:35 ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 13/13] PCI: aardvark: Fix reporting Data Link Layer Link Active Marek Behún
2021-10-04 9:53 ` [PATCH 00/13] PCI: aardvark controller fixes Lorenzo Pieralisi
2021-10-04 10:40 ` Marek Behún
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=87lf37qxzu.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=bhelgaas@google.com \
--cc=kabel@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=pali@kernel.org \
--cc=stable@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/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).