linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: linux-kernel@vger.kernel.org, olof@lixom.net, rppt@linux.ibm.com,
	ogabbay@habana.ai, arnd@arndb.de, joe@perches.com
Subject: Re: [PATCH v3 09/15] habanalabs: add sysfs and hwmon support
Date: Fri, 8 Feb 2019 13:14:02 +0100	[thread overview]
Message-ID: <20190208121402.GB23483@kroah.com> (raw)
In-Reply-To: <20190204203254.4026-10-oded.gabbay@gmail.com>

On Mon, Feb 04, 2019 at 10:32:48PM +0200, Oded Gabbay wrote:
> This patch add the sysfs and hwmon entries that are exposed by the driver.
> 
> Goya has several sensors, from various categories such as temperature,
> voltage, current, etc. The driver exposes those sensors in the standard
> hwmon mechanism.
> 
> In addition, the driver exposes a couple of interfaces in sysfs, both for
> configuration and for providing status of the device or driver.
> 
> The configuration attributes is for Power Management:
> - Automatic or manual
> - Frequency value when moving to high frequency mode
> - Maximum power the device is allowed to consume
> 
> The rest of the attributes are read-only and provide the following
> information:
> - Versions of the various firmwares running on the device
> - Contents of the device's EEPROM
> - The device type (currently only Goya is supported)
> - PCI address of the device (to allow user-space to connect between
>   /dev/hlX to PCI address)
> - Status of the device (operational, malfunction, in_reset)
> - How many processes are open on the device's file
> 
> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
> ---
>  .../ABI/testing/sysfs-driver-habanalabs       | 190 ++++++
>  drivers/misc/habanalabs/Makefile              |   2 +-
>  drivers/misc/habanalabs/device.c              | 146 +++++
>  drivers/misc/habanalabs/goya/Makefile         |   2 +-
>  drivers/misc/habanalabs/goya/goya.c           | 230 +++++++
>  drivers/misc/habanalabs/goya/goyaP.h          |  21 +
>  drivers/misc/habanalabs/goya/goya_hwmgr.c     | 306 +++++++++
>  drivers/misc/habanalabs/habanalabs.h          | 101 +++
>  drivers/misc/habanalabs/habanalabs_drv.c      |   7 +
>  drivers/misc/habanalabs/hwmon.c               | 449 +++++++++++++
>  drivers/misc/habanalabs/sysfs.c               | 589 ++++++++++++++++++
>  11 files changed, 2041 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-habanalabs
>  create mode 100644 drivers/misc/habanalabs/goya/goya_hwmgr.c
>  create mode 100644 drivers/misc/habanalabs/hwmon.c
>  create mode 100644 drivers/misc/habanalabs/sysfs.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs
> new file mode 100644
> index 000000000000..19edd4da87c1
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs
> @@ -0,0 +1,190 @@
> +What:           /sys/class/habanalabs/hl<n>/armcp_kernel_ver
> +Date:           Jan 2019
> +KernelVersion:  5.1
> +Contact:        oded.gabbay@gmail.com
> +Description:    Version of the Linux kernel running on the device's CPU

Hey, nice!  We can see how old that kernel gets over time :)

> +What:           /sys/class/habanalabs/hl<n>/soft_reset_cnt
> +Date:           Jan 2019
> +KernelVersion:  5.1
> +Contact:        oded.gabbay@gmail.com
> +Description:    Displays how many times the device have undergone a soft-reset
> +                operation

"how many times" since when?  Power on?  Kernel boot?  Driver load?

