1294525 Commits

Author SHA1 Message Date
Bjorn Helgaas
207bcb73fb Merge branch 'pci/dt-bindings'
- Drop minItems and maxItems from ranges in PCI generic host binding since
  host bridges may have several MMIO and I/O port apertures (Frank Li)

- Add kirin, rcar-gen2, uniphier DT binding top-level constraints for
  clocks (Krzysztof Kozlowski)

- Replace layerscape-pcie DT binding compatible fsl,lx2160a-pcie with
  fsl,lx2160ar2-pcie (Frank Li)

- Add layerscape-pcie DT binding deprecated 'num-viewport' property to
  address a DT checker warning (Frank Li)

- Change layerscape-pcie DT binding 'fsl,pcie-scfg' to phandle-array (Frank
  Li)

- Update qcom,pcie-sc7280 DT binding with eight interrupts (Rayyan Ansari)

- Convert altera DT bindings from text to YAML (Matthew Gerlach)

- Add imx6q-pcie 'dbi2' and 'atu' reg-names for i.MX8M Endpoints (Richard
  Zhu)

- Add back qcom 'vddpe-3v3-supply', which was incorrectly removed earlier
  (Johan Hovold)

* pci/dt-bindings:
  dt-bindings: PCI: qcom: Allow 'vddpe-3v3-supply' again
  dt-bindings: PCI: imx6q-pcie: Add reg-name "dbi2" and "atu" for i.MX8M PCIe Endpoint
  dt-bindings: PCI: altera: msi: Convert to YAML
  dt-bindings: PCI: altera: Convert to YAML
  dt-bindings: PCI: qcom,pcie-sc7280: Update bindings adding eight interrupts
  dt-bindings: PCI: layerscape-pci: Change property 'fsl,pcie-scfg' type
  dt-bindings: PCI: layerscape-pci: Add deprecated property 'num-viewport'
  dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with fsl,lx2160ar2-pcie
  dt-bindings: PCI: socionext,uniphier-pcie-ep: Add top-level constraints
  dt-bindings: PCI: renesas,pci-rcar-gen2: Add top-level constraints
  dt-bindings: PCI: hisilicon,kirin-pcie: Add top-level constraints
  dt-bindings: PCI: host-generic-pci: Drop minItems and maxItems of ranges
2024-09-19 14:25:28 -05:00
Bjorn Helgaas
ed072e447e Merge branch 'pci/sysfs'
- Add ARCH_PCI_DEV_GROUPS so s390 can add its own attribute_groups without
  having to stomp on the core's pdev->dev.groups (Lukas Wunner)

* pci/sysfs:
  s390/pci: Stop usurping pdev->dev.groups
2024-09-19 14:25:27 -05:00
Bjorn Helgaas
f2a3ce1597 Merge branch 'pci/reset'
- Wait for each level of downstream bus, not just the first, to become
  accessible before restoring devices on that bus (Ilpo Järvinen)

* pci/reset:
  PCI: Wait for Link before restoring Downstream Buses
2024-09-19 14:25:27 -05:00
Bjorn Helgaas
d774674f34 Merge branch 'pci/pwrctl'
- Add pwrctl support for ATH11K inside the WCN6855 package (Konrad Dybcio)

* pci/pwrctl:
  PCI/pwrctl: Add WCN6855 support
2024-09-19 14:25:27 -05:00
Bjorn Helgaas
9d4f1c0747 Merge branch 'pci/npem'
- 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
2024-09-19 14:25:26 -05:00
Bjorn Helgaas
e642aa6b38 Merge branch 'pci/iommu'
- Add function 0 DMA alias quirk for Glenfly Arise audio function, which
  uses the function 0 Requester ID (WangYuli)

* pci/iommu:
  PCI: Add function 0 DMA alias quirk for Glenfly Arise chip
2024-09-19 14:25:26 -05:00
Bjorn Helgaas
15a724aa43 Merge branch 'pci/hotplug'
- Remove unnecessary hpc_ops struct from shpchp (ngn)

- Check for PCI_POSSIBLE_ERROR(), not 0xffffffff, in cpqphp (weiyufeng)

* pci/hotplug:
  PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI: shpchp: Remove hpc_ops
2024-09-19 14:25:26 -05:00
Bjorn Helgaas
dffe4cca2e Merge branch 'pci/enumeration'
- Clear LBMS bit after a manual link retrain so we don't try to retrain a
  link when there's no downstream device anymore (Maciej W. Rozycki)

