March 2023 - Linux-kselftest-mirror

[PATCH] selftests: net: devlink_port_split.py: skip test if no suitable device available

by Po-Hsu Lin

The `devlink -j dev show` command output may not contain the "flavour" key, for example: $ devlink -j dev show {"dev":{"pci/0001:00:00.0":{},"pci/0002:00:00.0":{}}} This will cause a KeyError exception. Fix this by checking the key existence first. Also, if max lanes is 0 the port splitting won't be tested at all. but the script will end normally and thus causing a false-negative test result. Use a test_ran flag to determine if these tests were skipped and return KSFT_SKIP accordingly. Link: https://bugs.launchpad.net/bugs/1937133 Fixes: f3348a82e727 ("selftests: net: Add port split test") Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com> --- tools/testing/selftests/net/devlink_port_split.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/devlink_port_split.py b/tools/testing/selftests/net/devlink_port_split.py index 2b5d6ff..462f3df 100755 --- a/tools/testing/selftests/net/devlink_port_split.py +++ b/tools/testing/selftests/net/devlink_port_split.py @@ -61,7 +61,7 @@ class devlink_ports(object): for port in ports: if dev in port: - if ports[port]['flavour'] == 'physical': + if 'flavour' in ports[port] and ports[port]['flavour'] == 'physical': arr.append(Port(bus_info=port, name=ports[port]['netdev'])) return arr @@ -231,6 +231,7 @@ def make_parser(): def main(cmdline=None): + test_ran = False parser = make_parser() args = parser.parse_args(cmdline) @@ -277,6 +278,11 @@ def main(cmdline=None): split_splittable_port(port, lane, max_lanes, dev) lane //= 2 + test_ran = True + + if not test_ran: + print("No suitable device for the test, test skipped") + sys.exit(KSFT_SKIP) if __name__ == "__main__": -- 2.7.4

1 year, 9 months

2
2
0 0

[PATCH v3 00/12] Revise the hwpt lifetime model

by Jason Gunthorpe

As discussed here is a small series to address the confusing lifetime scheme for the hwpt. This was some leftover from prior rework that was never fully cleaned up. Make it clear that the ioas and ioas->hwpt_list are associated with the hwpt during creation and never changed until it is destroyed. A hwpt with a positive reference count is always valid for device attachment. This also improves the selftest handling of the mock domains so that we can implement more testing for the hwpt model. This is a step toward the nesting and replace series. I have this on github: https://github.com/jgunthorpe/linux/commits/iommufd_hwpt v3: - Split patch to just make the hwpt_item handling consistent - Remove two confusing comments - Four new patches to clean up the confusing 'domain_id' in the selftest v2: https://lore.kernel.org/r/0-v2-406f7ac07936+6a-iommufd_hwpt_jgg@nvidia.com - Basically completely different - Add a test for HWPT cases by enhancing the mock iommu driver to be more complete - Move the device attachment as well into iommufd_hw_pagetable_alloc() so destroy is more symmetric v1: https://lore.kernel.org/r/0-v1-4336b5cb2fe4+1d7-iommufd_hwpt_jgg@nvidia.com Jason Gunthorpe (12): iommufd: Assert devices_lock for iommufd_hw_pagetable_has_group() iommufd: Add iommufd_lock_obj() around the auto-domains hwpts iommufd: Consistently manage hwpt_item iommufd: Move ioas related HWPT destruction into iommufd_hw_pagetable_destroy() iommufd: Move iommufd_device to iommufd_private.h iommufd: Make iommufd_hw_pagetable_alloc() do iopt_table_add_domain() iommufd/selftest: Rename the sefltest 'device_id' to 'stdev_id' iommufd/selftest: Rename domain_id to stdev_id for FIXTURE iommufd_ioas iommufd/selftest: Rename domain_id to hwpt_id for FIXTURE iommufd_mock_domain iommufd/selftest: Rename the remaining mock device_id's to stdev_id iommufd/selftest: Make selftest create a more complete mock device iommufd/selftest: Add a selftest for iommufd_device_attach() with a hwpt argument drivers/iommu/iommufd/device.c | 149 +++++-------- drivers/iommu/iommufd/hw_pagetable.c | 70 ++++++- drivers/iommu/iommufd/iommufd_private.h | 35 +++- drivers/iommu/iommufd/iommufd_test.h | 2 +- drivers/iommu/iommufd/selftest.c | 198 +++++++++++++++--- tools/testing/selftests/iommu/iommufd.c | 68 +++--- .../selftests/iommu/iommufd_fail_nth.c | 38 ++-- tools/testing/selftests/iommu/iommufd_utils.h | 16 +- 8 files changed, 368 insertions(+), 208 deletions(-) base-commit: 8473685c99683f9e2c7e2a42ef3d3f14a79be274 -- 2.39.2

