<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/include/linux/pci.h, branch v6.12-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'pci/misc'</title>
<updated>2024-09-19T19:25:34+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-09-19T19:25:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5dc07a20ac1c6882e191f821f9c75edde958224d'/>
<id>5dc07a20ac1c6882e191f821f9c75edde958224d</id>
<content type='text'>
- Check pcie_find_root_port() return in x86 fixups to avoid NULL pointer
  dereferences (Samasth Norway Ananda)

- Make pci_bus_type constant (Kunwu Chan)

- Remove unused declarations of __pci_pme_wakeup() and pci_vpd_release()
  (Yue Haibing)

- Remove any leftover .*.cmd files with make clean (zhang jiao)

* pci/misc:
  PCI: Fix typos
  PCI/VPD: Remove pci_vpd_release() unused declarations
  PCI/PM: Remove __pci_pme_wakeup() unused declarations
  PCI: Make pci_bus_type constant
  x86/PCI: Check pcie_find_root_port() return for NULL
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Check pcie_find_root_port() return in x86 fixups to avoid NULL pointer
  dereferences (Samasth Norway Ananda)

- Make pci_bus_type constant (Kunwu Chan)

- Remove unused declarations of __pci_pme_wakeup() and pci_vpd_release()
  (Yue Haibing)

- Remove any leftover .*.cmd files with make clean (zhang jiao)

* pci/misc:
  PCI: Fix typos
  PCI/VPD: Remove pci_vpd_release() unused declarations
  PCI/PM: Remove __pci_pme_wakeup() unused declarations
  PCI: Make pci_bus_type constant
  x86/PCI: Check pcie_find_root_port() return for NULL
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'pci/controller/qcom'</title>
<updated>2024-09-19T19:25:32+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-09-19T19:25:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=45e981b86df3fa04ac581b8a462be6f32453bf53'/>
<id>45e981b86df3fa04ac581b8a462be6f32453bf53</id>
<content type='text'>
- Drop endpoint redundant masking of global IRQ events (Manivannan
  Sadhasivam)

- Clarify unknown global IRQ message and only log it once to avoid a flood
  (Manivannan Sadhasivam)

- Add Manivannan Sadhasivam as maintainer of qcom endpoint driver
  (Manivannan Sadhasivam)

- Add 'linux,pci-domain' property to endpoint DT binding (Manivannan
  Sadhasivam)

- Assign PCI domain number for endpoint controllers (Manivannan Sadhasivam)

- Add 'qcom_pcie_ep' and the PCI domain number to IRQ names for endpoint
  controller (Manivannan Sadhasivam)

- Add global SPI interrupt for PCIe link events to DT binding (Manivannan
  Sadhasivam)

- Add global RC interrupt handler to handle 'Link up' events and
  automatically enumerate hot-added devices (Manivannan Sadhasivam)

- Avoid mirroring of DBI and iATU register space so it doesn't overlap BAR
  MMIO space (Prudhvi Yarlagadda)

- Enable controller resources like PHY only after PERST# is deasserted to
  partially avoid the problem that the endpoint SoC crashes when accessing
  things when Refclk is absent (Manivannan Sadhasivam)

- Rename dw_pcie.link_gen to max_link_speed to avoid ambiguity (Manivannan
  Sadhasivam)

- Cache maximum link speed value in dw_pcie.max_link_speed for use by
  vendor drivers (Manivannan Sadhasivam)

- Add 16.0 GT/s equalization and RX lane margining settings (Shashank Babu
  Chinta Venkata)

- Pass domain number to pci_bus_release_domain_nr() explicitly to avoid a
  NULL pointer dereference (Manivannan Sadhasivam)

