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.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5DA49C5517A for ; Wed, 11 Nov 2020 12:18:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 10166206FB for ; Wed, 11 Nov 2020 12:18:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726541AbgKKMSA (ORCPT ); Wed, 11 Nov 2020 07:18:00 -0500 Received: from mga17.intel.com ([192.55.52.151]:6097 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbgKKMQF (ORCPT ); Wed, 11 Nov 2020 07:16:05 -0500 IronPort-SDR: if+ilNbfvERO7DguXrCdYqWD3FXFIIZEYXRld43cPevjgRsfLe7rAEjJpAmKotthxieCZOrRRu m6Pd56CqeiXA== X-IronPort-AV: E=McAfee;i="6000,8403,9801"; a="149984855" X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="149984855" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 04:15:29 -0800 IronPort-SDR: P0pxOyGYOJXKe5WjlCj0CoXCOjRax99APokYTyNSKuPFTrHrvLEVn0MYLxrN2Co+5fOKc4Am2B nM6KIiM7rTug== X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="541768713" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 04:15:27 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1kcp37-005u0W-C7; Wed, 11 Nov 2020 14:16:29 +0200 Date: Wed, 11 Nov 2020 14:16:29 +0200 From: Andy Shevchenko To: Evan Green Cc: Andy Shevchenko , "stable@vger.kernel.org" , Linus Walleij , Mika Westerberg , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] pinctrl: intel: Fix Jasperlake hostown offset Message-ID: <20201111121629.GL4077@smile.fi.intel.com> References: <20201110144932.1.I54a30ec0a7eb1f1b791dc9d08d5e8416a1e8e1ef@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 Tue, Nov 10, 2020 at 04:03:57PM -0800, Evan Green wrote: > On Tue, Nov 10, 2020 at 3:48 PM Andy Shevchenko > wrote: > > On Wednesday, November 11, 2020, Evan Green wrote: > >> > >> GPIOs that attempt to use interrupts get thwarted with a message like: > >> "pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because > >> the JSL_HOSTSW_OWN offset is incorrect, so every GPIO looks like it's > >> owned by ACPI. > > > > > > Funny, I have created a similar patch few hours ago. Are you sure this is enough? In mine I have also padcfglock updated. But I have to confirm that, that’s why I didn’t send it out. > > Oh weird! I didn't check padcfglock since it didn't happen to be > involved in the bug I was tracking down. I was trying to clean out > some skeletons in my kernel closet [1] and debugged it down to this. > > If you want to smash the two patches together I'm fine with that. Let > me know, and CC me if you do post something. Can you test that 0x90 is correct value for padcfglock offset? > [1] https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/master/overlay-dedede/sys-kernel/chromeos-kernel-5_4/files/0001-CHROMIUM-pinctrl-intel-Allow-pin-as-IRQ-even-in-ACPI.patch -- With Best Regards, Andy Shevchenko