X86 platform drivers
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <markgross@kernel.org>
Cc: platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH] platform/surface: avoid flush_scheduled_work() usage
Date: Fri, 17 Jun 2022 13:31:15 +0200	[thread overview]
Message-ID: <09c589ee-d7fd-a504-50ef-b7803c0dc403@gmail.com> (raw)
In-Reply-To: <cf87225f-7932-9df8-90d9-af602d798700@I-love.SAKURA.ne.jp>

On 6/17/22 12:40, Tetsuo Handa wrote:
> If you are fine with per a module WQ, please apply this patch to your tree.
> 
> If you prefer per a "struct san_data" WQ like
> https://lkml.kernel.org/r/f78ddbdc-8989-a1a7-2234-ce9ec3894625@I-love.SAKURA.ne.jp
> does, you can replace this patch with yours.

I think a per-module workqueue is perfectly adequate, unless there are
some considerations I'm missing. We generally expect there to only ever
be one device instance present that this driver binds to, and even if
there were multiple instances, it's fairly low-use and we only flush in
the remove function (this is to say that I see virtually no potential
for this to live-lock or something similar).

I guess one could make the case that having it in the module as opposed
to the driver may lead to an unused workqueue if the module is loaded
(or built in) but the driver is never used. However, generally the
driver should be built as module (unless you're very specifically
targeting Surface devices) and the module is only ever loaded if the
driver will actually be used.

So, in the end, both ways should lead to virtually the same result. And
I don't really have any strong preferences either way.

> On 2022/06/10 20:29, Maximilian Luz wrote:
>> On 6/10/22 07:41, Tetsuo Handa wrote:
>>> Use local wq in order to avoid flush_scheduled_work() usage.
>>>
>>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>>> ---
>>> Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
>>> using a macro") for background.
>>>
>>> This is a blind conversion, and is only compile tested.
>>
>> Looks good to me, thanks!
>>
>> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
>> Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
>>
>>>    .../platform/surface/surface_acpi_notify.c    | 27 ++++++++++++++++---
>>>    1 file changed, 24 insertions(+), 3 deletions(-)

  reply	other threads:[~2022-06-17 11:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10  5:41 [PATCH] platform/surface: avoid flush_scheduled_work() usage Tetsuo Handa
2022-06-10 11:29 ` Maximilian Luz
2022-06-17 10:40   ` Tetsuo Handa
2022-06-17 11:31     ` Maximilian Luz [this message]
2022-06-22 10:04   ` Hans de Goede

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=09c589ee-d7fd-a504-50ef-b7803c0dc403@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=markgross@kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=platform-driver-x86@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox