From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Oded Gabbay <ogabbay@kernel.org>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
Jeffrey Hugo <quic_jhugo@quicinc.com>,
Arnd Bergmann <arnd@arndb.de>,
Thomas Zimmermann <tzimmermann@suse.de>,
John Hubbard <jhubbard@nvidia.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
Jagan Teki <jagan@amarulasolutions.com>,
Jason Gunthorpe <jgg@nvidia.com>, Jiho Chu <jiho.chu@samsung.com>,
Alex Deucher <alexander.deucher@amd.com>,
Christoph Hellwig <hch@infradead.org>,
Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
Kevin Hilman <khilman@baylibre.com>
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major
Date: Thu, 3 Nov 2022 01:32:08 +0100 [thread overview]
Message-ID: <Y2MMCIe5wND2XPqE@kroah.com> (raw)
In-Reply-To: <20221102203405.1797491-2-ogabbay@kernel.org>
On Wed, Nov 02, 2022 at 10:34:03PM +0200, Oded Gabbay wrote:
> --- /dev/null
> +++ b/drivers/accel/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Compute Acceleration device configuration
> +#
> +# This framework provides support for compute acceleration devices, such
> +# as, but not limited to, Machine-Learning and Deep-Learning acceleration
> +# devices
> +#
> +menuconfig ACCEL
> + tristate "Compute Acceleration Framework"
> + depends on DRM
> + help
> + Framework for device drivers of compute acceleration devices, such
> + as, but not limited to, Machine-Learning and Deep-Learning
> + acceleration devices.
> + If you say Y here, you need to select the module that's right for
> + your acceleration device from the list below.
> + This framework is integrated with the DRM subsystem as compute
> + accelerators and GPUs share a lot in common and can use almost the
> + same infrastructure code.
> + Having said that, acceleration devices will have a different
> + major number than GPUs, and will be exposed to user-space using
> + different device files, called accel/accel* (in /dev, sysfs
> + and debugfs)
Module name if "M" is chosen?
> +static char *accel_devnode(struct device *dev, umode_t *mode)
> +{
> + return kasprintf(GFP_KERNEL, "accel/%s", dev_name(dev));
> +}
> +
> +static CLASS_ATTR_STRING(accel_version, 0444, "accel 1.0.0 20221018");
What is a version number doing here?
Please no, I understand that DRM has this, but it really does not make
sense for any in-kernel code. And that's not how sysfs is supposed to
work anyway (if a file is present, the value is documented, if the file
is not present, the value is just not there, userspace has to handle
it all.)
> +
> +/**
> + * accel_sysfs_init - initialize sysfs helpers
> + *
> + * This is used to create the ACCEL class, which is the implicit parent of any
> + * other top-level ACCEL sysfs objects.
> + *
> + * You must call accel_sysfs_destroy() to release the allocated resources.
> + *
> + * Return: 0 on success, negative error code on failure.
> + */
> +static int accel_sysfs_init(void)
> +{
> + int err;
> +
> + accel_class = class_create(THIS_MODULE, "accel");
> + if (IS_ERR(accel_class))
> + return PTR_ERR(accel_class);
> +
> + err = class_create_file(accel_class, &class_attr_accel_version.attr);
Hint, if you ever find yourself adding sysfs files "by hand" like this,
you are doing something wrong. The driver code should create them
automatically for you by setting up default groups, _OR_ as in this
case, you shouldn't be adding the file at all :)
> +static void accel_sysfs_destroy(void)
> +{
> + if (IS_ERR_OR_NULL(accel_class))
> + return;
> + class_remove_file(accel_class, &class_attr_accel_version.attr);
No need to manually destroy files when you remove a device. But you
will remove this file anyway for the next version of this patch, so it's
not a big deal :)
> + class_destroy(accel_class);
> + accel_class = NULL;
> +}
> +
> +static int accel_stub_open(struct inode *inode, struct file *filp)
> +{
> + DRM_DEBUG("Operation not supported");
ftrace is wonderful, please use that and not hand-rolled custom "I am
here!" type messages like this.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Oded Gabbay <ogabbay@kernel.org>
Cc: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Jason Gunthorpe <jgg@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Alex Deucher <alexander.deucher@amd.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
Jiho Chu <jiho.chu@samsung.com>,
Daniel Stone <daniel@fooishbar.org>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Jeffrey Hugo <quic_jhugo@quicinc.com>,
Christoph Hellwig <hch@infradead.org>,
Kevin Hilman <khilman@baylibre.com>,
Jagan Teki <jagan@amarulasolutions.com>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major
Date: Thu, 3 Nov 2022 01:32:08 +0100 [thread overview]
Message-ID: <Y2MMCIe5wND2XPqE@kroah.com> (raw)
In-Reply-To: <20221102203405.1797491-2-ogabbay@kernel.org>
On Wed, Nov 02, 2022 at 10:34:03PM +0200, Oded Gabbay wrote:
> --- /dev/null
> +++ b/drivers/accel/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Compute Acceleration device configuration
> +#
> +# This framework provides support for compute acceleration devices, such
> +# as, but not limited to, Machine-Learning and Deep-Learning acceleration
> +# devices
> +#
> +menuconfig ACCEL
> + tristate "Compute Acceleration Framework"
> + depends on DRM
> + help
> + Framework for device drivers of compute acceleration devices, such
> + as, but not limited to, Machine-Learning and Deep-Learning
> + acceleration devices.
> + If you say Y here, you need to select the module that's right for
> + your acceleration device from the list below.
> + This framework is integrated with the DRM subsystem as compute
> + accelerators and GPUs share a lot in common and can use almost the
> + same infrastructure code.
> + Having said that, acceleration devices will have a different
> + major number than GPUs, and will be exposed to user-space using
> + different device files, called accel/accel* (in /dev, sysfs
> + and debugfs)
Module name if "M" is chosen?
> +static char *accel_devnode(struct device *dev, umode_t *mode)
> +{
> + return kasprintf(GFP_KERNEL, "accel/%s", dev_name(dev));
> +}
> +
> +static CLASS_ATTR_STRING(accel_version, 0444, "accel 1.0.0 20221018");
What is a version number doing here?
Please no, I understand that DRM has this, but it really does not make
sense for any in-kernel code. And that's not how sysfs is supposed to
work anyway (if a file is present, the value is documented, if the file
is not present, the value is just not there, userspace has to handle
it all.)
> +
> +/**
> + * accel_sysfs_init - initialize sysfs helpers
> + *
> + * This is used to create the ACCEL class, which is the implicit parent of any
> + * other top-level ACCEL sysfs objects.
> + *
> + * You must call accel_sysfs_destroy() to release the allocated resources.
> + *
> + * Return: 0 on success, negative error code on failure.
> + */
> +static int accel_sysfs_init(void)
> +{
> + int err;
> +
> + accel_class = class_create(THIS_MODULE, "accel");
> + if (IS_ERR(accel_class))
> + return PTR_ERR(accel_class);
> +
> + err = class_create_file(accel_class, &class_attr_accel_version.attr);
Hint, if you ever find yourself adding sysfs files "by hand" like this,
you are doing something wrong. The driver code should create them
automatically for you by setting up default groups, _OR_ as in this
case, you shouldn't be adding the file at all :)
> +static void accel_sysfs_destroy(void)
> +{
> + if (IS_ERR_OR_NULL(accel_class))
> + return;
> + class_remove_file(accel_class, &class_attr_accel_version.attr);
No need to manually destroy files when you remove a device. But you
will remove this file anyway for the next version of this patch, so it's
not a big deal :)
> + class_destroy(accel_class);
> + accel_class = NULL;
> +}
> +
> +static int accel_stub_open(struct inode *inode, struct file *filp)
> +{
> + DRM_DEBUG("Operation not supported");
ftrace is wonderful, please use that and not hand-rolled custom "I am
here!" type messages like this.
thanks,
greg k-h
next prev parent reply other threads:[~2022-11-03 0:31 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 20:34 [RFC PATCH v2 0/3] new subsystem for compute accelerator devices Oded Gabbay
2022-11-02 20:34 ` Oded Gabbay
2022-11-02 20:34 ` [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major Oded Gabbay
2022-11-02 20:34 ` Oded Gabbay
2022-11-02 21:04 ` Jeffrey Hugo
2022-11-02 21:04 ` Jeffrey Hugo
2022-11-03 13:28 ` Oded Gabbay
2022-11-03 13:28 ` Oded Gabbay
2022-11-02 22:58 ` Randy Dunlap
2022-11-02 22:58 ` Randy Dunlap
2022-11-03 13:29 ` Oded Gabbay
2022-11-03 13:29 ` Oded Gabbay
2022-11-03 0:32 ` Greg Kroah-Hartman [this message]
2022-11-03 0:32 ` Greg Kroah-Hartman
2022-11-03 13:31 ` Oded Gabbay
2022-11-03 13:31 ` Oded Gabbay
2022-11-03 20:39 ` Oded Gabbay
2022-11-03 20:39 ` Oded Gabbay
2022-11-03 23:01 ` Randy Dunlap
2022-11-03 23:01 ` Randy Dunlap
2022-11-04 7:23 ` Stanislaw Gruszka
2022-11-04 7:23 ` Stanislaw Gruszka
2022-11-07 12:56 ` Jason Gunthorpe
2022-11-07 12:56 ` Jason Gunthorpe
2022-11-07 13:01 ` Oded Gabbay
2022-11-07 13:01 ` Oded Gabbay
2022-11-07 13:10 ` Jason Gunthorpe
2022-11-07 13:10 ` Jason Gunthorpe
2022-11-07 13:25 ` Stanislaw Gruszka
2022-11-07 13:25 ` Stanislaw Gruszka
2022-11-07 14:02 ` Oded Gabbay
2022-11-07 14:02 ` Oded Gabbay
2022-11-07 14:10 ` Jason Gunthorpe
2022-11-07 14:10 ` Jason Gunthorpe
2022-11-07 15:53 ` Oded Gabbay
2022-11-07 15:53 ` Oded Gabbay
2022-11-07 16:30 ` Jason Gunthorpe
2022-11-07 16:30 ` Jason Gunthorpe
2022-11-07 19:27 ` Oded Gabbay
2022-11-07 19:27 ` Oded Gabbay
2022-11-07 20:33 ` Dave Airlie
2022-11-07 20:33 ` Dave Airlie
2022-11-08 12:28 ` Jason Gunthorpe
2022-11-08 12:28 ` Jason Gunthorpe
2022-11-09 7:22 ` Dave Airlie
2022-11-09 7:22 ` Dave Airlie
2022-11-07 20:18 ` Dave Airlie
2022-11-07 20:18 ` Dave Airlie
2022-11-02 20:34 ` [RFC PATCH v2 2/3] accel: add dedicated minor for accelerator devices Oded Gabbay
2022-11-02 20:34 ` Oded Gabbay
2022-11-02 21:17 ` Jeffrey Hugo
2022-11-02 21:17 ` Jeffrey Hugo
2022-11-06 10:51 ` Oded Gabbay
2022-11-06 10:51 ` Oded Gabbay
2022-11-03 5:25 ` Jiho Chu
2022-11-03 5:25 ` Jiho Chu
2022-11-06 10:54 ` Oded Gabbay
2022-11-06 10:54 ` Oded Gabbay
2022-11-06 14:15 ` Oded Gabbay
2022-11-06 14:15 ` Oded Gabbay
2022-11-02 20:34 ` [RFC PATCH v2 3/3] drm: initialize accel framework Oded Gabbay
2022-11-02 20:34 ` Oded Gabbay
2022-11-02 21:30 ` Jeffrey Hugo
2022-11-02 21:30 ` Jeffrey Hugo
2022-11-06 10:55 ` Oded Gabbay
2022-11-06 10:55 ` Oded Gabbay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2MMCIe5wND2XPqE@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.deucher@amd.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=jagan@amarulasolutions.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=jiho.chu@samsung.com \
--cc=khilman@baylibre.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.kwapulinski@linux.intel.com \
--cc=ogabbay@kernel.org \
--cc=quic_jhugo@quicinc.com \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=yuji2.ishikawa@toshiba.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.