* pci/controller/qcom:
  PCI: Pass domain number to pci_bus_release_domain_nr() explicitly
  PCI: qcom: Add RX lane margining settings for 16.0 GT/s
  PCI: qcom: Add equalization settings for 16.0 GT/s
  PCI: dwc: Always cache the maximum link speed value in dw_pcie::max_link_speed
  PCI: dwc: Rename 'dw_pcie::link_gen' to 'dw_pcie::max_link_speed'
  PCI: qcom-ep: Enable controller resources like PHY only after refclk is available
  PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region
  PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt
  dt-bindings: PCI: qcom,pcie-sm8450: Add 'global' interrupt
  PCI: qcom-ep: Modify 'global_irq' and 'perst_irq' IRQ device names
  PCI: endpoint: Assign PCI domain number for endpoint controllers
  dt-bindings: PCI: pci-ep: Document 'linux,pci-domain' property
  dt-bindings: PCI: pci-ep: Update Maintainers
  PCI: qcom-ep: Reword the error message for receiving unknown global IRQ event
  PCI: qcom-ep: Drop the redundant masking of global IRQ events
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Drop endpoint redundant masking of global IRQ events (Manivannan
  Sadhasivam)

- Clarify unknown global IRQ message and only log it once to avoid a flood
  (Manivannan Sadhasivam)

- Add Manivannan Sadhasivam as maintainer of qcom endpoint driver
  (Manivannan Sadhasivam)

- Add 'linux,pci-domain' property to endpoint DT binding (Manivannan
  Sadhasivam)

- Assign PCI domain number for endpoint controllers (Manivannan Sadhasivam)

- Add 'qcom_pcie_ep' and the PCI domain number to IRQ names for endpoint
  controller (Manivannan Sadhasivam)

- Add global SPI interrupt for PCIe link events to DT binding (Manivannan
  Sadhasivam)

- Add global RC interrupt handler to handle 'Link up' events and
  automatically enumerate hot-added devices (Manivannan Sadhasivam)

- Avoid mirroring of DBI and iATU register space so it doesn't overlap BAR
  MMIO space (Prudhvi Yarlagadda)

- Enable controller resources like PHY only after PERST# is deasserted to
  partially avoid the problem that the endpoint SoC crashes when accessing
  things when Refclk is absent (Manivannan Sadhasivam)

- Rename dw_pcie.link_gen to max_link_speed to avoid ambiguity (Manivannan
  Sadhasivam)

- Cache maximum link speed value in dw_pcie.max_link_speed for use by
  vendor drivers (Manivannan Sadhasivam)

- Add 16.0 GT/s equalization and RX lane margining settings (Shashank Babu
  Chinta Venkata)

- Pass domain number to pci_bus_release_domain_nr() explicitly to avoid a
  NULL pointer dereference (Manivannan Sadhasivam)

* pci/controller/qcom:
  PCI: Pass domain number to pci_bus_release_domain_nr() explicitly
  PCI: qcom: Add RX lane margining settings for 16.0 GT/s
  PCI: qcom: Add equalization settings for 16.0 GT/s
  PCI: dwc: Always cache the maximum link speed value in dw_pcie::max_link_speed
  PCI: dwc: Rename 'dw_pcie::link_gen' to 'dw_pcie::max_link_speed'
  PCI: qcom-ep: Enable controller resources like PHY only after refclk is available
  PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region
  PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt
  dt-bindings: PCI: qcom,pcie-sm8450: Add 'global' interrupt
  PCI: qcom-ep: Modify 'global_irq' and 'perst_irq' IRQ device names
  PCI: endpoint: Assign PCI domain number for endpoint controllers
  dt-bindings: PCI: pci-ep: Document 'linux,pci-domain' property
  dt-bindings: PCI: pci-ep: Update Maintainers
  PCI: qcom-ep: Reword the error message for receiving unknown global IRQ event
  PCI: qcom-ep: Drop the redundant masking of global IRQ events
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'pci/npem'</title>
<updated>2024-09-19T19:25:26+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-09-19T19:25:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9d4f1c0747e2937c830d135a460d727002caed3d'/>
<id>9d4f1c0747e2937c830d135a460d727002caed3d</id>
<content type='text'>
- Initialize leds class earlier (with an unfortunate Makefile ordering
  change) so the PCI NPEM driver can use it (Mariusz Tkaczyk)

- Add Native PCIe Enclosure Management (NPEM) support for sysfs control of
  NVMe RAID storage indicators (ok/fail/locate/rebuild/etc) (Mariusz
  Tkaczyk)

- Add support for the ACPI _DSM PCIe SSD status LED management, which is
  functionally similar to NPEM but mediated by platform firmware (Mariusz
  Tkaczyk)

