From: "Sven Peter" <sven@svenpeter.dev> To: "Arnd Bergmann" <arnd@arndb.de> Cc: "Hector Martin" <marcan@marcan.st>, "Alyssa Rosenzweig" <alyssa@rosenzweig.io>, "Rob Herring" <robh+dt@kernel.org>, "Keith Busch" <kbusch@kernel.org>, "axboe@fb.com" <axboe@fb.com>, "hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>, "Marc Zyngier" <maz@kernel.org>, DTML <devicetree@vger.kernel.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-nvme@lists.infradead.org Subject: Re: [PATCH 5/9] soc: apple: Add RTKit IPC library Date: Sat, 02 Apr 2022 14:56:32 +0200 [thread overview] Message-ID: <3166b80d-d8a6-45d5-9e3b-2f9998aca0d3@www.fastmail.com> (raw) In-Reply-To: <CAK8P3a2VgrWHerXTX4_wS8UU7fpN9-JZ5xESaWrr-WGYqGty=g@mail.gmail.com> On Tue, Mar 22, 2022, at 14:13, Arnd Bergmann wrote: > On Mon, Mar 21, 2022 at 5:50 PM Sven Peter <sven@svenpeter.dev> wrote: >> >> Apple SoCs such as the M1 come with multiple embedded co-processors >> running proprietary firmware. Communication with those is established >> over a simple mailbox using the RTKit IPC protocol. >> >> Signed-off-by: Sven Peter <sven@svenpeter.dev> > >> + >> +#define rtk_err(format, arg...) dev_err(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_warn(format, arg...) dev_warn(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_info(format, arg...) dev_info(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_dbg(format, arg...) dev_dbg(rtk->dev, "RTKit: " format, ##arg) > > I generally don't like the custom printing macros, please just open-code > the prints where they are used, that makes it easier for other kernel > developers to see exactly what is being printed. > Sure, I'll remove them. >> +enum { APPLE_RTKIT_WORK_MSG, >> + APPLE_RTKIT_WORK_REINIT, >> +}; >> + >> +enum { APPLE_RTKIT_PWR_STATE_OFF = 0x00, >> + APPLE_RTKIT_PWR_STATE_SLEEP = 0x01, >> + APPLE_RTKIT_PWR_STATE_GATED = 0x02, >> + APPLE_RTKIT_PWR_STATE_QUIESCED = 0x10, >> + APPLE_RTKIT_PWR_STATE_ON = 0x20, >> +}; > > This is an odd indentation style, I would insert a newline after the 'enum {' Yeah, I blame clang-format and me not double-checking the result for that one. I'll add the newline. > >> +static int apple_rtkit_worker(void *data) >> +{ >> + struct apple_rtkit *rtk = data; >> + struct apple_rtkit_work work; >> + >> + while (!kthread_should_stop()) { >> + wait_event_interruptible(rtk->wq, >> + kfifo_len(&rtk->work_fifo) > 0 || >> + kthread_should_stop()); >> + >> + if (kthread_should_stop()) >> + break; >> + >> + while (kfifo_out_spinlocked(&rtk->work_fifo, &work, 1, >> + &rtk->work_lock) == 1) { >> + switch (work.type) { >> + case APPLE_RTKIT_WORK_MSG: >> + apple_rtkit_rx(rtk, &work.msg); >> + break; >> + case APPLE_RTKIT_WORK_REINIT: >> + apple_rtkit_do_reinit(rtk); >> + break; >> + } >> + } > > It looks like you add quite a bit of complexity by using a custom > worker thread implementation. Can you explain what this is > needed for? Isn't this roughly the same thing that one would > get more easily with create_singlethread_workqueue()? I originally had just a workqueue here but I can only put one instance of e.g. APPLE_RTKIT_WORK_MSG onto these. There could however be a new incoming message while the previous one is still being handled and I couldn't figure out a way to handle that with workqueues without introducing a race. > >> +#if IS_ENABLED(CONFIG_APPLE_RTKIT) > > Instead of allowing the interface to be used without CONFIG_APPLE_RTKIT, > I think it is sufficient to allow the driver itself to be built with > CONFIG_COMPILE_TEST (as you already do), and then have > drivers using it marked as 'depends on APPLE_RTKIT' > unconditionally. That's indeed much simpler and what I wanted to achieve. I just couldn't figure out how to do it. I'll use your approach! > >> +/* >> + * Initializes the internal state required to handle RTKit. This >> + * should usually be called within _probe. >> + * >> + * @dev: Pointer to the device node this coprocessor is assocated with >> + * @cookie: opaque cookie passed to all functions defined in rtkit_ops >> + * @mbox_name: mailbox name used to communicate with the co-processor >> + * @mbox_idx: mailbox index to be used if mbox_name is NULL >> + * @ops: pointer to rtkit_ops to be used for this co-processor >> + */ >> +struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie, >> + const char *mbox_name, int mbox_idx, >> + const struct apple_rtkit_ops *ops); >> + >> +/* >> + * Dev-res managed version of apple_rtkit_init. >> + */ >> +struct apple_rtkit *devm_apple_rtkit_init(struct device *dev, void *cookie, >> + const char *mbox_name, int mbox_idx, >> + const struct apple_rtkit_ops *ops); > > Do we need to export both of these? No, only devm_apple_rtkit_init needs to be exported. Thanks, Sven
WARNING: multiple messages have this Message-ID (diff)
From: "Sven Peter" <sven@svenpeter.dev> To: "Arnd Bergmann" <arnd@arndb.de> Cc: "Hector Martin" <marcan@marcan.st>, "Alyssa Rosenzweig" <alyssa@rosenzweig.io>, "Rob Herring" <robh+dt@kernel.org>, "Keith Busch" <kbusch@kernel.org>, "axboe@fb.com" <axboe@fb.com>, "hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>, "Marc Zyngier" <maz@kernel.org>, DTML <devicetree@vger.kernel.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-nvme@lists.infradead.org Subject: Re: [PATCH 5/9] soc: apple: Add RTKit IPC library Date: Sat, 02 Apr 2022 14:56:32 +0200 [thread overview] Message-ID: <3166b80d-d8a6-45d5-9e3b-2f9998aca0d3@www.fastmail.com> (raw) In-Reply-To: <CAK8P3a2VgrWHerXTX4_wS8UU7fpN9-JZ5xESaWrr-WGYqGty=g@mail.gmail.com> On Tue, Mar 22, 2022, at 14:13, Arnd Bergmann wrote: > On Mon, Mar 21, 2022 at 5:50 PM Sven Peter <sven@svenpeter.dev> wrote: >> >> Apple SoCs such as the M1 come with multiple embedded co-processors >> running proprietary firmware. Communication with those is established >> over a simple mailbox using the RTKit IPC protocol. >> >> Signed-off-by: Sven Peter <sven@svenpeter.dev> > >> + >> +#define rtk_err(format, arg...) dev_err(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_warn(format, arg...) dev_warn(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_info(format, arg...) dev_info(rtk->dev, "RTKit: " format, ##arg) >> +#define rtk_dbg(format, arg...) dev_dbg(rtk->dev, "RTKit: " format, ##arg) > > I generally don't like the custom printing macros, please just open-code > the prints where they are used, that makes it easier for other kernel > developers to see exactly what is being printed. > Sure, I'll remove them. >> +enum { APPLE_RTKIT_WORK_MSG, >> + APPLE_RTKIT_WORK_REINIT, >> +}; >> + >> +enum { APPLE_RTKIT_PWR_STATE_OFF = 0x00, >> + APPLE_RTKIT_PWR_STATE_SLEEP = 0x01, >> + APPLE_RTKIT_PWR_STATE_GATED = 0x02, >> + APPLE_RTKIT_PWR_STATE_QUIESCED = 0x10, >> + APPLE_RTKIT_PWR_STATE_ON = 0x20, >> +}; > > This is an odd indentation style, I would insert a newline after the 'enum {' Yeah, I blame clang-format and me not double-checking the result for that one. I'll add the newline. > >> +static int apple_rtkit_worker(void *data) >> +{ >> + struct apple_rtkit *rtk = data; >> + struct apple_rtkit_work work; >> + >> + while (!kthread_should_stop()) { >> + wait_event_interruptible(rtk->wq, >> + kfifo_len(&rtk->work_fifo) > 0 || >> + kthread_should_stop()); >> + >> + if (kthread_should_stop()) >> + break; >> + >> + while (kfifo_out_spinlocked(&rtk->work_fifo, &work, 1, >> + &rtk->work_lock) == 1) { >> + switch (work.type) { >> + case APPLE_RTKIT_WORK_MSG: >> + apple_rtkit_rx(rtk, &work.msg); >> + break; >> + case APPLE_RTKIT_WORK_REINIT: >> + apple_rtkit_do_reinit(rtk); >> + break; >> + } >> + } > > It looks like you add quite a bit of complexity by using a custom > worker thread implementation. Can you explain what this is > needed for? Isn't this roughly the same thing that one would > get more easily with create_singlethread_workqueue()? I originally had just a workqueue here but I can only put one instance of e.g. APPLE_RTKIT_WORK_MSG onto these. There could however be a new incoming message while the previous one is still being handled and I couldn't figure out a way to handle that with workqueues without introducing a race. > >> +#if IS_ENABLED(CONFIG_APPLE_RTKIT) > > Instead of allowing the interface to be used without CONFIG_APPLE_RTKIT, > I think it is sufficient to allow the driver itself to be built with > CONFIG_COMPILE_TEST (as you already do), and then have > drivers using it marked as 'depends on APPLE_RTKIT' > unconditionally. That's indeed much simpler and what I wanted to achieve. I just couldn't figure out how to do it. I'll use your approach! > >> +/* >> + * Initializes the internal state required to handle RTKit. This >> + * should usually be called within _probe. >> + * >> + * @dev: Pointer to the device node this coprocessor is assocated with >> + * @cookie: opaque cookie passed to all functions defined in rtkit_ops >> + * @mbox_name: mailbox name used to communicate with the co-processor >> + * @mbox_idx: mailbox index to be used if mbox_name is NULL >> + * @ops: pointer to rtkit_ops to be used for this co-processor >> + */ >> +struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie, >> + const char *mbox_name, int mbox_idx, >> + const struct apple_rtkit_ops *ops); >> + >> +/* >> + * Dev-res managed version of apple_rtkit_init. >> + */ >> +struct apple_rtkit *devm_apple_rtkit_init(struct device *dev, void *cookie, >> + const char *mbox_name, int mbox_idx, >> + const struct apple_rtkit_ops *ops); > > Do we need to export both of these? No, only devm_apple_rtkit_init needs to be exported. Thanks, Sven _______________________________________________ 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:[~2022-04-02 12:56 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-21 16:50 [PATCH 0/9] Apple M1 (Pro/Max) NVMe driver Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` [PATCH 1/9] dt-bindings: soc: apple: Add Apple SART Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-31 21:23 ` Rob Herring 2022-03-31 21:23 ` Rob Herring 2022-04-02 12:58 ` Sven Peter 2022-04-02 12:58 ` Sven Peter 2022-03-21 16:50 ` [PATCH 2/9] dt-bindings: soc: apple: Add ANS NVMe Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-23 11:14 ` Krzysztof Kozlowski 2022-03-23 11:14 ` Krzysztof Kozlowski 2022-04-02 13:05 ` Sven Peter 2022-04-02 13:05 ` Sven Peter 2022-04-02 16:06 ` Krzysztof Kozlowski 2022-04-02 16:06 ` Krzysztof Kozlowski 2022-03-21 16:50 ` [PATCH 3/9] soc: apple: Always include Makefile Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` [PATCH 4/9] soc: apple: Add SART driver Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 17:07 ` Arnd Bergmann 2022-03-21 17:07 ` Arnd Bergmann 2022-04-02 12:38 ` Sven Peter 2022-04-02 12:38 ` Sven Peter 2022-04-02 19:07 ` Arnd Bergmann 2022-04-02 19:07 ` Arnd Bergmann 2022-04-04 14:58 ` Rob Herring 2022-04-04 14:58 ` Rob Herring 2022-04-04 15:01 ` Hector Martin 2022-04-04 15:01 ` Hector Martin 2022-04-05 15:37 ` Sven Peter 2022-04-05 15:37 ` Sven Peter 2022-03-21 17:17 ` Alyssa Rosenzweig 2022-03-21 17:17 ` Alyssa Rosenzweig 2022-04-02 12:40 ` Sven Peter 2022-04-02 12:40 ` Sven Peter 2022-03-21 16:50 ` [PATCH 5/9] soc: apple: Add RTKit IPC library Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-22 13:13 ` Arnd Bergmann 2022-03-22 13:13 ` Arnd Bergmann 2022-03-22 17:41 ` Robin Murphy 2022-03-22 17:41 ` Robin Murphy 2022-04-02 12:56 ` Sven Peter [this message] 2022-04-02 12:56 ` Sven Peter 2022-04-02 18:30 ` Arnd Bergmann 2022-04-02 18:30 ` Arnd Bergmann 2022-04-03 10:45 ` Sven Peter 2022-04-03 10:45 ` Sven Peter 2022-03-22 17:23 ` Alyssa Rosenzweig 2022-03-22 17:23 ` Alyssa Rosenzweig 2022-04-02 12:50 ` Sven Peter 2022-04-02 12:50 ` Sven Peter 2022-03-23 11:19 ` Krzysztof Kozlowski 2022-03-23 11:19 ` Krzysztof Kozlowski 2022-04-02 13:51 ` Sven Peter 2022-04-02 13:51 ` Sven Peter 2022-04-02 16:08 ` Krzysztof Kozlowski 2022-04-02 16:08 ` Krzysztof Kozlowski 2022-04-04 15:02 ` Rob Herring 2022-04-04 15:02 ` Rob Herring 2022-04-04 15:47 ` Hector Martin 2022-04-04 15:47 ` Hector Martin 2022-03-21 16:50 ` [PATCH 6/9] nvme-apple: Add initial Apple SoC NVMe driver Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 17:01 ` Keith Busch 2022-03-21 17:01 ` Keith Busch 2022-04-02 13:10 ` Sven Peter 2022-04-02 13:10 ` Sven Peter 2022-03-22 13:38 ` Arnd Bergmann 2022-03-22 13:38 ` Arnd Bergmann 2022-04-02 13:34 ` Sven Peter 2022-04-02 13:34 ` Sven Peter 2022-04-02 13:58 ` Janne Grunau 2022-04-02 13:58 ` Janne Grunau 2022-04-02 14:02 ` Sven Peter 2022-04-02 14:02 ` Sven Peter 2022-04-02 21:26 ` Arnd Bergmann 2022-04-02 21:26 ` Arnd Bergmann 2022-03-24 6:16 ` Christoph Hellwig 2022-03-24 6:16 ` Christoph Hellwig 2022-04-02 12:47 ` Sven Peter 2022-04-02 12:47 ` Sven Peter 2022-04-04 15:57 ` Hector Martin 2022-04-04 15:57 ` Hector Martin 2022-04-04 15:59 ` Christoph Hellwig 2022-04-04 15:59 ` Christoph Hellwig 2022-04-04 16:03 ` Sven Peter 2022-04-04 16:03 ` Sven Peter 2022-04-04 16:05 ` hch 2022-04-04 16:05 ` hch 2022-04-04 16:05 ` Hector Martin 2022-04-04 16:05 ` Hector Martin 2022-04-04 18:29 ` Jens Axboe 2022-04-04 18:29 ` Jens Axboe 2022-04-05 6:24 ` Christoph Hellwig 2022-04-05 6:24 ` Christoph Hellwig 2022-03-21 16:50 ` [PATCH 7/9] nvme-apple: Serialize command issue Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-24 6:16 ` Christoph Hellwig 2022-03-24 6:16 ` Christoph Hellwig 2022-04-02 12:42 ` Sven Peter 2022-04-02 12:42 ` Sven Peter 2022-03-21 16:50 ` [PATCH 8/9] nvme-apple: Add support for multiple power domains Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-21 16:50 ` [PATCH 9/9] nvme-apple: Add support for suspend/resume Sven Peter 2022-03-21 16:50 ` Sven Peter 2022-03-24 6:17 ` Christoph Hellwig 2022-03-24 6:17 ` Christoph Hellwig 2022-03-22 17:26 ` [PATCH 0/9] Apple M1 (Pro/Max) NVMe driver Alyssa Rosenzweig 2022-03-22 17:26 ` Alyssa Rosenzweig
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=3166b80d-d8a6-45d5-9e3b-2f9998aca0d3@www.fastmail.com \ --to=sven@svenpeter.dev \ --cc=alyssa@rosenzweig.io \ --cc=arnd@arndb.de \ --cc=axboe@fb.com \ --cc=devicetree@vger.kernel.org \ --cc=hch@lst.de \ --cc=kbusch@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=marcan@marcan.st \ --cc=maz@kernel.org \ --cc=robh+dt@kernel.org \ --cc=sagi@grimberg.me \ /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.