* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-25 12:54 UTC (permalink / raw)
To: syyang, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, yangsunyun1993, xmzhu, xmzhu, rlyu,
xbpeng
In-Reply-To: <20260508134009.4582-3-syyang@lontium.com>
On 08/05/2026 15:40, syyang@lontium.com wrote:
> +
> +static void lt9611c_reset(struct lt9611c *lt9611c)
> +{
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> + msleep(20);
> +
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> + msleep(20);
> +
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
This is just plain wrong. Why do you assert, then de-assert and then
finally assert AGAIN the reset leaving the device in powerdown stage?
> + msleep(400);
> +
> + dev_dbg(lt9611c->dev, "lt9611c reset");
Drop such debug statements. This is some downstream, semi-useless code.
You are not supposed to add debug to every call.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Frank Li @ 2026-06-25 12:42 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, conor+dt, devicetree, linux-hwmon, linux-i3c, robh,
sashiko-reviews
In-Reply-To: <20260625093815.1794492-1-akhilrajeev@nvidia.com>
On Thu, Jun 25, 2026 at 09:38:15AM +0000, Akhil R wrote:
> On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
> ...
> ...
> >> [Severity: High]
> >> Is it possible that sending the SETAASA broadcast before direct SETDASA
> >> assignments breaks initialization for devices that natively support SETAASA
> >> but are configured for SETDASA?
> >>
> >> According to the I3C specification, any device on the bus natively supporting
> >> SETAASA will respond to this broadcast by adopting its static address as its
> >> dynamic address.
> >>
> >> After this broadcast, the driver iterates through devices and attempts to
> >> assign custom dynamic addresses via direct SETDASA commands:
> >>
> >> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
> >> ...
> >> ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> >> i3cdev->boardinfo->init_dyn_addr);
> >> ...
> >> }
> >>
> >> Since the target device already adopted its dynamic address during the
> >> SETAASA broadcast, it is no longer in the unassigned state and will NACK
> >> the subsequent SETDASA command.
> >
> > Look like correct, but I am not sure if target will NACK SETDASA. Or should
> > use SETNEWDA for SETAASA method.
>
> Yes, this looks valid for mixed device buses. I can move
> i3c_master_setaasa_locked() after the SETDASA handling and before
> i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
> ignore the later SETAASA broadcast. Does that sound good to you?
yes, try it to follow spec.
Frank
>
> Best Regards,
> Akhil
^ permalink raw reply
* Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
From: Parthiban.Veerasooran @ 2026-06-25 12:36 UTC (permalink / raw)
To: Selvamani.Rajagopal, andrew+netdev, davem, edumazet, kuba, pabeni,
robh, krzk+dt, conor+dt, Pier.Beruto
Cc: andrew, netdev, linux-kernel, Conor.Dooley, devicetree
In-Reply-To: <CYYPR02MB9828E1167750AEA090EC60CD83EE2@CYYPR02MB9828.namprd02.prod.outlook.com>
Hi Selvamani,
On 23/06/26 11:18 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> -----Original Message-----
>> From: Parthiban.Veerasooran@microchip.com <Parthiban.Veerasooran@microchip.com>
>> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
>> triggered.
>>
>>
>> I will find some time this week to test and share my feedback. In the
>> meantime, would it be possible for you to test using two instances (Test
>> Case 2)? I did not encounter many issues when testing with a single
>> instance.
>>
>> I believe that testing with two instances increases the likelihood of
>> reproducing the issue in your setup as well.
>
> Parthiban,
>
> Thanks.
>
> Our EVB design allows only one board to be connected to one Raspberry Pi.
> So, I don't think I can have a setup like yours. We did test with three Raspberry Pi boards with
> multi-drop connection. Couldn't see your "NULL pointer" crash. Will keep trying though.
Thank you for the update. So it seems you can't connect two of your
MAC-PHYs in one RPI 4? RPI 4 can support two SPI devices (MAC-PHYs).
https://patchwork.kernel.org/project/netdevbpf/list/?series=1114495&state=%2A&archive=both
https://patchwork.kernel.org/project/netdevbpf/patch/20260621-fix-race-condition-and-crash-v1-1-87e290d9357f@onsemi.com/
https://patchwork.kernel.org/project/netdevbpf/patch/20260621-fix-race-condition-and-crash-v1-2-87e290d9357f@onsemi.com/
With your above patches, I did a quick test (Test case 2) with two
Microchip MAC-PHYs and faced a similar issue reported before. Sharing
the dmesg crash log for your reference.
[ 2863.182105] eth1: Receive buffer overflow error
[ 2863.199905] eth1: Receive buffer overflow error
[ 2867.669312] Unable to handle kernel NULL pointer dereference at
virtual address 00000000000000b8
[ 2867.677658] Mem abort info:
[ 2867.680474] ESR = 0x0000000096000005
[ 2867.684258] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2867.689630] SET = 0, FnV = 0
[ 2867.692717] EA = 0, S1PTW = 0
[ 2867.695888] FSC = 0x05: level 1 translation fault
[ 2867.700825] Data abort info:
[ 2867.703726] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 2867.709303] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 2867.714399] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 2867.719773] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000113c2e000
[ 2867.726296] [00000000000000b8] pgd=0000000000000000,
p4d=0000000000000000, pud=0000000000000000
[ 2867.735109] Internal error: Oops: 0000000096000005 [#1] SMP
[ 2867.740830] Modules linked in: lan865x_t1s(O) microchip_t1s(O) sch_fq
snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfcomm algif_hash
aes_neon_bs algif_skcipher af_alg bnep binfmt_misc brcmfmac_cyw brcmfmac
hci_uart brcmutil btbcm bluetooth vc4 cfg80211 snd_soc_hdmi_codec
drm_exec ecdh_generic ecc drm_display_helper cec rfkill bcm2835_codec(C)
drm_dma_helper v3d rpi_hevc_dec drm_client_lib bcm2835_v4l2(C) gpu_sched
drm_shmem_helper crc_ccitt bcm2835_isp snd_soc_core drm_kms_helper
bcm2835_mmal_vchiq v4l2_mem2mem vc_sm_cma videobuf2_vmalloc
videobuf2_dma_contig raspberrypi_hwmon videobuf2_memops snd_compress
snd_bcm2835(C) videobuf2_v4l2 snd_pcm_dmaengine i2c_brcmstb snd_pcm
snd_timer videodev videobuf2_common snd mc raspberrypi_gpiomem
spi_bcm2835 gpio_fan nvmem_rmem sch_fq_codel i2c_dev zram lz4_compress
drm fuse drm_panel_orientation_quirks backlight nfnetlink [last
unloaded: microchip_t1s(O)]
[ 2867.821558] CPU: 3 UID: 0 PID: 2808 Comm: irq/59-spi0.0 Tainted: G
C O 7.1.0-rc7-v8+ #2 PREEMPT
[ 2867.831779] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 2867.836183] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 2867.842088] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 2867.849138] pc : oa_tc6_update_rx_skb+0x2c/0xa8 [lan865x_t1s]
[ 2867.854955] lr : oa_tc6_macphy_threaded_irq+0x430/0x870 [lan865x_t1s]
[ 2867.861476] sp : ffffffc083dbbd20
[ 2867.864825] x29: ffffffc083dbbd20 x28: 000000003e002020 x27:
ffffffed1cf609c8
[ 2867.872051] x26: 0000000000000000 x25: 0000000000000001 x24:
ffffff8040796480
[ 2867.879277] x23: 000000002020003e x22: 0000000000000000 x21:
0000000000000040
[ 2867.886504] x20: ffffff804a479080 x19: ffffff8040796480 x18:
00000000000982f8
[ 2867.893731] x17: ffffff80482d6500 x16: ffffffed1d87b6b0 x15:
ffffff8041a43c00
[ 2867.900957] x14: 0000000000000016 x13: 0000073d6a5d38dc x12:
00000000001d4ebe
[ 2867.908184] x11: 00000000000000c0 x10: 0000000000001ae0 x9 :
ffffffecc9c959e8
[ 2867.915410] x8 : ffffff804f1e5a40 x7 : 0000000000000002 x6 :
ffffffffffffffff
[ 2867.922636] x5 : ffffffed1e59d000 x4 : 0000000000000002 x3 :
0000000000000000
[ 2867.929863] x2 : 0000000000000040 x1 : ffffff804a479080 x0 :
0000000000000000
[ 2867.937090] Call trace:
[ 2867.939558] oa_tc6_update_rx_skb+0x2c/0xa8 [lan865x_t1s] (P)
[ 2867.945375] oa_tc6_macphy_threaded_irq+0x430/0x870 [lan865x_t1s]
[ 2867.951543] irq_thread_fn+0x34/0xc0
[ 2867.955156] irq_thread+0x1a8/0x308
[ 2867.958680] kthread+0x138/0x150
[ 2867.961942] ret_from_fork+0x10/0x20
[ 2867.965558] Code: aa0103f4 f90013f5 12001c55 f9403800 (29570403)
[ 2867.971727] ---[ end trace 0000000000000000 ]---
[ 2867.976443] genirq: exiting task "irq/59-spi0.0" (2808) is an active
IRQ thread (irq 59)
[ 2868.094789] irq 59: nobody cared (try booting with the "irqpoll" option)
[ 2868.101000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G D C
O 7.1.0-rc7-v8+ #2 PREEMPT
[ 2868.101007] Tainted: [D]=DIE, [C]=CRAP, [O]=OOT_MODULE
[ 2868.101009] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 2868.101011] Call trace:
[ 2868.101013] show_stack+0x20/0x38 (C)
[ 2868.101027] dump_stack_lvl+0x60/0x80
[ 2868.101033] dump_stack+0x18/0x24
[ 2868.101038] __report_bad_irq+0x54/0xf0
[ 2868.101043] note_interrupt+0x344/0x398
[ 2868.101048] handle_irq_event+0xa4/0x110
[ 2868.101051] handle_level_irq+0xe0/0x178
[ 2868.101056] handle_irq_desc+0x3c/0x68
[ 2868.101061] generic_handle_domain_irq+0x20/0x40
[ 2868.101067] bcm2835_gpio_irq_handle_bank+0x180/0x1c8
[ 2868.101074] bcm2835_gpio_irq_handler+0x88/0x188
[ 2868.101080] handle_irq_desc+0x3c/0x68
[ 2868.101085] generic_handle_domain_irq+0x20/0x40
[ 2868.101091] gic_handle_irq+0x4c/0xe0
[ 2868.101094] call_on_irq_stack+0x30/0x88
[ 2868.101099] do_interrupt_handler+0x88/0x98
[ 2868.101102] el1_interrupt+0x3c/0x60
[ 2868.101108] el1h_64_irq_handler+0x18/0x30
[ 2868.101113] el1h_64_irq+0x6c/0x70
[ 2868.101116] default_idle_call+0x34/0x1a0 (P)
[ 2868.101123] do_idle+0x260/0x2a0
[ 2868.101128] cpu_startup_entry+0x3c/0x50
[ 2868.101132] rest_init+0xe8/0xf0
[ 2868.101137] start_kernel+0x7f4/0x800
[ 2868.101143] __primary_switched+0x88/0x98
[ 2868.101149] handlers:
[ 2868.207750] lan8650 spi0.1: SPI transfer timed out
[ 2868.208070] [<0000000019361c17>] oa_tc6_macphy_isr [lan865x_t1s]
[ 2868.212048] spi_master spi0: failed to transfer one message from queue
[ 2868.215296] threaded [<00000000a4e6f0fa>] oa_tc6_macphy_threaded_irq
[lan865x_t1s]
[ 2868.219005] spi_master spi0: noqueue transfer failed
[ 2868.223053] Disabling IRQ #59
[ 2868.260162] lan8650 spi0.1 eth2: SPI data transfer failed: -110
[ 2868.266211] lan8650 spi0.1: Device interrupt disabled to avoid
interrupt storm
Best regards,
Parthiban V
>
> But I could see assert in skb_put immediately quickly.
>
>>
>> Best regards,
>> Parthiban V
>>>
>>>>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
From: Konrad Dybcio @ 2026-06-25 12:23 UTC (permalink / raw)
To: Aaron Kling
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CALHNRZ-J6DH1ebhUcRqbVRmStO_MGBJr63TEQg5vxNO_UpF-vQ@mail.gmail.com>
On 18-Jun-26 06:37, Aaron Kling wrote:
> On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>
>>> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
>>> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
>>> by aggregating bandwidth requests of all CPU core with reference to the
>>> current OPP they are configured in by the hardware.
>>>
>>> The effect is proper caches & DDR frequency scaling when CPU cores
>>> change frequency.
>>>
>>> The OPP tables were built using the downstream memlat ddr & llcc tables
>>> for each cluster types with the actual cpufreq LUT tables from running a
>>> CQ8725S device.
>>>
>>> Also add the interconnect entry for each cpu, with 2 different paths:
>>> - CPU to Last Level Cache Controller (LLCC)
>>> - Last Level Cache Controller (LLCC) to DDR
>>>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
>>> ---
>>
>> [...]
>>
>>> + cpu6_opp_table: opp-table-cpu6 {
>>> + compatible = "operating-points-v2";
>>> + opp-shared;
>>> +
>>> + opp-1017600000 {
>>> + opp-hz = /bits/ 64 <1017600000>;
>>> + opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>>
>> I think this should be * 4 in both cases since the interconnect driver
>> ignores the channel count for a node in peak voting. We may have a bug
>> in all other DTs here.
>
> If this is confirmed, I can update this patch. I based the
> calculations on my sm8550 copy of this change, which in turn was based
> on the sm8650 change. If this is wrong, that means one piece is
> scaling 4x too quickly? Making it a power consumption issue, not a
> performance issue.
>
>> BTW, are there no lower OPPs for the fast cores?
>
> Not on cq8725s at least. These lists came from an AYN Odin 3 with that
> soc. I don't have any sm8750 proper devices to see if that's any
> different.
Mobile SM8750:
root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu6/cpufreq/scaling_available_frequencies
1017600 1209600 1401600 1689600 1958400 2246400 2438400 2649600 2841600 3072000 3283200 3513600 3840000 4089600
root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
384000 556800 748800 960000 1152000 1363200 1555200 1785600 1996800 2227200 2400000 2745600 2918400 3072000 3321600 3532800
root@qcom-armv8a:~# grep ^ /sys/bus/soc/devices/soc0/*
/sys/bus/soc/devices/soc0/family:Snapdragon
/sys/bus/soc/devices/soc0/machine:SM8750
/sys/bus/soc/devices/soc0/revision:2.0
/sys/bus/soc/devices/soc0/serial_number:<snip>
/sys/bus/soc/devices/soc0/soc_id:618
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Waqar Hameed @ 2026-06-25 12:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <18ae59ae-024f-4dfb-ad66-2db90e6f7ed4@kernel.org>
On Thu, Jun 25, 2026 at 14:10 +0200 Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 25/06/2026 13:27, Waqar Hameed wrote:
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - interrupts
>>>> + - monitored-battery
>>>> +
>>>> +additionalProperties: false
>>>
>>> And here use 'unevaluatedProperties: false' instead.
>>
>> Hm, reading the documentation [1], `unevaluatedProperties` should be
>> used, because of the "include" of `power-supply.yaml`. I'll change to
>> that.
>>
>> However, there are tons of other places where `additionalProperties` is
>> used instead _with_ a reference to `power-supply.yaml` (which is what I
>> followed). Are all of them actually "wrong" then?
>
> No, they are not wrong, but usually preferred is to allow all properties
> from referenced power-supply schema.
Ah ok, I can see why it's more preferable to be more "permissive" with
`unevaluatedProperties`. Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: sashiko-bot @ 2026-06-25 12:20 UTC (permalink / raw)
To: Gokul Praveen; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625120805.28948-2-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding a third clock to the serdes2 node violates the Cadence Torrent PHY DT binding schema, which will cause `dtbs_check` validation to fail.
--
commit c7948a2c66b640fab1ce0e80a89c69a933059939
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
This commit adds the PLL1 reference clock to the clocks and clock-names
properties of the SERDES2 node. This is done to satisfy the assigned-clocks
parameter and prevent multilink configuration failures.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 78fcd0c40abcf..da8d582574d03 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
> resets = <&serdes_wiz2 0>;
> reset-names = "torrent_reset";
> clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
> + <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
> <&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
> - clock-names = "refclk", "phy_en_refclk";
> + clock-names = "refclk","pll1_refclk", "phy_en_refclk";
[Severity: Low]
Will adding a third clock to the serdes2 node cause dtbs_check validation
to fail?
The Cadence Torrent PHY device tree binding schema in
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml restricts
the clocks and clock-names properties to a maximum of 2 items. By adding
pll1_refclk alongside refclk and phy_en_refclk, the array now contains 3
items, which violates the existing schema constraints.
Does the device tree binding schema need to be updated first to support
this third clock?
> assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
> <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
> <&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=1
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
From: sashiko-bot @ 2026-06-25 12:20 UTC (permalink / raw)
To: Gokul Praveen; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625120805.28948-4-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incomplete clock configuration in `&serdes_wiz2` leaves a dangling `assigned-clocks` element as dead code.
- [Low] The unit addresses in the PHY node names do not match their `reg` property values.
--
commit ec16658036ad6f4bdcb6018a15184b9bd2b3c4aa
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
USXGMII mode with MAC Ports 1 and 2 of the instance, which are
connected to ENET Expansion 1 and ENET Expansion 2 slots on
the EVM respectively, through the Serdes2 instance of the SERDES.
Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
SGMII and USXGMII mode at 1Gbps and 5 Gbps each.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
> new file mode 100644
> index 0000000000000..553546b281a9e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
[ ... ]
> +&serdes_wiz2 {
> + assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
> + //assigned-clock-parents = <&k3_clks 406 9>; /* Use 100 MHz clock for SGMII */
> + status = "okay";
> +};
[Severity: Medium]
The assigned-clock-parents override is commented out here, but the
assigned-clocks array was expanded to two elements.
Because the base device tree only defines a single parent, the clock framework
will only process the first clock and silently ignore the second element.
Does this leave the second clock unconfigured, and should
assigned-clock-parents be uncommented to resolve this?
> +
> +&serdes2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + assigned-clock-parents = <&k3_clks 406 5>,
> + <&k3_clks 406 6>,
> + <&k3_clks 406 5>;
> +
> + serdes2_sgmii2_link: phy@1 {
> + reg = <2>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_SGMII>;
> + resets = <&serdes_wiz2 3>;
> + };
> + serdes2_usxgmii_link: phy@0 {
> + reg = <3>;
[Severity: Low]
Do the unit addresses phy@1 and phy@0 need to match their reg property
values <2> and <3>?
The dtc compiler will generate unit_address_vs_reg warnings when the unit
address and reg property do not match.
[ ... ]
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
> new file mode 100644
> index 0000000000000..c98be3bbf2c8b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
[ ... ]
> +&serdes_wiz2 {
> + assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
> + //assigned-clock-parents = <&k3_clks 406 9>; /* Use 156.25 MHz clock for USXGMII */
> + status = "okay";
> +};
[Severity: Medium]
Similar to the first overlay, the assigned-clock-parents override is commented
out while assigned-clocks contains two elements.
Is the second clock intended to be left unconfigured here?
> +
> +&serdes2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + assigned-clock-parents = <&k3_clks 406 5>,
> + <&k3_clks 406 6>,
> + <&k3_clks 406 5>;
> +
> +
> +
> + serdes2_sgmii2_link: phy@1 {
> + reg = <3>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_SGMII>;
> + resets = <&serdes_wiz2 4>;
> + };
> + serdes2_usxgmii_link: phy@0 {
> + reg = <2>;
[Severity: Low]
Are the unit addresses for these nodes correct?
They are named phy@1 and phy@0, but their reg properties are set to <3>
and <2>. Should they be updated to match the reg properties to prevent dtc
warnings?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=3
^ permalink raw reply
* Re: [PATCH 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
From: sashiko-bot @ 2026-06-25 12:18 UTC (permalink / raw)
To: Gokul Praveen; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260625120805.28948-3-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing AM65_CPSW_SGMII_CONTROL_MASTER bit in SGMII control register write
- [Medium] Hardcoded SGMII link advertisement to 1000 Mbps Full Duplex
--
commit 2e14387f10f244dbb25f009bd28dfe67470e6821
Author: Gokul Praveen <g-praveen@ti.com>
net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
Fix MAC configuration of CPSW Ethernet Switch in SGMII mode by
modifying the CPSW_SGMII_MR_ADV_ABILITY_REG and configuring MAC
in master mode as per CPSGMII Module specification.
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 7ac75fc8cdcf4..4740b35052464 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -84,6 +84,7 @@
> #define AM65_CPSW_SGMII_CONTROL_REG 0x010
> #define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG 0x018
> #define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE BIT(0)
> +#define AM65_CPSW_SGMII_CONTROL_MASTER BIT(5)
>
> #define AM65_CPSW_CTL_VLAN_AWARE BIT(1)
[ ... ]
> @@ -2063,8 +2064,10 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
>
> if (common->pdata.extra_modes & BIT(state->interface)) {
> if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> - writel(ADVERTISE_SGMII,
> - port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
> + writel(ADVERTISE_SGMII | LPA_SGMII_1000FULL | LPA_SGMII_LINK,
> + port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
[Severity: Medium]
Will this hardcoded advertisement break SGMII operation at 10 Mbps or 100
Mbps?
By unconditionally applying LPA_SGMII_1000FULL and LPA_SGMII_LINK, the MAC
seems to always claim 1000 Mbps capabilities regardless of the actual
requested or negotiated speed, which could restrict generic SGMII
functionality to gigabit-only.
> + writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
> + port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
[Severity: High]
Does this write miss the AM65_CPSW_SGMII_CONTROL_MASTER bit introduced earlier
in the patch?
The commit message states the intent is to configure the MAC in master mode,
but only AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE is being set in
am65_cpsw_nuss_mac_config().
Could this cause the MAC to remain in slave mode, potentially preventing the
SGMII link from coming up on MAC-to-MAC connections that require the MAC to
act as the master?
> cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
> } else {
> cpsw_sl_ctl_clr(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=2
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: sm8250: Add cam_mclk3_default pinctrl
From: Konrad Dybcio @ 2026-06-25 12:15 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_47473BB31C9142449F8C7C1BE69D9071510A@qq.com>
On 6/25/26 2:05 PM, Xin Xu wrote:
> Add a default pin configuration for CAM_MCLK3 (GPIO97), which is used
> as a master clock for camera sensors on SM8250 boards.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Konrad Dybcio @ 2026-06-25 12:11 UTC (permalink / raw)
To: Harendra Gautam
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <CAC-tS8Af8GNQ1rq2PN6Yr-wG8_D55ddU9t77H4CUEvWfaP=Gkw@mail.gmail.com>
On 6/24/26 8:59 AM, Harendra Gautam wrote:
> On Tue, Jun 23, 2026 at 9:18 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/23/26 2:26 PM, Harendra Gautam wrote:
>>> On Tue, Jun 9, 2026 at 3:27 PM Konrad Dybcio
>>> <konrad.dybcio@oss.qualcomm.com> wrote:
[...]
>>>>> + qcom,qaif-aif-sync-mode:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + description:
>>>>> + Sync mode. Use QAIF_AIF_SYNC_MODE_SHORT (0) for short (pulse)
>>>>> + sync or QAIF_AIF_SYNC_MODE_LONG (1) for long (level) sync.
>>>>> + qcom,qaif-aif-sync-src:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + description:
>>>>> + Sync source. Use QAIF_AIF_SYNC_SRC_SLAVE (0) for slave mode
>>>>> + or QAIF_AIF_SYNC_SRC_MASTER (1) for master mode.
>>>>
>>>> Should these be boolean flags then?
>>> It should not be, the intention is to define explicitly, for better
>>> readability I can rename these flags as EXTERNAL/INTERNAL, Please
>>> suggest.
>>
>> Are all 4 combinations of them being present/absent valid on shikra?
>>
>> Konrad
> Sorry if I did not put details properly, I will be correcting in the
> next patch. sync-src can be external clock or internal clock, where 0
> means external and 1 means internal.
What I meant to ask is whether all combinations of qcom,qaif-aif-sync-mode
and qcom,qaif-aif-sync-src being present/absent (set to 0/1) are actually
valid and should be supported
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Krzysztof Kozlowski @ 2026-06-25 12:10 UTC (permalink / raw)
To: Waqar Hameed
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <pndwlvm6ese.a.out@axis.com>
On 25/06/2026 13:27, Waqar Hameed wrote:
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>> + - monitored-battery
>>> +
>>> +additionalProperties: false
>>
>> And here use 'unevaluatedProperties: false' instead.
>
> Hm, reading the documentation [1], `unevaluatedProperties` should be
> used, because of the "include" of `power-supply.yaml`. I'll change to
> that.
>
> However, there are tons of other places where `additionalProperties` is
> used instead _with_ a reference to `power-supply.yaml` (which is what I
> followed). Are all of them actually "wrong" then?
No, they are not wrong, but usually preferred is to allow all properties
from referenced power-supply schema.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] clk: qcom: gpucc: Add Nord graphics clock controller support
From: Konrad Dybcio @ 2026-06-25 12:09 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Shawn Guo, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-6-860c84539804@oss.qualcomm.com>
On 6/23/26 12:54 PM, Taniya Das wrote:
> Add support for the GPU clock controllers (GPUCC) on the Qualcomm
> Nord platform.
>
> The platform includes two GPU clock controller instances,GPUCC
> and GPU2CC. Register support for both controllers, which provide
> clocks required for the graphics subsystem.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gpu2cc-nord.c | 546 +++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/gpucc-nord.c | 593 +++++++++++++++++++++++++++++++++++++++++
GPU_2_CC and GPU_CC seem to have a different set of clocks and
resets. If that's not physically the case, please align the
lists. Otherwise, please use a separate bindings header for each
one
Konrad
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add ov8856 front camera
From: Xin Xu @ 2026-06-25 12:08 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_47473BB31C9142449F8C7C1BE69D9071510A@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v3:
- Reorder pinctrl properties in camera_front_active.
- Use the new cam_mclk3_default from sm8250.dtsi and remove board-local
mclk3 node.
Changes in v2:
- Fix coding style (property order)
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 05c366eaeff1..19aff83ecf7b 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&cam_mclk3_default &camera_front_active>;
+ pinctrl-names = "default";
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -891,6 +947,13 @@ pm8008_reset_default: pm8008-reset-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: Gokul Praveen @ 2026-06-25 12:08 UTC (permalink / raw)
To: vigneshr, kristo, conor+dt, c-vankar, s-vadapalli, krzk+dt, davem,
andrew+netdev, pabeni, kuba, g-praveen, devicetree, linux-kernel
In-Reply-To: <20260625120805.28948-1-g-praveen@ti.com>
Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES2 node
as "assigned clocks" parameter has PLL1 and serdes multilink configuration
fails without PLL1.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 78fcd0c40abc..da8d582574d0 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
resets = <&serdes_wiz2 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk","pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
From: Gokul Praveen @ 2026-06-25 12:08 UTC (permalink / raw)
To: vigneshr, kristo, conor+dt, c-vankar, s-vadapalli, krzk+dt, davem,
andrew+netdev, pabeni, kuba, g-praveen, devicetree, linux-kernel
In-Reply-To: <20260625120805.28948-1-g-praveen@ti.com>
Fix MAC configuration of CPSW Ethernet Switch in SGMII mode by
modifying the CPSW_SGMII_MR_ADV_ABILITY_REG and configuring MAC
in master mode as per CPSGMII Module specification.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 434a31080855..291697d82491 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -84,6 +84,7 @@
#define AM65_CPSW_SGMII_CONTROL_REG 0x010
#define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG 0x018
#define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE BIT(0)
+#define AM65_CPSW_SGMII_CONTROL_MASTER BIT(5)
#define AM65_CPSW_CTL_VLAN_AWARE BIT(1)
#define AM65_CPSW_CTL_P0_ENABLE BIT(2)
@@ -2061,8 +2062,10 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
if (common->pdata.extra_modes & BIT(state->interface)) {
if (state->interface == PHY_INTERFACE_MODE_SGMII) {
- writel(ADVERTISE_SGMII,
- port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+ writel(ADVERTISE_SGMII | LPA_SGMII_1000FULL | LPA_SGMII_LINK,
+ port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+ writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
+ port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
} else {
cpsw_sl_ctl_clr(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
@@ -2076,8 +2079,6 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
CPSW_SL_CTL_XGIG | CPSW_SL_CTL_XGMII_EN);
}
- writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
- port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
From: Gokul Praveen @ 2026-06-25 12:08 UTC (permalink / raw)
To: vigneshr, kristo, conor+dt, c-vankar, s-vadapalli, krzk+dt, davem,
andrew+netdev, pabeni, kuba, g-praveen, devicetree, linux-kernel
In-Reply-To: <20260625120805.28948-1-g-praveen@ti.com>
The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
USXGMII mode with MAC Ports 1 and 2 of the instance, which are
connected to ENET Expansion 1 and ENET Expansion 2 slots on
the EVM respectively, through the Serdes2 instance of the SERDES.
Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
SGMII and USXGMII mode at 1Gbps and 5 Gbps each.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 11 ++-
...s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso | 93 ++++++++++++++++++
...s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso | 96 +++++++++++++++++++
3 files changed, 198 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe5..253706415833 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -199,6 +199,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-pcie0-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-quad-port-eth-exp1.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-usxgmii-exp1-exp2.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j784s4-j742s2-evm-usb0-type-a.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtbo
# Boards with J742S2 SoC
dtb-$(CONFIG_ARCH_K3) += k3-j742s2-evm.dtb
@@ -338,6 +340,10 @@ k3-j784s4-evm-usb0-type-a-dtbs := k3-j784s4-evm.dtb \
k3-j784s4-j742s2-evm-usb0-type-a.dtbo
k3-j784s4-evm-usxgmii-exp1-exp2-dtbs := k3-j784s4-evm.dtb \
k3-j784s4-evm-usxgmii-exp1-exp2.dtbo
+k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1-dtbs := k3-j784s4-evm.dtb \
+ k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtbo
+k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2-dtbs := k3-j784s4-evm.dtb \
+ k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtbo
dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
k3-am625-phyboard-lyra-disable-eth-phy.dtb \
@@ -404,7 +410,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j784s4-evm-pcie0-pcie1-ep.dtb \
k3-j784s4-evm-quad-port-eth-exp1.dtb \
k3-j784s4-evm-usb0-type-a.dtb \
- k3-j784s4-evm-usxgmii-exp1-exp2.dtb
-
+ k3-j784s4-evm-usxgmii-exp1-exp2.dtb \
+ k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtb \
+ k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtb \
# Enable support for device-tree overlays
DTC_FLAGS := -@
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
new file mode 100644
index 000000000000..553546b281a9
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
@@ -0,0 +1,93 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/**
+ * DT Overlay for CPSW9G in dual port fixed-link USXGMII mode using ENET-1
+ * and ENET-2 Expansion slots of J784S4 EVM.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/phy/phy-cadence.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "k3-serdes.h"
+
+&{/} {
+ aliases {
+ ethernet1 = "/bus@100000/ethernet@c000000/ethernet-ports/port@1";
+ ethernet2 = "/bus@100000/ethernet@c000000/ethernet-ports/port@2";
+ ethernet3 = "/bus@100000/ethernet@c200000/ethernet-ports/port@1";
+ };
+};
+
+&main_cpsw0 {
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&main_cpsw0_port1 {
+ phy-mode = "sgmii";
+ mac-address = [00 00 00 00 00 00];
+ phys = <&cpsw0_phy_gmii_sel 1>, <&serdes2_sgmii2_link>;
+ phy-names = "mac", "serdes";
+ status = "okay";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&main_cpsw0_port2 {
+ phy-mode = "usxgmii";
+ mac-address = [00 00 00 00 00 00];
+ phys = <&cpsw0_phy_gmii_sel 2>, <&serdes2_usxgmii_link>;
+ phy-names = "mac", "serdes";
+ status = "okay";
+ fixed-link {
+ speed = <5000>;
+ full-duplex;
+ };
+};
+
+&serdes_wiz2 {
+ assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
+ //assigned-clock-parents = <&k3_clks 406 9>; /* Use 100 MHz clock for SGMII */
+ status = "okay";
+};
+
+&serdes2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clock-parents = <&k3_clks 406 5>,
+ <&k3_clks 406 6>,
+ <&k3_clks 406 5>;
+
+ serdes2_sgmii2_link: phy@1 {
+ reg = <2>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_SGMII>;
+ resets = <&serdes_wiz2 3>;
+ };
+ serdes2_usxgmii_link: phy@0 {
+ reg = <3>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USXGMII>;
+ resets = <&serdes_wiz2 4>;
+ };
+};
+
+&serdes_ln_ctrl {
+ idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
+ <J784S4_SERDES0_LANE2_IP3_UNUSED>, <J784S4_SERDES0_LANE3_USB>,
+ <J784S4_SERDES1_LANE0_PCIE0_LANE0>, <J784S4_SERDES1_LANE1_PCIE0_LANE1>,
+ <J784S4_SERDES1_LANE2_PCIE0_LANE2>, <J784S4_SERDES1_LANE3_PCIE0_LANE3>,
+ <J784S4_SERDES2_LANE0_IP2_UNUSED>, <J784S4_SERDES2_LANE1_IP2_UNUSED>,
+ <J784S4_SERDES2_LANE2_QSGMII_LANE1>, <J784S4_SERDES2_LANE3_QSGMII_LANE2>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
new file mode 100644
index 000000000000..c98be3bbf2c8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/**
+ * DT Overlay for CPSW9G in dual port fixed-link USXGMII mode using ENET-1
+ * and ENET-2 Expansion slots of J784S4 EVM.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/phy/phy-cadence.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "k3-serdes.h"
+
+&{/} {
+ aliases {
+ ethernet1 = "/bus@100000/ethernet@c000000/ethernet-ports/port@1";
+ ethernet2 = "/bus@100000/ethernet@c000000/ethernet-ports/port@2";
+ ethernet3 = "/bus@100000/ethernet@c200000/ethernet-ports/port@1";
+ };
+};
+
+&main_cpsw0 {
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&main_cpsw0_port1 {
+ phy-mode = "usxgmii";
+ mac-address = [00 00 00 00 00 00];
+ phys = <&cpsw0_phy_gmii_sel 1>, <&serdes2_usxgmii_link>;
+ phy-names = "mac", "serdes";
+ status = "okay";
+ fixed-link {
+ speed = <5000>;
+ full-duplex;
+ };
+};
+
+&main_cpsw0_port2 {
+ phy-mode = "sgmii";
+ mac-address = [00 00 00 00 00 00];
+ phys = <&cpsw0_phy_gmii_sel 2>, <&serdes2_sgmii2_link>;
+ phy-names = "mac", "serdes";
+ status = "okay";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&serdes_wiz2 {
+ assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
+ //assigned-clock-parents = <&k3_clks 406 9>; /* Use 156.25 MHz clock for USXGMII */
+ status = "okay";
+};
+
+&serdes2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clock-parents = <&k3_clks 406 5>,
+ <&k3_clks 406 6>,
+ <&k3_clks 406 5>;
+
+
+
+ serdes2_sgmii2_link: phy@1 {
+ reg = <3>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_SGMII>;
+ resets = <&serdes_wiz2 4>;
+ };
+ serdes2_usxgmii_link: phy@0 {
+ reg = <2>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USXGMII>;
+ resets = <&serdes_wiz2 3>;
+ };
+
+};
+
+&serdes_ln_ctrl {
+ idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
+ <J784S4_SERDES0_LANE2_IP3_UNUSED>, <J784S4_SERDES0_LANE3_USB>,
+ <J784S4_SERDES1_LANE0_PCIE0_LANE0>, <J784S4_SERDES1_LANE1_PCIE0_LANE1>,
+ <J784S4_SERDES1_LANE2_PCIE0_LANE2>, <J784S4_SERDES1_LANE3_PCIE0_LANE3>,
+ <J784S4_SERDES2_LANE0_IP2_UNUSED>, <J784S4_SERDES2_LANE1_IP2_UNUSED>,
+ <J784S4_SERDES2_LANE2_QSGMII_LANE1>, <J784S4_SERDES2_LANE3_QSGMII_LANE2>;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] Add support for dual port USXGMII+SGMII
From: Gokul Praveen @ 2026-06-25 12:08 UTC (permalink / raw)
To: vigneshr, kristo, conor+dt, c-vankar, s-vadapalli, krzk+dt, davem,
andrew+netdev, pabeni, kuba, g-praveen, devicetree, linux-kernel
This patch series enables dual port USXGMII and SGMII Ethernet mode
support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.
The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
Expansion 2 slots through the SERDES2 instance. The series includes:
1. A fix to the SERDES2 node to add the missing PLL1 refclk, which is
required for multilink SERDES configuration to function properly.
2. A driver fix for the am65-cpsw Ethernet driver to properly configure
the MAC in SGMII mode according to the CPSGMII Module specification,
including correct advertisement ability register settings and master
mode configuration.
3. Device tree overlay support for two board configurations:
- Board 1: Port 1 in SGMII mode (1Gbps) + Port 2 in USXGMII mode (5Gbps)
- Board 2: Port 1 in USXGMII mode (5Gbps) + Port 2 in SGMII mode (1Gbps)
Both configurations use fixed-link mode and provide flexible multi-speed
networking options for the J784S4 platform.
Boot logs:
https://gist.github.com/GokulPraveen2001/7a09cc5ed0151d264f32cbbc31896605
Gokul Praveen (3):
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII
mode
arch/arm64/boot/dts/ti/Makefile | 11 ++-
...s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso | 97 +++++++++++++++++++
...s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso | 97 +++++++++++++++++++
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 7 +-
5 files changed, 209 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
--
2.34.1
^ permalink raw reply
* Re: [PATCH 4/6] clk: qcom: Add Nord display clock controller support
From: Konrad Dybcio @ 2026-06-25 12:06 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Shawn Guo, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-4-860c84539804@oss.qualcomm.com>
On 6/23/26 12:54 PM, Taniya Das wrote:
> Add support for the display clock controllers (DISPCC) on the
> Qualcomm Nord platform.
>
> The platform includes two display clock controller instances,
> display0 and display1. Register support for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
[...]
> +enum {
> + DT_BI_TCXO,
> + DT_BI_TCXO_AO,
This one can probably be removed, both files
I think the rest looks good
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: qcom: sm8250: Add cam_mclk3_default pinctrl
From: Xin Xu @ 2026-06-25 12:05 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_D4AB219A942591742C3A6DA4DFB0EBA49505@qq.com>
Add a default pin configuration for CAM_MCLK3 (GPIO97), which is used
as a master clock for camera sensors on SM8250 boards.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 7076720413ab..05e765616112 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -5165,6 +5165,13 @@ mclk-pins {
};
};
+ cam_mclk3_default: cam-mclk3-default-state {
+ pins = "gpio97";
+ function = "cam_mclk";
+ drive-strength = <4>;
+ bias-disable;
+ };
+
cci0_default: cci0-default-state {
cci0_i2c0_default: cci0-i2c0-default-pins {
/* SDA, SCL */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 11:50 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
Add the pm8008 PMIC node on i2c15 with seven LDOs,
using GPIO84 as interrupt and GPIO76 as reset.
Signed-off-by: Xin Xu <xxsemail@qq.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Changes in v3:
- Split pinctrl into two separate states for interrupt and reset, drop
input-enable.
- Reorder bias properties after drive-strength.
Changes in v2:
- Fix coding style (blank line, interrupts-extended, property order,
drop output-high)
- Correct voltage constraints for ldo1 and ldo2
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 90 +++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 51b57c697a75..05c366eaeff1 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -599,6 +599,82 @@ fuel-gauge@55 {
};
};
+&i2c15 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ pm8008: pmic@8 {
+ compatible = "qcom,pm8008";
+ reg = <0x8>;
+
+ interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
+
+ vdd-l1-l2-supply = <&vreg_s8c_1p35>;
+ vdd-l3-l4-supply = <&vreg_bob>;
+ vdd-l5-supply = <&vreg_bob>;
+ vdd-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_bob>;
+
+ pinctrl-0 = <&pm8008_int_default>, <&pm8008_reset_default>;
+ pinctrl-names = "default";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ regulators {
+ vreg_l1p: ldo1 {
+ regulator-name = "vreg_l1p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l2p: ldo2 {
+ regulator-name = "vreg_l2p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l3p: ldo3 {
+ regulator-name = "vreg_l3p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l4p: ldo4 {
+ regulator-name = "vreg_l4p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l5p: ldo5 {
+ regulator-name = "vreg_l5p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l6p: ldo6 {
+ regulator-name = "vreg_l6p";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_l7p: ldo7 {
+ regulator-name = "vreg_l7p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2900000>;
+ };
+ };
+ };
+};
+
&mdss {
status = "okay";
};
@@ -801,6 +877,20 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ pm8008_int_default: pm8008-int-default-state {
+ pins = "gpio84";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pm8008_reset_default: pm8008-reset-default-state {
+ pins = "gpio76";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 2/9] usb: misc: qcom_eud: add sysfs attribute for port selection
From: Konrad Dybcio @ 2026-06-25 11:51 UTC (permalink / raw)
To: Elson Serrao, Bjorn Andersson, Dmitry Baryshkov,
Greg Kroah-Hartman, Konrad Dybcio, Krzysztof Kozlowski,
Rob Herring, Conor Dooley, Souradeep Chowdhury
Cc: linux-arm-msm, devicetree, linux-usb, linux-kernel
In-Reply-To: <20260501170635.2641748-3-elson.serrao@oss.qualcomm.com>
On 5/1/26 7:06 PM, Elson Serrao wrote:
> EUD can be mapped to either the primary USB port or the secondary USB port
> depending on the value of the EUD_PORT_SEL register. Add a 'port' sysfs
> attribute to allow userspace to select which port EUD should operate on
> and update the ABI documentation. This is needed for systems with dual
> USB ports where EUD needs to be accessible on either port depending on the
> system configuration and use case.
>
> Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v1 4/8] arm64: dts: qcom: shikra: Add soundwire and macro nodes
From: Konrad Dybcio @ 2026-06-25 11:45 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260616201315.2565115-5-mohammad.rafi.shaik@oss.qualcomm.com>
On 6/16/26 10:13 PM, Mohammad Rafi Shaik wrote:
> Add SoC-level SoundWire masters and LPASS RX/VA macro nodes, along with
> DMIC and SWR pinctrl states required by the audio data path.
>
> Keep these nodes disabled in shikra.dtsi so board dts files can selectively
> enable and configure them.
>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
Just a couple style nits:
[...]
> + rxmacro: codec@a040000 {
> + compatible = "qcom,shikra-lpass-rx-macro";
> + reg = <0x0 0x0a040000 0x0 0x1000>;
> +
> + pinctrl-0 = <&rx_swr_active>;
> + pinctrl-names = "default";
Let's move this down.. maybe above all the #cells
> +
> + clocks = <&audiocorecc AUDIO_CORE_CC_RX_MCLK_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_RX_MCLK_2X_CLK>,
Please align all <s
> + <&vamacro>;
> + clock-names = "mclk",
> + "npl",
> + "fsgen";
> +
> + #clock-cells = <0>;
> + clock-output-names = "mclk";
> + #sound-dai-cells = <1>;
> + status = "disabled";
Let's keep a \n before 'status', everywhere
Konrad
^ permalink raw reply
* Re: [PATCH 4/5] media: i2c: vd55g1: Add support for vd55g4
From: Benjamin Mugnier @ 2026-06-25 11:41 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <ajkKkSeDNoijIsub@zed>
Hi Jacopo,
Le 22/06/2026 à 12:16, Jacopo Mondi a écrit :
> Hi Benjamin
>
> On Tue, Apr 28, 2026 at 10:40:58AM +0200, Benjamin Mugnier wrote:
>> vd55g4 is the same device as vd65g4 but outputs in monochrome instead of
>> RGB. Adapt the driver structure according to this new variant, and add
>> its support.
>>
>> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
>> ---
>> drivers/media/i2c/vd55g1.c | 110 ++++++++++++++++++++++++++++++---------------
>> 1 file changed, 74 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
>> index 2c962fcb41d2..9f62fc0428a1 100644
>> --- a/drivers/media/i2c/vd55g1.c
>> +++ b/drivers/media/i2c/vd55g1.c
>> @@ -29,11 +29,7 @@
>>
>> /* Register Map */
>> #define VD55G1_REG_MODEL_ID CCI_REG32_LE(0x0000)
>> -#define VD55G1_MODEL_ID_VD55G1 0x53354731 /* Mono */
>> -#define VD55G1_MODEL_ID_VD65G4 0x53354733 /* RGB */
>> -#define VD55G1_REG_REVISION CCI_REG16_LE(0x0004)
>> -#define VD55G1_REVISION_CCB 0x2020
>> -#define VD55G1_REVISION_BAYER 0x3030
>> +#define VD55G1_REG_COLOR_VERSION CCI_REG32_LE(0x0670)
>> #define VD55G1_REG_FWPATCH_REVISION CCI_REG16_LE(0x0012)
>> #define VD55G1_REG_FWPATCH_START_ADDR CCI_REG8(0x2000)
>> #define VD55G1_REG_SYSTEM_FSM CCI_REG8(0x001c)
>> @@ -138,8 +134,39 @@
>> #define VD55G1_MIPI_RATE_MIN (250 * MEGA)
>> #define VD55G1_MIPI_RATE_MAX (1200 * MEGA)
>>
>> -#define VD55G1_MODEL_ID_NAME(id) \
>> - ((id) == VD55G1_MODEL_ID_VD55G1 ? "vd55g1" : "vd65g4")
>> +enum vd55g1_model_id {
>> + VD55G1_MODEL_ID_2 = 0x53354731,
>> + VD55G1_MODEL_ID_3 = 0x53354733,
>> +};
>> +
>> +enum vd55g1_color_version {
>> + VD55G1_COLOR_VERSION_MONO = 0x0,
>> + VD55G1_COLOR_VERSION_BAYER = 0x1,
>
> nit: you don't need to initialize the enum members here
Thank you, will do.
>
>> +};
>> +
>> +struct vd55g1_version {
>> + char *name;
>> + enum vd55g1_model_id id;
>> + enum vd55g1_color_version color;
>> +};
>> +
>> +static const struct vd55g1_version vd55g1_versions[] = {
>> + {
>> + .name = "vd55g1",
>> + .id = VD55G1_MODEL_ID_2,
>> + .color = VD55G1_COLOR_VERSION_MONO,
>> + },
>> + {
>> + .name = "vd55g4",
>> + .id = VD55G1_MODEL_ID_3,
>> + .color = VD55G1_COLOR_VERSION_MONO,
>> + },
>> + {
>> + .name = "vd65g4",
>> + .id = VD55G1_MODEL_ID_3,
>> + .color = VD55G1_COLOR_VERSION_BAYER,
>> + },
>> +};
>>
>> static const u8 vd55g1_patch_array[] = {
>> 0x44, 0x03, 0x09, 0x02, 0xe6, 0x01, 0x42, 0x00, 0xea, 0x01, 0x42, 0x00,
>> @@ -535,7 +562,7 @@ struct vd55g1_vblank_limits {
>>
>> struct vd55g1 {
>> struct device *dev;
>> - unsigned int id;
>> + const struct vd55g1_version *version;
>> struct v4l2_subdev sd;
>> struct media_pad pad;
>> struct regulator_bulk_data supplies[ARRAY_SIZE(vd55g1_supply_name)];
>> @@ -628,7 +655,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
>> {
>> unsigned int i, j;
>>
>> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
>> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
>> return code;
>
> As pointed out in the previous patch, you seem to have 2 mono formats.
> Is this still ok ?
>
>>
>> for (i = 0; i < ARRAY_SIZE(vd55g1_mbus_formats_bayer); i++) {
>> @@ -1183,8 +1210,8 @@ static int vd55g1_patch(struct vd55g1 *sensor)
>> u64 patch;
>> int ret = 0;
>>
>> - /* vd55g1 needs a patch while vd65g4 does not */
>> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
>> + /* Version 2 needs a patch while version 3 does not */
>> + if (sensor->version->id == VD55G1_MODEL_ID_2) {
>> vd55g1_write_array(sensor, VD55G1_REG_FWPATCH_START_ADDR,
>> sizeof(vd55g1_patch_array),
>> vd55g1_patch_array, &ret);
>
> You might want to consider renaming vd55g1_patch_array ?
It doesn't really patch an array, it writes an array of values into
continuous i2c registers. Just like before converting to cci_write() I
used to have a vd55g1_write() function to write a register, I derived a
vd55g1_write_array() function. Here it happens to be a firmware patch,
but it could be anything you want ;)
>
>> @@ -1256,7 +1283,7 @@ static int vd55g1_enum_mbus_code(struct v4l2_subdev *sd,
>> struct vd55g1 *sensor = to_vd55g1(sd);
>> u32 base_code;
>>
>> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
>> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER) {
>> if (code->index >= ARRAY_SIZE(vd55g1_mbus_formats_mono))
>> return -EINVAL;
>> base_code = vd55g1_mbus_formats_mono[code->index];
>> @@ -1372,7 +1399,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> if (ret)
>> return ret;
>>
>> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
>> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
>> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
>> else
>> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
>> @@ -1659,38 +1686,48 @@ static int vd55g1_init_ctrls(struct vd55g1 *sensor)
>> return ret;
>> }
>>
>> +static const struct vd55g1_version *
>> + vd55g1_get_version(enum vd55g1_model_id id,
>> + enum vd55g1_color_version color)
>
> Should you indent one tab left ?
>
checkpatch.pl is fine with both. I can indent left, it looks cleaner.
>> +{
>> + unsigned int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(vd55g1_versions); i++) {
>
> You can declare i inside the for loop
>
Yes, thank you.
>> + if (vd55g1_versions[i].id == id &&
>> + vd55g1_versions[i].color == color)
>> + return &vd55g1_versions[i];
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> static int vd55g1_detect(struct vd55g1 *sensor)
>> {
>> - unsigned int dt_id = (uintptr_t)device_get_match_data(sensor->dev);
>> - u64 rev, id;
>> - int ret;
>> + const struct vd55g1_version *dt_version =
>> + device_get_match_data(sensor->dev);
>> + const struct vd55g1_version *version;
>> + u64 color, id;
>> + int ret = 0;
>>
>> - ret = vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, NULL);
>> + vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, &ret);
>> + vd55g1_read(sensor, VD55G1_REG_COLOR_VERSION, &color, &ret);
>> if (ret)
>> return ret;
>>
>> - if (id != VD55G1_MODEL_ID_VD55G1 && id != VD55G1_MODEL_ID_VD65G4) {
>> - dev_warn(sensor->dev, "Unsupported sensor id 0x%x\n",
>> - (u32)id);
>> + version = vd55g1_get_version(id, color);
>> + if (!version) {
>> + dev_warn(sensor->dev, "Unsupported sensor version, expected %s\n",
>> + dt_version->name);
>> return -ENODEV;
>> }
>> - if (id != dt_id) {
>> - dev_err(sensor->dev, "Probed sensor %s and device tree definition (%s) mismatch",
>> - VD55G1_MODEL_ID_NAME(id), VD55G1_MODEL_ID_NAME(dt_id));
>> + if (version->id != dt_version->id ||
>> + version->color != dt_version->color) {
>> + dev_err(sensor->dev, "Probed sensor version %s and device tree definition %s mismatch",
>> + version->name, dt_version->name);
>> return -ENODEV;
>> }
>> - sensor->id = id;
>>
>> - ret = vd55g1_read(sensor, VD55G1_REG_REVISION, &rev, NULL);
>> - if (ret)
>> - return ret;
>> -
>> - if ((id == VD55G1_MODEL_ID_VD55G1 && rev != VD55G1_REVISION_CCB) &&
>> - (id == VD55G1_MODEL_ID_VD65G4 && rev != VD55G1_REVISION_BAYER)) {
>> - dev_err(sensor->dev, "Unsupported sensor revision 0x%x for sensor %s\n",
>> - (u16)rev, VD55G1_MODEL_ID_NAME(id));
>> - return -ENODEV;
>> - }
>> + sensor->version = version;
>>
>> return 0;
>> }
>> @@ -2048,8 +2085,9 @@ static void vd55g1_remove(struct i2c_client *client)
>> }
>>
>> static const struct of_device_id vd55g1_dt_ids[] = {
>> - { .compatible = "st,vd55g1", .data = (void *)VD55G1_MODEL_ID_VD55G1 },
>> - { .compatible = "st,vd65g4", .data = (void *)VD55G1_MODEL_ID_VD65G4 },
>> + { .compatible = "st,vd55g1", .data = (void *)&vd55g1_versions[0] },
>> + { .compatible = "st,vd55g4", .data = (void *)&vd55g1_versions[1] },
>> + { .compatible = "st,vd65g4", .data = (void *)&vd55g1_versions[2] },
>> { /* sentinel */ }
>> };
>
> All minors
> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> Thanks
> j
>
>> MODULE_DEVICE_TABLE(of, vd55g1_dt_ids);
>>
>> --
>> 2.43.0
>>
>>
--
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH 1/5] media: i2c: vd55g1: Fix media bus code initialization
From: Benjamin Mugnier @ 2026-06-25 11:41 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <ajj90hhNwx7bLkOZ@zed>
Hi Jacopo,
Thank you for your review.
Le 22/06/2026 à 11:28, Jacopo Mondi a écrit :
> Hi Benjamin
>
> On Tue, Apr 28, 2026 at 10:40:55AM +0200, Benjamin Mugnier wrote:
>> In the driver initialization, the index of the default media bus code
>> from the supported media bus code array is passed directly to the
>> vd55g1_get_fmt_code() function instead of the proper media bus code.
>>
>> This works correctly as a proper media bus code is set after
>> initialization but could not have been the case. This also resulted in
>> mutliple "Unsupported mbus format" error messages.
>>
>> Retrieve the media bus code from the media bus code array, and pass this
>> media bus code to vd55g1_get_fmt_code() instead of the code index.
>>
>> Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and
>> VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future
>> confusions. Display the guilty error code in warning message.
>>
>> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
>>
> You should cc stable for fixes
>
> Cc: stable@vger.kernel.org
>
We talked about this very recently and somehow I still forgot.
>
> The CI should have flagged that, but for some reason it didn't run
> properly on your series
> https://gitlab.freedesktop.org/linux-media/users/patchwork/-/pipelines/1655147
>
>> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
>> ---
>> drivers/media/i2c/vd55g1.c | 17 +++++++++++------
>> 1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
>> index 78d18c028154..1e9db21322e3 100644
>> --- a/drivers/media/i2c/vd55g1.c
>> +++ b/drivers/media/i2c/vd55g1.c
>> @@ -114,9 +114,9 @@
>>
>> #define VD55G1_WIDTH 804
>> #define VD55G1_HEIGHT 704
>> -#define VD55G1_MODE_DEF 0
>> +#define VD55G1_MODE_IDX_DEF 0
>> #define VD55G1_NB_GPIOS 4
>> -#define VD55G1_MBUS_CODE_DEF 0
>> +#define VD55G1_MBUS_CODE_IDX_DEF 0
>> #define VD55G1_DGAIN_DEF 256
>> #define VD55G1_AGAIN_DEF 19
>> #define VD55G1_EXPO_MAX_TERM 64
>> @@ -634,7 +634,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
>
> Unrelated, but it seems you now have 2 codes for MONO. Does
>
> if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> return code;
>
> need an update ?>
Not in this patch because it does not add the new MONO sensor, but in
4/5 I separated the model ID from the color code. Example for the vd55g4 :
.name = "vd55g4",
.id = VD55G1_MODEL_ID_3,
.color = VD55G1_COLOR_VERSION_MONO,
So the patch 4/5 updates the previous 'if' you mentioned to check the
color member instead of the model :
if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
Which IMO is a good way to handle this problematic. Tell me if you're
thinking about something else.
>> goto adapt_bayer_pattern;
>> }
>> }
>> - dev_warn(sensor->dev, "Unsupported mbus format\n");
>> + dev_warn(sensor->dev, "Unsupported mbus format: 0x%x\n", code);
>>
>> return code;
>>
>> @@ -1347,6 +1347,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> {
>> struct vd55g1 *sensor = to_vd55g1(sd);
>> struct v4l2_subdev_format fmt = { 0 };
>> + int code;
>> struct v4l2_subdev_route routes[] = {
>> { .flags = V4L2_SUBDEV_ROUTE_FL_ACTIVE }
>> };
>> @@ -1361,9 +1362,13 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> if (ret)
>> return ret;
>>
>> - vd55g1_update_pad_fmt(sensor, &vd55g1_supported_modes[VD55G1_MODE_DEF],
>> - vd55g1_get_fmt_code(sensor, VD55G1_MBUS_CODE_DEF),
>> - &fmt.format);
>> + if (sensor->id == VD55G1_MODEL_ID_VD55G1)
>> + code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
>> + else
>> + code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
>
> Being this a multi-dimensional array, I don't seem much value in
> defining VD55G1_MBUS_CODE_IDX_DEF if this is the only place where it
> is used. What's the meaning of VD55G1_MBUS_CODE_IDX_DEF for
> vd55g1_mbus_formats_bayer ? Does it represent the bitwidth or does it
> represent the bayer pattern ?
For vd55g1_mbus_formats_bayer, the first dimension of the array is the
bitwidth, and the second one is the bayer pattern.
>
> I would rather define a
> VD55G1_DEF_MBUS_CODE_MONO MEDIA_BUS_FMT_Y8_1X8
> VD55G1_DEF_MBUS_CODE_BAYER MEDIA_BUS_FMT_SRGGB8_1X8
>
> Or maybe do
>
> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF]
> [VD55G1_MBUS_CODE_IDX_DEF];
>
> if easier.
>
> I understand it's a minor, so up to you.
As you mentioned it's only used here. I won't mind removing
VD55G1_MBUS_CODE_IDX_DEF entirely and do :
code = vd55g1_mbus_formats_bayer[0][0];
Does that sound okay ?
>
>
>
>> + vd55g1_update_pad_fmt(sensor,
>> + &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
>> + vd55g1_get_fmt_code(sensor, code), &fmt.format);
>>
>> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
>> }
>>
>> --
>> 2.43.0
>>
>>
--
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH 2/5] media: i2c: vd55g1: Remove spurious pad format update on init_state()
From: Benjamin Mugnier @ 2026-06-25 11:41 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <ajkAdol1szOK_XPB@zed>
Hi Jacopo,
Le 22/06/2026 à 11:30, Jacopo Mondi a écrit :
> Hi Benjamin
>
> On Tue, Apr 28, 2026 at 10:40:56AM +0200, Benjamin Mugnier wrote:
>> vd55g1_update_pad_fmt() is called in vd55g1_init_state(). But
>> vd55g1_set_pad_fmt(), called at the end of vd55g1_init_state(), also
>> calls vd55g1_update_pad_fmt() itself.
>>
>> Enhance readability and clear confusion by only preparing the format in
>> vd55g1_init_state() and let vd55g1_set_pad_fmt() update it instead,
>> effectively calling it only 1 time instead of 2.
>>
>> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
>
> Does this qualify as a fix ?
That's a good question, indeed this patch does not correct any 'bug' per
se. It's more of a code flow error so I think you're correct. I'm fine
with removing the 'Fixes:' tag.
>
> I think you could maybe squash it with the previous one if you want
> also this change to be backported as part of a larger fix
>
I don't know, this patch solves another issue than the previous patch
does. I'd like to keep it this in the git history if you don't mind.
>>
>> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
>
> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> Thanks
> j
>
>> ---
>> drivers/media/i2c/vd55g1.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
>> index 1e9db21322e3..e44174056ace 100644
>> --- a/drivers/media/i2c/vd55g1.c
>> +++ b/drivers/media/i2c/vd55g1.c
>> @@ -1366,9 +1366,9 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
>> else
>> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
>> - vd55g1_update_pad_fmt(sensor,
>> - &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
>> - vd55g1_get_fmt_code(sensor, code), &fmt.format);
>> + fmt.format.code = vd55g1_get_fmt_code(sensor, code);
>> + fmt.format.width = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].width;
>> + fmt.format.height = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].height;
>>
>> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
>> }
>>
>> --
>> 2.43.0
>>
>>
--
Regards,
Benjamin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox