lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 27 Nov 2014 11:28:20 +0800
From:	ethan zhao <ethan.zhao@...cle.com>
To:	Dirk Brandewie <dirk.brandewie@...il.com>
CC:	linda.knippers@...com, viresh.kumar@...aro.org, rjw@...ysocki.net,
	corbet@....net, dirk.j.brandewie@...el.com,
	linux-doc@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, ethan.kernel@...il.com
Subject: Re: [PATCH 1/2 v3] intel_pstate: skip this driver if Sun server has
 _PPC method

Dirk,

On 2014/11/25 22:57, Dirk Brandewie wrote:
> On 11/24/2014 08:59 PM, Ethan Zhao wrote:
>> Oracle Sun X86 servers have dynamic power capping capability that 
>> works via
>> ACPI _PPC method etc, so skip loading this driver if Sun server has 
>> ACPI _PPC
>> enabled.
>>
>
> How about this patch? only compile tested.
>
> diff --git a/drivers/cpufreq/intel_pstate.c 
> b/drivers/cpufreq/intel_pstate.c
> index 3468387..db7b8b2 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1025,15 +1025,46 @@ static bool intel_pstate_no_acpi_pss(void)
>      return true;
>  }
>
> +static bool intel_pstate_has_acpi_ppc(void)
> +{
> +    int i;
> +
> +    for_each_possible_cpu(i) {
> +        struct acpi_processor *pr = per_cpu(processors, i);
> +
> +        if (!pr)
> +            continue;
> +        if (acpi_has_method(pr->handle, "_PPC"))
> +            return true;
> +    }
> +    return false;
> +}
> +
> +enum {
> +    PSS,
> +    PCC,
> +};
> +
>  struct hw_vendor_info {
>      u16  valid;
>      char oem_id[ACPI_OEM_ID_SIZE];
>      char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> +    int  oem_pwr_table;
>  };
>
>  /* Hardware vendor-specific info that has its own power management 
> modes */
>  static struct hw_vendor_info vendor_info[] = {
> -    {1, "HP    ", "ProLiant"},
> +    {1, "HP    ", "ProLiant", PSS},
> +    {1, "ORACLE", "X4-2    ", PCC},
> +    {1, "ORACLE", "X4-2L   ", PCC},
> +    {1, "ORACLE", "X4-2B   ", PCC},
> +    {1, "ORACLE", "X3-2    ", PCC},
> +    {1, "ORACLE", "X3-2L   ", PCC},
> +    {1, "ORACLE", "X3-2B   ", PCC},
> +    {1, "ORACLE", "X4470M2 ", PCC},
> +    {1, "ORACLE", "X4270M3 ", PCC},
> +    {1, "ORACLE", "X4270M2 ", PCC},
> +    {1, "ORACLE", "X4170M2 ", PCC},
   But if someone would append line here and...
     +    {1, "VENDOR","XXXIX", PPC},
> {0, "", ""},
>  };
>
> @@ -1057,15 +1088,20 @@ static bool 
> intel_pstate_platform_pwr_mgmt_exists(void)
>
>      for (v_info = vendor_info; v_info->valid; v_info++) {
>          if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
> -            !strncmp(hdr.oem_table_id, v_info->oem_table_id, 
> ACPI_OEM_TABLE_ID_SIZE) &&
> -            intel_pstate_no_acpi_pss())
> -            return true;
> +            !strncmp(hdr.oem_table_id, v_info->oem_table_id, 
> ACPI_OEM_TABLE_ID_SIZE))
> +            switch (v_info->oem_pwr_table) {
> +            case PSS:
> +                return intel_pstate_no_acpi_pss();
> +            case PCC:
> +                return intel_pstate_has_acpi_ppc();
   All good till append the force loading parameter here, looks ugly if 
someone would add one line to vendor_info[] as above.

                       return intel_pstate_has_acpi_ppc() & (!load_on_sun);

Any idea ?

Thanks,
Ethan


> + }
>      }
>
>      return false;
>  }
>  #else /* CONFIG_ACPI not enabled */
>  static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { 
> return false; }
> +static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
>  #endif /* CONFIG_ACPI */
>
>  static int __init intel_pstate_init(void)
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