| Age | Commit message (Collapse) | Author |
|---|
|
The patch 'Replace atoi() with a robust strtoi()' introduced a bug
in parse_cpu_set(), which relies on partial parsing of the input string.
The function parses CPU specifications like '0-3,5' by incrementing
a pointer through the string. strtoi() rejects strings with trailing
characters, causing parse_cpu_set() to fail on any CPU list with
multiple entries.
Restore the original use of atoi() in parse_cpu_set().
Fixes: 7e9dfccf8f11 ("rtla: Replace atoi() with a robust strtoi()")
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20260112192642.212848-2-costa.shul@redhat.com
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
|
|
divider_determine_rate()
The divider_round_rate() function is now deprecated, so let's migrate
to divider_determine_rate() instead so that this deprecated API can be
removed.
Note that when the main function itself was migrated to use
determine_rate, this was mistakenly converted to:
req->rate = divider_round_rate(...)
This is invalid in the case when an error occurs since it can set the
rate to a negative value.
Fixes: cc41f29a6b04 ("drm/msm/dsi_phy_14nm: convert from round_rate() to determine_rate()")
Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/697613/
Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-24-535a3ed73bf3@redhat.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Janne Grunau <j@jannau.net> says:
Now that all dependencies for USB 2.0 and 3.x support are either merged
(tipd changes in v6.18, dwc3-apple in v6.19-rc1) or in linux-next (Apple
Type-C PHY) prepare device tree changes to expose the ports.
Each port on Apple silicon devices is driven by a separate collection of
hardware blocks. For USB 2.0 and 3.x the collection consists of:
- Apple Type-C PHY, combo PHY for USB 2.0, USB 3.x, USB4/Thunderbolt and
DisplayPort
- Synopsys Designware dwc3 USB controller
- two DART iommu instances for dwc3
- CD321x USB PD controller (similar to Ti's TPS6598x series)
The CD321x nodes are already present so this series add the remaining
devices nodes, typec connector nodes and connections between all
components.
The devices expose except for a few exceptions noted below all ports. M1
and M2 have two ports, M1 and M2 Pro and Max have four ports and
M1 and M2 Ultra have eight ports.
The Pro and Max based Macbook Pros use only three ports. The fourth port
is used as DisplayPort PHY to drive a HDMI output via an integrated
DP to HDMI converter.
The Ultra based Mac studio devices only use six ports. The third and
fourth port on the second die is completely fused off.
The changes for t600x and t602x are in a single commit since the devices
share .dtsi files across SoC generations due to their similarity.
Depends on commit c1538b87caef ("dt-bindings: phy: Add Apple Type-C
PHY") in linux-phy's [1] next branch for `make dtbs_check` to pass.
checkpatch warns about the undocumented DT compatible strings
"apple,t8112-atcphy", "apple,t6000-atcphy" and "apple,t6020-atcphy" but
not about "apple,t8103-atcphy". I don't under why it doesn't warn about
the last. "apple,t8103-atcphy" is only found in the added devicetree
files and nowhere else in v6.19-rc1.
Tested on top of next-20260106 on M1, M2, M1 Max and M2 Pro Mac mini /
Mac studio and a few fixes for dwc3-apple and atc [2, 3, 4, 5].
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-0-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated Type-C ports of M1 and M2 Pro, Max and Ultra based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
M1 and M2 Max based Mac Studio device have two additional USB Type-C
ports on the front which are driven by an AsMedia PCIe USB controller
and integrated USB hub. These ports are not covered by this change.
The port labels use Apple's established naming scheme for the ports.
Co-developed-by: R <rqou@berkeley.edu>
Signed-off-by: R <rqou@berkeley.edu>
Co-developed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-3-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated USBi Type-C ports of M2-based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
The port labels use Apple's established naming scheme for the ports.
Signed-off-by: Hector Martin <marcan@marcan.st>
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-2-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated USB-C ports of M1-based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
The iMac variant with four USB-C ports has two SoC integrated USB-C
ports and two additional USB-C ports driven by an AsMedia PCIe USB
controller. The latter ports are not covered by this change.
The port labels use Apple's established naming scheme for the ports.
Signed-off-by: Hector Martin <marcan@marcan.st>
Co-developed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-1-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
AGX appears to have a hidden communication channel to pmp, a power
management related co-processor already brought up by Apple's
bootloader. As there is not driver for this co-processor its
power-domain gets shut down after the initial boot.
This crashes the firmware running on AGX immediately.
Until there is a pmp driver and the dependency between AGX and pmp is
understood keep "ps_pmp" as dependency of "ps_gfx".
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-3-cfdce629c0a8@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Shutting these down breaks dwc3 init done by the firmware. We probably
never want to do this anyway. "always-on" is a plausible interpretation
of the "aon" suffix.
The t8112, t600x and t602x "ps_atc?_usb_aon" power-controller nodes are
have already "apple,always-on" properties.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-2-cfdce629c0a8@jannau.net
[sven: removed stale comment about PHY from commit message]
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add the display controller and DPTX phy power-domains to the framebuffer
node to keep the framebuffer and display out working after device probing
finished.
The OS has more control about the display pipeline used for the HDMI
output on M2 based devices. The HDMI output is driven by an integrated
DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now
controlled by the OS and no longer by firmware running on the display
co-processor. This allows using the second display controller on the
second USB type-c port or tunneling 2 DisplayPort connections over
USB4/Thunderbolt.
The m1n1 bootloader uses the second display controller to drive the HDMI
output. Adjust for this difference compared to the notebooks as well.
Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees")
Cc: stable@vger.kernel.org
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0a8@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Apple iMac (M1, 2021) are all-in-one devices with an integrated display.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-4-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
The tower and rack mount Mac Pro variants share the same .dts file and
are identical except for the chassis. There doesn't appear to be a
property in Apple's device tree to distinguish these two devices so use
"server" as chassis type which describes both if one doesn't look too
carefully.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-3-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Apple's Mac mini and Studio are desktop devices. The SMBIOS has chassis
types which might be more accurate like "low profile desktop" or "mini
pc" but without clear definition what those are use plain "desktop" as
chassis-type in the root node.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-2-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
All Macbook Air and Pro devices are laptops so annotate this as
chassis-tpe in the root node.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-1-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support
by both DPU and MDP5 drivers. Support for them in the DPU driver is
mature enough, so it's no longer sensible to keep them enabled in the
MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible
string. Drop support for the MDP5 3.x genration inside the MDP5
driver and migrate those to the DPU driver only.
Note: this will break if one uses the DT generated before v6.3 as they
had only the generic, "qcom,mdp5" compatible string for SDM630 and
SDM660. However granted that we had two LTS releases inbetween I don't
think it is an issue.
Patchwork: https://patchwork.freedesktop.org/patch/696491/
Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-3-7497c3d39179@oss.qualcomm.com
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
DPU units before 4.x don't have a separate CTL_START IRQ to mark the
begin of the data transfer. In such a case, wait for the frame transfer
to complete rather than trying to wait for the CTL_START interrupt (and
obviously hitting the timeout).
Fixes: 050770cbbd26 ("drm/msm/dpu: Fix timeout issues on command mode panels")
Reported-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Closes: https://lore.kernel.org/r/8e1d33ff-d902-4ae9-9162-e00d17a5e6d1@postmarketos.org
Patchwork: https://patchwork.freedesktop.org/patch/696490/
Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-2-7497c3d39179@oss.qualcomm.com
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
DPU 3.x don't have separate intr_start interrupt, drop it from catalog
files.
Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
Fixes: 7204df5e7e68 ("drm/msm/dpu: add support for SDM660 and SDM630 platforms")
Patchwork: https://patchwork.freedesktop.org/patch/696488/
Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-1-7497c3d39179@oss.qualcomm.com
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
The _dpu_format_populate_plane_sizes_ubwc() used MSM_MEDIA_ALIGN() and
MSM_MEDIA_ROUNDUP(), macros inherited from the previous implementation,
msm_media_info.h. Replace them with the standard Linux macros,
round_up() and DIV_ROUND_UP() respectively.
Patchwork: https://patchwork.freedesktop.org/patch/688182/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-12-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Drop extra wrapping layer (msm_media_info.h) and inline all VENUS_*()
functions, simplifying the code.
Patchwork: https://patchwork.freedesktop.org/patch/688184/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-11-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
_dpu_format_populate_plane_sizes*()
Drop redundant layout->num_planes assignments, using the value assigned
from the formats table. RGB UBWC formats need special handling: they use
two planes (per the format table), but the uAPI defines plane[1] as
empty.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688180/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-10-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Move common bits of _dpu_format_populate_plane_sizes_ubwc() and
_linear() to dpu_format_populate_plane_sizes(), reducing unnecessary
duplication and simplifying code flow fror the UBWC function.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688178/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-9-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Drop PSEUDO_YUV_FMT_LOOSE_TILED(), the macro is unused.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688176/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-8-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Pull common params of tiled YUV formats into corresponding macro
definitions, simplifying format table.
Patchwork: https://patchwork.freedesktop.org/patch/688174/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-7-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Pull common params of YUV formats into corresponding macro definitions,
simplifying format table.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688171/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-6-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Define several additional macros, capturing tiled RGB format classes, in
order to simplify defining particular RGB* format.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688169/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-5-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Define several additional macros, capturing RGB format classes, in order
to simplify defining particular RGB* format.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688168/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-4-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
INTERLEAVED_RGB_FMT_TILED
All interleaved compressed RGB formats use only 2 planes,
MDP_FETCH_LINEAR and MDP_TILE_HEIGHT_UBWC. Specify num_planes,
fetch_mode and tile_height directly in the macro and remove unused
parameters.
Patchwork: https://patchwork.freedesktop.org/patch/688166/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-3-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
All interleaved RGB formats use only 1 plane and MDP_FETCH_LINEAR.
Specify num_planes and fetch_mode directly in the macro and remove
unused parameters.
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688163/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-2-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Interleaved YUV formats use only one plane for all pixel data. Specify
num_planes = 1 for those formats. This was left unnoticed since
_dpu_format_populate_plane_sizes_linear() overrides layout->num_planes.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688162/
Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-1-cae312379d49@oss.qualcomm.com
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
The DRM buddy allocator is a shared DRM memory management
component used by multiple DRM drivers.
Matthew Auld and Arun Pravin have been actively involved in
maintaining this code, including patch review and functional
changes.
Add a dedicated MAINTAINERS entry to reflect the current
maintainership.
v2: Include drivers/gpu/drm/tests/drm_buddy_test.c file (Matthew).
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260112114022.315139-1-Arunpravin.PaneerSelvam@amd.com
|
|
Russell King says:
====================
net: stmmac: pcs: clean up pcs interrupt handling
Clean up the stmmac PCS interrupt handling:
- Avoid promotion to unsigned long from unsigned int by defining PCS
register bits/fields using u32 macros.
- Pass struct stmmac_priv into the host_irq_status MAC core method.
- Move the existing PCS interrupt handler (dwmac_pcs_isr) into
stmmac_pcs.c, change it's arguments, use dev_info() rather than
pr_info()
- arrange to call phylink_pcs_change() on link state changes.
====================
Link: https://patch.msgid.link/aWOiOfDQkMXDwtPp@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Report PCS link changes to phylink, which will allow phylink's inband
support to respoind to link events once the PCS is appropriately
configured.
An expected behavioural change is that should the PCS report that its
link has failed, but phylink is operating in outband mode and the PHY
reports that link is up, this event will cause the netdev's link to
momentarily drop, making the event more noticable, rather than just
producing a "stmmac_pcs: Link Down" message.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vevI1-00000002Yp8-3cM3@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Change the arguments to the PCS handler so that it can access the
struct device pointer and integrated PCS pointers.
This allows us to use the PCS register offset stored in struct
stmmac_pcs rather than passing it into the function, and also allows
the messages to be printed using dev_info() rather than pr_info(),
thereby allowing the stmmac instance to be identified.
Finally, as dev_info() identifies the driver/device, prefixing with
"stmmac_pcs: " is now redundant, so replace this with just "PCS ".
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vevHw-00000002Yoz-35A7@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Rather than passing struct mac_device_info to the host_irq_status()
method, pass struct stmmac_priv so that we can pass the integrated
PCS to the PCS interrupt handler.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vevHr-00000002YoY-2X2i@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
dwmac_pcs_isr() doesn't need to be inlined into the MAC's
host_irq_status method, as handling PCS interrupts isn't performance
critical. However, there is little point calling this function unless
an interrupt is pending for the PCS.
Rename it to stmmac_integrated_pcs_irq() while moving it.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vevHm-00000002YoS-23RX@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
stmmac registers a 32-bit. u32 is unsigned int. The use of BIT() and
GENMASK() leads to integer promotion to unsigned long in expressions
such as:
u32 old = foo;
dev_info(dev, "%08x %08x\n", old, old & BIT(1));
resulting in arg2 being accepted as compatible with the format string
and arg3 warning that the argument does not match (because the former
is unsigned int, and the latter is unsigned long.)
Fix this by defining 32-bit register bits using BIT_U32() and
GENMASK_U32() macros.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vevHh-00000002YoM-1TYL@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
clang is unable to inline the memset() calls in net/core/skbuff.c
when initializing allocated sk_buff.
memset(skb, 0, offsetof(struct sk_buff, tail));
This is unfortunate, because:
1) calling external memset_orig() helper adds a call/ret and
typical setup cost.
2) offsetof(struct sk_buff, tail) == 0xb8 = 0x80 + 0x38
On x86_64, memset_orig() performs two 64 bytes clear,
then has to loop 7 times to clear the final 56 bytes.
skbuff_clear() makes sure the minimal and optimal code
is generated.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260109203836.1667441-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Heiner Kallweit says:
====================
r8169: add support for RTL8127ATF (10G Fiber SFP)
RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.
The PHY driver is used by the RTL8127ATF support in r8169.
RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
PHY ID.
====================
Link: https://patch.msgid.link/c2ad7819-85f5-4df8-8ecf-571dbee8931b@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Link: https://patch.msgid.link/5c390273-458f-4d92-896b-3d85f2998d7d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.
This PHY driver is used by the RTL8127ATF support in r8169.
RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
PHY ID. This PHY driver is used by the RTL8127ATF support in r8169.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/e3d55162-210a-4fab-9abf-99c6954eee10@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED
events. As a result, i2c read event will trigger repeated reception of
old data, reset rx_pos when a read request is received.
Signed-off-by: Jian Zhang <zhangjian.3032@bytedance.com>
Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Yao Zi says:
====================
Add DWMAC glue driver for Motorcomm YT6801
This series adds glue driver for Motorcomm YT6801 PCIe ethernet
controller, which is considered mostly compatible with DWMAC-4 IP by
inspecting the register layout[1]. It integrates a Motorcomm YT8531S PHY
(confirmed by reading PHY ID) and GMII is used to connect the PHY to
MAC[2].
The initialization logic of the MAC is mostly based on previous upstream
effort for the controller[3] and the Deepin-maintained downstream Linux
driver[4] licensed under GPL-2.0 according to its SPDX headers. However,
this series is a completely re-write of the previous patch series,
utilizing the existing DWMAC4 driver and introducing a glue driver only.
This series only aims to add basic networking functions for the
controller, features like WoL, RSS and LED control are omitted for now.
Testing is done on i3-4170, it reaches 939Mbps (TX)/933Mbps (RX) on
average,
YT6801 TX
Connecting to host 192.168.114.51, port 5201
[ 5] local 192.168.114.50 port 52986 connected to 192.168.114.51 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 112 MBytes 938 Mbits/sec 0 950 KBytes
[ 5] 1.00-2.00 sec 113 MBytes 949 Mbits/sec 0 1.08 MBytes
[ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 0 1.08 MBytes
[ 5] 3.00-4.00 sec 111 MBytes 932 Mbits/sec 0 1.13 MBytes
[ 5] 4.00-5.00 sec 113 MBytes 945 Mbits/sec 0 1.13 MBytes
[ 5] 5.00-6.00 sec 112 MBytes 936 Mbits/sec 0 1.13 MBytes
[ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 1.19 MBytes
[ 5] 7.00-8.00 sec 112 MBytes 935 Mbits/sec 0 1.19 MBytes
[ 5] 8.00-9.00 sec 113 MBytes 948 Mbits/sec 0 1.19 MBytes
[ 5] 9.00-10.00 sec 111 MBytes 931 Mbits/sec 0 1.19 MBytes
YT6801 RX
Connecting to host 192.168.114.50, port 5201
[ 5] local 192.168.114.51 port 41578 connected to 192.168.114.50 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 113 MBytes 944 Mbits/sec 0 542 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 934 Mbits/sec 0 850 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 1.01 MBytes
[ 5] 3.00-4.00 sec 112 MBytes 943 Mbits/sec 0 1.01 MBytes
[ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec 0 1.01 MBytes
[ 5] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 0 1.01 MBytes
[ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 0 1.01 MBytes
[ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 0 1.01 MBytes
[ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec 0 1.01 MBytes
[ 5] 9.00-10.00 sec 111 MBytes 932 Mbits/sec 0 1.01 MBytes
====================
Link: https://patch.msgid.link/20260109093445.46791-2-me@ziyao.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
I volunteer to maintain the DWMAC glue driver for Motorcomm ethernet
controllers.
Signed-off-by: Yao Zi <me@ziyao.cc>
Link: https://patch.msgid.link/20260109093445.46791-5-me@ziyao.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
integrates an GbE phy, supporting WOL, VLAN tagging and various types
of offloading. It ships an on-chip eFuse for storing various vendor
configuration, including MAC address.
This patch adds basic glue code for the controller, allowing it to be
set up and transmit data at a reasonable speed. Features like WOL could
be implemented in the future.
Signed-off-by: Yao Zi <me@ziyao.cc>
Tested-by: Mingcong Bai <jeffbai@aosc.io>
Tested-by: Runhua He <hua@aosc.io>
Tested-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Sai Krishna <saikrishnag@marvell.com>
Link: https://patch.msgid.link/20260109093445.46791-4-me@ziyao.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
YT6801's internal PHY is confirmed as a GMII-capable variant of YT8531S
by a previous series[1] and reading PHY ID. Add support for
PHY_INTERFACE_MODE_GMII for YT8531S to allow the Ethernet driver to
reuse the PHY code for its internal PHY.
Link: https://lore.kernel.org/all/a48d76ac-db08-46d5-9528-f046a7b541dc@motor-comm.com/ # [1]
Co-developed-by: Frank Sae <Frank.Sae@motor-comm.com>
Signed-off-by: Frank Sae <Frank.Sae@motor-comm.com>
Signed-off-by: Yao Zi <me@ziyao.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20260109093445.46791-3-me@ziyao.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Fix Typo in airoha_ppe_dev_setup_tc_block_cb routine definition when
CONFIG_NET_AIROHA is not enabled.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601090517.Fj6v501r-lkp@intel.com/
Fixes: f45fc18b6de04 ("net: airoha: Add airoha_ppe_dev struct definition")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260109-airoha_ppe_dev_setup_tc_block_cb-typo-v1-1-282e8834a9f9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The "struct alg" object contains a union of 3 xfrm structures:
union {
struct xfrm_algo;
struct xfrm_algo_aead;
struct xfrm_algo_auth;
}
All of them end with a flexible array member used to store key material,
but the flexible array appears at *different offsets* in each struct.
bcz of this, union itself is of variable-sized & Placing it above
char buf[...] triggers:
ipsec.c:835:5: warning: field 'u' with variable sized type 'union
(unnamed union at ipsec.c:831:3)' not at the end of a struct or class
is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
835 | } u;
| ^
one fix is to use "TRAILING_OVERLAP()" which works with one flexible
array member only.
But In "struct alg" flexible array member exists in all union members,
but not at the same offset, so TRAILING_OVERLAP cannot be applied.
so the fix is to explicitly overlay the key buffer at the correct offset
for the largest union member (xfrm_algo_auth). This ensures that the
flexible-array region and the fixed buffer line up.
No functional change.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
Link: https://patch.msgid.link/20260109152201.15668-1-ankitkhushwaha.linux@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The comment has been around ever since commit 1da177e4c3f4
("Linux-2.6.12-rc2") and can be removed. Remove it and indent the code
block accordingly.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260109121128.170020-2-thorsten.blum@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Sami Tolvanen says:
====================
While running BPF self-tests with CONFIG_CFI (Control Flow
Integrity) enabled, I ran into a couple of failures in
bpf_obj_free_fields() caused by type mismatches between the
btf_dtor_kfunc_t function pointer type and the registered
destructor functions.
It looks like we can't change the argument type for these
functions to match btf_dtor_kfunc_t because the verifier doesn't
like void pointer arguments for functions used in BPF programs,
so this series fixes the issue by adding stubs with correct types
to use as destructors for each instance of this I found in the
kernel tree.
The last patch changes btf_check_dtor_kfuncs() to enforce the
function type when CFI is enabled, so we don't end up registering
destructors that panic the kernel.
v5:
- Rebased on bpf-next/master again.
v4: https://lore.kernel.org/bpf/20251126221724.897221-6-samitolvanen@google.com/
- Rebased on bpf-next/master.
- Renamed CONFIG_CFI_CLANG to CONFIG_CFI.
- Picked up Acked/Tested-by tags.
v3: https://lore.kernel.org/bpf/20250728202656.559071-6-samitolvanen@google.com/
- Renamed the functions and went back to __bpf_kfunc based
on review feedback.
v2: https://lore.kernel.org/bpf/20250725214401.1475224-6-samitolvanen@google.com/
- Annotated the stubs with CFI_NOSEAL to fix issues with IBT
sealing on x86.
- Changed __bpf_kfunc to explicit __used __retain.
v1: https://lore.kernel.org/bpf/20250724223225.1481960-6-samitolvanen@google.com/
====================
Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://patch.msgid.link/20260110082548.113748-6-samitolvanen@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Ensure that registered destructor kfuncs have the same type
as btf_dtor_kfunc_t to avoid a kernel panic on systems with
CONFIG_CFI enabled.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260110082548.113748-10-samitolvanen@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
With CONFIG_CFI enabled, the kernel strictly enforces that indirect
function calls use a function pointer type that matches the target
function. As bpf_testmod_ctx_release() signature differs from the
btf_dtor_kfunc_t pointer type used for the destructor calls in
bpf_obj_free_fields(), add a stub function with the correct type to
fix the type mismatch.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260110082548.113748-9-samitolvanen@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
