Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6173752rwb; Mon, 5 Dec 2022 08:52:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf4hfLq5o5f0zgQZFeCSTH0Tak6a10pjJx6mu4epxNjKaPuRNaGeWtdAn/FDPD37+MINQbl1 X-Received: by 2002:aa7:c859:0:b0:461:17e9:4ea3 with SMTP id g25-20020aa7c859000000b0046117e94ea3mr74461483edt.49.1670259160014; Mon, 05 Dec 2022 08:52:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670259160; cv=none; d=google.com; s=arc-20160816; b=E6z9cfUTjv5YYf2Ydcrlf8er/pdRBIk6d+WK9R1zswHXN0OfOjK/FfxES9Lv9FVAH/ ffTo3yODTxH9iPTUG5gWOl7XH/ruR9odrucNdp3TMOFP6tqOA0rv3oUfQfYa2YzlzvTn EMYSDXpy2IVUquQ2pgXs9nJR1T4Xc6ZoLZfAXN2LIWuVX5AN3cCS9ed9WE3OTGj2R0vR oM4K03hecD3hF3g6ix3y3sOGhXodJI58G8KzIGrSbSHUs939saUH2KILNnmShP0NN58D lYOz/Idr8P7B8xgbZ1ylPsHQZRwZ+Lp45ThREfsskMJjg1lzRC0xM36bcAM1D48HWoTg KU6Q== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=HzMYSvPDJqzbBeZPzO32EvtpfZ76bFAty3nVDxH187k=; b=MPsNFgs69+tEWEz2vhLUaStqtmZmfOTiZx1ZnD8HBLB/hjPraXM304NbN3yqdnD5Jg ZkBfZzvMXboOkvX17WnoTpmbI3k7GzlyjAXDP+YH6iEX6RA3+fNjuOrvfWdHBzf74sjV ZhatbXVupj2/sFEst8wq5g+80hm47RQtW4fHAM8QqzyzMYdh/YQlAd0FfvlRDPbid3gm rWbrnQRk4E810FHH9KPehgTHwcLmDxZocvmmIrCCwPFdlt29PNR1TRut9/fRigC0tphk EspP3ArtFGgO3zSN2+0MLfSShdTszOpDBiblU9TQM1Y10vH07jo8giaKdDRRYksv2MAs iHcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NJqRl810; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eh12-20020a0564020f8c00b0046a84b922a2si728edb.499.2022.12.05.08.52.20; Mon, 05 Dec 2022 08:52:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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; dkim=pass header.i=@intel.com header.s=Intel header.b=NJqRl810; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233216AbiLEQkV (ORCPT + 81 others); Mon, 5 Dec 2022 11:40:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232932AbiLEQjY (ORCPT ); Mon, 5 Dec 2022 11:39:24 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 194E9B1EC; Mon, 5 Dec 2022 08:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670258290; x=1701794290; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=j9+STK0zi4B2lTIuMwhQZtGCC1nrqQHxIDObNGJfAso=; b=NJqRl810z2WCNxXqNSoxRKGKkfwPOMbP/NSI8G1eeF+dtsDWwDtatG+C xlQ67/TO/W7OZ9Jd/Ok4D+kkQXk/24GIJlTTKh4zX3E3sN01Hg9RgDlns pqgO8Di6Hrx6RSDcVUjejOKasmjxztuPedHHEBP3wWMXQ7I98O6zOC7IV Mapt0PWfbBfbpZTJy5lzlep+JQWZH1ELPsTavRRzCaqTNSbVlpI+EHg4m ubKOXTybsL/krnkRVWYJg/AScMinTt5asuSaZb3/5A6iQCzqK3eDvSkcI Nl1J6RY5H8VjJ2OpVS4xAA7jdRPLlbAlq+Gfx8ICGTnm+jHInZ3g8d48O w==; X-IronPort-AV: E=McAfee;i="6500,9779,10552"; a="402670055" X-IronPort-AV: E=Sophos;i="5.96,220,1665471600"; d="scan'208";a="402670055" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2022 08:38:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10552"; a="714459365" X-IronPort-AV: E=Sophos;i="5.96,220,1665471600"; d="scan'208";a="714459365" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by fmsmga004.fm.intel.com with ESMTP; 05 Dec 2022 08:38:07 -0800 Date: Tue, 6 Dec 2022 00:28:22 +0800 From: Xu Yilun To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: Mark Brown , linux-fpga@vger.kernel.org, Wu Hao , Tom Rix , Moritz Fischer , Lee Jones , Matthew Gerlach , Russ Weight , Tianfei zhang , Greg KH , Marco Pagani , LKML Subject: Re: [PATCH v3 7/9] mfd: intel-m10-bmc: Add PMCI driver Message-ID: References: <20221202100841.4741-1-ilpo.jarvinen@linux.intel.com> <20221202100841.4741-8-ilpo.jarvinen@linux.intel.com> <855d463e-fb84-1910-f53-58e6b0a633a4@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <855d463e-fb84-1910-f53-58e6b0a633a4@linux.intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE 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-kernel@vger.kernel.org On 2022-12-05 at 11:51:15 +0200, Ilpo J?rvinen wrote: > On Sat, 3 Dec 2022, Xu Yilun wrote: > > > On 2022-12-02 at 12:08:39 +0200, Ilpo J?rvinen wrote: > > > + void __iomem *base, > > > + struct regmap_config *cfg, > > > + struct lock_class_key *lock_key, > > > + const char *lock_name) > > > +{ > > > + struct indirect_ctx *ctx; > > > + > > > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > > > + if (!ctx) > > > + return NULL; > > > + > > > + ctx->base = base; > > > + ctx->dev = dev; > > > + > > > + indirect_bus_clear_cmd(ctx); > > > + > > > + return __devm_regmap_init(dev, &indirect_bus, ctx, cfg, lock_key, lock_name); > > > > Sorry, I just can't remember why don't we just call devm_regmap_init() and > > get rid of all lock stuff? > > At this point, we're already entered into __-domain though a > __regmap_lockdep_wrapper(). If I call devm_regmap_init() here, the > second call into the wrapper would create another key which doesn't seem > right. I mean could we not define new regmap_init_xxx & __regmap_init_xxx APIs? Just call devm_regmap_init() when we have prepared the context, devm_regmap_init() will take care of the lock stuff. Thanks, Yilun