All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, Ludvig.Parsson@axis.com,
	cristian.marussi@arm.com
Subject: [PATCH 0/9] Rework SCMI initialization and probing sequence
Date: Thu, 22 Dec 2022 18:50:40 +0000	[thread overview]
Message-ID: <20221222185049.737625-1-cristian.marussi@arm.com> (raw)

Hi,

under some configurations the SCMI core stack, which is now initialized
as a whole at the subsys_initcall level, can be dependent on some other
Kernel subsystems (like TEE) when some SCMI transport backend like optee
is used.

This has been reported to lead to some awkward probe loop which, even
though successful at the end, leaves a track of errors in the logs coming
directly from the core Linux driver model facilities.

In order to solve this issue and cleaning up a bit the SCMI stack startup
sequence, this small series reviews and reworks the SCMI core stack
initialization and probe logic.

Basically the SCMI Bus is split into its own module (scmi-core.ko) which is
initialized at subsys_initcall, while the SCMI core stack, including its
various transport backends (like optee, mailbox, virtio, smc), is kept into
a distinct module (scmi-module.ko) which get initialized at module_init.

The SCMI driver users initlevel, instead, remains unchanged at module_init.

No change is made to the Kconfig: the main ARM_SCMI_PROTOCOL option will
now cause both modules to be built.

This allows the other possibly needed subsystems to be up and running
well before the core SCMI stack and its dependent transport backends, so
solving the reported issue.

Tested with SCMI transports mailbox/virtio and, in a previous draft, optee,
in a number of different load/unload/bind/unbind combinations both as
builtin and as LKMs.

Applies on v6.1.

Any feedback, testing welcome.

Thanks,
Cristian

Cristian Marussi (9):
  firmware: arm_scmi: Simplify chan_available transport operation
  firmware: arm_scmi: Use dedicated devices to initialize channels
  firmware: arm_scmi: Move protocol registration helpers
  firmware: arm_scmi: Add common notifier helpers
  firmware: arm_scmi: Refactor protocol device creation
  firmware: arm_scmi: Move handle get/set helpers
  firmware: arm_scmi: Refactor device create/destroy helpers
  firmware: arm_scmi: Introduce a new lifecycle for protocol devices
  firmware: arm_scmi: Split bus and driver into distinct modules

 drivers/firmware/arm_scmi/Makefile  |   8 +-
 drivers/firmware/arm_scmi/bus.c     | 388 ++++++++++++-----
 drivers/firmware/arm_scmi/common.h  |  25 +-
 drivers/firmware/arm_scmi/driver.c  | 623 ++++++++++++++--------------
 drivers/firmware/arm_scmi/mailbox.c |   6 +-
 drivers/firmware/arm_scmi/optee.c   |   6 +-
 drivers/firmware/arm_scmi/smc.c     |   6 +-
 drivers/firmware/arm_scmi/virtio.c  |   4 +-
 include/linux/scmi_protocol.h       |   5 -
 9 files changed, 622 insertions(+), 449 deletions(-)

-- 
2.34.1


WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, Ludvig.Parsson@axis.com,
	cristian.marussi@arm.com
Subject: [PATCH 0/9] Rework SCMI initialization and probing sequence
Date: Thu, 22 Dec 2022 18:50:40 +0000	[thread overview]
Message-ID: <20221222185049.737625-1-cristian.marussi@arm.com> (raw)

Hi,

under some configurations the SCMI core stack, which is now initialized
as a whole at the subsys_initcall level, can be dependent on some other
Kernel subsystems (like TEE) when some SCMI transport backend like optee
is used.

This has been reported to lead to some awkward probe loop which, even
though successful at the end, leaves a track of errors in the logs coming
directly from the core Linux driver model facilities.

In order to solve this issue and cleaning up a bit the SCMI stack startup
sequence, this small series reviews and reworks the SCMI core stack
initialization and probe logic.

Basically the SCMI Bus is split into its own module (scmi-core.ko) which is
initialized at subsys_initcall, while the SCMI core stack, including its
various transport backends (like optee, mailbox, virtio, smc), is kept into
a distinct module (scmi-module.ko) which get initialized at module_init.

The SCMI driver users initlevel, instead, remains unchanged at module_init.

No change is made to the Kconfig: the main ARM_SCMI_PROTOCOL option will
now cause both modules to be built.

This allows the other possibly needed subsystems to be up and running
well before the core SCMI stack and its dependent transport backends, so
solving the reported issue.

Tested with SCMI transports mailbox/virtio and, in a previous draft, optee,
in a number of different load/unload/bind/unbind combinations both as
builtin and as LKMs.

Applies on v6.1.

Any feedback, testing welcome.

Thanks,
Cristian

Cristian Marussi (9):
  firmware: arm_scmi: Simplify chan_available transport operation
  firmware: arm_scmi: Use dedicated devices to initialize channels
  firmware: arm_scmi: Move protocol registration helpers
  firmware: arm_scmi: Add common notifier helpers
  firmware: arm_scmi: Refactor protocol device creation
  firmware: arm_scmi: Move handle get/set helpers
  firmware: arm_scmi: Refactor device create/destroy helpers
  firmware: arm_scmi: Introduce a new lifecycle for protocol devices
  firmware: arm_scmi: Split bus and driver into distinct modules

 drivers/firmware/arm_scmi/Makefile  |   8 +-
 drivers/firmware/arm_scmi/bus.c     | 388 ++++++++++++-----
 drivers/firmware/arm_scmi/common.h  |  25 +-
 drivers/firmware/arm_scmi/driver.c  | 623 ++++++++++++++--------------
 drivers/firmware/arm_scmi/mailbox.c |   6 +-
 drivers/firmware/arm_scmi/optee.c   |   6 +-
 drivers/firmware/arm_scmi/smc.c     |   6 +-
 drivers/firmware/arm_scmi/virtio.c  |   4 +-
 include/linux/scmi_protocol.h       |   5 -
 9 files changed, 622 insertions(+), 449 deletions(-)

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-12-22 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 18:50 Cristian Marussi [this message]
2022-12-22 18:50 ` [PATCH 0/9] Rework SCMI initialization and probing sequence Cristian Marussi
2022-12-22 18:50 ` [PATCH 1/9] firmware: arm_scmi: Simplify chan_available transport operation Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 2/9] firmware: arm_scmi: Use dedicated devices to initialize channels Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 3/9] firmware: arm_scmi: Move protocol registration helpers Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 4/9] firmware: arm_scmi: Add common notifier helpers Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 5/9] firmware: arm_scmi: Refactor protocol device creation Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 6/9] firmware: arm_scmi: Move handle get/set helpers Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 7/9] firmware: arm_scmi: Refactor device create/destroy helpers Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 8/9] firmware: arm_scmi: Introduce a new lifecycle for protocol devices Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-22 18:50 ` [PATCH 9/9] firmware: arm_scmi: Split bus and driver into distinct modules Cristian Marussi
2022-12-22 18:50   ` Cristian Marussi
2022-12-23  5:36 ` [PATCH 0/9] Rework SCMI initialization and probing sequence Sumit Garg
2022-12-23  5:36   ` Sumit Garg
2022-12-23 11:37   ` Cristian Marussi
2022-12-23 11:37     ` Cristian Marussi
2022-12-26 13:54     ` Sumit Garg
2022-12-26 13:54       ` Sumit Garg
2023-01-19 19:31 ` Sudeep Holla
2023-01-19 19:31   ` 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=20221222185049.737625-1-cristian.marussi@arm.com \
    --to=cristian.marussi@arm.com \
    --cc=Ludvig.Parsson@axis.com \
    --cc=etienne.carriere@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.