On Monday, July 21, 2014 01:26:10 AM Zheng, Lv wrote: > Hi, Rafael > > > From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx] > > Sent: Sunday, July 20, 2014 7:46 AM > > To: Zheng, Lv > > > > On Wednesday, July 16, 2014 04:58:00 PM Lv Zheng wrote: > > > This patch adds default 64-bit mathematics in aclinux.h using do_div(). As > > > do_div() can be used for all Linux architectures, this can also be used as > > > stub macros for ACPICA 64-bit mathematics. > > > > > > But this is not a performance friendly way, as ACPICA's architecture > > > specific division OSL only requires a dividing 64-bit number with a 32-bit > > > number implementation, while Linux __div64_32() is not available for all > > > build environments. So currently, if an architecture really wants to > > > support ACPICA, it must implement its own division OSL. > > > > What does this mean for i386, in particular? > > All ACPICA environment macros have defaults in actypes.h or acenv.h, these macros are the only ones do not have defaults. > Because their defaults should be provided by OSPMs. > This patch just adds their default implementation for __KERNEL__ surrounded code for Linux kernel. > It only provides build protection and demonstrations of the functionality, no one actually uses it now. > > Let me figure out the possible users below: > > These macros are required by drivers/acpi/utmath.c when ACPI_USE_NATIVE_DIVIDE is not defined. > It is used by ACPICA, so currently this is only meaningful to CONFIG_ACPI builds. > So kernel will not use these macros unless CONFIG_ACPI is defined and ACPI_USE_DIVIDE is not defined. > > For 64-bit kernels: > In include/acpi/actypes.h, for ACPI_MACHINE_WIDTH=64, ACPI_USE_NATIVE_DIVIDE will be defined, thus these macros are not used. > In include/acpi/platform/aclinux.h, for __KERNEL__ surrounded code, ACPI_MACHINE_WIDTH is defined to be BITS_PER_LONG. > So all 64-bit kernels do not use these macros. > > For 32-bit kernels: > As mentioned above, these macros will be used when BITS_PER_LONG is 32. > Thus currently the i328 kernels are the only users for these macros. > But they won't use this default implementation provided by this patch because: > In arch/x86/include/asm/acenv.h, there are already overrides implemented. > So these default macros are not used by 32-bit x86 (i386) kernels. > > These macros will only be used by future non x86 32-bit architectures that try to support ACPI in Linux kernel. > During the period they do not have arch specific implementations of such macros, we can avoid build errors for them. > And since they can see ACPICA functioning without implementing any arch specific environment tunings, we can also avoid function errors for them. > As this implementation is not performance friendly, those architectures still need to implement real support in the end. > > As a conclusion, IMO: > 1. This default implementation just fill an ACPICA default environment gap. > 1. There are no users and will be no users of this default implementation in the kernel. > 3. Though this default implementation is not performance friendly, it functions correctly, so it can be a demo for future 32-bit architectures that try to support ACPI. > 4. We can use this default implementation to avoid build troubles. Good analysis, thanks! I copied the most useful part of it to the changelog of this patch and queued up the whole series for 3.17. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