* pci/npem:
  PCI/NPEM: Add _DSM PCIe SSD status LED management
  PCI/NPEM: Add Native PCIe Enclosure Management support
  leds: Init leds class earlier
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Initialize leds class earlier (with an unfortunate Makefile ordering
  change) so the PCI NPEM driver can use it (Mariusz Tkaczyk)

- Add Native PCIe Enclosure Management (NPEM) support for sysfs control of
  NVMe RAID storage indicators (ok/fail/locate/rebuild/etc) (Mariusz
  Tkaczyk)

- Add support for the ACPI _DSM PCIe SSD status LED management, which is
  functionally similar to NPEM but mediated by platform firmware (Mariusz
  Tkaczyk)

* pci/npem:
  PCI/NPEM: Add _DSM PCIe SSD status LED management
  PCI/NPEM: Add Native PCIe Enclosure Management support
  leds: Init leds class earlier
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'pci/devres'</title>
<updated>2024-09-19T19:25:25+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-09-19T19:25:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dceed69701ac2ac357c062117a3f201096c4bdab'/>
<id>dceed69701ac2ac357c062117a3f201096c4bdab</id>
<content type='text'>
- Export pcim_request_region(), a managed counterpart of
  pci_request_region(), for use by drivers (Philipp Stanner)

- Request the PCI BAR used by xboxvideo (Philipp Stanner)

- Export pcim_iomap_region() and deprecate pcim_iomap_regions() (Philipp
  Stanner)

- Request and map drm/ast BARs with pcim_iomap_region() (Philipp Stanner)

* pci/devres:
  drm/ast: Request PCI BAR with devres
  PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()
  drm/vboxvideo: Add PCI region request
  PCI: Make pcim_request_region() a public function
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Export pcim_request_region(), a managed counterpart of
  pci_request_region(), for use by drivers (Philipp Stanner)

- Request the PCI BAR used by xboxvideo (Philipp Stanner)

- Export pcim_iomap_region() and deprecate pcim_iomap_regions() (Philipp
  Stanner)

- Request and map drm/ast BARs with pcim_iomap_region() (Philipp Stanner)

* pci/devres:
  drm/ast: Request PCI BAR with devres
  PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()
  drm/vboxvideo: Add PCI region request
  PCI: Make pcim_request_region() a public function
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Pass domain number to pci_bus_release_domain_nr() explicitly</title>
<updated>2024-09-13T22:12:29+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@linaro.org</email>
</author>
<published>2024-09-12T05:30:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0cca961a026177af69044f10d6ae76d8ce043764'/>
<id>0cca961a026177af69044f10d6ae76d8ce043764</id>
<content type='text'>
The pci_bus_release_domain_nr() API is supposed to free the domain
number allocated by pci_bus_find_domain_nr(). Most of the callers of
pci_bus_find_domain_nr(), store the domain number in pci_bus::domain_nr.

As such, the pci_bus_release_domain_nr() implicitly frees the domain
number by dereferencing 'struct pci_bus'. However, one of the callers
of this API, the PCI endpoint subsystem, doesn't have 'struct pci_bus',
so it only passes NULL. Due to this, the API will end up dereferencing
the NULL pointer.

To fix this issue, pass the domain number to this API explicitly. Since
'struct pci_bus' is not used for anything else other than extracting the
domain number, it makes sense to pass the domain number directly.

Fixes: 0328947c5032 ("PCI: endpoint: Assign PCI domain number for endpoint controllers")
Closes: https://lore.kernel.org/linux-pci/c0c40ddb-bf64-4b22-9dd1-8dbb18aa2813@stanley.mountain
Link: https://lore.kernel.org/linux-pci/20240912053025.25314-1-manivannan.sadhasivam@linaro.org
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The pci_bus_release_domain_nr() API is supposed to free the domain
number allocated by pci_bus_find_domain_nr(). Most of the callers of
pci_bus_find_domain_nr(), store the domain number in pci_bus::domain_nr.

As such, the pci_bus_release_domain_nr() implicitly frees the domain
number by dereferencing 'struct pci_bus'. However, one of the callers
of this API, the PCI endpoint subsystem, doesn't have 'struct pci_bus',
so it only passes NULL. Due to this, the API will end up dereferencing
the NULL pointer.

