From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67A09C433B4 for ; Wed, 19 May 2021 05:36:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 43ED261364 for ; Wed, 19 May 2021 05:36:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244551AbhESFhS (ORCPT ); Wed, 19 May 2021 01:37:18 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:40806 "EHLO mail-lf1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241566AbhESFf2 (ORCPT ); Wed, 19 May 2021 01:35:28 -0400 Received: by mail-lf1-f48.google.com with SMTP id w33so9239548lfu.7 for ; Tue, 18 May 2021 22:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc :in-reply-to:references:mime-version:date:user-agent :content-transfer-encoding; bh=fC1CaIU+pSkmYQdi6dJq59uRpeoDdhiocnnvg2FvKyE=; b=YPcjqPRqtGlTinuTKNkuYKS05PxjkL0lQS5iWhoaY/H1/eQ0fZe9bCkYiLBejXsusR UoFKEFO4jYe6nGsXNTWLBm1FY9By6+TIZypWpeSpRGtdZlOwbcz19s4k6rSIvsZ3Hrak z98ffjbf/1HbdkALHKZQ412y1U+52O2PbSC1J3wcUWQc+IHL4jNAercBVMPYpMSPVagB 0gG9SlG4Q5vuQM6QglVESPjG36mfCZQNlDPXUlPGrQUjjmHHomRhNJaiKORRzogG3oqq MwVHqvwvYkrXLJT9d472GjMl0GYHLE2jgoteg13ZwlwzdsbUeN4SIoPUS6Ssi7Vd4JTp RxNQ== X-Gm-Message-State: AOAM5322lTJyn83mImdo7sZ0i1MWlcgker1x2HWZViide9t0MRmsxUZi rxusgYC28vre459Vu6SGOQgRY48icmrxJw== X-Google-Smtp-Source: ABdhPJyX4yTCbPOoWfrgd7DmBR3ZO5Rh49nIBfzOpw5Io832iLT5WCwHyiyQsWHhGZKuwNA/5WcOkw== X-Received: by 2002:a05:6512:21d:: with SMTP id a29mr7150382lfo.391.1621402447397; Tue, 18 May 2021 22:34:07 -0700 (PDT) Received: from dc7vkhyyyyyyyyyyyyyyt-3.rev.dnainternet.fi (dc7vkhyyyyyyyyyyyyyyt-3.rev.dnainternet.fi. [2001:14ba:16e2:8300::1]) by smtp.gmail.com with ESMTPSA id b24sm2480405lff.93.2021.05.18.22.34.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 May 2021 22:34:07 -0700 (PDT) Message-ID: <278ddbfcb0f5a9326eefdc22b35f2a476c482caa.camel@fi.rohmeurope.com> Subject: Re: [PATCH v2 0/5] Add devm helper for work-queue initialization From: Matti Vaittinen Reply-To: matti.vaittinen@fi.rohmeurope.com To: Rob Herring Cc: hanwoo Choi , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , MyungJoo Ham , Hans de Goede , Marek Szyprowski , linux-kernel@vger.kernel.org In-Reply-To: <20210519003938.GA1649581@robh.at.kernel.org> References: <20210519003938.GA1649581@robh.at.kernel.org> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 19 May 2021 08:33:58 +0300 User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2021-05-18 at 19:39 -0500, Rob Herring wrote: > On Tue, May 18, 2021 at 03:31:37PM +0300, Matti Vaittinen wrote: > > This series adds new devm_work_autocancel() helper. > > > > Many drivers which use work-queues must ensure the work is not > > queued when > > driver is detached. Often this is done by ensuring new work is not > > added and > > then calling cancel_work_sync() at remove(). In many cases this > > also requires > > cleanup at probe error path - which is easy to forget (or get > > wrong). > > > > Also the "by ensuring new work is not added" has a gotcha. > > > > It is not strange to see devm managed IRQs scheduling work. > > Mixing this with manual wq clean-up is hard to do correctly because > > the > > devm is likely to free the IRQ only after the remove() is ran. So > > manual > > wq cancellation and devm-based IRQ management do not mix well - > > there is > > a short(?) time-window after the wq clean-up when IRQs are still > > not > > freed and may schedule new work. > > > > When both WQs and IRQs are managed by devm things are likely to > > just > > work. WQs should be initialized before IRQs (when IRQs need to > > schedule > > work) and devm unwinds things in "FILO" order. > > Wouldn't it be better to convert drivers to use threaded IRQ > handlers? Morning Rob, I think for example the extcon drivers were using threaded IRQs. In general, there may be legitimate use-cases for having threaded IRQs but still offloading some work to WQ. I guess that for example the IRQF_ONESHOT usage could be such, right? Best Regards Matti Vaittinen