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 F2E82C4332F for ; Wed, 19 Oct 2022 11:52:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230032AbiJSLwD (ORCPT ); Wed, 19 Oct 2022 07:52:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231667AbiJSLvr (ORCPT ); Wed, 19 Oct 2022 07:51:47 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B4FE112AA4 for ; Wed, 19 Oct 2022 04:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666179009; x=1697715009; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=4YcfoLble85KQpMkw8dEMj5Q0sVuTa7xH+2uJMHUuQs=; b=mHBf27CxL2X00X4FaCNJutSOUtH54dbHAta6qoa4g4CcN5H3A8MXF1hh OY2Q2GoUTw8vnbolmr8LChT5hCFS109dbk0zIDgYV5oTsqNpdHbsTmKTL J+yPamsMU8sGv9DhuK6ohf82m+Ub49Kmo9qHcfoPBerrd8O7ZllB0/igl MTkckLvjTHa+hu2NFo1L2mhgwfPzgRnTD7BXxzfmrUk9TwIqJlsFUMCtn W6Cm/QKL3W76wQmeoS5jNO5eP9FmVCI8v8YvWIXo/JPGKVq9DnWp2tWyn Wv92RstLs1oT7e61vfvU0Rzx7+OepVJDwwcrhFuzmS3xpzjv5hM2CRUXk g==; X-IronPort-AV: E=McAfee;i="6500,9779,10504"; a="286099416" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="286099416" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 04:29:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10504"; a="624091750" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="624091750" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 19 Oct 2022 04:29:01 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1ol7Fq-009pYJ-3B; Wed, 19 Oct 2022 14:28:58 +0300 Date: Wed, 19 Oct 2022 14:28:58 +0300 From: Andy Shevchenko To: =?iso-8859-1?B?Uul26XN6LA==?= Levente Cc: Martyn Welch , Nate Drude , Haibo Chen , Puyou Lu , Justin Chen , Andrey Gusakov , Peter Robinson , Bartosz Golaszewski , "linux-gpio@vger.kernel.org" , Linus Walleij Subject: Re: [PATCH 0/2] gpio: pca953x: Add interrupt mask support for pca953x chips Message-ID: References: <20221010132007.924810-1-levente.revesz@eilabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Wed, Oct 19, 2022 at 10:15:01AM +0000, Révész, Levente wrote: > On Monday, October 17, 2022 7:31 PM, Andy Shevchenko wrote: > > At first glance I think this needs two prerequisite patches: > > > > 1) convert _TYPE from bits to plain numbers, so we will have room > > for up to 16 types; > > > > 2) Introducing PCAL953X_TYPE. > > > > After this is done, the current series will be neater. > > Thanks for the suggestions! > > I have started implementing this change: > > * Convert _TYPE from bits to 4 bit integer > > * Define 4 chip types: PCA953X_TYPE, PCAL953X_TYPE, > PCAL653X_TYPE, PCA957X_TYPE > > The PCA_PCAL bit is redundant, we know which chip is PCAL from their > chip type. Remove the PCA_PCAL bit and the PCA_LATCH_INT mask. Sounds good. > The now modified bits were also used in the acpi_device_id > initialization: > > static const struct acpi_device_id pca953x_acpi_ids[] = { > { "INT3491", 16 | PCA953X_TYPE | PCA_LATCH_INT, }, > { } > }; > MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids); I do not see any modifications in the above. > I do not understand what is happening in this snippet. > What should be the id? INT3491 is the ID. The chip behind is (usually) PCAL9555. In the cases when it's not, there is no associated interrupt line in the ACPI tables, so it won't hurt, however it's not the best solution made that time. -- With Best Regards, Andy Shevchenko