Re: [PATCH v3 0/5] of: add of_property_alloc/free() and of_node_alloc()

Sorry for the lack of response, it's been a busy week. I will get to this soon. -Frank On 6/20/22 06:41, Clément Léger wrote: > In order to be able to create new nodes and properties dynamically from > drivers, add of_property_alloc/free() and of_node_alloc(). These > functions can be used to

Re: [PATCH v2] of/fdt: Rework early_init_dt_scan_memory() to call directly

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' > - ea

Re: [PATCH 0/3] of/fdt: Rework early FDT scanning functions

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

Re: [PATCH 3/3] of/fdt: Rework early_init_dt_scan_memory() to call directly

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/

Re: [PATCH 2/3] of/fdt: Rework early_init_dt_scan_root() to call directly

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

Re: [PATCH 1/3] of/fdt: Rework early_init_dt_scan_chosen() to call directly

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 +++

Re: [PATCH/RFC] of: Shrink struct of_device_id

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,

Re: [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

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

Re: [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

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

Re: [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

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 >>

Re: [PATCH] dt: Remove booting-without-of.txt

ks 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. Reviewed-by: Frank Rowand -Frank > > Cc: Frank Rowand > Cc: Ma

Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc

+ 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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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 been

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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 incr

Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF

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

Re: [PATCH v2 2/2] of: __of_detach_node() - remove node from phandle cache

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

Re: [PATCH v2 2/2] of: __of_detach_node() - remove node from phandle cache

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 >>>> &

Re: [PATCH v3 2/2] of: __of_detach_node() - remove node from phandle cache

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

Re: [PATCH v3 1/2] of: of_node_get()/of_node_put() nodes held in phandle cache

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 p

Re: [PATCH v2 2/2] of: __of_detach_node() - remove node from phandle cache

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() >>

Re: [PATCH 1/2] of: of_node_get()/of_node_put() nodes held in phandle cache

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 >>>

Re: [PATCH 1/2] of: of_node_get()/of_node_put() nodes held in phandle cache

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 us

Re: [PATCH 2/2] of: __of_detach_node() - remove node from phandle cache

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 nod

Re: [PATCH 0/2] of: phandle_cache, fix refcounts, remove stale entry

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. T

Re: [PATCH v03] powerpc/mobility: Fix node detach/rename problem

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

Re: [PATCH] of: add dtc annotations functionality to dtx_diff

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

Re: [GIT PULL] of: overlay: validation checks, subsequent fixes for v20 -- correction: v4.20

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: >

[GIT PULL] of: overlay: validation checks, subsequent fixes for v20

, 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

Re: [PATCH v6 00/18] of: overlay: validation checks, subsequent fixes

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

Re: [PATCH v6 04/18] powerpc/pseries: add of_node_put() in dlpar_detach_node()

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: overlay ...

Re: [PATCH v6 03/18] of: overlay: add missing of_node_get() in __of_attach_node_sysfs

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

Re: [PATCH v6 07/18] of: dynamic: change type of of_{at,de}tach_node() to void

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? > >

Re: [PATCH v6 00/18] of: overlay: validation checks, subsequent fixes

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

Re: [PATCH v5 00/18] of: overlay: validation checks, subsequent fixes

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

Re: [PATCH v4 09/18] of: overlay: validate overlay properties #address-cells and #size-cells

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

Re: [PATCH v4 04/18] powerpc/pseries: add of_node_put() in dlpar_detach_node()

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_

Re: [PATCH v4 02/18] of: overlay: add missing of_node_put() after add new node to changeset

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.

Re: [PATCH v4 01/18] of: overlay: add tests to validate kfrees from overlay removal

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

Re: [PATCH v4 00/18] of: overlay: validation checks, subsequent fixes

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 >> possib

Re: [PATCH v3 00/18] of: overlay: validation checks, subsequent fixes

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 >> pos

Re: [PATCH v3 09/18] of: overlay: validate overlay properties #address-cells and #size-cells

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

Re: [PATCH v3 13/18] of: overlay: check prevents multiple fragments touching same property

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: >>>>

Re: [PATCH v3 13/18] of: overlay: check prevents multiple fragments touching same property

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

Re: [PATCH v3 13/18] of: overlay: check prevents multiple fragments touching same property

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 >

Re: [PATCH v2 12/18] of: overlay: check prevents multiple fragments add or delete same node

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

Re: [PATCH v2 12/18] of: overlay: check prevents multiple fragments add or delete same node

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 det

Re: [PATCH 05.1/16] of:overlay: missing name, phandle, linux, phandle in new nodes

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 all

Re: [RFC PATCH v2 3/3] cpuidle/powernv: save-restore sprs in opal

+ 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

Re: [RFC PATCH v2 2/3] powernv/cpuidle: Pass pointers instead of values to stop loop

+ 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 >

Re: [RFC PATCH v2 1/3] cpuidle/powernv: Add support for states with ibm,cpuidle-state-v1

+ 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

Re: [RFC PATCH v2 0/3] New device-tree format and Opal based idle save-restore

+ 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

Re: [PATCH 05.1/16] of:overlay: missing name, phandle, linux, phandle in new nodes

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

Re: [PATCH 05.1/16] of:overlay: missing name, phandle, linux, phandle in new 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

Re: [PATCH 05.1/16] of:overlay: missing name, phandle, linux, phandle in new nodes

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 add

Re: [PATCH 05/16] of: overlay: use prop add changeset entry for property in new nodes

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'. >> &g

Re: [PATCH 09/16] of: overlay: validate overlay properties #address-cells and #size-cells

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 >>

Re: [PATCH 09/16] of: overlay: validate overlay properties #address-cells and #size-cells

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 >>>> >>

Re: [PATCH 15/16] of: unittest: initialize args before calling of_irq_parse_one()

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

Re: [PATCH 15/16] of: unittest: initialize args before calling of_irq_parse_one()

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

Re: [PATCH 09/16] of: overlay: validate overlay properties #address-cells and #size-cells

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

Re: drivers binding to device node with multiple compatible strings

+ 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

Re: [PATCH 3/3] scripts/dtc: Update to upstream version v1.4.7-14-gc86da84d30e4

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

Re: [PATCH 3/3] scripts/dtc: Update to upstream version v1.4.7-14-gc86da84d30e4

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

Re: [PATCH] of: fix phandle cache creation for DTs with no phandles

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 Linu

Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

t; --- 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

Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

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

Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

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

Re: phandle_cache vs of_detach_node (was Re: [PATCH] powerpc/mobility: Fix node detach/rename problem)

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 &

Re: phandle_cache vs of_detach_node (was Re: [PATCH] powerpc/mobility: Fix node detach/rename problem)

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 patc

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:53, Tyrel Datwyler wrote: > On 01/25/2018 01:49 PM, Frank Rowand wrote: >> Hi Wolfram, >> >> On 01/25/18 03:03, Steven Rostedt wrote: >>> On Wed, 24 Jan 2018 22:55:13 -0800 >>> Frank Rowand <frowand.l...@gmail.com> wrote: >>>

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:14, Wolfram Sang wrote: > >> This means that ftrace can not be used for the of_node_get(), >> of_node_put(), and of_node_release() debug info, because >> these functions are called before early_initcall(). > > For the record: You can still unbind/bind devices. This is how I >

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/25/18 15:12, Wolfram Sang wrote: > Frank, > > here seems to be a misunderstanding going on. I don't want to push this > patch upstream against all odds. I merely wanted to find out what the > status of this patch is. Because one possibility was that it had just > been forgotten... > >>>

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 14:40, Tyrel Datwyler wrote: > On 01/24/2018 10:48 PM, Frank Rowand wrote: >> On 01/21/18 06:31, Wolfram Sang wrote: >>> From: Tyrel Datwyler <tyr...@linux.vnet.ibm.com> >>> >>> This patch introduces event tracepoints for tracking a device_nod

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Wolfram, On 01/25/18 03:03, Steven Rostedt wrote: > On Wed, 24 Jan 2018 22:55:13 -0800 > Frank Rowand <frowand.l...@gmail.com> wrote: > >> Hi Steve, > >> >> Off the top of your head, can you tell me know early in the boot >> process a trace_ev

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > 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

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/25/18 00:01, Geert Uytterhoeven wrote: > Hi Frank, > > On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand <frowand.l...@gmail.com> wrote: >>> create mode 100644 include/trace/events/of.h >> >> mode looks incorrect. Existing files in include/trace/events/ are

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler <tyr...@linux.vnet.ibm.com> >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, 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 >

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > 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

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

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

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

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

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

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

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

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

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

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

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand <frowand.l...@gmail.com> >>>> wrote: >>>>> On 10/17/17 14:46, Rob Herring wrote: >>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull <at...@kernel.org> wrote:

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand <frowand.l...@gmail.com> >>>> wrote: >>>>> On 10/17/17 14:46, Rob Herring wrote: >>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull <at...@kernel.org> wrote:

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

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

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

te: > Hi Frank, > > frowand.l...@gmail.com writes: >> From: Frank Rowand <frank.row...@sony.com> >> >> Remove "phandle", "linux,phandle", and "ibm,phandle" properties from >> the internal device tree. The phandle will still be in the

Re: [PATCH 0/4] Removing full paths from DT full_name

Hi Rob, On 07/25/17 14:44, Rob Herring wrote: > This series is the last steps to remove storing the full path for every > DT node. Instead, we can create full path strings dynamically as needed > with printf %pOF specifiers (commit ce4fecf1fe15). There are a number of > remaining direct users

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

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 <frank.row...@sony.com> >> >> Remove "phandle", "linux,phandle", and "ibm,phandle&

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

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

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

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 <fra

Re: [PATCH] of: update ePAPR references to point to Devicetree Specification

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 <frank.row...@sony.com> >> >> The Devicetree Specification has superseded the ePAPR as the >> base specification for binding

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

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 >>

  1   2   >