All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cedric Le Goater <clg@fr.ibm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
	lm-sensors@lm-sensors.org,
	Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
	skiboot@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org,
	Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels
Date: Tue, 07 Apr 2015 20:03:46 +0200	[thread overview]
Message-ID: <55241C02.60103@fr.ibm.com> (raw)
In-Reply-To: <20150407164439.GA4514@roeck-us.net>

Hello Guenter,

On 04/07/2015 06:44 PM, Guenter Roeck wrote:
> On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical 
>> identifier of the core in the "ibm,pir" property. The driver 
>> translates this identifier in a linux cpu number and prints out a 
>> range corresponding to the hardware threads of the core (as they
>> share the same sensor).
>>
>> The numbering gives a hint on the localization of the core in the 
>> system (which socket, which chip). 
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> Please do not send follow-up patches as reply, but as separate e-mail.

Ok. I will start a new thread when I resend this patch.

> Further comments below.
> 
>> ---
>>
>>  Changes since v1:
>>
>>  - check cpu validity before printing out the attribute label. 
>>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>>    number from a physical cpu number. 
>>
>>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> Index: linux.git/drivers/hwmon/ibmpowernv.c
>> ===================================================================
>> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
>> +++ linux.git/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>>  static void __init make_sensor_label(struct device_node *np,
>>  		    struct sensor_data *sdata, const char *label)
>>  {
>> +	u32 id;
>>  	size_t n;
>>  
>>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +	/*
>> +	 * Core temp pretty print
>> +	 */
>> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +		int i = -1;
>> +
>> +		for_each_possible_cpu(i)
>> +			if (paca[i].hw_cpu_id == id)
> 
> I think you should consider using get_hard_smp_processor_id() and avoid
> direct access to the paca array.

Yes. It will look better. Thanks.

>> +				break;
>> +
>> +		if (i != -1)
> 
> I don't think that works. i is initialized by for_each_possible_cpu(),
> either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
> it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).
> 
> You would need a second variable (which you could pre-initialize)
> to determine if the code found a matching ID or not.

gloups. I did that patch waaaay too quickly, it is completely bogus ... 
I will cook a new version. sorry for the noise. 

>> +			/*
>> +			 * The digital thermal sensors are associated
>> +			 * with a core. Let's print out the range of
>> +			 * cpu ids corresponding to the hardware
>> +			 * threads of the core.
>> +			 */
>> +			n += snprintf(sdata->label + n,
>> +				      sizeof(sdata->label) - n,
>> +				      " %d-%d", i, i+7);
> 
> I would really like to see how this looks like in practice.
> 
> The id in the devicetree entry is the physical CPU. The resulting index
> is the logical CPU number. So let's assume that the logical CPU number
> for the first physical CPU is 0. Output would be "0-7". If the second
> physical CPU matches logical CPU 1, output would be "1-8". 
> How does that make any sense ?

The logical CPU numbers on PowerPC are initialized looping on the cores
found in the device tree and then on the threads of the core. Something 
like :

	logical_cpu = core_index * max_threads_per_core + thread_index 

which gives on a P8  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3*    4*    5*    6*    7* 
	Core   1:    8*    9*   10*   11*   12*   13*   14*   15* 
	Core   2:   16*   17*   18*   19*   20*   21*   22*   23* 
	Core   3:   24*   25*   26*   27*   28*   29*   30*   31* 
	Core   4:   32*   33*   34*   35*   36*   37*   38*   39* 
	Core   5:   40*   41*   42*   43*   44*   45*   46*   47* 
	Core   6:   48*   49*   50*   51*   52*   53*   54*   55* 
	Core   7:   56*   57*   58*   59*   60*   61*   62*   63* 
	Core   8:   64*   65*   66*   67*   68*   69*   70*   71* 
	Core   9:   72*   73*   74*   75*   76*   77*   78*   79* 
	Core  10:   80*   81*   82*   83*   84*   85*   86*   87* 
	Core  11:   88*   89*   90*   91*   92*   93*   94*   95* 
	Core  12:   96*   97*   98*   99*  100*  101*  102*  103* 
	Core  13:  104*  105*  106*  107*  108*  109*  110*  111* 
	Core  14:  112*  113*  114*  115*  116*  117*  118*  119* 
	Core  15:  120*  121*  122*  123*  124*  125*  126*  127* 
	Core  16:  128*  129*  130*  131*  132*  133*  134*  135* 
	Core  17:  136*  137*  138*  139*  140*  141*  142*  143* 
	Core  18:  144*  145*  146*  147*  148*  149*  150*  151* 
	Core  19:  152*  153*  154*  155*  156*  157*  158*  159* 

