It is much saner to store a pointer to the kobject structure that contains
the cannonical stats pointer than to copy the stats pointers into a public
structure.
Future patches will require the sysfs pointer for other purposes.
Link: https://lore.kernel.org/r/f90551dfd296cde1cb507bbef27cca9891d19871.1623427137.git.leonro@nvidia.com
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
This is being used to implement both the port and device global stats,
which is causing some confusion in the drivers. For instance EFA and i40iw
both seem to be misusing the device stats.
Split it into two ops so drivers that don't support one or the other can
leave the op NULL'd, making the calling code a little simpler to
understand.
Link: https://lore.kernel.org/r/1955c154197b2a159adc2dc97266ddc74afe420c.1623427137.git.leonro@nvidia.com
Tested-by: Gal Pressman <galpress@amazon.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Running devlink reload command for port in switchdev mode cause
resources to corrupt: driver can't release allocated EQ and reclaim
memory pages, because "rdma" auxiliary device had add CQs which blocks
EQ from deletion.
Erroneous sequence happens during reload-down phase, and is following:
1. detach device - suspends auxiliary devices which support it, destroys
others. During this step "eth-rep" and "rdma-rep" are destroyed,
"eth" - suspended.
2. disable SRIOV - moves device to legacy mode; as part of disablement -
rescans drivers. This step adds "rdma" auxiliary device.
3. destroy EQ table - <failure>.
Driver shouldn't create any device during unload flows. To handle that
implement MLX5_PRIV_FLAGS_DETACH flag, set it on device detach and unset
on device attach. If flag is set do no-op on drivers rescan.
Fixes: a925b5e309 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus")
Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Attempting to boot 32-bit ARM kernels under QEMU's 3.x virt models fails
when we have more than 512M of RAM in the model as we run out of vmalloc
space for the PCI ECAM regions. This failure will be silent when running
libvirt, as the console in that situation is a PCI device.
In this configuration, the kernel maps the whole ECAM, which QEMU sets up
for 256 buses, even when maybe only seven buses are in use. Each bus uses
1M of ECAM space, and ioremap() adds an additional guard page between
allocations. The kernel vmap allocator will align these regions to 512K,
resulting in each mapping eating 1.5M of vmalloc space. This means we need
384M of vmalloc space just to map all of these, which is very wasteful of
resources.
Fix this by only mapping the ECAM for buses we are going to be using. In
my setups, this is around seven buses in most guests, which is 10.5M of
vmalloc space - way smaller than the 384M that would otherwise be required.
This also means that the kernel can boot without forcing extra RAM into
highmem with the vmalloc= argument, or decreasing the virtual RAM available
to the guest.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/E1lhCAV-0002yb-50@rmk-PC.armlinux.org.uk
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Make the gathered SMC statistics network namespace aware, for each
namespace collect an own set of statistic information.
Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support to collect more detailed SMC fallback reason statistics and
provide these statistics to user space on the netlink interface.
Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add the netlink function which collects the statistics information and
delivers it to the userspace.
Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a race between THP unmapping and truncation, when truncate sees
pmd_none() and skips the entry, after munmap's zap_huge_pmd() cleared
it, but before its page_remove_rmap() gets to decrement
compound_mapcount: generating false "BUG: Bad page cache" reports that
the page is still mapped when deleted. This commit fixes that, but not
in the way I hoped.
The first attempt used try_to_unmap(page, TTU_SYNC|TTU_IGNORE_MLOCK)
instead of unmap_mapping_range() in truncate_cleanup_page(): it has
often been an annoyance that we usually call unmap_mapping_range() with
no pages locked, but there apply it to a single locked page.
try_to_unmap() looks more suitable for a single locked page.
However, try_to_unmap_one() contains a VM_BUG_ON_PAGE(!pvmw.pte,page):
it is used to insert THP migration entries, but not used to unmap THPs.
Copy zap_huge_pmd() and add THP handling now? Perhaps, but their TLB
needs are different, I'm too ignorant of the DAX cases, and couldn't
decide how far to go for anon+swap. Set that aside.
The second attempt took a different tack: make no change in truncate.c,
but modify zap_huge_pmd() to insert an invalidated huge pmd instead of
clearing it initially, then pmd_clear() between page_remove_rmap() and
unlocking at the end. Nice. But powerpc blows that approach out of the
water, with its serialize_against_pte_lookup(), and interesting pgtable
usage. It would need serious help to get working on powerpc (with a
minor optimization issue on s390 too). Set that aside.
Just add an "if (page_mapped(page)) synchronize_rcu();" or other such
delay, after unmapping in truncate_cleanup_page()? Perhaps, but though
that's likely to reduce or eliminate the number of incidents, it would
give less assurance of whether we had identified the problem correctly.
This successful iteration introduces "unmap_mapping_page(page)" instead
of try_to_unmap(), and goes the usual unmap_mapping_range_tree() route,
with an addition to details. Then zap_pmd_range() watches for this
case, and does spin_unlock(pmd_lock) if so - just like
page_vma_mapped_walk() now does in the PVMW_SYNC case. Not pretty, but
safe.
Note that unmap_mapping_page() is doing a VM_BUG_ON(!PageLocked) to
assert its interface; but currently that's only used to make sure that
page->mapping is stable, and zap_pmd_range() doesn't care if the page is
locked or not. Along these lines, in invalidate_inode_pages2_range()
move the initial unmap_mapping_range() out from under page lock, before
then calling unmap_mapping_page() under page lock if still mapped.
Link: https://lkml.kernel.org/r/a2a4a148-cdd8-942c-4ef8-51b77f643dbe@google.com
Fixes: fc127da085 ("truncate: handle file thp")
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jue Wang <juew@google.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Xu <peterx@redhat.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Wang Yugui <wangyugui@e16-tech.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Stressing huge tmpfs often crashed on unmap_page()'s VM_BUG_ON_PAGE
(!unmap_success): with dump_page() showing mapcount:1, but then its raw
struct page output showing _mapcount ffffffff i.e. mapcount 0.
And even if that particular VM_BUG_ON_PAGE(!unmap_success) is removed,
it is immediately followed by a VM_BUG_ON_PAGE(compound_mapcount(head)),
and further down an IS_ENABLED(CONFIG_DEBUG_VM) total_mapcount BUG():
all indicative of some mapcount difficulty in development here perhaps.
But the !CONFIG_DEBUG_VM path handles the failures correctly and
silently.
I believe the problem is that once a racing unmap has cleared pte or
pmd, try_to_unmap_one() may skip taking the page table lock, and emerge
from try_to_unmap() before the racing task has reached decrementing
mapcount.
Instead of abandoning the unsafe VM_BUG_ON_PAGE(), and the ones that
follow, use PVMW_SYNC in try_to_unmap_one() in this case: adding
TTU_SYNC to the options, and passing that from unmap_page().
When CONFIG_DEBUG_VM, or for non-debug too? Consensus is to do the same
for both: the slight overhead added should rarely matter, except perhaps
if splitting sparsely-populated multiply-mapped shmem. Once confident
that bugs are fixed, TTU_SYNC here can be removed, and the race
tolerated.
Link: https://lkml.kernel.org/r/c1e95853-8bcd-d8fd-55fa-e7f2488e78f@google.com
Fixes: fec89c109f ("thp: rewrite freeze_page()/unfreeze_page() with generic rmap walkers")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jue Wang <juew@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Xu <peterx@redhat.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Wang Yugui <wangyugui@e16-tech.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Most callers of is_huge_zero_pmd() supply a pmd already verified
present; but a few (notably zap_huge_pmd()) do not - it might be a pmd
migration entry, in which the pfn is encoded differently from a present
pmd: which might pass the is_huge_zero_pmd() test (though not on x86,
since L1TF forced us to protect against that); or perhaps even crash in
pmd_page() applied to a swap-like entry.
Make it safe by adding pmd_present() check into is_huge_zero_pmd()
itself; and make it quicker by saving huge_zero_pfn, so that
is_huge_zero_pmd() will not need to do that pmd_page() lookup each time.
__split_huge_pmd_locked() checked pmd_trans_huge() before: that worked,
but is unnecessary now that is_huge_zero_pmd() checks present.
Link: https://lkml.kernel.org/r/21ea9ca-a1f5-8b90-5e88-95fb1c49bbfa@google.com
Fixes: e71769ae52 ("mm: enable thp migration for shmem thp")
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jue Wang <juew@google.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Xu <peterx@redhat.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Wang Yugui <wangyugui@e16-tech.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The routine restore_reserve_on_error is called to restore reservation
information when an error occurs after page allocation. The routine
alloc_huge_page modifies the mapping reserve map and potentially the
reserve count during allocation. If code calling alloc_huge_page
encounters an error after allocation and needs to free the page, the
reservation information needs to be adjusted.
Currently, restore_reserve_on_error only takes action on pages for which
the reserve count was adjusted(HPageRestoreReserve flag). There is
nothing wrong with these adjustments. However, alloc_huge_page ALWAYS
modifies the reserve map during allocation even if the reserve count is
not adjusted. This can cause issues as observed during development of
this patch [1].
One specific series of operations causing an issue is:
- Create a shared hugetlb mapping
Reservations for all pages created by default
- Fault in a page in the mapping
Reservation exists so reservation count is decremented
- Punch a hole in the file/mapping at index previously faulted
Reservation and any associated pages will be removed
- Allocate a page to fill the hole
No reservation entry, so reserve count unmodified
Reservation entry added to map by alloc_huge_page
- Error after allocation and before instantiating the page
Reservation entry remains in map
- Allocate a page to fill the hole
Reservation entry exists, so decrement reservation count
This will cause a reservation count underflow as the reservation count
was decremented twice for the same index.
A user would observe a very large number for HugePages_Rsvd in
/proc/meminfo. This would also likely cause subsequent allocations of
hugetlb pages to fail as it would 'appear' that all pages are reserved.
This sequence of operations is unlikely to happen, however they were
easily reproduced and observed using hacked up code as described in [1].
Address the issue by having the routine restore_reserve_on_error take
action on pages where HPageRestoreReserve is not set. In this case, we
need to remove any reserve map entry created by alloc_huge_page. A new
helper routine vma_del_reservation assists with this operation.
There are three callers of alloc_huge_page which do not currently call
restore_reserve_on error before freeing a page on error paths. Add
those missing calls.
[1] https://lore.kernel.org/linux-mm/20210528005029.88088-1-almasrymina@google.com/
Link: https://lkml.kernel.org/r/20210607204510.22617-1-mike.kravetz@oracle.com
Fixes: 96b96a96dd ("mm/hugetlb: fix huge page reservation leak in private mapping error paths"
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I found it by pure code review, that pte_same_as_swp() of unuse_vma()
didn't take uffd-wp bit into account when comparing ptes.
pte_same_as_swp() returning false negative could cause failure to
swapoff swap ptes that was wr-protected by userfaultfd.
Link: https://lkml.kernel.org/r/20210603180546.9083-1-peterx@redhat.com
Fixes: f45ec5ff16 ("userfaultfd: wp: support swap and page migration")
Signed-off-by: Peter Xu <peterx@redhat.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org> [5.7+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When hugetlb page fault (under overcommitting situation) and
memory_failure() race, VM_BUG_ON_PAGE() is triggered by the following
race:
CPU0: CPU1:
gather_surplus_pages()
page = alloc_surplus_huge_page()
memory_failure_hugetlb()
get_hwpoison_page(page)
__get_hwpoison_page(page)
get_page_unless_zero(page)
zero = put_page_testzero(page)
VM_BUG_ON_PAGE(!zero, page)
enqueue_huge_page(h, page)
put_page(page)
__get_hwpoison_page() only checks the page refcount before taking an
additional one for memory error handling, which is not enough because
there's a time window where compound pages have non-zero refcount during
hugetlb page initialization.
So make __get_hwpoison_page() check page status a bit more for hugetlb
pages with get_hwpoison_huge_page(). Checking hugetlb-specific flags
under hugetlb_lock makes sure that the hugetlb page is not transitive.
It's notable that another new function, HWPoisonHandlable(), is helpful
to prevent a race against other transitive page states (like a generic
compound page just before PageHuge becomes true).
Link: https://lkml.kernel.org/r/20210603233632.2964832-2-nao.horiguchi@gmail.com
Fixes: ead07f6a86 ("mm/memory-failure: introduce get_hwpoison_page() for consistent refcount handling")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@vger.kernel.org> [5.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Export two functions from GPIO ACPI for wider use
* Clean up Whiskey Cove and Crystal Cove GPIO drivers
The following is an automated git shortlog grouped by driver:
crystalcove:
- remove platform_set_drvdata() + cleanup probe
gpiolib:
- acpi: Add acpi_gpio_get_io_resource()
- acpi: Introduce acpi_get_and_request_gpiod() helper
wcove:
- Split error handling for CTRL and IRQ registers
- Unify style of to_reg() with to_ireg()
- Use IRQ hardware number getter instead of direct access
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAmC+NWQACgkQb7wzTHR8
rCjp+Q//dLwxIG2YLA/A1vfEUz2qaCIel9r+VrJjljz4W5Y4GSzLTcAwlnuFLiwX
ggJjpgj37MYmu+6Y+Y6oHf1OLexeYraHtNqsKND5DJn2rSDGcH3wj0h3Sb4FCOrb
w0jOe2SSKc3iyM/W4e8AdvYgBj3gu0LsfV0vA0b2kAIv5tEi+iG7kt+8GCNH77gc
rk1VusvSb57YbYZHZ/yc6tsoJcl+O9zX/eErjAbNOOoeme3uHATRq97K4h9ZuUUM
lEV4KpHIQP4iSsAhMOIiwurTS1HhwR/hELopQbHj0xkMdVtizI5yF4nIeZGjoaIA
JEEuxwPEMRpXNmq8q0MVVSuWaqR3IH6o7knOVI5BSrJplFRrqSqslAop5CWmY4S4
waWaGOUGhBDUcs4KwxeP2kGlkl7MW3OWHIpEdqvRDYM3vp7xcQURuvtgoqdlQSAl
jfyhOpW6XwqnAQW1/6UAT8OIc16pFkaQ3L0IUE5V4as2d6edEIhfo+gb5nvnppYe
TzFLOmXKSB+NPz6zsEMFxdYPjmW5nJdMdmD3LG5uNItkm1+AjB3bz5dy85Mz5fzl
VF2xAeLoobQTeT+WZIakBs0NuB2BRkYbk70XKidlTEsGsbWK4G2zIk3sLnWxS1Ch
EkXaH4EzMkSBrk3YHbq+leVszeYKuN80NKcl7eoxN4td/iFT6BA=
=WHpx
-----END PGP SIGNATURE-----
Merge tag 'intel-gpio-v5.14-1' into review-hans
intel-gpio for v5.14-1
* Export two functions from GPIO ACPI for wider use
* Clean up Whiskey Cove and Crystal Cove GPIO drivers
The following is an automated git shortlog grouped by driver:
crystalcove:
- remove platform_set_drvdata() + cleanup probe
gpiolib:
- acpi: Add acpi_gpio_get_io_resource()
- acpi: Introduce acpi_get_and_request_gpiod() helper
wcove:
- Split error handling for CTRL and IRQ registers
- Unify style of to_reg() with to_ireg()
- Use IRQ hardware number getter instead of direct access
While events can already be enabled and disabled via the generic request
IOCTL, this bypasses the internal reference counting mechanism of the
controller. Due to that, disabling an event will turn it off regardless
of any other client having requested said event, which may break
functionality of that client.
To solve this, add IOCTLs wrapping the ssam_controller_event_enable()
and ssam_controller_event_disable() functions, which have been
previously introduced for this specific purpose.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210604134755.535590-6-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently, debugging unknown events requires writing a custom driver.
This is somewhat difficult, slow to adapt, and not entirely
user-friendly for quickly trying to figure out things on devices of some
third-party user. We can do better. We already have a user-space
interface intended for debugging SAM EC requests, so let's add support
for receiving events to that.
This commit provides support for receiving events by reading from the
controller file. It additionally introduces two new IOCTLs to control
which event categories will be forwarded. Specifically, a user-space
client can specify which target categories it wants to receive events
from by registering the corresponding notifier(s) via the IOCTLs and
after that, read the received events by reading from the controller
device.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210604134755.535590-5-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We can already enable and disable SAM events via one of two ways: either
via a (non-observer) notifier tied to a specific event group, or a
generic event enable/disable request. In some instances, however,
neither method may be desirable.
The first method will tie the event enable request to a specific
notifier, however, when we want to receive notifications for multiple
event groups of the same target category and forward this to the same
notifier callback, we may receive duplicate events, i.e. one event per
registered notifier. The second method will bypass the internal
reference counting mechanism, meaning that a disable request will
disable the event regardless of any other client driver using it, which
may break the functionality of that driver.
To address this problem, add new functions that allow enabling and
disabling of events via the event reference counting mechanism built
into the controller, without needing to register a notifier.
This can then be used in combination with observer notifiers to process
multiple events of the same target category without duplication in the
same callback function.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210604134755.535590-3-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently, each SSAM event notifier is directly tied to one group of
events. This makes sense as registering a notifier will automatically
take care of enabling the corresponding event group and normally drivers
only need notifications for a very limited number of events, associated
with different callbacks for each group.
However, there are rare cases, especially for debugging, when we want to
get notifications for a whole event target category instead of just a
single group of events in that category. Registering multiple notifiers,
i.e. one per group, may be infeasible due to two issues: a) we might not
know every event enable/disable specification as some events are
auto-enabled by the EC and b) forwarding this to the same callback will
lead to duplicate events as we might not know the full event
specification to perform the appropriate filtering.
This commit introduces observer-notifiers, which are notifiers that are
not tied to a specific event group and do not attempt to manage any
events. In other words, they can be registered without enabling any
event group or incrementing the corresponding reference count and just
act as silent observers, listening to all currently/previously enabled
events based on their match-specification.
Essentially, this allows us to register one single notifier for a full
event target category, meaning that we can process all events of that
target category in a single callback without duplication. Specifically,
this will be used in the cdev debug interface to forward events to
user-space via a device file from which the events can be read.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210604134755.535590-2-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The legay ide driver has been replace with libata starting in 2003 and has
been scheduled for removal for a while. Finally kill it off so that we
can start cleaning up various bits of cruft it forced on the block layer.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This is a pre-cursor to some upcoming W=1 fix-ups.
Fixes the following W=1 kernel build warning(s):
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mark Lord <mlord@pobox.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210528090502.1799866-2-lee.jones@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The req pointer uniquely identify a specific request.
Having it in traces can provide valuable insights that is not possible
to have if the calling process is reusing the same user_data value.
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
These function declarations are not needed any more.
The definitions were deleted.
Fixes: 2ab6096db2 ("xfrm: remove output_finish indirection from xfrm_state_afinfo")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Although first implemented for NVME, this check may be usable by
other drivers as well. Microsoft's specification explicitly mentions
that is may be usable by SATA and AHCI devices. Google also indicates
that they have used this with SDHCI in a downstream kernel tree that
a user can plug a storage device into.
Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
Suggested-by: Keith Busch <kbusch@kernel.org>
CC: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com>
CC: Alexander Deucher <Alexander.Deucher@amd.com>
CC: Rafael J. Wysocki <rjw@rjwysocki.net>
CC: Prike Liang <prike.liang@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
CXL is a hotplug bus and arranges for nvdimm devices to be dynamically
discovered and removed. The libnvdimm core manages shutdown of nvdimm
security operations when the device is unregistered. That functionality
is moved to nvdimm_delete() and invoked by the CXL-to-nvdimm glue code.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/162379910271.2993820.2955889139842401250.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This patch enables support for Dell S140 and later controllers
that use Intel's PCHs configured as PCI_CLASS_STORAGE_RAID.
Reviewed-by: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Charles Rose <charles.rose@dell.com>
Link: https://lore.kernel.org/r/20210615190801.1744466-1-charles.rose@dell.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[WHY]
SCR for DP 2.0 spec says that multiple LTTPRs must not be accessed in a
single AUX transaction.
There may be other places in future where breaking up AUX accesses is
necessary.
[HOW]
Partition the entire DPCD address space into blocks. When an incoming AUX
request spans multiple blocks, break up the request into multiple requests.
Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Anson Jacob <Anson.Jacob@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Make dm-writecache wait if the kcopyd workqueue is busy (as will
happen if waiting for page allocation or inside submit_bio).
This change improves performance of "mkfs.ext2" by approximately 20%
on one testbed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The round-robin rr_tx_counter was shared across CPUs leading to
significant cache thrashing at high packet rates. This patch switches
the round-robin packet counter to use a per-cpu variable to decide
the destination slave.
On a test with 2x100Gbit ICE nic with pktgen_sample_04_many_flows.sh
(-s 64 -t 32) the tx rate was 19.6Mpps before and 22.3Mpps after
this patch.
"perf top -e cache_misses" before:
12.31% [bonding] [k] bond_xmit_roundrobin_slave_get
10.59% [sch_fq_codel] [k] fq_codel_dequeue
9.34% [kernel] [k] skb_release_data
after:
15.42% [sch_fq_codel] [k] fq_codel_dequeue
10.06% [kernel] [k] __memset
9.12% [kernel] [k] skb_release_data
Signed-off-by: Jussi Maki <joamaki@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The function get_net_ns_by_fd() could be inlined when NET_NS is not
enabled.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Scaled PPM conversion to PPB may (on 64bit systems) result
in a value larger than s32 can hold (freq/scaled_ppm is a long).
This means the kernel will not correctly reject unreasonably
high ->freq values (e.g. > 4294967295ppb, 281474976645 scaled PPM).
The conversion is equivalent to a division by ~66 (65.536),
so the value of ppb is always smaller than ppm, but not small
enough to assume narrowing the type from long -> s32 is okay.
Note that reasonable user space (e.g. ptp4l) will not use such
high values, anyway, 4289046510ppb ~= 4.3x, so the fix is
somewhat pedantic.
Fixes: d39a743511 ("ptp: validate the requested frequency adjustment.")
Fixes: d94ba80ebb ("ptp: Added a brand new class driver for ptp clocks.")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to possible mode switching to 8D-8D-8D, it might not be possible to
read the SFDP after the initial probe. To be able to dump the SFDP via
sysfs afterwards, make a complete copy of it.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
The Arm FFA specification describes a software architecture to
leverages the virtualization extension to isolate software images
provided by an ecosystem of vendors from each other and describes
interfaces that standardize communication between the various software
images including communication between images in the Secure world and
Normal world. Any Hypervisor could use the FFA interfaces to enable
communication between VMs it manages.
The Hypervisor a.k.a Partition managers in FFA terminology can assign
system resources(Memory regions, Devices, CPU cycles) to the partitions
and manage isolation amongst them.
This is the initial and minimal support for the FFA interface to enable
communication between secure partitions and the normal world OS.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmC19HAACgkQAEG6vDF+
4pijcw//XugK+jFEN7fA6eFzE7OeGt1xPG2mhG5TF1jtvQv2TQlij50V8evOgJmd
kM3h5pUeEWMt4XrF0I2TlLOglBHLpFbU253kRPRC7zeYxK+AzD6TxtABKZ+eykAk
OEQisX9FMp/h1rnnvu/OqT7l2AH/pZkVIwc2GQi6h+BvQzUq/NPanuuT+rS00U2E
lLfZ98MQIjoUSDKr6r0C83gt8BlUWR62jkIkhsLycwFFouhWrdewXptfOntD4wIs
1pDRi4+qdZLbOeFCLxHR9NfMTdGdnBY//P8NwmnSYV6YnbtVcgwvwyRqMAC6ElJM
Lk+AuqJS+RSCdyqQerjkvVMNSQx778nPsmzEMteOyLCAfr2kXhQ84FfqaJpFBDsJ
GQUUW8H5runR2P4p2Q3Tql9tTt7AhrOuO0iUIxBu5cq4YRBPMBamtRbquJtYN+VH
9ggV4ygbkq4BIKYaBFaVffHOg0ygbvDTkXv/09wRmcGNH12y9AeuLyumhwcWxV0Z
Kk0bjEieTjvisrshOeKOp5eOuhyixhFJNcffAOIos3KIkuQ1ivAL7cIig9fWF+k0
AbqOTvX4dVSdIKBi+Q8op2CZ1gyDi80P43MstTgKlbZ8AN2YWxa9S3Iw27D4gY8u
tIN8PqkB2NctwQecVcGv58JyDlqTRnCcuole7fJWr3iGRdGvyV4=
=DQ7A
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAmDI23cPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3uCcP/37GON7dD4zlic7idjGb6Wh5VuaaCSkKJDGc
J7KDji52tvYVzNiqlTJu4qgTzWEIX3RLGqKHjeZHBDUwuHoWZFOTtVAU0d3xLVw1
gXa9LQypRQ094pZ4/5ClaiBV2tiQB2E8j/jppynG+8XpOUDhu5rFD+dUpOhQwqW+
REs+t1xDuGItcoweJj7ufXw+ZLgoLkbRnU7YniPQe4awS8Ml6lwDi1Rj7CXHmpW4
5AMA1FLovAZ9Y0Dyy3MVOkfHTP/LVP6LPLxcSUc6xkBT9We76WgiHPMtzvNiwSAV
ZLTua2cB9OdYt1ZGB40x4XDEZs85L8dGSSRXsARkcX+ImR3rLLOcomdW5QrD7Hgr
1FtoAed13g5cxfiOizjpXLCEl6qxeW3lQ9au4FQ5xCasS7LM5tM/YuiyrafHu+Ep
yVNgy35pBNjgh0NmGCGtrH7H9d/n7kdMgTNXHVkD6GW8qxXKEVfVVtwATSRJMRTV
1bjxXjA2B7u91xAnWm874X6SLVYgxRXtHUR4EMxWoSATNAL4pvTNfGz6Wwt1QD1D
ZJ8wqjYKhdEnKPqjtUW7iFYrbUd550B9FXwu8f3Uaau8/ON9P+t63C1XPdmyZA57
CQMufO8TaXJ2ARDVxzO5dyYhgqN5Ew2DvDj/qmlGz26mF25JmdigeuRBplNF302+
wj3e47y6
=TfmE
-----END PGP SIGNATURE-----
Merge tag 'arm-ffa-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers
Arm Firmware Framework for ARMv8-A(FFA) interface driver
The Arm FFA specification describes a software architecture to
leverages the virtualization extension to isolate software images
provided by an ecosystem of vendors from each other and describes
interfaces that standardize communication between the various software
images including communication between images in the Secure world and
Normal world. Any Hypervisor could use the FFA interfaces to enable
communication between VMs it manages.
The Hypervisor a.k.a Partition managers in FFA terminology can assign
system resources(Memory regions, Devices, CPU cycles) to the partitions
and manage isolation amongst them.
This is the initial and minimal support for the FFA interface to enable
communication between secure partitions and the normal world OS.
* tag 'arm-ffa-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Add support for MEM_* interfaces
firmware: arm_ffa: Setup in-kernel users of FFA partitions
firmware: arm_ffa: Add support for SMCCC as transport to FFA driver
firmware: arm_ffa: Add initial Arm FFA driver support
firmware: arm_ffa: Add initial FFA bus support for device enumeration
arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
Link: https://lore.kernel.org/r/20210601095838.GA838783@bogus
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch introduces a new bpf_attach_type for BPF_PROG_TYPE_SK_REUSEPORT
to check if the attached eBPF program is capable of migrating sockets. When
the eBPF program is attached, we run it for socket migration if the
expected_attach_type is BPF_SK_REUSEPORT_SELECT_OR_MIGRATE or
net.ipv4.tcp_migrate_req is enabled.
Currently, the expected_attach_type is not enforced for the
BPF_PROG_TYPE_SK_REUSEPORT type of program. Thus, this commit follows the
earlier idea in the commit aac3fc320d ("bpf: Post-hooks for sys_bind") to
fix up the zero expected_attach_type in bpf_prog_load_fixup_attach_type().
Moreover, this patch adds a new field (migrating_sk) to sk_reuseport_md to
select a new listener based on the child socket. migrating_sk varies
depending on if it is migrating a request in the accept queue or during
3WHS.
- accept_queue : sock (ESTABLISHED/SYN_RECV)
- 3WHS : request_sock (NEW_SYN_RECV)
In the eBPF program, we can select a new listener by
BPF_FUNC_sk_select_reuseport(). Also, we can cancel migration by returning
SK_DROP. This feature is useful when listeners have different settings at
the socket API level or when we want to free resources as soon as possible.
- SK_PASS with selected_sk, select it as a new listener
- SK_PASS with selected_sk NULL, fallbacks to the random selection
- SK_DROP, cancel the migration.
There is a noteworthy point. We select a listening socket in three places,
but we do not have struct skb at closing a listener or retransmitting a
SYN+ACK. On the other hand, some helper functions do not expect skb is NULL
(e.g. skb_header_pointer() in BPF_FUNC_skb_load_bytes(), skb_tail_pointer()
in BPF_FUNC_skb_load_bytes_relative()). So we allocate an empty skb
temporarily before running the eBPF program.
Suggested-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/netdev/20201123003828.xjpjdtk4ygl6tg6h@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/netdev/20201203042402.6cskdlit5f3mw4ru@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/netdev/20201209030903.hhow5r53l6fmozjn@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/bpf/20210612123224.12525-10-kuniyu@amazon.co.jp
We will call sock_reuseport.prog for socket migration in the next commit,
so the eBPF program has to know which listener is closing to select a new
listener.
We can currently get a unique ID of each listener in the userspace by
calling bpf_map_lookup_elem() for BPF_MAP_TYPE_REUSEPORT_SOCKARRAY map.
This patch makes the pointer of sk available in sk_reuseport_md so that we
can get the ID by BPF_FUNC_get_socket_cookie() in the eBPF program.
Suggested-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/netdev/20201119001154.kapwihc2plp4f7zc@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/bpf/20210612123224.12525-9-kuniyu@amazon.co.jp
reuseport_migrate_sock() does the same check done in
reuseport_listen_stop_sock(). If the reuseport group is capable of
migration, reuseport_migrate_sock() selects a new listener by the child
socket hash and increments the listener's sk_refcnt beforehand. Thus, if we
fail in the migration, we have to decrement it later.
We will support migration by eBPF in the later commits.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/bpf/20210612123224.12525-5-kuniyu@amazon.co.jp
When we close a listening socket, to migrate its connections to another
listener in the same reuseport group, we have to handle two kinds of child
sockets. One is that a listening socket has a reference to, and the other
is not.
The former is the TCP_ESTABLISHED/TCP_SYN_RECV sockets, and they are in the
accept queue of their listening socket. So we can pop them out and push
them into another listener's queue at close() or shutdown() syscalls. On
the other hand, the latter, the TCP_NEW_SYN_RECV socket is during the
three-way handshake and not in the accept queue. Thus, we cannot access
such sockets at close() or shutdown() syscalls. Accordingly, we have to
migrate immature sockets after their listening socket has been closed.
Currently, if their listening socket has been closed, TCP_NEW_SYN_RECV
sockets are freed at receiving the final ACK or retransmitting SYN+ACKs. At
that time, if we could select a new listener from the same reuseport group,
no connection would be aborted. However, we cannot do that because
reuseport_detach_sock() sets NULL to sk_reuseport_cb and forbids access to
the reuseport group from closed sockets.
This patch allows TCP_CLOSE sockets to remain in the reuseport group and
access it while any child socket references them. The point is that
reuseport_detach_sock() was called twice from inet_unhash() and
sk_destruct(). This patch replaces the first reuseport_detach_sock() with
reuseport_stop_listen_sock(), which checks if the reuseport group is
capable of migration. If capable, it decrements num_socks, moves the socket
backwards in socks[] and increments num_closed_socks. When all connections
are migrated, sk_destruct() calls reuseport_detach_sock() to remove the
socket from socks[], decrement num_closed_socks, and set NULL to
sk_reuseport_cb.
By this change, closed or shutdowned sockets can keep sk_reuseport_cb.
Consequently, calling listen() after shutdown() can cause EADDRINUSE or
EBUSY in inet_csk_bind_conflict() or reuseport_add_sock() which expects
such sockets not to have the reuseport group. Therefore, this patch also
loosens such validation rules so that a socket can listen again if it has a
reuseport group with num_closed_socks more than 0.
When such sockets listen again, we handle them in reuseport_resurrect(). If
there is an existing reuseport group (reuseport_add_sock() path), we move
the socket from the old group to the new one and free the old one if
necessary. If there is no existing group (reuseport_alloc() path), we
allocate a new reuseport group, detach sk from the old one, and free it if
necessary, not to break the current shutdown behaviour:
- we cannot carry over the eBPF prog of shutdowned sockets
- we cannot attach/detach an eBPF prog to/from listening sockets via
shutdowned sockets
Note that when the number of sockets gets over U16_MAX, we try to detach a
closed socket randomly to make room for the new listening socket in
reuseport_grow().
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/bpf/20210612123224.12525-4-kuniyu@amazon.co.jp
As noted in the following commit, a closed listener has to hold the
reference to the reuseport group for socket migration. This patch adds a
field (num_closed_socks) to struct sock_reuseport to manage closed sockets
within the same reuseport group. Moreover, this and the following commits
introduce some helper functions to split socks[] into two sections and keep
TCP_LISTEN and TCP_CLOSE sockets in each section. Like a double-ended
queue, we will place TCP_LISTEN sockets from the front and TCP_CLOSE
sockets from the end.
TCP_LISTEN----------> <-------TCP_CLOSE
+---+---+ --- +---+ --- +---+ --- +---+
| 0 | 1 | ... | i | ... | j | ... | k |
+---+---+ --- +---+ --- +---+ --- +---+
i = num_socks - 1
j = max_socks - num_closed_socks
k = max_socks - 1
This patch also extends reuseport_add_sock() and reuseport_grow() to
support num_closed_socks.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20210612123224.12525-3-kuniyu@amazon.co.jp
This commit adds a new sysctl option: net.ipv4.tcp_migrate_req. If this
option is enabled or eBPF program is attached, we will be able to migrate
child sockets from a listener to another in the same reuseport group after
close() or shutdown() syscalls.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Benjamin Herrenschmidt <benh@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20210612123224.12525-2-kuniyu@amazon.co.jp
This patch adds bindings required for Quinary MI2S ports on AFE.
Signed-off-by: Gabriel David <ultracoolguy@disroot.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210605022206.13226-2-ultracoolguy@disroot.org
Signed-off-by: Mark Brown <broonie@kernel.org>
These changes implement the core power domain for the PMC, and fix a
couple of minor issues as well as add stubs to help some drivers be
compile tested more easily.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmDDjV4THHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoXVsD/0QgZHiuEH8rU42JtYGB/rjCskWUPen
BOtcrIi+QxJ7m8q4qnRrPIeE8ETjQAB92pWpZE8VQ260Pk/s8NAeIXBbP7I2lKU8
M+TkwvCQ8zZw18q9ZPinqSUHgVsh7Q+7kQggHGZcYpE4rOmlb0oTr9B2EprdSpBl
hVNGtcaJ9Ovqri1ioDi/owUaxYpeJ3L8A++luIv9K8oDUpN7GBw3nV0dMOBvUOBs
nT9iQFEThvo0NRNs4zPNDPLPsLJFwePRDmY9SE4PCreDKo26+VWAamooW8R6iEnU
P7OOfCSZbLqMs8Sfkjrb742sqWX50okFFJQG6aW3BOln3IA5esc9uJ3l2jH6GZP1
21hestxJjK2JuZLv8uMtGHura8do7e4PrYVvxOT6Lp85AXaXA1/uieAWRyh40lcD
d4S4hL3prlfgepj6eUy40MnbLbatsRyQoFYdloZtB+cZb+KxMSV/Lx+j0Y5VyOI/
OpVcTxTxwAZRrVcHTISkUjkxLProY1hQwQP9vexRMIn8SB+ZhgztjHJQuUxa25at
c2Q1aOeGr+h3w1NYpOa+u1tyyKt/Vw92tA84MHaoGoWJg2DGXDAh66HFpiFrmE8q
+n2wc/uyhz1bdS38ky73ibJ6iQ96ucRLxEjCIz+59hdZ57bEYnF+EUJtNdMSyqXg
hGVs5fnWFlw97Q==
=g0AU
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-5.14-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/soc
soc/tegra: Changes for v5.14-rc1
These changes implement the core power domain for the PMC, and fix a
couple of minor issues as well as add stubs to help some drivers be
compile tested more easily.
* tag 'tegra-for-5.14-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: fuse: Fix Tegra234-only builds
soc/tegra: fuse: Don't return -ENOMEM when allocate lookups failed
soc/tegra: regulators: Support core domain state syncing
soc/tegra: pmc: Add driver state syncing
soc/tegra: pmc: Add core power domain
soc/tegra: fuse: Add stubs needed for compile-testing
soc/tegra: Add devm_tegra_core_dev_init_opp_table()
soc/tegra: Add stub for soc_is_tegra()
soc/tegra: regulators: Bump voltages on system reboot
regulator: core: Add regulator_sync_voltage_rdev()
Link: https://lore.kernel.org/r/20210611164437.3568059-2-thierry.reding@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
In addition to fixing a kerneldoc issue in the qcom-ebi2 driver this
populates socinfo with a range of platforms and PMICs and extends a few
of the Qualcomm drivers bits of support for MSM8226, MDM9607, SM6125 and
SC8180X.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmDHzwcbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FGQQP/1LIahAfEFvu6UfbVIOJ
6cRsYCNv0UnqzGUqiV+4RehNkq9n/VTEvRKKk8bXrQoH75V4TVoCpKy22h2/13MF
+2zts3dDdsTSLZqRaWJCt2AShkQwqF2W+3cpy9g9hcJaP/5L8rQGSsfmzIyZ/mwn
fp2xHHF624Wf6o8GjMVk7TyeUJ+FTeZovoc9vOPdG0f+Zmb+JniSdl5LTd3h0bYr
ZcFyDnd6/b3sU7jUy3x2tHEZwr8T3uPCN8T2tsrVc6NbjXF7QTnfhtkl8jOOmrZW
MAHr8qC9hjhZDbJCYOvOHpUWXqwIybfsliAE3mEqA7k2AGgeVTr5qBGnGUiBmM1i
OZ+AE34CP3p5L+GFz+ZaDeAa0NhaLMluHCvMb42xvf9iNdlnYoSgmo+CwSTloc4F
hHvnmZtRdCC6A6hjR3pjMZw/gStH5a5HAchLIneAeP/fferoHox/7tb/IOYXcMuW
pkjrXxvR4+0TtV/RSeqIOp2L5vq5UjJkN690UyFzZqltaWd312WPXRaO9L+GKVoc
9Tru3y9kx/oQvt36elB8SKWaiYMpYEie8pGKCWhNRLW/EAZCIPRWcu3aFgkXCP9g
uDjRQEO3Q+h/A4qXrWKuhgbrM+wXwoqSsVyWsiNLu75swjPi11Yx97BQGbqvlC5c
JZ14hDxM/uifaWsndnnPoRqk
=EwKG
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers
Qualcomm driver updates for v5.14
In addition to fixing a kerneldoc issue in the qcom-ebi2 driver this
populates socinfo with a range of platforms and PMICs and extends a few
of the Qualcomm drivers bits of support for MSM8226, MDM9607, SM6125 and
SC8180X.
* tag 'qcom-drivers-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
firmware: qcom_scm: Add MDM9607 compatible
soc: qcom: rpmpd: Add MDM9607 RPM Power Domains
soc: qcom: smd-rpm: Add MSM8226 compatible
dt-bindings: soc: qcom: smd-rpm: Add MSM8226 compatible
soc: qcom: socinfo: import PMIC IDs from pmic-spmi
bus: qcom-ebi2: Fix incorrect documentation for '{slow,fast}_cfg'
soc: qcom: socinfo: Add more IDs
soc: qcom: rpmhpd: Add SC8180X
dt-bindings: power: rpmpd: Add SC8180X to rpmpd binding
dt-bindings: soc: qcom: smd-rpm: Document SM6125 compatible
soc: qcom: smd-rpm: Add SM6125 compatible
soc: qcom: socinfo: Add remaining IPQ6018 family ID-s
soc: qcom: socinfo: Add missing SoC ID for SM6125
Link: https://lore.kernel.org/r/20210614223727.393159-1-bjorn.andersson@linaro.org
Signed-off-by: Olof Johansson <olof@lixom.net>
MSM8916 gains new support for Huawei Ascend G7, with NFC, sensors and
touchscreen. The Samsung Galaxy A3/A5 gains battery support, touch keys,
NFC.
MSM8996 received more cleanup and refactoring, preparing for upcoming
new devices. Note worthy is the long pending enablement of CPUfreq.
SC7180 continues to stabilize, with a range of small fixes for various
bits and pieces, and new revisions for the CoachZ and pompom devices.
SC7280 continues to grow, with more clock controllers, thermal sensors,
thermal zones, CPUfreq and interconnect providers.
Xiaomi Poco F1 gaines audio support and the OnePlus 6/6T gaines IPA
support.
SM8350 gains some cleanups and the IPA device is enabled.
Initial support for the Microsoft Surface Duo, based on SM8150, is
added.
IPQ8074 gained support for the HK10 board.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmDH2OsbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FDXkQAKsqE8ItJUGMoSjdmyFM
9qdaFPtrUI2kJdyq5HQ75duaSdIcVtiiDzl1w/oz8JQJg+1Wy0/x33Y8vPt4EIrs
9VQjeeXI4IyUMTnw/UEPZzmXebxYQBzryRQw0QQljptaFeIg9iVJXSUy+xqhHSdo
nWlT7XqWsDE/WA0JJhd1mPZeF1YQ7EbSJRAuME4lPDv8Toi158i2rFQLV/ebI306
U2KtN3C8N+XPsMwNZlGkPPIWXmcGlDgPHt3Wg7cTU8DUOP4c71pEuT2c8oC5o1Zu
XXd6Irp3MLlmLImLYZBLUYho1SCHknbya2pKGfBy39yiI0RqPFFIPVFjcpHMomDT
r1qsvbvtktK5TW7sYGR+Fcf66vQbvFVbydgR4IzvGth1DbajEkCGlPL7GwJURGN6
U5U6Fws6cF0wko81CMy09/9j9F/HmWsL0t1z3aL3gdo0DswsxUy5NsWcEEY9xG0t
A8IT7Qjd0t1OnVYp12oUKRKsvGtjL7O5iDBEV4QU4h2ckT0i12Wnxev1t6mw56V6
RWzKd0aki7NCFwQ3AWWNeFpC+hmVrKz3OtnSQbjS0R+DEg9ayO9T46UVLer1maoh
yXbaXyd5A1Vl3NQ4+1CARHgCWA9fmgJD13DDPF6zEVwPY8JS4ARSXVCLDXI7z4zC
5xyHsMOMWPhR8LHaAUxlGqyU
=Pj6c
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
Qualcomm ARM64 DT updates for v5.14
MSM8916 gains new support for Huawei Ascend G7, with NFC, sensors and
touchscreen. The Samsung Galaxy A3/A5 gains battery support, touch keys,
NFC.
MSM8996 received more cleanup and refactoring, preparing for upcoming
new devices. Note worthy is the long pending enablement of CPUfreq.
SC7180 continues to stabilize, with a range of small fixes for various
bits and pieces, and new revisions for the CoachZ and pompom devices.
SC7280 continues to grow, with more clock controllers, thermal sensors,
thermal zones, CPUfreq and interconnect providers.
Xiaomi Poco F1 gaines audio support and the OnePlus 6/6T gaines IPA
support.
SM8350 gains some cleanups and the IPA device is enabled.
Initial support for the Microsoft Surface Duo, based on SM8150, is
added.
IPQ8074 gained support for the HK10 board.
* tag 'qcom-arm64-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (85 commits)
arm64: dts: qcom: sc7180: Add xo clock for eMMC and Sd card
arm64: dts: sc7280: Add interconnect provider DT nodes
arm64: dts: qcom: msm8916-huawei-g7: Add NFC
arm64: dts: qcom: msm8916-huawei-g7: Add display regulator
arm64: dts: qcom: msm8916-huawei-g7: Add sensors
arm64: dts: qcom: msm8916-huawei-g7: Add touchscreen
arm64: dts: qcom: msm8916: Add device tree for Huawei Ascend G7
arm64: dts: qcom: sc7180-trogdor: Update flash freq to match reality
arm64: dts: qcom: sc7180: Add wakeup delay for adau codec
arm64: dts: qcom: sdm845: Remove cros-pd-update on Cheza
arm64: dts: qcom: sc7180: Remove cros-pd-update on Trogdor
arm64: dts: qcom: sc7180: Disable PON on Trogdor
arm64: dts: qcom: sc7180: Modify SPI_CLK voltage level for trogdor
arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo
arm64: dts: qcom: sdm845-mtp: enable IPA
arm64: dts: qcom: sc7180: SD-card GPIO pin set bias-pull up
arm64: dts: qcom: sc7180: Move sdc pinconf to board specific DT files
arm64: dts: qcom: msm8916-samsung-a2015: Add NFC
arm64: dts: qcom: msm8916-samsung-a2015: Add rt5033 battery
arm64: dts: qcom: msm8916-samsung-a5u: Add touch key regulator
...
Link: https://lore.kernel.org/r/20210614223712.393096-1-bjorn.andersson@linaro.org
Signed-off-by: Olof Johansson <olof@lixom.net>
In some cases the printf() mechanism is too heavy and can't be used.
For example, when debugging a race condition involving devres API.
When CONFIG_DEBUG_DEVRES is enabled I can't reproduce an issue, and
otherwise it's quite visible with a useful information being collected.
Enable trace events for devres part of the driver core.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517122946.53161-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Add SMP support for i.MX7D, as there are i.MX7D devices running in
field with U-Boot that doesn't support PSCI.
- Fix imx5_cpu_suspend_info reference in i.MX5 PM code comments.
- Add SoC ID initialization for i.MX50.
- Drop unnecessary of_platform_default_populate() call from i.MX6Q
.init_machine hook.
- A series from Oleksij Rempel to remove most of the i.MX6/7 board
specific PHY fixups.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmDFcfAUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM668wgAieu+Vi5mp8bua+jX4x1+ROy8/xkq
Ib6/Xd23jhAF1SEGUMSnOP5zoXRvUVZeaH27A0UYpvlDPSMVVUFnjpAIkv7x3bwl
dRUocW++95Ld85ns3ciVI38XT1eDP+VWnfv92AxIFlFiEbvRdl50cC+VfF7bppwk
5WbBpcFuT0RUesMKvzh5Yr6kVtNV6p4B25BW2dxdhxO+Nj3WhuNIlxGVJrpqYBRo
VQmfZhvQgZ4zCo83bgSbaDvo+NCejRUkF9j3H/ZJsvyztQsDv6mDm6DGzfUnRvju
MHXOgehdJ1IuG2ED3mBtb1tJ7kC8ChZBIqz4EcgQd4lOWuFUQbUsMVPN9w==
=v8xZ
-----END PGP SIGNATURE-----
Merge tag 'imx-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/soc
i.MX SoC changes for 5.14:
- Add SMP support for i.MX7D, as there are i.MX7D devices running in
field with U-Boot that doesn't support PSCI.
- Fix imx5_cpu_suspend_info reference in i.MX5 PM code comments.
- Add SoC ID initialization for i.MX50.
- Drop unnecessary of_platform_default_populate() call from i.MX6Q
.init_machine hook.
- A series from Oleksij Rempel to remove most of the i.MX6/7 board
specific PHY fixups.
* tag 'imx-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx: add smp support for imx7d
ARM: imx6q: drop of_platform_default_populate() from init_machine
ARM: imx7d: remove Atheros AR8031 PHY fixup
ARM: imx6sx: remove Atheros AR8031 PHY fixup
ARM: imx6q: remove Atheros AR8035 SmartEEE fixup
ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs
ARM: imx6q: remove BMCR_PDOWN handler in ar8035_phy_fixup()
ARM: imx6q: remove part of ar8031_phy_fixup()
ARM: imx6q: remove PHY fixup for KSZ9031
ARM: imx: Initialize SoC ID on i.MX50
ARM: imx: pm-imx5: Fix references to imx5_cpu_suspend_info
Link: https://lore.kernel.org/r/20210613082544.16067-2-shawnguo@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
- A patch series from Lucas Stach and Peng Fan adding i.MX8MM power
domains support into i.MX GPCv2 driver.
- A couple of patches from Adam Ford adding i.MX8MN power domains on top
of i.MX8MM power domain support.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmDFbO4UHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM7qLQf/ahf5xIQiQFpWMa8A+wJwYFucs4Tz
FD8HzO9/l6/WFQgwTa9WGseEnur5XIjSiyv6sCSBsxbroz8FlQvTpn2sOl0OoONB
OXBM6aSZahC/GMOgAfuKZ3/xftIKxtY4arlzumYC56ox9AzSPxW4UhoFFrabz1zj
Ib4uSMW1VjV9d+qP9QwpM8j24nBhzw7kbhitzlfFPjnDfKbvfl7VTdQLxNWONyTe
bAxSNqcWrrUxslmhHpcUHk0O86GDmxLMktQQuv+yPI7KaD/k4XDfcLMmgFZ0hwPn
08dDFbidovow/aNRu+Ham//qwyuA71qqS+6M7hE34o1IW+UCZchpyo8X4A==
=AVH/
-----END PGP SIGNATURE-----
Merge tag 'imx-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/drivers
i.MX drivers update for 5.14:
- A patch series from Lucas Stach and Peng Fan adding i.MX8MM power
domains support into i.MX GPCv2 driver.
- A couple of patches from Adam Ford adding i.MX8MN power domains on top
of i.MX8MM power domain support.
* tag 'imx-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
soc: imx: gpcv2: add support for i.MX8MN power domains
dt-bindings: add defines for i.MX8MN power domains
soc: imx: gpcv2: move reset assert after requesting domain power up
soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX power domains
soc: imx: gpcv2: add support for i.MX8MM power domains
dt-bindings: power: add defines for i.MX8MM power domains
soc: imx: gpcv2: add support for optional resets
soc: imx: gpcv2: allow domains without power-sequence control
soc: imx: gpcv2: add runtime PM support for power-domains
soc: imx: gpcv2: wait for ADB400 handshake
soc: imx: gpcv2: split power up and power down sequence control
soc: imx: gpcv2: switch to clk_bulk_* API
soc: imx: gpcv2: move domain mapping to domain driver probe
soc: imx: gpcv2: move to more ideomatic error handling in probe
Link: https://lore.kernel.org/r/20210613082544.16067-1-shawnguo@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
