Use pci_vpd_find_ro_info_keyword() to search for keywords in VPD to
simplify the code.

Link: https://lore.kernel.org/r/db576a3e-e877-b37b-98ed-cfc03d225ab3@gmail.comSigned-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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