To fix this issue, pass the domain number to this API explicitly. Since
'struct pci_bus' is not used for anything else other than extracting the
domain number, it makes sense to pass the domain number directly.

Fixes: 0328947c5032 ("PCI: endpoint: Assign PCI domain number for endpoint controllers")
Closes: https://lore.kernel.org/linux-pci/c0c40ddb-bf64-4b22-9dd1-8dbb18aa2813@stanley.mountain
Link: https://lore.kernel.org/linux-pci/20240912053025.25314-1-manivannan.sadhasivam@linaro.org
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Rename CRS Completion Status to RRS</title>
<updated>2024-09-11T00:52:30+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-08-27T23:48:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=87f10faf166a9114aa0d4132298cad379de16fdd'/>
<id>87f10faf166a9114aa0d4132298cad379de16fdd</id>
<content type='text'>
PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status"
Completion Status from "CRS" to "RRS" and uses the terminology of
"Configuration RRS Software Visibility" instead of "CRS Software
Visibility".

Align the Linux usage with the r6.0 spec language.  No functional change
intended.

It's confusing to make this change, but I think "RRS" *is* a better
abbreviation because it was easy to interpret "CRS" as "Completion Retry
Status", which really didn't make any sense.

Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status"
Completion Status from "CRS" to "RRS" and uses the terminology of
"Configuration RRS Software Visibility" instead of "CRS Software
Visibility".

Align the Linux usage with the r6.0 spec language.  No functional change
intended.

It's confusing to make this change, but I think "RRS" *is* a better
abbreviation because it was easy to interpret "CRS" as "Completion Retry
Status", which really didn't make any sense.

Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Wait for device readiness with Configuration RRS</title>
<updated>2024-09-11T00:52:23+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2024-08-27T23:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d591f6804e7e1310881c9224d72247a2b65039af'/>
<id>d591f6804e7e1310881c9224d72247a2b65039af</id>
<content type='text'>
After a device reset, delays are required before the device can
successfully complete config accesses.  PCIe r6.0, sec 6.6, specifies some
delays required before software can perform config accesses.  Devices that
require more time after those delays may respond to config accesses with
Configuration Request Retry Status (RRS) completions.

Callers of pci_dev_wait() are responsible for delays until the device can
respond to config accesses.  pci_dev_wait() waits any additional time until
the device can successfully complete config accesses.

Reading config space of devices that are not present or not ready typically
returns ~0 (PCI_ERROR_RESPONSE).  Previously we polled the Command register
until we got a value other than ~0.  This is sometimes a problem because
Root Complex handling of RRS completions may include several retries and
implementation-specific behavior that is invisible to software (see sec
2.3.2), so the exponential backoff in pci_dev_wait() may not work as
intended.

Linux enables Configuration RRS Software Visibility on all Root Ports that
support it.  If it is enabled, read the Vendor ID instead of the Command
register.  RRS completions cause immediate return of the 0x0001 reserved
Vendor ID value, so the pci_dev_wait() backoff works correctly.

When a read of Vendor ID eventually completes successfully by returning a
non-0x0001 value (the Vendor ID or 0xffff for VFs), the device should be
initialized and ready to respond to config requests.

For conventional PCI devices or devices below Root Ports that don't support
Configuration RRS Software Visibility, poll the Command register as before.

This was developed independently, but is very similar to Stanislav
Spassov's previous work at
https://lore.kernel.org/linux-pci/20200223122057.6504-1-stanspas@amazon.com

Link: https://lore.kernel.org/r/20240827234848.4429-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Duc Dang &lt;ducdang@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After a device reset, delays are required before the device can
successfully complete config accesses.  PCIe r6.0, sec 6.6, specifies some
delays required before software can perform config accesses.  Devices that
require more time after those delays may respond to config accesses with
Configuration Request Retry Status (RRS) completions.

Callers of pci_dev_wait() are responsible for delays until the device can
respond to config accesses.  pci_dev_wait() waits any additional time until
the device can successfully complete config accesses.

Reading config space of devices that are not present or not ready typically
returns ~0 (PCI_ERROR_RESPONSE).  Previously we polled the Command register
until we got a value other than ~0.  This is sometimes a problem because
Root Complex handling of RRS completions may include several retries and
implementation-specific behavior that is invisible to software (see sec
2.3.2), so the exponential backoff in pci_dev_wait() may not work as
intended.

