On 03/13/2015 01:43 AM, David Gibson wrote: > On Tue, Mar 10, 2015 at 09:47:44AM -0400, Peter Hurley wrote: >> Hi David, >> >> On 03/09/2015 08:17 PM, David Gibson wrote: >>> On Fri, Mar 06, 2015 at 10:12:38AM -0500, Peter Hurley wrote: >>>> Properties may contain path names which are not NUL-terminated. >>>> For example, the 'stdout-path' property allows the form 'path:options', >>>> where the ':' character terminates the path specifier. >>>> >>>> Allow these path names to be used in-place for path descending; >>>> add fdt_path_offset_namelen(), which limits the path name to 'namelen' >>>> characters. >>>> >>>> Reimplement fdt_path_offset() as a trivial wrapper. >>>> >>>> Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> >>> >>> I think this function is a good idea, however I would like to see a >>> testcase for it. >> >> Sure, I can do that. >> >> I assume you mean a path name with non-NUL termination because >> the fdt_path_offset() tests are already exercising the >> fdt_path_offset_name() implementation. > > Yes, I mean the non-\0-terminated case. Or more specifically still, > making sure that if you call fdt_path_offset_namelen() on a portion of > a longer path, it correctly gives you the offset for only the partial > path. > > That said, there may be some other edge cases that could do with > testing too, if you have time. In particular I'm thinking of paths > where there are repeated '/' character, and paths ending with one or > more '/' characters. > >> Is there a readme somewhere regarding the test matrix (ie., >> which dts files go with which tests)? > > I'm afraid not, apart from the test runner script itself. I'm not > sure quite what information you're after here. Ok, now that I have the test working, I see why you didn't understand what I was after. The purpose of fdt_path_offset_namelen() is to perform path-descending from in-place property values; for example, finding the node offset from the /chosen/stdout-path property of the form / { chosen { stdout-path = "/ocp/serial@44e04d00:115200"; }; } I wrote the test to get string properties containing paths from the fdt; for example, assuming the fdt contains path1 = "/subnode@1/subsubnode:"; path2 = "/subnode@2/subsubnode@0:"; path3 = "/subnode@1////subsubnode///:"; path4 = "/subnode@2///subsubnode///:/subnode@1"; the test did: const char *path1; path1 = fdt_getprop(fdt, 0, "path1", &len); ... I had looked at the run_test.sh scripts and known that there were multiple dtb files produced for the test_tree1 tests so I was asking for a handy readme to tell me which dts(i) files to add the string properties to. When I got the test running for dtbs produced from test_tree1.body.dtsi, I discovered there were some cross-referenced tests from other sources, like sw_tree1.c; thus the changes to test_tree1.body.dtsi cause other tests to fail. So I've given up on testing fdt_path_offset_namelen() that way, and instead, am just using static const paths defined in the test itself, which I will submit shortly. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html