On 4/8/21 9:20 PM, Guenter Roeck wrote:
> On 4/8/21 3:53 PM, Frank Rowand wrote:
>> On 4/8/21 4:54 PM, Guenter Roeck wrote:
>>> On 4/8/21 2:28 PM, Rob Herring wrote:
>>>>
>>>> Applying now so this gets into linux-next this week.
>>>>
&
On 4/8/21 4:54 PM, Guenter Roeck wrote:
> On 4/8/21 2:28 PM, Rob Herring wrote:
>>
>> Applying now so this gets into linux-next this week.
>>
> The patch doesn't apply on top of today's -next; it conflicts
> with "of: properly check for error returned by fdt_get_name()".
>
> I reverted that patch
On 4/8/21 4:28 PM, Rob Herring wrote:
> On Thu, Apr 8, 2021 at 3:45 PM wrote:
>>
>> From: Frank Rowand
>>
>> The Devicetree standard specifies an 8 byte alignment of the FDT.
>> Code in libfdt expects this alignment for an FDT image in memory.
>> kmemdup
On 4/8/21 1:27 PM, Rob Herring wrote:
> On Thu, Apr 8, 2021 at 10:17 AM wrote:
>>
>> From: Frank Rowand
>>
>> The Devicetree standard specifies an 8 byte alignment of the FDT.
>> Code in libfdt expects this alignment for an FDT image in memory.
>> kmemdup
Hi Guenter,
Thanks for the review!
On 4/8/21 10:32 AM, Guenter Roeck wrote:
> On 4/8/21 8:17 AM, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> The Devicetree standard specifies an 8 byte alignment of the FDT.
>> Code in libfdt expects this alignment
Hi Rob,
I had a git hiccup, this is not the version I meant to send. v3 coming shortly.
-Frank
On 4/8/21 9:43 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The Devicetree standard specifies an 8 byte alignment of the FDT.
> Code in libfdt expects this alignment for
On 4/7/21 5:01 PM, Guenter Roeck wrote:
> On 4/7/21 1:59 PM, Frank Rowand wrote:
>> Hi Guenter,
>>
>> On 4/7/21 3:51 PM, frowand.l...@gmail.com wrote:
>>> From: Frank Rowand
>>>
>>> The Devicetree standard specifies an 8 byte alignment of the FDT.
On 4/7/21 4:34 PM, Rob Herring wrote:
> On Wed, Apr 7, 2021 at 3:51 PM wrote:
>>
>> From: Frank Rowand
>>
>> The Devicetree standard specifies an 8 byte alignment of the FDT.
>> Code in libfdt expects this alignment for an FDT image in memory.
>> kmemdup
On 4/6/21 3:30 PM, Frank Rowand wrote:
> On 4/6/21 2:21 PM, Rob Herring wrote:
>> On Sun, Apr 04, 2021 at 10:28:45PM -0500, frowand.l...@gmail.com wrote:
>>> From: Frank Rowand
>>>
>>> fdt_get_name() returns error values via a parameter pointer
>>>
Hi Guenter,
On 4/7/21 3:51 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The Devicetree standard specifies an 8 byte alignment of the FDT.
> Code in libfdt expects this alignment for an FDT image in memory.
> kmemdup() returns 4 byte alignment on openrisc. Replace k
On 4/6/21 2:21 PM, Rob Herring wrote:
> On Sun, Apr 04, 2021 at 10:28:45PM -0500, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> fdt_get_name() returns error values via a parameter pointer
>> instead of in function return. Fix check for this error valu
Adding Rob, so that he will be in the loop.
-Frank
On 4/5/21 12:28 PM, Guenter Roeck wrote:
> On 4/5/21 10:14 AM, Linus Torvalds wrote:
>> On Mon, Apr 5, 2021 at 10:10 AM Guenter Roeck wrote:
>>>
>>> No change in test results since last week [..]
>>
>> Let's ping Frank for the alignment issue.
, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> fdt_get_name() returns error values via a parameter pointer
> instead of in function return. Fix check for this error value
> in populate_node() and callers of populate_node().
>
> Chasing up the caller tree showed callers
On 3/27/21 12:40 PM, Rob Herring wrote:
> On Wed, Mar 24, 2021 at 05:37:13PM -0500, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> Add Makefile rule to build .dtbo.o assembly file from overlay .dtso
>> source file.
>>
>> Rename unittest .dts o
On 3/29/21 1:21 PM, Rob Herring wrote:
> On Sat, Mar 27, 2021 at 5:41 PM Guenter Roeck wrote:
>>
>> If an unaligned pointer is passed to of_fdt_unflatten_tree(),
>> populate_node() as called from unflatten_dt_nodes() will fail.
>> unflatten_dt_nodes() will return 0 and set *nodepp to NULL.
>> This
On 3/29/21 1:41 PM, Rob Herring wrote:
> n Mon, Mar 29, 2021 at 1:05 PM Linus Torvalds
> wrote:
>>
>> On Sun, Mar 28, 2021 at 7:07 PM Guenter Roeck wrote:
>>>
>>> This is not really a new problem. I enabled devicetree unit tests
>>> in the openrisc kernel and was rewarded with a crash.
>>> https:
Hi Viresh,
On 3/24/21 2:34 AM, Frank Rowand wrote:
> On 3/16/21 12:42 AM, Viresh Kumar wrote:
>> On 16-03-21, 00:36, Frank Rowand wrote:
>>> I should have looked at patch 3/5 more carefully instead of counting on
>>> Masahiro to check it out and simply build testing.
On 3/16/21 12:42 AM, Viresh Kumar wrote:
> On 16-03-21, 00:36, Frank Rowand wrote:
>> I should have looked at patch 3/5 more carefully instead of counting on
>> Masahiro to check it out and simply build testing.
>>
>> Patch 3/5 does not seem correct. I'll lo
of_node_put(node);
> goto err_free_fragments;
> }
>
Reviewed-by: Frank Rowand
Tested-by: Frank Rowand
While reading through the code touched by the patch I noticed that
the clean up at label err_free_fragments does not do the required
of_node_put() calls. I'll add creating a patch to fix that to my
todo list.
-Frank
On 3/15/21 5:12 PM, Laurent Pinchart wrote:
> Hi Yamada-san,
>
> On Tue, Mar 16, 2021 at 02:43:45AM +0900, Masahiro Yamada wrote:
>> On Mon, Mar 15, 2021 at 3:40 PM Viresh Kumar wrote:
>>> On 14-03-21, 20:16, Frank Rowand wrote:
>>>> On 3/12/21 11:11 PM, Frank
On 3/15/21 1:40 AM, Viresh Kumar wrote:
> On 14-03-21, 20:16, Frank Rowand wrote:
>> On 3/12/21 11:11 PM, Frank Rowand wrote:
>>> On 3/12/21 1:13 AM, Viresh Kumar wrote:
>>>> On 12-03-21, 01:09, Frank Rowand wrote:
>>>>> I suggested having the .dts
Hi VIresh,
On 3/12/21 11:11 PM, Frank Rowand wrote:
> On 3/12/21 1:13 AM, Viresh Kumar wrote:
>> On 12-03-21, 01:09, Frank Rowand wrote:
>>> I suggested having the .dtso files include the .dts file because that is a
>>> relatively
>>> small and easy change to
On 3/12/21 1:13 AM, Viresh Kumar wrote:
> On 12-03-21, 01:09, Frank Rowand wrote:
>> I suggested having the .dtso files include the .dts file because that is a
>> relatively
>> small and easy change to test. What would probably make more sense is the
>> rename
>>
On 3/12/21 1:03 AM, Frank Rowand wrote:
> Hi Viresh,
>
> On 3/11/21 10:47 PM, Viresh Kumar wrote:
>> On 10-03-21, 20:24, Masahiro Yamada wrote:
>>> Even without "-I dts",
>>>
>>>inform = guess_input_format(arg, "dts");
>>>
Hi Viresh,
On 3/11/21 10:47 PM, Viresh Kumar wrote:
> On 10-03-21, 20:24, Masahiro Yamada wrote:
>> Even without "-I dts",
>>
>>inform = guess_input_format(arg, "dts");
>>
>> seems to fall back to "dts" anyway,
>> but I guess you wanted to make this explicit, correct?
>
>
>>> +# Required for
On 3/11/21 10:31 PM, Viresh Kumar wrote:
> On 11-03-21, 17:27, Frank Rowand wrote:
>> On 3/9/21 11:35 PM, Viresh Kumar wrote:
>>> Viresh Kumar (4):
>>> kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
>>> kbuild: Allow .dtso format for overlay sou
sion I used to test
this series.
There is still confusion caused by the contortions that unittest
goes through to mis-use base DTBs vs overlay DTBs, so _after_
this series is merged by Rob, I will poke around and see if
I can change unittest so that it does not look like it is
mis-using DTBs and overlay DTBs.
Reviewed-by: Frank Rowand
Tested-by: Frank Rowand
On 3/10/21 9:15 AM, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 11:47 PM Viresh Kumar wrote:
>>
>> On 10-03-21, 20:24, Masahiro Yamada wrote:
>>> On Wed, Mar 10, 2021 at 2:35 PM Viresh Kumar
>>> wrote:
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index bc045a54a34e..59
Hi Viresh,
I commented on this patch in v7 after you had created v8. You acknowledged
that comment and said that it will be corrected.
-Frank
On 2/12/21 5:18 AM, Viresh Kumar wrote:
> In order to build-test the same unit-test files using fdtoverlay tool,
> move the device nodes from the existin
Hi Viresh,
On 3/1/21 12:56 AM, Viresh Kumar wrote:
> On 12-02-21, 16:48, Viresh Kumar wrote:
>> Hi,
>>
>> This patchset adds a generic rule for applying overlays using fdtoverlay
>> tool and then updates unittests to get built statically using the same.
>>
>> V7->V8:
>> - Patch 1 is new.
>> - Plat
On 2/5/21 3:08 PM, Rob Herring wrote:
> On Fri, Feb 05, 2021 at 11:17:10AM +0100, Geert Uytterhoeven wrote:
>> Hi Viresh,
>>
>> On Fri, Feb 5, 2021 at 10:55 AM Viresh Kumar wrote:
>>> On 05-02-21, 10:41, Geert Uytterhoeven wrote:
On Fri, Feb 5, 2021 at 10:25 AM Viresh Kumar
wrote:
On 2/24/21 7:00 AM, Enrico Weigelt, metux IT consult wrote:
> On 15.02.21 02:12, Frank Rowand wrote:
>
>> Why not compile in ACPI data (tables?) instead of devicetree description?
>
> The problem is a bit more complex than it might seem.
>
> Let's take the A
Hi Viresh,
I am in the wrong version with the comments below. You are at version 8 now.
-Frank
On 2/18/21 3:02 PM, Frank Rowand wrote:
> On 1/29/21 1:24 AM, Viresh Kumar wrote:
>> In order to build-test the same unit-test files using fdtoverlay tool,
>> move the device nodes fr
On 1/29/21 1:24 AM, Viresh Kumar wrote:
> In order to build-test the same unit-test files using fdtoverlay tool,
> move the device nodes from the existing overlay_base.dts and
> testcases_common.dts files to .dtsi counterparts. The .dts files now
> include the new .dtsi files, resulting in exactly
+Frank, Rob, devicetree list
On 2/16/21 9:35 AM, Michal Simek wrote:
> Hi,
>
> I have a question about expectations when pinctrl setting is applied. In
> DTS all nodes are described in the order available in DT.
>
> uart-default {
> mux {
> ...
> };
>
> conf {
>
On 2/12/21 5:54 AM, Enrico Weigelt, metux IT consult wrote:
> On 12.02.21 10:58, Linus Walleij wrote:
>
> Hi,
>
>> I think Intel people often take the stance that the ACPI DSDT (or whatever)
>> needs to be fixed.
>
> It should, actually board/firmware vendors should think more carefully
> and do
On 2/8/21 5:48 PM, Rob Herring wrote:
> +Johan H
>
> On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult
> wrote:
>>
>> Hello folks,
>>
>> here's an RFC for using compiled-in dtb's for initializing board devices
>> that can't be probed via bus'es or firmware.
I've just been monitorin
On 2/6/21 8:35 AM, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski wrote:
>> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
>>>
>>>
>>> Samsung DTS ARM changes for v5.12
>>>
>>> 1. Use
Hi Viresh,
Second attempt, I think the first reply did not properly send.
On 1/26/21 11:56 PM, Viresh Kumar wrote:
> On 22-01-21, 16:20, Viresh Kumar wrote:
>> In order to build-test the same unit-test files using fdtoverlay tool,
>> move the device nodes from the existing overlay_base.dts and
>>
On 1/22/21 4:50 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need fdtoverlay going forward. Lets start building it.
>
> The fdtoverlay program applies (or merges) one or more overlay dtb
> blobs to a base dtb blob. The kernel build system w
Hi Viresh,
On 1/26/21 11:56 PM, Viresh Kumar wrote:
> On 22-01-21, 16:20, Viresh Kumar wrote:
>> In order to build-test the same unit-test files using fdtoverlay tool,
>> move the device nodes from the existing overlay_base.dts and
>> testcases_common.dts files to .dtsi files. The .dts files now i
+frank
On 1/25/21 3:53 PM, Masahiro Yamada wrote:
> On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König
> wrote:
>>
>> Adding the -@ switch to dtc results in the binary devicetrees containing
>> a list of symbolic references and their paths. This is necessary to
>> apply device tree overlays e.g. o
+frank
On 1/25/21 4:57 AM, Uwe Kleine-König wrote:
> Adding the -@ switch to dtc results in the binary devicetrees containing
> a list of symbolic references and their paths. This is necessary to
> apply device tree overlays e.g. on Raspberry Pi as described on
> https://www.raspberrypi.org/docume
Hi Uwe,
On 1/26/21 12:03 PM, Frank Rowand wrote:
> +frank
>
> On 1/26/21 1:20 AM, Uwe Kleine-König wrote:
>> Hello Masahiro,
>>
>> On 1/25/21 10:53 PM, Masahiro Yamada wrote:
>>> On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König
>>> wrote:
>>
+frank
On 1/26/21 1:20 AM, Uwe Kleine-König wrote:
> Hello Masahiro,
>
> On 1/25/21 10:53 PM, Masahiro Yamada wrote:
>> On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König
>> wrote:
>>>
>>> Adding the -@ switch to dtc results in the binary devicetrees containing
>>> a list of symbolic references a
+frank
On 1/26/21 2:43 AM, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> On Tue, Jan 26, 2021 at 8:21 AM Uwe Kleine-König
> wrote:
>> And then I learned with hints from Rob and Geert that symbols are not
>> really necessary for overlays, you just cannot use named labels. But
>> using
>>
>> ta
+frank
On 1/25/21 5:15 AM, Cyril Brulebois wrote:
> Hi,
>
> Uwe Kleine-König (2021-01-25):
>> Adding the -@ switch to dtc results in the binary devicetrees containing
>> a list of symbolic references and their paths. This is necessary to
>> apply device tree overlays e.g. on Raspberry Pi as desc
On 1/22/21 4:50 AM, Viresh Kumar wrote:
> Hi Frank/Rob,
>
> This patchset makes necessary changes to the kernel to add support for
> building overlays (%.dtbo) and the required fdtoverlay tool. This also
> builds static_test.dtb using most of the existing overlay tests present
> in drivers/of/unit
Hi David,
On 1/22/21 12:34 AM, David Gibson wrote:
> On Wed, Jan 20, 2021 at 10:47:40AM +0530, Viresh Kumar wrote:
>> +David.
>>
>> On 19-01-21, 11:12, Frank Rowand wrote:
>>> On 1/12/21 2:28 AM, Viresh Kumar wrote:
>>>> We will start building ove
On 1/25/21 9:15 PM, Frank Rowand wrote:
> On 1/22/21 4:50 AM, Viresh Kumar wrote:
>> Now that fdtoverlay is part of the kernel build, start using it to test
>> the unitest overlays we have by applying them statically. Create a new
>> base file static_base.dts which inclu
On 1/22/21 9:07 PM, David Gibson wrote:
> On Fri, Jan 22, 2021 at 04:20:35PM +0530, Viresh Kumar wrote:
>> In order to build-test the same unit-test files using fdtoverlay tool,
>> move the device nodes from the existing overlay_base.dts and
>> testcases_common.dts files to .dtsi files. The .dts fi
On 1/22/21 4:50 AM, Viresh Kumar wrote:
> Now that fdtoverlay is part of the kernel build, start using it to test
> the unitest overlays we have by applying them statically. Create a new
> base file static_base.dts which includes other .dtsi files.
>
> Some unittest overlays deliberately contain e
On 1/20/21 11:58 PM, Viresh Kumar wrote:
> On 20-01-21, 23:55, Frank Rowand wrote:
>> yes, but using the modified versions ("/plugin/;" removed) of
>> testcases.dtb and overlay_base.dtb.
>
> Okay, that would work fine I guess. I will try to implement this in
>
On 1/20/21 11:43 PM, Viresh Kumar wrote:
> Hi Frank,
>
> On 20-01-21, 23:34, Frank Rowand wrote:
>> It should be possible to apply this same concept to copying overlay_base.dts
>> to overlay_base_base.dts, removing the "/plugin/;" from overlay_base_base.dts
>>
On 1/20/21 11:34 PM, Viresh Kumar wrote:
> On 20-01-21, 23:14, Frank Rowand wrote:
>> It is a convenient FDT to use because it provides the frame that the overlays
>> require to be applied. It is fortunate that fdtoverlay does not reject the
>> use
>> of an FDT with o
On 1/20/21 10:13 PM, Viresh Kumar wrote:
> On 21-01-21, 11:49, David Gibson wrote:
>> If you're using overlays, you probably need the -@ flag, for both the
>> base file and the overlays, which AFAICT is not already the case.
>
> I think the idea was to do that in the platform specific Makefiles,
>
Hi Viresh,
On 1/20/21 11:14 PM, Frank Rowand wrote:
> Hi David,
>
> On 1/20/21 6:51 PM, David Gibson wrote:
>> On Wed, Jan 20, 2021 at 12:36:47PM +0530, Viresh Kumar wrote:
>>> Now that fdtoverlay is part of the kernel build, start using it to test
>>> the uni
Hi David,
On 1/20/21 6:51 PM, David Gibson wrote:
> On Wed, Jan 20, 2021 at 12:36:47PM +0530, Viresh Kumar wrote:
>> Now that fdtoverlay is part of the kernel build, start using it to test
>> the unitest overlays we have by applying them statically.
>>
>> Some unittest overlays deliberately contai
+David
so I don't have to repeat this in another thread
On 1/19/21 11:06 PM, Viresh Kumar wrote:
> On 19-01-21, 09:44, Frank Rowand wrote:
>> No. overlay_base.dts is intentionally compiled into a base FDT, not
>> an overlay. Unittest intentionally unflattens this FDT
On 1/12/21 2:28 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need fdtoverlay tool going forward. Lets start fetching and
> building it.
>
> While at it, also remove fdtdump.c file, which isn't used by the kernel.
>
> V4:
> - Don't fetch an
Hi Viresh,
I made these comments in the v2 patch series. I am copying them here since
this is the current version.
On 1/12/21 2:29 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need fdtoverlay going forward. Lets start building it.
>
> Th
On 1/19/21 10:28 AM, Frank Rowand wrote:
> On 1/6/21 11:15 PM, Viresh Kumar wrote:
>> We will start building overlays for platforms soon in the kernel and
>> would need these tools going forward. Lets start building them.
>>
>> Signed-off-by: Viresh Kumar
>>
On 1/12/21 2:29 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need fdtoverlay tool going forward. Lets start fetching it.
>
> Signed-off-by: Viresh Kumar
> ---
> scripts/dtc/update-dtc-source.sh | 6 +++---
> 1 file changed, 3 insertions(+
On 1/19/21 10:21 AM, Frank Rowand wrote:
> On 1/6/21 11:15 PM, Viresh Kumar wrote:
>> We will start building overlays for platforms soon in the kernel and
>> would need these tools going forward. Lets start fetching them.
>>
>> Note that a copy of fdtdump.c was already c
On 1/6/21 11:15 PM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start building them.
>
> Signed-off-by: Viresh Kumar
> ---
> scripts/dtc/Makefile | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletio
On 1/6/21 11:15 PM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start fetching them.
>
> Note that a copy of fdtdump.c was already copied back in the year 2012,
> but was never updated or built for some rea
On 1/19/21 2:05 AM, Viresh Kumar wrote:
> On 18-01-21, 20:21, frowand.l...@gmail.com wrote:
>> From: Frank Rowand
>>
>> These changes apply on top of the patches in:
>>
>> [PATCH] of: unittest: Statically apply overlays
On 1/17/21 9:54 PM, Frank Rowand wrote:
> Hi Viresh,
>
> On 1/14/21 11:44 PM, Viresh Kumar wrote:
>> +David,
>>
>> On 14-01-21, 09:01, Rob Herring wrote:
>>> On Wed, Jan 13, 2021 at 11:03 PM Viresh Kumar
>>> wrote:
>>>>
>>>>
On 1/18/21 12:30 AM, David Gibson wrote:
> On Fri, Jan 15, 2021 at 11:14:50AM +0530, Viresh Kumar wrote:
>> +David,
>>
>> On 14-01-21, 09:01, Rob Herring wrote:
>>> On Wed, Jan 13, 2021 at 11:03 PM Viresh Kumar
>>> wrote:
On 11-01-21, 09:46, Rob Herring wrote:
> On Fri, Jan 8, 2021
On 1/13/21 11:00 PM, Viresh Kumar wrote:
> Frank/Rob.
>
> On 08-01-21, 14:11, Viresh Kumar wrote:
>> diff --git a/drivers/of/unittest-data/Makefile
>> b/drivers/of/unittest-data/Makefile
>> index 009f4045c8e4..f17bce85f65f 100644
>> --- a/drivers/of/unittest-data/Makefile
>> +++ b/drivers/of/unit
Hi Viresh,
On 1/14/21 11:44 PM, Viresh Kumar wrote:
> +David,
>
> On 14-01-21, 09:01, Rob Herring wrote:
>> On Wed, Jan 13, 2021 at 11:03 PM Viresh Kumar
>> wrote:
>>>
>>> On 11-01-21, 09:46, Rob Herring wrote:
On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar
wrote:
>
> Now that
On 1/13/21 9:05 AM, Rob Herring wrote:
> On Tue, Jan 12, 2021 at 8:20 PM Frank Rowand wrote:
>>
>> On 1/12/21 2:46 PM, Rob Herring wrote:
>>> On Tue, Jan 12, 2021 at 2:05 PM Frank Rowand wrote:
>>>>
>>>> On 1/12/21 1:41 PM, Rob Herring wrote:
&g
On 1/12/21 2:46 PM, Rob Herring wrote:
> On Tue, Jan 12, 2021 at 2:05 PM Frank Rowand wrote:
>>
>> On 1/12/21 1:41 PM, Rob Herring wrote:
>>> On Tue, Jan 12, 2021 at 1:06 PM Frank Rowand wrote:
>>>>
>>>> On 1/12/21 8:04 AM, Rob Herring wrote:
&g
On 1/12/21 1:41 PM, Rob Herring wrote:
> On Tue, Jan 12, 2021 at 1:06 PM Frank Rowand wrote:
>>
>> On 1/12/21 8:04 AM, Rob Herring wrote:
>>> On Mon, Jan 11, 2021 at 4:06 PM Frank Rowand wrote:
>>>>
>>>> On 1/8/21 2:41 AM, Viresh Kumar wrote:
>&
On 1/12/21 8:04 AM, Rob Herring wrote:
> On Mon, Jan 11, 2021 at 4:06 PM Frank Rowand wrote:
>>
>> On 1/8/21 2:41 AM, Viresh Kumar wrote:
>>> Now that fdtoverlay is part of the kernel build, start using it to test
>>> the unitest overlays we have by applying
On 1/11/21 11:08 PM, Viresh Kumar wrote:
> On 11-01-21, 18:44, Frank Rowand wrote:
>> On 1/7/21 12:25 AM, Viresh Kumar wrote:
>>> We will start building overlays for platforms soon in the kernel and
>>> would need these tools going forward. Lets start building them.
>
On 1/12/21 4:16 AM, Bill Mills wrote:
>
>
> On 1/12/21 3:37 AM, Viresh Kumar wrote:
>> On 11-01-21, 20:22, Bill Mills wrote:
>>> On 1/11/21 5:06 PM, Frank Rowand wrote:
>>>> NACK to this specific patch, in its current form.
>>>>
>>>> T
Hi Viresh,
I may have an email hiccup, but I don't see a "[PATCH V3 1/2]" email, I
only see this "V3 2/2" email.
Please start each new version of a patch series as a stand alone email
instead of a reply to an email in a previous version of the series.
That way each patch series discussion stands
On 1/7/21 12:25 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start building them.
>
> The fdtoverlay program applies (or merges) one ore more overlay dtb
> blobs to a base dtb blob. The kernel build syst
On 1/5/21 9:37 AM, Rob Herring wrote:
> On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote:
>>
>> Update dtc compiler to accept dtbo as an outform.
>>
>> Signed-off-by: Viresh Kumar
>>
>> ---
>> I feel that this needs to go directly to
>> https://git.kernel.org/pub/scm/utils/dtc/dtc.git
>>
>> Righ
On 1/5/21 9:21 AM, Rob Herring wrote:
> On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote:
>>
>> Hello,
>>
>> Here is an attempt to make some changes in the kernel to allow building
>> of device tree overlays.
>>
>> While at it, I would also like to discuss about how we should mention
>> the base
Hi Viresh,
On 1/6/21 11:15 PM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start fetching them.
>
> Note that a copy of fdtdump.c was already copied back in the year 2012,
> but was never updated or built
On 1/11/21 9:46 AM, Rob Herring wrote:
> On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar wrote:
>>
>> Now that fdtoverlay is part of the kernel build, start using it to test
>> the unitest overlays we have by applying them statically.
>
> Nice idea.
>
>> The file overlay_base.dtb have symbols of its
On 1/8/21 2:41 AM, Viresh Kumar wrote:
> Now that fdtoverlay is part of the kernel build, start using it to test
> the unitest overlays we have by applying them statically.
>
> The file overlay_base.dtb have symbols of its own and we need to apply
> overlay.dtb to overlay_base.dtb alone first to m
On 12/4/20 7:23 AM, Paul Menzel wrote:
> Dear Wim, dear Daniel,
>
>
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
>
>> I agree with you. Using an existing standard is better than inventing
>> a new one in this case. I think using the
On 10/28/20 11:25 AM, Michael Auchter wrote:
> Hey Saravana,
>
> Thanks for taking the time to look into this!
>
> On Mon, Oct 26, 2020 at 12:10:33PM -0700, Saravana Kannan wrote:
>> On Wed, Oct 21, 2020 at 2:02 PM Frank Rowand wrote:
>>>
>>> Hi Saravana,
Hi Saravana,
Michael found an issue related to the removal of a devicetree node
which involves devlinks:
On 10/14/20 2:36 PM, Michael Auchter wrote:
> After updating to v5.9, I've started seeing errors in the kernel log
> when using device tree overlays. Specifically, the problem seems to
> happe
Hi Michael,
On 10/14/20 2:36 PM, Michael Auchter wrote:
> After updating to v5.9, I've started seeing errors in the kernel log
> when using device tree overlays. Specifically, the problem seems to
> happen when removing a device tree overlay that contains two devices
> with some dependency between
Hi Rob,
On 2020-08-26 08:54, Matthias Schiffer wrote:
> On Wed, 2020-08-26 at 08:01 -0500, Frank Rowand wrote:
>> On 2020-08-26 07:02, Matthias Schiffer wrote:
>>> Allow disabling CPU nodes using status = "disabled".
>>>
>>> This allows a bootloader t
On 2020-08-26 07:02, Matthias Schiffer wrote:
> Allow disabling CPU nodes using status = "disabled".
>
> This allows a bootloader to change the number of available CPUs (for
> example when a common DTS is used for SoC variants with different numbers
> of cores) without deleting the nodes altogethe
Hi Vaishnav,
Apologies in advance -- I expect to be very slow in responding this
week. Linux Plumbers will take some of my time and I am moving to
a new home.
-Frank
On 2020-08-18 15:38, Frank Rowand wrote:
> Hi Vaishnav,
>
> +me +devicetree
>
> Please add these two recip
Hi Vaishnav,
+me +devicetree
Please add these two recipients to future versions.
I will comment more after reading the first version and v2.
-Frank
On 2020-08-18 07:48, Vaishnav M A wrote:
> Hi,
>
> This Patch series is an update to the mikroBUS driver
> RFC v1 Patch : https://lkml.org/lkml/
On 2020-08-12 08:27, Enrico Weigelt, metux IT consult wrote:
> On 07.08.20 16:17, Sven Van Asbroeck wrote:
>
> Hi,
>
>> I believe you're asking: "how do I associate device tree nodes to
>> devices on a dynamically discoverable bus such as USB or PCI" right ?
>>
>> I believe that already exists. Y
On 2020-07-22 15:13, Saravana Kannan wrote:
> Add support for pinctrl-0 through pinctrl-8 explicitly instead of trying
> to add support for pinctrl-%d properties.
>
> Of all the pinctrl-* properties in dts files (20322), only 47% (9531)
> are pinctrl-%d properties. Of all the pinctrl-%d properties
+Frank (me)
On 2020-06-22 16:03, Michael Walle wrote:
> Am 2020-06-14 12:26, schrieb Michael Walle:
>> Hi Rob,
>>
>> Am 2020-06-10 00:03, schrieb Rob Herring:
>> [..]
>>> Yes, we should use 'reg' whenever possible. If we don't have 'reg',
>>> then you shouldn't have a unit-address either and you c
On 2020-06-24 11:14, Lee Jones wrote:
> On Wed, 24 Jun 2020, Frank Rowand wrote:
>
>> On 2020-06-24 02:46, Lee Jones wrote:
>>> On Tue, 23 Jun 2020, Frank Rowand wrote:
>>>
>>>> On 2020-06-23 14:59, Lee Jones wrote:
>>
>> < big snip >
On 2020-06-24 02:46, Lee Jones wrote:
> On Tue, 23 Jun 2020, Frank Rowand wrote:
>
>> On 2020-06-23 14:59, Lee Jones wrote:
< big snip >
Thanks for the replies in the above portion.
>>>> But yes or no to my solution #2 (with some slight changes to
>>>&
On 2020-06-21 17:49, Frank Rowand wrote:
> On 2020-06-21 17:45, Frank Rowand wrote:
>> Tim Bird started a thread [1] proposing that he document the selftest result
>> format used by Linux kernel tests.
>>
>> [1]
>> https://lore.kernel.org/r/cy4pr13mb1175b804e3
+Dmitry, since Brendan added him to another reply at this thread level
On 2020-06-22 21:46, David Gow wrote:
> On Mon, Jun 22, 2020 at 6:45 AM Frank Rowand wrote:
>>
>> Tim Bird started a thread [1] proposing that he document the selftest result
>> format used by Linux k
On 2020-06-11 14:10, Lee Jones wrote:
> Currently, when a child platform device (sometimes referred to as a
> sub-device) is registered via the Multi-Functional Device (MFD) API,
> the framework attempts to match the newly registered platform device
> with its associated Device Tree (OF) node. Unt
1 - 100 of 953 matches
Mail list logo
