| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We have a long chain of memory dereferencing just to whether or not
this disk has a special submit_bio helper. As that's not necessarily
the common case, add a bd_has_submit_bio state in the bdev to avoid
traversing this memory dependency chain if we don't need to.
Signed-off-by: Jens Axboe <[email protected]>
|
|
This moves struct device out-of-line as it's just used at open/close
time, so we can keep some of the commonly used fields closer together.
On a standard setup, it also reduces the size from 864 bytes to 848
bytes. Yes, struct device is a pig...
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Backmerging drm-next to sync with msm tree. Resolves a conflict
between aperture-helper changes and msm's use of those interfaces.
Signed-off-by: Thomas Zimmermann <[email protected]>
|
|
As the first step of converting hardcoded blocksize to that specified in
on-disk superblock, convert all call sites of hardcoded blocksize to
sb->s_blocksize except for:
1) use sbi->blkszbits instead of sb->s_blocksize in
erofs_superblock_csum_verify() since sb->s_blocksize has not been
updated with the on-disk blocksize yet when the function is called.
2) use inode->i_blkbits instead of sb->s_blocksize in erofs_bread(),
since the inode operated on may be an anonymous inode in fscache mode.
Currently the anonymous inode is allocated from an anonymous mount
maintained in erofs, while in the near future we may allocate anonymous
inodes from a generic API directly and thus have no access to the
anonymous inode's i_sb. Thus we keep the block size in i_blkbits for
anonymous inodes in fscache mode.
Be noted that this patch only gets rid of the hardcoded blocksize, in
preparation for actually setting the on-disk block size in the following
patch. The hard limit of constraining the block size to PAGE_SIZE still
exists until the next patch.
Signed-off-by: Jingbo Xu <[email protected]>
Reviewed-by: Gao Xiang <[email protected]>
Reviewed-by: Yue Hu <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Gao Xiang: fold a patch to fix incorrect truncated offsets. ]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Gao Xiang <[email protected]>
|
|
We've managed to improve the UX for kptrs significantly over the last 9
months. All of the existing use cases which previously had KF_KPTR_GET
kfuncs (struct bpf_cpumask *, struct task_struct *, and struct cgroup *)
have all been updated to be synchronized using RCU. In other words,
their KF_KPTR_GET kfuncs have been removed in favor of KF_RCU |
KF_ACQUIRE kfuncs, with the pointers themselves also being readable from
maps in an RCU read region thanks to the types being RCU safe.
While KF_KPTR_GET was a logical starting point for kptrs, it's become
clear that they're not the correct abstraction. KF_KPTR_GET is a flag
that essentially does nothing other than enforcing that the argument to
a function is a pointer to a referenced kptr map value. At first glance,
that's a useful thing to guarantee to a kfunc. It gives kfuncs the
ability to try and acquire a reference on that kptr without requiring
the BPF prog to do something like this:
struct kptr_type *in_map, *new = NULL;
in_map = bpf_kptr_xchg(&map->value, NULL);
if (in_map) {
new = bpf_kptr_type_acquire(in_map);
in_map = bpf_kptr_xchg(&map->value, in_map);
if (in_map)
bpf_kptr_type_release(in_map);
}
That's clearly a pretty ugly (and racy) UX, and if using KF_KPTR_GET is
the only alternative, it's better than nothing. However, the problem
with any KF_KPTR_GET kfunc lies in the fact that it always requires some
kind of synchronization in order to safely do an opportunistic acquire
of the kptr in the map. This is because a BPF program running on another
CPU could do a bpf_kptr_xchg() on that map value, and free the kptr
after it's been read by the KF_KPTR_GET kfunc. For example, the
now-removed bpf_task_kptr_get() kfunc did the following:
struct task_struct *bpf_task_kptr_get(struct task_struct **pp)
{
struct task_struct *p;
rcu_read_lock();
p = READ_ONCE(*pp);
/* If p is non-NULL, it could still be freed by another CPU,
* so we have to do an opportunistic refcount_inc_not_zero()
* and return NULL if the task will be freed after the
* current RCU read region.
*/
|f (p && !refcount_inc_not_zero(&p->rcu_users))
p = NULL;
rcu_read_unlock();
return p;
}
In other words, the kfunc uses RCU to ensure that the task remains valid
after it's been peeked from the map. However, this is completely
redundant with just defining a KF_RCU kfunc that itself does a
refcount_inc_not_zero(), which is exactly what bpf_task_acquire() now
does.
So, the question of whether KF_KPTR_GET is useful is actually, "Are
there any synchronization mechanisms / safety flags that are required by
certain kptrs, but which are not provided by the verifier to kfuncs?"
The answer to that question today is "No", because every kptr we
currently care about is RCU protected.
Even if the answer ever became "yes", the proper way to support that
referenced kptr type would be to add support for whatever
synchronization mechanism it requires in the verifier, rather than
giving kfuncs a flag that says, "Here's a pointer to a referenced kptr
in a map, do whatever you need to do."
With all that said -- so as to allow us to consolidate the kfunc API,
and simplify the verifier a bit, this patch removes KF_KPTR_GET, and all
relevant logic from the verifier.
Signed-off-by: David Vernet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The syscall user dispatch configuration can only be set by the task itself,
but lacks a ptrace set/get interface which makes it impossible to implement
checkpoint/restore for it.
Add the required ptrace requests and the get/set functions in the syscall
user dispatch code to make that possible.
Signed-off-by: Gregory Price <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The hardware for gma500 is different from the rest, as it uses stolen
framebuffer memory that is not available via PCI BAR. The regular PCI
removal helper cannot detect the framebuffer, while the non-PCI helper
misses possible conflicting VGA devices (i.e., a framebuffer or text
console).
Gma500 therefore calls both helpers to catch all cases. It's confusing
as it implies that there's something about the PCI device that requires
ownership management. The relationship between the PCI device and the
VGA devices is non-obvious. At worst, readers might assume that calling
two functions for clearing aperture ownership is a bug in the driver.
Hence, move the PCI removal helper's code for VGA functionality into
a separate function and call this function from gma500. Documents the
purpose of each call to aperture helpers. The change contains comments
and example code form the discussion at [1].
v5:
* fix grammar in gma500 comment (Javier)
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ # 1
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With the preceding patches it's become defunct. Also I'm about to add
a different boolean argument, so it's better to keep the confusion
down to the absolute minimum.
v2: Since the hypervfb patch got droppped (it's only a pci device for
gen1 vm, not for gen2) there is one leftover user in an actual driver
left to touch.
v4:
- fixes to commit message
- fix Daniel's S-o-b address
v5:
- add back an S-o-b tag with Daniel's Intel address
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: [email protected]
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: "K. Y. Srinivasan" <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Cc: Wei Liu <[email protected]>
Cc: Dexuan Cui <[email protected]>
Cc: [email protected]
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Only really pci devices have a business setting this - it's for
figuring out whether the legacy vga stuff should be nuked too. And
with the preceding two patches those are all using the pci version of
this.
Which means for all other callers primary == false and we can remove
it now.
v2:
- Reorder to avoid compile fail (Thomas)
- Include gma500, which retained it's called to the non-pci version.
v4:
- fix Daniel's S-o-b address
v5:
- add back an S-o-b tag with Daniel's Intel address
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Deepak Rawat <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Jerome Brunet <[email protected]>
Cc: Martin Blumenstingl <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Jonathan Hunter <[email protected]>
Cc: Emma Anholt <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Acked-by: Martin Blumenstingl <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rename existing HCA capability relaxed_ordering_read to
relaxed_ordering_read_pci_enabled. This is in accordance with recent PRM
change to better describe the capability, as it's set only if both the
device supports relaxed ordering (RO) read and RO is enabled in PCI
config space.
In addition, add new HCA capability relaxed_ordering_read which is set
if the device supports RO read, regardless of RO in PCI config space.
This will be used in the following patch to allow RO in VFs and VMs.
Signed-off-by: Avihai Horon <[email protected]>
Reviewed-by: Shay Drory <[email protected]>
Link: https://lore.kernel.org/r/caa0002fd8135086357dfcc368e2f5cc73b08480.1681131553.git.leon@kernel.org
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
|
|
Make it clearer what is going on by adding a function to go back from the
"virtual" dma_addr to a kva and another to a struct page. This is used in the
ib_uses_virt_dma() style drivers (siw, rxe, hfi, qib).
Call them instead of a naked casting and virt_to_page() when working with dma_addr
values encoded by the various ib_map functions.
This also fixes the virt_to_page() casting problem Linus Walleij has been
chasing.
Cc: Linus Walleij <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
|
|
swiotlb currently reports the total number of slabs and the instantaneous
in-use slabs in debugfs. But with increased usage of swiotlb for all I/O
in Confidential Computing (coco) VMs, it has become difficult to know
how much memory to allocate for swiotlb bounce buffers, either via the
automatic algorithm in the kernel or by specifying a value on the
kernel boot line. The current automatic algorithm generously allocates
swiotlb bounce buffer memory, and may be wasting significant memory in
many use cases.
To support better understanding of swiotlb usage, add tracking of the
the high water mark for usage of the default swiotlb bounce buffer memory
pool and any reserved memory pools. Report these high water marks in
debugfs along with the other swiotlb pool metrics. Allow the high water
marks to be reset to zero at runtime by writing to them.
Signed-off-by: Michael Kelley <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
All btf_fields in an object are 0-initialized by memset in
bpf_obj_init. This might not be a valid initial state for some field
types, in which case kfuncs that use the type will properly initialize
their input if it's been 0-initialized. Some BPF graph collection types
and kfuncs do this: bpf_list_{head,node} and bpf_rb_node.
An earlier patch in this series added the bpf_refcount field, for which
the 0 state indicates that the refcounted object should be free'd.
bpf_obj_init treats this field specially, setting refcount to 1 instead
of relying on scattered "refcount is 0? Must have just been initialized,
let's set to 1" logic in kfuncs.
This patch extends this treatment to list and rbtree field types,
allowing most scattered initialization logic in kfuncs to be removed.
Note that bpf_{list_head,rb_root} may be inside a BPF map, in which case
they'll be 0-initialized without passing through the newly-added logic,
so scattered initialization logic must remain for these collection root
types.
Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
Consider this code snippet:
struct node {
long key;
bpf_list_node l;
bpf_rb_node r;
bpf_refcount ref;
}
int some_bpf_prog(void *ctx)
{
struct node *n = bpf_obj_new(/*...*/), *m;
bpf_spin_lock(&glock);
bpf_rbtree_add(&some_tree, &n->r, /* ... */);
m = bpf_refcount_acquire(n);
bpf_rbtree_add(&other_tree, &m->r, /* ... */);
bpf_spin_unlock(&glock);
/* ... */
}
After bpf_refcount_acquire, n and m point to the same underlying memory,
and that node's bpf_rb_node field is being used by the some_tree insert,
so overwriting it as a result of the second insert is an error. In order
to properly support refcounted nodes, the rbtree and list insert
functions must be allowed to fail. This patch adds such support.
The kfuncs bpf_rbtree_add, bpf_list_push_{front,back} are modified to
return an int indicating success/failure, with 0 -> success, nonzero ->
failure.
bpf_obj_drop on failure
=======================
Currently the only reason an insert can fail is the example above: the
bpf_{list,rb}_node is already in use. When such a failure occurs, the
insert kfuncs will bpf_obj_drop the input node. This allows the insert
operations to logically fail without changing their verifier owning ref
behavior, namely the unconditional release_reference of the input
owning ref.
With insert that always succeeds, ownership of the node is always passed
to the collection, since the node always ends up in the collection.
With a possibly-failed insert w/ bpf_obj_drop, ownership of the node
is always passed either to the collection (success), or to bpf_obj_drop
(failure). Regardless, it's correct to continue unconditionally
releasing the input owning ref, as something is always taking ownership
from the calling program on insert.
Keeping owning ref behavior unchanged results in a nice default UX for
insert functions that can fail. If the program's reaction to a failed
insert is "fine, just get rid of this owning ref for me and let me go
on with my business", then there's no reason to check for failure since
that's default behavior. e.g.:
long important_failures = 0;
int some_bpf_prog(void *ctx)
{
struct node *n, *m, *o; /* all bpf_obj_new'd */
bpf_spin_lock(&glock);
bpf_rbtree_add(&some_tree, &n->node, /* ... */);
bpf_rbtree_add(&some_tree, &m->node, /* ... */);
if (bpf_rbtree_add(&some_tree, &o->node, /* ... */)) {
important_failures++;
}
bpf_spin_unlock(&glock);
}
If we instead chose to pass ownership back to the program on failed
insert - by returning NULL on success or an owning ref on failure -
programs would always have to do something with the returned ref on
failure. The most likely action is probably "I'll just get rid of this
owning ref and go about my business", which ideally would look like:
if (n = bpf_rbtree_add(&some_tree, &n->node, /* ... */))
bpf_obj_drop(n);
But bpf_obj_drop isn't allowed in a critical section and inserts must
occur within one, so in reality error handling would become a
hard-to-parse mess.
For refcounted nodes, we can replicate the "pass ownership back to
program on failure" logic with this patch's semantics, albeit in an ugly
way:
struct node *n = bpf_obj_new(/* ... */), *m;
bpf_spin_lock(&glock);
m = bpf_refcount_acquire(n);
if (bpf_rbtree_add(&some_tree, &n->node, /* ... */)) {
/* Do something with m */
}
bpf_spin_unlock(&glock);
bpf_obj_drop(m);
bpf_refcount_acquire is used to simulate "return owning ref on failure".
This should be an uncommon occurrence, though.
Addition of two verifier-fixup'd args to collection inserts
===========================================================
The actual bpf_obj_drop kfunc is
bpf_obj_drop_impl(void *, struct btf_struct_meta *), with bpf_obj_drop
macro populating the second arg with 0 and the verifier later filling in
the arg during insn fixup.
Because bpf_rbtree_add and bpf_list_push_{front,back} now might do
bpf_obj_drop, these kfuncs need a btf_struct_meta parameter that can be
passed to bpf_obj_drop_impl.
Similarly, because the 'node' param to those insert functions is the
bpf_{list,rb}_node within the node type, and bpf_obj_drop expects a
pointer to the beginning of the node, the insert functions need to be
able to find the beginning of the node struct. A second
verifier-populated param is necessary: the offset of {list,rb}_node within the
node type.
These two new params allow the insert kfuncs to correctly call
__bpf_obj_drop_impl:
beginning_of_node = bpf_rb_node_ptr - offset
if (already_inserted)
__bpf_obj_drop_impl(beginning_of_node, btf_struct_meta->record);
Similarly to other kfuncs with "hidden" verifier-populated params, the
insert functions are renamed with _impl prefix and a macro is provided
for common usage. For example, bpf_rbtree_add kfunc is now
bpf_rbtree_add_impl and bpf_rbtree_add is now a macro which sets
"hidden" args to 0.
Due to the two new args BPF progs will need to be recompiled to work
with the new _impl kfuncs.
This patch also rewrites the "hidden argument" explanation to more
directly say why the BPF program writer doesn't need to populate the
arguments with anything meaningful.
How does this new logic affect non-owning references?
=====================================================
Currently, non-owning refs are valid until the end of the critical
section in which they're created. We can make this guarantee because, if
a non-owning ref exists, the referent was added to some collection. The
collection will drop() its nodes when it goes away, but it can't go away
while our program is accessing it, so that's not a problem. If the
referent is removed from the collection in the same CS that it was added
in, it can't be bpf_obj_drop'd until after CS end. Those are the only
two ways to free the referent's memory and neither can happen until
after the non-owning ref's lifetime ends.
On first glance, having these collection insert functions potentially
bpf_obj_drop their input seems like it breaks the "can't be
bpf_obj_drop'd until after CS end" line of reasoning. But we care about
the memory not being _freed_ until end of CS end, and a previous patch
in the series modified bpf_obj_drop such that it doesn't free refcounted
nodes until refcount == 0. So the statement can be more accurately
rewritten as "can't be free'd until after CS end".
We can prove that this rewritten statement holds for any non-owning
reference produced by collection insert functions:
* If the input to the insert function is _not_ refcounted
* We have an owning reference to the input, and can conclude it isn't
in any collection
* Inserting a node in a collection turns owning refs into
non-owning, and since our input type isn't refcounted, there's no
way to obtain additional owning refs to the same underlying
memory
* Because our node isn't in any collection, the insert operation
cannot fail, so bpf_obj_drop will not execute
* If bpf_obj_drop is guaranteed not to execute, there's no risk of
memory being free'd
* Otherwise, the input to the insert function is refcounted
* If the insert operation fails due to the node's list_head or rb_root
already being in some collection, there was some previous successful
insert which passed refcount to the collection
* We have an owning reference to the input, it must have been
acquired via bpf_refcount_acquire, which bumped the refcount
* refcount must be >= 2 since there's a valid owning reference and the
node is already in a collection
* Insert triggering bpf_obj_drop will decr refcount to >= 1, never
resulting in a free
So although we may do bpf_obj_drop during the critical section, this
will never result in memory being free'd, and no changes to non-owning
ref logic are needed in this patch.
Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
A local kptr is considered 'refcounted' when it is of a type that has a
bpf_refcount field. When such a kptr is created, its refcount should be
initialized to 1; when destroyed, the object should be free'd only if a
refcount decr results in 0 refcount.
Existing logic always frees the underlying memory when destroying a
local kptr, and 0-initializes all btf_record fields. This patch adds
checks for "is local kptr refcounted?" and new logic for that case in
the appropriate places.
This patch focuses on changing existing semantics and thus conspicuously
does _not_ provide a way for BPF programs in increment refcount. That
follows later in the series.
__bpf_obj_drop_impl is modified to do the right thing when it sees a
refcounted type. Container types for graph nodes (list, tree, stashed in
map) are migrated to use __bpf_obj_drop_impl as a destructor for their
nodes instead of each having custom destruction code in their _free
paths. Now that "drop" isn't a synonym for "free" when the type is
refcounted it makes sense to centralize this logic.
Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
A 'struct bpf_refcount' is added to the set of opaque uapi/bpf.h types
meant for use in BPF programs. Similarly to other opaque types like
bpf_spin_lock and bpf_rbtree_node, the verifier needs to know where in
user-defined struct types a bpf_refcount can be located, so necessary
btf_record plumbing is added to enable this. bpf_refcount is sized to
hold a refcount_t.
Similarly to bpf_spin_lock, the offset of a bpf_refcount is cached in
btf_record as refcount_off in addition to being in the field array.
Caching refcount_off makes sense for this field because further patches
in the series will modify functions that take local kptrs (e.g.
bpf_obj_drop) to change their behavior if the type they're operating on
is refcounted. So enabling fast "is this type refcounted?" checks is
desirable.
No such verifier behavior changes are introduced in this patch, just
logic to recognize 'struct bpf_refcount' in btf_record.
Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The btf_field_offs struct contains (offset, size) for btf_record fields,
sorted by offset. btf_field_offs is always used in conjunction with
btf_record, which has btf_field 'fields' array with (offset, type), the
latter of which btf_field_offs' size is derived from via
btf_field_type_size.
This patch adds a size field to struct btf_field and sorts btf_record's
fields by offset, making it possible to get rid of btf_field_offs. Less
data duplication and less code complexity results.
Since btf_field_offs' lifetime closely followed the btf_record used to
populate it, most complexity wins are from removal of initialization
code like:
if (btf_record_successfully_initialized) {
foffs = btf_parse_field_offs(rec);
if (IS_ERR_OR_NULL(foffs))
// free the btf_record and return err
}
Other changes in this patch are pretty mechanical:
* foffs->field_off[i] -> rec->fields[i].offset
* foffs->field_sz[i] -> rec->fields[i].size
* Sort rec->fields in btf_parse_fields before returning
* It's possible that this is necessary independently of other
changes in this patch. btf_record_find in syscall.c expects
btf_record's fields to be sorted by offset, yet there's no
explicit sorting of them before this patch, record's fields are
populated in the order they're read from BTF struct definition.
BTF docs don't say anything about the sortedness of struct fields.
* All functions taking struct btf_field_offs * input now instead take
struct btf_record *. All callsites of these functions already have
access to the correct btf_record.
Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
Instead of waiting for rsrc_data->refs to be downed to zero, check
whether there are rsrc nodes queued for completion, that's easier then
maintaining references.
Signed-off-by: Pavel Begunkov <[email protected]>
Link: https://lore.kernel.org/r/8e33fd143d83e11af3e386aea28eb6d6c6a1be10.1681395792.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <[email protected]>
|
|
Replace completions with waitqueues for rsrc data quiesce, the main
wakeup condition is when data refs hit zero. Note that data refs are
only changes under ->uring_lock, so we prepare before mutex_unlock()
reacquire it after taking the lock back. This change will be needed
in the next patch.
Signed-off-by: Pavel Begunkov <[email protected]>
Link: https://lore.kernel.org/r/1d0dbc74b3b4fd67c8f01819e680c5e0da252956.1681395792.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <[email protected]>
|
|
The sr030pc30 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v2.6.37. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The s5k6aa camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.11. The driver hasn't
been used since them. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The noon010pc30 camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.16. A device tree file
referencing the device has been added in v3.17, but without
corresponding DT bindings, and with DT support in the driver. The driver
thus hasn't been used since v316. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The mt9t001 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.2. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The mt9m032 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.4. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The m5mols camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.11. The driver hasn't
been used since them. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The ad9389b video encoder driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.7. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Hans Verkuil <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Tasklets are supposed to finish their work quickly and should not block the
current running process, but it is not guaranteed that they do so.
Currently softirq_entry/exit can be used to analyse the total tasklets
execution time, but that's not helpful to track individual tasklets
execution time. That makes it hard to identify tasklet functions, which
take more time than expected.
Add tasklet_entry/exit trace point support to track individual tasklet
execution.
Trivial usage example:
# echo 1 > /sys/kernel/debug/tracing/events/irq/tasklet_entry/enable
# echo 1 > /sys/kernel/debug/tracing/events/irq/tasklet_exit/enable
# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 4/4 #P:4
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
<idle>-0 [003] ..s1. 314.011428: tasklet_entry: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func
<idle>-0 [003] ..s1. 314.011432: tasklet_exit: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func
<idle>-0 [003] ..s1. 314.017369: tasklet_entry: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func
<idle>-0 [003] ..s1. 314.017371: tasklet_exit: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func
Signed-off-by: Lingutla Chandrasekhar <[email protected]>
Signed-off-by: J. Avila <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Steven Rostedt (Google) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[elavila: Port to android-mainline]
[jstultz: Rebased to upstream, cut unused trace points, added
comments for the tracepoints, reworded commit]
|
|
ABGR64_12 is a reversed RGB format with alpha channel last,
12 bits per component like ABGR32,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
BGR48_12 is a reversed RGB format with 12 bits per component like BGR24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
YUV48_12 is a YUV format with 12-bits per component like YUV24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
[hverkuil: replaced a . by ,]
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Y012 is a luma-only formats with 12-bits per pixel,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
P012 is a YUV format with 12-bits per component with interleaved UV,
like NV12, expanded to 16 bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
And P012M has two non contiguous planes.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Add new ioctls to set and get subdev client capabilities. Client in this
context means the userspace application which opens the subdev device
node. The client capabilities are stored in the file handle of the
opened subdev device node, and the client must set the capabilities for
each opened subdev.
For now we only add a single flag, V4L2_SUBDEV_CLIENT_CAP_STREAMS, which
indicates that the client is streams-aware.
The reason for needing such a flag is as follows:
Many structs passed via ioctls, e.g. struct v4l2_subdev_format, contain
reserved fields (usually a single array field). These reserved fields
can be used to extend the ioctl. The userspace is required to zero the
reserved fields.
We recently added a new 'stream' field to many of these structs, and the
space for the field was taken from these reserved arrays. The assumption
was that these new 'stream' fields are always initialized to zero if the
userspace does not use them. This was a mistake, as, as mentioned above,
the userspace is required to zero the _reserved_ fields. In other words,
there is no requirement to zero this new stream field, and if the
userspace doesn't use the field (which is the case for all userspace
applications at the moment), the field may contain random data.
This shows that the way the reserved fields are defined in v4l2 is, in
my opinion, somewhat broken, but there is nothing to do about that.
To fix this issue we need a way for the userspace to tell the kernel
that the userspace has indeed set the 'stream' field, and it's fine for
the kernel to access it. This is achieved with the new ioctl, which the
userspace should usually use right after opening the subdev device node.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Convert this driver from the old videobuf framework to the vb2
frame.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Use the video_fmt in saa7146_vv instead of having a pointer
to it in struct saa7146_buf.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Instead use vv->resources and video_drvdata(file) to
obtain this information.
This prepares for the vb2 conversion later when saa7146_fh is
dropped completely.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Recent patches to mlx5 mentioned a regression when moving from
driver local page pool to only using the generic page pool code.
Page pool has two recycling paths (1) direct one, which runs in
safe NAPI context (basically consumer context, so producing
can be lockless); and (2) via a ptr_ring, which takes a spin
lock because the freeing can happen from any CPU; producer
and consumer may run concurrently.
Since the page pool code was added, Eric introduced a revised version
of deferred skb freeing. TCP skbs are now usually returned to the CPU
which allocated them, and freed in softirq context. This places the
freeing (producing of pages back to the pool) enticingly close to
the allocation (consumer).
If we can prove that we're freeing in the same softirq context in which
the consumer NAPI will run - lockless use of the cache is perfectly fine,
no need for the lock.
Let drivers link the page pool to a NAPI instance. If the NAPI instance
is scheduled on the same CPU on which we're freeing - place the pages
in the direct cache.
With that and patched bnxt (XDP enabled to engage the page pool, sigh,
bnxt really needs page pool work :() I see a 2.6% perf boost with
a TCP stream test (app on a different physical core than softirq).
The CPU use of relevant functions decreases as expected:
page_pool_refill_alloc_cache 1.17% -> 0%
_raw_spin_lock 2.41% -> 0.98%
Only consider lockless path to be safe when NAPI is scheduled
- in practice this should cover majority if not all of steady state
workloads. It's usually the NAPI kicking in that causes the skb flush.
The main case we'll miss out on is when application runs on the same
CPU as NAPI. In that case we don't use the deferred skb free path.
Reviewed-by: Tariq Toukan <[email protected]>
Acked-by: Jesper Dangaard Brouer <[email protected]>
Tested-by: Dragos Tatulea <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into soc/drivers
mtk-svs:
smaller coding style changes
mtk-mutex:
- add support for mt8365 display and mt8195 VPP mutex
- add support for more then 32 mods
- use module_platform_driver instead of open coding
mtk-mmsys:
- add support for mt8195 RSZ switching
- add remove function
- use module_platform_driver instead of open coding
- split out mt8173 routing table from the legacy table
- bump up resets in mt8173 to 64
- add support for mt6795 (Helio X10)
- clean-up IS_REACHABLE code for cmdq
* tag 'v6.3-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: (25 commits)
soc: mediatek: Kconfig: Add MTK_CMDQ dependency to MTK_MMSYS
soc: mediatek: mutex: Use dev_err_probe()
soc: mediatek: mtk-mmsys: Add support for MT6795 Helio X10
soc: mediatek: mtk-mmsys: Change MT8173 num_resets to 64
soc: mediatek: mtk-mmsys: Split out MT8173 mmsys DDP routing table
soc: mediatek: Cleanup ifdefs for IS_REACHABLE(CONFIG_MTK_CMDQ)
soc: mediatek: cmdq: Add inline functions for !CONFIG_MTK_CMDQ
soc: mediatek: mtk-mutex: Use module_platform_driver() macro
soc: mediatek: mtk-mutex: Replace max handles number with definition
soc: mediatek: mtk-mutex: Compress of_device_id array entries
soc: mediatek: mtk-mmsys: Add MODULE_DEVICE_TABLE() to allow auto-load
soc: mediatek: mtk-mmsys: Compress of_device_id array entries
soc: mediatek: mtk-mmsys: Use module_platform_driver() macro
soc: mediatek: mtk-mmsys: Add .remove() callback
dt-bindings: soc: mediatek: add display mutex for MT8365 SoC
dt-bindings: soc: mediatek: specify which compatible requires clocks property
soc: mediatek: mtk-svs: add thermal voltage compensation if needed
soc: mediatek: mtk-svs: fix passing zero to 'PTR_ERR'
soc: mediatek: mtk-svs: delete node name check
soc: mediatek: mutex: support MT8195 VPPSYS
...
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Address minor omissions from kdoc for ops structures flagged by check-kdoc:
./scripts/kernel-doc -Werror -none include/linux/vfio.h
include/linux/vfio.h:114: warning: Function parameter or member 'name' not described in 'vfio_device_ops'
include/linux/vfio.h:143: warning: Cannot understand * @migration_set_state: Optional callback to change the migration state for
on line 143 - I thought it was a doc line
include/linux/vfio.h:168: warning: Cannot understand * @log_start: Optional callback to ask the device start DMA logging.
on line 168 - I thought it was a doc line
Signed-off-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alex Williamson <[email protected]>
|
|
There are no dm_get_queue_limits() callers outside of DM core and
there shouldn't be.
Also, remove its BUG_ON(!atomic_read(&md->holders)) to micro-optimize
__process_abnormal_io().
Signed-off-by: Mike Snitzer <[email protected]>
|
|
Introduce max_write_zeroes_granularity and
max_secure_erase_granularity flags in the dm_target struct.
If a target sets these then DM core will split IO of these operation
types accordingly (in terms of max_write_zeroes_sectors and
max_secure_erase_sectors respectively).
Signed-off-by: Mike Snitzer <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
More Qualcomm ARM64 Devicetree updated for v6.4
Devicetree for the QCM2210/QCM2290 is introduced. Support for the RB1
board is introduced on QRB2210, RB2 on QRB4210, the AL02 board on
IPQ9574, the MI01.6 board is introduced on IPQ5332 and initial support
for Xiaomi Mi A3 is introduced on SM6125.
Support for the output-enable/disable flag is introduced in the
pinctrl-msm driver, and the non-standard "input-enable" is dropped from
a range of platforms.
A wide range of smaller fixes are introduced, based on Devicetree
validation.
MSM8953 gains LPASS, MPSS and Wireless subsystem support.
The iommus property is removed from PCIe nodes in all platforms, as the
only the child devices should be associated with iommu groups, through
the existing iommu-map property.
A few QUP instances are introduced on the IPQ5332 platform, and support
for the MI01.6 board is introduced.
The reserved-memory map on Huawei Nexus 6P is updated with the addition
of splash screen framebuffer memory and adjustment to the reserved
memory region overlapping the smem region.
Regulators are introduces for the SA8775P Ride platform.
A regulator is marked always-on, for correctness, on Trogdor. Pinconf
fixes are introduced to both sc7180 and sc7280 devices. A dedicated
reviewers list is added for boards relevant to the Chromebook engineers.
A set of pinconf fixes are introduced for sc8280xp, labels are
introduced for Soundwire nodes.
The sensor core remoteproc and FastRPC thereon, is introduce in SDM845
and enabled for OnePlus 6/6T and Shift Shift6mq.
RMTFS, remoteprocs, ath10k and ramoops is introduced for the Lenovo Tab
P11.
UFS support is introduced on SM6125.
SM8150 no longer defines the GPU to be in headless mode by default, GPU
speedbins are introduced.
GPU speedbins are introduced for SM8250 as well, as is support for
display on Xiaomi Mi Pad 5 Pro, with two different panels supported.
Soundwire controllers, ADSP audio codec macros and the Inline Crypto
Engine support is added to the SM8550 platform.
* tag 'qcom-arm64-for-6.4-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (85 commits)
arm64: dts: qcom: Add base qrb4210-rb2 board dts
arm64: dts: qcom: sm8550: add Soundwire controllers
arm64: dts: qcom: sm8250: Add GPU speedbin support
arm64: dts: qcom: sm8150: Add GPU speedbin support
arm64: dts: qcom: sm8150: Don't start Adreno in headless mode
arm64: dts: qcom: ipq5332: add support for the RDP468 variant
arm64: dts: qcom: sdm630: move DSI opp-table out of DSI node
arm64: dts: qcom: sm6115p-j606f: Enable ATH10K WiFi
arm64: dts: qcom: sm6115p-j606f: Enable remoteprocs
arm64: dts: qcom: sm6115: Add RMTFS
arm64: dts: qcom: sm6115-j606f: Add ramoops node
arm64: dts: qcom: msm8916-thwc-ufi001c: add function to pin config
arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node
arm64: dts: MSM8953: Add lpass nodes
arm64: dts: MSM8953: Add mpss nodes
arm64: dts: MSM8953: Add wcnss nodes
arm64: dts: qcom: sm8350: remove superfluous "input-enable"
arm64: dts: qcom: sm8150: remove superfluous "input-enable"
arm64: dts: qcom: apq8016: remove superfluous "input-enable"
arm64: dts: qcom: sc8280xp-lenovo-thinkpad: correct pin drive-strength
...
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
Qualcomm ARM64 updates for v6.4
PCI I/O and MEM ranges are corrected across all targets with PCIe
enabled. Likewise is CPU clocks defined to be provided from CPUfreq for
a wide range of platforms, to satisfy the OPP definitions, and LLCC bank
information is corrected for all relevant platforms.
IPQ5332 gains SMEM, CPUfreq and support for triggering download mode.
The MI01.2 board is introduced.
On MSM8916 WCN compatibles are moved to be defined per board, to avoid
issues when boards rely on the incorrect defaults. Support for Yiming
UZ801 4G modem stick is introduced.
XO clock is defined and fed to RPMCC on MSM8953 and MSM8976, to ensure
clock trees are properly rooted. DSI clocks feeding into gcc are
described on MSM8953.
On MSM8996 the external audio components are moved from the SoC dtsi. A
few DWC3 quirks are added.
On MSM8998 GPIO names are introduced for Sony Xperia XZ Premium, XZ1 and
XZ1 Compact. A numbe of boards have GPIO keys properly marked as
wakeup-source.
The SA8775P platform is extended with CPUfreq, UARTs, I2C controllers,
SPI controllers, SPMI and PMICs, PDC support. The associated PMICs gains
reset and power key support, as well as thermal zones defined. Nodes are
sorted. On top of this the SA8775P Ride board/platform is introduced.
On SC7180 and SC7280 a range of fixes coming from DeviceTree validation are
introduced, some clearing up unused properties, others correcting
errors. A number of Google rev0 boards on SC7180 are dropped, as these
are not considered to be in use by anyone anymore.
On SC8280XP RTC support is introduced and enabled for the CRD and Lenovo
Thinkpad X13s. It gains another UART, upon which Bluetooth is enabled on
the Lenovo ThinkPad X13s. The touchpad definition is altered to attempt
to probe both devices seen in the wild. A number of bug fixes are also
introduced, and the regulator definitions on X13s are corrected.
On SDM845 dynamic power coefficients are improved. BWMON compatible is
corrected. Xiaomi Pocophone F1 gains notification LED. Sony Xperia XZ2,
XZ2 Compact and XZ3 gains display, touchscreen, gpu and remoteproc
support. OnePlus 6 and 6T gains hall sensor.
GPU clock controller and remoteproc nodes are added for SM6115. CPU
clock are defined to come from CPUfreq. Board-specific USB-properties
are moved out of the SoC dtsi.
On SM6375 L3 scaling, IMEM, RMTFS, RPM sleep stats, Tsens, modem
remoteproc and WiFi nodes are added. Tsens thermal zones are defined and additional low power states
are defined. Sony Xperia 10 IV gains volume down key support.
On SM8150 another UART is introduced, to be used by GNSS on the SA8155
ADP. Support for the Flash LED block in PM8150L is added.
On SM8250 TPDM MM and PRNG is defined, MHI region is added to PCIe node.
A few bug fixes are introduced after Devicetree validation.
The DisplayPort controller on both SM8350 and SM8450 is defined and the
related QMP instance is transitioned to the USB3/DP combo variant. IMEM
and PIL info is introduced, for post mortem debugging of remoteprocs. On
the HDK PMIC GLINK is enabled and role switch is enabled. Some audio
resources are corrected.
A typo in the USB role property of the Microsoft Surface is corrected,
thanks to DeviceTree validation.
PCIe controllers and PHYs descriptions are corrected, and pinctrl state
definitions are moved from the soc to the board definition. BWMON
compatibles are corrected. PM8550B gains the definition of the eUSB2
repeater and this is enabled on the MTP. PMIC GLINK is also defined for
the MTP and connected to DWC3, for role switching support.
In addition to this, a range of cleanups based on Devicetree validation
is introduced.
A few clock bindings are introduced, from topic-branches shared with the
clock tree, to aid introduction of references to these.
* tag 'qcom-arm64-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (256 commits)
arm64: dts: qcom: sc8280xp-x13s: Add bluetooth
arm64: dts: qcom: sc8280xp: Define uart2
arm64: dts: qcom: sc8280xp: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sm8250: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sdm845: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sa8775p-ride: set gpio-line-names for PMIC GPIOs
arm64: dts: qcom: sa8775p: add PMIC GPIO controller nodes
arm64: dts: qcom: sa8775p: pmic: add thermal zones
arm64: dts: qcom: sa8775p: pmic: add support for the pmm8654 RESIN input
arm64: dts: qcom: sa8775p: pmic: add the power key
arm64: dts: qcom: sa8775p: add the Power On device node
arm64: dts: qcom: sa8775p: add support for the on-board PMICs
arm64: dts: qcom: sa8775p: add the spmi node
arm64: dts: qcom: sa8775p: add the pdc node
arm64: dts: qcom: sa8775p: sort soc nodes by reg property
arm64: dts: qcom: sa8775p: pad reg properties to 8 digits
arm64: dts: qcom: sc8280xp: correct Soundwire wakeup interrupt name
arm64: dts: qcom: sdm845-tama: Enable GPI_DMA0/1
arm64: dts: qcom: sdm845-tama: Enable GPU
arm64: dts: qcom: sdm845-tama: Enable remoteprocs
...
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/dt
TI K3 device tree updates for v6.4
New features:
* Overlays for CPSW9G and CPSW5G on J721e-evm, J7200-evm
* Add support for AM625 based BeaglePlay, AM62-LP-SK
* Audio, RTC, watchdog support for AM625
* McSPI for J7200,j721e, j721s2, J784s4
* ADC for j721s2
* Crypto acceleration, CPSW2G for J784s4
Non critical fixes:
AM62, AM62a:
* Fix schematics error to increase DDR to 4GB on AM62a-SK
* L2Cache size fix (AM62a/AM625)
* ti,vbus-divider property to USB1 on AM625-SK
* Gpio count fix for AM625
J7200,j721e, j721s2, J784s4, AM68, AM69:
* ti,sci-dev-id for J784s4 NAVSS nodes
* j721e-sk: Drop application specific firmware name
* am68-sk: Fix the gpio expander lines for production version
Cleanups:
* Pinmux header move to dt folder (next kernel PR, we will drop the uapi header).
* j721e: ti,strobe-sel property cleanup for descoped HS400 MMC operation
* tag 'ti-k3-dt-for-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: (34 commits)
arm64: dts: ti: k3-j784s4-evm: Add eMMC mmc0 support
arm64: dts: ti: Enable audio on SK-AM62(-LP)
arm64: dts: ti: k3-am62-main: Add McASP nodes
arm64: dts: ti: k3-j784s4: Add MCSPI nodes
arm64: dts: ti: k3-j721s2: Add MCSPI nodes
arm64: dts: ti: k3-j7200: Add MCSPI nodes
arm64: dts: ti: k3-j721e: Add MCSPI nodes
arm64: ti: dts: Add support for AM62x LP SK
arm64: dts: ti: Refractor AM625 SK dts
dt-bindings: arm: ti: k3: Add compatible for AM62x LP SK
arm64: dts: ti: k3-am625-sk: Add ti,vbus-divider property to usbss1
arm64: dts: ti: k3-am68-sk-base-board: Update IO EXP GPIO lines for Rev E2
arm64: dts: ti: Add k3-am625-beagleplay
dt-bindings: arm: ti: Add BeaglePlay
arm64: dts: ti: k3-j7200: Add overlay to enable CPSW5G ports in QSGMII mode
arm64: dts: ti: j7200-main: Add CPSW5G nodes
arm64: dts: ti: k3-j721e: Add overlay to enable CPSW9G ports in QSGMII mode
arm64: dts: ti: k3-j721e: Add CPSW9G nodes
arm64: dts: ti: k3-j784s4-evm: Enable MCU CPSW2G
arm64: dts: ti: k3-j721s2-common-proc-board: Add pinmux information for ADC
...
Link: https://lore.kernel.org/r/20230410140521.3u3fftgnejakqnzj@shakable
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.4 (take two)
- Add PWM support for the R-Car H1 and H2 SoCs,
- Add slide switch and I2C support for the Marzen development board,
- Add SCI (serial) and Camera support for the RZ/G2L SoC and the
RZ/G2L SMARC EVK development board,
- Add IOMMU support for the R-Car V4H SoC,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: dts: renesas: r8a779a0: Revise renesas,ipmmu-main
arm64: dts: renesas: falcon-csi-dsi: Set bus-type for MAX96712
arm64: dts: renesas: r8a779g0: Add iommus to MMC node
arm64: dts: renesas: r8a779g0: Add iommus to DMAC nodes
arm64: dts: renesas: r8a779g0: Add IPMMU nodes
arm64: dts: renesas: r8a779f0: Revise renesas,ipmmu-main
arm64: dts: renesas: rzg2l-smarc: Enable CRU, CSI support
arm64: dts: renesas: r9a07g044: Add CSI and CRU nodes
arm64: dts: renesas: r9a07g044: Enable SCI0 using DT overlay
ARM: dts: r8a7790: Add PWM device nodes
ARM: dts: r8a7790: Add TPU device node
ARM: dts: marzen: Enable I2C support
ARM: dts: marzen: Add slide switches
ARM: dts: r8a7779: Add PWM support
dt-bindings: clock: r8a7779: Add PWM module clock
arm64: dts: renesas: rzg2l: Add clock-names and reset-names to DMAC nodes
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
In preparation for improving objtool's handling of weak noreturn
functions, mark nmi_panic_self_stop() __noreturn.
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/316fc6dfab5a8c4e024c7185484a1ee5fb0afb79.1681342859.git.jpoimboe@kernel.org
|
|
In preparation for improving objtool's handling of weak noreturn
functions, mark panic_smp_self_stop() __noreturn.
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/92d76ab5c8bf660f04fdcd3da1084519212de248.1681342859.git.jpoimboe@kernel.org
|
|
Now that arch_call_rest_init() is __noreturn, mark its caller
start_kernel() __noreturn.
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/7069acf026a195f26a88061227fba5a3b0337b9a.1681342859.git.jpoimboe@kernel.org
|
|
In preparation for improving objtool's handling of weak noreturn
functions, mark start_kernel(), arch_call_rest_init(), and rest_init()
__noreturn.
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Link: https://lore.kernel.org/r/7194ed8a989a85b98d92e62df660f4a90435a723.1681342859.git.jpoimboe@kernel.org
|
|
|