| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The MCP2221 driver should not connect to the hidraw userspace interface,
as it needs exclusive access to the chip.
If you want to use /dev/hidrawX with the MCP2221, you need to avoid
binding this driver to the device and use the hid generic driver instead
(e.g. using udev rules).
Cc: [email protected]
Reported-by: Sven Zühlsdorf <[email protected]>
Signed-off-by: Enrik Berkhan <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The Force Feedback code assumes that all the devices passed to it will
be USB devices, but that might not be the case for emulated devices.
Guard against a crash by checking the device type before poking at USB
properties.
Cc: [email protected] # v5.16+
Reported-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Bastien Nocera <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
David Howells says:
====================
rxrpc: Fixes for I/O thread conversion/SACK table expansion
Here are some fixes for AF_RXRPC:
(1) Fix missing unlock in rxrpc's sendmsg.
(2) Fix (lack of) propagation of security settings to rxrpc_call.
(3) Fix NULL ptr deref in rxrpc_unuse_local().
(4) Fix problem with kthread_run() not invoking the I/O thread function if
the kthread gets stopped first. Possibly this should actually be
fixed in the kthread code.
(5) Fix locking problem as putting a peer (which may be done from RCU) may
now invoke kthread_stop().
(6) Fix switched parameters in a couple of trace calls.
(7) Fix I/O thread's checking for kthread stop to make sure it completes
all outstanding work before returning so that calls are cleaned up.
(8) Fix an uninitialised var in the new rxperf test server.
(9) Fix the return value of rxrpc_new_incoming_call() so that the checks
on it work correctly.
The patches fix at least one syzbot bug[1] and probably some others that
don't have reproducers[2][3][4]. I think it also fixes another[5], but
that showed another failure during testing that was different to the
original.
There's also an outstanding bug in rxrpc_put_peer()[6] that is fixed by a
combination of several patches in my rxrpc-next branch, but I haven't
included that here.
====================
Tested-by: Marc Dionne <[email protected]>
Tested-by: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
Dan Carpenter sayeth[1]:
The patch 5e6ef4f1017c: "rxrpc: Make the I/O thread take over the
call and local processor work" from Jan 23, 2020, leads to the
following Smatch static checker warning:
net/rxrpc/io_thread.c:283 rxrpc_input_packet()
warn: bool is not less than zero.
Fix this (for now) by changing rxrpc_new_incoming_call() to return an int
with 0 or error code rather than bool. Note that the actual return value
of rxrpc_input_packet() is currently ignored. I have a separate patch to
clean that up.
Fixes: 5e6ef4f1017c ("rxrpc: Make the I/O thread take over the call and local processor work")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Link: http://lists.infradead.org/pipermail/linux-afs/2022-December/006123.html [1]
Signed-off-by: David S. Miller <[email protected]>
|
|
Dan Carpenter sayeth[1]:
The patch 75bfdbf2fca3: "rxrpc: Implement an in-kernel rxperf server
for testing purposes" from Nov 3, 2022, leads to the following Smatch
static checker warning:
net/rxrpc/rxperf.c:337 rxperf_deliver_to_call()
error: uninitialized symbol 'ret'.
Fix this by initialising ret to 0. The value is only used for tracing
purposes in the rxperf server.
Fixes: 75bfdbf2fca3 ("rxrpc: Implement an in-kernel rxperf server for testing purposes")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Link: http://lists.infradead.org/pipermail/linux-afs/2022-December/006124.html [1]
Signed-off-by: David S. Miller <[email protected]>
|
|
The rxrpc I/O thread checks to see if there's any work it needs to do, and
if not, checks kthread_should_stop() before scheduling, and if it should
stop, breaks out of the loop and tries to clean up and exit.
This can, however, race with socket destruction, wherein outstanding calls
are aborted and released from the socket and then the socket unuses the
local endpoint, causing kthread_stop() to be issued. The abort is deferred
to the I/O thread and the event can by issued between the I/O thread
checking if there's any work to be done (such as processing call aborts)
and the stop being seen.
This results in the I/O thread stopping processing of events whilst call
cleanup events are still outstanding, leading to connections or other
objects still being around and uncleaned up, which can result in assertions
being triggered, e.g.:
rxrpc: AF_RXRPC: Leaked client conn 00000000e8009865 {2}
------------[ cut here ]------------
kernel BUG at net/rxrpc/conn_client.c:64!
Fix this by retrieving the kthread_should_stop() indication, then checking
to see if there's more work to do, and going back round the loop if there
is, and breaking out of the loop only if there wasn't.
This was triggered by a syzbot test that produced some other symptom[1].
Fixes: a275da62e8c1 ("rxrpc: Create a per-local endpoint receive queue and I/O thread")
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]/ [1]
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix the switched parameters on rxrpc_alloc_peer() and rxrpc_get_peer().
The ref argument and the why argument got mixed.
Fixes: 47c810a79844 ("rxrpc: trace: Don't use __builtin_return_address for rxrpc_peer tracing")
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
Now that rxrpc_put_local() may call kthread_stop(), it can't be called
under spinlock as it might sleep. This can cause a problem in the peer
keepalive code in rxrpc as it tries to avoid dropping the peer_hash_lock
from the point it needs to re-add peer->keepalive_link to going round the
loop again in rxrpc_peer_keepalive_dispatch().
Fix this by just dropping the lock when we don't need it and accepting that
we'll have to take it again. This code is only called about every 20s for
each peer, so not very often.
This allows rxrpc_put_peer_unlocked() to be removed also.
If triggered, this bug produces an oops like the following, as reproduced
by a syzbot reproducer for a different oops[1]:
BUG: sleeping function called from invalid context at kernel/sched/completion.c:101
...
RCU nest depth: 0, expected: 0
3 locks held by kworker/u9:0/50:
#0: ffff88810e74a138 ((wq_completion)krxrpcd){+.+.}-{0:0}, at: process_one_work+0x294/0x636
#1: ffff8881013a7e20 ((work_completion)(&rxnet->peer_keepalive_work)){+.+.}-{0:0}, at: process_one_work+0x294/0x636
#2: ffff88817d366390 (&rxnet->peer_hash_lock){+.+.}-{2:2}, at: rxrpc_peer_keepalive_dispatch+0x2bd/0x35f
...
Call Trace:
<TASK>
dump_stack_lvl+0x4c/0x5f
__might_resched+0x2cf/0x2f2
__wait_for_common+0x87/0x1e8
kthread_stop+0x14d/0x255
rxrpc_peer_keepalive_dispatch+0x333/0x35f
rxrpc_peer_keepalive_worker+0x2e9/0x449
process_one_work+0x3c1/0x636
worker_thread+0x25f/0x359
kthread+0x1a6/0x1b5
ret_from_fork+0x1f/0x30
Fixes: a275da62e8c1 ("rxrpc: Create a per-local endpoint receive queue and I/O thread")
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]/ [1]
Signed-off-by: David S. Miller <[email protected]>
|
|
When starting a kthread, the __kthread_create_on_node() function, as called
from kthread_run(), waits for a completion to indicate that the task_struct
(or failure state) of the new kernel thread is available before continuing.
This does not wait, however, for the thread function to be invoked and,
indeed, will skip it if kthread_stop() gets called before it gets there.
If this happens, though, kthread_run() will have returned successfully,
indicating that the thread was started and returning the task_struct
pointer. The actual error indication is returned by kthread_stop().
Note that this is ambiguous, as the caller cannot tell whether the -EINTR
error code came from kthread() or from the thread function.
This was encountered in the new rxrpc I/O thread, where if the system is
being pounded hard by, say, syzbot, the check of KTHREAD_SHOULD_STOP can be
delayed long enough for kthread_stop() to get called when rxrpc releases a
socket - and this causes an oops because the I/O thread function doesn't
get started and thus doesn't remove the rxrpc_local struct from the
local_endpoints list.
Fix this by using a completion to wait for the thread to actually enter
rxrpc_io_thread(). This makes sure the thread can't be prematurely
stopped and makes sure the relied-upon cleanup is done.
Fixes: a275da62e8c1 ("rxrpc: Create a per-local endpoint receive queue and I/O thread")
Reported-by: [email protected]
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: Hillf Danton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]/
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix rxrpc_unuse_local() to get the debug_id *after* checking to see if
local is NULL.
Fixes: a2cf3264f331 ("rxrpc: Fold __rxrpc_unuse_local() into rxrpc_unuse_local()")
Reported-by: [email protected]
Signed-off-by: David Howells <[email protected]>
Tested-by: [email protected]
cc: Marc Dionne <[email protected]>
cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix the propagation of the security settings from sendmsg to the rxrpc_call
struct.
Fixes: f3441d4125fc ("rxrpc: Copy client call parameters into rxrpc_call earlier")
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
One of the error paths in rxrpc_do_sendmsg() doesn't unlock the call mutex
before returning. Fix it to do this.
Note that this still doesn't get rid of the checker warning:
../net/rxrpc/sendmsg.c:617:5: warning: context imbalance in 'rxrpc_do_sendmsg' - wrong count at exit
I think the interplay between the socket lock and the call's user_mutex may
be too complicated for checker to analyse, especially as
rxrpc_new_client_call_for_sendmsg(), which it calls, returns with the
call's user_mutex if successful but unconditionally drops the socket lock.
Fixes: e754eba685aa ("rxrpc: Provide a cmsg to specify the amount of Tx data for a call")
Signed-off-by: David Howells <[email protected]>
cc: Marc Dionne <[email protected]>
cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
When TCF_EM_SIMPLE was introduced, it is supposed to be convenient
for ematch implementation:
https://lore.kernel.org/all/[email protected]/
"You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE
set will simply result in allocating & copy. It's an optimization,
nothing more."
So if an ematch module provides ops->datalen that means it wants a
complex data structure (saved in its em->data) instead of a simple u32
value. We should simply reject such a combination, otherwise this u32
could be misinterpreted as a pointer.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-and-tested-by: [email protected]
Reported-by: Jun Nie <[email protected]>
Cc: Jamal Hadi Salim <[email protected]>
Cc: Paolo Abeni <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Document the compatible for SM8550 mailbox.
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
If the system comes from kexec() the peripheral might trigger an IRQ
befoe we are ready for it. Triggering a crash due to an access to
invalid memory.
Signed-off-by: Ricardo Ribalda <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Chun-Kuang Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
If device_register() fails, it has two issues:
1. The name allocated by dev_set_name() is leaked.
2. The parent of device is not NULL, device_unregister() is called
in zynqmp_ipi_free_mboxes(), it will lead a kernel crash because
of removing not added device.
Call put_device() to give up the reference, so the name is freed in
kobject_cleanup(). Add device registered check in zynqmp_ipi_free_mboxes()
to avoid null-ptr-deref.
Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
Signed-off-by: Yang Yingliang <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Copying platform data to struct cmdq serves to no purpose, as that
data is never modified during runtime: it's worth at this point
storing a pointer to gce_plat in gce and.
Remove all duplicated `struct gce_plat` members from `struct gce`
and reuse the platform data across the driver to save some memory.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Reviewed-by: Chun-Kuang Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
If devm_of_iomap() fails, it returns ERR_PTR() and never
return NULL, so replace NULL pointer check with IS_ERR()
to fix this problem.
Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver")
Signed-off-by: Yang Yingliang <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Add mt8188 compatible name.
Signed-off-by: Elvis Wang <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno<[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Add Global Command Engine(GCE) header file to define the GCE thread priority,
GCE subsys id, event and constant for mt8188.
Signed-off-by: Elvis Wang <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno<[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Some services explicitly return an error code in their response, but
others rely on the system controller to set a status in its status
register. The meaning of the bits varies based on what service is
requested, so pass it back up to the driver that requested the service
in the first place. The field in the message struct already existed, but
was unused until now.
If the system controller is busy, in which case we should never actually
be in the interrupt handler, or if the service fails the mailbox itself
should not be read. Callers should check the status before operating on
the response.
There's an existing, but unused, #define for the mailbox mask - but it
was incorrect. It was doing a GENMASK_ULL(32, 16) which should've just
been a GENMASK(31, 16), so fix that up and start using it.
Fixes: 83d7b1560810 ("mbox: add polarfire soc system controller mailbox")
Signed-off-by: Conor Dooley <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
add MT8186 cmdq support
Signed-off-by: Yongqiang Niu <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: CK Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
add gce ddr enable control flow when gce suspend/resume
when all cmdq instruction task has been processed done,
we need set this gce ddr enable to disable status to tell
cmdq hardware gce there is none task need process, and the hardware
can go into idle mode and no access ddr anymore, then the spm can go
into suspend.
the original issue is gce still access ddr when cmdq suspend function
call, but there is no task run.
so, we need control gce access ddr with this flow.
when cmdq suspend function, there is no task need process, we can
disable gce access ddr, to make sure system go into suspend success.
Signed-off-by: Yongqiang Niu <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: CK Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
if gce work control by software, we need set software enable
for MT8186 Soc
there is a handshake flow between gce and ddr hardware,
if not set ddr enable flag of gce, ddr will fall into idle
mode, then gce instructions will not process done.
we need set this flag of gce to tell ddr when gce is idle or busy
controlled by software flow.
0x48[2:0] means control by software
0x48[18:16] means ddr enable
0x48[2:0] is pre-condition of 0x48[18:16].
if we want set 0x48[18:16] ddr enable, 0x48[2:0] must be set at same
time.
and only these bits is useful, other bits is useless bits
Signed-off-by: Yongqiang Niu <[email protected]>
Reviewed-by: CK Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Use GCE_CTRL_BY_SW definition instead of number
Signed-off-by: Yongqiang Niu <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: CK Hu <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Directly get the match data with device_get_match_data().
Signed-off-by: ye xingchen <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Document the sc8280xp compatible, and at the same time also make sure
the list is sorted alphabetically.
Signed-off-by: Luca Weiss <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Defaulting the build to ARCH_K3 for the TI message manager driver.
Signed-off-by: Nicolas Frayer <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Enable SM4250 APCS IPC support by adding the compatible.
It reuses msm8994_apcs_data.
Signed-off-by: Bhupesh Sharma <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Add compatible for the Qualcomm SM4250 APCS block.
Signed-off-by: Bhupesh Sharma <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
|
|
Fix those make warnings:
arch/parisc/kernel/vdso32/Makefile:30: FORCE prerequisite is missing
arch/parisc/kernel/vdso64/Makefile:30: FORCE prerequisite is missing
Add the missing FORCE prerequisites for all build targets identified by
"make help".
Fixes: e1f86d7b4b2a5213 ("kbuild: warn if FORCE is missing for if_changed(_dep,_rule) and filechk")
Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # 5.18+
|
|
Signed-off-by: Helge Deller <[email protected]>
|
|
No need to have specific locking for console I/O since
the PDC functions provide an own locking.
Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # 6.1+
|
|
The kgdb console is already implemented and registered in pdc_cons.c,
so the duplicate code can be dropped.
Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # 6.1+
|
|
Utilize pdc_lock spinlock to protect parallel modifications of the
iodc_dbuf[] buffer, check length to prevent buffer overflow of
iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong
indentings.
Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # 6.0+
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2022-12-15 (igc)
Muhammad Husaini Zulkifli says:
This patch series fixes bugs for the Time-Sensitive Networking(TSN)
Qbv Scheduling features.
An overview of each patch series is given below:
Patch 1: Using a first flag bit to schedule a packet to the next cycle if
packet cannot fit in current Qbv cycle.
Patch 2: Enable strict cycle for Qbv scheduling.
Patch 3: Prevent user to set basetime less than zero during tc config.
Patch 4: Allow the basetime enrollment with zero value.
Patch 5: Calculate the new end time value to exclude the time interval that
exceed the cycle time as user can specify the cycle time in tc config.
Patch 6: Resolve the HW bugs where the gate is not fully closed.
---
This contains the net patches from this original pull request:
https://lore.kernel.org/netdev/[email protected]/
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
It's quite possible that we got woken up because task_work was queued,
and we need to process this task_work to generate the events waited for.
If we return to the wait loop without running task_work, we'll end up
adding the task to the waitqueue again, only to call
io_cqring_wait_schedule() again which will run the task_work. This is
less efficient than it could be, as it requires adding to the cq_wait
queue again. It also triggers the wakeup path for completions as
cq_wait is now non-empty with the task itself, and it'll require another
lock grab and deletion to remove ourselves from the waitqueue.
Signed-off-by: Jens Axboe <[email protected]>
|
|
The rcu_poll_gp_seq_end() and rcu_poll_gp_seq_end_unlocked() both check
that interrupts are enabled, as they normally should be when waiting for
an RCU grace period. Except that it is legal to wait for grace periods
during early boot, before interrupts have been enabled for the first time,
and polling for grace periods is required to work during this time.
This can result in false-positive lockdep splats in the presence of
boot-time-initiated tracing.
This commit therefore conditions those interrupts-enabled checks on
rcu_scheduler_active having advanced past RCU_SCHEDULER_INACTIVE, by
which time interrupts have been enabled.
Reported-by: Steven Rostedt <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Tested-by: Steven Rostedt (Google) <[email protected]>
|
|
PMD_SHIFT isn't defined if CONFIG_PGTABLE_LEVELS == 3, and as
such the kernel test robot found this warning:
In file included from include/linux/pgtable.h:6,
from arch/parisc/kernel/head.S:23:
arch/parisc/include/asm/pgtable.h:169:32: warning: "PMD_SHIFT" is not defined, evaluates to 0 [-Wundef]
169 | #if (KERNEL_INITIAL_ORDER) >= (PMD_SHIFT)
Avoid the warning by using PLD_SHIFT and BITS_PER_PTE.
Signed-off-by: Helge Deller <[email protected]>
Reported-by: kernel test robot <[email protected]>
Cc: <[email protected]> # 6.0+
|
|
Adjust some MADV_XXX constants to be in sync what their values are on
all other platforms. There is currently no reason to have an own
numbering on parisc, but it requires workarounds in many userspace
sources (e.g. glibc, qemu, ...) - which are often forgotten and thus
introduce bugs and different behaviour on parisc.
A wrapper avoids an ABI breakage for existing userspace applications by
translating any old values to the new ones, so this change allows us to
move over all programs to the new ABI over time.
Signed-off-by: Helge Deller <[email protected]>
|
|
start_task() calls create_singlethread_workqueue() and not checked the
ret value, which may return NULL. And a null-ptr-deref may happen:
start_task()
create_singlethread_workqueue() # failed, led_wq is NULL
queue_delayed_work()
queue_delayed_work_on()
__queue_delayed_work() # warning here, but continue
__queue_work() # access wq->flags, null-ptr-deref
Check the ret value and return -ENOMEM if it is NULL.
Fixes: 3499495205a6 ("[PARISC] Use work queue in LED/LCD driver instead of tasklet.")
Signed-off-by: Shang XiaoJing <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]>
|
|
Use task_work_pending() as a better test for whether we have task_work
or not, TIF_NOTIFY_SIGNAL is only valid if the any of the task_work
items had been queued with TWA_SIGNAL as the notification mechanism.
Hence task_work_pending() is a more reliable check.
Signed-off-by: Jens Axboe <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm updates from Dave Hansen:
"New Feature:
- Randomize the per-cpu entry areas
Cleanups:
- Have CR3_ADDR_MASK use PHYSICAL_PAGE_MASK instead of open coding it
- Move to "native" set_memory_rox() helper
- Clean up pmd_get_atomic() and i386-PAE
- Remove some unused page table size macros"
* tag 'x86_mm_for_6.2_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (35 commits)
x86/mm: Ensure forced page table splitting
x86/kasan: Populate shadow for shared chunk of the CPU entry area
x86/kasan: Add helpers to align shadow addresses up and down
x86/kasan: Rename local CPU_ENTRY_AREA variables to shorten names
x86/mm: Populate KASAN shadow for entire per-CPU range of CPU entry area
x86/mm: Recompute physical address for every page of per-CPU CEA mapping
x86/mm: Rename __change_page_attr_set_clr(.checkalias)
x86/mm: Inhibit _PAGE_NX changes from cpa_process_alias()
x86/mm: Untangle __change_page_attr_set_clr(.checkalias)
x86/mm: Add a few comments
x86/mm: Fix CR3_ADDR_MASK
x86/mm: Remove P*D_PAGE_MASK and P*D_PAGE_SIZE macros
mm: Convert __HAVE_ARCH_P..P_GET to the new style
mm: Remove pointless barrier() after pmdp_get_lockless()
x86/mm/pae: Get rid of set_64bit()
x86_64: Remove pointless set_64bit() usage
x86/mm/pae: Be consistent with pXXp_get_and_clear()
x86/mm/pae: Use WRITE_ONCE()
x86/mm/pae: Don't (ab)use atomic64
mm/gup: Fix the lockless PMD access
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms
Pull MSI fixes from Marc Zyngier:
"Thomas tasked me with sending out a few urgent fixes after the giant
MSI rework that landed in 6.2, as both s390 and powerpc ended-up
suffering from it (they do not use the full core code infrastructure,
leading to these previously undetected issues):
- Return MSI_XA_DOMAIN_SIZE as the maximum MSI index when the
architecture does not make use of irq domains instead of returning
0, which is pretty limiting.
- Check for the presence of an irq domain when validating the MSI
iterator, as s390/powerpc won't have one.
- Fix powerpc's MSI backends which fail to clear the descriptor's IRQ
field on teardown, leading to a splat and leaked descriptors"
* tag 'msi-fixes-6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms:
powerpc/msi: Fix deassociation of MSI descriptors
genirq/msi: Return MSI_XA_DOMAIN_SIZE as the maximum MSI index when no domain is present
genirq/msi: Check for the presence of an irq domain when validating msi_ctrl
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi
Pull HSI updates from Sebastian Reichel:
- misc small fixes
* tag 'hsi-for-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi:
HSI: omap_ssi_core: Fix error handling in ssi_init()
headers: Remove some left-over license text in include/uapi/linux/hsi/
HSI: omap_ssi_core: fix possible memory leak in ssi_probe()
HSI: omap_ssi_core: fix unbalanced pm_runtime_disable()
HSI: ssi_protocol: Fix return type of ssip_pn_xmit()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply and reset updates from Sebastian Reichel:
- bq25890: add charge voltage/current support
- bd99954: convert to linear range
- convert all i2c drivers to use probe_new
- misc fixes and cleanups
* tag 'for-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (51 commits)
power: supply: fix null pointer dereferencing in power_supply_get_battery_info
power: supply: bq25890: Fix usb-notifier probe and remove races
power: supply: bq25890: Ensure pump_express_work is cancelled on remove
power: supply: Fix refcount leak in rk817_charger_probe
power: supply: bq25890: Only use pdata->regulator_init_data for vbus
power: supply: ab8500: Fix error handling in ab8500_charger_init()
power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()
power: supply: z2_battery: Fix possible memleak in z2_batt_probe()
power: supply: z2_battery: Convert to i2c's .probe_new()
power: supply: ucs1002: Convert to i2c's .probe_new()
power: supply: smb347: Convert to i2c's .probe_new()
power: supply: sbs-manager: Convert to i2c's .probe_new()
power: supply: sbs: Convert to i2c's .probe_new()
power: supply: rt9455: Convert to i2c's .probe_new()
power: supply: rt5033_battery: Convert to i2c's .probe_new()
power: supply: max17042_battery: Convert to i2c's .probe_new()
power: supply: max17040: Convert to i2c's .probe_new()
power: supply: max14656: Convert to i2c's .probe_new()
power: supply: ltc4162-l: Convert to i2c's .probe_new()
power: supply: ltc2941: Convert to i2c's .probe_new()
...
|
|
git://www.linux-watchdog.org/linux-watchdog
Pull watchdog updates from Wim Van Sebroeck:
- Add Advantech EC watchdog driver
- Add support for MT6795 Helio X10 watchdog and toprgu
- Add support for MT8188 watchdog device
- Remove #ifdef guards for PM related functions
- Other fixes and improvements
* tag 'linux-watchdog-6.2-rc1' of git://www.linux-watchdog.org/linux-watchdog:
watchdog: aspeed: Enable pre-timeout interrupt
watchdog: iTCO_wdt: Set NO_REBOOT if the watchdog is not already running
watchdog: rn5t618: add support for read out bootstatus
watchdog: kempld: Remove #ifdef guards for PM related functions
watchdog: omap: Remove #ifdef guards for PM related functions
watchdog: twl4030: Remove #ifdef guards for PM related functions
watchdog: at91rm9200: Remove #ifdef guards for PM related functions
watchdog: Add Advantech EC watchdog driver
dt-bindings: watchdog: mediatek,mtk-wdt: Add compatible for MT8173
dt-bindings: watchdog: mediatek,mtk-wdt: Add compatible for MT6795
dt-bindings: watchdog: mediatek: Convert mtk-wdt to json-schema
watchdog: mediatek: mt8188: add wdt support
dt-bindings: reset: mt8188: add toprgu reset-controller header file
dt-bindings: watchdog: Add compatible for MediaTek MT8188
watchdog: mtk_wdt: Add support for MT6795 Helio X10 watchdog and toprgu
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Lee Jones offered his help with maintaining LEDs, thanks a lot.
Plus, there are some bugfixes as a bonus"
* tag 'leds-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: MAINTAINERS: include dt-bindings headers
leds: qcom,pm8058-led: Convert to DT schema
leds: use sysfs_emit() to instead of scnprintf()
leds: is31fl319x: Fix setting current limit for is31fl319{0,1,3}
MAINTAINERS: Add additional co-maintainer to LEDs
leds: lp5523: fix out-of-bounds bug in lp5523_selftest()
dt-bindings: leds: Add 'cpuX' to 'linux,default-trigger'
led: qcom-lpg: Fix sleeping in atomic
leds: max8997: Don't error if there is no pdata
leds: lp55xx: remove variable j
leds-pca955x: Remove the unused function pca95xx_num_led_regs()
|
|
Pull rdma fixes from Jason Gunthorpe:
"Fix two build warnings on 32 bit platforms
It seems the linux-next CI and 0-day bot are not testing enough 32 bit
configurations, as soon as you merged the rdma pull request there were
two instant reports of warnings on these sytems that I would have
thought should have been covered by time in linux-next
Anyhow, here are the fixes so people don't hit problems with -Werror"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/siw: Fix pointer cast warning
RDMA/rxe: Fix compile warnings on 32-bit
|