On 04/03/2015 05:49 PM, Guenter Roeck wrote:
> On 04/01/2015 03:15 AM, 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.
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> drivers/hwmon/ibmpowernv.c | 22 ++
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
Hello Guenter,
On 04/07/2015 09:22 PM, Guenter Roeck wrote:
> Hi Cedric,
>
> On Tue, Apr 07, 2015 at 08:03:46PM +0200, Cedric Le Goater wrote:
>>
>> on a P7 :
>>
>> # ppc64_cpu --info
>> Core 0:0*1*2*3*
>> Core
On 04/08/2015 03:26 PM, Guenter Roeck wrote:
> On 04/08/2015 12:00 AM, 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
On 04/08/2015 05:20 PM, Guenter Roeck wrote:
> On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree for sensors has a different layout and uses new
>> property names, for the type and for the handler used to capture the
>> sensor data.
>>
>> This patch modif
On 04/08/2015 07:32 PM, Guenter Roeck wrote:
> On Wed, Apr 08, 2015 at 07:19:46PM +0200, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches extend the ibmpowernv driver to support the new OPAL firmware
>> which now exposes in its device tree the Digital Temperature Sensors of
>> a P8 system.
Hello,
On 05/28/2015 07:25 PM, Neelesh Gupta wrote:
>
>
> On 05/28/2015 06:36 PM, Cyril Bur wrote:
>> Powerpc powernv platforms allow access to certain system flash devices
>> through a firmwarwe interface. This change adds an mtd driver for these
>> flash devices.
>>
>> Minor updates from Jere
Hello Michael,
On 10/28/2014 05:31 AM, Michael Ellerman wrote:
> On Mon, 2014-27-10 at 14:30:06 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote:
>> CC arch/powerpc/mm/slice.o
>> In file included from ../arch/powerpc/mm/slice.c:33:0:
>> ../include/linux/hugetlb.h:141:47: error: expected identifie
Hi Suka,
On 06/26/2014 08:10 AM, Sukadev Bhattiprolu wrote:
> I got the following crash in Open Firmware, on two separate systems
> with recent mainline kernel (3.16.0-rc2). One was a P8 LPAR with no
> changes to kernel and another a Power7 LPAR with some kernel changes
> (24x7 perf counter patche
Hi,
On 09/19/2013 11:41 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King
> ---
> arch/powerpc/kernel/vio.c |
On 11/16/2013 04:32 PM, Russell King - ARM Linux wrote:
> On Fri, Nov 15, 2013 at 05:16:55PM +0100, Cedric Le Goater wrote:
>> The new helper routine dma_set_mask_and_coherent() breaks the
>> initialization of the pseries vio devices which do not have an
>> initial dev->d
Hi,
On 11/20/2013 11:50 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-10-31 at 10:36 +0100, Cédric Le Goater wrote:
>> The "screen" properties : depth, width, height, linebytes need
>> to be converted to the host endian order when read from the device
>> tree.
>>
>> Signed-off-by: Cédric Le Goa
On 11/21/2013 08:57 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-11-21 at 16:45 +0100, Cedric Le Goater wrote:
>>> - fbdev *generally* assume native endian framebuffer, but of course
>>> under qemu today, the adapter will use a big endian frame buffer
>>> apertu
On 11/23/2013 10:04 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2013-11-23 at 18:38 +0100, Cedric Le Goater wrote:
>> So, 32bpp "works" but 16 is broken ... I guess my palette fix is just a lucky
>> hack and I need to dig deeper in fb code to have a better understa
Hi Geoff,
> Do you have these in a git branch somewhere so I can merge and test
> them?
No, sorry, I don't have a public git repo. Let me see how I can fix
that, it might be useful for future patchsets.
Thanks,
C.
___
Linuxppc-dev mailing list
L
Hi Geoff,
>> Do you have these in a git branch somewhere so I can merge and test
>> them?
>
> No, sorry, I don't have a public git repo. Let me see how I can fix
> that, it might be useful for future patchsets.
Please try that :
git pull git://github.com/legoater/linux.git zimage
Th
On 03/21/2014 06:28 PM, Geoff Levand wrote:
> Hi Cédric,
>
> On Thu, 2014-03-20 at 16:09 +0100, Cédric Le Goater wrote:
>> The following patchset adds support for 64bit little endian boot
>> wrapper. It is based on original code from Andrew Tauferner.
>
> I tested this on PS3 (64 bit BE) and fo
Hi Benjamin,
> So I originally applied all 3 last patches of the series as one
> (collapsed them in git) in order to not break bisection.
>
> However, I had to take the series out in the end due to it
> causing this error on some of my test configs:
>
> powerpc64-linux-ld: cannot find arch/power
On 02/11/2015 05:55 AM, Jeremy Kerr wrote:
> For epapr-style boot, we may be little-endian. This change implements
> the proper conversion for fdt*_to_cpu and cpu_to_fdt*. We also need the
> full cpu_to_* and *_to_cpu macros for this.
>
> Signed-off-by: Jeremy Kerr
> Acked-by: Benjamin Herrenschm
On 02/20/2015 05:53 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:
>
> You should explain here why this patch is needed.
Yes. What it does is to check that the firmware exposes the service
this driver is using (OPAL_SENSOR_READ). I will fix it.
Thank
On 02/20/2015 05:52 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches rework the ibmpowernv driver to support the new device
>> tree as proposed by this patchset on the skiboot mailing list :
>>
>> https://lists.ozlabs.org
On 02/21/2015 12:52 AM, Guenter Roeck wrote:
> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>> Hello !
>>>>
>>>> These p
On 02/21/2015 12:03 PM, Guenter Roeck wrote:
> On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
>> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>>>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>>>
On 02/23/2015 12:58 PM, Thomas Haschka wrote:
> Hi everyone,
>
> The current driver linux/drivers/macintosh/therm_adt746x.c does not take the
> HDD BUTTOMSIDE sensor into account. It actually should as the 12" Powerbooks
> and IBooks are build in a way that the airflow cools the harddrive and
>
On 02/24/2015 05:54 AM, Michael Ellerman wrote:
> On Fri, 2015-02-20 at 16:07 +0100, Cédric Le Goater wrote:
>> Signed-off-by: Cédric Le Goater
>> ---
>> arch/powerpc/platforms/powernv/opal-sensor.c |3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/o
On 02/25/2015 10:16 PM, Stewart Smith wrote:
> Cédric Le Goater writes:
>> On Open Power systems, such call fails in OPAL :
>>
>>OPAL: Called with bad token 101 !
>>
>> The check on the OPAL_UNREGISTER_DUMP_REGION call is added for
>> symmetry. I did not see any errors for it.
>
> I've alre
[ ... ]
> @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
>
> sdata[count].id = sensor_id;
> sdata[count].type = type;
> - err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> - sdata[count].na
On 03/20/2015 04:26 PM, Guenter Roeck wrote:
> On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> The current implementation of the driver uses an index for the hwmon
>> attribute which is extracted from the device node name. This index
>> is calculated by the OPAL
On 03/26/2015 12:07 AM, Stewart Smith wrote:
> Cédric Le Goater writes:
>> Currently, when a sensor value is read, the kernel calls OPAL, which in
>> turn builds a message for the FSP, and waits for a message back.
>>
>> The new device tree for OPAL sensors [1] adds new sensors that can be
>> re
On 03/26/2015 10:44 AM, Cedric Le Goater wrote:
> On 03/26/2015 12:07 AM, Stewart Smith wrote:
>> Cédric Le Goater writes:
>>> Currently, when a sensor value is read, the kernel calls OPAL, which in
>>> turn builds a message for the FSP, and waits for a message back.
On 03/27/2015 11:36 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2015-03-27 at 20:59 +1100, Michael Ellerman wrote:
>>
>> Can you put it in opal.h and give it a better name, maybe
>> opal_error_code() ?
>
> Do we want it to be inlined all the time ? Feels more like something we
> should have in opa
On 03/27/2015 10:59 AM, Michael Ellerman wrote:
> On Thu, 2015-26-03 at 16:04:45 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote:
>> OPAL has its own list of return codes. The patch provides a translation
>> of such codes in errnos for the opal_sensor_read call.
>>
>> Signed-off-by: Cédric Le Goater
On 03/30/2015 04:05 AM, Michael Ellerman wrote:
> On Fri, 2015-03-27 at 17:39 +0100, Cédric Le Goater wrote:
>> OPAL has its own list of return codes. The patch provides a translation
>> of such codes in errnos for the opal_sensor_read call, and possibly
>> others if needed.
>>
>> Index: linux.git
On 03/30/2015 04:09 AM, Michael Ellerman wrote:
> On Fri, 2015-03-27 at 17:39 +0100, Cédric Le Goater wrote:
>> The opal sensor mutex protects the opal_sensor_read call which
>> can return a OPAL_BUSY code on IBM Power systems if a previous
>> request is in progress.
>>
>> This can be handled at u
On 03/30/2015 08:54 AM, Michael Ellerman wrote:
> On Mon, 2015-03-30 at 08:37 +0200, Cedric Le Goater wrote:
>> On 03/30/2015 04:05 AM, Michael Ellerman wrote:
>>> On Fri, 2015-03-27 at 17:39 +0100, Cédric Le Goater wrote:
>>>> OPAL has its own list of retu
On 03/30/2015 08:59 AM, Michael Ellerman wrote:
> On Mon, 2015-03-30 at 08:51 +0200, Cedric Le Goater wrote:
>> On 03/30/2015 04:09 AM, Michael Ellerman wrote:
>>> On Fri, 2015-03-27 at 17:39 +0100, Cédric Le Goater wrote:
>>>> The opal sensor mutex protects t
> More specifically, I envision restart to work like this:
>
> 1) user invokes user-land utility (e.g. "cr --restart ..."
> 2) 'cr' will create a new container
> 3) 'cr' will start a child in that container
process 1 in its private namespaces.
> 4) child will create rest of tree (in kernel or i
> Again, how would 'cr' obtain exit status for these tasks, and how would
> it distinguish failure from normal operation?
Here's our solution to this issue.
mcr maintains in its kernel container object an exitcode attribute for
the mcr-restart process. This process is detached from the fork tree
38 matches
Mail list logo