Linux enables Configuration RRS Software Visibility on all Root Ports that
support it.  If it is enabled, read the Vendor ID instead of the Command
register.  RRS completions cause immediate return of the 0x0001 reserved
Vendor ID value, so the pci_dev_wait() backoff works correctly.

When a read of Vendor ID eventually completes successfully by returning a
non-0x0001 value (the Vendor ID or 0xffff for VFs), the device should be
initialized and ready to respond to config requests.

For conventional PCI devices or devices below Root Ports that don't support
Configuration RRS Software Visibility, poll the Command register as before.

This was developed independently, but is very similar to Stanislav
Spassov's previous work at
https://lore.kernel.org/linux-pci/20200223122057.6504-1-stanspas@amazon.com

Link: https://lore.kernel.org/r/20240827234848.4429-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Duc Dang &lt;ducdang@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/NPEM: Add Native PCIe Enclosure Management support</title>
<updated>2024-09-04T22:25:12+00:00</updated>
<author>
<name>Mariusz Tkaczyk</name>
<email>mariusz.tkaczyk@linux.intel.com</email>
</author>
<published>2024-09-04T10:48:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4e893545ef8712d25f3176790ebb95beb073637e'/>
<id>4e893545ef8712d25f3176790ebb95beb073637e</id>
<content type='text'>
Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does not
give direct access to LEDs. Although each indication *could* represent an
individual LED, multiple indications could also be represented as a single,
multi-color LED or a single LED blinking in a specific interval.  The
specification leaves that open.

Each enabled indication (capability register bit on) is represented as a
ledclass_dev which can be controlled through sysfs. For every ledclass
device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
This corresponds to the NPEM control register (Indication bit on/off).

Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
device which has an NPEM Extended Capability and indication is enabled in
NPEM capability register. For example, these are LEDs created for pcieport
"10000:02:05.0" on my setup:

  leds/
  ├── 10000:02:05.0:enclosure:fail
  ├── 10000:02:05.0:enclosure:locate
  ├── 10000:02:05.0:enclosure:ok
  └── 10000:02:05.0:enclosure:rebuild

They can be also found in "/sys/class/leds" directory. The parent PCIe
device domain/bus/device/function address is used to guarantee uniqueness
across leds subsystem.

To enable/disable a "fail" indication, the "brightness" file can be edited:

  echo 1 &gt; ./leds/10000:02:05.0:enclosure:fail/brightness
  echo 0 &gt; ./leds/10000:02:05.0:enclosure:fail/brightness

PCIe r6.1, sec 7.9.19.2 defines the possible indications.

Multiple indications for same parent PCIe device can conflict and hardware
may update them when processing new request. To avoid issues, driver
refresh all indications by reading back control register.

This driver expects to be the exclusive NPEM extended capability manager.
It waits up to 1 second after imposing new request, it doesn't verify if
controller is busy before write, and it assumes the mutex lock gives
protection from concurrent updates.

If _DSM LED management is available, we assume the platform may be using
NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
driver does not use NPEM. A future patch will add _DSM support; an info
message notes whether NPEM or _DSM is being used.

NPEM is a PCIe extended capability so it should be registered in
pcie_init_capabilities() but it is not possible due to LED dependency.  The
parent pci_device must be added earlier for led_classdev_register() to be
successful. NPEM does not require configuration on kernel side, so it is
safe to register LED devices later.

Link: https://lore.kernel.org/r/20240904104848.23480-3-mariusz.tkaczyk@linux.intel.com
Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Mariusz Tkaczyk &lt;mariusz.tkaczyk@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Stuart Hayes &lt;stuart.w.hayes@gmail.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does not
give direct access to LEDs. Although each indication *could* represent an
individual LED, multiple indications could also be represented as a single,
multi-color LED or a single LED blinking in a specific interval.  The
specification leaves that open.

Each enabled indication (capability register bit on) is represented as a
ledclass_dev which can be controlled through sysfs. For every ledclass
device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
This corresponds to the NPEM control register (Indication bit on/off).

Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
device which has an NPEM Extended Capability and indication is enabled in
NPEM capability register. For example, these are LEDs created for pcieport
"10000:02:05.0" on my setup:

  leds/
  ├── 10000:02:05.0:enclosure:fail
  ├── 10000:02:05.0:enclosure:locate
  ├── 10000:02:05.0:enclosure:ok
  └── 10000:02:05.0:enclosure:rebuild