1 year, 10 months

2
21
0 0

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

by Frank Rowand

On 3/2/23 17:57, Stephen Boyd wrote: > Quoting Rob Herring (2023-03-02 12:18:34) >> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd(a)kernel.org> wrote: >>> >>> Quoting Rob Herring (2023-03-02 09:13:59) >>>> >>>> Good to see bindings for this. I've been meaning to do something about >>>> the DT unittest ones being undocumented, but I hadn't really decided >>>> whether it was worth writing schemas for them. The compatibles at >>>> least show up with 'make dt_compatible_check'. Perhaps we want to just >>>> define some vendor (not 'linux') that's an exception rather than >>>> requiring schemas (actually, that already works for 'foo'). >>> >>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"? >> >> We'd want to use the same thing on the DT unittests or anything else >> potentially. How about just 'test'? > > Sounds good. > >> >>>> It's >>>> likely that we want test DTs that fail normal checks and schemas get >>>> in the way of that as we don't have a way to turn off checks. >>> >>> Having the schemas is nice to make sure tests that are expecting some >>> binding are actually getting that. But supporting broken bindings is >>> also important to test any error paths in functions that parse >>> properties. Maybe we keep the schema and have it enforce that incorrect >>> properties are being set? >> >> I wasn't suggesting throwing them out. More why I hadn't written any I guess. >> >>> Do we really need to test incorrect bindings? Doesn't the >>> dt_bindings_check catch these problems so we don't have to write DTB >>> verifiers in the kernel? >> >> Fair enough. Using my frequently stated position against me. :) >> >> I do have a secret plan to implement (debug) type checks into the >> of_property_* APIs by extracting the type information from schemas >> into C. >> > > Ok. I suspect we may want to test error paths though so I don't know Yes, exactly. > what to do here. For now I'll just leave the bindings in place and > change the prefix to "test". > >> >>>> We already have GPIO tests in the DT unittests, so why is clocks >>>> different? Or should the GPIO tests be moved out (yes, please!)? >>> >>> Ah I didn't notice the GPIO tests in there. There are i2c tests too, >>> right? All I can say is clks are using kunit, that's the difference ;-) >> >> Yeah, they should perhaps all move to the subsystems. > > Got it. > >> >>>> What happens when/if the DT unittest is converted to kunit? I think >>>> that would look confusing from the naming. My initial thought is >>>> 'kunit' should be dropped from the naming of a lot of this. Note that >>>> the original kunit submission converted the DT unittests. I would >>>> still like to see that happen. Frank disagreed over what's a unit test >>>> or not, then agreed, then didn't... I don't really care. If there's a >>>> framework to use, then we should use it IMO. >>> >>> Honestly I don't want to get involved in migrating the existing DT >>> unittest code to kunit. I'm aware that it was attempted years ago when >>> kunit was introduced. Maybe if the overlay route works well enough I can >>> completely sidestep introducing any code in drivers/of/ besides some >>> kunit wrappers for this. I'll cross my fingers! >> >> Yeah, I wasn't expecting you to. I just want to make sure this meshes >> with any future conversion to kunit. > > Phew! > >> >> There's also some plans to always populate the DT root node if not >> present. That may help here. Or not. There's been a few versions >> posted with Frank's in the last week or 2. >> > > Ok. I think I have some time to try this overlay approach so let me see > what is needed. Please avoid overlays. See my other replies in this thread for why.

1 year, 10 months

2
2
0 0

[PATCH linux-next v2] selftests: net: udpgso_bench_tx: Add test for IP fragmentation of UDP packets

by yang.yang29＠zte.com.cn

