From: Cristian Marussi <cristian.marussi@arm.com> To: Etienne Carriere <etienne.carriere@linaro.org> Cc: linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Sudeep Holla <sudeep.holla@arm.com>, Vincent Guittot <vincent.guittot@linaro.org> Subject: Re: [PATCH v2 4/4] firmware: arm_scmi: add optee transport Date: Fri, 11 Jun 2021 18:30:19 +0100 [thread overview] Message-ID: <20210611173019.GB35183@e120937-lin> (raw) In-Reply-To: <CAN5uoS_0SMndmAvTwZnsCeQSUAfvBRz1diU_94CSYrsBxsZeew@mail.gmail.com> Hi Etienne, On Fri, May 28, 2021 at 11:43:24AM +0200, Etienne Carriere wrote: > Hello Christian, > > On Thu, 27 May 2021 at 17:11, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > > Hi Etienne, > > > > some remarks below. > > > > On Fri, May 21, 2021 at 03:40:54PM +0200, Etienne Carriere wrote: > > > Add a new transport channel to the SCMI firmware interface driver for > > > SCMI message exchange based on OP-TEE transport channel that leverage > > > OP-TEE secure threaded context for processing of SCMI messages. > > > > > > +static int __init optee_scmi_init(void) [snip] > > > +{ > > > + return driver_register(&optee_scmi_driver.driver); > > > +} > > > + > > > +static void __exit optee_scmi_exit(void) > > > +{ > > > + driver_unregister(&optee_scmi_driver.driver); > > > +} > > > + > > > +module_init(optee_scmi_init); > > > +module_exit(optee_scmi_exit); > > > + > > > > This cannot compile is the full SCMI statck ARM_SCMI_PROTOCOL is configured as =m > > > > /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > drivers/firmware/arm_scmi/optee_service.o: in function > > `optee_scmi_init': > > /home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/optee_service.c:515: > > multiple definition of `init_module'; > > drivers/firmware/arm_scmi/driver.o:/home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/driver.c:1593: > > first defined here > > /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > drivers/firmware/arm_scmi/optee_service.o: in function > > `optee_scmi_exit': > > /home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/optee_service.c:520: > > multiple definition of `cleanup_module'; > > drivers/firmware/arm_scmi/driver.o:/home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/driver.c:1611: > > first defined here > > /home/crimar01/ARM/dev/src/pdsw/linux/scripts/Makefile.build:449: recipe > > for target 'drivers/firmware/arm_scmi/scmi-module.o' failed > > make[4]: *** [drivers/firmware/arm_scmi/scmi-module.o] Error 1 > > > > > > Indeed it was the same issue we faced in the virtio-scmi series, and it > > derives from the fact that SCMI transports 'driver' are really NOT > > standalone drivers but only extension of the main SCMI module, so you > > cannot have them initialize their stuff using usual kernel module_ machinery. > > > > In order to address this, and avoid a hell of ifdeffery probably, > > in the context of virtio-scmi, I added a couple of transport's > > optionalily provided init/deinit functions so that a transport can provide > > some specific init code and be assured they are called at SCMI stack init, > > so definitely even before the SCMI stack is probed and the selected > > transport used. > > > > This is the patch from the virtio-scmi series: > > > > https://lore.kernel.org/linux-arm-kernel/20210511002040.802226-3-peter.hilber@opensynergy.com/ > > > > which in that context is used like: > > > > +static int __init virtio_scmi_init(void) > > +{ > > + return register_virtio_driver(&virtio_scmi_driver); > > +} > > + > > +static void __exit virtio_scmi_exit(void) > > +{ > > + unregister_virtio_driver(&virtio_scmi_driver); > > +} > > + > > +const struct scmi_desc scmi_virtio_desc = { > > + .init = virtio_scmi_init, > > + .exit = virtio_scmi_exit, > > + .ops = &scmi_virtio_ops, > > > > I'll cleanup further that init/deinit patch and move it out into that bunch > > of SCMI core changes that I'm making (in a separate series) to aid in virtio-scmi > > devel. > > In the meantime for your testing the above lore patch should work fine. > > Thanks for the details, i'll upgrade to the series. > Just a heads up that I have minimally updated this patch about transport init/exit helpers in V4 VirtIO SCMI series, to address some bug at unloading time I spotted while testing (even though you're not probably interested in such load/unload scenario) Updated patch: https://lore.kernel.org/linux-arm-kernel/20210611165937.701-4-cristian.marussi@arm.com/T/#u Thanks, Cristian
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: Etienne Carriere <etienne.carriere@linaro.org> Cc: linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Sudeep Holla <sudeep.holla@arm.com>, Vincent Guittot <vincent.guittot@linaro.org> Subject: Re: [PATCH v2 4/4] firmware: arm_scmi: add optee transport Date: Fri, 11 Jun 2021 18:30:19 +0100 [thread overview] Message-ID: <20210611173019.GB35183@e120937-lin> (raw) In-Reply-To: <CAN5uoS_0SMndmAvTwZnsCeQSUAfvBRz1diU_94CSYrsBxsZeew@mail.gmail.com> Hi Etienne, On Fri, May 28, 2021 at 11:43:24AM +0200, Etienne Carriere wrote: > Hello Christian, > > On Thu, 27 May 2021 at 17:11, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > > Hi Etienne, > > > > some remarks below. > > > > On Fri, May 21, 2021 at 03:40:54PM +0200, Etienne Carriere wrote: > > > Add a new transport channel to the SCMI firmware interface driver for > > > SCMI message exchange based on OP-TEE transport channel that leverage > > > OP-TEE secure threaded context for processing of SCMI messages. > > > > > > +static int __init optee_scmi_init(void) [snip] > > > +{ > > > + return driver_register(&optee_scmi_driver.driver); > > > +} > > > + > > > +static void __exit optee_scmi_exit(void) > > > +{ > > > + driver_unregister(&optee_scmi_driver.driver); > > > +} > > > + > > > +module_init(optee_scmi_init); > > > +module_exit(optee_scmi_exit); > > > + > > > > This cannot compile is the full SCMI statck ARM_SCMI_PROTOCOL is configured as =m > > > > /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > drivers/firmware/arm_scmi/optee_service.o: in function > > `optee_scmi_init': > > /home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/optee_service.c:515: > > multiple definition of `init_module'; > > drivers/firmware/arm_scmi/driver.o:/home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/driver.c:1593: > > first defined here > > /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > drivers/firmware/arm_scmi/optee_service.o: in function > > `optee_scmi_exit': > > /home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/optee_service.c:520: > > multiple definition of `cleanup_module'; > > drivers/firmware/arm_scmi/driver.o:/home/crimar01/ARM/dev/src/pdsw/linux/drivers/firmware/arm_scmi/driver.c:1611: > > first defined here > > /home/crimar01/ARM/dev/src/pdsw/linux/scripts/Makefile.build:449: recipe > > for target 'drivers/firmware/arm_scmi/scmi-module.o' failed > > make[4]: *** [drivers/firmware/arm_scmi/scmi-module.o] Error 1 > > > > > > Indeed it was the same issue we faced in the virtio-scmi series, and it > > derives from the fact that SCMI transports 'driver' are really NOT > > standalone drivers but only extension of the main SCMI module, so you > > cannot have them initialize their stuff using usual kernel module_ machinery. > > > > In order to address this, and avoid a hell of ifdeffery probably, > > in the context of virtio-scmi, I added a couple of transport's > > optionalily provided init/deinit functions so that a transport can provide > > some specific init code and be assured they are called at SCMI stack init, > > so definitely even before the SCMI stack is probed and the selected > > transport used. > > > > This is the patch from the virtio-scmi series: > > > > https://lore.kernel.org/linux-arm-kernel/20210511002040.802226-3-peter.hilber@opensynergy.com/ > > > > which in that context is used like: > > > > +static int __init virtio_scmi_init(void) > > +{ > > + return register_virtio_driver(&virtio_scmi_driver); > > +} > > + > > +static void __exit virtio_scmi_exit(void) > > +{ > > + unregister_virtio_driver(&virtio_scmi_driver); > > +} > > + > > +const struct scmi_desc scmi_virtio_desc = { > > + .init = virtio_scmi_init, > > + .exit = virtio_scmi_exit, > > + .ops = &scmi_virtio_ops, > > > > I'll cleanup further that init/deinit patch and move it out into that bunch > > of SCMI core changes that I'm making (in a separate series) to aid in virtio-scmi > > devel. > > In the meantime for your testing the above lore patch should work fine. > > Thanks for the details, i'll upgrade to the series. > Just a heads up that I have minimally updated this patch about transport init/exit helpers in V4 VirtIO SCMI series, to address some bug at unloading time I spotted while testing (even though you're not probably interested in such load/unload scenario) Updated patch: https://lore.kernel.org/linux-arm-kernel/20210611165937.701-4-cristian.marussi@arm.com/T/#u Thanks, Cristian _______________________________________________ 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:[~2021-06-11 17:30 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-21 13:40 [PATCH v2 1/4] firmware: arm_scmi: fix deps arm-smccc-discovery deps in Kconfig Etienne Carriere 2021-05-21 13:40 ` Etienne Carriere 2021-05-21 13:40 ` [PATCH v2 2/4] dt-bindings: arm: scmi property mboxes is not mandatory Etienne Carriere 2021-05-21 13:40 ` Etienne Carriere 2021-06-02 10:40 ` Sudeep Holla 2021-06-02 10:40 ` Sudeep Holla 2021-05-21 13:40 ` [PATCH v2 3/4] dt-bindings: arm: OP-TEE as transport channel for SCMI messages Etienne Carriere 2021-05-21 13:40 ` Etienne Carriere 2021-06-02 10:53 ` Sudeep Holla 2021-06-02 10:53 ` Sudeep Holla 2021-05-21 13:40 ` [PATCH v2 4/4] firmware: arm_scmi: add optee transport Etienne Carriere 2021-05-21 13:40 ` Etienne Carriere 2021-05-27 15:11 ` Cristian Marussi 2021-05-27 15:11 ` Cristian Marussi 2021-05-28 9:43 ` Etienne Carriere 2021-05-28 9:43 ` Etienne Carriere 2021-06-01 10:41 ` Cristian Marussi 2021-06-01 10:41 ` Cristian Marussi 2021-06-11 17:30 ` Cristian Marussi [this message] 2021-06-11 17:30 ` Cristian Marussi 2021-05-21 15:15 ` [PATCH v2 1/4] firmware: arm_scmi: fix deps arm-smccc-discovery deps in Kconfig Sudeep Holla 2021-05-21 15:15 ` Sudeep Holla 2021-05-21 15:20 ` Florian Fainelli 2021-05-21 15:20 ` Florian Fainelli 2021-05-21 15:26 ` Sudeep Holla 2021-05-21 15:26 ` Sudeep Holla 2021-05-27 13:28 ` Cristian Marussi 2021-05-27 13:28 ` Cristian Marussi 2021-06-02 10:55 ` Sudeep Holla 2021-06-02 10:55 ` Sudeep Holla 2021-06-04 8:53 ` (subset) " Sudeep Holla 2021-06-04 8:53 ` 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=20210611173019.GB35183@e120937-lin \ --to=cristian.marussi@arm.com \ --cc=etienne.carriere@linaro.org \ --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: linkBe 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.