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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC761C433FE for ; Mon, 28 Nov 2022 09:42:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229681AbiK1JmD (ORCPT ); Mon, 28 Nov 2022 04:42:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229680AbiK1JmC (ORCPT ); Mon, 28 Nov 2022 04:42:02 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6DBD186C2; Mon, 28 Nov 2022 01:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669628521; x=1701164521; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+kLVSYpCxieBezViNJmOXfw8Ev9qIKORVhxwHMbB9K0=; b=fxm9i70QSjM2dZH9lAUvdfHaDGoFzzUq2oLNhJ5flP1hkNm/D4EQWAwr gL5TgR/wTb5oe7G1D8RbjhlSryveRxkXe3tYErQ7c2xShi5iY7i89mGia 3vHvzL5uKG+0t4HiYh9PMLClllo7YghEOB0xVHCCXrRw3K0UDHHX+wOH/ 7gywZyryM9jATZxOf9BkaF+uZfesHTXiSmTQzT3D7Rd9ZUedoQuZnA0iD S4HgEPStpxno7Wi9q0alfDk82VdQXnunI9gu/XlFOw3USMx/OX6VhRqh1 S3xmAitk20cvwvetXh8kJHQpMtmxlWXXyIQJoCn2eZWqVcu+d1G4TkVwl A==; X-IronPort-AV: E=McAfee;i="6500,9779,10544"; a="316617910" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="316617910" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 01:42:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10544"; a="711901393" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="711901393" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga004.fm.intel.com with ESMTP; 28 Nov 2022 01:41:59 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1ozaeD-0013kQ-0h; Mon, 28 Nov 2022 11:41:57 +0200 Date: Mon, 28 Nov 2022 11:41:56 +0200 From: Andy Shevchenko To: Michael Walle Cc: William Breathitt Gray , linus.walleij@linaro.org, brgl@bgdev.pl, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, broonie@kernel.org Subject: Re: [PATCH v3 3/9] gpio: 104-dio-48e: Migrate to the regmap-irq API Message-ID: References: <80fc819bcafe9697b6e02c0750d3cf0ea4ec9e1b.1669100542.git.william.gray@linaro.org> <3a23df35a35cdba19eeb10c75b5bca97@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a23df35a35cdba19eeb10c75b5bca97@walle.cc> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Sun, Nov 27, 2022 at 07:31:48PM +0100, Michael Walle wrote: > Am 2022-11-22 11:29, schrieb William Breathitt Gray: > > On Wed, Nov 23, 2022 at 05:01:53PM +0200, Andy Shevchenko wrote: > > > On Tue, Nov 22, 2022 at 02:11:00AM -0500, William Breathitt Gray > > > wrote: > > > > + /* Initialize device interrupt state */ > > > > + err = regmap_read(map, DIO48E_DISABLE_INTERRUPT, &val); > > > > + if (err) > > > > + return err; > > > > > > Use ->init_hw() callback for this. > > > > In a subsequent patch 7/9 we remove direct gpio_chip registration in > > favor of the i8255 library registration via gpio_regmap. It doesn't look > > like gpio_regmap_register() sets the init_hw() callback. > > > > Michael, do you see any issues if I introduce init_hw() to > > gpio_regmap_config? Or do you think this IRQ initialization belongs > > somewhere else? > > Something like the following? > gpiochip->init_hw = config.irq_init_hw; > > gpiochip doesn't seem to be the correct place, gpiochip_add_irqchip() > is a noop for gpio-regmap, right? So using gpiochip_irqchip_init_hw() > seems wrong. > > Maybe make gpio-regmap call it on its own? But really we just connect > the regmap-irq to the gpiochip irqdomain. What is the purpose of the > .init_hw callback? I've looked at other drivers which use regmap-irq > and they all seem to just initialize the hardware in their _probe(). The purpose of that callback is to initialize IRQ part of the GPIO hardware in the appropriate point of time. Of course there are drivers that are using it and it's not in their ->probe():s, however you can tell that in the same flow, because it's called synchronously. -- With Best Regards, Andy Shevchenko