on a P7  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3* 
	Core   1:    4*    5*    6*    7* 
	Core   2:    8*    9*   10*   11* 
	Core   3:   12*   13*   14*   15* 
	Core   4:   16*   17*   18*   19* 
	Core   5:   20*   21*   22*   23* 


> Also, how do you know that the range of CPU IDs is always 8 ?

This is a shortcut. The code is for the ibmpowernv platform and assumes 
that we are running on a P8 (8 hardware threads). It would be better to 
use a "maximum threads per core" variable but I am not sure this is 
available, as it is a tunable. I will look into it.

> Can you provide some resulting outputs ?

sure. 

On an Open Power system : 

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	Core 8-15:    +29.0°C  
	Core 16-23:   +29.0°C  
	Core 24-31:   +30.0°C  
	Core 32-39:   +30.0°C  
	Core 40-47:   +32.0°C  
	Core 48-55:   +29.0°C  
	Core 56-63:   +29.0°C  
	Centaur 0:    +28.0°C  
	Centaur 1:    +32.0°C  
	Centaur 4:    +28.0°C  
	Centaur 5:    +27.0°C  
	Core 0-7:     +29.0°C  

The Centaur numbering does not look as good as for the core.

On an IBM Power system :

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	fan1:         5960 RPM  (min =    0 RPM)
	fan2:         5252 RPM  (min =    0 RPM)
	fan3:         5960 RPM  (min =    0 RPM)
	fan4:         5242 RPM  (min =    0 RPM)
	fan5:         5008 RPM  (min =    0 RPM)
	fan6:         5000 RPM  (min =    0 RPM)
	fan7:         5232 RPM  (min =    0 RPM)
	fan8:         5986 RPM  (min =    0 RPM)
	fan9:         5232 RPM  (min =    0 RPM)
	fan10:        6094 RPM  (min =    0 RPM)
	fan11:        5242 RPM  (min =    0 RPM)
	fan12:        5882 RPM  (min =    0 RPM)
	fan13:        5212 RPM  (min =    0 RPM)
	fan14:        5973 RPM  (min =    0 RPM)
	Ambient:       +18.0°C  (high =  +0.0°C)
	Core 0-7:      +40.0°C  
	Core 8-15:     +39.0°C  
	Core 16-23:    +39.0°C  
	Core 24-31:    +38.0°C  
	Core 32-39:    +38.0°C  
	Core 40-47:    +37.0°C  
	Core 48-55:    +37.0°C  
	Core 56-63:    +38.0°C  
	Core 64-71:    +38.0°C  
	Core 72-79:    +39.0°C  
	Core 80-87:    +35.0°C  
	Core 88-95:    +34.0°C  
	Core 96-103:   +33.0°C  
	Core 104-111:  +34.0°C  
	Core 112-119:  +33.0°C  
	Core 120-127:  +31.0°C  
	Core 128-135:  +31.0°C  
	Core 136-143:  +39.0°C  
	Core 144-151:  +39.0°C  
	Core 152-159:  +40.0°C  
	power1:       425.00 W  

The Centaur are not exposed yet.

Thanks,

C.

WARNING: multiple messages have this Message-ID (diff)
From: Cedric Le Goater <clg@fr.ibm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
	lm-sensors@lm-sensors.org,
	Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
	skiboot@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org,
	Jean Delvare <jdelvare@suse.de>
Subject: Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels
Date: Tue, 07 Apr 2015 18:03:46 +0000	[thread overview]
Message-ID: <55241C02.60103@fr.ibm.com> (raw)
In-Reply-To: <20150407164439.GA4514@roeck-us.net>

Hello Guenter,

On 04/07/2015 06:44 PM, Guenter Roeck wrote:
> On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical 
>> identifier of the core in the "ibm,pir" property. The driver 
>> translates this identifier in a linux cpu number and prints out a 
>> range corresponding to the hardware threads of the core (as they
>> share the same sensor).
>>
>> The numbering gives a hint on the localization of the core in the 
>> system (which socket, which chip). 
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> Please do not send follow-up patches as reply, but as separate e-mail.

