From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3BA9D7763F; Thu, 21 Dec 2023 13:42:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JrbMBzzc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703166145; x=1734702145; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=R6miQeV/VuHmO5eVyMe/230bW5y4XCSTO7Hh0DdH/iE=; b=JrbMBzzc/E5CHeIzx3cD96HPDfSc1DQ80FRltqNSJqd+X03HHFokZnU4 R64hilneFtKx2EyHIBCPZGlVTSBVfH4FgxJZNiKInmIFbsDYShj04Bp6G jxeecy/v08PLK1iHS/FjXDh0YIYfOxPsfQK79B7UdflmYDLbz4xjTvnNh rQGZT48BpqM3bp1eTFqrud7LRxyDXGl2Smt/KUj7S3C09x4c/azUuuZI0 R+s1IU2olMsP6ImxWj8syY3ameFaJgMs03QmWfMDIbZJU6bRV60E13gQT ugeRY2gJgUwLWv59Pnre1C69yEsz8l/vCamvcNg6XOSZ7Yl/Yc5tXpLJC Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10930"; a="393141727" X-IronPort-AV: E=Sophos;i="6.04,293,1695711600"; d="scan'208";a="393141727" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Dec 2023 05:42:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10930"; a="776707125" X-IronPort-AV: E=Sophos;i="6.04,293,1695711600"; d="scan'208";a="776707125" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Dec 2023 05:42:20 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1rGJJa-00000007rYy-0CnL; Thu, 21 Dec 2023 15:42:18 +0200 Date: Thu, 21 Dec 2023 15:42:17 +0200 From: Andy Shevchenko To: Mark Hasemeyer Cc: LKML , chrome-platform@lists.linux.dev, cros-qcom-dts-watchers@chromium.org, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH v2 00/22] Improve IRQ wake capability reporting and update the cros_ec driver to use it Message-ID: References: <20231220235459.2965548-1-markhas@chromium.org> Precedence: bulk X-Mailing-List: linux-i2c@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Wed, Dec 20, 2023 at 04:54:14PM -0700, Mark Hasemeyer wrote: > Currently the cros_ec driver assumes that its associated interrupt is > wake capable. This is an incorrect assumption as some Chromebooks use a > separate wake pin, while others overload the interrupt for wake and IO. > This patch train updates the driver to query the underlying ACPI/DT data > to determine whether or not the IRQ should be enabled for wake. > > Both the device tree and ACPI systems have methods for reporting IRQ > wake capability. In device tree based systems, a node can advertise > itself as a 'wakeup-source'. In ACPI based systems, GpioInt and > Interrupt resource descriptors can use the 'SharedAndWake' or > 'ExclusiveAndWake' share types. > > Some logic is added to the platform, ACPI, and DT subsystems to more > easily pipe wakeirq information up to the driver. Just wondering if you used --histogram diff algo when preparing patches. -- With Best Regards, Andy Shevchenko