mainline: bump edge 6.18 to rc7
#8989
Conversation
EvilOlaf
requested review from
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
NicoD-SBC,
SteeManMI,
SuperKali,
TheSnowfield,
Tonymac32,
adeepn,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx,
efectn,
igorpecovnik,
joekhoobyar,
krachlatte,
lanefu,
paolosabatino,
prahal,
pyavitz,
rpardini,
schwar3kat and
teknoid
as code owners
WalkthroughBump 6.18 kernel release candidate from rc6 to rc7. Add D-WAV MultiTouch USB touchscreen driver with HID quirks and ODROID device IDs. Expand device tree support for Rockchip platforms: ODROID M1 peripherals, OrangePi5 SATA power, RK3328 SPDIF audio and USB3, new Rockchip IEP V4L2 M2M video driver, rkvdec multi-variant decoder support, RK3328 DMC devfreq, and Inno USB3 PHY driver. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant DT as Device Tree
participant Drv as IEP Driver
participant HW as Hardware
participant V4L2 as V4L2 Framework
DT->>Drv: probe(compatible)
Drv->>Drv: map registers & clocks
Drv->>HW: enable clocks
Drv->>V4L2: register M2M device
V4L2->>Drv: open()
Drv->>Drv: allocate context
V4L2->>Drv: set_fmt() src/dst
Drv->>Drv: validate & store format
V4L2->>Drv: qbuf(src/dst)
Drv->>Drv: queue buffers to URB
V4L2->>Drv: streamon()
Drv->>HW: write HW registers
HW->>HW: process (interrupt)
HW->>Drv: IRQ
Drv->>V4L2: buffer_done()
sequenceDiagram
autonumber
participant DT as Device Tree
participant Probe as Probe Logic
participant Variant as Variant Config
participant HW as Hardware
participant Fmt as Format Ops
DT->>Probe: of_device_id match
Probe->>Variant: load variant (RK3588/RK3576/RK3288)
Variant->>Variant: select register offsets & quirks
Probe->>Probe: check multicore (disable if not first)
Probe->>HW: load capabilities & formats
Probe->>Fmt: register variant-specific fmt_ops
Fmt->>Fmt: colmv_size(), flatten_matrices()
Fmt->>HW: write variant-aware register layout
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Areas requiring extra attention:
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
size/medium
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (13)
patch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patch (1)
18-30: Use official compatible string as primary fallback for RGA node.The patch adds an RGA node to rk3328.dtsi, but the primary compatible string needs correction:
The compatible string "rockchip,rk3328-rga" is not recognized in the official upstream Rockchip RGA device tree binding, which only documents "rockchip,rk3288-rga" and "rockchip,rk3399-rga".
The node currently uses
compatible = "rockchip,rk3328-rga", "rockchip,rk3399-rga". This relies on the fallback to an officially recognized binding. To ensure proper compatibility and avoid reliance on non-standard device tree properties, swap the order:compatible = "rockchip,rk3399-rga", "rockchip,rk3328-rga";This preserves the RK3328-specific behavior while using the official binding as the primary match. The patch does not appear to have been upstreamed to Linux 6.18-rc7, so removal is not necessary.
patch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patch (3)
28-36: Addpinctrl-namesfor consistency.The pwm1 and pwm2 nodes are missing the
pinctrl-names = "default"property, while the i2c3 node above includes it. For consistency and to follow device tree best practices, add this property to both PWM nodes.Apply this diff:
&pwm1 { status = "disabled"; + pinctrl-names = "default"; pinctrl-0 = <&pwm1m1_pins>; }; &pwm2 { status = "disabled"; + pinctrl-names = "default"; pinctrl-0 = <&pwm2m1_pins>; };
48-54: Addpinctrl-namesfor multiple UART configurations.The uart1 node defines two pinctrl configurations (basic transfer and transfer with CTS/RTS), as indicated by the comment on line 51, but lacks the
pinctrl-namesproperty. This property is essential for selecting between the basic UART mode and the hardware flow control mode.Apply this diff:
&uart1 { status = "disabled"; dma-names = "tx", "rx"; /* uart1 uart1-with-ctsrts */ + pinctrl-names = "default", "ctsrts"; pinctrl-0 = <&uart1m1_xfer>; pinctrl-1 = <&uart1m1_xfer &uart1m1_ctsn &uart1m1_rtsn>; };
38-46: Fix two device tree property issues in spi0 and uart1 nodes:
Add
pinctrl-names = "default", "high_speed";to label the two pinctrl configurations (spi0 currently has pinctrl-0 and pinctrl-1 without names, and pinctrl-names maps state names to integer state IDs).Rockchip SPI driver reads the
num-csproperty (not underscore), so changenum_chipselecttonum-cs.Same issues apply to the uart1 node (lines 47-54), which also has multiple pinctrl configurations but lacks pinctrl-names.
&spi0 { status = "disabled"; + pinctrl-names = "default", "high_speed"; pinctrl-0 = <&spi0m1_pins>; pinctrl-1 = <&spi0m1_pins_hs>; - num_chipselect = <1>; + num-cs = <1>; cs-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_LOW>; }; &uart1 { status = "disabled"; dma-names = "tx", "rx"; + pinctrl-names = "default", "ctsrts"; /* uart1 uart1-with-ctsrts */ pinctrl-0 = <&uart1m1_xfer>; pinctrl-1 = <&uart1m1_xfer &uart1m1_ctsn &uart1m1_rtsn>; };patch/kernel/archive/rockchip64-6.18/general-v4l2-iep-driver.patch (3)
99-153: DT binding omitsinterrupt-nameswhile DTS nodes use itThe binding sets
additionalProperties: falsebut does not declare aninterrupt-namesproperty, while all new IEP DT nodes provideinterrupt-names = "iep";. This will causedtbs_check/ schema validation warnings or failures.Please either add
interrupt-namesto the binding, or drop it from the DTS nodes. Typically adding it to the binding is preferred.Example binding fix:
properties: compatible: oneOf: - const: rockchip,rk3228-iep - items: - enum: - rockchip,rk3288-iep - rockchip,rk3328-iep - rockchip,rk3368-iep - rockchip,rk3399-iep - const: rockchip,rk3228-iep reg: maxItems: 1 interrupts: maxItems: 1 + + interrupt-names: + items: + - const: iep clocks: maxItems: 2Also applies to: 193-203, 227-236
482-487: Fix logic bug inIEP_DEIN_OUT_MODE_1FRM_TOP_FIELD()(always true condition)
IEP_DEIN_OUT_MODE_1FRM_TOP_FIELDis currently:#define IEP_DEIN_OUT_MODE_1FRM_TOP_FIELD(m) (m == IEP_DEIN_MODE_I4O1T || IEP_DEIN_MODE_I2O1T \ ? 1 : 0)Because the second operand of
||lacksm ==, this effectively becomes(m == IEP_DEIN_MODE_I4O1T || 5 ? 1 : 0)and will always evaluate to1. Even if it’s not used today, this is a latent logic bug.Suggested fix (also tightening parentheses and types):
-#define IEP_DEIN_OUT_MODE_1FRM_TOP_FIELD(m) (m == IEP_DEIN_MODE_I4O1T || IEP_DEIN_MODE_I2O1T \ - ? 1 : 0) +#define IEP_DEIN_OUT_MODE_1FRM_TOP_FIELD(m) \ + (((m) == IEP_DEIN_MODE_I4O1T || (m) == IEP_DEIN_MODE_I2O1T) ? 1U : 0U)Additionally, consider double‑checking
IEP_SRC_RGB_SWP_MASK:#define IEP_SRC_RGB_SWP_MASK (2 << IEP_SRC_RGB_SWP_SHFT)If the RGB swap field is two bits wide (three values:
XRGB,XBGR,BGRX), the mask likely wants3 << IEP_SRC_RGB_SWP_SHFTsoiep_shadow_mod()can reliably update both bits when RGB formats are added later.Also applies to: 521-535, 572-573
1412-1434: Probe continues after clock/DT parse failure, risking runtime crash
iep_parse_dt()returns an error ifdevm_clk_get()fails (e.g. missing or misspelled clocks in DT), butiep_probe()only logs and continues:ret = iep_parse_dt(iep); if (ret) dev_err(&pdev->dev, "Unable to parse OF data\n");If clocks are missing,
iep->axi_clk/iep->ahb_clkremainERR_PTR(...), yet lateriep_runtime_resume()callsclk_prepare_enable()on them, which can crash the kernel.
iep_probe()should bail out ifiep_parse_dt()fails. Example fix:ret = iep_parse_dt(iep); - if (ret) - dev_err(&pdev->dev, "Unable to parse OF data\n"); + if (ret) { + dev_err(&pdev->dev, "Unable to parse OF data\n"); + return ret; + }If you intentionally want to treat
clk_set_rate()failures as non‑fatal, you can adjustiep_parse_dt()to return0in that specific case and only propagate truly fatal errors.Also applies to: 1519-1522
patch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch (5)
420-547: Guard shared-memory initialization failures in DDR SIP v2 helpersIn
clk-ddr.c,rockchip_ddrclk_data_init()and the v2 helpers assumeROCKCHIP_SIP_SHARE_MEMandioremap()always succeed:
- If the SMC returns an error (
res.a0 != 0) orioremap()fails,ddr_data.share_memoryremainsNULLandddr_data.inited_flagstays 0.rockchip_ddrclk_sip_set_rate_v2()/rockchip_ddrclk_sip_round_rate_v2()then callrockchip_ddrclk_data_init()but unconditionally dereferenceddr_data.share_memoryviastruct share_params *p, which can lead to a NULL‑pointer dereference in kernel context.Consider explicitly checking both SMC and
ioremap()results and bailing out cleanly from the v2 ops when initialization fails. For example:static void rockchip_ddrclk_data_init(void) { struct arm_smccc_res res; arm_smccc_smc(ROCKCHIP_SIP_SHARE_MEM, 1, SHARE_PAGE_TYPE_DDR, 0, 0, 0, 0, 0, &res); - if (!res.a0) { - ddr_data.share_memory = (void __iomem *)ioremap(res.a1, 1<<12); - ddr_data.inited_flag = 1; - } + if (!res.a0) { + ddr_data.share_memory = ioremap(res.a1, 1 << 12); + if (ddr_data.share_memory) + ddr_data.inited_flag = 1; + } } static int rockchip_ddrclk_sip_set_rate_v2(struct clk_hw *hw, unsigned long drate, unsigned long prate) { struct share_params *p; struct arm_smccc_res res; - if (!ddr_data.inited_flag) - rockchip_ddrclk_data_init(); - - p = (struct share_params *)ddr_data.share_memory; + if (!ddr_data.inited_flag) + rockchip_ddrclk_data_init(); + if (!ddr_data.inited_flag || !ddr_data.share_memory) + return -EIO; + + p = ddr_data.share_memory; @@ static long rockchip_ddrclk_sip_round_rate_v2(struct clk_hw *hw, unsigned long rate, unsigned long *prate) { struct share_params *p; struct arm_smccc_res res; - if (!ddr_data.inited_flag) - rockchip_ddrclk_data_init(); - - p = (struct share_params *)ddr_data.share_memory; + if (!ddr_data.inited_flag) + rockchip_ddrclk_data_init(); + if (!ddr_data.inited_flag || !ddr_data.share_memory) + return -EIO; + + p = ddr_data.share_memory;This prevents hard crashes if secure firmware doesn’t support the share‑mem call or returns an error.
Also applies to: 551-557
1523-1567: Critical:platform_set_drvdatais too late for devfreq callbacksIn
rk3328_dmcfreq_probe()you call:
rk3328_dmc_init(pdev, data);rk3328_devfreq_init(data);→ internally callsdevm_devfreq_add_device(dev, &rk3328_devfreq_dmc_profile, ...)platform_set_drvdata(pdev, data);All devfreq profile callbacks (
rk3328_dmcfreq_target,_get_dev_status,_get_cur_freq, suspend/resume) obtain theirrk3328_dmcfreqviadev_get_drvdata(dev). Duringdevm_devfreq_add_device(), devfreq may immediately invoke these callbacks (e.g. to set the initial rate), but at that pointplatform_set_drvdata()has not yet run, sodev_get_drvdata(dev)returnsNULLand the callbacks will dereference a NULL pointer → kernel crash.Fix is to register the driver data before any devfreq activity:
static int rk3328_dmcfreq_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct rk3328_dmcfreq *data; int ret; data = devm_kzalloc(dev, sizeof(struct rk3328_dmcfreq), GFP_KERNEL); if (!data) return -ENOMEM; mutex_init(&data->lock); data->dev = dev; + + /* Make dev_get_drvdata(dev) usable for devfreq callbacks */ + platform_set_drvdata(pdev, data); @@ ret = rk3328_dmc_init(pdev, data); if (ret) return ret; ret = rk3328_devfreq_init(data); if (ret) return ret; - - platform_set_drvdata(pdev, data); - - return 0; + return 0; }This ensures all devfreq callbacks see a valid
rk3328_dmcfreqinstance from the start.
1279-1339:ROCKCHIP_SIP_CONFIG_DRAM_GET_VERSIONopcode collision: must use a different value than0x08The verification reveals a critical flaw in the patch:
ROCKCHIP_SIP_CONFIG_DRAM_GET_VERSIONis defined as0x08, which is already assigned toROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD. This opcode collision means calls tork3328_dmc_init()at line 1299 will invoke the wrong SMC sub-command in TF-A, causing the version check to fail and return-ENXIOas the original review predicted.The constant definition at line 1884 needs correction to a unique opcode value that matches the TF-A firmware's actual
DRAM_GET_VERSIONsub-command.
637-760: Add NULL-safety guards for clock operations on RK3228/RK3328 pathsVerification confirms the critical concern:
rockchip_dfi_enable()contains unconditional calls toclk_prepare_enable(dfi->clk)(line 181) andclk_disable_unprepare(dfi->clk)(line 243) without NULL checks. Settingdfi->clk = NULLinrk3228_dfi_init()andrk3328_dfi_init()will cause NULL-pointer dereference when the device is used.Fix options:
- Add
IS_ERR_OR_NULL()guards around clock operations inrockchip_dfi_enable()and any other locations that unconditionally usedfi->clk.- Alternatively, use
devm_clk_get_optional()for RK3228/RK3328 instead of settingdfi->clk = NULL, ensuring consistent error-pointer semantics.
1877-1895: ---Fix opcode value conflict:
ROCKCHIP_SIP_CONFIG_DRAM_GET_VERSIONcannot share opcode 0x08 withROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PDVerification confirms the issue:
ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD = 0x08is the established command in Linux mainline and Rockchip TF‑A. There is noROCKCHIP_SIP_CONFIG_DRAM_GET_VERSIONdefined in the Linux mainlineinclude/soc/rockchip/rockchip_sip.hor in the Rockchip TF‑A DDR SMC handler.The patch introduces
GET_VERSIONas a new custom command but assigns it the same opcode (0x08). This creates an ambiguous alias where the firmware cannot distinguish between the two operations.Either assign a unique opcode value to
ROCKCHIP_SIP_CONFIG_DRAM_GET_VERSION(e.g., 0x09 or higher), or provide firmware documentation confirming that 0x08 is multi-function with explicit disambiguation logic.patch/kernel/archive/meson64-6.18/general-input-touchscreen-Add-D-WAV-Multitouch.patch (1)
575-587: Freedwav_usb_mt->fingerin error and disconnect paths (leaks on unplug/failure)In
dwav_usb_mt_probe()you allocatedwav_usb_mt->fingerwithkzalloc(), but it is never freed in either the error path (err_free_mem:) ordwav_usb_mt_disconnect(). Only the maindwav_usb_mtstruct iskfree()’d, so each failed probe or unplug/replug sequence leaks the finger array.A minimal fix that keeps the vendor code structure intact:
@@ -581,8 +581,10 @@ err_free_buffers: err_free_mem: if (input_dev) input_free_device(input_dev); - kfree(dwav_usb_mt); + kfree(dwav_usb_mt->finger); + kfree(dwav_usb_mt); @@ -605,8 +607,10 @@ static void dwav_usb_mt_disconnect(struct usb_interface *intf) usb_free_urb(dwav_usb_mt->irq); dwav_usb_mt_free_buffers(interface_to_usbdev(intf), dwav_usb_mt); - - kfree(dwav_usb_mt); + + kfree(dwav_usb_mt->finger); + kfree(dwav_usb_mt); }This closes the leak on both early‑error and normal disconnect while leaving the rest of the driver logic unchanged. Based on learnings, this keeps the patch very close to the original vendor implementation and only fixes a real resource‑management bug.
Also applies to: 589-610
🧹 Nitpick comments (6)
patch/kernel/archive/rockchip64-6.18/general-v4l2-iep-driver.patch (1)
1722-1724:IEP_TIMEOUTunits/comment mismatch
IEP_TIMEOUTis commented as nanoseconds://ns #define IEP_TIMEOUT 250000but is passed as the
timeout_usargument toreadl_poll_timeout(), which expects microseconds. That makes this a 250 ms timeout, not 250 µs or 250 ns.To avoid confusion, either adjust the comment or rename/scale the constant, for example:
-//ns -#define IEP_TIMEOUT 250000 +/* timeout for status idle, in microseconds (250 ms) */ +#define IEP_TIMEOUT 250000patch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch (1)
1438-1521: Devfreq init: minor robustness tweaks around OPP/regulator setup
rk3328_devfreq_init():
- Treats operating-points-v2 as optional (early‑exit if missing), which is good.
- Binds OPPs to
"dmc_clk"and an optional"center"regulator, handling-ENODEVgracefully.- Uses
devfreq_recommended_opp()to setinitial_freqand registers devfreq withDEVFREQ_GOV_SIMPLE_ONDEMAND, then registers a cooling device.Two small robustness suggestions:
- Initialize
cur_freqto the actual current DMC clock rate (clk_get_rate(rdev->dmc_clk)) instead of 0 before callingdevfreq_recommended_opp(), to pick the nearest valid OPP to hardware reality.- Consider logging a warning (once) if
devm_pm_opp_of_add_table()ordevfreq_recommended_opp()fail, to aid debugging misconfigured DTs.These are non‑blocking refinements.
patch/kernel/archive/rockchip64-6.18/rk3328-inno-usb3phy-driver.patch (4)
455-459: IncompletePIPE_REG_160define is dead code and can be cleaned up
#define PIPE_REG_160has no value and is not used anywhere in the driver. It’s harmless but confusing.Consider either giving it the intended address or dropping it entirely until it’s actually used:
-/* default 0x0d4 */ -#define PIPE_REG_160 +/* default 0xd4 (reserved for future tuning; currently unused) */ +/* #define PIPE_REG_160 0x160 */or simply:
-/* default 0x0d4 */ -#define PIPE_REG_160 +/* default 0xd4: register reserved for future tuning (not used yet) */
544-556: Use logical OR instead of bitwise OR in rate range checkFunctionally
|works here because the operands are boolean, but||is the conventional and clearer choice for range checks:- } else if ((rate < 48) | (rate > 16000)) { + } else if (rate < 48 || rate > 16000) {This avoids any future confusion if the expression is extended.
588-605: Tighten error handling inrockchip_usb3phy_initand avoid noisydev_warnTwo minor quality issues here:
dev_warn()on everyphy_init()call will spam logs for normal operation;dev_dbg()(or dropping the message) is more appropriate.- The return value from
rockchip_usb3phy_bulk_update()(UTMI tuning) is currently ignored; if register access fails,phy_init()still reports success.Suggested tweak:
- dev_warn(usb3phy->dev, "usb3phy_init %s\n", dev_name(&phy->dev)); + dev_dbg(usb3phy->dev, "usb3phy_init %s\n", dev_name(&phy->dev)); @@ -594,11 +594,14 @@ static int rockchip_usb3phy_init(struct phy *phy) if (port->type == USB3PHY_TYPE_USB2) { @@ - ret = rockchip_usb3phy_bulk_update(usb3phy, port->regmap, rk3328_utmi_config, - ARRAY_SIZE(rk3328_utmi_config)); + ret = rockchip_usb3phy_bulk_update(usb3phy, port->regmap, + rk3328_utmi_config, + ARRAY_SIZE(rk3328_utmi_config)); + if (ret) + return ret; }You may also want to check
retafter the SSC / TX / pipe power bulk updates for the USB3 path, for consistency.
588-605: Balanceclk_refenable/disable across init/exit
rockchip_usb3phy_init()callsclk_prepare_enable(usb3phy->clk_ref)on everyphy_init()butrockchip_usb3phy_exit()never callsclk_disable_unprepare()forclk_ref. For long‑running systems or repeated init/exit cycles, this can leave the reference clock permanently enabled.If there isn’t a strong reason to keep
clk_refalways-on, consider:static int rockchip_usb3phy_init(struct phy *phy) { @@ - clk_prepare_enable(usb3phy->clk_ref); + ret = clk_prepare_enable(usb3phy->clk_ref); + if (ret) + return ret; @@ static int rockchip_usb3phy_exit(struct phy *phy) { @@ dev_dbg(usb3phy->dev, "usb3phy_shutdown\n"); rockchip_usb3phy_reset(usb3phy, true, port->type); + clk_disable_unprepare(usb3phy->clk_ref);If the design assumes
clk_refshould stay on for the lifetime of the PHY block, it’d be good to add a short comment stating that so future readers don’t treat this as an accidental leak.Also applies to: 970-979
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (13)
config/sources/mainline-kernel.conf.sh(1 hunks)patch/kernel/archive/meson64-6.18/general-input-touchscreen-Add-D-WAV-Multitouch.patch(2 hunks)patch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/general-v4l2-iep-driver.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/media-0001-Add-rkvdec-Support-v5.patch(2 hunks)patch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/rk3328-dtsi-spdif.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/rk3328-dtsi-usb3-reset-properties.patch(1 hunks)patch/kernel/archive/rockchip64-6.18/rk3328-inno-usb3phy-driver.patch(2 hunks)patch/kernel/archive/rockchip64-6.18/rk3576-0004-arch-arm64-dts-rockchip-remove-overclocked-CPU-OPP-t.patch(0 hunks)
💤 Files with no reviewable changes (1)
- patch/kernel/archive/rockchip64-6.18/rk3576-0004-arch-arm64-dts-rockchip-remove-overclocked-CPU-OPP-t.patch
👮 Files not reviewed due to content moderation or server errors (1)
- patch/kernel/archive/rockchip64-6.18/media-0001-Add-rkvdec-Support-v5.patch
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/kernel/archive/rockchip64-6.18/rk3328-dtsi-usb3-reset-properties.patchpatch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patchpatch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patchpatch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patchpatch/kernel/archive/rockchip64-6.18/general-v4l2-iep-driver.patchpatch/kernel/archive/rockchip64-6.18/media-0001-Add-rkvdec-Support-v5.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patchpatch/kernel/archive/rockchip64-6.18/rk3328-inno-usb3phy-driver.patch
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patchpatch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patchpatch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch
📚 Learning: 2025-09-14T06:32:29.806Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Applied to files:
patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patchpatch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patchpatch/kernel/archive/rockchip64-6.18/general-v4l2-iep-driver.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch
📚 Learning: 2025-03-31T22:20:48.475Z
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Applied to files:
patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patch
📚 Learning: 2025-03-31T22:20:41.849Z
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:73-75
Timestamp: 2025-03-31T22:20:41.849Z
Learning: When porting patches between U-Boot versions (like from 2025.01 to 2025.04), rpardini prefers to maintain patches as-is rather than introducing refactoring changes, even when potential improvements are identified. This approach prioritizes consistency and reduces the risk of introducing new issues.
Applied to files:
patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patch
📚 Learning: 2025-11-15T14:33:30.654Z
Learnt from: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.
Applied to files:
patch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patchpatch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patchpatch/kernel/archive/rockchip64-6.18/media-0001-Add-rkvdec-Support-v5.patchpatch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patchpatch/kernel/archive/rockchip64-6.18/rk3328-inno-usb3phy-driver.patch
📚 Learning: 2025-11-10T23:44:53.363Z
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-11-10T23:44:53.363Z
Learning: For the RV1106 family in Armbian (config/sources/families/rockchip-rv1106.conf), udev.children-max=1 is set in the kernel boot parameters to prevent early-boot OOM errors. The RV1106 has a single-core CPU, so parallelism in udev child processes provides no practical benefit. Testing higher values is impractical due to the difficulty of monitoring at this early boot stage.
Applied to files:
patch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patch
📚 Learning: 2025-10-22T07:51:53.015Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
Applied to files:
patch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patch
📚 Learning: 2025-04-30T16:16:47.150Z
Learnt from: The-going
Repo: armbian/build PR: 8147
File: config/sources/families/include/sunxi64_common.inc:38-39
Timestamp: 2025-04-30T16:16:47.150Z
Learning: The Armbian build system references Linux kernel versions in the form "tag:v6.14.4" in the KERNELBRANCH variable, even when point release tags might not be directly visible in the upstream repository in the same form.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-07-21T04:12:02.439Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-11-10T22:05:40.490Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-06-25T03:42:09.086Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-09-11T06:06:52.328Z
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-11-02T20:49:56.719Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-09-14T06:10:25.610Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Applied to files:
patch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patch
🧬 Code graph analysis (1)
config/sources/mainline-kernel.conf.sh (2)
config/sources/vendors/microsoft/wsl2.hooks.sh (1)
post_family_config_branch_current__wsl2(14-19)lib/functions/artifacts/artifact-kernel.sh (1)
artifact_kernel_prepare_version(28-216)
🔇 Additional comments (28)
patch/kernel/archive/rockchip64-6.18/rk3328-add-rga-node.patch (1)
1-9: LGTM: Patch metadata is correct.The patch header follows the standard git format-patch structure with appropriate metadata.
patch/kernel/archive/rockchip64-6.18/rk3328-dtsi-spdif.patch (2)
91-104: No issues found. Clock arrays are properly aligned and configuration is valid.The patch correctly adds one entry to both
assigned-clocksandassigned-clock-ratesarrays (now 8 entries each), maintaining proper alignment. The absence of an addition toassigned-clock-parentsis valid—device tree clock bindings allow this array to be shorter when clocks don't require parent reassignment. The 500 MHz clock rate for ACLK_GPU is a standard and reasonable frequency for GPU operation on ARM SoCs.
68-87: No issues found — spdif hardware node exists in upstream kernel v6.18.The
<&spdif>phandle reference at line 80 is valid. The upstream Linux kernel v6.18 includes the spdif hardware controller node (spdif@ff030000with compatible"rockchip,rk3328-spdif") inarch/arm64/boot/dts/rockchip/rk3328.dtsi, which the patch correctly references. The added nodes (spdif_out and spdif_sound) follow the standard device tree audio binding patterns and are properly disabled by default.patch/kernel/archive/rockchip64-6.18/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patch (2)
22-26: LGTM!The i2c3 node is properly configured with pinctrl settings and disabled status for overlay support.
22-54: Verify all pinctrl node references exist in RK3568 base dtsi.All pinctrl references in the patch (i2c3m1_xfer, pwm1m1_pins, pwm2m1_pins, spi0m1_pins, spi0m1_pins_hs, uart1m1_xfer, uart1m1_ctsn, uart1m1_rtsn) follow standard RK3568 naming conventions and are documented in the upstream Linux kernel's rk3568-pinctrl.dtsi. These pinctrl definitions exist in arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi. The patch correctly adds device tree nodes that reference these standard pinctrl definitions. No invalid references detected.
patch/kernel/archive/rockchip64-6.18/rk3328-add-dmc-driver.patch (13)
29-339: rk3328-dram-default-timing.dtsi looks internally consistentThe DDR timing/de‑skew table and use of the new dt‑bindings appear self‑consistent and match the expected rk3328 layout; no functional issues spotted here.
344-408: DFI/DMC DT nodes and OPP table wiring are coherent
dfianddmcnodes (reg ranges,rockchip,grf/devfreq-eventsphandle,clocks = <&cru SCLK_DDRCLK>withclock-names = "dmc_clk", andoperating-points-v2 = <&dmc_opp_table>) line up with the rk3328 DFI and DMC drivers; disabled high‑frequency OPPs are also correctly markedstatus = "disabled".
565-587: RK3328 DDR clock rewire via COMPOSITE_DDRCLK looks correctSwitching from a generic
COMPOSITE()DDR clock toCOMPOSITE_DDRCLK(SCLK_DDRCLK, "sclk_ddrc", ...)withROCKCHIP_DDRCLK_SIP_V2, and reparentingclk_ddrmsch,clk_ddrupctl, andaclk_ddrupctlto"sclk_ddrc"matches the new SIP v2 path and theclocks = <&cru SCLK_DDRCLK>DT wiring. No inconsistencies spotted.
766-1277: rk3328_dmc timing parsing and de‑skew mapping are structurally soundThe
share_paramslayout,rk3328_ddr_dts_config_timing/rk3328_ddr_de_skew_settingstructures, and the variousrk3328_dts_*_timingname arrays match up in size and usage:
of_get_rk3328_timings()reads all required timing and de‑skew properties into a temporaryde_skewstruct and only callsrk3328_de_skew_setting_2_register()when all reads succeed.- The de‑skew mapping logic for CA, CS0, and CS1 uses consistent indexing and bit‑packing into
ca_skew[],cs0_skew[],cs1_skew[], then marksdts_timing->available = 1on success.Given this mirrors vendor BSP logic and operates on ATF‑backed shared memory, the overall structure looks correct.
1341-1395: Devfreq profile implementation for rk3328 DMC is standard
rk3328_dmcfreq_target(),rk3328_dmcfreq_get_dev_status(), andrk3328_dmcfreq_get_cur_freq()follow the devfreq conventions:
- Use
devfreq_recommended_opp()+dev_pm_opp_set_rate()intarget().- Pull utilization from DFI via
devfreq_event_get_event()inget_dev_status().- Use an internal
ratecache forget_cur_freq().Once the probe bug (see below) is fixed so
dev_get_drvdata(dev)is valid, these callbacks look correct.
1396-1437: Suspend/resume hooks correctly coordinate devfreq and devfreq-eventThe
SIMPLE_DEV_PM_OPSsuspend/resume paths disable/enable the DFI devfreq‑event device and suspend/resume the devfreq instance in the right order. No issues noted here.
1570-1580: Remove path correctly tears down devfreq and cooling
rk3328_dmcfreq_remove()delegates tork3328_devfreq_fini(), which safely unregisters the cooling device and devfreq instance if present; this matches the devm‑based allocations inrk3328_devfreq_init(). No issues here.
1582-1587: OF match table and driver registration are minimal and correctThe OF compatible
rockchip,rk3328-dmcand therk3328_dmcfreq_driverregistration (name, PM ops, of_match_table) align with the DT additions and the rest of the driver.
1603-1671: DDR dt-bindings header matches timing DTS usage
include/dt-bindings/clock/rockchip-ddr.hdefines the DDR3/DDR4 speed bin constants (DDR3_DEFAULT,DDR4_DEFAULT, etc.) used inrk3328-dram-default-timing.dtsiand introducesPAUSE_CPU_STACK_SIZE, matching typical Rockchip BSP headers. The values are self‑consistent and not used in a way that looks problematic in this patch set.
1672-1835: RK3328 DRAM dt-bindings header is consistent with DDR timing usage
include/dt-bindings/memory/rk3328-dram.hdefines drive strengths, ODT values, and PHY RON/RTT constants referenced throughoutrk3328-dram-default-timing.dtsi. The naming and ranges are in line with Rockchip’s existing DRAM bindings, and there are no obvious inconsistencies in how these enums are used in the DTS.
1837-1856: rk3228_grf.h and rk3328_grf.h headers are minimal and correctly wiredThe new GRF headers:
- Define
RK3228_GRF_OS_REG2/RK3328_GRF_OS_REG2and their*_DDRTPYEbitfields viaGENMASK(15, 13).- Are included only by
drivers/devfreq/event/rockchip-dfi.cin this patch and used to extractdfi->ddr_type.Definitions are minimal and correct for this use.
Also applies to: 1857-1876
602-620: Review comment is based on outdated assumptions; no changes neededCurrent mainline Linux shows
ARM_RK3399_DMC_DEVFREQdepends only onARCH_ROCKCHIP(withoutHAVE_ARM_SMCCC), contrary to the premise of this review. The RK3328 config in the patch already aligns with current mainline practice. The suggested dependency change would introduce an inconsistency rather than resolve one.Likely an incorrect or invalid review comment.
591-598: Review concern about bitwise operations does not apply to actual code usageThe flags are used exclusively in a switch statement (
case ROCKCHIP_DDRCLK_SIP:at line 552,case ROCKCHIP_DDRCLK_SIP_V2:at line 555) where they are treated as discrete enum values, not as bitmasks. No bitwise AND operations (ddr_flag & ROCKCHIP_DDRCLK_SIP) exist in the patch. The change fromBIT(0)to0x01is purely stylistic (identical value), andROCKCHIP_DDRCLK_SIP_V2 = 0x03receives its own dedicated case statement with no risk of unintended matches.Likely an incorrect or invalid review comment.
patch/kernel/archive/rockchip64-6.18/general-rk3328-dtsi-trb-ent-quirk.patch (1)
51-57: XHCI TRB ENT quirk wiring for rk3328 looks correctThe new
snps,xhci-trb-ent-quirk;flag is added to the rightusbdrd3node and is consistent with the other Synopsys xHCI quirk properties; no functional issues spotted.config/sources/mainline-kernel.conf.sh (1)
10-12: 6.18 RC bump to v6.18-rc7 is scoped and consistentThe hook still only overrides when
KERNEL_MAJOR_MINOR=="6.18"andKERNELBRANCHis empty, and the TODO uses the generic “MAJOR.MINOR-rc1” pattern preferred for recurring bumps.patch/kernel/archive/rockchip64-6.18/rk3328-dtsi-usb3-reset-properties.patch (1)
14-20: USB3 OTG reset phandles are wired as expected
resets = <&cru SRST_USB3OTG>;andreset-names = "usb3-otg";are added to the correctusbdrd3node and follow the standard Rockchip CRU reset binding pattern; nothing problematic here.patch/kernel/archive/rockchip64-6.18/board-orangepi5-sata-supply.patch (1)
21-37: Confirm vcc3v3_pcie20 is actually a 3.3 V rail for SATAThe new
&sata0 { sata-port@0 { target-supply = <&vcc3v3_pcie20>; }; };wiring matches the AHCI binding and the archeology comment (“SATA power via vcc3v3_pcie20; set to 3.3V”), but this patch now only adds the SATA node.Please verify in your 6.18 kernel source that
vcc3v3_pcie20is already configured as 3.3 V (min/max 3300000 µV). If it’s still at 1.8 V in that tree, SATA power will be undervolted and you’ll want to adjust the regulator there or reintroduce the voltage change.patch/kernel/archive/meson64-6.18/general-input-touchscreen-Add-D-WAV-Multitouch.patch (1)
15-40: HID IDs/quirks and Kconfig/Makefile wiring look consistent; test interaction with generic HIDThe new ODROID/D‑WAV IDs in
hid-ids.h, the added entries inhid_ignore_list, and theTOUCHSCREEN_DWAV_USB_MTKconfig + Makefile hook all line up and mirror how vendor trees integrate this driver.Because these devices were previously handled by generic HID (
hid-multitouch/usbhid) in many distros, it’s worth explicitly testing that:
- The ODROID VU5/VU7+ devices now bind to
dwav_usb_mtas intended.- There are no regressions compared to
hid-multitouch(gestures, calibration, suspend/resume).- There are no remaining devices with the same VID:PID that should stay on the generic HID path.
Also applies to: 47-61, 66-71
patch/kernel/archive/rockchip64-6.18/rk3328-inno-usb3phy-driver.patch (5)
21-187: DT binding forrockchip,rk3328-usb3phylooks consistent and completeThe YAML describes the top-level PHY and
utmi-port/pipe-portchildren in a way that matches the driver expectations (clocks, resets, interrupt-names, child compatibles,#phy-cells, example node). No issues from a schema/driver-alignment perspective.
191-241: rk3328.dtsi integration of usb3phy and wiring intousbdrd3is coherentThe new
usb3phynode and itsutmi-port/pipe-portchildren match the binding, and theusbdrd3node’sphys/phy-namescorrectly reference them. The register ranges and clocks/resets line up with the driver’s DT parsing code.
248-273: Kconfig/Makefile wiring for PHY_ROCKCHIP_INNO_USB3 is correctThe new Kconfig symbol has sensible dependencies (
ARCH_ROCKCHIP || COMPILE_TEST,COMMON_CLK,USB_SUPPORT) and selects the expected helpers, and the Makefile line cleanly hooksphy-rockchip-inno-usb3.ointo the Rockchip PHY build. Nothing to change here.
653-968: DT parsing and IRQ setup align with the binding and look solidClock, reset, and IRQ retrieval (
devm_clk_get,devm_reset_control_get,of_irq_get_bynameanddevm_request_threaded_irq) all use names that match the new binding and rk3328.dtsi snippet. Error paths propagate failures cleanly. No functional issues spotted here.
1017-1131: Probe sequence and PHY provider registration are reasonableProbe allocates state, maps the core block once, asserts/deasserts resets in a sane order, sets up per-port regmaps/PHYs for
utmi-portandpipe-port, and registers an OF PHY provider. The bounds check againstUSB3PHY_TYPE_MAXpreventsports[]overflow. Overall this hooks the block into the generic PHY framework cleanly.
|
✅ This PR has been reviewed and approved — all set for merge! |
igorpecovnik
added
02
|
Nice, thanks! |
|
@rpardini could you test loong64? I don't have a sid environment available. |
4 participants
Description
pending:
How Has This Been Tested?
Checklist: