[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b11cd9f2-3759-1df2-ea00-50c574668c28@amd.com>
Date: Thu, 23 Feb 2023 10:40:18 +0100
From: Michal Simek <michal.simek@....com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>,
Tanmay Shah <tanmay.shah@....com>
CC: <andersson@...nel.org>, <jaswinder.singh@...aro.org>,
<ben.levinsky@....com>, <shubhrajyoti.datta@....com>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-remoteproc@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] drivers: mailbox: zynqmp: handle multiple child
nodes
On 2/22/23 18:34, Mathieu Poirier wrote:
> On Mon, Feb 13, 2023 at 01:18:24PM -0800, Tanmay Shah wrote:
>> As of now only one child node is handled by zynqmp-ipi
>> mailbox driver. Upon introducing remoteproc r5 core mailbox
>> nodes, found few enhancements in Xilinx zynqmp mailbox driver
>> as following:
>>
>> - fix mailbox child node counts
>> If child mailbox node status is disabled it causes
>> crash in interrupt handler. Fix this by assigning
>> only available child node during driver probe.
>>
>> - fix typo in IPI documentation %s/12/32/
>> Xilinx IPI message buffers allows 32-byte data transfer.
>> Fix documentation that says 12 bytes
>>
>> - fix bug in zynqmp-ipi isr handling
>> Multiple IPI channels are mapped to same interrupt handler.
>> Current isr implementation handles only one channel per isr.
>> Fix this behavior by checking isr status bit of all child
>> mailbox nodes.
>>
>> Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
>> Signed-off-by: Tanmay Shah <tanmay.shah@....com>
>> ---
>>
>> Changelog:
>> - This is first version of this change, however posting as part of the series
>> that has version v3.
>>
>> v2: https://lore.kernel.org/all/20230126213154.1707300-1-tanmay.shah@amd.com/
>>
>> drivers/mailbox/zynqmp-ipi-mailbox.c | 8 ++++----
>> include/linux/mailbox/zynqmp-ipi-message.h | 2 +-
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> index 12e004ff1a14..b1498f6f06e1 100644
>> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
>> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> @@ -152,7 +152,7 @@ static irqreturn_t zynqmp_ipi_interrupt(int irq, void *data)
>> struct zynqmp_ipi_message *msg;
>> u64 arg0, arg3;
>> struct arm_smccc_res res;
>> - int ret, i;
>> + int ret, i, status = IRQ_NONE;
>>
>> (void)irq;
>> arg0 = SMC_IPI_MAILBOX_STATUS_ENQUIRY;
>> @@ -170,11 +170,11 @@ static irqreturn_t zynqmp_ipi_interrupt(int irq, void *data)
>> memcpy_fromio(msg->data, mchan->req_buf,
>> msg->len);
>> mbox_chan_received_data(chan, (void *)msg);
>> - return IRQ_HANDLED;
>> + status = IRQ_HANDLED;
>> }
>> }
>> }
>> - return IRQ_NONE;
>> + return status;
>> }
>>
>> /**
>> @@ -634,7 +634,7 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
>> struct zynqmp_ipi_mbox *mbox;
>> int num_mboxes, ret = -EINVAL;
>>
>> - num_mboxes = of_get_child_count(np);
>> + num_mboxes = of_get_available_child_count(np);
>> pdata = devm_kzalloc(dev, sizeof(*pdata) + (num_mboxes * sizeof(*mbox)),
>> GFP_KERNEL);
>> if (!pdata)
>> diff --git a/include/linux/mailbox/zynqmp-ipi-message.h b/include/linux/mailbox/zynqmp-ipi-message.h
>> index 35ce84c8ca02..31d8046d945e 100644
>> --- a/include/linux/mailbox/zynqmp-ipi-message.h
>> +++ b/include/linux/mailbox/zynqmp-ipi-message.h
>> @@ -9,7 +9,7 @@
>> * @data: message payload
>> *
>> * This is the structure for data used in mbox_send_message
>> - * the maximum length of data buffer is fixed to 12 bytes.
>> + * the maximum length of data buffer is fixed to 32 bytes.
>> * Client is supposed to be aware of this.
>
> I agree that this should be split in 3 patches but the fixes are so small that
> it is hardly required. I'll leave it up to Michal to decide.
Generic guidance is saying that you should split that patches. I personally
prefer to have one patch per change. It is useful for bisecting and faster for
reviewing.
I would expect that this patch should go via mailbox tree and the rest via
remoteproc tree. That's why maintainer should say what it is preferred way.
In connection mailbox. I recently had some time to look at this driver and I
didn't really get why there are registers listed. Because all that addresses can
be calculated based on soc compatible string and by xlnx,ipi-id for both sides.
Thanks,
Michal
Powered by blists - more mailing lists