linux-kernel - Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20231005133024.kdxfajmruedli4ne@bogus>
Date:   Thu, 5 Oct 2023 14:30:24 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jens Wiklander <jens.wiklander@...aro.org>
Cc:     Olivier Deprez <Olivier.Deprez@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marc Bonnici <Marc.Bonnici@....com>,
        Coboy Chen <coboy.chen@...iatek.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification
 bind and unbind interface

On Thu, Oct 05, 2023 at 11:56:22AM +0200, Jens Wiklander wrote:
> On Thu, Oct 5, 2023 at 10:51 AM Sudeep Holla <sudeep.holla@....com> wrote:

[...]

> > 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.
> 
> Thanks for the explanation, now I get it. My mistake was that I
> thought that sender and receiver meant the sender and receiver of the
> actual message being sent like with a direct request, it is using the
> same register and the same wording after all. Instead, it means the
> sender and receiver of an eventual notification, which of course is
> the exact opposite.
> 

Thanks for the response. Glad we are on same page now with respect to this.

-- 
Regards,
Sudeep