mbox series

[GIT,PULL] firmware: arm_scmi: Updates for v5.17

Message ID 20211222141342.56395-1-sudeep.holla@arm.com (mailing list archive)
State Accepted
Commit deccdc186789acda88077a2b0ed0da85708df45e
Headers show
Series [GIT,PULL] firmware: arm_scmi: Updates for v5.17 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.17

Message

Sudeep Holla Dec. 22, 2021, 2:13 p.m. UTC
Hi ARM SoC Team,

Please pull !

Regards,
Sudeep

-->8

The following changes since commit 026d9835b62bba34b7e657a0bfb76717822f9319:

  firmware: arm_scmi: Fix type error assignment in voltage protocol (2021-11-17 11:24:50 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.17

for you to fetch changes up to 94d0cd1da14af0042c8ee7c2cf401dfc321c575c:

  firmware: arm_scmi: Add new parameter to mark_txdone (2021-12-21 10:59:38 +0000)

----------------------------------------------------------------
Arm SCMI firmware interface updates for v5.17

Couple of main additions:
- Support for OPTEE based SCMI transport to enable using SCMI service
  provided by OPTEE on some platforms
- Support for atomic SCMI transports which enables few SCMI transactions
  to be completed in atomic context. This involves other refactoring work
  associated with it. It also marks SMC and OPTEE as atomic transport as
  the commands are completed once the return

Other changes involves some trace and log enhancements and a miscellaneous
bug fix.

----------------------------------------------------------------
Cristian Marussi (15):
      firmware: arm_scmi: Review some virtio log messages
      firmware: arm_scmi: Make virtio Version_1 compliance optional
      firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer
      firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms
      firmware: arm_scmi: Refactor message response path
      include: trace: Add new scmi_xfer_response_wait event
      firmware: arm_scmi: Use new trace event scmi_xfer_response_wait
      firmware: arm_scmi: Add configurable polling mode for transports
      firmware: arm_scmi: Make smc transport use common completions
      firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag
      firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret
      firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret
      firmware: arm_scmi: Add support for atomic transports
      firmware: arm_scmi: Add atomic mode support to smc transport
      firmware: arm_scmi: Add new parameter to mark_txdone

Etienne Carriere (2):
      dt-bindings: arm: Add OP-TEE transport for SCMI
      firmware: arm_scmi: Add optee transport

Sudeep Holla (1):
      firmware: arm_scmi: optee: Drop the support for the OPTEE shared dynamic buffer

Wei Yongjun (1):
      firmware: arm_scmi: optee: Fix missing mutex_init()

 .../devicetree/bindings/firmware/arm,scmi.yaml     |  65 +++
 drivers/firmware/arm_scmi/Kconfig                  |  41 ++
 drivers/firmware/arm_scmi/Makefile                 |   1 +
 drivers/firmware/arm_scmi/common.h                 |  26 +-
 drivers/firmware/arm_scmi/driver.c                 | 207 ++++++--
 drivers/firmware/arm_scmi/mailbox.c                |   3 +-
 drivers/firmware/arm_scmi/optee.c                  | 567 +++++++++++++++++++++
 drivers/firmware/arm_scmi/smc.c                    |  98 +++-
 drivers/firmware/arm_scmi/virtio.c                 |  22 +-
 include/linux/scmi_protocol.h                      |   8 +
 include/trace/events/scmi.h                        |  28 +
 11 files changed, 986 insertions(+), 80 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/optee.c

Comments

Sudeep Holla Jan. 7, 2022, 11:37 a.m. UTC | #1
Hi again,

On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>

I am aware I sent this pull request just around the same time Arnd finalised
the initial set. I have seen emails suggesting that Olof might be planning
to merge additional PR, so it would be great if this gets included in
that cut. All the changes are in -next since 21st December, so there should
be no surprises.

Thanks again and sorry for nagging.

--
Regards,
Sudeep
Olof Johansson Jan. 8, 2022, 8:24 p.m. UTC | #2
On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote:
> 
> Hi again,
> 
> On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote:
> > Hi ARM SoC Team,
> >
> > Please pull !
> >
> 
> I am aware I sent this pull request just around the same time Arnd finalised
> the initial set. I have seen emails suggesting that Olof might be planning
> to merge additional PR, so it would be great if this gets included in
> that cut. All the changes are in -next since 21st December, so there should
> be no surprises.
> 
> Thanks again and sorry for nagging.

Yeah, no worries -- I'd been letting pull requests sitting for a while over the
holidays. I've merged this into our late branch now.


Thanks,

-Olof
patchwork-bot+linux-soc@kernel.org Jan. 8, 2022, 10 p.m. UTC | #3
Hello:

This pull request was applied to soc/soc.git (for-next)
by Olof Johansson <olof@lixom.net>:

On Wed, 22 Dec 2021 14:13:42 +0000 you wrote:
> Hi ARM SoC Team,
> 
> Please pull !
> 
> Regards,
> Sudeep
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] firmware: arm_scmi: Updates for v5.17
    https://git.kernel.org/soc/soc/c/deccdc186789