Ok. I will start a new thread when I resend this patch.

> Further comments below.
> 
>> ---
>>
>>  Changes since v1:
>>
>>  - check cpu validity before printing out the attribute label. 
>>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>>    number from a physical cpu number. 
>>
>>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> Index: linux.git/drivers/hwmon/ibmpowernv.c
>> ===================================================================
>> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
>> +++ linux.git/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>>  static void __init make_sensor_label(struct device_node *np,
>>  		    struct sensor_data *sdata, const char *label)
>>  {
>> +	u32 id;
>>  	size_t n;
>>  
>>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +	/*
>> +	 * Core temp pretty print
>> +	 */
>> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +		int i = -1;
>> +
>> +		for_each_possible_cpu(i)
>> +			if (paca[i].hw_cpu_id == id)
> 
> I think you should consider using get_hard_smp_processor_id() and avoid
> direct access to the paca array.

Yes. It will look better. Thanks.

>> +				break;
>> +
>> +		if (i != -1)
> 
> I don't think that works. i is initialized by for_each_possible_cpu(),
> either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
> it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).
> 
> You would need a second variable (which you could pre-initialize)
> to determine if the code found a matching ID or not.

gloups. I did that patch waaaay too quickly, it is completely bogus ... 
I will cook a new version. sorry for the noise. 

>> +			/*
>> +			 * The digital thermal sensors are associated
>> +			 * with a core. Let's print out the range of
>> +			 * cpu ids corresponding to the hardware
>> +			 * threads of the core.
>> +			 */
>> +			n += snprintf(sdata->label + n,
>> +				      sizeof(sdata->label) - n,
>> +				      " %d-%d", i, i+7);
> 
> I would really like to see how this looks like in practice.
> 
> The id in the devicetree entry is the physical CPU. The resulting index
> is the logical CPU number. So let's assume that the logical CPU number
> for the first physical CPU is 0. Output would be "0-7". If the second
> physical CPU matches logical CPU 1, output would be "1-8". 
> How does that make any sense ?

The logical CPU numbers on PowerPC are initialized looping on the cores
found in the device tree and then on the threads of the core. Something 
like :

	logical_cpu = core_index * max_threads_per_core + thread_index 

which gives on a P8  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3*    4*    5*    6*    7* 
	Core   1:    8*    9*   10*   11*   12*   13*   14*   15* 
	Core   2:   16*   17*   18*   19*   20*   21*   22*   23* 
	Core   3:   24*   25*   26*   27*   28*   29*   30*   31* 
	Core   4:   32*   33*   34*   35*   36*   37*   38*   39* 
	Core   5:   40*   41*   42*   43*   44*   45*   46*   47* 
	Core   6:   48*   49*   50*   51*   52*   53*   54*   55* 
	Core   7:   56*   57*   58*   59*   60*   61*   62*   63* 
	Core   8:   64*   65*   66*   67*   68*   69*   70*   71* 
	Core   9:   72*   73*   74*   75*   76*   77*   78*   79* 
	Core  10:   80*   81*   82*   83*   84*   85*   86*   87* 
	Core  11:   88*   89*   90*   91*   92*   93*   94*   95* 
	Core  12:   96*   97*   98*   99*  100*  101*  102*  103* 
	Core  13:  104*  105*  106*  107*  108*  109*  110*  111* 
	Core  14:  112*  113*  114*  115*  116*  117*  118*  119* 
	Core  15:  120*  121*  122*  123*  124*  125*  126*  127* 
	Core  16:  128*  129*  130*  131*  132*  133*  134*  135* 
	Core  17:  136*  137*  138*  139*  140*  141*  142*  143* 
	Core  18:  144*  145*  146*  147*  148*  149*  150*  151* 
	Core  19:  152*  153*  154*  155*  156*  157*  158*  159* 

on a P7  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3* 
	Core   1:    4*    5*    6*    7* 
	Core   2:    8*    9*   10*   11* 
	Core   3:   12*   13*   14*   15* 
	Core   4:   16*   17*   18*   19* 
	Core   5:   20*   21*   22*   23* 


> Also, how do you know that the range of CPU IDs is always 8 ?

This is a shortcut. The code is for the ibmpowernv platform and assumes 
that we are running on a P8 (8 hardware threads). It would be better to 
use a "maximum threads per core" variable but I am not sure this is 
available, as it is a tunable. I will look into it.

