[PATCH v3 1/3] drivers: mailbox: zynqmp: handle multiple child nodes

Michal Simek michal.simek at amd.com
Thu Feb 23 01:40:18 PST 2023



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 at amd.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




More information about the linux-arm-kernel mailing list