- 24 Aug, 2021 10 commits
-
-
Heiner Kallweit authored
Member ec isn't used, so remove it. Link: https://lore.kernel.org/r/30648e95-bfb9-9af3-0c8f-dd3e34df8b6b@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Validate the VPD checksum with pci_vpd_check_csum() to simplify the code. Link: https://lore.kernel.org/r/70404ece-0036-c0ce-f824-f5637e54115e@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Link: https://lore.kernel.org/r/f062921c-ad33-3b3e-8ada-b53427a9cd4a@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_alloc() to dynamically allocate a properly sized buffer and read the full VPD data into it. This simplifies the code, and we no longer have to make assumptions about VPD size. Link: https://lore.kernel.org/r/62522a24-f39a-2b35-1577-1fbb41695bed@gmail.comReported-by: kernel test robot <lkp@intel.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Use strncasecmp() to match Vendor ID instead of comparing with lower- and upper-case hex string. [bhelgaas: convert to strncasecmp()] Link: https://lore.kernel.org/r/a9f730cf-e31e-902b-7b39-0ff2e99636e0@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_alloc() to dynamically allocate a properly sized buffer and read the full VPD data into it. This simplifies the code, and we no longer have to make assumptions about VPD size. Link: https://lore.kernel.org/r/821a334d-ff9d-386e-5f42-9b620ab3dbfa@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Read NVRAM directly into buffer and use swab32s() to byte swap it in-place instead of reading it into the end of the buffer and swapping it manually while copying it. [bhelgaas: commit log] Link: https://lore.kernel.org/r/e4ac6229-1df5-8760-3a87-1ad0ace87137@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Link: https://lore.kernel.org/r/7ca2b8b5-4c94-f644-1d80-b2ffb8df2d05@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Replace netif_err() with pci_err() because the netdevice isn't registered yet, which results in very ugly messages. Use kmemdup_nul() instead of open-coding it. This is the same as 37838aa4 ("sfc: Search VPD with pci_vpd_find_ro_info_keyword()"), just for the falcon chip version. Link: https://lore.kernel.org/r/898282a1-13bd-17bc-2e9a-d3dcd336b46c@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_alloc() to dynamically allocate a properly sized buffer and read the full VPD data into it. This avoids having to allocate a buffer on the stack, and we don't have to make any assumptions on VPD size and location of information in VPD. This is the same as 5119e20f ("sfc: Read VPD with pci_vpd_alloc()"), just for the falcon chip version. Link: https://lore.kernel.org/r/2a8d069e-9516-50d8-6520-2614222c8f5f@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 20 Aug, 2021 8 commits
-
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Link: https://lore.kernel.org/r/0ae9d4c0-590d-682a-a0af-2272e5f71630@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Validate the VPD checksum with pci_vpd_check_csum() to simplify the code. Link: https://lore.kernel.org/r/7297fce9-47db-3b86-366e-10b9ef43beaf@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_alloc() to dynamically allocate a properly sized buffer and read the full VPD data into it. This simplifies the code, and we no longer have to make assumptions about VPD size. Link: https://lore.kernel.org/r/bd3cd19c-b74f-9704-5786-476bf35ab5de@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to simplify the code. Replace netif_err() with pci_err() because the netdevice isn't registered yet, which results in very ugly messages. Use kmemdup_nul() instead of open-coding it. Link: https://lore.kernel.org/r/bf5d4ba9-61a9-2bfe-19ec-75472732d74d@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Use pci_vpd_alloc() to dynamically allocate a properly sized buffer and read the full VPD data into it. This avoids having to allocate a buffer on the stack, and we don't have to make any assumptions on VPD size and location of information in VPD. Link: https://lore.kernel.org/r/e58f1e40-c043-0266-9a0f-e5a7f3f6883c@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
VPD checksum information and checksum calculation are specified by PCIe r5.0, sec 6.28.2.2. Therefore checksum handling can and should be moved into the PCI VPD core. Add pci_vpd_check_csum() to validate the VPD checksum. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/1643bd7a-088e-1028-c9b0-9d112cf48d63@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
All users of pci_vpd_find_info_keyword() are interested in the VPD RO section only. In addition all calls are followed by the same activities to calculate start of tag data area and size of the data area. Add pci_vpd_find_ro_info_keyword() that combines these functionalities. pci_vpd_find_info_keyword() can be phased out once all users are converted. [bhelgaas: split pci_vpd_check_csum() to separate patch] Link: https://lore.kernel.org/r/1643bd7a-088e-1028-c9b0-9d112cf48d63@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Several users of the VPD API use a fixed-size buffer and read the VPD into it for further usage. This requires special handling for the case that the buffer isn't big enough to hold the full VPD data. Also the buffer is often allocated on the stack, which isn't too nice. Add pci_vpd_alloc() to dynamically allocate buffer of the correct size and read VPD into it. Link: https://lore.kernel.org/r/955ff598-0021-8446-f856-0c2c077635d7@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 12 Aug, 2021 6 commits
-
-
Heiner Kallweit authored
Exporting sysfs files that can't be accessed doesn't make much sense. Therefore, if either a quirk or the dynamic size calculation result in VPD being marked as invalid, treat this as though the device has no VPD capability. One consequence is that the "vpd" sysfs file is not visible. Link: https://lore.kernel.org/r/6a02b204-4ed2-4553-c3b2-eacf9554fa8d@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Determine VPD size in pci_vpd_init(). Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the dynamic size calculation. Prerequisite is that we move the quirks from FINAL to HEADER so they are run before pci_vpd_init(). Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Now that struct pci_vpd is really small, simplify the code by embedding struct pci_vpd directly in struct pci_dev instead of dynamically allocating it. Link: https://lore.kernel.org/r/d898489e-22ba-71f1-2f31-f1a78dc15849@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Instead of having a separate flag, use vp->len != 0 as indicator that VPD validity has been checked. Now vpd->len == PCI_VPD_SZ_INVALID indicates that VPD is invalid. Link: https://lore.kernel.org/r/9f777bc7-5316-e1b8-e5d4-f9f609bdb5dd@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Some multi-function devices share VPD hardware across functions and don't work correctly for concurrent VPD accesses to different functions. Struct pci_vpd_ops was added by 932c435c ("PCI: Add dev_flags bit to access VPD through function 0") so that on these devices, VPD accesses to any function would always go to function 0. It's easier to just check for the PCI_DEV_FLAGS_VPD_REF_F0 quirk bit in the two places we need it than to deal with the struct pci_vpd_ops. Simplify the code by removing struct pci_vpd_ops and removing the indirect calls. [bhelgaas: check for !func0_dev earlier, commit log] Link: https://lore.kernel.org/r/b2532a41-df8b-860f-461f-d5c066c819d0@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Reorder pci_read_vpd() and pci_write_vpd() to prepare for future patches. No functional change intended. Link: https://lore.kernel.org/r/89f0f5a2-293b-a017-fc67-a36473a792bf@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 09 Aug, 2021 6 commits
-
-
Heiner Kallweit authored
The struct pci_vpd.flag member was used only to communicate between pci_vpd_wait() and its callers. Remove the flag member and pass the value directly to pci_vpd_wait() to simplify the code. [bhelgaas: commit log] Link: https://lore.kernel.org/r/e4ef6845-6b23-1646-28a0-d5c5a28347b6@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
Reading/writing 4 bytes should be fast enough even on a slow bus, therefore pci_vpd_wait() doesn't have to be interruptible. Making it uninterruptible allows to simplify the code. In addition make VPD writes uninterruptible in general. It's about vital data, and allowing writes to be interruptible may leave the VPD in an inconsistent state. Link: https://lore.kernel.org/r/258bf994-bc2a-2907-9181-2c7a562986d5@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Heiner Kallweit authored
vpd->len is initialized to PCI_VPD_MAX_SIZE, and if a quirk is used to set a specific VPD size, then pci_vpd_set_size() sets vpd->valid, resulting in pci_vpd_size() not being called. Therefore we can remove the old_size argument. Note that we don't have to check off < PCI_VPD_MAX_SIZE because that's implicitly done by pci_read_vpd(). Link: https://lore.kernel.org/r/ede36c16-5335-6867-43a1-293641348430@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Previously, if we found any error in the VPD, we returned size 0, which prevents access to all of VPD. But there may be valid resources in VPD before the error, and there's no reason to prevent access to those. "off" covers only VPD resources known to have valid header tags. In case of error, return "off" (which may be zero if we haven't found any valid header tags at all). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
Bjorn Helgaas authored
VPD consists of a series of Small and Large Resources. Computing the size of VPD requires only the length of each, which is specified in the generic tag of each resource. We only expect to see ID_STRING, RO_DATA, and RW_DATA in VPD, but it's not a problem if it contains other resource types because all we care about is the size. Drop the validity checking of Large Resource items. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
Bjorn Helgaas authored
VPD is limited in size by the 15-bit VPD Address field in the VPD Capability. Each resource tag includes a length that determines the overall size of the resource. Reject any resources that would extend past the maximum VPD size. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
- 30 Jul, 2021 3 commits
-
-
Heiner Kallweit authored
Previously we assumed that the first tag being 0x00 meant an EEPROM was missing. The first tag being 0xff means the same thing; check for that also. [bhelgaas: rework error mesage] Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
Bjorn Helgaas authored
Previously, we checked for PCI_VPD_STIN_END, PCI_VPD_LTIN_ID_STRING, etc., outside the Large and Small Resource cases, so we checked Large Resource Item Names against a Small Resource name and vice versa. Move these tests into the Large and Small Resource cases, so we only check PCI_VPD_STIN_END for Small Resources and PCI_VPD_LTIN_* for Large Resources. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
Bjorn Helgaas authored
Previously, when a VPD read failed, we warned about an "invalid large VPD tag". Warn about the VPD read failure instead. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
-
- 11 Jul, 2021 7 commits
-
-
Linus Torvalds authored
-
Hugh Dickins authored
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734c ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reported-by: kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61b ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/563ce5b2-7a44-5b4d-1dfd-59a0e65932a9@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Ingo Molnar: "Two fixes: - Fix a MIPS IRQ handling RCU bug - Remove a DocBook annotation for a parameter that doesn't exist anymore" * tag 'irq-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mips: Fix RCU violation when using irqdomain lookup on interrupt entry genirq/irqdesc: Drop excess kernel-doc entry @lookup
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Ingo Molnar: "Three fixes: - Fix load tracking bug/inconsistency - Fix a sporadic CFS bandwidth constraints enforcement bug - Fix a uclamp utilization tracking bug for newly woken tasks" * tag 'sched-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/uclamp: Ignore max aggregation if rq is idle sched/fair: Fix CFS bandwidth hrtimer expiry type sched/fair: Sync load_sum with load_avg after dequeue
-