Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	dlemoal@kernel.org, "Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/2] PCI: dwc: ep: Fix broken set_msix() callback
Date: Mon, 12 May 2025 11:28:28 +0200	[thread overview]
Message-ID: <aCG_PC3llyx3bs34@ryzen> (raw)
In-Reply-To: <kgw4y5mrvt3g6vnnkiaicufticbpyc5vmhbo6ee4g7ayg2hntt@fogtz5lizk5f>

On Mon, May 12, 2025 at 01:00:02PM +0530, Manivannan Sadhasivam wrote:
> On Sat, May 10, 2025 at 01:43:39PM +0200, Niklas Cassel wrote:
> > On Sat, May 10, 2025 at 11:27:55AM +0530, Manivannan Sadhasivam wrote:
> > > On Wed, Apr 30, 2025 at 02:31:59PM +0200, Niklas Cassel wrote:
> > > > While the parameter 'interrupts' to the functions pci_epc_set_msi() and
> > > > pci_epc_set_msix() represent the actual number of interrupts, and
> > > > pci_epc_get_msi() and pci_epc_get_msix() return the actual number of
> > > > interrupts.
> > > > 
> > > > These endpoint library functions just mentioned will however supply
> > > > "interrupts - 1" to the EPC callback functions pci_epc_ops->set_msi() and
> > > > pci_epc_ops->set_msix(), and likewise add 1 to return value from
> > > > pci_epc_ops->get_msi() and pci_epc_ops->get_msix(),
> > > 
> > > Only {get/set}_msix() callbacks were having this behavior, right?
> > 
> > pci_epc_get_msix() adds 1 to the return of epc->ops->get_msix().
> > pci_epc_set_msix() subtracts 1 to the parameter sent to epc->ops->set_msix().
> > 
> > pci_epc_get_msi() does 1 << interrupt from the return of epc->ops->get_msi().
> > So a return of 0 from epc->ops->get_msi() will result in pci_epc_get_msi()
> > returning 1. A return of 1 from epc->ops->get_msi() will result in
> > pci_epc_get_msi() returning 2.
> > 
> > Similar for pci_epc_set_msi(). It will call order_base_2() on the parameter
> > before sending it to epc->ops->set_msi().
> > 
> 
> Yeah. I was pointing out the fact that bitshifting != incrementing/decrementing
> 1. And you just mentioned the latter for both msi/msix callbacks. I can ammend
> it while applying.

Thank you!



> > I am a bit worried about patches after the cleanup getting backported, which
> > will need to be different before and after this cleanup.
> 
> We can add stable+noautosel to mark the patches to not backport.
> 
> > Perhaps renaming the
> > callbacks at the same as the cleanup might be a good idea?
> > 
> > It should be a simple cleanup though, just do the order_base_2() etc in the
> > driver callbacks themselves.
> > 
> > We really should rename the parameter of .set_msi() though, as it is totally
> > misleading as of now.
> > 
> 
> As I said above, we should keep the semantics for 'interrupt' and make changes
> accordingly i.e., by doing order_base_2() inside the callbacks as you suggested.

Yeah, I agree, better to rename the parameter of the existing callbacks that use
mmc/mme to interrupts, and actually perform the cleanup so that the take interrupts
instead of mmc/mme.


Considering that it is only 4 drivers, with a maximum of 4 callbacks in each driver
that needs to be cleaned up, it's not so bad.

Since we seem to have identified all the weirdness with the existing APIs,
let me try to cleanup this mess this week.


(Would be nice to get this fixed queued first though, so cleanup patches can
come on top.)


Kind regards,
Niklas

  reply	other threads:[~2025-05-12  9:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30 12:31 [PATCH 1/2] PCI: dwc: ep: Fix broken set_msix() callback Niklas Cassel
2025-04-30 12:32 ` [PATCH 2/2] PCI: cadence-ep: " Niklas Cassel
2025-05-01  2:04   ` Wilfred Mallawa
2025-05-01 19:02   ` Damien Le Moal
2025-05-01  2:04 ` [PATCH 1/2] PCI: dwc: ep: " Wilfred Mallawa
2025-05-01 19:01 ` Damien Le Moal
2025-05-10  5:57 ` Manivannan Sadhasivam
2025-05-10 11:43   ` Niklas Cassel
2025-05-12  7:30     ` Manivannan Sadhasivam
2025-05-12  9:28       ` Niklas Cassel [this message]
2025-05-12 16:56         ` Niklas Cassel

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=aCG_PC3llyx3bs34@ryzen \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dlemoal@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=robh@kernel.org \
    --cc=wilfred.mallawa@wdc.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