Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1517838iob; Fri, 29 Apr 2022 07:06:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxd8t2KnYHfJtgWWbeq/BrQMebJMiLFSBrSA3Rh0YsNhON6Id/icl28FF4Jfd2Uy0fokmOE X-Received: by 2002:a17:902:b596:b0:158:f23a:c789 with SMTP id a22-20020a170902b59600b00158f23ac789mr38365911pls.57.1651241203553; Fri, 29 Apr 2022 07:06:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651241203; cv=none; d=google.com; s=arc-20160816; b=ynnWk/KABWkNWJUFUd0q/xknZbK4Q+qiHdnTO8cz7l4zYQgu4F3SPP9jSmJD1gxiV5 p8No+5MlesysRktmtJGfMIccfMrCU1tv81/lmQISYVt/nd8o65yF6cJVc8yRFsMolkOn ahz26LYdBuL4HiwcpchyKEJjqEGsVh2WnLgsBuAsdpDn0Vn85r2+2wckonpP+2bTduML zztiSe2PwX70rY+BFGekd7l6pIWY4mbK1KFOeqp6BEXolC4IlvLMRSW/95p/wiR8lscn omjo62b/n2cBa6ZJEMxL+x93X3WbP69S4P34/0USWsbNPDIBxX7X1zqg6pMyutMViY8O 2y0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ckh5lPtVNWT5Zk7PnvCXV4e1X8+6r1hk/gvVz+045HM=; b=EkxCjp3QU/nrtB9d2BkMX1qdtiPqAuCqIysa/5E6uEhGVK0+Y4Og9hnmbrcACzXIwo /piy6qAtYiZU/ghmPn/A01YQV4lacOs3JNq3xqcYcz7/peZf0oHAy4WSTD8liCXkfCU+ QnyOij82Fr5kF7vNnHouJ5hwt5oBkTCTa+93zTUztqC3Mwiv1XgBlDy/r72QrloKqRk7 ajlqU9/QkOAtg82viDT5TujGlMk0Q4rkH6F7Od2Hm/VEaSItVb+soxHK06tquT8b7yzp mjPEsfCzk/Dg4B7wQ5+qbgIxwCCIAUu8d+E9vh1i5Jt6iB9goGJE7CztmwvOSftMjoO9 RZeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v6-20020a63b646000000b003bc321e6d61si7052819pgt.379.2022.04.29.07.06.20; Fri, 29 Apr 2022 07:06:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348910AbiD2IsP (ORCPT + 99 others); Fri, 29 Apr 2022 04:48:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351140AbiD2IsO (ORCPT ); Fri, 29 Apr 2022 04:48:14 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B342EC400A for ; Fri, 29 Apr 2022 01:44:56 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1nkMF2-008CAp-7E; Fri, 29 Apr 2022 18:44:45 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 29 Apr 2022 16:44:44 +0800 Date: Fri, 29 Apr 2022 16:44:44 +0800 From: Herbert Xu To: Tetsuo Handa Cc: Tudor Ambarus , "David S. Miller" , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , linux-crypto@vger.kernel.org Subject: Re: [PATCH] crypto: atmel - Avoid flush_scheduled_work() usage Message-ID: References: <35da6cb2-910f-f892-b27a-4a8bac9fd1b1@I-love.SAKURA.ne.jp> <5de198b9-7488-13e4-bf22-6c58c1c8b401@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5de198b9-7488-13e4-bf22-6c58c1c8b401@I-love.SAKURA.ne.jp> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Apr 29, 2022 at 03:26:07PM +0900, Tetsuo Handa wrote: > > Since drivers/crypto/Makefile has lines in > > obj-$(CONFIG_CRYPTO_DEV_ATMEL_I2C) += atmel-i2c.o > obj-$(CONFIG_CRYPTO_DEV_ATMEL_ECC) += atmel-ecc.o > obj-$(CONFIG_CRYPTO_DEV_ATMEL_SHA204A) += atmel-sha204a.o > > order (which will be used as link order for built-in.o), module_init() > is processed in this order. Also, module_exit() is no-op if built-in. > Therefore, I think there is no need to explicitly boost the priority > of atmel_i2c_init(). If we're going to rely on the Makefile ordering please make it explicit and add a comment in the Makefile. Otherwise this is way too fragile. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt