From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lan Tianyu Subject: Re: [PATCH] I2C: Make I2C core able to be module when I2C_ACPI is selected. Date: Wed, 13 Aug 2014 15:22:57 +0800 Message-ID: <53EB1251.1000401@intel.com> References: <1407740455-21269-1-git-send-email-tianyu.lan@intel.com> <20140812095321.GU1657@lahna.fi.intel.com> <20140813020250.GA2853@katana> <53EAD278.2010003@intel.com> <20140813070759.GB1657@lahna.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140813070759.GB1657-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mika Westerberg Cc: Wolfram Sang , torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-i2c@vger.kernel.org On 2014=E5=B9=B408=E6=9C=8813=E6=97=A5 15:07, Mika Westerberg wrote: > On Wed, Aug 13, 2014 at 10:50:32AM +0800, Lan Tianyu wrote: >> On 2014=E5=B9=B408=E6=9C=8813=E6=97=A5 10:03, Wolfram Sang wrote: >>> On Tue, Aug 12, 2014 at 12:53:21PM +0300, Mika Westerberg wrote: >>>> On Mon, Aug 11, 2014 at 03:00:55PM +0800, Lan Tianyu wrote: >>>>> Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I= 2C_ACPI >>>>> config) adds a new kernel config I2C_ACPI and make I2C core built= in >>>>> when the config is selected. This is wrong because distributions >>>>> etc generally compile I2C as a module and the commit broken that. >>>>> This patch is to make I2C core able to be a module when I2C_ACPI = is >>>>> selected. Original issue the commit da3c6647 tried to avoid will >>>>> be fixed in ACPICA and it's rarely triggered during unloading mod= ule.=20 >>>>> >>>>> Signed-off-by: Lan Tianyu >>>> >>>> I wonder if we can do >>>> >>>> depends on I2C=3Dy >>>> >>>> here? If I understand it right, then we only build the ACPI_I2C if= I2C >>>> is compiled into the kernel. That way the problem da3c6647 tried t= o >>>> solve doens't re-appear. >>>> >>>> We can later on relax this once ACPICA has been fixed. Thoughts? >>> >>> I had the same idea yet my travel to Chicago interrupted thinking a= bout >>> it further. Once I get rid of my jetlag, I'll have a closer look. U= nless >>> you already came up with the perfect solution until then, of course= ;) >>> >> >> Hi Mika & Wolfram: >> I have one concern about "depends on I2C=3Dy". If distribution conf= ig >> file selects I2C core as a module, the original code can enumerate I= 2C >> slave devices from ACPI table. But now I2C_ACPI depends on I2C core >> built in, the I2C module can't enumerate devices from ACPI table. Th= is >> maybe a regression for distribution? >=20 > True, but only the I2C OpRegion parts needs to have I2C=3Dy. Does it = make > sense to name ACPI_I2C to ACPI_I2C_OPREGION (or something like that) > and only enable it when I2C=3Dy? Then we would have ACPI I2C enumerat= ion > still in place. >=20 Yes, this makes sense to me. I will rewrite the patch. --=20 Best regards Tianyu Lan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbaHMH0P (ORCPT ); Wed, 13 Aug 2014 03:26:15 -0400 Received: from mga09.intel.com ([134.134.136.24]:51236 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743AbaHMH0N (ORCPT ); Wed, 13 Aug 2014 03:26:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,855,1400050800"; d="scan'208";a="557857661" Message-ID: <53EB1251.1000401@intel.com> Date: Wed, 13 Aug 2014 15:22:57 +0800 From: Lan Tianyu User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mika Westerberg CC: Wolfram Sang , torvalds@linux-foundation.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] I2C: Make I2C core able to be module when I2C_ACPI is selected. References: <1407740455-21269-1-git-send-email-tianyu.lan@intel.com> <20140812095321.GU1657@lahna.fi.intel.com> <20140813020250.GA2853@katana> <53EAD278.2010003@intel.com> <20140813070759.GB1657@lahna.fi.intel.com> In-Reply-To: <20140813070759.GB1657@lahna.fi.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2014年08月13日 15:07, Mika Westerberg wrote: > On Wed, Aug 13, 2014 at 10:50:32AM +0800, Lan Tianyu wrote: >> On 2014年08月13日 10:03, Wolfram Sang wrote: >>> On Tue, Aug 12, 2014 at 12:53:21PM +0300, Mika Westerberg wrote: >>>> On Mon, Aug 11, 2014 at 03:00:55PM +0800, Lan Tianyu wrote: >>>>> Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI >>>>> config) adds a new kernel config I2C_ACPI and make I2C core built in >>>>> when the config is selected. This is wrong because distributions >>>>> etc generally compile I2C as a module and the commit broken that. >>>>> This patch is to make I2C core able to be a module when I2C_ACPI is >>>>> selected. Original issue the commit da3c6647 tried to avoid will >>>>> be fixed in ACPICA and it's rarely triggered during unloading module. >>>>> >>>>> Signed-off-by: Lan Tianyu >>>> >>>> I wonder if we can do >>>> >>>> depends on I2C=y >>>> >>>> here? If I understand it right, then we only build the ACPI_I2C if I2C >>>> is compiled into the kernel. That way the problem da3c6647 tried to >>>> solve doens't re-appear. >>>> >>>> We can later on relax this once ACPICA has been fixed. Thoughts? >>> >>> I had the same idea yet my travel to Chicago interrupted thinking about >>> it further. Once I get rid of my jetlag, I'll have a closer look. Unless >>> you already came up with the perfect solution until then, of course ;) >>> >> >> Hi Mika & Wolfram: >> I have one concern about "depends on I2C=y". If distribution config >> file selects I2C core as a module, the original code can enumerate I2C >> slave devices from ACPI table. But now I2C_ACPI depends on I2C core >> built in, the I2C module can't enumerate devices from ACPI table. This >> maybe a regression for distribution? > > True, but only the I2C OpRegion parts needs to have I2C=y. Does it make > sense to name ACPI_I2C to ACPI_I2C_OPREGION (or something like that) > and only enable it when I2C=y? Then we would have ACPI I2C enumeration > still in place. > Yes, this makes sense to me. I will rewrite the patch. -- Best regards Tianyu Lan