From: zhang yunkai (CGEL ZTE) <zhang.yunkai(a)zte.com.cn> The UDP GSO bench only tests the performance of userspace payload splitting and UDP GSO. But we are also concerned about the performance comparing with IP fragmentation and UDP GSO. In other words comparing IP fragmentation and segmentation. So we add testcase of IP fragmentation of UDP packets, then user would easy to get to know the performance promotion of UDP GSO compared with IP fragmentation. We add a new option "-f", which is to send big data using IP fragmentation instead of using UDP GSO or userspace payload splitting. In the QEMU environment we could see obvious promotion of UDP GSO. The first test is to get the performance of userspace payload splitting. bash# udpgso_bench_tx -l 4 -4 -D "$DST" udp tx: 21 MB/s 15162 calls/s 361 msg/s udp tx: 21 MB/s 15498 calls/s 369 msg/s udp tx: 18 MB/s 13440 calls/s 320 msg/s udp tx: 19 MB/s 13776 calls/s 328 msg/s The second test is to get the performance of IP fragmentation. bash# udpgso_bench_tx -l 4 -4 -D "$DST" -f udp tx: 41 MB/s 711 calls/s 711 msg/s udp tx: 41 MB/s 700 calls/s 700 msg/s udp tx: 43 MB/s 738 calls/s 738 msg/s udp tx: 40 MB/s 693 calls/s 693 msg/s The third test is to get the performance of UDP GSO. bash# udpgso_bench_tx -l 4 -4 -D "$DST" -S 0 udp tx: 45 MB/s 775 calls/s 775 msg/s udp tx: 47 MB/s 800 calls/s 800 msg/s udp tx: 47 MB/s 814 calls/s 814 msg/s udp tx: 47 MB/s 812 calls/s 812 msg/s v2: Suggested by Willem de Bruijn <willemdebruijn.kernel(a)gmail.com> - Use IP_PMTUDISC_OMIT to disable PMTU discovery and to avoid send returning with error after ICMP destination unreachable messages if MTU is exceeded in the path. Signed-off-by: zhang yunkai (CGEL ZTE) <zhang.yunkai(a)zte.com.cn> Reviewed-by: xu xin (CGEL ZTE) <xu.xin16(a)zte.com.cn> Reviewed-by: Yang Yang (CGEL ZTE) <yang.yang29(a)zte.com.cn> Cc: Xuexin Jiang (CGEL ZTE) <jiang.xuexin(a)zte.com.cn> --- tools/testing/selftests/net/udpgso_bench_tx.c | 49 ++++++++++++++++++++++----- 1 file changed, 40 insertions(+), 9 deletions(-) diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c b/tools/testing/selftests/net/udpgso_bench_tx.c index 477392715a9a..b3333b39bb87 100644 --- a/tools/testing/selftests/net/udpgso_bench_tx.c +++ b/tools/testing/selftests/net/udpgso_bench_tx.c @@ -64,6 +64,7 @@ static int cfg_runtime_ms = -1; static bool cfg_poll; static int cfg_poll_loop_timeout_ms = 2000; static bool cfg_segment; +static bool cfg_fragment; static bool cfg_sendmmsg; static bool cfg_tcp; static uint32_t cfg_tx_ts = SOF_TIMESTAMPING_TX_SOFTWARE; @@ -375,6 +376,21 @@ static int send_udp_sendmmsg(int fd, char *data) return ret; } +static int send_udp_fragment(int fd, char *data) +{ + int ret; + + ret = sendto(fd, data, cfg_payload_len, cfg_zerocopy ? MSG_ZEROCOPY : 0, + cfg_connected ? NULL : (void *)&cfg_dst_addr, + cfg_connected ? 0 : cfg_alen); + if (ret == -1) + error(1, errno, "write"); + if (ret != cfg_payload_len) + error(1, errno, "write: %uB != %uB\n", ret, cfg_payload_len); + + return 1; +} + static void send_udp_segment_cmsg(struct cmsghdr *cm) { uint16_t *valp; @@ -429,7 +445,7 @@ static int send_udp_segment(int fd, char *data) static void usage(const char *filepath) { - error(1, 0, "Usage: %s [-46acmHPtTuvz] [-C cpu] [-D dst ip] [-l secs] " + error(1, 0, "Usage: %s [-46acfmHPtTuvz] [-C cpu] [-D dst ip] [-l secs] " "[-L secs] [-M messagenr] [-p port] [-s sendsize] [-S gsosize]", filepath); } @@ -440,7 +456,7 @@ static void parse_opts(int argc, char **argv) int max_len, hdrlen; int c; - while ((c = getopt(argc, argv, "46acC:D:Hl:L:mM:p:s:PS:tTuvz")) != -1) { + while ((c = getopt(argc, argv, "46acC:D:fHl:L:mM:p:s:PS:tTuvz")) != -1) { switch (c) { case '4': if (cfg_family != PF_UNSPEC) @@ -469,6 +485,9 @@ static void parse_opts(int argc, char **argv) case 'l': cfg_runtime_ms = strtoul(optarg, NULL, 10) * 1000; break; + case 'f': + cfg_fragment = true; + break; case 'L': cfg_poll_loop_timeout_ms = strtoul(optarg, NULL, 10) * 1000; break; @@ -527,10 +546,10 @@ static void parse_opts(int argc, char **argv) error(1, 0, "must pass one of -4 or -6"); if (cfg_tcp && !cfg_connected) error(1, 0, "connectionless tcp makes no sense"); - if (cfg_segment && cfg_sendmmsg) - error(1, 0, "cannot combine segment offload and sendmmsg"); - if (cfg_tx_tstamp && !(cfg_segment || cfg_sendmmsg)) - error(1, 0, "Options -T and -H require either -S or -m option"); + if ((cfg_segment + cfg_sendmmsg + cfg_fragment) > 1) + error(1, 0, "cannot combine segment offload, fragment and sendmmsg"); + if (cfg_tx_tstamp && !(cfg_segment || cfg_sendmmsg || cfg_fragment)) + error(1, 0, "Options -T and -H require either -S or -m or -f option"); if (cfg_family == PF_INET) hdrlen = sizeof(struct iphdr) + sizeof(struct udphdr); @@ -551,14 +570,24 @@ static void set_pmtu_discover(int fd, bool is_ipv4) { int level, name, val; + /* IP fragmentation test uses IP_PMTUDISC_OMIT to disable PMTU discovery and + * to avoid send returning with error after ICMP destination unreachable + * messages if MTU is exceeded in the path. + */ if (is_ipv4) { level = SOL_IP; name = IP_MTU_DISCOVER; - val = IP_PMTUDISC_DO; + if (cfg_segment) + val = IP_PMTUDISC_DO; + else if (cfg_fragment) + val = IP_PMTUDISC_OMIT; } else { level = SOL_IPV6; name = IPV6_MTU_DISCOVER; - val = IPV6_PMTUDISC_DO; + if (cfg_segment) + val = IPV6_PMTUDISC_DO; + else if (cfg_fragment) + val = IPV6_PMTUDISC_OMIT; } if (setsockopt(fd, level, name, &val, sizeof(val))) @@ -674,7 +703,7 @@ int main(int argc, char **argv) connect(fd, (void *)&cfg_dst_addr, cfg_alen)) error(1, errno, "connect"); - if (cfg_segment) + if (cfg_segment || cfg_fragment) set_pmtu_discover(fd, cfg_family == PF_INET); if (cfg_tx_tstamp) @@ -695,6 +724,8 @@ int main(int argc, char **argv) num_sends += send_udp_segment(fd, buf[i]); else if (cfg_sendmmsg) num_sends += send_udp_sendmmsg(fd, buf[i]); + else if (cfg_fragment) + num_sends += send_udp_fragment(fd, buf[i]); else num_sends += send_udp(fd, buf[i]); num_msgs++; -- 2.15.2