They can be also found in "/sys/class/leds" directory. The parent PCIe
device domain/bus/device/function address is used to guarantee uniqueness
across leds subsystem.

To enable/disable a "fail" indication, the "brightness" file can be edited:

  echo 1 &gt; ./leds/10000:02:05.0:enclosure:fail/brightness
  echo 0 &gt; ./leds/10000:02:05.0:enclosure:fail/brightness

PCIe r6.1, sec 7.9.19.2 defines the possible indications.

Multiple indications for same parent PCIe device can conflict and hardware
may update them when processing new request. To avoid issues, driver
refresh all indications by reading back control register.

This driver expects to be the exclusive NPEM extended capability manager.
It waits up to 1 second after imposing new request, it doesn't verify if
controller is busy before write, and it assumes the mutex lock gives
protection from concurrent updates.

If _DSM LED management is available, we assume the platform may be using
NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
driver does not use NPEM. A future patch will add _DSM support; an info
message notes whether NPEM or _DSM is being used.

NPEM is a PCIe extended capability so it should be registered in
pcie_init_capabilities() but it is not possible due to LED dependency.  The
parent pci_device must be added earlier for led_classdev_register() to be
successful. NPEM does not require configuration on kernel side, so it is
safe to register LED devices later.

Link: https://lore.kernel.org/r/20240904104848.23480-3-mariusz.tkaczyk@linux.intel.com
Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Mariusz Tkaczyk &lt;mariusz.tkaczyk@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Stuart Hayes &lt;stuart.w.hayes@gmail.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Make pci_bus_type constant</title>
<updated>2024-08-23T17:46:22+00:00</updated>
<author>
<name>Kunwu Chan</name>
<email>chentao@kylinos.cn</email>
</author>
<published>2024-08-23T07:42:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8a48281cfa7f380707d42b649acda3ea36348697'/>
<id>8a48281cfa7f380707d42b649acda3ea36348697</id>
<content type='text'>
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a
const *"), the driver core can properly handle constant struct bus_type,
move the pci_bus_type variable to be a constant structure as well, placing
it into read-only memory which can not be modified at runtime.

Link: https://lore.kernel.org/r/20240823074202.139265-1-kunwu.chan@linux.dev
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Kunwu Chan &lt;chentao@kylinos.cn&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a
const *"), the driver core can properly handle constant struct bus_type,
move the pci_bus_type variable to be a constant structure as well, placing
it into read-only memory which can not be modified at runtime.

Link: https://lore.kernel.org/r/20240823074202.139265-1-kunwu.chan@linux.dev
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Kunwu Chan &lt;chentao@kylinos.cn&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()</title>
<updated>2024-08-09T20:08:35+00:00</updated>
<author>
<name>Philipp Stanner</name>
<email>pstanner@redhat.com</email>
</author>
<published>2024-08-07T08:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d140f80f603584d8282817994c0c6241e736bef4'/>
<id>d140f80f603584d8282817994c0c6241e736bef4</id>
<content type='text'>
pcim_iomap_regions() is a complicated function that uses a bit mask to
determine the BARs the user wishes to request and ioremap. Almost all users
only ever set a single bit in that mask, making that mechanism
questionable.

pcim_iomap_region() is now available as a more simple replacement.

Make pcim_iomap_region() a public function.

Mark pcim_iomap_regions() as deprecated.

Link: https://lore.kernel.org/r/20240807083018.8734-2-pstanner@redhat.com
Signed-off-by: Philipp Stanner &lt;pstanner@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pcim_iomap_regions() is a complicated function that uses a bit mask to
determine the BARs the user wishes to request and ioremap. Almost all users
only ever set a single bit in that mask, making that mechanism
questionable.

pcim_iomap_region() is now available as a more simple replacement.

Make pcim_iomap_region() a public function.

Mark pcim_iomap_regions() as deprecated.

Link: https://lore.kernel.org/r/20240807083018.8734-2-pstanner@redhat.com
Signed-off-by: Philipp Stanner &lt;pstanner@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