You are awesome, thank you!
Arnd Bergmann Feb. 8, 2022, 10 a.m. UTC | #4
On Sat, Jan 8, 2022 at 9:24 PM Olof Johansson <olof@lixom.net> wrote:
> On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote:
> > On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote:
> > > Hi ARM SoC Team,
> > >
> > > Please pull !
> > >
> >
> > I am aware I sent this pull request just around the same time Arnd finalised
> > the initial set. I have seen emails suggesting that Olof might be planning
> > to merge additional PR, so it would be great if this gets included in
> > that cut. All the changes are in -next since 21st December, so there should
> > be no surprises.
> >
> > Thanks again and sorry for nagging.
>
> Yeah, no worries -- I'd been letting pull requests sitting for a while over the
> holidays. I've merged this into our late branch now.

Hi Sudeep,

I'm going through all the stuff that we ended up not getting into v5.17.
As you probably already know, this pull request was part of the arm/late
branch that missed out, sorry for the mistake on our end.

As the contents are still fine, I could offer to either merge the branch again
for v5.18, or I can drop it and wait for a new pull request from you, please
let me know your preference.

If any of the patches are bug fixes that you think should be in v5.17,
it would be good to have a separate pull request or patch email for the
5.17 fixes branch.

       Arnd
Sudeep Holla Feb. 8, 2022, 10:33 a.m. UTC | #5
On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote:
> On Sat, Jan 8, 2022 at 9:24 PM Olof Johansson <olof@lixom.net> wrote:
> > On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote:
> > > On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote:
> > > > Hi ARM SoC Team,
> > > >
> > > > Please pull !
> > > >
> > >
> > > I am aware I sent this pull request just around the same time Arnd finalised
> > > the initial set. I have seen emails suggesting that Olof might be planning
> > > to merge additional PR, so it would be great if this gets included in
> > > that cut. All the changes are in -next since 21st December, so there should
> > > be no surprises.
> > >
> > > Thanks again and sorry for nagging.
> >
> > Yeah, no worries -- I'd been letting pull requests sitting for a while over the
> > holidays. I've merged this into our late branch now.
> 
> Hi Sudeep,
> 
> I'm going through all the stuff that we ended up not getting into v5.17.
> As you probably already know, this pull request was part of the arm/late
> branch that missed out, sorry for the mistake on our end.
>

No worries, it was indeed a late PR.

> As the contents are still fine, I could offer to either merge the branch again
> for v5.18, or I can drop it and wait for a new pull request from you, please
> let me know your preference.
>

Is it OK if I merge this tag with v5.17-rc1 as base and load it with any
new v5.18 material on the top ? I just want to avoid rebasing as the same time
some of the new material depend on these changes. Let me know if that
is fine. I am open to any other suggestions too.

> If any of the patches are bug fixes that you think should be in v5.17,
> it would be good to have a separate pull request or patch email for the
> 5.17 fixes branch.
>

Sure, I will check again, but AFAIK there were no fixes for existing bugs.
Arnd Bergmann Feb. 8, 2022, 11:14 a.m. UTC | #6
On Tue, Feb 8, 2022 at 11:33 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote:
> > As the contents are still fine, I could offer to either merge the branch again
> > for v5.18, or I can drop it and wait for a new pull request from you, please
> > let me know your preference.
> >
>
> Is it OK if I merge this tag with v5.17-rc1 as base and load it with any
> new v5.18 material on the top ? I just want to avoid rebasing as the same time
> some of the new material depend on these changes. Let me know if that
> is fine. I am open to any other suggestions too.

Yes, I think that is ok, as long as you start a branch from v5.17-rc1 and merge
the old contents into the new branch, rather than back-merging the -rc1 tag
into your existing branch. This way, the git history still makes sense
across the
merges.

       Arnd
Sudeep Holla Feb. 8, 2022, 11:34 a.m. UTC | #7
On Tue, Feb 08, 2022 at 12:14:25PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 8, 2022 at 11:33 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote:
> > > As the contents are still fine, I could offer to either merge the branch again
> > > for v5.18, or I can drop it and wait for a new pull request from you, please
> > > let me know your preference.
> > >
> >
> > Is it OK if I merge this tag with v5.17-rc1 as base and load it with any
> > new v5.18 material on the top ? I just want to avoid rebasing as the same time
> > some of the new material depend on these changes. Let me know if that
> > is fine. I am open to any other suggestions too.
> 
> Yes, I think that is ok, as long as you start a branch from v5.17-rc1 and merge
> the old contents into the new branch, rather than back-merging the -rc1 tag
> into your existing branch. This way, the git history still makes sense
> across the merges.

Thanks for confirming my understanding.