All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Sven Peter <sven@svenpeter.dev>
Cc: Hector Martin <marcan@marcan.st>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Rob Herring <robh+dt@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <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: Tue, 22 Mar 2022 14:13:53 +0100	[thread overview]
Message-ID: <CAK8P3a2VgrWHerXTX4_wS8UU7fpN9-JZ5xESaWrr-WGYqGty=g@mail.gmail.com> (raw)
In-Reply-To: <20220321165049.35985-6-sven@svenpeter.dev>

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.

> +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 {'

> +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()?

> +#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.

> +/*
> + * 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?

         Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Sven Peter <sven@svenpeter.dev>
Cc: Hector Martin <marcan@marcan.st>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Rob Herring <robh+dt@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Keith Busch <kbusch@kernel.org>,  Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <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: Tue, 22 Mar 2022 14:13:53 +0100	[thread overview]
Message-ID: <CAK8P3a2VgrWHerXTX4_wS8UU7fpN9-JZ5xESaWrr-WGYqGty=g@mail.gmail.com> (raw)
In-Reply-To: <20220321165049.35985-6-sven@svenpeter.dev>

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.

> +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 {'

> +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()?

> +#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.

> +/*
> + * 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?

         Arnd

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

  reply	other threads:[~2022-03-22 13:14 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 [this message]
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
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='CAK8P3a2VgrWHerXTX4_wS8UU7fpN9-JZ5xESaWrr-WGYqGty=g@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=alyssa@rosenzweig.io \
    --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 \
    --cc=sven@svenpeter.dev \
    /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.