From: Peter Hilber <peter.hilber@opensynergy.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: peng.fan@nxp.com, arnd@arndb.de, jassisinghbrar@gmail.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, cristian.marussi@arm.com
Subject: Re: [PATCH V5] firmware: arm_scmi: Make scmi core independent of the transport type
Date: Thu, 30 Jan 2020 12:58:08 +0100 [thread overview]
Message-ID: <b970542b-0c05-5401-46be-5f585bdafb09@opensynergy.com> (raw)
In-Reply-To: <20200128173524.GB36496@bogus>
On 28.01.20 18:35, Sudeep Holla wrote:
> Otherwise looks good. Since we are not adding module support, I am fine
> even if we have to make changes to transport ops bit later if required
> and realised when adding new transport. Let us see if Peter has any major
> objections.
I have no objections. Looks good. One remark:
> +struct scmi_transport_ops {
> + bool (*chan_available)(struct device *dev, int idx);
> + int (*chan_setup)(struct scmi_chan_info *cinfo, struct device *dev, bool tx);
> + int (*chan_free)(int id, void *p, void *data);
> + int (*send_message)(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer);
> + void (*mark_txdone)(struct scmi_chan_info *cinfo, int ret);
> + void (*fetch_response)(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer);
> + bool (*poll_done)(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer);
> +};
Maybe the mark_txdone, fetch_response, and poll_done ops should also get
a `u32 msg_hdr' parameter? I thought it could be required in case of
concurrent xfers, or maybe I don't understand the imposed concurrency
limitations properly.
Best regards,
Peter
Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
[tech_days_munchen]
OpenSynergy TechDay München
am 11. Februar 2020, ab 12:00Uhr, im Studio Balan, Moosacherstr. 86.
Anmeldung bitte hier<mailto:sabine.mutumba@opensynergy.com>
_______________________________________________
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:[~2020-01-30 11:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 10:54 [PATCH V5] firmware: arm_scmi: Make scmi core independent of the transport type Viresh Kumar
2020-01-28 17:35 ` Sudeep Holla
2020-01-30 11:58 ` Peter Hilber [this message]
2020-01-31 4:33 ` Viresh Kumar
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=b970542b-0c05-5401-46be-5f585bdafb09@opensynergy.com \
--to=peter.hilber@opensynergy.com \
--cc=arnd@arndb.de \
--cc=cristian.marussi@arm.com \
--cc=jassisinghbrar@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.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