Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp445362rdb; Tue, 5 Dec 2023 09:33:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IFXd8RsbuPIvwveCJXjpXG0TUL+nJN4717djbTDPyLnHU3Y1KBTV3ruDODmrAz3klICZbdK X-Received: by 2002:a17:902:c945:b0:1d0:7b67:c535 with SMTP id i5-20020a170902c94500b001d07b67c535mr2374581pla.17.1701797610780; Tue, 05 Dec 2023 09:33:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701797610; cv=none; d=google.com; s=arc-20160816; b=P/gacB/YPKSXsTCJMAZ+lIxAKNhQOVHIt2DIuvMkZ0wpcC33ArDDuUBOwU5ZS60lNy iaI7B1WNS2XsNKQQLlh9GKUY5kmkEpsbe+yipVrhzv7vl5J46/eZkstxrsN2O3O4QQ+u 9B4mOmH9DiChwzp9+m2Gmii3AWOBowk2kRtK/QcIgzlQerI5dwwteSJc1j9YSHBLsVxK J/GtbSS+Zh3l1cD6OL28FhztM4dDdKWfgiYp/y96MpUW5vMCVpx5drZLbwb5K7BgEz9s BbykP/toJjcc5nNr15dLRww336IGNOdiBYQixF6usy9VgHkSLzYIPaxNI1LOiJ/9TyBu v/YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=OBfGAJZjNspBwWQQfwMRbyiAixl9IabhlUsYdf56Yds=; fh=bqho5+DluhI0sqBIaNt9ylVScwZOmbMAY6m92rchEkk=; b=z19zRBrtfSveyw7OXv6jMhC/4HZbmyMrqySY54Bnn3xNVWiI6Avs4VIRITUQB86c4n Wdw0V27r3e20F8+9wglvHtMYiH44/uZ+AU8Kt05aV0y7aHdcXQJ00zttOhJvxUNPhwkt NXeWWe7Vrk6BSa0uLtckSUWNWqNp5cDYF+MMW6E/5exKTDDQS0+Lib9G98OXGj83lA97 GcOLDM53rlAY+p4f4AE8t/6Xqtpi8YWHbmFP6Et0Vcry01gcav4DjCdO6atr4jbmACBV uYvree2LP0rQqN/lo7yohOy51mc+qytwkgyV/0SXH50Rt/maa1LdfQaf1+vV2qP4X0/w q0Ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Eo34XWay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id ck1-20020a056a02090100b005c671034477si5176878pgb.539.2023.12.05.09.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 09:33:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Eo34XWay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 1CE048069992; Tue, 5 Dec 2023 09:31:08 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345246AbjLERat (ORCPT + 99 others); Tue, 5 Dec 2023 12:30:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346190AbjLERar (ORCPT ); Tue, 5 Dec 2023 12:30:47 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3744CA for ; Tue, 5 Dec 2023 09:30:52 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D0D6C433C8; Tue, 5 Dec 2023 17:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1701797452; bh=CwZH8dp4E6n8XqkzFtg8ZeyfOny+4HhH2LzxKqY45/g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Eo34XWayzo1yJIrgJEuVirn1KuAJ+0ua2w/vTh2EcI8xwiKp/gbo39WkN0UCHBKGR BJ5BHYJ1Qew/EmfyAP6UUgwVOzL9+KmH9VkQkYNa1g4WjJEul68Q66H4Z5r/XaLggs UmgJ5WWiwP3rUxNeLI/TGqEurRJQVrSx4dvN4+Es= Date: Wed, 6 Dec 2023 02:30:45 +0900 From: Greg Kroah-Hartman To: davidgow@google.com Cc: Rae Moar , Brendan Higgins , Matti Vaittinen , Stephen Boyd , Shuah Khan , Jonathan Corbet , Kees Cook , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Maxime Ripard , linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-sound@vger.kernel.org Subject: Re: [PATCH 1/4] kunit: Add APIs for managing devices Message-ID: <2023120602-vaguely-primarily-b6b2@gregkh> References: <20231205-kunit_bus-v1-0-635036d3bc13@google.com> <20231205-kunit_bus-v1-1-635036d3bc13@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231205-kunit_bus-v1-1-635036d3bc13@google.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 05 Dec 2023 09:31:08 -0800 (PST) On Tue, Dec 05, 2023 at 03:31:33PM +0800, davidgow@google.com wrote: > Tests for drivers often require a struct device to pass to other > functions. While it's possible to create these with > root_device_register(), or to use something like a platform device, this > is both a misuse of those APIs, and can be difficult to clean up after, > for example, a failed assertion. > > Add some KUnit-specific functions for registering and unregistering a > struct device: > - kunit_device_register() > - kunit_device_register_with_driver() > - kunit_device_unregister() > > These helpers allocate a on a 'kunit' bus which will either probe the > driver passed in (kunit_device_register_with_driver), or will create a > stub driver (kunit_device_register) which is cleaned up on test shutdown. > > Devices are automatically unregistered on test shutdown, but can be > manually unregistered earlier with kunit_device_unregister() in order > to, for example, test device release code. At first glance, nice work. But looks like 0-day doesn't like it that much, so I'll wait for the next version to review it properly. One nit I did notice: > +// For internal use only -- registers the kunit_bus. > +int kunit_bus_init(void); Put stuff like this in a local .h file, don't pollute the include/linux/ files for things that you do not want any other part of the kernel to call. > +/** > + * kunit_device_register_with_driver() - Create a struct device for use in KUnit tests > + * @test: The test context object. > + * @name: The name to give the created device. > + * @drv: The struct device_driver to associate with the device. > + * > + * Creates a struct kunit_device (which is a struct device) with the given > + * name, and driver. The device will be cleaned up on test exit, or when > + * kunit_device_unregister is called. See also kunit_device_register, if you > + * wish KUnit to create and manage a driver for you > + */ > +struct device *kunit_device_register_with_driver(struct kunit *test, > + const char *name, > + struct device_driver *drv); Shouldn't "struct device_driver *" be a constant pointer? But really, why is this a "raw" device_driver pointer and not a pointer to the driver type for your bus? Oh heck, let's point out the other issues as I'm already here... > @@ -7,7 +7,8 @@ kunit-objs += test.o \ > assert.o \ > try-catch.o \ > executor.o \ > - attributes.o > + attributes.o \ > + device.o Shouldn't this file be "bus.c" as you are creating a kunit bus? > > ifeq ($(CONFIG_KUNIT_DEBUGFS),y) > kunit-objs += debugfs.o > diff --git a/lib/kunit/device.c b/lib/kunit/device.c > new file mode 100644 > index 000000000000..93ace1a2297d > --- /dev/null > +++ b/lib/kunit/device.c > @@ -0,0 +1,176 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * KUnit basic device implementation "basic bus/driver implementation", not device, right? > + * > + * Implementation of struct kunit_device helpers. > + * > + * Copyright (C) 2023, Google LLC. > + * Author: David Gow > + */ > + > +#include > + > +#include > +#include > +#include > + > + > +/* Wrappers for use with kunit_add_action() */ > +KUNIT_DEFINE_ACTION_WRAPPER(device_unregister_wrapper, device_unregister, struct device *); > +KUNIT_DEFINE_ACTION_WRAPPER(driver_unregister_wrapper, driver_unregister, struct device_driver *); > + > +static struct device kunit_bus = { > + .init_name = "kunit" > +}; A static device as a bus? This feels wrong, what is it for? And where does this live? If you _REALLY_ want a single device for the root of your bus (which is a good idea), then make it a dynamic variable (as it is reference counted), NOT a static struct device which should not be done if at all possible. > + > +/* A device owned by a KUnit test. */ > +struct kunit_device { > + struct device dev; > + struct kunit *owner; > + /* Force binding to a specific driver. */ > + struct device_driver *driver; > + /* The driver is managed by KUnit and unique to this device. */ > + bool cleanup_driver; > +}; Wait, why isn't your "kunit" device above a struct kunit_device structure? Why is it ok to be a "raw" struct device (hint, that's almost never a good idea.) > +static inline struct kunit_device *to_kunit_device(struct device *d) > +{ > + return container_of(d, struct kunit_device, dev); container_of_const()? And to use that properly, why not make this a #define? > +} > + > +static int kunit_bus_match(struct device *dev, struct device_driver *driver) > +{ > + struct kunit_device *kunit_dev = to_kunit_device(dev); > + > + if (kunit_dev->driver == driver) > + return 1; > + > + return 0; I don't understand, what are you trying to match here? > +} > + > +static struct bus_type kunit_bus_type = { > + .name = "kunit", > + .match = kunit_bus_match > +}; > + > +int kunit_bus_init(void) > +{ > + int error; > + > + error = bus_register(&kunit_bus_type); > + if (!error) { > + error = device_register(&kunit_bus); > + if (error) > + bus_unregister(&kunit_bus_type); > + } > + return error; > +} > +late_initcall(kunit_bus_init); > + > +static void kunit_device_release(struct device *d) > +{ > + kfree(to_kunit_device(d)); > +} > + > +struct device_driver *kunit_driver_create(struct kunit *test, const char *name) > +{ > + struct device_driver *driver; > + int err = -ENOMEM; > + > + driver = kunit_kzalloc(test, sizeof(*driver), GFP_KERNEL); > + > + if (!driver) > + return ERR_PTR(err); > + > + driver->name = name; > + driver->bus = &kunit_bus_type; > + driver->owner = THIS_MODULE; > + > + err = driver_register(driver); > + if (err) { > + kunit_kfree(test, driver); > + return ERR_PTR(err); > + } > + > + kunit_add_action(test, driver_unregister_wrapper, driver); > + return driver; > +} > +EXPORT_SYMBOL_GPL(kunit_driver_create); > + > +struct kunit_device *__kunit_device_register_internal(struct kunit *test, > + const char *name, > + struct device_driver *drv) > +{ > + struct kunit_device *kunit_dev; > + int err = -ENOMEM; > + > + kunit_dev = kzalloc(sizeof(struct kunit_device), GFP_KERNEL); > + if (!kunit_dev) > + return ERR_PTR(err); > + > + kunit_dev->owner = test; > + > + err = dev_set_name(&kunit_dev->dev, "%s.%s", test->name, name); > + if (err) { > + kfree(kunit_dev); > + return ERR_PTR(err); > + } > + > + /* Set the expected driver pointer, so we match. */ > + kunit_dev->driver = drv; Ah, so this is the match function to pass above? If so, why do you need it at all? > + > + kunit_dev->dev.release = kunit_device_release; > + kunit_dev->dev.bus = &kunit_bus_type; > + kunit_dev->dev.parent = &kunit_bus; > + > + err = device_register(&kunit_dev->dev); > + if (err) { > + put_device(&kunit_dev->dev); > + return ERR_PTR(err); > + } > + > + kunit_add_action(test, device_unregister_wrapper, &kunit_dev->dev); > + > + return kunit_dev; > +} > + > +struct device *kunit_device_register_with_driver(struct kunit *test, > + const char *name, > + struct device_driver *drv) > +{ > + struct kunit_device *kunit_dev = __kunit_device_register_internal(test, name, drv); > + > + if (IS_ERR_OR_NULL(kunit_dev)) This is almost always a sign that something is wrong with the api. > + return (struct device *)kunit_dev; /* This is an error or NULL, so is compatible */ Ick, the cast is odd, are you sure you need it? Why would you return a struct device and not a kunit_device() anyway? > + > + return &kunit_dev->dev; Again, why this type, why not use the real type you have? thanks, greg k-h