1 year, 10 months

4
6
0 0

[PATCH] selftests: amd-pstate: fix TEST_FILES

by Guillaume Tucker

Bring back the Python scripts that were initially added with TEST_GEN_FILES but now with TEST_FILES to avoid having them deleted when doing a clean. Also fix the way the architecture is being determined as they should also be installed when ARCH=x86_64 is provided explicitly. Then also append extra files to TEST_FILES and TEST_PROGS with += so they don't get discarded. Fixes: ba2d788aa873 ("selftests: amd-pstate: Trigger tbench benchmark and test cpus") Fixes: ac527cee87c9 ("selftests: amd-pstate: Don't delete source files via Makefile") Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com> --- tools/testing/selftests/amd-pstate/Makefile | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/amd-pstate/Makefile b/tools/testing/selftests/amd-pstate/Makefile index 5fd1424db37d..c382f579fe94 100644 --- a/tools/testing/selftests/amd-pstate/Makefile +++ b/tools/testing/selftests/amd-pstate/Makefile @@ -4,10 +4,15 @@ # No binaries, but make sure arg-less "make" doesn't trigger "run_tests" all: -uname_M := $(shell uname -m 2>/dev/null || echo not) -ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/) +ARCH ?= $(shell uname -m 2>/dev/null || echo not) +ARCH := $(shell echo $(ARCH) | sed -e s/i.86/x86/ -e s/x86_64/x86/) -TEST_PROGS := run.sh -TEST_FILES := basic.sh tbench.sh gitsource.sh +ifeq (x86,$(ARCH)) +TEST_FILES += ../../../power/x86/amd_pstate_tracer/amd_pstate_trace.py +TEST_FILES += ../../../power/x86/intel_pstate_tracer/intel_pstate_tracer.py +endif + +TEST_PROGS += run.sh +TEST_FILES += basic.sh tbench.sh gitsource.sh include ../lib.mk -- 2.30.2