- Revert to the original link speed after retraining fails instead of
  leaving it restricted to 2.5GT/s, so a future device has a chance to use
  higher speeds (Maciej W. Rozycki)

- Correct interpretation of pcie_retrain_link() return status and update it
  to return 0/errno instead of true/false (Maciej W.  Rozycki)

* pci/enumeration:
  PCI: Use an error code with PCIe failed link retraining
  PCI: Correct error reporting with PCIe failed link retraining
  PCI: Revert to the original speed after PCIe failed link retraining
  PCI: Clear the LBMS bit after a link retrain
2024-09-19 14:25:25 -05:00
Bjorn Helgaas
dceed69701 Merge branch 'pci/devres'
- 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
2024-09-19 14:25:25 -05:00
Bjorn Helgaas
59b748cd62 Merge branch 'pci/crs'
- Wait for device readiness after reset by polling Vendor ID and looking
  for Configuration RRS instead of polling the Command register and looking
  for non-error completions (Bjorn Helgaas)

- Fix an aardvark issue with emulating Configuration RRS for two-byte reads
  of Vendor ID; previously it only worked for four-byte reads (Bjorn
  Helgaas)

- Rename CRS Completion Status to RRS to match spec usage (Bjorn Helgaas)

* pci/crs:
  PCI: Rename CRS Completion Status to RRS
  PCI: aardvark: Correct Configuration RRS checking
  PCI: Wait for device readiness with Configuration RRS
2024-09-19 14:25:24 -05:00
Bjorn Helgaas
1a3465598e Merge branch 'pci/aer'
- Use PCI_DEVID() macro in aer_inject() instead of open-coding it (Jinjie
  Ruan)

* pci/aer:
  PCI/AER: Use PCI_DEVID() macro in aer_inject()
2024-09-19 14:25:24 -05:00
Johan Hovold
3cd3b49989 dt-bindings: PCI: qcom: Allow 'vddpe-3v3-supply' again
Commit 756485bfbb85 ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to
dedicated schema") incorrectly removed 'vddpe-3v3-supply' from the
bindings, which results in DT checker warnings like:

  arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-dora.dtb: pcie@600000: Unevaluated properties are not allowed ('vddpe-3v3-supply' was unexpected)
  from schema $id: http://devicetree.org/schemas/pci/qcom,pcie.yaml#

Note that this property has been part of the Qualcomm PCIe bindings since
2018 and would need to be deprecated rather than simply removed if there is
a desire to replace it with 'vpcie3v3' which is used for some non-Qualcomm
controllers.

Link: https://lore.kernel.org/lkml/Zp_LPixNnh-2Fy5N@hovoldconsulting.com/
Fixes: 756485bfbb85 ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to dedicated schema")
Link: https://lore.kernel.org/r/20240723151328.684-1-johan+linaro@kernel.org
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-09-13 18:59:48 -05:00
Richard Zhu
f500a2f128
dt-bindings: PCI: imx6q-pcie: Add reg-name "dbi2" and "atu" for i.MX8M PCIe Endpoint
Add reg-name: "dbi2", "atu" for i.MX8M PCIe Endpoint.

For i.MX8M PCIe EP, the dbi2 and atu addresses are pre-defined in the
driver. This method is not good.

In commit b7d67c6130ee ("PCI: imx6: Add iMX95 Endpoint (EP) support"),
Frank suggests to fetch the dbi2 and atu from DT directly. This commit is
preparation to do that for i.MX8M PCIe EP.

These changes wouldn't break driver function. When "dbi2" and "atu"
properties are present, i.MX PCIe driver would fetch the according base
addresses from DT directly. If only two reg properties are provided, i.MX
PCIe driver would fall back to the old method.

Link: https://lore.kernel.org/linux-pci/1723534943-28499-2-git-send-email-hongxing.zhu@nxp.com
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-13 12:38:54 +00:00
Matthew Gerlach
dff07b5e4b
dt-bindings: PCI: altera: msi: Convert to YAML
Convert the devicetree bindings for the Altera PCIe MSI controller
from text to YAML.

Link: https://lore.kernel.org/linux-pci/20240717181756.2177553-1-matthew.gerlach@linux.intel.com
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
[kwilczynski: remove unused msi0 label]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
2024-09-13 12:38:22 +00:00
Bjorn Helgaas
87f10faf16 PCI: Rename CRS Completion Status to RRS
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 <bhelgaas@google.com>
2024-09-10 19:52:30 -05:00
Bjorn Helgaas
dd4e47eab8 PCI: aardvark: Correct Configuration RRS checking
Per PCIe r6.0, sec 2.3.2, when a Root Complex handles a Completion with
Request Retry Status for a Configuration Read Request that includes both
bytes of the Vendor ID field, it must complete the Request to the host by
returning 0001h for the Vendor ID and all 1's for any additional bytes.

