From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 01/10] PCI: Add pci_host_alloc_intx_irqd() for allocating IRQ domain
Date: Thu, 19 Jul 2018 12:37:14 +0100 [thread overview]
Message-ID: <20180719113714.GC9213@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <20180614090902.7b30a0d2@windsurf>
On Thu, Jun 14, 2018 at 09:09:02AM +0200, Thomas Petazzoni wrote:
[...]
> > + sizeof(struct irq_domain_ops), GFP_KERNEL);
> > + if (!irqd_ops) {
> > + err = -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + irqd_ops->map = &pcie_intx_map;
> > + if (general_xlate)
> > + irqd_ops->xlate = &pci_irqd_intx_xlate;
> > + intx_domain_ops = irqd_ops;
> > + }
> > +#ifdef CONFIG_IRQ_DOMAIN
> > + domain = irq_domain_add_linear(intc, PCI_NUM_INTX,
> > + intx_domain_ops, host);
> > +#endif
>
> Isn't it a bit weird to have this in the middle of this function ?
> Should you instead declare a stub pci_host_alloc_intx_irqd() function
> in the header file if CONFIG_IRQ_DOMAIN is not enabled ?
>
> I.e in pci.h:
>
> #ifdef CONFIG_IRQ_DOMAIN
> struct irq_domain *pci_host_alloc_intx_irqd(struct device *dev,
> void *host, bool general_xlate,
> const struct irq_domain_ops *intx_domain_ops,
> struct device_node *local_intc);
> #else
> static inline struct irq_domain *pci_host_alloc_intx_irqd(struct device *dev,
> void *host, bool general_xlate, const struct irq_domain_ops *intx_domain_ops,
> struct device_node *local_intc)
> {
> return PTR_ERR(-EINVAL);
> }
> #endif
>
> or something like that.
Yes, he should.
> Finally a purely subjective and personal opinion: I'm not a big fan of
> this boolean that tells whether the ->xlate hook should be populated or
> not. I'm not sure if it makes sense for this function to create the
> irqdomain_ops altogether, perhaps it should be mandatory for the
> irq_domain_ops to be provided by the caller. The problem with the
> boolean general_xlate is that it is an endless story of additional
> booleans to tweak more stuff in the irq_domain_ops structure. But of
> course that's just a personal view, and my view doesn't really count
> here :-)
Your view does count here and I 100% agree with you. I do not like the
->xlate hack (that is just there to make things work on systems with
broken DTS files and bindings for legacy IRQ mappings) and this patch
would just institutionalize it at PCI API level. So, if we *do* want to
consolidate code, the domain ops should be passed in, as you mentioned.
Thanks,
Lorenzo
next prev parent reply other threads:[~2018-07-19 12:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-14 1:33 [PATCH v4 0/10] Add new helper to allocate IRQ domain for host drivers Shawn Lin
2018-06-14 1:34 ` [PATCH v4 01/10] PCI: Add pci_host_alloc_intx_irqd() for allocating IRQ domain Shawn Lin
2018-06-14 7:09 ` Thomas Petazzoni
2018-07-19 11:37 ` Lorenzo Pieralisi [this message]
2018-06-14 1:34 ` [PATCH v4 02/10] PCI: dra7xx: Use pci_host_alloc_intx_irqd() helper to simplify the code Shawn Lin
2018-06-14 1:34 ` [PATCH v4 03/10] PCI: keystone-dw: Use pci_host_alloc_intx_irqd() helper to get irq domain for INTx Shawn Lin
2018-06-14 1:35 ` [PATCH v4 04/10] PCI: aardvark: " Shawn Lin
2018-06-14 1:35 ` [PATCH v4 05/10] PCI: faraday: " Shawn Lin
2018-06-14 1:35 ` [PATCH v4 06/10] PCI: altera: " Shawn Lin
2018-06-14 10:51 ` Ley Foon Tan
2018-06-14 1:36 ` [PATCH v4 07/10] PCI: mediatek: " Shawn Lin
2018-06-14 1:36 ` [PATCH v4 08/10] PCI: xilinx-nwl: " Shawn Lin
2018-06-14 1:36 ` [PATCH v4 09/10] PCI: xilinx: " Shawn Lin
2018-06-14 1:36 ` [PATCH v4 10/10] PCI: rockchip: " Shawn Lin
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=20180719113714.GC9213@e107981-ln.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=shawn.lin@rock-chips.com \
--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