| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Pull in a major rework of gpiochip_add_data_with_key()
|
|
drm_sched_fini() contained a hack to work around a race in amdgpu.
According to AMD, the hack should not be necessary anymore. In case
there should have been undetected users,
commit 975ca62a014c ("drm/sched: Add warning for removing hack in drm_sched_fini()")
had added a warning one release cycle ago.
Thus, it can be derived that the hack can be savely removed by now.
Remove the hack.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260108083019.63532-2-phasta@kernel.org
|
|
Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),
`gdev->dev.release` is unset. As a result, the reference count to
`gdev->dev` isn't dropped on the error handling paths.
Drop the reference on errors.
Also reorder the instructions to make the error handling simpler.
Now gpiochip_add_data_with_key() roughly looks like:
>>> Some memory allocation. Go to ERR ZONE 1 on errors.
>>> device_initialize().
gpiodev_release() takes over the responsibility for freeing the
resources of `gdev->dev`. The subsequent error handling paths
shouldn't go through ERR ZONE 1 again which leads to double free.
>>> Some initialization mainly on `gdev`.
>>> The rest of initialization. Go to ERR ZONE 2 on errors.
>>> Chip registration success and exit.
>>> ERR ZONE 2. gpio_device_put() and exit.
>>> ERR ZONE 1.
Cc: stable@vger.kernel.org
Fixes: aab5c6f20023 ("gpio: set device type for GPIO chips")
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260205092840.2574840-1-tzungbi@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
In GPIOLIB, during fwnode lookup, after having resolved the consumer's
reference to a specific fwnode, we only match it against the primary
node of the controllers. Let's extend that to also the secondary node by
reworking gpio_chip_match_by_fwnode()
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20260226-device-match-secondary-fwnode-v4-1-27bd0cfbd8c6@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Update header inclusions to follow IWYU (Include What You Use)
principle.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260226092023.4096921-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Convert the direct i915_overlay_*() calls from the display
side to go over a new parent interface instead.
v2: Correctly handle the ERR_PTR returned by
i915_overlay_obj_lookup() (Jani)
v3: Rebase due to the NULL check in intel_overlay_cleanup()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226130150.16816-1-ville.syrjala@linux.intel.com
|
|
Relocate the i915 driver specific parts of the overlay code
into i915_overlay.c. This leaves intel_overlay.c with just
the display specific code.
The one annoyance here is the DSPCLK_GATE_D register access
being done from i830_overlay_clock_gating(). The register
definition lives on the display side as we do need to access
it on other platforms there. Since it's just one register
and bit, I decided to just duplicate that part in i915_reg.h.
v2: Use kzalloc_obj()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226133855.17690-1-ville.syrjala@linux.intel.com
|
|
We don't generally want fetch_and_zero() on the display side, so
stop using it in the display side intel_overlay_cleanup().
Fortunately we don't really have anything to do here apart from
freeing the data. And we'll keep on clearing the pointer, just
in case something somewhere cares about it.
Note that once i915_overlay_cleanup() is converted to the parent
interface we can't call it unconditionally (as xe won't have it).
So we need to keep the early bailout for overlay==NULL.
v2: Adjust the commit message since we do apparently
have fetch_and_zero() in display code as well (Jani)
v3: Skip i915_overlay_cleanup() if the overlay wasn't initialized
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226130113.16714-1-ville.syrjala@linux.intel.com
|
|
Split the i915 driver specific bits from 'struct intel_overlay'
into a seaarate 'struct i915_overlay'. The latter will move to
the i915 side of the parent vs. display driver split.
The display side will also need to know the virtual address of
the register map. That now gets passed as the return value
from i915_overlay_setup(), so that the display side doesn't
need to know how the mapping was achieved.
v2: Use kzalloc_obj()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-17-ville.syrjala@linux.intel.com
|
|
Rename the one lingering 'dev_priv' variable to the
more modern 'i915' in the overlay code.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-16-ville.syrjala@linux.intel.com
|
|
i830_overlay_clock_gating() will remain on the i915 side of the
parent vs. display driver split. Stop using display specific stuff
inside it.
The one annoyance here is access to the display engine's
DSPCLK_GATE_D register. The proper way to deal with that might
be to move it to the display side, but that seems a bit hard right
now. So leave it where it is for now.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-15-ville.syrjala@linux.intel.com
|
|
Adjust the names ("i915_overlay_" prefix) and calling
convention (pass the driver agnostic 'struct drm_device'()
of the functions that will provide the remainder of the
parent driver interface to be used by the overlay display
code.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-14-ville.syrjala@linux.intel.com
|
|
Some of the lower level functions in the overlay code will
move to the i915 side of the upcoming parent vs. display
driver split. Move all such functions to the "i915_overlay_"
namespace to make it easier to see what belongs where.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-13-ville.syrjala@linux.intel.com
|
|
Make the buffer (un)pinning a bit more abstract so that
the display side of the code doesn't need to know about i915
specific things (i915_ggtt_offset() and i915_vma_unpin()).
In preparation for the full parent vs. display driver split
we'll also pass in the drm_device to these functions, although
not strictly needed yet.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-12-ville.syrjala@linux.intel.com
|
|
Pull the i915 specific bits of the overlay cleanup into
a separate function (i915_overlay_cleanup()) to accommodate
the upcoming parent vs. display driver split.
For now we'll also have to pass in the overlay struct, but
that will disappear once the i915 vs. display split is completed.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-11-ville.syrjala@linux.intel.com
|
|
Pull the gem/gt related bits of the overlay setup into
a separate function (i915_overlay_setup()) that will eventually
move to the i915 side of the parent vs. display driver split.
For now we'll also have to pass in the overlay struct, but
that will disappear once the i915 vs. display split is completed.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-10-ville.syrjala@linux.intel.com
|
|
overlay->frontbuffer_bits tracking will move to the i915 side
of the parent vs. display driver split, so extract the reset
part of that into a new function (i915_overlay_reset()).
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-9-ville.syrjala@linux.intel.com
|
|
Use 'struct drm_gem_object' for the BO instead of 'struct
drm_i915_gem_object', to avoid having the display side
know anything about the i915 specific BO type.
v2: Correctly handle the ERR_PTR returned by
i915_overlay_obj_lookup() (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-8-ville.syrjala@linux.intel.com
|
|
Extract the BO lookup and tiling check into a new
helper called i915_overlay_obj_lookup(). This will have to
move to the i915 side of the parent vs. display driver split.
There is a slight change here in that we now do the tiling
check before taking the modeset locks, but those locks don't
protect the BO tiling stuff in any way, so nothing is really
different here.
Note that the hardware should support X-tiled scanout also
for the overlay, but I guess no one ever bothered to hook
it up and test it. So the check should stay at least for now.
v2: Correctly handle the ERR_PTR returned by
i915_overlay_obj_lookup() (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-7-ville.syrjala@linux.intel.com
|
|
Move the underrun check out from intel_overlay_continue()
so that the DOVSTA register access can stay on the display
side of the parent vs. display driver split.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-6-ville.syrjala@linux.intel.com
|
|
Now that we have overlay->frontbuffer_bits, overlay->active
is completely redundant, so remove it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-5-ville.syrjala@linux.intel.com
|
|
Pull the "is the overlay active?" check to a helper
(i915_overlay_is_active()). This will have to move to the
i915 side of the parent vs. display driver split.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-4-ville.syrjala@linux.intel.com
|
|
Store the current frontbuffer_bits in the overlay data. The
main benefit here is that we get rid of the 'crtc->pipe'
usage from intel_overlay_flip_prepare() which will have to
move to the i915 side of the parent vs. display driver split.
And since the goal is to get rid of the crtc stuff, move those
out from intel_overlay_off_tail() into intel_overlay_switch_off()
since the i915 side doesn't use those anymore, and the display
side doesn't need those anymore after that anyway.
intel_overlay_off_tail() will itself move to the i915 side of
the fence once the driver split is done.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-3-ville.syrjala@linux.intel.com
|
|
The overlay snapshot stuff is a bit annoying because some of
it more or less of belongs on the gt side, and some on the
display side. Remove the whole thing to avoid having to deal
with it when splitting the overlay code around the i915
vs. display boundary. I don't think I've ever actually used
this for anything, so no real loss from my POV. And it can
always be resurrected later should the need arise.
v2: Rebase due to kmalloc_obj()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260226100738.29997-2-ville.syrjala@linux.intel.com
|
|
Display Code is made independent of i915_reg.h, hence
it can be dropped from compat header.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260226175531.2324526-1-uma.shankar@intel.com
|
|
When a process is deregistered from the binder context, the all_procs
vector may have significant unused capacity. Add logic to shrink the
vector using a conservative strategy that prevents shrink-then-regrow
oscillation.
The shrinking strategy triggers when length drops below 1/4 of capacity,
and shrinks to twice the current length rather than to the exact length.
This provides hysteresis to avoid repeated reallocations when the process
count fluctuates.
The shrink operation uses GFP_KERNEL and is allowed to fail gracefully
since it is purely an optimization. The vector remains valid and
functional even if shrinking fails.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260216-binder-shrink-vec-v3-v6-3-ece8e8593e53@zohomail.in
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Binder currently uses from.process.task.euid() as the transaction sender
EUID, where from.process.task is the main thread of the process that opened
/dev/binder. That's not clean; use the subjective EUID of the current task
instead.
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260213-binder-uid-v1-2-7b795ae05523@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Binder currently uses task_euid(proc->tsk) as the transaction sender EUID,
where proc->tsk is the main thread of the process that opened /dev/binder.
That's not clean; use the subjective EUID of the current task instead.
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260213-binder-uid-v1-1-7b795ae05523@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Currently ps -A shows processes waiting on schedule() in functions with
names such as do_epoll_wait, wait_woken, and the impeccably named
_RNvMs2_NtCs8QPsHWIn21X_16rust_binder_main6threadNtB5_6Thread8get_work.
To improve how ps output looks, give explicit non-mangled names to the
functions where Rust Binder calls schedule(), since these are the most
likely places to show up on ps output.
The name of rust_binder_waitlcl is truncated instead of using _local
suffix because rust_binder_wait_local is sufficiently long that ps shows
unaligned output.
This is intended to be a temporary workaround until we find a better
solution. Adding #[export_name] to every Rust function that calls
schedule() is not a great long-term solution.
Suggested-by: Matthew Maurer <mmaurer@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260219-rust-binder-ps-v2-1-773eca09c125@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There's no reason to lock the whole mm when we are doing operations on
the vma if we can help it, so to reduce contention, use the
lock_vma_under_rcu() abstraction.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Jann Horn <jannh@google.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://patch.msgid.link/20260218-binder-vma-rcu-v1-1-8bd45b2b1183@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Consider the following sequence of events on a death listener:
1. The remote process dies and sends a BR_DEAD_BINDER message.
2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.
3. The local process then invokes the BC_DEAD_BINDER_DONE.
Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a
BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().
However, this can result in a deadlock if the current thread is not a
looper. This is because dead_binder_done() still holds the proc lock
during set_notification_done(), which called push_work_if_looper().
Normally, push_work_if_looper() takes the thread lock, which is fine to
take under the proc lock. But if the current thread is not a looper,
then it falls back to delivering the reply to the process work queue,
which involves taking the proc lock. Since the proc lock is already
held, this is a deadlock.
Fix this by releasing the proc lock during set_notification_done(). It
was not intentional that it was held during that function to begin with.
I don't think this ever happens in Android because BC_DEAD_BINDER_DONE
is only invoked in response to BR_DEAD_BINDER messages, and the kernel
always delivers BR_DEAD_BINDER to a looper. So there's no scenario where
Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.
Cc: stable <stable@kernel.org>
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Reported-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com
Tested-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260224-binder-dead-binder-done-proc-lock-v1-1-bbe1b8a6e74a@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When sending a transaction, its offsets array is first copied into the
target proc's vma, and then the values are read back from there. This is
normally fine because the vma is a read-only mapping, so the target
process cannot change the value under us.
However, if the target process somehow gains the ability to write to its
own vma, it could change the offset before it's read back, causing the
kernel to misinterpret what the sender meant. If the sender happens to
send a payload with a specific shape, this could in the worst case lead
to the receiver being able to privilege escalate into the sender.
The intent is that gaining the ability to change the read-only vma of
your own process should not be exploitable, so remove this TOCTOU read
even though it's unexploitable without another Binder bug.
Cc: stable <stable@kernel.org>
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://patch.msgid.link/20260218-binder-vma-check-v2-2-60f9d695a990@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When installing missing pages (or zapping them), Rust Binder will look
up the vma in the mm by address, and then call vm_insert_page (or
zap_page_range_single). However, if the vma is closed and replaced with
a different vma at the same address, this can lead to Rust Binder
installing pages into the wrong vma.
By installing the page into a writable vma, it becomes possible to write
to your own binder pages, which are normally read-only. Although you're
not supposed to be able to write to those pages, the intent behind the
design of Rust Binder is that even if you get that ability, it should not
lead to anything bad. Unfortunately, due to another bug, that is not the
case.
To fix this, store a pointer in vm_private_data and check that the vma
returned by vma_lookup() has the right vm_ops and vm_private_data before
trying to use the vma. This should ensure that Rust Binder will refuse
to interact with any other VMA. The plan is to introduce more vma
abstractions to avoid this unsafe access to vm_ops and vm_private_data,
but for now let's start with the simplest possible fix.
C Binder performs the same check in a slightly different way: it
provides a vm_ops->close that sets a boolean to true, then checks that
boolean after calling vma_lookup(), but this is more fragile
than the solution in this patch. (We probably still want to do both, but
the vm_ops->close callback will be added later as part of the follow-up
vma API changes.)
It's still possible to remap the vma so that pages appear in the right
vma, but at the wrong offset, but this is a separate issue and will be
fixed when Rust Binder gets a vm_ops->close callback.
Cc: stable <stable@kernel.org>
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://patch.msgid.link/20260218-binder-vma-check-v2-1-60f9d695a990@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The spam detection logic in TreeRange was executed before the current
request was inserted into the tree. So the new request was not being
factored in the spam calculation. Fix this by moving the logic after
the new range has been inserted.
Also, the detection logic for ArrayRange was missing altogether which
meant large spamming transactions could get away without being detected.
Fix this by implementing an equivalent low_oneway_space() in ArrayRange.
Note that I looked into centralizing this logic in RangeAllocator but
iterating through 'state' and 'size' got a bit too complicated (for me)
and I abandoned this effort.
Cc: stable <stable@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260210232949.3770644-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
ALE table
In the current implementation, flushing multicast entries in MAC mode
incorrectly deletes entries for all ports instead of only the target port,
disrupting multicast traffic on other ports. The cause is adding multicast
entries by setting only host port bit, and not setting the MAC port bits.
Fix this by setting the MAC port's bit in the port mask while adding the
multicast entry. Also fix the flush logic to preserve the host port bit
during removal of MAC port and free ALE entries when mask contains only
host port.
Fixes: 5c50a856d550 ("drivers: net: ethernet: cpsw: add multicast address to ALE table")
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260224181359.2055322-1-c-vankar@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Corrected the typo in the function name from
`airhoa_is_lan_gdm_port` to `airoha_is_lan_gdm_port`. This change ensures
consistency in the API naming convention.
Signed-off-by: Zhengping Zhang <aquapinn@qq.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/tencent_E4FD5D6BC0131E617D848896F5F9FCED6E0A@qq.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 853a2944aaf3 ("net: atlantic: support reading SFP module info")
added support for reading SFP module info on AQC100-based cards. However,
it only supports reading directly from the controller's hardware
registers, and this does not seem to be supported on certain cards,
including my TRENDnet TEG-10GECSFP V3. "ethtool -m" times out when reading
certain registers, even when I increase the read poll timeout values.
The DPDK "atlantic" driver reads module info via firmware calls instead of
directly reading the hardware registers, provided that the NIC's firmware
version supports it.
This change adapts the DPDK firmware call code to the kernel driver. It
preserves the old hardware-based module read code as a fallback when the
firmware does not support it, to avoid breaking cards that are currently
working.
Tested on 2 different TRENDnet TEG-10GECSFP V3 cards, both with firmware
version 3.1.121 (current at the time of this patch). Both cards correctly
reported module info for a passive DAC cable and 2 different 10G optical
transceivers.
Signed-off-by: Tiernan Hubble <thubble@thubble.ca>
Link: https://patch.msgid.link/20260225002026.1754045-1-thubble@thubble.ca
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In SGMII mode, GEM can work with or without inband
autonegotiation.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Link: https://patch.msgid.link/20260224202854.112813-4-charles.perry@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
This makes it possible to use in-band autonegotiation with
SGMII.
If using a device tree, this can be done by adding the managed =
"in-band-status" property to the gem node.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Link: https://patch.msgid.link/20260224202854.112813-3-charles.perry@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Make it possible to connect a PHY which does not use inband
autoneg to a gem MAC using phylink's information.
The previous implementation relied on whether or not the link
was a fixed-link to disable SGMII autoneg. This commit extend
this to all link which are not configured for inband
autonegotiation.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Link: https://patch.msgid.link/20260224202854.112813-2-charles.perry@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Some panels need VESA DPCD AUX backlight but VBT says otherwise.
This is why we try with Intel backlight interface over VESA backlight
interface. This causes a blankout on such panels without any fallback
mechanism.
Remove try_vesa_interface and use VESA AUX backlight interface as a
fallback mechanism.
While at in sneak in a small comment cleanup too.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15679
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260224031322.2568874-1-suraj.kandpal@intel.com
|
|
mtk_phy_pdata documentation does not use correct tag for struct, while at
it fix one of member wrongly documented.
Warning: drivers/phy/mediatek/phy-mtk-tphy.c:289 cannot understand function prototype: 'struct mtk_phy_pdata'
Warning: drivers/phy/mediatek/phy-mtk-tphy.c:296 struct member 'slew_ref_clock_mhz' not described in 'mtk_phy_pdata'
Link: https://patch.msgid.link/20260223071032.408425-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Kconfig is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that
Link: https://patch.msgid.link/20260223065819.395612-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Makefile is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that
Link: https://patch.msgid.link/20260223065743.395539-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
created spacemit subfolder with usb driver while commit 57e920b92724
("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
folder. Move latter into spacemit subfolder and rename file to
phy-k1-pcie.c
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260223064240.386617-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
mac_to_index_bmap is allocated with rvu_alloc_bitmap(), so free it
with rvu_free_bitmap() instead of open-coding kfree(.bmap) to keep
the alloc/free API pairing consistent.
Signed-off-by: Bo Sun <bo@mboxify.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/20260225082348.2519131-1-bo@mboxify.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ptp_clock_ops.n_per_out sets the number of PPS outputs, which the PTP
subsystem uses to validate userspace input, such as the index number
used in a PTP_CLK_REQ_PEROUT request.
stmmac_enable() uses this to index the priv->pps array, which is an
array of size STMMAC_PPS_MAX. ptp_clock_ops.n_per_out is initialised
using priv->dma_cap.pps_out_num, which is a three bit field read from
hardware.
Documentation that I've checked suggests that values >= 5 are reserved,
but that doesn't mean such values won't appear, and if they do, we
can overrun the priv->pps array in stmmac_enable().
stmmac_ptp_register() has protection against this in its loop, but it
doesn't act to limit ptp_clock_ops.n_per_out.
Fix this by introducing a local variable, pps_out_num which is limited
to STMMAC_PPS_MAX, and use that when initialising the array and setting
priv->ptp_clock_ops.n_per_out. Print a warning when we limit the number
of outputs.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vvBhn-0000000ArCg-4C4u@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Some pinconf properties are mutually exclusive, either because they
convey the same information in different units or represent incompatible
configurations of the same pin. Attempt, in two ways, to prevent these
situations.
Firstly, for enable/disable properties, produce an error if both are
set. Since enable/disable properties share the same enum value, they can
be trivially checked via the newly added bitmap. Having both enable and
disable for the same config makes no sense at all, so produce an error
in this case.
For interactions between properties, doing them outside the loop makes
more sense as it can be evaluated once. In case there are some edge
cases that would be broken by producing an error, only warn for now.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into work-linus
Jonathan writes:
IIO: 1st set of fixes for the 7.0 cycle
Usual mixed bag of ancient bugs that have been discovered and more
recent stuff.
core
- Cleanup a wait_queue if a driver is removed at exacty the wrong
moment.
adi,adf4377
- Check correct masks when waiting for reset to complete.
adi,adis
- Fix a NULL pointer dereference if ops not provided to adis_init()
bosch,bme680
- Fix typo in value used to calculate measurement wait duration.
infineon,tlv493d
- Drop incorrect shifting of some bits for x-axis
invensense,icm42600
- Fix corner case of output data rate being set to the value it already
has which resulted in waiting for ever for a flag to say the update was
completed.
- Fix a case where the buffer is turned off whilst ODR switch is in progress.
invensense,icm45600
- Interrupt 1 drive bit was inverted.
- Fix a underflow for regulator put warning if probe fails
invensense,mpu9150
- Work around a hardware quirk where reading from irq status is not sufficient
to acknowledge an interrupt.
maxim,ds4424
- Reject -128 as a possible raw value as it's out of range with the sign
/ magnitude encoding used by this chip.
microchip,mcp4131
- Shift the wiper value only once.
rohm,bh1780
- Fix a runtime reference count issue on an error path.
sensiron,sps30
- Fix two buffer size issues due to sizeof() wrong thing.
tyhx,hx9023s
- Ensure count used by __counted_by is set before accessing the buffer.
- Avoid a potential division by zero.
* tag 'iio-fixes-for-7.0a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
iio: imu: adis: Fix NULL pointer dereference in adis_init
iio: imu: inv_icm45600: fix regulator put warning when probe fails
iio: buffer: Fix wait_queue not being removed
iio: gyro: mpu3050-core: fix pm_runtime error handling
iio: gyro: mpu3050-i2c: fix pm_runtime error handling
iio: adc: ad7768-1: Fix ERR_PTR dereference in ad7768_fill_scale_tbl
iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas()
iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()
iio: magnetometer: tlv493d: remove erroneous shift in X-axis data
iio: proximity: hx9023s: Protect against division by zero in set_samp_freq
iio: proximity: hx9023s: fix assignment order for __counted_by
iio: chemical: bme680: Fix measurement wait duration calculation
iio: dac: ds4424: reject -128 RAW value
iio: imu: inv_icm45600: fix INT1 drive bit inverted
iio: potentiometer: mcp4131: fix double application of wiper shift
iio: imu: inv-mpu9150: fix irq ack preventing irq storms
iio: frequency: adf4377: Fix duplicated soft reset mask
iio: light: bh1780: fix PM runtime leak on error path
iio: imu: inv_icm42600: fix odr switch when turning buffer off
iio: imu: inv_icm42600: fix odr switch to the same value
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-7.0-2026-02-26:
amdgpu:
- UserQ fixes
- DC fix
- RAS fixes
- VCN 5 fix
- Slot reset fix
- Remove MES workaround that's no longer needed
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260226161330.3549393-1-alexander.deucher@amd.com
|
