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: lee.jones@linaro.org, hdegoede@redhat.com, bhelgaas@google.com,
	gregkh@linuxfoundation.org, srinivas.pandruvada@intel.com,
	mgross@linux.intel.com, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-pci@vger.kernel.org,
	Mark Gross <markgross@kernel.org>
Subject: Re: [PATCH V3 3/6] platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus
Date: Mon, 13 Dec 2021 20:27:51 +0200	[thread overview]
Message-ID: <YbeQpyIijHbPHktN@smile.fi.intel.com> (raw)
In-Reply-To: <20211213175921.1897860-4-david.e.box@linux.intel.com>

On Mon, Dec 13, 2021 at 09:59:18AM -0800, David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) support is indicated by presence
> of an Intel defined PCIe Designated Vendor Specific Extended Capabilities
> (DVSEC) structure with a PMT specific ID. The current MFD implementation
> creates child devices for each PMT feature, currently telemetry, watcher,
> and crashlog. However DVSEC structures may also be used by Intel to
> indicate support for other features. The Out Of Band Management Services
> Module (OOBMSM) uses DVSEC to enumerate several features, including PMT.
> In order to support them it is necessary to modify the intel_pmt driver to
> handle the creation of the child devices more generically. To that end,
> modify the driver to create child devices for any VSEC/DVSEC features on
> supported devices (indicated by PCI ID).  Additionally, move the
> implementation from MFD to the Auxiliary bus.  VSEC/DVSEC features are
> really multifunctional PCI devices, not platform devices as MFD was
> designed for. Auxiliary bus gives more flexibility by allowing the
> definition of custom structures that can be shared between associated
> auxiliary devices and the parent device. Also, rename the driver from
> intel_pmt to intel_vsec to better reflect the purpose.
> 
> This series also removes the current runtime pm support which was not
> complete to begin with. None of the current devices require runtime pm.
> However the support will be replaced when a device is added that requires
> it.

...

> +static bool intel_vsec_walk_dvsec(struct pci_dev *pdev, unsigned long quirks)
> +{
> +	bool have_devices = false;
> +	int pos = 0;
> +
> +	do {
> +		struct intel_vsec_header header;
> +		u32 table, hdr;
> +		u16 vid;
> +		int ret;
> +
> +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> +		if (!pos)
> +			break;
> +
> +		pci_read_config_dword(pdev, pos + PCI_DVSEC_HEADER1, &hdr);
> +		vid = PCI_DVSEC_HEADER1_VID(hdr);
> +		if (vid != PCI_VENDOR_ID_INTEL)
> +			continue;
> +
> +		/* Support only revision 1 */
> +		header.rev = PCI_DVSEC_HEADER1_REV(hdr);
> +		if (header.rev != 1) {
> +			dev_info(&pdev->dev, "Unsupported DVSEC revision %d\n", header.rev);
> +			continue;
> +		}
> +
> +		header.length = PCI_DVSEC_HEADER1_LEN(hdr);
> +
> +		pci_read_config_byte(pdev, pos + INTEL_DVSEC_ENTRIES, &header.num_entries);
> +		pci_read_config_byte(pdev, pos + INTEL_DVSEC_SIZE, &header.entry_size);
> +		pci_read_config_dword(pdev, pos + INTEL_DVSEC_TABLE, &table);
> +
> +		header.tbir = INTEL_DVSEC_TABLE_BAR(table);
> +		header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
> +
> +		pci_read_config_dword(pdev, pos + PCI_DVSEC_HEADER2, &hdr);
> +		header.id = PCI_DVSEC_HEADER2_ID(hdr);
> +
> +		ret = intel_vsec_add_dev(pdev, &header, quirks);
> +		if (ret)
> +			continue;
> +
> +		have_devices = true;
> +	} while (true);
> +
> +	return have_devices;
> +}
> +
> +static bool intel_vsec_walk_vsec(struct pci_dev *pdev, unsigned long quirks)
> +{
> +	bool have_devices = false;
> +	int pos = 0;
> +
> +	do {
> +		struct intel_vsec_header header;
> +		u32 table, hdr;
> +		int ret;
> +
> +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_VNDR);
> +		if (!pos)
> +			break;
> +
> +		pci_read_config_dword(pdev, pos + PCI_VNDR_HEADER, &hdr);
> +
> +		/* Support only revision 1 */
> +		header.rev = PCI_VNDR_HEADER_REV(hdr);
> +		if (header.rev != 1) {
> +			dev_info(&pdev->dev, "Unsupported VSEC revision %d\n", header.rev);
> +			continue;
> +		}
> +
> +		header.id = PCI_VNDR_HEADER_ID(hdr);
> +		header.length = PCI_VNDR_HEADER_LEN(hdr);
> +
> +		/* entry, size, and table offset are the same as DVSEC */
> +		pci_read_config_byte(pdev, pos + INTEL_DVSEC_ENTRIES, &header.num_entries);
> +		pci_read_config_byte(pdev, pos + INTEL_DVSEC_SIZE, &header.entry_size);
> +		pci_read_config_dword(pdev, pos + INTEL_DVSEC_TABLE, &table);
> +
> +		header.tbir = INTEL_DVSEC_TABLE_BAR(table);
> +		header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
> +
> +		ret = intel_vsec_add_dev(pdev, &header, quirks);
> +		if (ret)
> +			continue;
> +
> +		have_devices = true;
> +	} while (true);
> +
> +	return have_devices;
> +}


I'm wondering if it makes sense to refactor each of the above to something like

int intel_vsec_extract_vsec(...)
{
	...
}

static bool intel_vsec_walk_dvsec(struct pci_dev *pdev, unsigned long quirks)
{
	bool have_devices = false;
	int pos;

	while ((pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC))) {
		if (intel_vsec_extract_vsec())
			continue;

		have_devices = true;
	}

	return have_devices;
}

Either way, it may be worth to convert infinite loops to ones with the clear
exit condition.

...

> +	/*
> +	 * Driver cleanup handled by intel_vsec_remove_aux() which is added
> +	 * to the pci device as a devm action

PCI

Grammatical period at the end.

> +	 */

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-12-13 18:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 17:59 [PATCH V3 0/6] Auxiliary bus driver support for Intel PCIe VSEC/DVSEC David E. Box
2021-12-13 17:59 ` [PATCH V3 1/6] PCI: Add #defines for accessing PCIe DVSEC fields David E. Box
2021-12-13 17:59 ` [PATCH V3 2/6] driver core: auxiliary bus: Add driver data helpers David E. Box
2021-12-13 18:04   ` Andy Shevchenko
2021-12-13 18:19     ` David E. Box
2021-12-13 17:59 ` [PATCH V3 3/6] platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus David E. Box
2021-12-13 18:27   ` Andy Shevchenko [this message]
2021-12-13 21:18     ` David E. Box
2021-12-13 17:59 ` [PATCH V3 4/6] platform/x86: Add Intel Software Defined Silicon driver David E. Box
2021-12-15  6:39   ` kernel test robot
2021-12-15  6:39     ` kernel test robot
2021-12-13 17:59 ` [PATCH V3 5/6] tools arch x86: Add Intel SDSi provisioning tool David E. Box
2021-12-13 17:59 ` [PATCH V3 6/6] selftests: sdsi: test sysfs setup David E. Box

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=YbeQpyIijHbPHktN@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=david.e.box@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=srinivas.pandruvada@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.