Previously we only returned the 0001h Vendor ID value if we got an RRS
completion for reads of exactly 4 bytes.  A read of 2 bytes would not
qualify, although the spec says it should.

Check for reads of 2 or more bytes including the Vendor ID.

I don't think this will fix any observable problems because RRS only
applies to the first config reads after reset, and those are all currently
dword (4-byte) reads.

Link: https://lore.kernel.org/r/20240827234848.4429-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-09-10 19:52:30 -05:00
Bjorn Helgaas
d591f6804e PCI: Wait for device readiness with Configuration RRS
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 <bhelgaas@google.com>
Tested-by: Duc Dang <ducdang@google.com>
2024-09-10 19:52:23 -05:00
Maciej W. Rozycki
59100eb248
PCI: Use an error code with PCIe failed link retraining
Given how the call place in pcie_wait_for_link_delay() got structured now,
and that pcie_retrain_link() returns a potentially useful error code,
convert pcie_failed_link_retrain() to return an error code rather than a
boolean status, fixing handling at the call site mentioned.  Update the
other call site accordingly.

Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.uk
Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+
2024-09-09 14:03:36 +00:00
Maciej W. Rozycki
712e49c967
PCI: Correct error reporting with PCIe failed link retraining
Only return successful completion status from pcie_failed_link_retrain() if
retraining has actually been done, preventing excessive delays from being
triggered at call sites in a hope that communication will finally be
established with the downstream device where in fact nothing has been done
about the link in question that would justify such a hope.

Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133260.61955@angie.orcam.me.uk
Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+
2024-09-09 13:58:38 +00:00
Maciej W. Rozycki
f68dea1340
PCI: Revert to the original speed after PCIe failed link retraining
When `pcie_failed_link_retrain' has failed to retrain the link by hand
it leaves the link speed restricted to 2.5GT/s, which will then affect
any device that has been plugged in later on, which may not suffer from
the problem that caused the speed restriction to have been attempted.
Consequently such a downstream device will suffer from an unnecessary
communication throughput limitation and therefore performance loss.

Remove the speed restriction then and revert the Link Control 2 register
to its original state if link retraining with the speed restriction in
place has failed.  Retrain the link again afterwards so as to remove any
residual state, waiting on LT rather than DLLLA to avoid an excessive
delay and ignoring the result as this training is supposed to fail
anyway.

Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/linux-pci/alpine.DEB.2.21.2408251412590.30766@angie.orcam.me.uk
Reported-by: Matthew W Carlis <mattc@purestorage.com>
Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+
2024-09-09 13:58:25 +00:00
Maciej W. Rozycki
8037ac08c2
PCI: Clear the LBMS bit after a link retrain
The LBMS bit, where implemented, is set by hardware either in response
to the completion of retraining caused by writing 1 to the Retrain Link
bit or whenever hardware has changed the link speed or width in attempt
to correct unreliable link operation.  It is never cleared by hardware
other than by software writing 1 to the bit position in the Link Status
register and we never do such a write.

We currently have two places, namely apply_bad_link_workaround() and
pcie_failed_link_retrain() in drivers/pci/controller/dwc/pcie-tegra194.c
and drivers/pci/quirks.c respectively where we check the state of the LBMS
bit and neither is interested in the state of the bit resulting from the
completion of retraining, both check for a link fault.

And in particular pcie_failed_link_retrain() causes issues consequently, by
trying to retrain a link where there's no downstream device anymore and the
state of 1 in the LBMS bit has been retained from when there was a device
downstream that has since been removed.

Clear the LBMS bit then at the conclusion of pcie_retrain_link(), so that
we have a single place that controls it and that our code can track link
speed or width changes resulting from unreliable link operation.

Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133140.61955@angie.orcam.me.uk
Reported-by: Matthew W Carlis <mattc@purestorage.com>
Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: <stable@vger.kernel.org> # v6.5+
2024-09-09 13:42:31 +00:00
Mariusz Tkaczyk
759ec28242 PCI/NPEM: Add _DSM PCIe SSD status LED management
The PCIe SSD Status LED Management _DSM defined in PCI Firmware Spec r3.3
sec 4.7 provides a way to manage LEDs via ACPI.

The design is similar to NPEM defined in PCIe Base Specification r6.1 sec
6.28:

  - Both standards are indication oriented,

  - _DSM supported bits correspond to NPEM capability register bits,

  - _DSM control bits correspond to NPEM control register bits.

_DSM does not support enclosure-specific indications or the special NPEM
commands NPEM_ENABLE and NPEM_RESET.

_DSM is implemented as a second backend in NPEM driver. The backend used is
logged with info priority. The same sysfs interface is used for both NPEM
and _DSM.

According to spec, _DSM has higher priority, and availability  of _DSM in
not limited to devices with NPEM support.

The Dell implementation of DSM uses acpi ipmi, which may not be available
immediately (in fact it may take up to 10s for this interface to be
available). It can determine if DSM is supported (GET_SUPPORTED_STATES_DSM
is working) but it cannot serve GET_STATE_DSM or SET_STATE_DSM commands in
this time.

From userspace application perspective (primarily configured by systemd
service) it is better to have not working but configured interface rather
than have it available after few seconds.

For that reason, npem->active_indications cache is now loaded lazily, i.e.
any GET or SET request want cache to be updated if it is not done yet.

Link: https://lore.kernel.org/r/20240904104848.23480-4-mariusz.tkaczyk@linux.intel.com
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-09-06 11:37:24 -05:00
Mariusz Tkaczyk
4e893545ef PCI/NPEM: Add Native PCIe Enclosure Management support
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 > ./leds/10000:02:05.0:enclosure:fail/brightness
  echo 0 > ./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 <lukas@wunner.de>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-09-04 17:25:12 -05:00
Mariusz Tkaczyk
78efa53e71 leds: Init leds class earlier
NPEM driver will require leds class, there is an init-order conflict.
Make sure that LEDs initialization happens first and add comment.

Link: https://lore.kernel.org/r/20240904104848.23480-2-mariusz.tkaczyk@linux.intel.com
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-09-04 17:24:58 -05:00
Matthew Gerlach
b08929e1ec
dt-bindings: PCI: altera: Convert to YAML
Convert the devicetree bindings for the Altera Root Port PCIe controller
from text to YAML.

While at it, update the entries in the interrupt-map field to have the
correct number of address cells for the interrupt parent.

Link: https://lore.kernel.org/linux-pci/20240702162652.1349121-1-matthew.gerlach@linux.intel.com
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
2024-09-04 15:22:38 +00:00
Rayyan Ansari
364cfd8a56
dt-bindings: PCI: qcom,pcie-sc7280: Update bindings adding eight interrupts
Previous commit to this bindings, commit 756485bfbb85 ("dt-bindings:
PCI: qcom,pcie-sc7280: Move SC7280 to dedicated schema"), updated the
bindings to specify one interrupt only, as the devicetree at that time
did not describe the hardware fully.

The devicetree for SC7280 now specifies eight interrupts, following the
commit b8ba66b40da3 ("arm64: dts: qcom: sc7280: Add additional MSI
interrupts").

Thus, update the bindings to reflect this.

Link: https://lore.kernel.org/linux-pci/20240722-sc7280-pcie-interrupts-v2-1-a5414d3dbc64@linaro.org
Signed-off-by: Rayyan Ansari <rayyan.ansari@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-09-04 15:10:48 +00:00
Frank Li
f66b63ef10
dt-bindings: PCI: layerscape-pci: Change property 'fsl,pcie-scfg' type
The fsl,pcie-scfg requires an argument when there are more than one PCIe
instances.

Thus, change it to the phandle-array type and use items to describe
what each field means.

This also fixes the following warning:

  arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dtb: pcie@3400000: fsl,pcie-scfg:0: [22, 0] is too long from schema $id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie.yaml#

Link: https://lore.kernel.org/linux-pci/20240701221612.2112668-1-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
2024-09-04 14:58:08 +00:00
Frank Li
b9fe09a1b2
dt-bindings: PCI: layerscape-pci: Add deprecated property 'num-viewport'
Copy the 'num-viewport' property from snps,dw-pcie-common.yaml to
fsl,layerscape-pcie.yaml to address the following warning:

  /arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dtb: pcie@3400000: Unevaluated properties are not allowed ('num-viewport' was unexpected)

This is necessary due to historical reasons where fsl,layerscape-pcie.yaml
does not directly reference snps,dw-pcie-common.yaml.

Link: https://lore.kernel.org/linux-pci/20240823185855.776904-1-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-04 14:46:20 +00:00
Frank Li
1a1bf58897
dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with fsl,lx2160ar2-pcie
The fsl,lx2160a-pcie compatible is used for mobivel according to the
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt file.

Whereas the fsl,layerscape-pcie is used for DesignWare PCIe controller binding.

So change it to fsl,lx2160ar2-pcie and allow a fall back to fsl,ls2088a-pcie.

While at it, sort compatible string.

Fixes: 24cd7ecb3886 ("dt-bindings: PCI: layerscape-pci: Convert to YAML format")
Link: https://lore.kernel.org/linux-pci/20240826-2160r2-v1-1-106340d538d6@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-04 14:39:58 +00:00
Krzysztof Kozlowski
a5c1bf7e9a
dt-bindings: PCI: socionext,uniphier-pcie-ep: Add top-level constraints
Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clock-names and reset-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-04 14:32:34 +00:00
Krzysztof Kozlowski
c62a0b8fe8
dt-bindings: PCI: renesas,pci-rcar-gen2: Add top-level constraints
Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clocks and clock-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-04 14:32:02 +00:00
Krzysztof Kozlowski
ac44be2155
dt-bindings: PCI: hisilicon,kirin-pcie: Add top-level constraints
Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clock-names and reset-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-04 14:31:10 +00:00
Jinjie Ruan
3ee1a6b5d7
PCI/AER: Use PCI_DEVID() macro in aer_inject()
The PCI_DEVID() macro can be used instead of open-coding it.

No functional changes intended.

Link: https://lore.kernel.org/linux-pci/20240829022435.4145181-1-ruanjinjie@huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2024-09-01 17:05:45 +00:00
WangYuli
9246b487ab PCI: Add function 0 DMA alias quirk for Glenfly Arise chip
Add DMA support for audio function of Glenfly Arise chip, which uses
Requester ID of function 0.

Link: https://lore.kernel.org/r/CA2BBD087345B6D1+20240823095708.3237375-1-wangyuli@uniontech.com
Signed-off-by: SiyuLi <siyuli@glenfly.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
[bhelgaas: lower-case hex to match local code, drop unused Device IDs]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
2024-08-23 13:01:20 -05:00
Konrad Dybcio
0da59840f1 PCI/pwrctl: Add WCN6855 support
Add support for ATH11K inside the WCN6855 package to the power sequencing
PCI power control driver.

Link: https://lore.kernel.org/r/20240813191201.155123-1-brgl@bgdev.pl
[Bartosz: split Konrad's bigger patch, write the commit message]
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Konrad Dybcio <konradybcio@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Dybcio <konradybcio@kernel.org>
2024-08-22 14:03:41 -05:00
Ilpo Järvinen
3e40aa29d4 PCI: Wait for Link before restoring Downstream Buses
__pci_reset_bus() calls pci_bridge_secondary_bus_reset() to perform the
reset and also waits for the Secondary Bus to become again accessible.
__pci_reset_bus() then calls pci_bus_restore_locked() that restores the PCI
devices connected to the bus, and if necessary, recursively restores also
the subordinate buses and their devices.

The logic in pci_bus_restore_locked() does not take into account that after
restoring a device on one level, there might be another Link Downstream
that can only start to come up after restore has been performed for its
Downstream Port device. That is, the Link may require additional wait until
it becomes accessible.

Similarly, pci_slot_restore_locked() lacks wait.

Amend pci_bus_restore_locked() and pci_slot_restore_locked() to wait for
the Secondary Bus before recursively performing the restore of that bus.

Fixes: 090a3c5322e9 ("PCI: Add pci_reset_slot() and pci_reset_bus()")
Link: https://lore.kernel.org/r/20240808121708.2523-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-08-09 15:35:42 -05:00
Philipp Stanner
2eb20b96d7 drm/ast: Request PCI BAR with devres
ast currently ioremaps two PCI BARs using pcim_iomap(). It does not perform
a request on the regions, however, which would make the driver a bit more
robust.

PCI now offers pcim_iomap_region(), a managed function which both requests
and ioremaps a BAR.

Replace pcim_iomap() with pcim_iomap_region().

Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20240807083018.8734-4-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Dave Airlie <airlied@redhat.com>
2024-08-09 15:08:42 -05:00
Philipp Stanner
d140f80f60 PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()
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 <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-08-09 15:08:35 -05:00
Philipp Stanner
89121e5d08 drm/vboxvideo: Add PCI region request
vboxvideo currently does not reserve its PCI BAR through a region request.

Implement the request through the managed function pcim_request_region().

Link: https://lore.kernel.org/r/20240729093625.17561-5-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2024-08-09 15:08:26 -05:00
Philipp Stanner
7ff7509fa5 PCI: Make pcim_request_region() a public function
pcim_request_region() is the managed counterpart of pci_request_region().
It is currently only used internally for PCI.

It can be useful for a number of drivers and exporting it is a step towards
deprecating more complicated functions.

Make pcim_request_region() a public function.

Link: https://lore.kernel.org/r/20240729093625.17561-4-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2024-08-09 15:08:18 -05:00
Lukas Wunner
265baca69a s390/pci: Stop usurping pdev->dev.groups
Bjorn suggests using pdev->dev.groups for attribute_groups constructed on
PCI device enumeration:

  "Is it feasible to build an attribute group in pci_doe_init() and
   add it to dev->groups so device_add() will automatically add them?"
   https://lore.kernel.org/r/20231019165829.GA1381099@bhelgaas

Unfortunately on s390, pcibios_device_add() usurps pdev->dev.groups for
arch-specific attribute_groups, preventing its use for anything else.

Introduce an ARCH_PCI_DEV_GROUPS macro which arches can define in
<asm/pci.h>.  The macro is visible in drivers/pci/pci-sysfs.c through the
inclusion of <linux/pci.h>, which in turn includes <asm/pci.h>.

On s390, define the macro to the three attribute_groups previously assigned
to pdev->dev.groups.  Thereby pdev->dev.groups is made available for use by
the PCI core.

As a side effect, arch/s390/pci/pci_sysfs.c no longer needs to be compiled
into the kernel if CONFIG_SYSFS=n.

Link: https://lore.kernel.org/r/7b970f7923e373d1b23784721208f93418720485.1722870934.git.lukas@wunner.de
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
2024-08-09 14:58:27 -05:00
Frank Li
f73286f392 dt-bindings: PCI: host-generic-pci: Drop minItems and maxItems of ranges
The ranges description states that "at least one non-prefetchable memory
and one or both of prefetchable memory and IO space may also be provided."

However, it should not limit the maximum number of ranges to 3.

Freescale LS1028 and iMX95 use more than 3 ranges because the space splits
some discontinuous prefetchable and non-prefetchable segments.

Drop minItems and maxItems. The number of entries will be limited to 32
in pci-bus-common.yaml in dtschema, which should be sufficient.

Fixes this CHECK_DTBS warning:

  arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb: pcie@1f0000000: ranges: [[2181038080, 1, 4160749568, 1, 4160749568, 0, 1441792], [3254779904, 1, 4162191360, 1, 4162191360, 0, 458752], [2181038080, 1, 4162650112, 1, 4162650112, 0, 131072], [3254779904, 1, 4162781184, 1, 4162781184, 0, 131072], [2181038080, 1, 4162912256, 1, 4162912256, 0, 131072], [3254779904, 1, 4163043328, 1, 4163043328, 0, 131072], [2181038080, 1, 4227858432, 1, 4227858432, 0, 4194304]] is too long

Link: https://lore.kernel.org/r/20240704164019.611454-1-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-08-09 14:03:02 -05:00
weiyufeng
87d5403378 PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
Use PCI_POSSIBLE_ERROR() to check the response we get when we read data
from hardware.  This unifies PCI error response checking and makes error
checks consistent and easier to find.

Link: https://lore.kernel.org/r/20240806065050.28725-1-412574090@163.com
Signed-off-by: weiyufeng <weiyufeng@kylinos.cn>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-08-06 14:16:57 -05:00
ngn
5d8491ae3b PCI: shpchp: Remove hpc_ops
Remove the hpc_ops struct from shpchp. This struct is unnecessary and no
other hotplug controller implements it. A similar thing has already been
done in pciehp with 82a9e79ef132 ("PCI: pciehp: remove hpc_ops").

Link: https://lore.kernel.org/r/Zp-XXVW4hlcMASEc@archbtw
Signed-off-by: ngn <ngn@ngn.tf>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-08-02 11:39:59 -05:00
Linus Torvalds
8400291e28 Linux 6.11-rc1 v6.11-rc1 2024-07-28 14:19:55 -07:00
Linus Torvalds
a0c04bd55a Kbuild fixes for v6.11
- Fix RPM package build error caused by an incorrect locale setup
 
  - Mark modules.weakdep as ghost in RPM package
 
  - Fix the odd combination of -S and -c in stack protector scripts, which
    is an error with the latest Clang
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAmamlN8VHG1hc2FoaXJv
 eUBrZXJuZWwub3JnAAoJED2LAQed4NsG828P/R3MRpmWBhMrw/JmvpJ3hyby6sZA
 VcwOMLmmiIFdmVK5NKqWRkOBfD2JlRrbuuCrJKGJIX1lo4h/TifQf+gu8s8bN38h
 ZLo7KMzn4kCX91jSwhnOBczw2jEnKbrQrMoktTl7k9GC+pnebf9pzdxXzXWIf5Rs
 Z91XuueFrOZ/lDOVjv/675MPrp9M4tM2aZPo3RaKbbPFAaSPDihSa3iKyRDqPd6K
 1rzqgt3+fvkVVO8HZjm12XBg5AoL2bYvaJtF12zZkFEhJRRmXmGQxTVbZSh/PP+z
 D+BCFUTAt0gr8rQSLTtW2PStjvZc0nEG6Mpnz/OiQCEcMycLgEq+YkD9TbQISX8q
 FiQMVPe9YV7AWSYZd5RgMHxgeB2RDd6e6Z4yKATeatJ46UpoV6Kg1JczBJTs1b5X
 bb9Q+nZniioyzc3ys5UQchTu01bzv17GsWya6ipZWf8Lf+yvMipoADuV6MOs6YUh
 TEFjoA/cGiGQQ5uLHDZ69n8dJ+FRZfMvW4dQIGE2kf92e0lQKrKwa1WXQ78+rPMn
 j8wVYB8kiqgDW+ObxTJgr0NakbqMEBQsGxwv0W4TRjD9fN4kXcWqN/bKq2IfTwxk
 mSi/ASo900XHLCGKtBH6vNoi6bkJXC7YoSBEIulpYaxCf5S0VPHZ5iFrQpdhqKSZ
 qNfFHDoZFyTdPGZk
 =HYew
 -----END PGP SIGNATURE-----

Merge tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Fix RPM package build error caused by an incorrect locale setup

 - Mark modules.weakdep as ghost in RPM package

 - Fix the odd combination of -S and -c in stack protector scripts,
   which is an error with the latest Clang

* tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kbuild: Fix '-S -c' in x86 stack protector scripts
  kbuild: rpm-pkg: ghost modules.weakdep file
  kbuild: rpm-pkg: Fix C locale setup
2024-07-28 14:02:48 -07:00
Linus Torvalds
017fa3e891 minmax: simplify and clarify min_t()/max_t() implementation
This simplifies the min_t() and max_t() macros by no longer making them
work in the context of a C constant expression.

That means that you can no longer use them for static initializers or
for array sizes in type definitions, but there were only a couple of
such uses, and all of them were converted (famous last words) to use
MIN_T/MAX_T instead.

Cc: David Laight <David.Laight@aculab.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-07-28 13:50:01 -07:00
Linus Torvalds
4477b39c32 minmax: add a few more MIN_T/MAX_T users
Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant
expressions in VM code") added the simpler MIN_T/MAX_T macros in order
to avoid some excessive expansion from the rather complicated regular
min/max macros.

The complexity of those macros stems from two issues:

 (a) trying to use them in situations that require a C constant
     expression (in static initializers and for array sizes)

 (b) the type sanity checking

and MIN_T/MAX_T avoids both of these issues.

Now, in the whole (long) discussion about all this, it was pointed out
that the whole type sanity checking is entirely unnecessary for
min_t/max_t which get a fixed type that the comparison is done in.

But that still leaves min_t/max_t unnecessarily complicated due to
worries about the C constant expression case.

However, it turns out that there really aren't very many cases that use
min_t/max_t for this, and we can just force-convert those.

This does exactly that.

Which in turn will then allow for much simpler implementations of
min_t()/max_t().  All the usual "macros in all upper case will evaluate
the arguments multiple times" rules apply.

We should do all the same things for the regular min/max() vs MIN/MAX()
cases, but that has the added complexity of various drivers defining
their own local versions of MIN/MAX, so that needs another level of
fixes first.

Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/
Cc: David Laight <David.Laight@aculab.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-07-28 13:41:14 -07:00
Linus Torvalds
7e2d0ba732 This pull request contains updates (actually, just fixes) for UBI and UBIFS:
- Many fixes for power-cut issues by Zhihao Cheng
 - Another ubiblock error path fix
 - ubiblock section mismatch fix
 - Misc fixes all over the place
 -----BEGIN PGP SIGNATURE-----
 
 iQJKBAABCAA0FiEEdgfidid8lnn52cLTZvlZhesYu8EFAmamiikWHHJpY2hhcmRA
 c2lnbWEtc3Rhci5hdAAKCRBm+VmF6xi7wTy6EACEj6VcTRei5Ndt2QXNiKHNgJ3j
 yV0QmLWUF5brfXbUsoP9oeKL/Y9s+02maDUkOJoHGcHRClLyHkIMMHXYy5gpXyiI
 h4zTcx3x33+oddYJeqdZYDDpWwk8RsqE1UjB8i7q+DF7vznWqYl3/+G7coH8ZD8M
 +//3AzWjD/U9Gj3KVuyBgok0OmnwFJ36w3Ckoj7NKxbFQrCmxa7qtLqseuiHumhu
 HjAMPS1V+Hmw6qw/s+hs6NdBhOvmO56s1wwT26mji+kQVMuh6tG3YNo2tyM7AHSv
 cGJDVGuDmO3F6iKqom3edjxHetWmCN3gvCkacpE6G/9Q1x3XO7vWhPfl6JHv+KTu
 zsc0WDhmNKkxUIHgBKvFGCylo6Ui4rIn5iFihXBiGTjB52tBqPU+0STDfcKcqz6U
 BrgCiKdAuX7tZT00tuFJE9eWbZvPVWQii0aNw5uLi9GwXOFmLP/VAi+FDQ0hsNSF
 XQxgWAd9b7eLmyWUrn6ORj2+FIzjmF6oxBfUOHgE4J1GPggIDXii9NDJcma3XSTn
 OcqpCJe5SOc38M7ldwbZup53fl+DFvsbnbDofrGCvhSTCqAyGx5su3m40YsIVRvI
 fpCk6L/6vGp/ONw90Vq/KKeIkAJaHnqi6KbnfyDtF6LSwW7cb4+Cw69BWvpP0gQb
 m1hTm4vIaPvD25840g==
 =0y6/
 -----END PGP SIGNATURE-----

Merge tag 'ubifs-for-linus-6.11-rc1-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs

Pull UBI and UBIFS updates from Richard Weinberger:

 - Many fixes for power-cut issues by Zhihao Cheng

 - Another ubiblock error path fix

 - ubiblock section mismatch fix

 - Misc fixes all over the place

* tag 'ubifs-for-linus-6.11-rc1-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
  ubi: Fix ubi_init() ubiblock_exit() section mismatch
  ubifs: add check for crypto_shash_tfm_digest
  ubifs: Fix inconsistent inode size when powercut happens during appendant writing
  ubi: block: fix null-pointer-dereference in ubiblock_create()
  ubifs: fix kernel-doc warnings
  ubifs: correct UBIFS_DFS_DIR_LEN macro definition and improve code clarity
  mtd: ubi: Restore missing cleanup on ubi_init() failure path
  ubifs: dbg_orphan_check: Fix missed key type checking
  ubifs: Fix unattached inode when powercut happens in creating
  ubifs: Fix space leak when powercut happens in linking tmpfile
  ubifs: Move ui->data initialization after initializing security
  ubifs: Fix adding orphan entry twice for the same inode
  ubifs: Remove insert_dead_orphan from replaying orphan process
  Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"
  ubifs: Don't add xattr inode into orphan area
  ubifs: Fix unattached xattr inode if powercut happens after deleting
  mtd: ubi: avoid expensive do_div() on 32-bit machines
  mtd: ubi: make ubi_class constant
  ubi: eba: properly rollback inside self_check_eba
2024-07-28 11:51:51 -07:00
Nathan Chancellor
3415b10a03 kbuild: Fix '-S -c' in x86 stack protector scripts
After a recent change in clang to stop consuming all instances of '-S'
and '-c' [1], the stack protector scripts break due to the kernel's use
of -Werror=unused-command-line-argument to catch cases where flags are
not being properly consumed by the compiler driver:

  $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
  clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]

This results in CONFIG_STACKPROTECTOR getting disabled because
CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.

'-c' and '-S' both instruct the compiler to stop at different stages of
the pipeline ('-S' after compiling, '-c' after assembling), so having
them present together in the same command makes little sense. In this
case, the test wants to stop before assembling because it is looking at
the textual assembly output of the compiler for either '%fs' or '%gs',
so remove '-c' from the list of arguments to resolve the error.

All versions of GCC continue to work after this change, along with
versions of clang that do or do not contain the change mentioned above.

Cc: stable@vger.kernel.org
Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
Link: 6461e53781 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-29 03:47:00 +09:00