On 8/5/2015 9:11 PM, Gavin Shan wrote:
> This introduces one more argument to of_fdt_unflatten_tree()
> to specify the root node for the FDT blob, which is going to be
> unflattened. In the result, the function can be used to unflatten
> FDT blob, which represents device sub-tree in PowerNV hotplug
On 8/5/2015 9:11 PM, Gavin Shan wrote:
> This changes of_fdt_unflatten_tree() so that it returns the allocated
> memory chunk for unflattened device-tree, which can be released once
> it's obsoleted.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/fdt.c | 11 ++-
> include/linux/o
es and 'name' property?
> - Need how addresses work?
Looks good. Since this is a first pass, I'm expecting that polishing
(things like updating section numbers) would happen in subsequent
patches after more of the content changes are done, so no need
to do so in this patch.
R
On 11/29/19 9:10 AM, Sebastian Andrzej Siewior wrote:
> I've been looking at phandle_cache and noticed the following: The raw
> phandle value as generated by dtc starts at zero and is incremented by
> one for each phandle entry. The qemu pSeries model is using Slof (which
> is probably the same thi
On 12/2/19 10:12 PM, Michael Ellerman wrote:
> Frank Rowand writes:
>> On 11/29/19 9:10 AM, Sebastian Andrzej Siewior wrote:
>>> I've been looking at phandle_cache and noticed the following: The raw
>>> phandle value as generated by dtc starts at zero and is
On 12/3/19 12:35 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Dec 03, 2019 at 03:03:22PM +1100, Michael Ellerman wrote:
>> Sebastian Andrzej Siewior writes:
>> I've certainly heard it said that on some OF's the phandle was just ==
>> the address of the internal representation, and I guess mayb
On 12/3/19 10:56 AM, Rob Herring wrote:
> On Mon, Dec 2, 2019 at 10:28 PM Frank Rowand wrote:
>>
>> On 12/2/19 10:12 PM, Michael Ellerman wrote:
>>> Frank Rowand writes:
>>>> On 11/29/19 9:10 AM, Sebastian Andrzej Siewior wrote:
>>>>> I've
On 12/5/19 10:35 AM, Sebastian Andrzej Siewior wrote:
> On 2019-12-03 10:56:35 [-0600], Rob Herring wrote:
>>> Another possibility would be to make the cache be dependent
>>> upon not CONFIG_PPC. It might be possible to disable the
>>> cache with a minimal code change.
>>
>> I'd rather not do that
On 12/6/19 5:40 PM, Segher Boessenkool wrote:
> Hi,
>
> On Thu, Dec 05, 2019 at 07:37:24PM -0600, Frank Rowand wrote:
>> On 12/3/19 12:35 PM, Segher Boessenkool wrote:
>>> Btw. Some OFs mangle the phandles some way, to make it easier to catch
>>> people usin
On 12/5/19 7:52 PM, Frank Rowand wrote:
> On 12/3/19 10:56 AM, Rob Herring wrote:
>> On Mon, Dec 2, 2019 at 10:28 PM Frank Rowand wrote:
>>>
>>> On 12/2/19 10:12 PM, Michael Ellerman wrote:
>>>> Frank Rowand writes:
>>>>> On 11/29/19 9:10
On 12/9/19 7:51 PM, Rob Herring wrote:
> On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
> wrote:
>>
>> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
>>> Is there a memory usage issue for the systems that led to this thread?
>>
>> No, no memo
Hi Michael,
On 4/7/20 10:13 PM, Michael Ellerman wrote:
> bugzilla-dae...@bugzilla.kernel.org writes:
>> https://bugzilla.kernel.org/show_bug.cgi?id=206203
>>
>> Erhard F. (erhar...@mailbox.org) changed:
>>
>>What|Removed |Added
>> --
On 4/8/20 10:22 AM, Frank Rowand wrote:
> Hi Michael,
>
> On 4/7/20 10:13 PM, Michael Ellerman wrote:
>> bugzilla-dae...@bugzilla.kernel.org writes:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=206203
>>>
>>> Erhard F. (erhar...@mailbox.org) ch
On 4/15/20 10:27 PM, Frank Rowand wrote:
> On 4/8/20 10:22 AM, Frank Rowand wrote:
>> Hi Michael,
>>
>> On 4/7/20 10:13 PM, Michael Ellerman wrote:
>>> bugzilla-dae...@bugzilla.kernel.org writes:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=206203
Hi Finn,
On 08/29/18 17:44, Finn Thain wrote:
> Hi Frank,
>
> Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
> very early, before any video driver loads.
>
> Stan and I were able to bisect the regression between v4.16 and v4.17 and
> arrived at commit 0b3ce78e90fc (
On 09/09/18 10:04, Benjamin Herrenschmidt wrote:
> On Fri, 2018-08-31 at 14:58 +1000, Benjamin Herrenschmidt wrote:
>>
>>> A long shot, but something to consider, is that I failed to cover the
>>> cases of dynamic devicetree updates (removing nodes that contain a
>>> phandle) in ways other than ove
dex 9095b8290150..74eaedd5b860 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -140,6 +140,9 @@ void of_populate_phandle_cache(void)
> if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
> phandles++;
>
> + if (!phandles)
> + goto out;
> +
> cache_entries = roundup_pow_of_two(phandles);
> phandle_cache_mask = cache_entries - 1;
>
>
Thanks Rob! That fix makes sense, and the test results look
promising.
Reviewed-by: Frank Rowand
f
> of_find_node_by_phandle()")
> Cc: sta...@vger.kernel.org # 4.17+
> Reported-by: Finn Thain
> Tested-by: Stan Johnson
> Cc: Frank Rowand
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Rob Herring
> ---
> Here's a formal patch of what Stan tested. Will send to
On 09/13/18 13:28, Rob Herring wrote:
> Major changes are I2C and SPI bus checks, YAML output format (for
> future validation), some new libfdt functions, and more libfdt
> validation of dtbs.
>
> The YAML addition adds an optional dependency on libyaml. pkg-config is
> used to test for it and pkg
On 09/18/18 11:55, Rob Herring wrote:
> On Fri, Sep 14, 2018 at 2:32 PM Frank Rowand wrote:
>>
>> On 09/13/18 13:28, Rob Herring wrote:
>>> Major changes are I2C and SPI bus checks, YAML output format (for
>>> future validation), some new libfdt functions, and m
+ Frank
On 09/27/18 15:25, Li Yang wrote:
> Hi Rob and Grant,
>
> Various device tree specs are recommending to include all the
> potential compatible strings in the device node, with the order from
> most specific to most general. But it looks like Linux kernel doesn't
> provide a way to bind
On 10/05/18 08:07, Rob Herring wrote:
> On Thu, Oct 4, 2018 at 11:14 PM wrote:
>>
>> From: Frank Rowand
>>
>> If overlay properties #address-cells or #size-cells are already in
>> the live devicetree for any given node, then the values in the
>> overlay
On 10/05/18 07:53, Rob Herring wrote:
> On Thu, Oct 4, 2018 at 11:14 PM wrote:
>>
>> From: Frank Rowand
>>
>> Callers of of_irq_parse_one() blindly use the pointer args.np
>> without checking whether of_irq_parse_one() had an error and
>> thus did not set
On 10/05/18 06:26, Guenter Roeck wrote:
> On 10/04/2018 09:12 PM, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> Callers of of_irq_parse_one() blindly use the pointer args.np
>> without checking whether of_irq_parse_one() had an error and
>> thus
On 10/05/18 12:04, Rob Herring wrote:
> On Fri, Oct 5, 2018 at 1:53 PM Frank Rowand wrote:
>>
>> On 10/05/18 08:07, Rob Herring wrote:
>>> On Thu, Oct 4, 2018 at 11:14 PM wrote:
>>>>
>>>> From: Frank Rowand
>>>>
>>>> If
On 10/08/18 11:46, Alan Tull wrote:
> On Mon, Oct 8, 2018 at 10:57 AM Alan Tull wrote:
>>
>> On Thu, Oct 4, 2018 at 11:14 PM wrote:
>>>
>>> From: Frank Rowand
>>>
>>> If overlay properties #address-cells or #size-cells are already in
>>
On 10/09/18 13:28, Alan Tull wrote:
> On Thu, Oct 4, 2018 at 11:14 PM wrote:
>>
>> From: Frank Rowand
>>
>
> Hi Frank,
>
>> The changeset entry 'update property' was used for new properties in
>> an overlay instead of 'add property
On 10/09/18 23:04, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
>
> "of: overlay: use prop add changeset entry for property in new nodes"
> fixed a problem where an 'update property' changeset entry was
> created for properties contained in nodes
On 10/10/18 13:40, Alan Tull wrote:
> On Wed, Oct 10, 2018 at 1:49 AM Frank Rowand wrote:
>>
>> On 10/09/18 23:04, frowand.l...@gmail.com wrote:
>>> From: Frank Rowand
>>>
>>>
>>> "of: overlay: use prop add changeset entry for property in
On 10/10/18 14:03, Frank Rowand wrote:
> On 10/10/18 13:40, Alan Tull wrote:
>> On Wed, Oct 10, 2018 at 1:49 AM Frank Rowand wrote:
>>>
>>> On 10/09/18 23:04, frowand.l...@gmail.com wrote:
>>>> From: Frank Rowand
>>>>
>>>>
>>&g
+ devicetree mail list
On 10/11/18 06:22, Akshay Adiga wrote:
> Previously if a older kernel runs on a newer firmware, it may enable
> all available states irrespective of its capability of handling it.
> New device tree format adds a compatible flag, so that only kernel
> which has the capability
+ devicetree mail list
On 10/11/18 06:22, Akshay Adiga wrote:
> This patch adds support for new device-tree format for idle state
> description.
>
> Previously if a older kernel runs on a newer firmware, it may enable
> all available states irrespective of its capability of handling it.
> New dev
+ devicetree mail list
On 10/11/18 06:22, Akshay Adiga wrote:
> Passing pointer to the pnv_idle_state instead of psscr value and mask.
> This helps us to pass more information to the stop loop. This will help to
> figure out the method to enter/exit idle state.
>
> Signed-off-by: Akshay Adiga
>
+ devicetree mail list
On 10/11/18 06:22, Akshay Adiga wrote:
> From: Abhishek Goel
>
> This patch moves the saving and restoring of sprs for P9 cpuidle
> from kernel to opal.
> In an attempt to make the powernv idle code backward compatible,
> and to some extent forward compatible, add support
On 10/11/18 12:33, Alan Tull wrote:
> On Thu, Oct 11, 2018 at 12:39 AM Frank Rowand wrote:
>
> [resend of my messed up rejected email of a minute ago, sorry]
>
>>
>> On 10/10/18 14:03, Frank Rowand wrote:
< snip >
> I understand you're quite busy with al
On 10/13/18 05:51, Joe Perches wrote:
> On Fri, 2018-10-12 at 21:53 -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> Multiple overlay fragments adding or deleting the same node is not
>> supported. Replace code comment of such, with check to detect
On 10/13/18 11:21, Frank Rowand wrote:
> On 10/13/18 05:51, Joe Perches wrote:
>> On Fri, 2018-10-12 at 21:53 -0700, frowand.l...@gmail.com wrote:
>>> From: Frank Rowand
>>>
>>> Multiple overlay fragments adding or deleting the same node is not
>>> s
On 10/14/18 18:06, Joe Perches wrote:
> On Sun, 2018-10-14 at 17:24 -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> Add test case of two fragments updating the same property. After
>> adding the test case, the system hangs at end of boot, after
>
On 10/14/18 18:55, Joe Perches wrote:
> On Sun, 2018-10-14 at 18:52 -0700, Frank Rowand wrote:
>> On 10/14/18 18:06, Joe Perches wrote:
>>> On Sun, 2018-10-14 at 17:24 -0700, frowand.l...@gmail.com wrote:
>>>> From: Frank Rowand
>>>>
>>>> Add
On 10/14/18 20:21, Frank Rowand wrote:
> On 10/14/18 18:55, Joe Perches wrote:
>> On Sun, 2018-10-14 at 18:52 -0700, Frank Rowand wrote:
>>> On 10/14/18 18:06, Joe Perches wrote:
>>>> On Sun, 2018-10-14 at 17:24 -0700, frowand.l...@gmail.com wrote:
>>>>
On 10/15/18 12:01, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM wrote:
>>
>> From: Frank Rowand
>>
>> If overlay properties #address-cells or #size-cells are already in
>> the live devicetree for any given node, then the values in the
>> overlay
On 10/15/18 12:21, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM wrote:
>>
>> From: Frank Rowand
>>
>> Add checks to (1) overlay apply process and (2) memory freeing
>> triggered by overlay release. The checks are intended to detect
>> possible memor
On 10/16/18 02:47, Michael Ellerman wrote:
> frowand.l...@gmail.com writes:
>
>> From: Frank Rowand
>>
>> Add checks to (1) overlay apply process and (2) memory freeing
>> triggered by overlay release. The checks are intended to detect
>> possible memory l
On 10/18/18 10:03, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 07:37:21PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> Add checks:
>> - attempted kfree due to refcount reaching zero before overlay
>> is removed
>> - properties
On 10/18/18 10:05, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 07:37:22PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> The refcount of a newly added overlay node decrements to one
>> (instead of zero) when the overlay changeset is destroyed. Th
On 10/18/18 10:09, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 07:37:24PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> "of: overlay: add missing of_node_get() in __of_attach_node_sysfs"
>> added a missing of_node_get() to __of_attac
On 10/18/18 11:13, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 07:37:29PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> If overlay properties #address-cells or #size-cells are already in
>> the live devicetree for any given node, then the values i
On 10/18/18 15:46, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Add checks to (1) overlay apply process and (2) memory freeing
> triggered by overlay release. The checks are intended to detect
> possible memory leaks and invalid overlays.
>
> The checks revealed
Hi Michael, Ben, Paul,
Do you know if anyone has tried this series on PowerPC?
Thanks,
-Frank
On 11/5/18 11:24 AM, Rob Herring wrote:
> On Mon, Nov 5, 2018 at 9:26 AM wrote:
>>
>> From: Frank Rowand
>>
>> Add checks to (1) overlay apply process and (2) memory free
On 11/7/18 4:08 AM, Michael Ellerman wrote:
> frowand.l...@gmail.com writes:
>
>> From: Frank Rowand
>>
>> of_attach_node() and of_detach_node() always return zero, so
>> their return value is meaningless.
>
> But should they always return zero?
>
>
On 11/7/18 4:14 AM, Michael Ellerman wrote:
> frowand.l...@gmail.com writes:
>
>> From: Frank Rowand
>>
>> There is a matching of_node_put() in __of_detach_node_sysfs()
>>
>> Remove misleading comment from function header comment for
>> of_detach_nod
On 11/7/18 4:23 AM, Michael Ellerman wrote:
> frowand.l...@gmail.com writes:
>
>> From: Frank Rowand
>>
>> "of: overlay: add missing of_node_get() in __of_attach_node_sysfs"
>
> It would be clearer if you said 'The previous commit "of: overla
On 11/7/18 4:09 AM, Michael Ellerman wrote:
> Frank Rowand writes:
>
>> Hi Michael, Ben, Paul,
>>
>> Do you know if anyone has tried this series on PowerPC?
>
> I have. No obvious breakage.
>
> My test does a loop of adding and removing multiple CPUs multip
, which are fixed in
separate patches.
Frank Rowand (17):
of: overlay: add tests to validate kfrees from overlay removal
of: overlay: add missing of_node_put() after add new node to changeset
of: overlay: add missing
On 11/8/18 10:56 PM, Frank Rowand wrote:
> Hi Rob,
>
> Please pull the changes to add the overlay validation checks.
>
> This is the v7 version of the patch series.
>
> -Frank
>
>
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
>
Hi Rob,
I got the cc: list wrong on this patch, please dis-regard.
I will resend (with unchanged version) to the correct cc: list.
-Frank
On 11/26/18 3:54 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Add -T and --annotations command line arguments to dtx_dif
Hi Michael Bringmann,
On 12/11/18 8:07 AM, Rob Herring wrote:
> On Tue, Dec 11, 2018 at 7:29 AM Michael Ellerman wrote:
>>
>> Hi Michael,
>>
>> Please Cc the device tree folks on device tree patches, and also the
>> original author of the patch that added the code you're modifying.
>>
>> So I've
Hi Michael Bringmann,
On 12/13/18 10:42 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Non-overlay dynamic devicetree node removal may leave the node in
> the phandle cache. Subsequent calls to of_find_node_by_phandle()
> will incorrectly find the stale entry. This
On 12/14/18 1:56 PM, Michael Bringmann wrote:
> On 12/14/2018 11:20 AM, Rob Herring wrote:
>> On Fri, Dec 14, 2018 at 12:43 AM wrote:
>>>
>>> From: Frank Rowand
>>>
>>> Non-overlay dynamic devicetree node removal may leave the node i
On 12/14/18 9:15 AM, Rob Herring wrote:
> On Fri, Dec 14, 2018 at 12:43 AM wrote:
>>
>> From: Frank Rowand
>>
>> The phandle cache contains struct device_node pointers. The refcount
>> of the pointers was not incremented while in the cache, allowing use
>>
On 12/14/18 2:47 PM, Frank Rowand wrote:
> On 12/14/18 9:15 AM, Rob Herring wrote:
>> On Fri, Dec 14, 2018 at 12:43 AM wrote:
>>>
>>> From: Frank Rowand
>>>
>>> The phandle cache contains struct device_node pointers. The refcount
>>>
On 12/17/18 2:52 AM, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.l...@gmail.com writes:
>> From: Frank Rowand
>>
>> Non-overlay dynamic devicetree node removal may leave the node in
>> the phandle cache. Subsequent calls to of_find_node_by_phandle()
>>
On 12/18/18 11:40 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The phandle cache contains struct device_node pointers. The refcount
> of the pointers was not incremented while in the cache, allowing use
> after free error after kfree() of the node. Add the proper
On 12/18/18 11:40 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Non-overlay dynamic devicetree node removal may leave the node in
> the phandle cache. Subsequent calls to of_find_node_by_phandle()
> will incorrectly find the stale entry. Remove the node from the
&g
On 12/18/18 12:01 PM, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand wrote:
>>
>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
>>> Hi Frank,
>>>
>>> frowand.l...@gmail.com writes:
>>>> From: Frank Rowand
>>>>
&
On 12/18/18 12:09 PM, Frank Rowand wrote:
> On 12/18/18 12:01 PM, Rob Herring wrote:
>> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand wrote:
>>>
>>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
>>>> Hi Frank,
>>>>
>>>> frowand.l
lar fix as this commit did for overlays:
>
> commit b9952b5218added5577e4a3443969bc20884cea9
> Author: Frank Rowand
> Date: Thu Jul 12 14:00:07 2018 -0700
>
> of: overlay: update phandle cache on overlay apply and remove
>
> A comment in the review of the patch addi
On 07/31/18 12:18, Frank Rowand wrote:
> On 07/31/18 07:17, Rob Herring wrote:
>> On Tue, Jul 31, 2018 at 12:34 AM Michael Ellerman
>> wrote:
>>>
>>> Hi Rob/Frank,
>>>
>>> I think we might have a problem with the phandle_cache not interacting
&
On 12/10/19 2:17 AM, Frank Rowand wrote:
> On 12/9/19 7:51 PM, Rob Herring wrote:
>> On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
>> wrote:
>>>
>>> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
>>>> Is there a memory usage
+ Frank (me)
On 1/26/20 5:52 AM, Michael Ellerman wrote:
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it
ng on x86.
Your email can at an opportune time for me... I was starting to try
2.6.28-rt on ARM and quickly came to the conclusion that the arch
patches weren't the focus yet. But I'm currently side-tracked with
getting my board to even boot a vanilla 2.6.28 kernel
On 06/15/10 23:52, M. Warner Losh wrote:
> In message: <4c187013.5000...@firmworks.com>
> Mitch Bradley writes:
> : Mike Rapoport wrote:
> : > Mitch Bradley wrote:
> : >> Mike Rapoport wrote:
> : >>> Mitch Bradley wrote:
> : >>>
> : The second topic is the hypothetical use of OFW
Hi Geert,
On 11/10/21 11:23 AM, Geert Uytterhoeven wrote:
> Currently struct of_device_id is 196 (32-bit) or 200 (64-bit) bytes
> large. It contains fixed-size strings for a name, a type, and a
> compatible value, but the first two are barely used.
> OF device ID tables contain multiple entries,
errenschmidt
> Cc: Paul Mackerras
> Cc: Frank Rowand
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> arch/powerpc/kernel/prom.c | 2 +-
> arch/powerpc/mm/nohash/kaslr_booke.c | 4 +--
> drivers/of/fdt.c | 39 +++
chmidt
> Cc: Paul Mackerras
> Cc: Frank Rowand
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> arch/powerpc/kernel/prom.c | 4 ++--
> drivers/of/fdt.c | 14 +++---
> include/linux/of_fdt.h | 3 +--
> 3 files changed
fer
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Frank Rowand
> Cc: linux-m...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> arch/mips/ralink/of.c | 16 ++---
> arch/powerpc/
On 11/18/21 1:12 PM, Rob Herring wrote:
> The early FDT scanning functions use of_scan_flat_dt() which implements
> its own node walking method. This function predates libfdt and is an
> unnecessary indirection. This series reworks
> early_init_dt_scan_chosen(), early_init_dt_scan_root(), and
>
fer
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Frank Rowand
> Cc: linux-m...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> v2:
> - ralink: Use 'if' instead of 'else if&#x
On 04/17/17 17:32, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API several device_node
> under
On 04/18/17 17:07, Frank Rowand wrote:
> On 04/17/17 17:32, Tyrel Datwyler wrote:
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to node/property manipulations.
>>
>
On 04/18/17 18:31, Michael Ellerman wrote:
> Frank Rowand writes:
>
>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>
On 04/18/17 19:46, Steven Rostedt wrote:
> On Tue, 18 Apr 2017 17:07:17 -0700
> Frank Rowand wrote:
>
>
>> As far as I know, there is no easy way to combine trace data and printk()
>> style data to create a single chronology of events. If some of the
>> informati
On 04/17/17 17:32, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API several device_node
> under
On 04/19/17 11:45, Tyrel Datwyler wrote:
> On 04/18/2017 07:49 PM, Steven Rostedt wrote:
>> On Tue, 18 Apr 2017 18:42:32 -0700
>> Frank Rowand wrote:
>>
>>> And of course the other issue with using tracepoints is the extra space
>>> required to hold
On 04/19/17 16:27, Tyrel Datwyler wrote:
> On 04/18/2017 06:31 PM, Michael Ellerman wrote:
>> Frank Rowand writes:
>>
>>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>>> This patch introduces event tracepoints for tracking a device_nodes
>>>> r
On 04/19/17 19:33, Steven Rostedt wrote:
> On Wed, 19 Apr 2017 16:27:10 -0700
> Tyrel Datwyler wrote:
>
>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>> # cat trace | grep -A6 "/pci@8002018"
>
> Just to let you know that there is now stacktrace event triggers, where
> yo
On 04/19/17 21:43, Frank Rowand wrote:
> On 04/19/17 16:27, Tyrel Datwyler wrote:
>> On 04/18/2017 06:31 PM, Michael Ellerman wrote:
< snip >
>>
>> To get that same info as far as I know is to add a dump_stack() after
>> each pr_debug.
>
> Here is a pat
On 04/19/17 19:37, Frank Rowand wrote:
> On 04/19/17 11:45, Tyrel Datwyler wrote:
>> On 04/18/2017 07:49 PM, Steven Rostedt wrote:
>>> On Tue, 18 Apr 2017 18:42:32 -0700
>>> Frank Rowand wrote:
>>>
>>>> And of course the other issue with using trac
On 04/20/17 09:51, Tyrel Datwyler wrote:
> On 04/19/2017 09:43 PM, Frank Rowand wrote:
>
< snip >
>> The call stack could easily be post-processed, for example using addr2line.
>> Here is the call stack for when the refcount incremented to 23 from 22 (or
>>
On 06/18/17 07:05, Rob Herring wrote:
> On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> The Devicetree Specification has superseded the ePAPR as the
>> base specification for bindings. Update files in Documentat
Hi Rob,
Michael has an issue that means this patch series is not OK in the
current form. I will work on a v7 to see if I can resolve the
issue.
-Frank
On 06/20/17 21:57, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.l...@gmail.com writes:
>> From: Frank Rowand
>&g
On 06/20/17 23:18, Frank Rowand wrote:
> Hi Rob,
>
> Michael has an issue that means this patch series is not OK in the
> current form. I will work on a v7 to see if I can resolve the
> issue.
>
> -Frank
< snip >
Hi Rob,
The issue is in patch 1. Patches 2 - 4 ar
adding Ben and Paul.
Hi Michael,
On 06/20/17 21:57, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.l...@gmail.com writes:
>> From: Frank Rowand
>>
>> Remove "phandle", "linux,phandle", and "ibm,phandle" properties from
>> the
On 10/17/17 14:46, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull wrote:
>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring wrote:
>>
>> Hi Rob,
>>
>>> With dependencies on a statically allocated full path name converted to
>>> use %pOF format specifier, we can store just the basen
On 10/18/17 11:39, Alan Tull wrote:
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
> wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand
On 10/18/17 11:30, Rob Herring wrote:
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
> wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote:
>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowan
On 10/19/17 13:06, Moritz Fischer wrote:
< snip >
> We also have plenty of code that is just not aware of overlays, and
> assumes certain parts of the tree to stay static.
I would state that somewhat differently. :-) There is very little
code that is aware of overlays, and most code assumes th
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem.
> This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
> work!
>
> Note
On 01/23/18 04:11, Michael Ellerman wrote:
> Wolfram Sang writes:
>
>> Hi Frank,
>>
>>> Please go back and read the thread for version 1. Simply resubmitting a
>>> forward port is ignoring that whole conversation.
>>>
>>> There is a lot of good info in that thread. I certainly learned stuff in
On 01/22/18 03:49, Wolfram Sang wrote:
> Hi Frank,
>
>> Please go back and read the thread for version 1. Simply resubmitting a
>> forward port is ignoring that whole conversation.
>>
>> There is a lot of good info in that thread. I certainly learned stuff in it.
>
> Yes, I did that and learned
1 - 100 of 122 matches
Mail list logo
