From: Florian Fainelli <firstname.lastname@example.org> To: Cristian Marussi <email@example.com>, firstname.lastname@example.org, email@example.com Cc: firstname.lastname@example.org, email@example.com, Jonathan.Cameron@Huawei.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support Date: Mon, 24 May 2021 19:20:45 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 5/24/2021 4:15 PM, Cristian Marussi wrote: > Introduce optional support for delegated xfers allocation. > > An SCMI transport can optionally declare to support delegated xfers and > then use a few helper functions exposed by the core SCMI transport layer to > query the core for existing in-flight transfers matching a provided message > header or alternatively and transparently obtain a brand new xfer to handle > a freshly received notification message. > In both cases the obtained xfer is uniquely mapped into a specific xfer > through the means of the message header acting as key. > > In this way such a transport can properly store its own transport specific > payload into the xfer uniquely associated to the message header before > even calling into the core scmi_rx_callback() in the usual way, so that > the transport specific message envelope structures can be freed early > and there is no more need to keep track of their status till the core > fully processes the xfer to completion or times out. > > The scmi_rx_callbak() does not need to be modified to carry additional > transport-specific ancillary data related to such message envelopes since > an unique natural association is established between the xfer and the > related message header. > > Existing transports that do not need anything of the above will continue > to work as before without any change. > > Signed-off-by: Cristian Marussi <email@example.com> It would be better to see this in the context of its planned user, but that looked reasonable enough. -- Florian _______________________________________________ linux-arm-kernel mailing list firstname.lastname@example.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-25 3:47 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-24 23:14 [PATCH 0/4] Review/Extend SCMI Transport Core layer Cristian Marussi 2021-05-24 23:15 ` [PATCH 1/4] firmware: arm_scmi: reset_rx_to_maxsz during async commands Cristian Marussi 2021-05-24 23:15 ` [PATCH 2/4] firmware: arm_scmi: Add support for type handling in common functions Cristian Marussi 2021-05-25 1:53 ` Florian Fainelli 2021-05-24 23:15 ` [PATCH 3/4] firmware: arm_scmi: Introduce monotonically increasing tokens Cristian Marussi 2021-05-25 2:13 ` Florian Fainelli 2021-05-26 14:44 ` Cristian Marussi [not found] ` <CA+-6iNx-EoMUhOncrgYTxh52mW_7yjjBbfHK8mVyEY0Uw4piwg@mail.gmail.com> 2021-05-26 14:45 ` Cristian Marussi 2021-05-24 23:15 ` [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support Cristian Marussi 2021-05-25 2:20 ` Florian Fainelli [this message] 2021-05-26 14:53 ` Cristian Marussi
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Jonathan.Cameron@Huawei.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).