From: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
To: Marc Zyngier <marc.zyngier@arm.com>, <monstr@monstr.eu>,
<ralf@linux-mips.org>, <tglx@linutronix.de>,
<jason@lakedaemon.net>
Cc: <soren.brinkmann@xilinx.com>, <linux-kernel@vger.kernel.org>,
<linux-mips@linux-mips.org>, <michal.simek@xilinx.com>,
<netdev@vger.kernel.org>
Subject: Re: [Patch v4 02/12] irqchip: axi-intc: Clean up irqdomain argument and read/write
Date: Fri, 2 Sep 2016 11:47:19 +0100 [thread overview]
Message-ID: <3e4cf28a-2efd-84ab-9f78-6755dec9fb94@imgtec.com> (raw)
In-Reply-To: <57C86241.8000806@arm.com>
Hi,
Thanks for the review.
Comments inline.
On 09/01/2016 06:15 PM, Marc Zyngier wrote:
> On 01/09/16 17:50, Zubair Lutfullah Kakakhel wrote:
>> The drivers read/write function handling is a bit quirky.
>> And the irqmask is passed directly to the handler.
>>
>> Add a new irqchip struct to pass to the handler and
>> cleanup read/write handling.
>>
>> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
>>
>> ---
>> V3 -> V4
>> Better error handling for kzalloc
>> Erroring out if the axi intc is probed twice as that isn't
>> supported
>>
...
>> static int __init xilinx_intc_of_init(struct device_node *intc,
>> struct device_node *parent)
>> {
>> - u32 nr_irq, intr_mask;
>> + u32 nr_irq;
>> int ret;
>> + struct xintc_irq_chip *irqc;
>> +
>> + irqc = kzalloc(sizeof(*irqc), GFP_KERNEL);
>> + if (!irqc)
>> + return -ENOMEM;
>>
>> - intc_baseaddr = of_iomap(intc, 0);
>> - BUG_ON(!intc_baseaddr);
>> + if (xintc_irqc) {
>> + pr_err("%s: Multiple instances of axi_intc aren't supported\n");
>> + ret = -EINVAL;
>> + goto err_alloc;
>
> How about testing the variable first and error-ing early, rather than
> performing the allocation and undoing it later?
>
Sure. Thanks
>> + } else {
>> + xintc_irqc = irqc;
>> + }
>> +
>> + irqc->base = of_iomap(intc, 0);
>> + BUG_ON(!irqc->base);
>>
>> ret = of_property_read_u32(intc, "xlnx,num-intr-inputs", &nr_irq);
>> if (ret < 0) {
>> pr_err("%s: unable to read xlnx,num-intr-inputs\n", __func__);
>> - return ret;
>> + goto err_alloc;
>> }
>>
>> - ret = of_property_read_u32(intc, "xlnx,kind-of-intr", &intr_mask);
>> + ret = of_property_read_u32(intc, "xlnx,kind-of-intr", &irqc->intr_mask);
>> if (ret < 0) {
>> pr_err("%s: unable to read xlnx,kind-of-intr\n", __func__);
>> - return ret;
>> + goto err_alloc;
>> }
>>
>> - if (intr_mask >> nr_irq)
>> + if (irqc->intr_mask >> nr_irq)
>> pr_warn("%s: mismatch in kind-of-intr param\n", __func__);
>>
>> pr_info("%s: num_irq=%d, edge=0x%x\n",
>> - intc->full_name, nr_irq, intr_mask);
>> + intc->full_name, nr_irq, irqc->intr_mask);
>>
>> - write_fn = intc_write32;
>> - read_fn = intc_read32;
>> + irqc->read = intc_read32;
>> + irqc->write = intc_write32;
>>
>> /*
>> * Disable all external interrupts until they are
>> * explicity requested.
>> */
>> - write_fn(0, intc_baseaddr + IER);
>> + xintc_write(irqc, IER, 0);
>>
>> /* Acknowledge any pending interrupts just in case. */
>> - write_fn(0xffffffff, intc_baseaddr + IAR);
>> + xintc_write(irqc, IAR, 0xffffffff);
>>
>> /* Turn on the Master Enable. */
>> - write_fn(MER_HIE | MER_ME, intc_baseaddr + MER);
>> - if (!(read_fn(intc_baseaddr + MER) & (MER_HIE | MER_ME))) {
>> - write_fn = intc_write32_be;
>> - read_fn = intc_read32_be;
>> - write_fn(MER_HIE | MER_ME, intc_baseaddr + MER);
>> + xintc_write(irqc, MER, MER_HIE | MER_ME);
>> + if (!(xintc_read(irqc, MER) & (MER_HIE | MER_ME))) {
>> + irqc->read = intc_read32_be;
>> + irqc->write = intc_write32_be;
>> + xintc_write(irqc, MER, MER_HIE | MER_ME);
>> }
>>
>> - /* Yeah, okay, casting the intr_mask to a void* is butt-ugly, but I'm
>> - * lazy and Michal can clean it up to something nicer when he tests
>> - * and commits this patch. ~~gcl */
>> root_domain = irq_domain_add_linear(intc, nr_irq, &xintc_irq_domain_ops,
>> - (void *)intr_mask);
>> + irqc);
>
> What if the domain allocation fails? You've now configured the HW for
> something you can't use. What are the side effects? Hint: handle
> everything that can fail first, and only then poke the HW.
>
Thanks for pointing it out. I'll add an error check.
>>
>> irq_set_default_host(root_domain);
>>
>> return 0;
>> +
>> +err_alloc:
>> + xintc_irqc = NULL;
>> + kfree(irqc);
>> + return ret;
>> +
>> }
>>
>> IRQCHIP_DECLARE(xilinx_intc, "xlnx,xps-intc-1.00.a", xilinx_intc_of_init);
>>
>
> Instead of posting 3 versions in 3 days, please take the time to
> correctly address the comments, and review your own code before
> re-posting it. Rushing to get it merged for 4.9 is really not the best
> approach.
Apologies for the spam. Combination of some free time this week + window of opportunity.
To be fair, AFAIK, this driver has lived in arch/microblaze without receiving a full thorough
review by any irqchip maintainer.
Hence the various missing bits. e.g. the root_domain error check didn't exist before.
And I didn't see it.
Regards,
ZubairLK
>
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2016-09-02 11:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:50 [Patch v4 00/12] microblaze/MIPS: xilfpga: intc and peripheral Zubair Lutfullah Kakakhel
2016-09-01 16:50 ` [Patch v4 01/12] microblaze: irqchip: Move intc driver to irqchip Zubair Lutfullah Kakakhel
2016-09-02 5:56 ` Michal Simek
2016-09-02 9:55 ` Zubair Lutfullah Kakakhel
2016-09-02 6:25 ` Michal Simek
2016-09-02 10:06 ` Zubair Lutfullah Kakakhel
2016-09-02 10:27 ` Michal Simek
2016-09-02 11:46 ` Zubair Lutfullah Kakakhel
2016-09-02 12:06 ` Michal Simek
2016-09-02 12:48 ` Jason Cooper
2016-09-02 13:28 ` Jason Cooper
2016-09-02 13:31 ` Marc Zyngier
2016-09-01 16:50 ` [Patch v4 02/12] irqchip: axi-intc: Clean up irqdomain argument and read/write Zubair Lutfullah Kakakhel
2016-09-01 17:15 ` Marc Zyngier
2016-09-02 10:47 ` Zubair Lutfullah Kakakhel [this message]
2016-09-02 1:25 ` kbuild test robot
2016-09-01 16:50 ` [Patch v4 03/12] irqchip: axi-intc: Rename get_irq to xintc_get_irq Zubair Lutfullah Kakakhel
2016-09-02 5:58 ` Michal Simek
2016-09-01 16:50 ` [Patch v4 04/12] irqchip: axi-intc: Add support for parent intc Zubair Lutfullah Kakakhel
2016-09-01 17:17 ` Marc Zyngier
2016-09-01 16:50 ` [Patch v4 05/12] MIPS: xilfpga: Use irqchip_init instead of the legacy way Zubair Lutfullah Kakakhel
2016-09-01 16:50 ` [Patch v4 06/12] MIPS: xilfpga: Use Xilinx AXI Interrupt Controller Zubair Lutfullah Kakakhel
2016-09-02 7:05 ` Michal Simek
2016-09-02 7:06 ` Michal Simek
2016-09-01 16:51 ` [Patch v4 07/12] MIPS: xilfpga: Update DT node and specify uart irq Zubair Lutfullah Kakakhel
2016-09-01 16:51 ` [Patch v4 08/12] MIPS: Xilfpga: Add DT node for AXI I2C Zubair Lutfullah Kakakhel
2016-09-01 16:51 ` [Patch v4 09/12] net: ethernet: xilinx: Generate random mac if none found Zubair Lutfullah Kakakhel
2016-09-02 7:08 ` Michal Simek
2016-09-01 16:51 ` [Patch v4 10/12] net: ethernet: xilinx: Enable emaclite for MIPS Zubair Lutfullah Kakakhel
2016-09-01 16:51 ` [Patch v4 11/12] MIPS: xilfpga: Add DT node for AXI emaclite Zubair Lutfullah Kakakhel
2016-09-01 16:51 ` [Patch v4 12/12] MIPS: xilfpga: Update defconfig Zubair Lutfullah Kakakhel
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=3e4cf28a-2efd-84ab-9f78-6755dec9fb94@imgtec.com \
--to=zubair.kakakhel@imgtec.com \
--cc=jason@lakedaemon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=marc.zyngier@arm.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=netdev@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=soren.brinkmann@xilinx.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®