From: Alexander Duyck <alexander.duyck@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "David E. Box" <david.e.box@linux.intel.com>,
Lee Jones <lee.jones@linaro.org>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Alexey Budankov <alexey.budankov@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: [PATCH V7 4/5] platform/x86: Intel PMT Telemetry capability driver
Date: Thu, 1 Oct 2020 09:46:26 -0700 [thread overview]
Message-ID: <CAKgT0UcJXEeC4ZNQ0vq6Q6gBQeUe9uaFDHoDNoTjL0eYWaYUEA@mail.gmail.com> (raw)
In-Reply-To: <CAHp75VfcXbedZbbF3KATWYMR1SPXusuaU+vrkvM1zsRpYzDFiA@mail.gmail.com>
On Thu, Oct 1, 2020 at 9:03 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Oct 1, 2020 at 4:43 AM David E. Box <david.e.box@linux.intel.com> wrote:
> >
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > PMT Telemetry is a capability of the Intel Platform Monitoring Technology.
> > The Telemetry capability provides access to device telemetry metrics that
> > provide hardware performance data to users from read-only register spaces.
> >
> > With this driver present the intel_pmt directory can be populated with
> > telem<x> devices. These devices will contain the standard intel_pmt sysfs
> > data and a "telem" binary sysfs attribute which can be used to access the
> > telemetry data.
>
> ...
>
> > +static DEFINE_XARRAY_ALLOC(telem_array);
> > +static struct intel_pmt_namespace pmt_telem_ns = {
> > + .name = "telem",
> > + .xa = &telem_array
>
> Leave comma at the end.
>
> > +};
> > +
> > +/*
> > + * driver initialization
> > + */
>
> This is a useless comment.
>
> > + size = offsetof(struct pmt_telem_priv, entry[pdev->num_resources]);
> > + priv = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
>
> Please, use struct_size() from overflow.h instead of custom approach.
>
> ...
So all of the above make sense and can be fixed shortly and pushed as
a v8 for both the telemetry and crashlog drivers.
> > +static struct platform_driver pmt_telem_driver = {
> > + .driver = {
> > + .name = TELEM_DEV_NAME,
>
> I'm not sure I have interpreted this:
> - Use 'raw' string instead of defines for device names
> correctly. Can you elaborate?
Can you point me to a reference of that? I'm not sure what you are referring to.
> > + },
> > + .remove = pmt_telem_remove,
> > + .probe = pmt_telem_probe,
> > +};
>
> ...
>
> > +MODULE_ALIAS("platform:" TELEM_DEV_NAME);
>
> Ditto.
This doesn't make sense to me. Are you saying we are expected to use
"pmt_telemetry" everywhere instead of the define? It seems like that
would be much more error prone. It seems like common practice to use
DRV_NAME throughout a driver for these sort of things so if you are
wanting us to rename it to that I am fine with that, but I am not sure
getting rid of the use of a define makes sense.
next prev parent reply other threads:[~2020-10-01 16:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 1:42 [PATCH V7 0/5] Intel Platform Monitoring Technology David E. Box
2020-10-01 1:42 ` [PATCH V7 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
2020-10-01 1:42 ` [PATCH V7 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
2020-10-01 1:42 ` [PATCH V7 3/5] platform/x86: Intel PMT class driver David E. Box
2020-10-01 16:23 ` Andy Shevchenko
2020-10-01 17:44 ` Alexander Duyck
2020-10-01 18:06 ` Andy Shevchenko
2020-10-01 19:02 ` Alexander Duyck
2020-10-01 1:42 ` [PATCH V7 4/5] platform/x86: Intel PMT Telemetry capability driver David E. Box
2020-10-01 16:00 ` Andy Shevchenko
2020-10-01 16:46 ` Alexander Duyck [this message]
2020-10-01 17:54 ` Andy Shevchenko
2020-10-01 1:42 ` [PATCH V7 5/5] platform/x86: Intel PMT Crashlog " David E. Box
2020-10-01 16:35 ` Andy Shevchenko
2020-10-01 18:33 ` Alexander Duyck
2020-10-01 18:46 ` Andy Shevchenko
2020-10-01 19:15 ` Alexander Duyck
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=CAKgT0UcJXEeC4ZNQ0vq6Q6gBQeUe9uaFDHoDNoTjL0eYWaYUEA@mail.gmail.com \
--to=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=andy@infradead.org \
--cc=bhelgaas@google.com \
--cc=david.e.box@linux.intel.com \
--cc=dvhart@infradead.org \
--cc=hdegoede@redhat.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/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).