[PATCHv3,1/3] ACPI: Provide struct acpi_device stub for !CONFIG_ACPI builds

We have a few cases where we want to access struct device dev field in
struct acpi_device from generic code that is build also without CONFIG_ACPI.

Provide here a minimal struct acpi_device stub that allows to build such a
code without adding new #ifdef CONFIG_ACPI churn. This should not increase
section sizes if code is protected by ACPI_COMPANION() runtime checks as
those will be optimized out by later compiler stages in case CONFIG_ACPI is
not set.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Rafael, instead of this we could also have an accessor but adev->dev looked
better in actual code and size vmlinux didn't change for x86_64_defconfig
with CONFIG_ACPI is not set nor for omap2plus_defconfig.
---
 include/linux/acpi.h | 4 ++++
 1 file changed, 4 insertions(+)

At Thu, 14 Nov 2013 11:00:59 +0200,
Jarkko Nikula wrote:
> 
> We have a few cases where we want to access struct device dev field in
> struct acpi_device from generic code that is build also without CONFIG_ACPI.
> 
> Provide here a minimal struct acpi_device stub that allows to build such a
> code without adding new #ifdef CONFIG_ACPI churn. This should not increase
> section sizes if code is protected by ACPI_COMPANION() runtime checks as
> those will be optimized out by later compiler stages in case CONFIG_ACPI is
> not set.
> 
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> ---
> Rafael, instead of this we could also have an accessor but adev->dev looked
> better in actual code and size vmlinux didn't change for x86_64_defconfig
> with CONFIG_ACPI is not set nor for omap2plus_defconfig.

This looks too hackish, IMO.  Defining a different dummy struct often
gives more headaches.  Thinking of the potential risk by misuses, it'd
be simpler and safer to define a macro like acpi_dev_name() instead.

BTW, is linux/device.h already included in !CONFIG_ACPI case?


Takashi

> ---
>  include/linux/acpi.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 0da49ed..df444e1 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -414,6 +414,10 @@ static inline bool acpi_driver_match_device(struct device *dev,
>  
>  #else	/* !CONFIG_ACPI */
>  
> +struct acpi_device {
> +	struct device dev;
> +};
> +
>  #define acpi_disabled 1
>  
>  #define ACPI_COMPANION(dev)		(NULL)
> -- 
> 1.8.4.2
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 11/14/2013 12:03 PM, Takashi Iwai wrote:
> At Thu, 14 Nov 2013 11:00:59 +0200,
> Jarkko Nikula wrote:
>> We have a few cases where we want to access struct device dev field in
>> struct acpi_device from generic code that is build also without CONFIG_ACPI.
>>
>> Provide here a minimal struct acpi_device stub that allows to build such a
>> code without adding new #ifdef CONFIG_ACPI churn. This should not increase
>> section sizes if code is protected by ACPI_COMPANION() runtime checks as
>> those will be optimized out by later compiler stages in case CONFIG_ACPI is
>> not set.
>>
>> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
>> ---
>> Rafael, instead of this we could also have an accessor but adev->dev looked
>> better in actual code and size vmlinux didn't change for x86_64_defconfig
>> with CONFIG_ACPI is not set nor for omap2plus_defconfig.
> This looks too hackish, IMO.  Defining a different dummy struct often
> gives more headaches.  Thinking of the potential risk by misuses, it'd
> be simpler and safer to define a macro like acpi_dev_name() instead.
>
> BTW, is linux/device.h already included in !CONFIG_ACPI case?
>
It is included unconditionally in include/linux/acpi.h.

Your acpi_dev_name() proposal may be good enough for now as adev->dev 
access in generic code (now under CONFIG_ACPI) seems to be anyway around 
dev_name, using only pointer to struct acpi_device or has more things 
that prevents immediate #ifdef CONFIG_ACPI removal there.

But one problem at time. I'll cook a version with acpi_dev_name.