From: Sudeep Holla <sudeep.holla@arm.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Olivier Deprez <Olivier.Deprez@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marc Bonnici <Marc.Bonnici@arm.com>,
Coboy Chen <coboy.chen@mediatek.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface
Date: Thu, 5 Oct 2023 09:49:46 +0100 [thread overview]
Message-ID: <20231005084946.vn4mbizdisaw4q5d@bogus> (raw)
In-Reply-To: <CAHUa44GWA_WQSgOgtQKgawc11vpaD5B4q5rNq8fxnEFJk_NzmA@mail.gmail.com>
On Thu, Oct 05, 2023 at 08:57:26AM +0200, Jens Wiklander wrote:
> Hi Sudeep,
>
> On Wed, Oct 4, 2023 at 5:32 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Oct 04, 2023 at 10:50:26AM +0100, Olivier Deprez wrote:
> > > Hi Jens,
> > >
> > > > dst_id and drv_info->vm_id should be swapped.
> > >
> > > I'm curious about this because swapping like this actually makes hafnium
> > > fail. Need to check from the spec.
> >
> > I did check after I had swapped this in v2(because I was convinced Jens) was
> > correct and you reported the failure. Reading the spec again the other day,
> > I got corrected myself and agreed with Olivier and my original
> > implementation(v1) which matches this patch(v3).
Well, I am not exactly sure what is the root cause for the confusion here:
My poor choice of variable names and their usage with this macro, or the
macro definition itself(I am not sure)
OR
The wordings in the specification
>
> I don't get it. The spec says for FFA_NOTIFICATION_BIND:
> Sender and Receiver endpoint IDs.
> – Bit[31:16]: Sender endpoint ID.
> – Bit[15:0]: Receiver endpoint ID.
> This is exactly the same as for instance FFA_MSG_SEND_DIRECT_REQ.
>
Not really as per my understanding of the specification.
> In ffa_msg_send_direct_req() you assign
> src_dst_ids = PACK_TARGET_INFO(src_id, dst_id);
>
Correct and if you look at the callsite, it is
ffa_msg_send_direct_req(drv_info->vm_id, dev->vm_id,...)
So the driver is the sender and the partition is the receiver. Probably
this is simpler.
> but here in ffa_notification_bind_common() you assign
> src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);
>
A receiver(FF-A driver) must bind a non-framework notification to a
sender(SP) before the latter can signal the notification to the former.
Only the sender can ring these doorbells. A receiver uses the
FFA_NOTIFICATION_BIND interface to bind one or more notifications to the
sender.
So, based on this text(modified to refer sender and receiver in the driver
context) from the spec, my understanding is the driver is the receiver
and the SP is the sender of the notification.
Do you think I am missing someting here ? Sorry for agreeing with you
in v2 and silently changing it back without this actual discussion.
Olivier raised the issue and then when I went back and looked at the
spec, I realised why I had it this way from the beginning.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-05 8:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 15:02 [PATCH v3 00/17] firmware: arm_ffa: Add FF-A v1.1 support(notification + new memory descriptor format) Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 01/17] firmware: arm_ffa: Update the FF-A command list with v1.1 additions Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 02/17] firmware: arm_ffa: Implement notification bitmap create and destroy interfaces Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface Sudeep Holla
2023-10-04 9:11 ` Jens Wiklander
2023-10-04 9:50 ` Olivier Deprez
2023-10-04 15:32 ` Sudeep Holla
2023-10-05 6:57 ` Jens Wiklander
2023-10-05 8:49 ` Sudeep Holla [this message]
2023-10-05 9:56 ` Jens Wiklander
2023-09-29 15:02 ` [PATCH v3 04/17] firmware: arm_ffa: Implement the FFA_RUN interface Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 05/17] firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interface Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 06/17] firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interface Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 07/17] firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface Sudeep Holla
2023-10-04 9:10 ` Jens Wiklander
2023-10-04 15:11 ` Sudeep Holla
2023-10-05 6:30 ` Jens Wiklander
2023-09-29 15:02 ` [PATCH v3 08/17] firmware: arm_ffa: Initial support for scheduler receiver interrupt Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 09/17] firmware: arm_ffa: Add schedule receiver callback mechanism Sudeep Holla
2023-09-29 15:02 ` [PATCH v3 10/17] firmware: arm_ffa: Add interfaces to request notification callbacks Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 11/17] firmware: arm_ffa: Add interface to send a notification to a given partition Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 12/17] firmware: arm_ffa: Add notification handling mechanism Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 13/17] firmware: arm_ffa: Simplify the computation of transmit and fragment length Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 14/17] KVM: arm64: FFA: Remove access of endpoint memory access descriptor array Sudeep Holla
2023-10-02 16:20 ` Sudeep Holla
2023-10-04 10:08 ` Marc Zyngier
2023-10-04 13:22 ` Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 15/17] firmware: arm_ffa: Switch to using ffa_mem_desc_offset() accessor Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 16/17] firmware: arm_ffa: Update memory descriptor to support v1.1 format Sudeep Holla
2023-09-29 15:03 ` [PATCH v3 17/17] firmware: arm_ffa: Upgrade the driver version to v1.1 Sudeep Holla
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=20231005084946.vn4mbizdisaw4q5d@bogus \
--to=sudeep.holla@arm.com \
--cc=Marc.Bonnici@arm.com \
--cc=Olivier.Deprez@arm.com \
--cc=coboy.chen@mediatek.com \
--cc=jens.wiklander@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
/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