All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "David E. Box" <david.e.box@linux.intel.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Michael J. Ruhl" <michael.j.ruhl@intel.com>,
	intel-xe@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org,
	"Hans de Goede" <hdegoede@redhat.com>,
	rodrigo.vivi@intel.com, lucas.demarchi@intel.com
Subject: Re: [PATCH v2 0/2] Support BMG PMT features for Xe
Date: Wed, 13 Nov 2024 20:59:05 +0200	[thread overview]
Message-ID: <ZzT2-R2uiXn_cHRT@smile.fi.intel.com> (raw)
In-Reply-To: <7e22fc28bd8d81d42c75166b8792eaf0d856a413.camel@linux.intel.com>

On Wed, Nov 13, 2024 at 10:40:42AM -0800, David E. Box wrote:
> On Wed, 2024-11-13 at 15:52 +0200, Ilpo Järvinen wrote:
> > On Wed, 13 Nov 2024, Andy Shevchenko wrote:
> > > On Tue, Nov 12, 2024 at 11:30:33AM -0500, Michael J. Ruhl wrote:
> > > > Updates for PMT to support user offsets from the sysfs API.
> > > > 
> > > > Addressed review comments for the Xe driver udpates.
> > > 
> > > FWIW,
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > 
> > > If you have wish and time, there are problems with the drivers of different
> > > severities (from "fine as is" to "good to be fixed, but okay as is") I have
> > > noticed so far:
> > > - it uses s*printf() instead of sysfs_emit*()
> > > - it most likely never tested the corner cases. e.g.,
> > > 
> > > 	if (disc_res->start >= pci_resource_start(pci_dev, i) &&
> > > 	    (disc_res->start <= pci_resource_end(pci_dev, i))) {
> > > 
> > >   what is this supposed to mean? Probably someone wanted resource_contains()
> > > or
> > >   alike to be called here.
> 
> This is a corner case that occurs for devices that are non-compliant, in this
> case meaning devices that don't follow our PMT spec convention of specifying
> which BAR an address belongs to. Without this information, we have to deduce the
> BAR manually to access other needed registers that are offset from the base of
> that BAR.

What I am pointing out is that we compare start address (and only start!) to
both, start _and_ end of the given resource. So currently the second check is
redundant and that looks suspicious. I believe one wanted to have

	if (disc_res->start >= pci_resource_start(pci_dev, i) &&
	    (disc_res->end <= pci_resource_end(pci_dev, i))) {

(note end!) and if using helpers, this would never happened :-)

> I can change this to use resource_contains().

Please, will clarify the above confusion..

> > > - slightly above the above piece the for-loop
> > > 
> > > 	for (i = 0; i < 6; i++)
> > > 
> > >   which probably want to use PCI_STD_RESOURCE_END)
> > 
> > While both work, in practice PCI_STD_NUM_BARS is way more common than 
> > PCI_STD_RESOURCE_END.
> 
> Will change this too. Thanks.

You are welcome!

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-11-13 18:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-12 16:30 [PATCH v2 0/2] Support BMG PMT features for Xe Michael J. Ruhl
2024-11-12 16:30 ` [PATCH v2 1/2] platform/x86/intel/pmt: allow user offset for PMT callbacks Michael J. Ruhl
2024-11-13 10:26   ` Andy Shevchenko
2024-11-13 21:57     ` Ruhl, Michael J
2024-11-12 16:30 ` [PATCH v2 2/2] drm/xe/vsec: Support BMG devices Michael J. Ruhl
2024-11-13  7:55 ` ✓ CI.Patch_applied: success for Support BMG PMT features for Xe Patchwork
2024-11-13  7:55 ` ✗ CI.checkpatch: warning " Patchwork
2024-11-13  7:56 ` ✓ CI.KUnit: success " Patchwork
2024-11-13  8:08 ` ✓ CI.Build: " Patchwork
2024-11-13  8:10 ` ✓ CI.Hooks: " Patchwork
2024-11-13  8:11 ` ✓ CI.checksparse: " Patchwork
2024-11-13  8:29 ` ✓ CI.BAT: " Patchwork
2024-11-13 10:06 ` ✗ CI.FULL: failure " Patchwork
2024-11-13 10:18 ` [PATCH v2 0/2] " Andy Shevchenko
2024-11-13 10:38 ` Andy Shevchenko
2024-11-13 13:52   ` Ilpo Järvinen
2024-11-13 17:55     ` Andy Shevchenko
2024-11-13 18:40     ` David E. Box
2024-11-13 18:59       ` Andy Shevchenko [this message]
2024-11-13 21:00         ` David E. Box
2024-11-13 18:21   ` Ruhl, Michael J

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=ZzT2-R2uiXn_cHRT@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=david.e.box@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rodrigo.vivi@intel.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 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.