On 01/31/18 12:05, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Create a cache of the nodes that contain a phandle property. Use this
> cache to find the node for a given phandle value instead of scanning
> the devicetree to find the node. If the phandle value is not
resolver.c
will fail on 4.9 because that code does not exist yet -- you can just
remove that portion of the patch.
-Frank
On 01/31/18 12:05, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Create a cache of the nodes that contain a phandle property. Use this
> cache to find
Hi Rob,
Please ignore this one. My signed-off is below the first "---".
-Frank
On 01/31/18 12:02, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Create a cache of the nodes that contain a phandle property. Use this
> cache to find the node for a given ph
On 01/30/18 00:04, Chintan Pandya wrote:
>> (1)
>>
>> Can you point me to the driver code that is invoking
>> the search?
> There are many locations. Few of them being,
> https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/of/irq.c?h=msm-4.9#n214
> https://source.codeaurora.org/quic/l
arget-path. Is the
target-path form needed by the fpga subsystem, or can this
be removed?
-Frank
On 01/29/18 16:22, Frank Rowand wrote:
> On 01/29/18 06:08, Geert Uytterhoeven wrote:
>> Hi Frank,
>>
>> On Mon, Jan 29, 2018 at 3:53 AM, wrote:
>>> From: Frank Rowand
On 01/29/18 06:08, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Mon, Jan 29, 2018 at 3:53 AM, wrote:
>> From: Frank Rowand
>>
>> Move duplicating and unflattening of an overlay flattened devicetree
>> (FDT) into the overlay application code. To accompli
On 01/29/18 02:37, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Mon, Jan 29, 2018 at 3:53 AM, wrote:
>> From: Frank Rowand
>>
>> The unittest-data overlays have been pulled into proper overlay
>> devicetree source files without changing their format. The
>&
On 01/29/18 07:05, Geert Uytterhoeven wrote:
> On Mon, Jan 29, 2018 at 3:42 PM, Rob Herring wrote:
>> On Sun, Jan 28, 2018 at 8:53 PM, wrote:
>>> From: Frank Rowand
>>>
>>> Move duplicating and unflattening of an overlay flattened devicetree
>>>
On 01/29/18 06:42, Rob Herring wrote:
> On Sun, Jan 28, 2018 at 8:53 PM, wrote:
>> From: Frank Rowand
>>
>> Move duplicating and unflattening of an overlay flattened devicetree
>> (FDT) into the overlay application code. To accomplish this,
>>
Hi Chintan,
On 01/26/18 00:31, Chintan Pandya wrote:
> of_find_node_by_phandle() takes a lot of time (1ms per
> call) to find right node when your intended device is
> too deeper in the fdt. Reason is, we search for each
> device serially in the fdt. See this,
>
> struct device_node *__of_find_al
On 01/28/18 19:21, Masahiro Yamada wrote:
> Hi Frank,
>
> 2018-01-29 11:53 GMT+09:00 :
>> From: Frank Rowand
>> diff --git a/drivers/of/unittest-data/Makefile
>> b/drivers/of/unittest-data/Makefile
>> index df697976740a..2b7ee68c908e 100644
>> --- a/dri
On 01/26/18 13:29, Frank Rowand wrote:
> On 01/26/18 13:27, Frank Rowand wrote:
>> On 01/26/18 00:22, Chintan Pandya wrote:
>>>
>>>
>>> On 1/26/2018 1:24 AM, Frank Rowand wrote:
>>>> On 01/25/18 02:14, Chintan Pandya wrote:
>>>>> of
On 01/26/18 13:27, Frank Rowand wrote:
> On 01/26/18 00:22, Chintan Pandya wrote:
>>
>>
>> On 1/26/2018 1:24 AM, Frank Rowand wrote:
>>> On 01/25/18 02:14, Chintan Pandya wrote:
>>>> of_find_node_by_phandle() takes a lot of time finding
>>>>
On 01/26/18 00:22, Chintan Pandya wrote:
>
>
> On 1/26/2018 1:24 AM, Frank Rowand wrote:
>> On 01/25/18 02:14, Chintan Pandya wrote:
>>> of_find_node_by_phandle() takes a lot of time finding
>>> right node when your intended device is too right-side
>>
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 wrote:
>>>
>>>> Hi Steve,
>&g
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
> debug
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...
>
>>> So,
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
>>>
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle a
Hi Wolfram,
On 01/25/18 03:03, Steven Rostedt wrote:
> On Wed, 24 Jan 2018 22:55:13 -0800
> Frank Rowand wrote:
>
>> Hi Steve,
>
>>
>> Off the top of your head, can you tell me know early in the boot
>> process a trace_event can be called and successfully p
On 01/25/18 02:14, Chintan Pandya wrote:
> of_find_node_by_phandle() takes a lot of time finding
> right node when your intended device is too right-side
> in the fdt. Reason is, we search each device serially
> from the fdt, starting from left-most to right-most.
Please give me a pointer to the c
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 upstreaming of the refcount API se
On 01/25/18 00:01, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Thu, Jan 25, 2018 at 7:48 AM, Frank Rowand wrote:
>>> create mode 100644 include/trace/events/of.h
>>
>> mode looks incorrect. Existing files in include/trace/events/ are -rw-rw
>
> Not in
On 01/24/18 22:48, Frank Rowand wrote:
> 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
>&g
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
> work!
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 upstreaming of the refcount API se
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/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
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/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/05/18 05:05, Alexandre Belloni wrote:
> Hi,
>
> I'm definitively late to the party but...
>
> On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote:
>> +2. Style:
>> +
>> + The SPDX license identifier is added in form of a comment. The comment
>> + style depends on the file type::
>>
t.h | 6 +-
> include/linux/of_platform.h | 7 +--
> 25 files changed, 25 insertions(+), 100 deletions(-)
Reviewed-by: Frank Rowand
< snip >
On 12/16/17 09:25, Andre Heider wrote:
> Hi Frank,
>
> On 15/12/17 22:06, Frank Rowand wrote:
>> On 12/14/17 07:12, Andre Heider wrote:
>>> The overlay feature requires the base dtb to be built with symbols, so
>>> lets build the dtbs with symbols when overlay s
On 12/14/17 07:12, Andre Heider wrote:
> The overlay feature requires the base dtb to be built with symbols, so
> lets build the dtbs with symbols when overlay support was explicitly
> enabled.
>
> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
> average.
>
> Totals in b
On 12/09/17 01:04, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Sat, Dec 9, 2017 at 7:01 AM, Frank Rowand wrote:
>> On 12/08/17 05:13, Geert Uytterhoeven wrote:
>>> This patch series fixes memory corruption when applying overlays.
>>> I first noticed this when
lies to Rob's for-next
> branch only.
Overlay FDT files should not have invalid contents. But they inevitably
will, so the code has to handle those cases. Thanks for finding this
problem and making the code better!
For the full series:
Reviewed-by: Frank Rowand
> I've updated
adding /me
On 12/04/17 04:24, Greg Kroah-Hartman wrote:
> On Sun, Dec 03, 2017 at 07:19:53PM +0200, Dan Aloni wrote:
>> Hi all,
>>
>> [[ CC'ed: folks relating to the original __*_refok family of attributes,
>> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
>> kernel harderni
adding /me
On 12/03/17 12:19, Dan Aloni wrote:
> Hi all,
>
> [[ CC'ed: folks relating to the original __*_refok family of attributes,
> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
> kernel harderning, LKML ]]
>
> It seems that it is possible to cause a use-after-free in
On 12/05/17 12:07, Alan Tull wrote:
> On Mon, Dec 4, 2017 at 7:14 PM, Frank Rowand wrote:
>> Hi Alan,
>>
>> In the RFC thread "of: Add whitelist", I did not understand the use case and
>> asked you some questions (30 Nov 2017 07:46:36 -0500), that you seem to
On 12/05/17 11:33, Alan Tull wrote:
> On Thu, Nov 30, 2017 at 6:46 AM, Frank Rowand wrote:
>> On 11/29/17 11:11, Alan Tull wrote:
>>> On Wed, Nov 29, 2017 at 7:31 AM, Rob Herring wrote:
>>>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand
>>>> wrote
On 12/05/17 11:55, Alan Tull wrote:
> On Thu, Nov 30, 2017 at 6:18 AM, Frank Rowand wrote:
>> On 11/29/17 08:31, Rob Herring wrote:
>>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand
>>> wrote:
>>>> On 11/27/17 15:58, Alan Tull wrote:
>>>>&
On 11/30/17 09:39, Rob Herring wrote:
> On Wed, Nov 29, 2017 at 4:47 PM, Frank Rowand wrote:
>> On 11/29/17 04:20, Frank Rowand wrote:
>>> On 11/27/17 15:58, Alan Tull wrote:
>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>&
_overlay_apply() error path
> of: overlay: Fix (un)locking in of_overlay_apply()
>
> drivers/of/overlay.c | 31 +--
> 1 file changed, 13 insertions(+), 18 deletions(-)
>
Thank you, the code is much improved by these patches.
Reviewed-by: Frank Rowand
On 12/05/17 08:58, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Tue, Dec 5, 2017 at 2:45 PM, Frank Rowand wrote:
>> On 12/05/17 03:01, Geert Uytterhoeven wrote:
>>> On Tue, Dec 5, 2017 at 3:07 AM, Frank Rowand wrote:
>>>> Also, the previous version of the
On 12/05/17 05:49, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Tue, Dec 5, 2017 at 9:01 AM, Geert Uytterhoeven
> wrote:
>> On Tue, Dec 5, 2017 at 3:07 AM, Frank Rowand wrote:
>>> On 12/04/17 10:47, Geert Uytterhoeven wrote:
>>>> If of_resolve_phandl
On 12/05/17 03:01, Geert Uytterhoeven wrote:
> Hi Frank,
>
> On Tue, Dec 5, 2017 at 3:07 AM, Frank Rowand wrote:
>> On 12/04/17 10:47, Geert Uytterhoeven wrote:
>>> If of_resolve_phandles() fails, free_overlay_changeset() is called in
>>> the error path. Howeve
Hi Geert,
Thanks for finding the issues and for the fixes.
Comments in line.
On 12/04/17 10:47, Geert Uytterhoeven wrote:
> If of_resolve_phandles() fails, free_overlay_changeset() is called in
> the error path. However, that function returns early if the list hasn't
> been initialized yet, be
On 12/04/17 14:45, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Mon, Dec 4, 2017 at 8:35 PM, Rob Herring wrote:
>> On Mon, Dec 4, 2017 at 9:47 AM, Geert Uytterhoeven
>> wrote:
>>> The special overlay mutex is taken first, hence it should be released
>>> last in the error path.
>>>
>>> Move "mutex_
Hi Alan,
In the RFC thread "of: Add whitelist", I did not understand the use case and
asked you some questions (30 Nov 2017 07:46:36 -0500), that you seem to have
overlooked (or my mail server failed to deliver your answer to me). Can you
please answer that question so I can better understand thi
On 11/30/17 08:37, Frank Rowand wrote:
> Hi Colin, Rob,
>
> On 11/30/17 07:18, Colin Ian King wrote:
>> On 30/11/17 12:14, Frank Rowand wrote:
>>> On 11/29/17 14:17, Colin King wrote:
>>>> From: Colin Ian King
>>>>
>>>> Currently if
Hi Colin, Rob,
On 11/30/17 07:18, Colin Ian King wrote:
> On 30/11/17 12:14, Frank Rowand wrote:
>> On 11/29/17 14:17, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> Currently if the call to of_resolve_phandles fails then then ovcs
>>> is not kfr
On 11/29/17 11:11, Alan Tull wrote:
> On Wed, Nov 29, 2017 at 7:31 AM, Rob Herring wrote:
>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand wrote:
>>> On 11/27/17 15:58, Alan Tull wrote:
>>>> Here's a proposal for a whitelist to lock down the dynamic device t
On 11/29/17 08:31, Rob Herring wrote:
> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand wrote:
>> On 11/27/17 15:58, Alan Tull wrote:
>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>
>>> For an overlay to be accepted, all o
On 11/29/17 14:17, Colin King wrote:
> From: Colin Ian King
>
> Currently if the call to of_resolve_phandles fails then then ovcs
> is not kfree'd on the error exit path. Rather than try and make
> the clean up exit path more convoluted, fix this by just kfree'ing
> ovcs at the point of error de
On 11/29/17 04:20, Frank Rowand wrote:
> On 11/27/17 15:58, Alan Tull wrote:
>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>
>> For an overlay to be accepted, all of its targets are required to be
>> on a target node whitelist.
>&g
On 11/29/17 04:20, Frank Rowand wrote:
> On 11/27/17 15:58, Alan Tull wrote:
>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>
>> For an overlay to be accepted, all of its targets are required to be
>> on a target node whitelist.
>&g
On 11/28/17 14:26, Alan Tull wrote:
> On Tue, Nov 28, 2017 at 9:15 AM, Rob Herring wrote:
>> On Mon, Nov 27, 2017 at 02:58:03PM -0600, Alan Tull wrote:
>>> Add simple whitelist. When an overlay is submitted, if any target in
>>> the overlay is not in the whitelist, the overlay is rejected. Drive
On 11/27/17 15:58, Alan Tull wrote:
> Here's a proposal for a whitelist to lock down the dynamic device tree.
>
> For an overlay to be accepted, all of its targets are required to be
> on a target node whitelist.
>
> Currently the only way I have to get on the whitelist is calling a
> function to
, 3 insertions(+), 4 deletions(-)
>
All patches:
Reviewed-by: Frank Rowand
Hi Geert,
I did not receive patch 1/2, can you please resend it?
-Frank
On 11/27/17 09:46, Geert Uytterhoeven wrote:
> Hi Pantelis, Rob, Frank,
>
> Here are two locking fixes for OF overlays, found by code inspection.
>
> They were compile-tested only, as I'm still working on getting "re
Hi Ulf, Rob,
On 11/20/17 15:19, Ulf Samuelsson wrote:
>
>
> On 2017-11-20 05:32, Frank Rowand wrote:
>> Hi Ulf,
>>
>>
>> On 11/19/17 23:23, Frank Rowand wrote:
>>> adding devicetree list, devicetree maintainers
>>>
>>> On 11/18/17 1
Ulf,
On 11/20/17 06:44, Mark Rutland wrote:
> On Sun, Nov 19, 2017 at 11:23:42PM -0500, Frank Rowand wrote:
>> adding devicetree list, devicetree maintainers
>>
>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>> I noticed when checking out the OpenWRT support for t
Hi Ulf,
On 11/19/17 23:23, Frank Rowand wrote:
> adding devicetree list, devicetree maintainers
>
> On 11/18/17 12:59, Ulf Samuelsson wrote:
>> I noticed when checking out the OpenWRT support for the board that they have
>> a method to avoid having to pass the device tree
adding devicetree list, devicetree maintainers
On 11/18/17 12:59, Ulf Samuelsson wrote:
> I noticed when checking out the OpenWRT support for the board that they have
> a method to avoid having to pass the device tree address to the kernel, and
> can thus boot device tree based kernels with U-bo
On 11/16/17 13:05, Rob Herring wrote:
> Remove the manually added __local_fixups__ because dtc can now generate
> them. This also fixes a new warning in the process:
>
> drivers/of/unittest-data/testcases.dtb: Warning
> (interrupts_extended_property): Could not get phandle node for
> /__local_fi
Hi Jyri,
On 11/13/17 07:40, Jyri Sarha wrote:
> On 11/13/17 07:58, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote:
>>>
>>> Today's linux-next merge of the devicetree tree got a conflict in:
>>>
>>> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>>
>>
Hi Michael,
On 11/12/17 03:49, Michael Ellerman wrote:
> Hi Frank,
>
> Frank Rowand writes:
>> Hi Michael, Tobin,
>>
>> On 11/08/17 04:10, Michael Ellerman wrote:
>>> "Tobin C. Harding" writes:
>>>> Currently we are leaking addre
Hi Michael, Tobin,
On 11/08/17 04:10, Michael Ellerman wrote:
> "Tobin C. Harding" writes:
>> Currently we are leaking addresses from the kernel to user space. This
>> script is an attempt to find some of those leakages. Script parses
>> `dmesg` output and /proc and /sys files for hex strings tha
->name);
> - kfree(prop->value);
> - kfree(prop);
> - prop = next;
> + property_list_free(node->properties);
> + property_list_free(node->deadprops);
>
> - if (!prop) {
> - prop = node->deadprops;
> - node->deadprops = NULL;
> - }
> - }
> kfree(node->full_name);
> kfree(node->data);
> kfree(node);
>
Hi Lixin,
My bad... Thanks for the fix.
Reviewed-by: Frank Rowand
Hi Lixin,
On 10/19/17 02:40, Lixin Wang wrote:
> If a node with no properties is dynamically added, then a property is
> dynamically added to the node, then the property is dynamically removed,
> the result will be node->properties == NULL and node->deadprops != NULL.
>
> Add a separate function
On 10/19/17 14:18, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> A device tree overlay notifier can return NOTIFY_OK, NOTIFY_STOP,
> or an embedded errno. overlay_notify() incorrectly reports an
> error for NOTIFY_OK.
>
> Reported-by: at...@kernel.org
> Sig
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 10/19/17 12:04, Alan Tull wrote:
> On Tue, Oct 17, 2017 at 6:36 PM, wrote:
>
>> static int overlay_notify(struct overlay_changeset *ovcs,
>> enum of_overlay_notify_action action)
>> {
>> @@ -86,8 +109,14 @@ static int overlay_notify(struct overlay_changeset *ovcs,
>>
>>
On 10/19/17 07:29, Alan Tull wrote:
> On Wed, Oct 18, 2017 at 5:34 PM, Frank Rowand wrote:
>> On 10/18/17 13:16, Rob Herring wrote:
>>> Use devicetree-compiler list for dtc issues please.
>>>
>>> On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand
>>> wr
On 10/18/17 13:16, Rob Herring wrote:
> Use devicetree-compiler list for dtc issues please.
>
> On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand wrote:
>> Hi Rob, Alan,
>>
>> On 10/18/17 08:58, Alan Tull wrote:
>>> Hi Rob,
>>>
>>> I've no
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/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
Hi Rob, Alan,
On 10/18/17 08:58, Alan Tull wrote:
> Hi Rob,
>
> I've noticed a problem compiling DT overlays and traced it back to
> beginning in next-20171009
>
> That tag adds the following in scripts/dtc
>
> e9480c1 2017-10-09 16:17:32 +0100 : Mark Brown : Merge remote-tracking
> branch 'dev
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/17/17 07:38, Rob Herring wrote:
> On Mon, Oct 16, 2017 at 8:17 PM, wrote:
>> From: Frank Rowand
>>
>> This patch is aimed primarily at drivers/of/overlay.c, but those
>> changes also have a small impact in a few other files.
>>
>> overlay.c is d
On 10/16/17 18:17, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> I have found the device tree overlay code to be difficult to read and
> maintain. This patch series attempts to improve that situation.
>
> The cleanup includes some changes visible to users of overla
On 10/16/17 18:17, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The process of applying an overlay consists of:
> - unflatten an overlay FDT (flattened device tree) into an
> EDT (expanded device tree)
> - fixup the phandle values in the overlay EDT to fi
On 10/16/17 13:46, Rob Herring wrote:
> On Tue, Oct 10, 2017 at 8:02 PM, wrote:
>> From: Frank Rowand
>>
>> Move more code into of_overlay_apply() so that it does not have
>> to be duplicated by each caller of of_overlay_apply().
>>
>> The test in of_reso
+ me
On 09/28/17 03:45, Sudeep Holla wrote:
> Since "/firmware" does not have its own "compatible" property as it's
> just collection of nodes representing firmware interface, it's sub-nodes
> are not populated during system initialization.
>
> Currently different firmware drivers search the /fir
+ me
On 09/28/17 03:45, Sudeep Holla wrote:
> Hi Rob, Arnd,
>
> There's a push to place all firmware related device node under
> /firmware/ node. However all the associated drivers are dealing with
> device creation in their own ways. For example, qcom_scm, optee and
> meson-sm drivers deal with
h your patches? Or I have
> to wait for your patches merged? Thanks.
>
> -Original Message-----
> From: Frank Rowand [mailto:frowand.l...@gmail.com]
> Sent: Saturday, October 14, 2017 6:05 AM
> To: Wang, Alan 1. (NSB - CN/Hangzhou) ; Pantelis
> Antoniou ; Rob Herring
e body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
The code looks right to me. The patch description is confusing to me.
If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.
Reviewed-by: Frank Rowand
Hi Rob,
On 07/25/17 13:36, Rob Herring wrote:
> On Tue, Apr 25, 2017 at 7:09 PM, wrote:
>> From: Frank Rowand
>>
>> Existing overlay unit tests examine individual pieces of the overlay
>> code. The new tests target the entire process of applying an overlay.
>&g
off) = cpu_to_be32(phandle);
> + be32_add_cpu(prop->value + off, phandle_delta);
> }
> }
>
>
Reviewed-by: Frank Rowand
GFP_KERNEL);
> + value = kmemdup(prop_fixup->value, prop_fixup->length, GFP_KERNEL);
> if (!value)
> return -ENOMEM;
> - memcpy(value, prop_fixup->value, prop_fixup->length);
>
> /* prop_fixup contains a list of tuples of path:property_name:offset */
> end = value + prop_fixup->length;
>
Reviewed-by: Frank Rowand
pr_err("%s: Failed to resolve phandles (rc=%i)\n", __func__,
> rc);
> @@ -2262,7 +2261,6 @@ static int __init overlay_data_add(int onum)
> ret = 0;
> goto out_free_data;
> }
> - of_node_set_flag(info->np_overlay, OF_DETAC
t; + * @detached: if true set OF_DETACHED on @mynodes
> *
> * Returns NULL on failure or the memory chunk containing the unflattened
> * device tree on success.
>
Reviewed-by: Frank Rowand
Hi Rob,
On 10/12/17 20:07, Lixin Wang wrote:
> From: alawang
>
> Hello,
>
> Sorry It was my fault in last email that wrote the wrong subject and sign off
> name.
> Correct them this time.
> Thanks
>
> Function of_changeset_add_property or of_changeset_update_property may
> fails. In this case
Hi Rob,
On 10/02/17 20:53, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> I have found the device tree overlay code to be difficult to read and
> maintain. This patch series attempts to improve that situation.
>
> The cleanup includes some changes visible to users
On 10/12/17 18:53, alawang wrote:
> Function of_changeset_add_property or of_changeset_update_property may
> fails. In this case the property just allocated is never deallocated.
>
> Signed-off-by: alawang
> ---
> drivers/of/overlay.c | 15 +++
> 1 file changed, 11 insertions(+), 4 d
On 10/10/17 11:26, Rob Herring wrote:
> +Frank
>
> On Tue, Oct 10, 2017 at 12:33 PM, Randy Dunlap wrote:
>> On 10/09/17 14:21, Mark Brown wrote:
>>> For my birthday I've gone and got myself a linux-next tree:
>>>
>>> Changes since 20170929:
>>>
>>> The net-next and drm trees lost their build fail
On 10/10/17 14:06, Rob Herring wrote:
> On Tue, Oct 10, 2017 at 2:39 PM, Frank Rowand wrote:
< snip >
>
> AFAICT, I don't think anything between of_resolve_phandles and
> of_overlay_apply calls in tilcdc depends on the phandles being fixed
> up.
I think you are co
On 10/10/17 14:06, Rob Herring wrote:
> On Tue, Oct 10, 2017 at 2:39 PM, Frank Rowand wrote:
>> On 10/10/17 11:40, Rob Herring wrote:
>>> On Wed, Oct 04, 2017 at 08:29:59PM -0700, Frank Rowand wrote:
>>>> On 10/04/17 08:19, Rob Herring wrote:
>>>>
On 10/10/17 11:40, Rob Herring wrote:
> On Wed, Oct 04, 2017 at 08:29:59PM -0700, Frank Rowand wrote:
>> On 10/04/17 08:19, Rob Herring wrote:
>>> On Mon, Oct 2, 2017 at 10:53 PM, wrote:
>>>> From: Frank Rowand
>>>>
>>>> The process of
On 10/09/17 11:59, Rob Herring wrote:
> On Sun, Oct 8, 2017 at 5:57 PM, Frank Rowand wrote:
>> On 10/03/17 09:18, Rob Herring wrote:
>>> For static DT usecases, we don't need the disabled nodes and can skip
>>> unflattening. This saves a significant amount of RAM
On 10/07/17 03:23, Pantelis Antoniou wrote:
> Hi Rob,
>
>> On Oct 6, 2017, at 16:55 , Rob Herring wrote:
>>
>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>> wrote:
>>> Hi Rob,
< snip >
>>> eBPF is portable, can be serialized after compiling in the schema file
>>> and can be executed in
401 - 500 of 953 matches
Mail list logo