> Can you provide some resulting outputs ?

sure. 

On an Open Power system : 

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	Core 8-15:    +29.0°C  
	Core 16-23:   +29.0°C  
	Core 24-31:   +30.0°C  
	Core 32-39:   +30.0°C  
	Core 40-47:   +32.0°C  
	Core 48-55:   +29.0°C  
	Core 56-63:   +29.0°C  
	Centaur 0:    +28.0°C  
	Centaur 1:    +32.0°C  
	Centaur 4:    +28.0°C  
	Centaur 5:    +27.0°C  
	Core 0-7:     +29.0°C  

The Centaur numbering does not look as good as for the core.

On an IBM Power system :

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	fan1:         5960 RPM  (min =    0 RPM)
	fan2:         5252 RPM  (min =    0 RPM)
	fan3:         5960 RPM  (min =    0 RPM)
	fan4:         5242 RPM  (min =    0 RPM)
	fan5:         5008 RPM  (min =    0 RPM)
	fan6:         5000 RPM  (min =    0 RPM)
	fan7:         5232 RPM  (min =    0 RPM)
	fan8:         5986 RPM  (min =    0 RPM)
	fan9:         5232 RPM  (min =    0 RPM)
	fan10:        6094 RPM  (min =    0 RPM)
	fan11:        5242 RPM  (min =    0 RPM)
	fan12:        5882 RPM  (min =    0 RPM)
	fan13:        5212 RPM  (min =    0 RPM)
	fan14:        5973 RPM  (min =    0 RPM)
	Ambient:       +18.0°C  (high =  +0.0°C)
	Core 0-7:      +40.0°C  
	Core 8-15:     +39.0°C  
	Core 16-23:    +39.0°C  
	Core 24-31:    +38.0°C  
	Core 32-39:    +38.0°C  
	Core 40-47:    +37.0°C  
	Core 48-55:    +37.0°C  
	Core 56-63:    +38.0°C  
	Core 64-71:    +38.0°C  
	Core 72-79:    +39.0°C  
	Core 80-87:    +35.0°C  
	Core 88-95:    +34.0°C  
	Core 96-103:   +33.0°C  
	Core 104-111:  +34.0°C  
	Core 112-119:  +33.0°C  
	Core 120-127:  +31.0°C  
	Core 128-135:  +31.0°C  
	Core 136-143:  +39.0°C  
	Core 144-151:  +39.0°C  
	Core 152-159:  +40.0°C  
	power1:       425.00 W  

The Centaur are not exposed yet.

Thanks,

