From patchwork Mon Oct 28 13:15:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jarkko Nikula X-Patchwork-Id: 286514 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 866CE2C008C for ; Tue, 29 Oct 2013 00:15:31 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756164Ab3J1NP3 (ORCPT ); Mon, 28 Oct 2013 09:15:29 -0400 Received: from mga02.intel.com ([134.134.136.20]:38066 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752050Ab3J1NP2 (ORCPT ); Mon, 28 Oct 2013 09:15:28 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Oct 2013 06:15:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,535,1378882800"; d="scan'208";a="399852577" Received: from mylly.fi.intel.com (HELO [10.237.72.53]) ([10.237.72.53]) by orsmga001.jf.intel.com with ESMTP; 28 Oct 2013 06:15:26 -0700 Message-ID: <526E636D.3070005@linux.intel.com> Date: Mon, 28 Oct 2013 15:15:25 +0200 From: Jarkko Nikula User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: "Rafael J. Wysocki" CC: Mark Brown , Wolfram Sang , linux-spi@vger.kernel.org, linux-i2c@vger.kernel.org, alsa-devel@alsa-project.org, linux-acpi@vger.kernel.org Subject: Re: [RFC 1/2] i2c: Use stable dev_name for ACPI enumerated I2C slaves References: <1382703540-3769-1-git-send-email-jarkko.nikula@linux.intel.com> <98785510.yWYAtabkbj@vostro.rjw.lan> <526A726F.1030407@linux.intel.com> <2889412.bEKBLJtgSW@vostro.rjw.lan> In-Reply-To: <2889412.bEKBLJtgSW@vostro.rjw.lan> Sender: linux-i2c-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Hi Rafael On 10/25/2013 05:08 PM, Rafael J. Wysocki wrote: > On Friday, October 25, 2013 04:30:23 PM Jarkko Nikula wrote: >>> >> Hmm, not only. Referencing to dev field in struct acpi_device by >> dev_name(&adev->dev) here will fail too. > > Well, something is not quite right here. > > One of the *reasons* for having ACPI_HANDLE() defined this way is to > avoid using explicit CONFIG_ACPI checks, so if that doesn't work, > then all of that becomes a bit pointless. > One possible thing to do is to let structure definitions to be available for non-ACPI builds. Then compiler won't fail on structure access which will be anyway optimized away by later compiler stages. With a quick test below vmlinux section sizes don't change for couple non-ACPI build tests and allow to get rid off IS_ENABLED(CONFIG_ACPI) test in this patch. It's very minimal as it only moves the CONFIG_ACPI test just after the struct acpi_device definition and defines acpi_bus_get_device for non-ACPI case. What I don't know how consistent it is as there are still couple structure definitions under CONFIG_ACPI, doesn't touch other acpi headers and requires to include acpi_bus.h in driver (or move acpi_bus.h include in linux/acpi.h currently under CONFIG_ACPI). diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index d901982..7ab7870 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -66,8 +66,6 @@ bool acpi_ata_match(acpi_handle handle); bool acpi_bay_match(acpi_handle handle); bool acpi_dock_match(acpi_handle handle); -#ifdef CONFIG_ACPI - #include #define ACPI_BUS_FILE_ROOT "acpi" @@ -314,6 +312,8 @@ struct acpi_device { void (*remove)(struct acpi_device *); }; +#if IS_ENABLED(CONFIG_ACPI) + static inline void *acpi_driver_data(struct acpi_device *d) { return d->driver_data; @@ -531,6 +531,8 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev) static inline int register_acpi_bus_type(void *bus) { return 0; } static inline int unregister_acpi_bus_type(void *bus) { return 0; } +static inline int acpi_bus_get_device(acpi_handle handle, + struct acpi_device **device) { return 0; } #endif /* CONFIG_ACPI */