- 11 2月, 2021 2 次提交
-
-
由 Daniel Vetter 提交于
Since 3234ac66 ("/dev/mem: Revoke mappings when a driver claims the region") /dev/kmem zaps PTEs when the kernel requests exclusive acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is the default for all driver uses. Except there are two more ways to access PCI BARs: sysfs and proc mmap support. Let's plug that hole. For revoke_devmem() to work we need to link our vma into the same address_space, with consistent vma->vm_pgoff. ->pgoff is already adjusted, because that's how (io_)remap_pfn_range works, but for the mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is to adjust this at at ->open time: - for sysfs this is easy, now that binary attributes support this. We just set bin_attr->mapping when mmap is supported - for procfs it's a bit more tricky, since procfs PCI access has only one file per device, and access to a specific resource first needs to be set up with some ioctl calls. But mmap is only supported for the same resources as sysfs exposes with mmap support, and otherwise rejected, so we can set the mapping unconditionally at open time without harm. A special consideration is for arch_can_pci_mmap_io() - we need to make sure that the ->f_mapping doesn't alias between ioport and iomem space. There are only 2 ways in-tree to support mmap of ioports: generic PCI mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single architecture hand-rolling. Both approaches support ioport mmap through a special PFN range and not through magic PTE attributes. Aliasing is therefore not a problem. The only difference in access checks left is that sysfs PCI mmap does not check for CAP_RAWIO. I'm not really sure whether that should be added or not. Acked-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Kees Cook <keescook@chromium.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210204165831.2703772-3-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
We are already doing this for all the regular sysfs files on PCI devices, but not yet on the legacy io files on the PCI buses. Thus far no problem, but in the next patch I want to wire up iomem revoke support. That needs the vfs up and running already to make sure that iomem_get_mapping() works. Wire it up exactly like the existing code in pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files() doesn't need a check since the one for pci_bus->legacy_io is sufficient. An alternative solution would be to implement a callback in sysfs to set up the address space from iomem_get_mapping() when userspace calls mmap(). This also works, but Greg didn't really like that just to work around an ordering issue when the kernel loads initially. v2: Improve commit message (Bjorn) Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Kees Cook <keescook@chromium.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210205133632.2827730-1-daniel.vetter@ffwll.ch
-
- 05 12月, 2020 1 次提交
-
-
由 Maximilian Luz 提交于
While PCI power states D0-D3hot can be queried from user-space via lspci, D3cold cannot. lspci cannot provide an accurate value when the device is in D3cold as it has to restore the device to D0 before it can access its power state via the configuration space, leading to it reporting D0 or another on-state. Thus lspci cannot be used to diagnose power consumption issues for devices that can enter D3cold or to ensure that devices properly enter D3cold at all. Add a new sysfs device attribute for the PCI power state, showing the current power state as seen by the kernel. [bhelgaas: drop READ_ONCE(), see discussion at the link] Link: https://lore.kernel.org/r/20201102141520.831630-1-luzmaximilian@gmail.comSigned-off-by: NMaximilian Luz <luzmaximilian@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 9月, 2020 2 次提交
-
-
由 Clint Sbisa 提交于
f7195824 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") changed the #ifdef condition around pci_create_resource_files(), pci_remove_resource_files(), and related functions, but did not update comments at the #else and #ifdef. Update the comments to match the #ifdef. [bhelgaas: commit log, drop #endif comment since it's close to the #else] Link: https://lore.kernel.org/r/20200821155121.nzxjeeoze4h5pone@amazon.comSigned-off-by: NClint Sbisa <csbisa@amazon.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Jiang Biao 提交于
The PCI sysfs "config" file allows large reads, and the resulting PCI config reads can take several milliseconds to complete. Testing with the cyclictest [1] benchmark showed 5ms+ latencies. Add a schedule point in pci_read_config() to reduce the maximum latency. [1] https://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20200824052025.48362-1-benbjiang@tencent.comReported-by: NBin Lai <robinlai@tencent.com> Signed-off-by: NJiang Biao <benbjiang@tencent.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 02 9月, 2020 1 次提交
-
-
由 Krzysztof Wilczyński 提交于
Sysfs "show" methods should return the number of bytes printed into the buffer. This is the return value of scnprintf() [1]. snprintf(buf, size, ...) prints at most "size" bytes into "buf", but returns the number of bytes that *would* be printed if "buf" were large enough. Replace use of snprintf() with scnprintf(). No functional change intended. Related: https://patchwork.kernel.org/patch/9946759/#20969333 https://lwn.net/Articles/69419 [1] Documentation/filesystems/sysfs.rst [bhelgaas: squashed, commit log] Suggested-by: NBjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20200824233918.26306-2-kw@linux.com Link: https://lore.kernel.org/r/20200824233918.26306-3-kw@linux.com Link: https://lore.kernel.org/r/20200824233918.26306-4-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 30 3月, 2020 1 次提交
-
-
由 Kelsey Skunberg 提交于
We changed these sysfs filenames: .../pci_bus/<domain:bus>/rescan -> .../pci_bus/<domain:bus>/bus_rescan .../<domain:bus:dev.fn>/rescan -> .../<domain:bus:dev.fn>/dev_rescan and Ruslan reported [1] that this broke a userspace application. Revert these name changes so both files are named "rescan" again. Note that we have to use __ATTR() to assign custom C symbols, i.e., "struct device_attribute <symbol>". [1] https://lore.kernel.org/r/CAB=otbSYozS-ZfxB0nCiNnxcbqxwrHOSYxJJtDKa63KzXbXgpw@mail.gmail.com [bhelgaas: commit log, use __ATTR() both places so we don't have to rename the attributes] Fixes: 8bdfa145 ("PCI: sysfs: Define device attributes with DEVICE_ATTR*()") Fixes: 4e2b7943 ("PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()") Link: https://lore.kernel.org/r/20200325151708.32612-1-skunberg.kelsey@gmail.comSigned-off-by: NKelsey Skunberg <kelsey.skunberg@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org # v5.4+
-
- 11 3月, 2020 1 次提交
-
-
由 Bjorn Helgaas 提交于
Previously some PCI speed strings came from pci_speed_string(), some came from the PCIe-specific PCIE_SPEED2STR(), and some came from a PCIe-specific switch statement. These methods were inconsistent: pci_speed_string() PCIE_SPEED2STR() switch ------------------ ---------------- ------ 33 MHz PCI ... 2.5 GT/s PCIe 2.5 GT/s 2.5 GT/s 5.0 GT/s PCIe 5 GT/s 5 GT/s 8.0 GT/s PCIe 8 GT/s 8 GT/s 16.0 GT/s PCIe 16 GT/s 16 GT/s 32.0 GT/s PCIe 32 GT/s 32 GT/s Standardize on pci_speed_string() as the single source of these strings. Note that this adds ".0" and "PCIe" to some messages, including sysfs "max_link_speed" files, a brcmstb "link up" message, and the link status dmesg logging, e.g., nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) I think it's better to standardize on a single version of the speed text. Previously we had strings like this: /sys/bus/pci/slots/0/cur_bus_speed: 8.0 GT/s PCIe /sys/bus/pci/slots/0/max_bus_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8 GT/s /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8 GT/s This changes the latter two to match the slots files: /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8.0 GT/s PCIe Based-on-patch by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 11月, 2019 2 次提交
-
-
由 Heiner Kallweit 提交于
Previously, CONFIG_PCIEASPM_DEBUG enabled "link_state" and "clk_ctl" sysfs files that controlled ASPM. We believe these files were rarely if ever used. We recently added sysfs ASPM controls that are always present, so the debug code is no longer needed. Removing this debug code has been discussed for quite some time, see e.g. [0]. Remove PCIEASPM_DEBUG and the related code. [0] https://lore.kernel.org/lkml/20180727202619.GD173328@bhelgaas-glaptop.roam.corp.google.com/ Link: https://lore.kernel.org/r/ec935d8e-c084-3938-f1d1-748617596b25@gmail.comSigned-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Heiner Kallweit 提交于
Add sysfs attributes to Endpoints and other Upstream Ports to control ASPM, Clock PM, and L1 PM Substates. The new attributes are: /sys/devices/pci*/.../link/clkpm /sys/devices/pci*/.../link/l0s_aspm /sys/devices/pci*/.../link/l1_aspm /sys/devices/pci*/.../link/l1_1_aspm /sys/devices/pci*/.../link/l1_2_aspm /sys/devices/pci*/.../link/l1_1_pcipm /sys/devices/pci*/.../link/l1_2_pcipm An attribute is only visible if both ends of the Link leading to the device support the state. Writing y/1/on to the file enables the state; n/0/off disables it. These attributes can be used to tune the power/performance tradeoff for individual devices. [bhelgaas: commit log, rename directory to "link"] Link: https://lore.kernel.org/r/b1c83f8a-9bf6-eac5-82d0-cf5b90128fbf@gmail.comSigned-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 21 11月, 2019 1 次提交
-
-
由 Ben Dooks 提交于
56c1af46 ("PCI: Add sysfs max_link_speed/width, current_link_speed/width, etc") added the following objects, but they are unused, so remove them: pci_bridge_group pci_bridge_groups pcie_dev_group pcie_dev_groups This fixes the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning: symbol 'pci_bridge_groups' was not declared. Should it be static? drivers/pci/pci-sysfs.c:1555:30: warning: symbol 'pcie_dev_groups' was not declared. Should it be static? Link: https://lore.kernel.org/r/20191016080324.12864-1-ben.dooks@codethink.co.ukSigned-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 14 10月, 2019 1 次提交
-
-
由 Denis Efremov 提交于
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.comSigned-off-by: NDenis Efremov <efremov@linux.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
-
- 21 8月, 2019 4 次提交
-
-
由 Kelsey Skunberg 提交于
The sysfs SR-IOV functions are only needed when the kernel is built with SR-IOV support. Rather than put them in pci-sysfs.c under #ifdef CONFIG_PCI_IOV, move them to iov.c, which is only compiled when CONFIG_PCI_IOV=y. Link: https://lore.kernel.org/r/20190813204513.4790-4-skunberg.kelsey@gmail.comSigned-off-by: NKelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NDonald Dutile <ddutile@redhat.com> Reviewed-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
-
由 Kelsey Skunberg 提交于
We prefer octal permissions over symbolic permissions such as "(S_IWUSR | S_IWGRP)". Change all symbolic permissions to octal permissions, e.g., - (S_IWUSR | S_IWGRP) + 0220 Link: https://lore.kernel.org/r/20190813204513.4790-3-skunberg.kelsey@gmail.comSigned-off-by: NKelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NDonald Dutile <ddutile@redhat.com>
-
由 Kelsey Skunberg 提交于
DEVICE_ATTR() should only be used when files have unusual permissions. Change DEVICE_ATTR() with '0220' write-only permissions to DEVICE_ATTR_WO(), e.g., - static DEVICE_ATTR(_name, (S_IWUSR | S_IWGRP), NULL, _store); + static DEVICE_ATTR_WO(_name); Since _store is no longer passed, make the _name passed by DEVICE_ATTR_WO() and the related _name##_store() name match with each other, e.g., DEVICE_ATTR_WO(bus_rescan) must be able to call bus_rescan_store() Link: https://lore.kernel.org/r/20190815153352.86143-4-skunberg.kelsey@gmail.comSigned-off-by: NKelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NDonald Dutile <ddutile@redhat.com>
-
由 Kelsey Skunberg 提交于
Device attributes should be defined using DEVICE_ATTR*(_name, _mode, _show, _store). Convert them all from __ATTR*() to DEVICE_ATTR*(), e.g., - struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store) + static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo) Link: https://lore.kernel.org/r/20190813204513.4790-2-skunberg.kelsey@gmail.comSigned-off-by: NKelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NDonald Dutile <ddutile@redhat.com>
-
- 20 8月, 2019 1 次提交
-
-
由 Matthew Garrett 提交于
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NMatthew Garrett <mjg59@google.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKees Cook <keescook@chromium.org> cc: linux-pci@vger.kernel.org Signed-off-by: NJames Morris <jmorris@namei.org>
-
- 21 6月, 2019 1 次提交
-
-
由 Marek Vasut 提交于
With CONFIG_PROVE_LOCKING=y, using sysfs to remove a bridge with a device below it causes a lockdep warning, e.g., # echo 1 > /sys/class/pci_bus/0000:00/device/0000:00:00.0/remove ============================================ WARNING: possible recursive locking detected ... pci_bus 0000:01: busn_res: [bus 01] is released The remove recursively removes the subtree below the bridge. Each call uses a different lock so there's no deadlock, but the locks were all created with the same lockdep key so the lockdep checker can't tell them apart. Mark the "remove" sysfs attribute with __ATTR_IGNORE_LOCKDEP() as it is safe to ignore the lockdep check between different "remove" kernfs instances. There's discussion about a similar issue in USB at [1], which resulted in 356c05d5 ("sysfs: get rid of some lockdep false positives") and e9b526fe ("i2c: suppress lockdep warning on delete_device"), which do basically the same thing for USB "remove" and i2c "delete_device" files. [1] https://lore.kernel.org/r/Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org Link: https://lore.kernel.org/r/20190526225151.3865-1-marek.vasut@gmail.comSigned-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com> [bhelgaas: trim commit log, details at above links] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Tejun Heo <tj@kernel.org> Cc: Wolfram Sang <wsa@the-dreams.de>
-
- 14 6月, 2019 1 次提交
-
-
由 Gustavo Pimentel 提交于
PCIe r5.0, sec 7.5.3.18, defines a new 32.0 GT/s bit in the Supported Link Speeds Vector of Link Capabilities 2. Decode this new speed. This does not affect the speed of the link, which should be negotiated automatically by the hardware; it only adds decoding when showing the speed to the user. Previously, reading the speed of a link operating at this speed showed "Unknown speed" instead of "32.0 GT/s". Link: https://lore.kernel.org/lkml/92365e3caf0fc559f9ab14bcd053bfc92d4f661c.1559664969.git.gustavo.pimentel@synopsys.comSigned-off-by: NGustavo Pimentel <gustavo.pimentel@synopsys.com> [bhelgaas: changelog] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 09 5月, 2019 1 次提交
-
-
由 Bjorn Helgaas 提交于
Use dev_printk() when possible. This makes messages more consistent with other device-related messages and, in some cases, adds useful information. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 1月, 2019 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
We are trying to get rid of BUS_ATTR() and the usage of that in pci-sysfs.c can be trivially converted to use BUS_ATTR_WO(), so use that instead. Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 8月, 2018 1 次提交
-
-
由 Bjorn Helgaas 提交于
Several PCI core files include pci-aspm.h even though they don't need anything provided by that file. Remove the unnecessary includes of it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NSinan Kaya <okaya@kernel.org>
-
- 01 8月, 2018 1 次提交
-
-
由 Lukas Wunner 提交于
When performing a function reset via sysfs, the device's config space is accessed in places such as pcie_flr() and its MMIO space is accessed e.g. in reset_ivb_igd(), so ensure accessibility by resuming the device to D0. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Yinghai Lu <yinghai@kernel.org>
-
- 20 7月, 2018 1 次提交
-
-
由 Rajat Jain 提交于
Add sysfs attributes to provide total and breakdown of the AERs seen, into different type of correctable, fatal and nonfatal errors: /sys/bus/pci/devices/<dev>/aer_dev_correctable /sys/bus/pci/devices/<dev>/aer_dev_fatal /sys/bus/pci/devices/<dev>/aer_dev_nonfatal Signed-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 13 6月, 2018 1 次提交
-
-
由 Kees Cook 提交于
The kzalloc() function has a 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a * b, gfp) as well as handling cases of: kzalloc(a * b * c, gfp) with: kzalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kzalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kzalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kzalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kzalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kzalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(char) * COUNT + COUNT , ...) | kzalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kzalloc + kcalloc ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kzalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kzalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kzalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kzalloc(C1 * C2 * C3, ...) | kzalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kzalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kzalloc(sizeof(THING) * C2, ...) | kzalloc(sizeof(TYPE) * C2, ...) | kzalloc(C1 * C2 * C3, ...) | kzalloc(C1 * C2, ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - (E1) * E2 + E1, E2 , ...) | - kzalloc + kcalloc ( - (E1) * (E2) + E1, E2 , ...) | - kzalloc + kcalloc ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: NKees Cook <keescook@chromium.org>
-
- 26 5月, 2018 1 次提交
-
-
由 Christoph Hellwig 提交于
Manipulating the enable_cnt behind the back of the driver will wreak complete havoc with the kernel state, so disallow it. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de> Acked-by: NKeith Busch <keith.busch@intel.com>
-
- 31 3月, 2018 2 次提交
-
-
由 Tal Gilboa 提交于
Add pcie_get_width_cap() to find the max link width supported by a device. Change max_link_width_show() to use pcie_get_width_cap(). Signed-off-by: NTal Gilboa <talgi@mellanox.com> [bhelgaas: return width directly instead of error and *width, don't export outside drivers/pci] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
-
由 Tal Gilboa 提交于
Add pcie_get_speed_cap() to find the max link speed supported by a device. Change max_link_speed_show() to use pcie_get_speed_cap(). Signed-off-by: NTal Gilboa <talgi@mellanox.com> [bhelgaas: return speed directly instead of error and *speed, don't export outside drivers/pci] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
-
- 22 3月, 2018 1 次提交
-
-
由 Jay Fang 提交于
PCIe 4.0 defines the 16.0 GT/s link speed. Links can run at that speed without any Linux changes, but previously their sysfs "max_link_speed" and "current_link_speed" files contained "Unknown speed", not the expected "16.0 GT/s". Add decoding for the new 16 GT/s link speed. Signed-off-by: NJay Fang <f.fangjian@huawei.com> [bhelgaas: add PCI_EXP_LNKCAP2_SLS_16_0GB] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NDongdong Liu <liudongdong3@huawei.com>
-
- 20 3月, 2018 2 次提交
-
-
由 Bjorn Helgaas 提交于
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Move the VPD-related sysfs code from pci-sysfs.c to vpd.c. This follows the pattern of pcie_aspm_create_sysfs_dev_files(). The goal is to encapsulate all the VPD code and structures in vpd.c. No functional change intended. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 17 2月, 2018 1 次提交
-
-
由 Bjorn Helgaas 提交于
Previously we called pci_probe_reset_function() in this path: pci_sysfs_init # late_initcall for_each_pci_dev(dev) pci_create_sysfs_dev_files(dev) pci_create_capabilities_sysfs(dev) pci_probe_reset_function pci_dev_specific_reset pcie_has_flr pcie_capability_read_dword pci_sysfs_init() is a late_initcall, and a driver may have already claimed one of these devices and enabled runtime power management for it, so the device could already be in D3 by the time we get to pci_sysfs_init(). The device itself should respond to the config read even while it's in D3hot, but if an upstream bridge is also in D3hot, the read won't even reach the device because the bridge won't forward it downstream to the device. If the bridge is a PCIe port, it should complete the read as an Unsupported Request, which may be reported to the CPU as an exception or as invalid data. Avoid this case by probing for reset support from pci_init_capabilities(), before a driver can claim the device. The device may be in D3hot, but any bridges leading to it should be in D0, so the device's config space should be fully accessible at that point. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 1月, 2018 1 次提交
-
-
由 Stuart Hayes 提交于
Some multifunction PCI devices with more than 8 functions use "alternative routing-ID interpretation" (ARI), which means the 8-bit device/function number field will be interpreted as 8 bits specifying the function number (the device number is 0 implicitly), rather than the upper 5 bits specifying the device number and the lower 3 bits specifying the function number. The kernel can enable and use this. Expose in a sysfs attribute whether the kernel has enabled ARI, so that a program in userspace won't have to parse PCI devices and PCI configuration space to figure out if it is enabled. This will allow better predictable network naming using PCI function numbers without using PCI bus or device numbers, which is desirable because bus and device numbers can change with system configuration but function numbers will not. Signed-off-by: NStuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 19 1月, 2018 1 次提交
-
-
由 Frederick Lawler 提交于
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by: NFrederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 19 12月, 2017 1 次提交
-
-
由 Bjorn Helgaas 提交于
When a process uses sysfs and tries to mmap more space than is available in a PCI BAR, we emit a warning and a backtrace. The mmap fails anyway, so the backtrace is mainly for debugging. But in general we don't emit kernel messages when syscalls return failure. The similar procfs mmap path simply fails the mmap with no warning. Remove the sysfs warning. Reported-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 10月, 2017 1 次提交
-
-
由 Filippo Sironi 提交于
Expose the SR-IOV device offset, stride, and VF device ID via sysfs to make it easier for userspace applications to consume them. Signed-off-by: NFilippo Sironi <sironi@amazon.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 06 10月, 2017 1 次提交
-
-
由 Bhumika Goyal 提交于
Make this const as it not modified in the file referencing it. It is only stored in a const field 'type' of a device structure. Also, add const to the variable declaration in the header file. Signed-off-by: NBhumika Goyal <bhumirks@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 26 9月, 2017 1 次提交
-
-
由 Nicolai Stange 提交于
The driver_override implementation is susceptible to a race condition when different threads are reading vs. storing a different driver override. Add locking to avoid the race condition. This is in close analogy to commit 62655397 ("driver core: platform: fix race condition with driver_override") from Adrian Salido. Fixes: 782a985d ("PCI: Introduce new device binding path using pci_dev.driver_override") Signed-off-by: NNicolai Stange <nstange@suse.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v3.16+
-
- 02 9月, 2017 1 次提交
-
-
由 Shawn Lin 提交于
The "res" variable in pci_resource_io() is never used. Remove it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-