1 year, 10 months

3
4
0 0

[PATCH bpf v2 2/2] selftests/bpf: check that modifier resolves after pointer

by Lorenz Bauer

Add a regression test that ensures that a VAR pointing at a modifier which follows a PTR (or STRUCT or ARRAY) is resolved correctly by the datasec validator. Signed-off-by: Lorenz Bauer <lmb(a)isovalent.com> --- tools/testing/selftests/bpf/prog_tests/btf.c | 28 ++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c index cbb600be943d..210d643fda6c 100644 --- a/tools/testing/selftests/bpf/prog_tests/btf.c +++ b/tools/testing/selftests/bpf/prog_tests/btf.c @@ -879,6 +879,34 @@ static struct btf_raw_test raw_tests[] = { .btf_load_err = true, .err_str = "Invalid elem", }, +{ + .descr = "var after datasec, ptr followed by modifier", + .raw_types = { + /* .bss section */ /* [1] */ + BTF_TYPE_ENC(NAME_TBD, BTF_INFO_ENC(BTF_KIND_DATASEC, 0, 2), + sizeof(void*)+4), + BTF_VAR_SECINFO_ENC(4, 0, sizeof(void*)), + BTF_VAR_SECINFO_ENC(6, sizeof(void*), 4), + /* int */ /* [2] */ + BTF_TYPE_INT_ENC(0, BTF_INT_SIGNED, 0, 32, 4), + /* int* */ /* [3] */ + BTF_TYPE_ENC(0, BTF_INFO_ENC(BTF_KIND_PTR, 0, 0), 2), + BTF_VAR_ENC(NAME_TBD, 3, 0), /* [4] */ + /* const int */ /* [5] */ + BTF_TYPE_ENC(0, BTF_INFO_ENC(BTF_KIND_CONST, 0, 0), 2), + BTF_VAR_ENC(NAME_TBD, 5, 0), /* [6] */ + BTF_END_RAW, + }, + .str_sec = "\0a\0b\0c\0", + .str_sec_size = sizeof("\0a\0b\0c\0"), + .map_type = BPF_MAP_TYPE_ARRAY, + .map_name = ".bss", + .key_size = sizeof(int), + .value_size = sizeof(void*)+4, + .key_type_id = 0, + .value_type_id = 1, + .max_entries = 1, +}, /* Test member exceeds the size of struct. * * struct A { -- 2.39.2

1 year, 10 months

1
0
0 0

Re: Claim of Fund:

by Ms Eve from U.N

Hello Good Morning, This is to bring to your notice that all our efforts to contact you through this your email ID failed Please Kindly contact Barrister. Steven Mike { mbarrsteven(a)gmail.com } on his private email for the claim of your compensation entitlement Note: You have to pay for the delivery fee. Yours Sincerely Mrs EVE LEWIS

1 year, 10 months

1
0
0 0

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

by Geert Uytterhoeven

Hi Stephen, On Thu, Mar 2, 2023 at 8:28 PM Stephen Boyd <sboyd(a)kernel.org> wrote: > Quoting Rob Herring (2023-03-02 09:32:09) > > On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow(a)google.com> wrote: > > > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd(a)kernel.org> wrote: > > > > This patch series adds unit tests for the clk fixed rate basic type and > > > > the clk registration functions that use struct clk_parent_data. To get > > > > there, we add support for loading a DTB into the UML kernel that's > > > > running the unit tests along with probing platform drivers to bind to > > > > device nodes specified in DT. > > > > > > > > With this series, we're able to exercise some of the code in the common > > > > clk framework that uses devicetree lookups to find parents and the fixed > > > > rate clk code that scans devicetree directly and creates clks. Please > > > > review. > > > > > > > > > > Thanks Stephen -- this is really neat! > > > > > > This works well here, and I love all of the tests for the > > > KUnit/device-tree integration as well. > > > > > > I'm still looking through the details of it (alas, I've mostly lived > > > in x86-land, so my device-tree knowledge is, uh, spotty to say the > > > least), but apart from possibly renaming some things or similarly > > > minor tweaks, I've not got any real suggestions thus far. > > > > > > I do wonder whether we'll want, on the KUnit side, to have some way of > > > supporting KUnit device trees on non-UML architecctures (e.g., if we > > > need to test something architecture-specific, or on a big-endian > > > platform, etc), but I think that's a question for the future, rather > > > than something that affects this series. > > > > I'll say that's a requirement. We should be able to structure the > > tests to not interfere with the running system's DT. The DT unittest > > does that. > > That could be another choice in the unit test choice menu. > CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an > architecture that wants to run tests. As long as you use compatible values that don't exist elsewhere, and don't overwrite anything, you can load your kunit test overlays on any running system that has DT support. > > As a side topic, Is anyone looking at getting UML to work on arm64? > > It's surprising how much x86 stuff there is which is I guess one > > reason it hasn't happened. > > I've no idea but it would be nice indeed. I believe that's non-trivial. At least for arm32 (I didn't have any arm64 systems last time I asked the experts). > > > Similarly, I wonder if there's something we could do with device tree > > > overlays, in order to make it possible for tests to swap nodes in and > > > out for testing. > > > > Yes, that's how the DT unittest works. But it is pretty much one big > > overlay (ignoring the overlay tests). It could probably be more > > modular where it is apply overlay, test, remove overlay, repeat. > > I didn't want to rely on the overlay code to inject DT nodes. Having > tests written for the fake KUnit machine is simple. It closely matches > how clk code probes the DTB and how nodes are created and populated on > the platform bus as devices. CLK_OF_DECLARE() would need the overlay to > be applied early too, which doesn't happen otherwise as far as I know. Don't all generic clock drivers also create a platform driver? At least drivers/clk/clk-fixed-factor.c does. > But perhaps this design is too much of an end-to-end test and not a unit > test? In the spirit of unit testing we shouldn't care about how the node > is added to the live devicetree, just that there is a devicetree at all. > > Supporting overlays to more easily test combinations sounds like a good > idea. Probably some kunit_*() prefixed functions could be used to > apply a test managed overlay and automatically remove it when the test > is over would work. The clk registration tests could use this API to > inject an overlay and then manually call the of_platform_populate() > function to create the platform device(s). The overlay could be built in > drivers/clk/ too and then probably some macroish function can find the > blob and apply it. No need to manually call of_platform_populate() to create the platform devices. That is taken care of automatically when applying an overlay. > Is there some way to delete the platform devices that we populate from > the overlay? I'd like the tests to be hermetic. Removing the overlay will delete the platform devices. All of that works if you have your own code to apply a DT overlay. The recent fw_devlinks patches did cause some regressions, cfr. https://lore.kernel.org/all/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-K… P.S. Shameless plug: for loading overlays from userspace, there are my overlay branches, cfr. https://elinux.org/R-Car/DT-Overlays Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

1 year, 10 months

2
3
0 0

[PATCH bpf-next 0/2] bpf: add bound tracking for BPF_MOD

by Xu Kuohai

From: Xu Kuohai <xukuohai(a)huawei.com> dst_reg is marked as unknown when BPF_MOD instruction is verified, causing the following bpf prog to be incorrectly rejected. 0: r0 = 0 1: r0 %= 10 // r0 is marked as unknown 2: r1 = 0 3: r1 += 1 4: if r1 < r0 goto pc-2 // verifier concludes the loop is unbounded 5: exit To teach verifier to accept the above prog, this series adds bound tracking for BPF_MOD. Xu Kuohai (2): bpf: add bound tracking for BPF_MOD selftests/bpf: check if verifier tracks dst_reg bound for BPF_MOD kernel/bpf/verifier.c | 98 +++++++- tools/testing/selftests/bpf/verifier/mod.c | 247 +++++++++++++++++++++ 2 files changed, 340 insertions(+), 5 deletions(-) create mode 100644 tools/testing/selftests/bpf/verifier/mod.c -- 2.30.2

1 year, 10 months

2
4
0 0

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

by Rob Herring

On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd(a)kernel.org> wrote: > > Quoting Rob Herring (2023-03-02 09:13:59) > > On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd(a)kernel.org> wrote: > > > > > > This patch series adds unit tests for the clk fixed rate basic type and > > > the clk registration functions that use struct clk_parent_data. To get > > > there, we add support for loading a DTB into the UML kernel that's > > > running the unit tests along with probing platform drivers to bind to > > > device nodes specified in DT. > > > > > > With this series, we're able to exercise some of the code in the common > > > clk framework that uses devicetree lookups to find parents and the fixed > > > rate clk code that scans devicetree directly and creates clks. Please > > > review. > > > > > > I Cced everyone to all the patches so they get the full context. I'm > > > hoping I can take the whole pile through the clk tree as they almost all > > > depend on each other. In the future I imagine it will be easy to add > > > more test nodes to the clk.dtsi file and not need to go across various > > > maintainer trees like this series does. > > > > > > Stephen Boyd (8): > > > dt-bindings: Add linux,kunit binding > > > of: Enable DTB loading on UML for KUnit tests > > > kunit: Add test managed platform_device/driver APIs > > > clk: Add test managed clk provider/consumer APIs > > > dt-bindings: kunit: Add fixed rate clk consumer test > > > clk: Add KUnit tests for clk fixed rate basic type > > > dt-bindings: clk: Add KUnit clk_parent_data test > > > clk: Add KUnit tests for clks registered with struct clk_parent_data > > > > Good to see bindings for this. I've been meaning to do something about > > the DT unittest ones being undocumented, but I hadn't really decided > > whether it was worth writing schemas for them. The compatibles at > > least show up with 'make dt_compatible_check'. Perhaps we want to just > > define some vendor (not 'linux') that's an exception rather than > > requiring schemas (actually, that already works for 'foo'). > > Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"? We'd want to use the same thing on the DT unittests or anything else potentially. How about just 'test'? > > It's > > likely that we want test DTs that fail normal checks and schemas get > > in the way of that as we don't have a way to turn off checks. > > Having the schemas is nice to make sure tests that are expecting some > binding are actually getting that. But supporting broken bindings is > also important to test any error paths in functions that parse > properties. Maybe we keep the schema and have it enforce that incorrect > properties are being set? I wasn't suggesting throwing them out. More why I hadn't written any I guess. > Do we really need to test incorrect bindings? Doesn't the > dt_bindings_check catch these problems so we don't have to write DTB > verifiers in the kernel? Fair enough. Using my frequently stated position against me. :) I do have a secret plan to implement (debug) type checks into the of_property_* APIs by extracting the type information from schemas into C. > > We already have GPIO tests in the DT unittests, so why is clocks > > different? Or should the GPIO tests be moved out (yes, please!)? > > Ah I didn't notice the GPIO tests in there. There are i2c tests too, > right? All I can say is clks are using kunit, that's the difference ;-) Yeah, they should perhaps all move to the subsystems. > > What happens when/if the DT unittest is converted to kunit? I think > > that would look confusing from the naming. My initial thought is > > 'kunit' should be dropped from the naming of a lot of this. Note that > > the original kunit submission converted the DT unittests. I would > > still like to see that happen. Frank disagreed over what's a unit test > > or not, then agreed, then didn't... I don't really care. If there's a > > framework to use, then we should use it IMO. > > Honestly I don't want to get involved in migrating the existing DT > unittest code to kunit. I'm aware that it was attempted years ago when > kunit was introduced. Maybe if the overlay route works well enough I can > completely sidestep introducing any code in drivers/of/ besides some > kunit wrappers for this. I'll cross my fingers! Yeah, I wasn't expecting you to. I just want to make sure this meshes with any future conversion to kunit. There's also some plans to always populate the DT root node if not present. That may help here. Or not. There's been a few versions posted with Frank's in the last week or 2. Rob

1 year, 10 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror March 2023