> +static ssize_t mme_clk_show(struct device *dev, struct device_attribute *attr,
> +				char *buf)
> +{
> +	struct hl_device *hdev = dev_get_drvdata(dev);
> +	long value;
> +
> +	if (hdev->disabled)
> +		return -ENODEV;
> +
> +	value = hl_get_frequency(hdev, MME_PLL, false);
> +
> +	if (value < 0)
> +		return value;
> +
> +	return snprintf(buf, PAGE_SIZE, "%lu\n", value);

Meta-comment.  You do this in all of your sysfs show functions, and I
understand the "I want to be safe!" feeling here, but you should just
use sprintf().  The size of a sysfs buffer is PAGE_SIZE, and you should
never even get close to it if you are only writing a single numeric
value.

So no need to do anything fancy, just use sprintf() please.

> +static DEVICE_ATTR_RW(mme_clk);
> +static DEVICE_ATTR_RW(tpc_clk);
> +static DEVICE_ATTR_RW(ic_clk);
> +static DEVICE_ATTR_RO(mme_clk_curr);
> +static DEVICE_ATTR_RO(tpc_clk_curr);
> +static DEVICE_ATTR_RO(ic_clk_curr);

Some people like to put the macro right under the show/store functions,
to keep them all in one place.  Makes it easier to change/add things
later over time.

> +int goya_add_device_attr(struct hl_device *hdev)
> +{
> +	int rc;
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_mme_clk);
> +	if (rc) {
> +		dev_err(hdev->dev, "failed to create device file mme_clk\n");
> +		return rc;
> +	}
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_tpc_clk);
> +	if (rc) {
> +		dev_err(hdev->dev, "failed to create device file tpc_clk\n");
> +		goto remove_mme_clk;
> +	}
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_ic_clk);
> +	if (rc) {
> +		dev_err(hdev->dev, "failed to create device file ic_clk\n");
> +		goto remove_tpc_clk;
> +	}
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_mme_clk_curr);
> +	if (rc) {
> +		dev_err(hdev->dev,
> +			"failed to create device file mme_clk_curr\n");
> +		goto remove_ic_clk;
> +	}
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_tpc_clk_curr);
> +	if (rc) {
> +		dev_err(hdev->dev,
> +			"failed to create device file tpc_clk_curr\n");
> +		goto remove_mme_clk_curr;
> +	}
> +
> +	rc = device_create_file(hdev->dev, &dev_attr_ic_clk_curr);
> +	if (rc) {
> +		dev_err(hdev->dev,
> +			"failed to create device file ic_clk_curr\n");
> +		goto remove_tpc_clk_curr;
> +	}


You do know about attribute groups, right?  Please use them so you don't
have to hand-roll the "add a bunch of files" logic here and elsewhere.
The driver core will just automatically add and remove all of the files
when the device is bound properly without you having to do anything.
That saves you a lot of code and debugging logic.

Same for your other lists of attributes, they can all be handled
automatically, no need for this type of logic.

thanks,

greg k-h

  reply	other threads:[~2019-02-08 12:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 20:32 [PATCH v3 00/15] Habana Labs kernel driver Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 01/15] habanalabs: add skeleton driver Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 03/15] habanalabs: add basic Goya support Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 04/15] habanalabs: add context and ASID modules Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 05/15] habanalabs: add command buffer module Oded Gabbay
2019-02-08 12:06   ` Greg KH
2019-02-08 19:53     ` Oded Gabbay
2019-02-09  9:09       ` Greg KH
2019-02-04 20:32 ` [PATCH v3 06/15] habanalabs: add basic Goya h/w initialization Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 07/15] habanalabs: add h/w queues module Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 08/15] habanalabs: add event queue and interrupts Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 09/15] habanalabs: add sysfs and hwmon support Oded Gabbay
2019-02-08 12:14   ` Greg KH [this message]
2019-02-08 21:18     ` Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 10/15] habanalabs: add device reset support Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 11/15] habanalabs: add command submission module Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 12/15] habanalabs: add virtual memory and MMU modules Oded Gabbay
2019-02-06 15:14   ` Mike Rapoport
2019-02-07 13:15     ` Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 13/15] habanalabs: implement INFO IOCTL Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 14/15] habanalabs: add debugfs support Oded Gabbay
2019-02-06 15:16   ` Mike Rapoport
2019-02-08 12:16   ` Greg KH
2019-02-08 21:24     ` Oded Gabbay
2019-02-04 20:32 ` [PATCH v3 15/15] Update MAINTAINERS and CREDITS with habanalabs info Oded Gabbay
2019-02-06 11:52 ` [PATCH v3 00/15] Habana Labs kernel driver Mike Rapoport
2019-02-08 21:33   ` Oded Gabbay
2019-02-08 21:43     ` Joe Perches
2019-02-08 21:44       ` 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=20190208121402.GB23483@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oded.gabbay@gmail.com \
    --cc=ogabbay@habana.ai \
    --cc=olof@lixom.net \
    --cc=rppt@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).