From: kernel test robot <lkp@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: oe-kbuild-all@lists.linux.dev, Leon Romanovsky <leon@kernel.org>
Subject: [leon-rdma:rdma-next 90/112] drivers/iommu/iommu.c:1619:12: warning: assignment to 'struct pci_dev *' from 'int' makes pointer from integer without a cast
Date: Sat, 26 Jul 2025 06:44:52 +0200 [thread overview]
Message-ID: <202507260636.eeHS4uo9-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next
head: aea452cc27ca9e5169f7279d7b524190c39e7260
commit: b6ad3735a7afc29ce93ff75fbd98aac2466749be [90/112] iommu: Compute iommu_groups properly for PCIe switches
config: arm-randconfig-2002-20250720 (https://download.01.org/0day-ci/archive/20250726/202507260636.eeHS4uo9-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250726/202507260636.eeHS4uo9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507260636.eeHS4uo9-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/iommu/iommu.c:24:
include/linux/pci.h:2066:24: warning: no previous prototype for 'pci_bus_isolated' [-Wmissing-prototypes]
enum pci_bus_isolation pci_bus_isolated(struct pci_bus *bus)
^~~~~~~~~~~~~~~~
include/linux/pci.h: In function 'pci_bus_isolated':
include/linux/pci.h:2067:10: error: 'PCI_NON_ISOLATED' undeclared (first use in this function); did you mean 'PCIE_NON_ISOLATED'?
{ return PCI_NON_ISOLATED; }
^~~~~~~~~~~~~~~~
PCIE_NON_ISOLATED
include/linux/pci.h:2067:10: note: each undeclared identifier is reported only once for each function it appears in
drivers/iommu/iommu.c: In function 'pci_device_group':
drivers/iommu/iommu.c:1619:14: error: implicit declaration of function 'pci_real_dma_dev'; did you mean 'pci_alloc_dev'? [-Werror=implicit-function-declaration]
real_pdev = pci_real_dma_dev(pdev);
^~~~~~~~~~~~~~~~
pci_alloc_dev
>> drivers/iommu/iommu.c:1619:12: warning: assignment to 'struct pci_dev *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
real_pdev = pci_real_dma_dev(pdev);
^
In file included from drivers/iommu/iommu.c:24:
include/linux/pci.h: In function 'pci_bus_isolated':
include/linux/pci.h:2067:1: warning: control reaches end of non-void function [-Wreturn-type]
{ return PCI_NON_ISOLATED; }
^
cc1: some warnings being treated as errors
vim +1619 drivers/iommu/iommu.c
1575
1576 /*
1577 * For legacy PCI we have two main considerations when forming groups:
1578 *
1579 * 1) In PCI we can loose the RID inside the fabric, or some devices will use
1580 * the wrong RID. The PCI core calls this aliasing, but from an IOMMU
1581 * perspective it means that a PCI device may have multiple RIDs and a
1582 * single RID may represent many PCI devices. This effectively means all the
1583 * aliases must share a translation, thus group, because the IOMMU cannot
1584 * tell devices apart.
1585 *
1586 * 2) PCI permits a bus segment to claim an address even if the transaction
1587 * originates from an end point not the CPU. When it happens it is called
1588 * peer to peer. Claiming a transaction in the middle of the bus hierarchy
1589 * bypasses the IOMMU translation. The IOMMU subsystem rules require these
1590 * devices to be placed in the same group because they lack isolation from
1591 * each other. In PCI Express the ACS system can be used to inhibit this and
1592 * force transactions to go to the IOMMU.
1593 *
1594 * From a PCI perspective any given PCI bus is either isolating or
1595 * non-isolating. Isolating means downstream originated transactions always
1596 * progress toward the CPU and do not go to other devices on the bus
1597 * segment, while non-isolating means downstream originated transactions can
1598 * progress back downstream through another device on the bus segment.
1599 *
1600 * Beyond buses a multi-function device or bridge can also allow
1601 * transactions to loop back internally from one function to another.
1602 *
1603 * Once a PCI bus becomes non isolating the entire downstream hierarchy of
1604 * that bus becomes a single group.
1605 */
1606 struct iommu_group *pci_device_group(struct device *dev)
1607 {
1608 struct pci_dev *pdev = to_pci_dev(dev);
1609 struct iommu_group *group;
1610 struct pci_dev *real_pdev;
1611
1612 if (WARN_ON(!dev_is_pci(dev)))
1613 return ERR_PTR(-EINVAL);
1614
1615 /*
1616 * Arches can supply a completely different PCI device that actually
1617 * does DMA.
1618 */
> 1619 real_pdev = pci_real_dma_dev(pdev);
1620 if (real_pdev != pdev) {
1621 group = iommu_group_get(&real_pdev->dev);
1622 if (!group) {
1623 /*
1624 * The real_pdev has not had an iommu probed to it. We
1625 * can't create a new group here because there is no way
1626 * for pci_device_group(real_pdev) to pick it up.
1627 */
1628 dev_err(dev,
1629 "PCI device is probing out of order, real device of %s is not probed yet\n",
1630 pci_name(real_pdev));
1631 return ERR_PTR(-EPROBE_DEFER);
1632 }
1633 return group;
1634 }
1635
1636 if (pdev->dev_flags & PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT)
1637 return iommu_group_alloc();
1638
1639 /* Anything upstream of this enforcing non-isolated? */
1640 group = pci_hierarchy_group(pdev);
1641 if (group)
1642 return group;
1643
1644 switch (pci_bus_isolated(pdev->bus)) {
1645 case PCIE_ISOLATED:
1646 /* Check multi-function groups and same-bus devfn aliases */
1647 group = pci_get_alias_group(pdev);
1648 if (group)
1649 return group;
1650
1651 /* No shared group found, allocate new */
1652 return iommu_group_alloc();
1653
1654 /*
1655 * On legacy PCI there is no RID at an electrical level. On PCI-X the
1656 * RID of the bridge may be used in some cases instead of the
1657 * downstream's RID. This creates aliasing problems. PCI/PCI-X doesn't
1658 * provide isolation either. The end result is that as soon as we hit a
1659 * PCI/PCI-X bus we switch to non-isolated for the whole downstream for
1660 * both aliasing and isolation reasons. The bridge has to be included in
1661 * the group because of the aliasing.
1662 */
1663 case PCI_BRIDGE_NON_ISOLATED:
1664 /* A PCIe switch where the USP has MMIO and is not isolated. */
1665 case PCIE_NON_ISOLATED:
1666 group = iommu_group_get(&pdev->bus->self->dev);
1667 if (WARN_ON(!group))
1668 return ERR_PTR(-EINVAL);
1669 /*
1670 * No need to be concerned with aliases here since we are going
1671 * to put the entire downstream tree in the bridge/USP's group.
1672 */
1673 group->bus_data |= BUS_DATA_PCI_UNISOLATED;
1674 return group;
1675
1676 /*
1677 * It is a PCI bus and the upstream bridge/port does not alias or allow
1678 * P2P.
1679 */
1680 case PCI_BUS_NON_ISOLATED:
1681 /*
1682 * It is a PCIe switch and the DSP cannot reach the USP. The DSP's
1683 * are not isolated from each other and share a group.
1684 */
1685 case PCIE_SWITCH_DSP_NON_ISOLATED: {
1686 struct pci_dev *piter = NULL;
1687
1688 /*
1689 * All the downstream devices on the bus share a group. If this
1690 * is a PCIe switch then they will all be DSPs
1691 */
1692 for_each_pci_dev(piter) {
1693 if (piter->bus != pdev->bus)
1694 continue;
1695 group = iommu_group_get(&piter->dev);
1696 if (group) {
1697 pci_dev_put(piter);
1698 if (WARN_ON(!(group->bus_data &
1699 BUS_DATA_PCI_UNISOLATED)))
1700 group->bus_data |=
1701 BUS_DATA_PCI_UNISOLATED;
1702 return group;
1703 }
1704 }
1705
1706 group = iommu_group_alloc();
1707 group->bus_data |= BUS_DATA_PCI_UNISOLATED;
1708 return group;
1709 }
1710 default:
1711 break;
1712 }
1713 WARN_ON(true);
1714 return ERR_PTR(-EINVAL);
1715 }
1716 EXPORT_SYMBOL_GPL(pci_device_group);
1717
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2025-07-26 4:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202507260636.eeHS4uo9-lkp@intel.com \
--to=lkp@intel.com \
--cc=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
/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.