C.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2015-04-07 18:04 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1423117857-32759-1-git-send-email-clg@fr.ibm.com>
2015-02-20 15:07 ` [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-02-20 15:07   ` [lm-sensors] " Cédric Le Goater
2015-02-20 16:52   ` Guenter Roeck
2015-02-20 16:52     ` [lm-sensors] " Guenter Roeck
2015-02-20 20:15     ` Cedric Le Goater
2015-02-20 20:15       ` [lm-sensors] " Cedric Le Goater
2015-02-20 23:52       ` Guenter Roeck
2015-02-20 23:52         ` [lm-sensors] " Guenter Roeck
2015-02-21  7:14         ` Cedric Le Goater
2015-02-21  7:14           ` [lm-sensors] " Cedric Le Goater
2015-02-21 11:03           ` Guenter Roeck
2015-02-21 11:03             ` [lm-sensors] " Guenter Roeck
2015-02-23 10:54             ` Cedric Le Goater
2015-02-23 10:54               ` [lm-sensors] " Cedric Le Goater
2015-02-20 15:07 ` [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist Cédric Le Goater
2015-02-20 15:07   ` [lm-sensors] " Cédric Le Goater
2015-02-20 16:53   ` Guenter Roeck
2015-02-20 16:53     ` [lm-sensors] " Guenter Roeck
2015-02-20 20:18     ` Cedric Le Goater
2015-02-20 20:18       ` [lm-sensors] " Cedric Le Goater
2015-02-24  4:54   ` Michael Ellerman
2015-02-24  4:54     ` [lm-sensors] " Michael Ellerman
2015-02-25 17:28     ` Cedric Le Goater
2015-02-25 17:28       ` [lm-sensors] " Cedric Le Goater
2015-02-20 15:07 ` [RFC PATCH 2/3] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Cédric Le Goater
2015-02-20 15:07   ` [lm-sensors] " Cédric Le Goater
2015-02-20 15:07 ` [RFC PATCH 3/3] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-02-20 15:07   ` [lm-sensors] " Cédric Le Goater
2015-03-18 15:47 ` [PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-19  4:05   ` Guenter Roeck
2015-03-19  4:05     ` [lm-sensors] " Guenter Roeck
2015-03-18 15:47 ` [PATCH 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-18 15:47 ` [PATCH 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-18 15:47 ` [PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-19  3:58   ` Guenter Roeck
2015-03-19  3:58     ` [lm-sensors] " Guenter Roeck
2015-03-18 15:47 ` [PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-19  4:02   ` Guenter Roeck
2015-03-19  4:02     ` [lm-sensors] " Guenter Roeck
2015-03-18 15:47 ` [PATCH 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names Cédric Le Goater
2015-03-18 15:47   ` [lm-sensors] " Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-03-20 15:26   ` Guenter Roeck
2015-03-20 15:26     ` [lm-sensors] " Guenter Roeck
2015-03-20 16:52     ` Cedric Le Goater
2015-03-20 16:52       ` [lm-sensors] " Cedric Le Goater
2015-04-01 10:15   ` [PATCH 0/4] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-04-01 10:15     ` [lm-sensors] " Cédric Le Goater
2015-04-01 10:15   ` [PATCH 1/4] hwmon: (ibmpowernv) add a helper routine create_hwmon_attr Cédric Le Goater
2015-04-01 10:15     ` [lm-sensors] " Cédric Le Goater
2015-04-01 10:15   ` [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree Cédric Le Goater
2015-04-01 10:15     ` [lm-sensors] " Cédric Le Goater
2015-04-01 10:15   ` [PATCH 3/4] hwmon: (ibmpowernv) add a label attribute Cédric Le Goater
2015-04-01 10:15     ` [lm-sensors] " Cédric Le Goater
2015-04-01 10:15   ` [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels Cédric Le Goater
2015-04-01 10:15     ` [lm-sensors] " Cédric Le Goater
2015-04-03 15:49     ` Guenter Roeck
2015-04-03 15:49       ` [lm-sensors] " Guenter Roeck
2015-04-07 14:42       ` Cedric Le Goater
2015-04-07 14:42         ` [lm-sensors] " Cedric Le Goater
2015-04-07 14:45         ` Cédric Le Goater
2015-04-07 14:45           ` [lm-sensors] " Cédric Le Goater
2015-04-07 16:44           ` Guenter Roeck
2015-04-07 16:44             ` [lm-sensors] " Guenter Roeck
2015-04-07 18:03             ` Cedric Le Goater [this message]
2015-04-07 18:03               ` Cedric Le Goater
2015-04-07 19:22               ` Guenter Roeck
2015-04-07 19:22                 ` [lm-sensors] " Guenter Roeck
2015-04-08  6:57                 ` Cedric Le Goater
2015-04-08  6:57                   ` [lm-sensors] " Cedric Le Goater
2015-04-07 20:22               ` [Skiboot] " Benjamin Herrenschmidt
2015-04-07 20:22                 ` [lm-sensors] " Benjamin Herrenschmidt
2015-03-19 17:44 ` [PATCH v2 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-03-20  8:06   ` Cedric Le Goater
2015-03-20  8:06     ` [lm-sensors] " Cedric Le Goater
2015-03-20 15:27     ` Guenter Roeck
2015-03-20 15:27       ` [lm-sensors] " Guenter Roeck
2015-03-19 17:44 ` [PATCH v2 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names Cédric Le Goater
2015-03-19 17:44   ` [lm-sensors] " Cédric Le Goater
2015-04-08 15:20 [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree Guenter Roeck
2015-04-08 15:20 ` [lm-sensors] " Guenter Roeck
2015-04-08 16:06 ` Cedric Le Goater
2015-04-08 16:06   ` [lm-sensors] " Cedric Le Goater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55241C02.60103@fr.ibm.com \
    --to=clg@fr.ibm.com \
    --cc=jdelvare@suse.de \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=neelegup@linux.vnet.ibm.com \
    --cc=skiboot@lists.ozlabs.org \
    --cc=stewart@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.