* RE: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
From: Sherry Sun @ 2026-06-10 10:13 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Krzysztof Kozlowski, sashiko-reviews@lists.linux.dev,
manivannan.sadhasivam@oss.qualcomm.com, linux-pci@vger.kernel.org,
robh@kernel.org, Frank.Li@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev
In-Reply-To: <mvxoynvocxcalxcwogbiovg5yurjczxqfu2fqkji33bunmlplz@zxqjsdjts65j>
> On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > > > Thank you for your contribution! Sashiko AI review found 1
> > > > potential
> > > issue(s) to consider:
> > > > - [Medium] The `vpcie3v3aux-supply` property describes a
> > > > non-existent
> > > hardware feature on the M.2 Key E connector to work around a
> > > software policy.
> > >
> > > Feels valid. Describe which pin on M2 connector are you representing.
> > >
> >
> > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > Grounds.
> >
> > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > source, 3.3 V, is expected to be available during the system’s
> > stand-by/suspend state to support wake event processing on the
> > communications card.
> >
> > But the current vpcie3v3-supply may be gated off during system suspend.
> > So I tried to add vpcie3v3aux-supply to let this 3.3 V power source
> > always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
> > and vpcie3v3-supply actually refer to the same 3.3 V power source.
> >
> > @Mani, do you think this is reasonable? Or do you have any other
> > better solutions? Thanks!
> >
>
> There is no Vaux defined in the M.2 spec. So you cannot define that supply in
> the binding. You can define the custom Vaux supply as a fixed regulator in DT
> and mark it always on so that it is keeps supplying 3.3v to the card.
>
Hi Mani, thanks for the suggestion, but adding an always on regulator may
cause board power waste, current solution ensures the 3.3v regulator is
only enabled when M.2 connector needs to work .
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add HINLINK H28K
From: sashiko-bot @ 2026-06-10 10:15 UTC (permalink / raw)
To: Chukun Pan; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260610100006.366963-3-amadeus@jmu.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added device tree `rk3528-hinlink-h28k.dts` fails to compile because it references undefined USB node labels.
--
commit 07ca37acc11522d114428bc076a631a2223bfa47
Author: Chukun Pan <amadeus@jmu.edu.cn>
Subject: arm64: dts: rockchip: Add HINLINK H28K
This commit introduces a new device tree for the HINLINK H28K (LinkStar
H28K) single-board computer based on the Rockchip RK3528 SoC. It adds
support for basic features including Ethernet, eMMC, MicroSD, and USB.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
[ ... ]
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0m0_xfer>;
> + status = "okay";
> +};
> +
> +&usb2phy {
> + status = "okay";
> +};
> +
> +&usb2phy_host {
> + phy-supply = <&vcc5v0_sys>;
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
[Severity: Low]
Are these USB node labels defined in the included rk3528.dtsi at this
revision? It appears that referencing &usb2phy, &usb2phy_host,
&usb_host0_ehci, and &usb_host0_ohci here will cause a DTC build failure
with a "Label or path not found" error because the underlying node labels
do not seem to exist yet in the included trees.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610100006.366963-1-amadeus@jmu.edu.cn?part=2
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: pwm: dwc: Add eswin compatible and resets property
From: Krzysztof Kozlowski @ 2026-06-10 10:17 UTC (permalink / raw)
To: Xuyang Dong
Cc: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel, ningyu, linmin, xuxiang,
wangguosheng, pinkesh.vaghela
In-Reply-To: <25b0baf0.731a.19eb0d9bf07.Coremail.dongxuyang@eswincomputing.com>
On 10/06/2026 11:25, Xuyang Dong wrote:
>>> Hi Krzysztof,
>>>
>>> Thanks for your comments and time.
>>>
>>> Regarding snps,dw-apb-timers-pwm2, we previously intended to add the
>>> resets property in the same patch.
>>> However, as you suggested, we will split it into a separate patch.
>>
>> I find commit msg still confusing. Please always clearly explain WHY you
>> are doing changes.
>>
>
> Hi Krzysztof,
>
> Thanks for your comments.
>
> According to the DesignWare IP for PWM controllers manual, it seems to me
> that Ben's previous submission may have missed the optional resets property.
>
> Therefore, I would like to confirm: should I submit a separate fix patch for
> the resets property, or include it as a feature patch in this series?
>
One change is adding resets to existing binding for existing device.
With its own rationale.
Another change is adding new device compatible with its own necessary
changes (if resets are different).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/3] dmaengine: atcdmac300: Add driver for Andes ATCDMAC300 DMA controller
From: sashiko-bot @ 2026-06-10 10:17 UTC (permalink / raw)
To: CL Wang; +Cc: conor+dt, robh, vkoul, devicetree, Frank.Li, dmaengine
In-Reply-To: <20260610095724.1980622-3-cl634@andestech.com>
Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
- [High] Unmanaged `cyclic` flag leads to NULL pointer dereferences, infinite loops, and resume panics.
- [High] Interrupt handler masks hardware interrupt status with `used_chan`, leaving unmasked interrupts unacknowledged.
- [High] Premature execution of unissued DMA descriptors violates the DMA engine API.
- [High] Missing `device_synchronize` callback prevents safe client synchronization with the threaded IRQ handler.
- [High] Fetching the client callback outside the lock in `atcdmac_advance_work` creates a Use-After-Free race with channel termination.
- [High] Reusing descriptors from `free_list` does not clear previously set callbacks and parameters.
- [Medium] `atcdmac_set_device_config` strictly validates unused configuration fields, breaking unidirectional slave configurations.
- [Medium] Asymmetric registration and teardown order creates Use-After-Free vulnerabilities and Race Conditions.
- [Medium] Prepared but unsubmitted DMA descriptors are permanently leaked due to missing `desc_free` callback.
- [Medium] Truncation of `size_t len` to `unsigned int trans_size` could lead to incomplete DMA transfers on 64-bit platforms.
--
commit 892196b95d4c6cbcb6477d01fb69f6b5e13d4612
Author: CL Wang <cl634@andestech.com>
dmaengine: atcdmac300: Add driver for Andes ATCDMAC300 DMA controller
This patch adds support for the Andes ATCDMAC300 DMA controller.
It provides memory-to-memory and peripheral DMA controller
support with scatter-gather, cyclic, and slave transfer capabilities.
> diff --git a/drivers/dma/atcdmac300.c b/drivers/dma/atcdmac300.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/dma/atcdmac300.c
> @@ -0,0 +1,1518 @@
[ ... ]
> +static struct atcdmac_desc *atcdmac_alloc_desc(struct dma_chan *chan,
> + gfp_t gfp_flags)
> +{
[ ... ]
> + desc = dma_pool_zalloc(dmac->dma_desc_pool, gfp_flags, &phys);
> + if (desc) {
> + INIT_LIST_HEAD(&desc->tx_list);
> + dma_async_tx_descriptor_init(&desc->txd, chan);
> + desc->txd.flags = DMA_CTRL_ACK;
[Severity: Medium]
Is there a missing assignment for the desc_free callback here?
When a client prepares a transaction, descriptors are removed from
dmac_chan->free_list. If the client aborts and calls dmaengine_desc_free(),
the dmaengine core attempts to invoke desc->txd.desc_free. Because
atcdmac_alloc_desc() never assigns this callback, the core drops the
descriptor.
Since atcdmac_free_chan_resources() only reclaims descriptors currently
present in free_list, any orphaned, unsubmitted descriptors seem permanently
leaked from dmac->dma_desc_pool. Can we add the appropriate callback to
prevent pool exhaustion?
> + desc->txd.tx_submit = atcdmac_tx_submit;
> + desc->txd.phys = phys;
> + }
> +
> + return desc;
> +}
[ ... ]
> +static struct atcdmac_desc *atcdmac_get_desc(struct atcdmac_chan *dmac_chan)
> +{
[ ... ]
> + spin_lock_irqsave(&dmac_chan->lock, flags);
> + list_for_each_entry_safe(desc, desc_next,
> + &dmac_chan->free_list,
> + desc_node) {
> + if (async_tx_test_ack(&desc->txd)) {
> + list_del_init(&desc->desc_node);
> + ret = desc;
> + break;
> + }
[Severity: High]
Should the descriptor callback and parameter fields be reset before reusing
it from the free_list?
When atcdmac_get_desc() retrieves a descriptor for a new transfer, it does
not appear to zero out desc->txd.callback and desc->txd.callback_param. If a
client previously used this descriptor with a callback, freed its context,
and reuses it without setting a new callback, the DMA engine might
inadvertently execute the stale callback.
Could this lead to use-after-free issues if the context is already freed?
> + }
> + spin_unlock_irqrestore(&dmac_chan->lock, flags);
[ ... ]
> +static void atcdmac_start_next_trans(struct atcdmac_chan *dmac_chan)
> +{
> + struct atcdmac_desc *next_tx = NULL;
> + struct atcdmac_desc *dma_desc;
> +
> + if (dmac_chan->cyclic) {
> + /* Get the next DMA descriptor from tx_list. */
> + dma_desc = atcdmac_get_active_head(dmac_chan);
> + dma_desc->at = dma_desc->at->next;
[Severity: High]
Does this sequence safely handle channels that have transitioned from cyclic
to non-cyclic transfers, or handle resume states properly?
The driver sets dmac_chan->cyclic to true in atcdmac_prep_dma_cyclic(), but
this flag is never reset to false during atcdmac_terminate_all() or when
preparing subsequent non-cyclic transfers like memcpy.
If a channel is used for a cyclic transfer, terminated, and then reused for a
non-cyclic transfer, the stale cyclic state causes atcdmac_advance_work() to
enter the cyclic path here. For memcpy descriptors, this leads to a null
pointer dereference on dma_desc->at->next.
Additionally, during system resume, atcdmac_resume() unconditionally calls
atcdmac_start_next_trans() on all channels. For a terminated cyclic channel,
active_list is empty, causing atcdmac_get_active_head() to return an invalid
pointer and crashing the kernel upon dereference.
> + if ((uintptr_t)dma_desc->at == (uintptr_t)&dma_desc->tx_list)
> + next_tx = list_entry(dma_desc->at,
> + struct atcdmac_desc,
> + tx_list);
> + else
> + next_tx = list_entry(dma_desc->at,
> + struct atcdmac_desc,
> + desc_node);
> + } else {
> + if (list_empty(&dmac_chan->active_list)) {
> + if (!list_empty(&dmac_chan->queue_list)) {
> + list_splice_init(&dmac_chan->queue_list,
> + &dmac_chan->active_list);
[Severity: High]
Is it safe to splice the entire queue_list into active_list without checking
if the client has explicitly issued the pending descriptors?
The DMA engine API contract requires that descriptors submitted via tx_submit
remain pending and are not started until the client explicitly calls
dma_async_issue_pending().
However, atcdmac_advance_work() unconditionally splices unissued descriptors
from queue_list into active_list when a prior transaction completes.
Similarly, atcdmac_resume() pulls unissued descriptors from queue_list. If a
client submits descriptors but intentionally delays issuing them (e.g. waiting
for a peripheral), the driver will incorrectly execute them prematurely.
> + next_tx = atcdmac_get_active_head(dmac_chan);
> + }
[ ... ]
> +static void atcdmac_advance_work(struct atcdmac_chan *dmac_chan)
> +{
[ ... ]
> + if (dmac_chan->cyclic) {
> + if (!stop)
> + atcdmac_start_next_trans(dmac_chan);
> +
> + spin_unlock_irqrestore(&dmac_chan->lock, flags);
> + res.result = DMA_TRANS_NOERROR;
> + dmaengine_desc_get_callback_invoke(&dma_desc->txd, &res);
[Severity: High]
Does fetching the client callback outside the channel lock create a
use-after-free race condition?
For cyclic transfers, dma_desc remains on active_list. The lock is dropped
via spin_unlock_irqrestore() before accessing dma_desc->txd to invoke the
callback.
While the lock is dropped, a concurrent dmaengine_terminate_all() can acquire
the lock, splice the active_list away, and return dma_desc to the free_list.
The client might then release the channel, freeing the descriptor back to the
pool. The IRQ thread will then use the freed descriptor to invoke the
callback. Should the callback information be extracted while the lock is
still held?
> + } else {
[ ... ]
> +static irqreturn_t atcdmac_interrupt(int irq, void *dev_id)
> +{
> + struct atcdmac_dmac *dmac = dev_id;
> + struct atcdmac_chan *dmac_chan;
> + unsigned int status;
> + unsigned int int_ch;
> + int ret = IRQ_NONE;
> + int i;
> +
> + regmap_read(dmac->regmap, REG_INT_STA, &status);
> + int_ch = READ_ONCE(dmac->used_chan) & DMA_INT_ALL(status);
> +
> + while (int_ch) {
[Severity: High]
Can this loop leave hardware interrupts unacknowledged and cause an interrupt
storm?
The handler masks the hardware interrupt status with the software-tracked
used_chan mask. It only clears the interrupts identified by int_ch. If the
hardware asserts an interrupt for a channel not currently in used_chan
(for instance, an ABT interrupt generated by atcdmac_terminate_all() on a
previously idle channel, or a spurious interrupt), int_ch evaluates to 0.
Because the while loop is skipped, the handler will not clear REG_INT_STA
and returns IRQ_NONE. Since the interrupt is level-triggered, the uncleared
interrupt will immediately re-fire, causing an infinite loop until the
kernel disables the IRQ line.
> + spin_lock(&dmac->lock);
> + dmac->used_chan = READ_ONCE(dmac->used_chan) & ~int_ch;
> + spin_unlock(&dmac->lock);
> + regmap_write(dmac->regmap, REG_INT_STA, DMA_INT_CLR(int_ch));
[ ... ]
> +static struct dma_async_tx_descriptor *
> +atcdmac_prep_dma_memcpy(struct dma_chan *chan,
> + dma_addr_t dst,
> + dma_addr_t src,
> + size_t len,
> + unsigned long flags)
> +{
[ ... ]
> + ctrl = SRC_BURST_SIZE(src_max_burst) |
> + SRC_ADDR_MODE_INCR |
> + DST_ADDR_MODE_INCR |
> + DST_WIDTH(dst_width) |
> + SRC_WIDTH(src_width);
> +
> + desc = atcdmac_build_desc(dmac_chan, src, dst, ctrl,
> + len >> src_width, 1);
[Severity: Medium]
Could the truncation of size_t len lead to incomplete DMA transfers on 64-bit
platforms?
Here, the 64-bit size_t len is shifted and passed as an unsigned int into
atcdmac_build_desc(). If a user requests a transfer length such that
len >> src_width exceeds 32 bits, the value will be silently truncated. The
DMA hardware would perform a shorter transfer but report success, leading to
silent data corruption. Is there a way to safely bound or reject overly large
sizes?
> + if (!desc)
> + goto err_desc_get;
[ ... ]
> +static int atcdmac_set_device_config(struct dma_chan *chan,
> + struct dma_slave_config *sconfig)
> +{
> + struct atcdmac_chan *dmac_chan = atcdmac_chan_to_dmac_chan(chan);
> +
> + /* Check if this chan is configured for device transfers */
> + if (!dmac_chan->dev_chan)
> + return -EINVAL;
> +
> + /* Must be powers of two according to ATCDMAC300 spec */
> + if (!is_power_of_2(sconfig->src_maxburst) ||
> + !is_power_of_2(sconfig->dst_maxburst) ||
> + !is_power_of_2(sconfig->src_addr_width) ||
> + !is_power_of_2(sconfig->dst_addr_width))
> + return -EINVAL;
[Severity: Medium]
Does this check incorrectly reject valid, standard unidirectional
configurations?
Standard DMA engine consumers populate only the dma_slave_config fields
corresponding to their active transfer direction, leaving fields for the
unused direction as 0.
Because is_power_of_2(0) returns false, this strict global validation rejects
perfectly valid setups with -EINVAL, forcing clients to provide dummy
parameters for unused directions. Could the validation be limited to the
active transfer direction?
> +
> + memcpy(&dmac_chan->dma_sconfig, sconfig, sizeof(*sconfig));
[ ... ]
> +static void atcdmac_init_dma_device(struct platform_device *pdev,
> + struct atcdmac_dmac *dmac)
> +{
> + struct dma_device *device = &dmac->dma_device;
> +
> + device->device_alloc_chan_resources = atcdmac_alloc_chan_resources;
> + device->device_free_chan_resources = atcdmac_free_chan_resources;
> + device->device_tx_status = atcdmac_get_tx_status;
> + device->device_issue_pending = atcdmac_issue_pending;
> + device->device_prep_dma_memcpy = atcdmac_prep_dma_memcpy;
> + device->device_prep_slave_sg = atcdmac_prep_device_sg;
> + device->device_config = atcdmac_set_device_config;
> + device->device_terminate_all = atcdmac_terminate_all;
> + device->device_prep_dma_cyclic = atcdmac_prep_dma_cyclic;
[Severity: High]
Is the device_synchronize callback missing from this list?
The driver processes completions and invokes client callbacks in a threaded
IRQ handler (atcdmac_advance_work). Clients rely on
dmaengine_terminate_sync() to ensure all transfers are aborted and no
callbacks are executing before freeing resources.
Without a device_synchronize callback, dmaengine_terminate_sync() fails to
wait for the threaded IRQ. If a client unloads immediately after calling it,
the IRQ thread may still be executing the client's callback, triggering a
use-after-free or executing unloaded module code.
> +
> + device->dev = &pdev->dev;
[ ... ]
> +static int atcdmac_probe(struct platform_device *pdev)
> +{
[ ... ]
> + atcdmac_init_dma_device(pdev, dmac);
> +
> + ret = dma_async_device_register(&dmac->dma_device);
> + if (ret)
> + return ret;
> +
> + ret = atcdmac_init_irq(pdev, dmac);
[Severity: Medium]
Does registering the device before fully initializing it expose the driver
to use-after-free or race conditions?
Here, dma_async_device_register() is called before atcdmac_init_irq() and
atcdmac_init_iocp(). Once registered, the device is globally visible and
clients can acquire channels and submit transfers before the IRQ handler or
cache consistency parameters are fully set up.
If the subsequent initialization steps fail, dmac is freed while a client may
be holding a channel reference. Symmetrically, in atcdmac_remove(), the
driver resets the hardware before calling dma_async_device_unregister(),
meaning active clients may submit new transfers that the now-reset hardware
will attempt to execute. Should registration happen at the very end of probe?
> + if (ret)
> + goto err_dma_async_register;
> +
> + ret = atcdmac_init_iocp(pdev, dmac);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610095724.1980622-1-cl634@andestech.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Francesco Dolcini @ 2026-06-10 10:22 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Krzysztof Kozlowski, Bjorn Andersson, Mathieu Poirier,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Peng Fan, Fabio Estevam, Daniel Baluta, Francesco Dolcini,
linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <2fc48536-5af9-419e-b4df-746b678cb6ab@gmail.com>
On Wed, Jun 10, 2026 at 02:10:37AM -0700, Laurentiu Mihalcea wrote:
>
>
> On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
> > On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> >> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >>
> >> The names of the carveout regions are derived using the names of the
> >> reserved memory devicetree nodes, which are referenced using the
> >> "memory-region" property. This adds a restriction on the names of said
> >> devicetree nodes, often bearing specific names such as: "vdevbuffer",
> >> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> >> specification's recommendation, which states that the devicetree node
> >> names should be generic.
> >
> > No, it does not. Names like rsc-table feels exactly like DT spec is
> > asking - for a name matching purpose. Are you sure you read the spec?
>
> Quoting from the spec:
>
> "The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model"
>
> and looking at the examples provided in "2.2.2 Generic Names Recommendation",
> wouldn't "memory" be a more appropriate choice for the DT node name instead of
> "rsc-table" since it's more generic, while still matching the purpose
> of the device? Or perhaps I'm interpreting this the wrong way?
Please see
https://lore.kernel.org/all/CAL_JsqKRW-=er+DCTob0HmQv9OyVt7yiej-Yht6UR-mcW=LHUg@mail.gmail.com/
Francesco
^ permalink raw reply
* Re: [PATCH v6 00/11] ASoC: renesas: fsi: Fix system hang by adding SPU clock
From: Mark Brown @ 2026-06-09 23:34 UTC (permalink / raw)
To: Kuninori Morimoto, Geert Uytterhoeven, phucduc.bui
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260609113836.45079-1-phucduc.bui@gmail.com>
On Tue, 09 Jun 2026 18:38:25 +0700, phucduc.bui@gmail.com wrote:
> ASoC: renesas: fsi: Fix system hang by adding SPU clock
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Hi all,
>
> The FSI on r8a7740 requires the SPU clock to be enabled before accessing
> its internal registers. Without it, register accesses may hang the system
> even when the FSI functional clock is enabled.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[01/11] ASoC: dt-bindings: renesas,fsi: add support multiple clocks
https://git.kernel.org/broonie/sound/c/955fecff55c3
[03/11] ASoC: renesas: fsi: Fix trigger stop ordering
https://git.kernel.org/broonie/sound/c/859efe92b0bc
[04/11] ASoC: renesas: fsi: Move fsi_stream_is_working()
https://git.kernel.org/broonie/sound/c/c9e05e2fa089
[05/11] ASoC: renesas: fsi: Fix register access from in-flight IRQ after shutdown
https://git.kernel.org/broonie/sound/c/e813df3ef529
[06/11] ASoC: renesas: fsi: Move fsi_clk_init()
https://git.kernel.org/broonie/sound/c/cfa1466e6dfd
[07/11] ASoC: renesas: fsi: Use devm_clk_get_optional() for optional clocks
https://git.kernel.org/broonie/sound/c/5fb4660ce59b
[08/11] ASoC: renesas: fsi: refactor clock initialization
https://git.kernel.org/broonie/sound/c/2330e0b49f14
[09/11] ASoC: renesas: fsi: Add SPU clock support
https://git.kernel.org/broonie/sound/c/39033b278f9c
[10/11] ASoC: renesas: fsi: add fsi_clk_prepare/unprepare()
https://git.kernel.org/broonie/sound/c/05e1ebfeb726
[11/11] ASoC: renesas: fsi: Add SPU clock control in hw_startup/shutdown
https://git.kernel.org/broonie/sound/c/26deeee42f4f
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [net-next 0/9] ravb: Add gPTP support for Gen4
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
Hello,
This series is the second part cleaning up how PTP timer support is
implemented on R-Car Gen4. Currently there is partial support for it in
some of the Ethernet devices that can use it, but not all.
On Gen2 and Gen3 each RAVB instance have it's own private PTP clock as
part of the RAVB register space. For this reason the PTP functionally
was implemented directly in the RAVB driver. For Gen4 however there is a
system-wide PTP clock shared by all RAVB instances, and on some Gen4
platforms with other Ethernet devices.
The RAVB Gen4 driver currently advertise PTP support to user-space, but
the support is in fact completely broken. It tries to use RAVB private
PTP clock, which do not exist on Gen4.
Further more the PTP clock behaved slightly different on Gen2 and Gen3.
These decencies have been handled by adding platform specific flags
inside the driver.
The usage of these flags have grown organically and been extended all
over the driver as it gained new features. Adding a new third set of
flags for Gen4 would be messy and add to the confusion.
Therefore patches 1/9 thru 7/9 refactors the usage of the PTP flags into
optional callbacks and untangles the usage. This allows adding Gen4
support easy as it can just implement it's own set of Gen4 specific
callbacks without altering the driver logic.
Patch 8/9 is a small DT binding addition adding an optional phandle to
link a RAVB device to the external PTP clock. Ideally this property
should be mandatory, but for backward comp ability is is made optional.
If the phandle is not set, or the PTP clock not enabled, the RAVB driver
will continue to faction as before, but no longer advertise PTP support
to user space.
Finally patch 9/9 adds the Gen4 specific PTP callbacks which allows the
driver to use the external PTP clock.
For part one of this work see [1]. The two series are independent of
each other but both are needed before a third series liking the RAVB to
the PTP clock in the platforms device tree. I will hold posting the
third series until all dependencies are merged. For this reason there is
no user of the new renesas,gptp device tree property added in this
series.
The work is tested on both Gen3 and Gen4 R-Car devices (with [1] and
appropriate DTS). I do however not have access to any Gen2 device where
the RAVB IP is wired to a MAC, so the small rework of the flags for Gen2
to callbacks have only been compiled tested. If anybody have a RZ device
where RAVB is wired and uses the Gen2 method of starting/stopping the
PTP timer together with the DMAC please test this.
1. https://lore.kernel.org/all/20260609215711.2960150-1-niklas.soderlund+renesas@ragnatech.se/
Niklas Söderlund (9):
net: ethernet: ravb: Remove gPTP control from WoL setup and restore
net: ethernet: ravb: Move programming of gPTP timer interval
net: ethernet: ravb: Simplify gPTP start and stop
net: ethernet: ravb: Remove redundant argument to ravb_ptp_init()
net: ethernet: ravb: Replace gPTP flags with callbacks
net: ethernet: ravb: Add callback for gPTP probe
net: ethernet: ravb: Add callback for gPTP clock index
dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
net: ethernet: ravb: Add gPTP support for Gen4
.../bindings/net/renesas,etheravb.yaml | 16 ++
drivers/net/ethernet/renesas/ravb.h | 34 ++-
drivers/net/ethernet/renesas/ravb_main.c | 246 ++++++++++++------
drivers/net/ethernet/renesas/ravb_ptp.c | 15 +-
4 files changed, 219 insertions(+), 92 deletions(-)
--
2.54.0
^ permalink raw reply
* [net-next 1/9] net: ethernet: ravb: Remove gPTP control from WoL setup and restore
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
Since commit a6a85ba36fd0 ("net: ravb: Move PTP initialization in the
driver's ndo_open API for ccc_gac platorms") the gPTP clock (if
supported) is stopped and started by opening and closing the ndev.
This makes the special case to stop and start it when resuming from WoL
redundant. As the ndev will always be closed and re-opened when
suspending and resuming the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 5f88733094d0..77c0645a1c4d 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -3179,9 +3179,6 @@ static int ravb_wol_setup(struct net_device *ndev)
/* Enable MagicPacket */
ravb_modify(ndev, ECMR, ECMR_MPDE, ECMR_MPDE);
- if (priv->info->ccc_gac)
- ravb_ptp_stop(ndev);
-
return enable_irq_wake(priv->emac_irq);
}
@@ -3201,9 +3198,6 @@ static int ravb_wol_restore(struct net_device *ndev)
if (error)
return error;
- if (priv->info->ccc_gac)
- ravb_ptp_init(ndev, priv->pdev);
-
if (info->nc_queues)
napi_enable(&priv->napi[RAVB_NC]);
napi_enable(&priv->napi[RAVB_BE]);
--
2.54.0
^ permalink raw reply related
* [net-next 2/9] net: ethernet: ravb: Move programming of gPTP timer interval
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
Commit f384ab481cab ("net: ravb: Split GTI computation and set
operations") broke apart the operations of computing the timer interval
and programming of it. However it kept the programming of the interval
in the RAVB main logic.
Having split the two apart this can be improved further by moving the
programming to the gPTP initialization function, as the first action of
the gPTP init function is to wait for the timer interval programming to
be acknowledge by the hardware.
As an added bonus the interaction with the gPTP registers for the
programming can then also be done while holding the gPTP registers lock.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb_main.c | 16 ----------------
drivers/net/ethernet/renesas/ravb_ptp.c | 11 ++++++++++-
2 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 77c0645a1c4d..dc2fbbeff895 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1846,20 +1846,6 @@ static int ravb_set_config_mode(struct net_device *ndev)
return error;
}
-static void ravb_set_gti(struct net_device *ndev)
-{
- struct ravb_private *priv = netdev_priv(ndev);
- const struct ravb_hw_info *info = priv->info;
-
- if (!(info->gptp || info->ccc_gac))
- return;
-
- ravb_write(ndev, priv->gti_tiv, GTI);
-
- /* Request GTI loading */
- ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
-}
-
static int ravb_compute_gti(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
@@ -1974,8 +1960,6 @@ static int ravb_open(struct net_device *ndev)
ravb_emac_init(ndev);
- ravb_set_gti(ndev);
-
/* Initialise PTP Clock driver */
if (info->gptp || info->ccc_gac)
ravb_ptp_init(ndev, priv->pdev);
diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c b/drivers/net/ethernet/renesas/ravb_ptp.c
index 226c6c0ab945..7c78f75cb284 100644
--- a/drivers/net/ethernet/renesas/ravb_ptp.c
+++ b/drivers/net/ethernet/renesas/ravb_ptp.c
@@ -319,11 +319,20 @@ void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
priv->ptp.info = ravb_ptp_info;
- priv->ptp.default_addend = ravb_read(ndev, GTI);
+ priv->ptp.default_addend = priv->gti_tiv;
priv->ptp.current_addend = priv->ptp.default_addend;
spin_lock_irqsave(&priv->lock, flags);
+
+ /* Set gPTP Timer Increment Value. */
+ ravb_write(ndev, priv->ptp.default_addend, GTI);
+
+ /* Request GTI loading. */
+ ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
+
+ /* Wait for GIT loading to complete. */
ravb_wait(ndev, GCCR, GCCR_TCR, GCCR_TCR_NOREQ);
+
ravb_modify(ndev, GCCR, GCCR_TCSS, GCCR_TCSS_ADJGPTP);
spin_unlock_irqrestore(&priv->lock, flags);
--
2.54.0
^ permalink raw reply related
* [net-next 3/9] net: ethernet: ravb: Simplify gPTP start and stop
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
For devices that do not support the gPTP clock in config mode the
somewhat oddly named flag gptp is set, compared to devices that do
support the gPTP clock in config and operation mode where the flag
ccc_gac is set instead. The two flags are mutually exclusive.
For the gptp-flag devices (Gen2) the clock is tied to the AVB-DMAC, when
it is stopped so is the gPTP clock. For ccc_gac-flag devices (Gen3) the
gPTP clock is available whenever the ndev is open.
Prepare to add Gen4 support which will add a third way by cleaning the
Gen2 and Gen3 cases up a bit.
Fold the gptp-flag start and stop calls into ravb_dmac_init() and
ravb_stop_dma(), which start and stops the AVB-DMAC. There are no
functional change as all call sites to the construct,
if (info->gptp)
ravb_ptp_init(ndev, priv->pdev);
Are always just after a call to into ravb_dmac_init() and all call sites
to the to the construct,
if (info->gptp)
ravb_ptp_stop(ndev);
Are always directly followed by a call to ravb_stop_dma().
There are two special cases where the calling construct covers both the
gptp-flag and info->ccc_gac devices, one for start and one for stop. The
condition that it is preceded by a call to ravb_dmac_init(), or followed
by a call to ravb_stop_dma() are however true for them too. Reworked the
two special cases to drop the check of info->gptp.
The end result is that the gPTP clock will be started or stopped for the
gptp-flag devices in tandem with the AVB-DMAC, while the info->ccc_gac
devices will be controlled, as before, when the ndev is opened or
closed.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb_main.c | 37 ++++++++++--------------
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index dc2fbbeff895..dff66a347baf 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -707,7 +707,15 @@ static int ravb_dmac_init(struct net_device *ndev)
return error;
/* Setting the control will start the AVB-DMAC process. */
- return ravb_set_opmode(ndev, CCC_OPC_OPERATION);
+ error = ravb_set_opmode(ndev, CCC_OPC_OPERATION);
+ if (error)
+ return error;
+
+ /* Initialise PTP Clock driver */
+ if (info->gptp)
+ ravb_ptp_init(ndev, priv->pdev);
+
+ return 0;
}
static void ravb_get_tx_tstamp(struct net_device *ndev)
@@ -1115,6 +1123,10 @@ static int ravb_stop_dma(struct net_device *ndev)
netdev_err(ndev, "failed to stop AXI BUS\n");
}
+ /* Stop PTP Clock driver */
+ if (info->gptp)
+ ravb_ptp_stop(ndev);
+
/* Stop AVB-DMAC process */
return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
}
@@ -1719,9 +1731,7 @@ static int ravb_set_ringparam(struct net_device *ndev,
if (netif_running(ndev)) {
netif_device_detach(ndev);
- /* Stop PTP Clock driver */
- if (info->gptp)
- ravb_ptp_stop(ndev);
+
/* Wait for DMA stopping */
error = ravb_stop_dma(ndev);
if (error) {
@@ -1752,10 +1762,6 @@ static int ravb_set_ringparam(struct net_device *ndev,
ravb_emac_init(ndev);
- /* Initialise PTP Clock driver */
- if (info->gptp)
- ravb_ptp_init(ndev, priv->pdev);
-
netif_device_attach(ndev);
}
@@ -1961,7 +1967,7 @@ static int ravb_open(struct net_device *ndev)
ravb_emac_init(ndev);
/* Initialise PTP Clock driver */
- if (info->gptp || info->ccc_gac)
+ if (info->ccc_gac)
ravb_ptp_init(ndev, priv->pdev);
/* PHY control start */
@@ -1974,9 +1980,6 @@ static int ravb_open(struct net_device *ndev)
return 0;
out_ptp_stop:
- /* Stop PTP Clock driver */
- if (info->gptp || info->ccc_gac)
- ravb_ptp_stop(ndev);
ravb_stop_dma(ndev);
out_set_reset:
ravb_set_opmode(ndev, CCC_OPC_RESET);
@@ -2020,10 +2023,6 @@ static void ravb_tx_timeout_work(struct work_struct *work)
netif_tx_stop_all_queues(ndev);
- /* Stop PTP Clock driver */
- if (info->gptp)
- ravb_ptp_stop(ndev);
-
/* Wait for DMA stopping */
if (ravb_stop_dma(ndev)) {
/* If ravb_stop_dma() fails, the hardware is still operating
@@ -2056,10 +2055,6 @@ static void ravb_tx_timeout_work(struct work_struct *work)
ravb_emac_init(ndev);
out:
- /* Initialise PTP Clock driver */
- if (info->gptp)
- ravb_ptp_init(ndev, priv->pdev);
-
netif_tx_start_all_queues(ndev);
out_unlock:
@@ -2374,7 +2369,7 @@ static int ravb_close(struct net_device *ndev)
}
/* Stop PTP Clock driver */
- if (info->gptp || info->ccc_gac)
+ if (info->ccc_gac)
ravb_ptp_stop(ndev);
/* Set the config mode to stop the AVB-DMAC's processes */
--
2.54.0
^ permalink raw reply related
* [net-next 4/9] net: ethernet: ravb: Remove redundant argument to ravb_ptp_init()
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
There is no need to explicitly pass the struct platform_device pointer
to ravb_ptp_init(), it can retrieve it directly from the private data
structure.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb.h | 2 +-
drivers/net/ethernet/renesas/ravb_main.c | 4 ++--
drivers/net/ethernet/renesas/ravb_ptp.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index 5e56ec9b1013..013ced6dcf29 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -1160,7 +1160,7 @@ void ravb_modify(struct net_device *ndev, enum ravb_reg reg, u32 clear,
int ravb_wait(struct net_device *ndev, enum ravb_reg reg, u32 mask, u32 value);
void ravb_ptp_interrupt(struct net_device *ndev);
-void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev);
+void ravb_ptp_init(struct net_device *ndev);
void ravb_ptp_stop(struct net_device *ndev);
#endif /* #ifndef __RAVB_H__ */
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index dff66a347baf..b3cc4c79b29f 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -713,7 +713,7 @@ static int ravb_dmac_init(struct net_device *ndev)
/* Initialise PTP Clock driver */
if (info->gptp)
- ravb_ptp_init(ndev, priv->pdev);
+ ravb_ptp_init(ndev);
return 0;
}
@@ -1968,7 +1968,7 @@ static int ravb_open(struct net_device *ndev)
/* Initialise PTP Clock driver */
if (info->ccc_gac)
- ravb_ptp_init(ndev, priv->pdev);
+ ravb_ptp_init(ndev);
/* PHY control start */
error = ravb_phy_start(ndev);
diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c b/drivers/net/ethernet/renesas/ravb_ptp.c
index 7c78f75cb284..1c9b33d1b8b9 100644
--- a/drivers/net/ethernet/renesas/ravb_ptp.c
+++ b/drivers/net/ethernet/renesas/ravb_ptp.c
@@ -312,7 +312,7 @@ void ravb_ptp_interrupt(struct net_device *ndev)
ravb_write(ndev, ~(gis | GIS_RESERVED), GIS);
}
-void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
+void ravb_ptp_init(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
unsigned long flags;
@@ -336,7 +336,7 @@ void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
ravb_modify(ndev, GCCR, GCCR_TCSS, GCCR_TCSS_ADJGPTP);
spin_unlock_irqrestore(&priv->lock, flags);
- priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &pdev->dev);
+ priv->ptp.clock = ptp_clock_register(&priv->ptp.info, &priv->pdev->dev);
}
void ravb_ptp_stop(struct net_device *ndev)
--
2.54.0
^ permalink raw reply related
* [net-next 5/9] net: ethernet: ravb: Replace gPTP flags with callbacks
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
Prepare for adding Gen4 support which will add a third and new way to
interact with the gPTP clock by replacing the flags for Gen2 behavior
(info->gptp) and Gen3 behavior (info->ccc_gac) with callbacks.
This will make adding Gen4 support cleaner as the code will not have "if
else if else" sprinkled all over to handle each generations special
cases.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb.h | 24 ++++++-
drivers/net/ethernet/renesas/ravb_main.c | 80 +++++++++++++++---------
2 files changed, 73 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index 013ced6dcf29..70bef3b31d38 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -1034,6 +1034,27 @@ struct ravb_ptp {
struct ravb_ptp_perout perout[N_PER_OUT];
};
+/**
+ * struct ravb_gptp_info - Platform specific gPTP behavior
+ *
+ * Each generation of RAVB have slightly different behaviors when interacting
+ * with the gPTP clock. This struct provides the callbacks to be called at
+ * critical points in the RAVB driver.
+ *
+ * @set_config_mode: Enter config mode
+ * @dmac_start: Called when the DMAC starts
+ * @dmac_stop: Called when the DMAC stops
+ * @ndev_open: Called when the ndev is opened
+ * @ndev_close: Called when the ndev is closed
+ */
+struct ravb_gptp_info {
+ int (*set_config_mode)(struct net_device *ndev);
+ void (*dmac_start)(struct net_device *ndev);
+ void (*dmac_stop)(struct net_device *ndev);
+ void (*ndev_open)(struct net_device *ndev);
+ void (*ndev_close)(struct net_device *ndev);
+};
+
struct ravb_hw_info {
int (*receive)(struct net_device *ndev, int budget, int q);
void (*set_rate)(struct net_device *ndev);
@@ -1052,6 +1073,7 @@ struct ravb_hw_info {
u32 rx_buffer_size;
u32 rx_desc_size;
u32 dbat_entry_num;
+ const struct ravb_gptp_info *ptp; /* Callbacks to handle gPTP interactions. */
unsigned aligned_tx: 1;
unsigned coalesce_irqs:1; /* Needs software IRQ coalescing */
@@ -1062,8 +1084,6 @@ struct ravb_hw_info {
unsigned multi_irqs:1; /* AVB-DMAC and E-MAC has multiple irqs */
unsigned irq_en_dis:1; /* Has separate irq enable and disable regs */
unsigned err_mgmt_irqs:1; /* Line1 (Err) and Line2 (Mgmt) irqs are separate */
- unsigned gptp:1; /* AVB-DMAC has gPTP support */
- unsigned ccc_gac:1; /* AVB-DMAC has gPTP support active in config mode */
unsigned gptp_ref_clk:1; /* gPTP has separate reference clock */
unsigned nc_queues:1; /* AVB-DMAC has RX and TX NC queues */
unsigned magic_pkt:1; /* E-MAC supports magic packet detection */
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index b3cc4c79b29f..577cd2245e60 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -712,8 +712,8 @@ static int ravb_dmac_init(struct net_device *ndev)
return error;
/* Initialise PTP Clock driver */
- if (info->gptp)
- ravb_ptp_init(ndev);
+ if (info->ptp && info->ptp->dmac_start)
+ info->ptp->dmac_start(ndev);
return 0;
}
@@ -1124,8 +1124,8 @@ static int ravb_stop_dma(struct net_device *ndev)
}
/* Stop PTP Clock driver */
- if (info->gptp)
- ravb_ptp_stop(ndev);
+ if (info->ptp && info->ptp->dmac_stop)
+ info->ptp->dmac_stop(ndev);
/* Stop AVB-DMAC process */
return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
@@ -1774,7 +1774,7 @@ static int ravb_get_ts_info(struct net_device *ndev,
struct ravb_private *priv = netdev_priv(ndev);
const struct ravb_hw_info *hw_info = priv->info;
- if (hw_info->gptp || hw_info->ccc_gac) {
+ if (hw_info->ptp) {
info->so_timestamping =
SOF_TIMESTAMPING_TX_SOFTWARE |
SOF_TIMESTAMPING_TX_HARDWARE |
@@ -1835,21 +1835,11 @@ static int ravb_set_config_mode(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
const struct ravb_hw_info *info = priv->info;
- int error;
- if (info->gptp) {
- error = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
- if (error)
- return error;
- /* Set CSEL value */
- ravb_modify(ndev, CCC, CCC_CSEL, CCC_CSEL_HPB);
- } else if (info->ccc_gac) {
- error = ravb_set_opmode(ndev, CCC_OPC_CONFIG | CCC_GAC | CCC_CSEL_HPB);
- } else {
- error = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
- }
+ if (info->ptp && info->ptp->set_config_mode)
+ return info->ptp->set_config_mode(ndev);
- return error;
+ return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
}
static int ravb_compute_gti(struct net_device *ndev)
@@ -1860,7 +1850,7 @@ static int ravb_compute_gti(struct net_device *ndev)
unsigned long rate;
u64 inc;
- if (!(info->gptp || info->ccc_gac))
+ if (!info->ptp)
return 0;
if (info->gptp_ref_clk)
@@ -1967,8 +1957,8 @@ static int ravb_open(struct net_device *ndev)
ravb_emac_init(ndev);
/* Initialise PTP Clock driver */
- if (info->ccc_gac)
- ravb_ptp_init(ndev);
+ if (info->ptp && info->ptp->ndev_open)
+ info->ptp->ndev_open(ndev);
/* PHY control start */
error = ravb_phy_start(ndev);
@@ -2187,7 +2177,7 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
desc->dptr = cpu_to_le32(dma_addr);
/* TX timestamp required */
- if (info->gptp || info->ccc_gac) {
+ if (info->ptp) {
if (q == RAVB_NC) {
ts_skb = kmalloc_obj(*ts_skb, GFP_ATOMIC);
if (!ts_skb) {
@@ -2369,8 +2359,8 @@ static int ravb_close(struct net_device *ndev)
}
/* Stop PTP Clock driver */
- if (info->ccc_gac)
- ravb_ptp_stop(ndev);
+ if (info->ptp && info->ptp->ndev_close)
+ info->ptp->ndev_close(ndev);
/* Set the config mode to stop the AVB-DMAC's processes */
if (ravb_stop_dma(ndev) < 0)
@@ -2378,7 +2368,7 @@ static int ravb_close(struct net_device *ndev)
"device will be stopped after h/w processes are done.\n");
/* Clear the timestamp list */
- if (info->gptp || info->ccc_gac) {
+ if (info->ptp) {
list_for_each_entry_safe(ts_skb, ts_skb2, &priv->ts_skb_list, list) {
list_del(&ts_skb->list);
kfree_skb(ts_skb->skb);
@@ -2660,6 +2650,26 @@ static int ravb_mdio_release(struct ravb_private *priv)
return 0;
}
+static int ravb_gen2_ptp_set_config_mode(struct net_device *ndev)
+{
+ int ret;
+
+ ret = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
+ if (ret)
+ return ret;
+
+ /* gPTP Clock Select High-speed peripheral bus clock. */
+ ravb_modify(ndev, CCC, CCC_CSEL, CCC_CSEL_HPB);
+
+ return 0;
+}
+
+static const struct ravb_gptp_info ravb_gen2_ptp_info = {
+ .set_config_mode = ravb_gen2_ptp_set_config_mode,
+ .dmac_start = ravb_ptp_init,
+ .dmac_stop = ravb_ptp_stop,
+};
+
static const struct ravb_hw_info ravb_gen2_hw_info = {
.receive = ravb_rx_rcar,
.set_rate = ravb_set_rate_rcar,
@@ -2678,12 +2688,24 @@ static const struct ravb_hw_info ravb_gen2_hw_info = {
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
.rx_desc_size = sizeof(struct ravb_ex_rx_desc),
.dbat_entry_num = 22,
+ .ptp = &ravb_gen2_ptp_info,
.aligned_tx = 1,
- .gptp = 1,
.nc_queues = 1,
.magic_pkt = 1,
};
+static int ravb_gen3_ptp_set_config_mode(struct net_device *ndev)
+{
+ /* Enable gPTP Clock and Select High-speed peripheral bus clock. */
+ return ravb_set_opmode(ndev, CCC_OPC_CONFIG | CCC_GAC | CCC_CSEL_HPB);
+}
+
+static const struct ravb_gptp_info ravb_gen3_ptp_info = {
+ .set_config_mode = ravb_gen3_ptp_set_config_mode,
+ .ndev_open = ravb_ptp_init,
+ .ndev_close = ravb_ptp_stop,
+};
+
static const struct ravb_hw_info ravb_gen3_hw_info = {
.receive = ravb_rx_rcar,
.set_rate = ravb_set_rate_rcar,
@@ -2702,11 +2724,11 @@ static const struct ravb_hw_info ravb_gen3_hw_info = {
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
.rx_desc_size = sizeof(struct ravb_ex_rx_desc),
.dbat_entry_num = 22,
+ .ptp = &ravb_gen3_ptp_info,
.internal_delay = 1,
.tx_counters = 1,
.multi_irqs = 1,
.irq_en_dis = 1,
- .ccc_gac = 1,
.nc_queues = 1,
.magic_pkt = 1,
};
@@ -2733,7 +2755,7 @@ static const struct ravb_hw_info ravb_gen4_hw_info = {
.tx_counters = 1,
.multi_irqs = 1,
.irq_en_dis = 1,
- .ccc_gac = 1,
+ .ptp = &ravb_gen3_ptp_info,
.nc_queues = 1,
.magic_pkt = 1,
};
@@ -2758,7 +2780,7 @@ static const struct ravb_hw_info ravb_rzv2m_hw_info = {
.dbat_entry_num = 22,
.multi_irqs = 1,
.err_mgmt_irqs = 1,
- .gptp = 1,
+ .ptp = &ravb_gen2_ptp_info,
.gptp_ref_clk = 1,
.nc_queues = 1,
.magic_pkt = 1,
--
2.54.0
^ permalink raw reply related
* [net-next 6/9] net: ethernet: ravb: Add callback for gPTP probe
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
Different generations of the RAVB IP have different needs when it probes
the gPTP timer clock. Add a callback in the PTP information to allow
each generation to probe its own way.
With this the last gPTP specific flag (gptp_ref_clk) can be removed.
However the primary motivation for the change is to prepare for Gen4
support, which compared to other generations with gPTP support does not
have the clock as part of the IP itself.
Gen4 will not need to compute GTI value as it have no where to write it,
as the gPTP clock is external. For this reason move the computation of
it into the newly gPTP probe specific callbacks for the RAVB IP's that
support it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb.h | 3 +-
drivers/net/ethernet/renesas/ravb_main.c | 53 +++++++++++++++---------
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index 70bef3b31d38..f063f4ba5714 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -1041,6 +1041,7 @@ struct ravb_ptp {
* with the gPTP clock. This struct provides the callbacks to be called at
* critical points in the RAVB driver.
*
+ * @probe: Probe the gPTP clock
* @set_config_mode: Enter config mode
* @dmac_start: Called when the DMAC starts
* @dmac_stop: Called when the DMAC stops
@@ -1048,6 +1049,7 @@ struct ravb_ptp {
* @ndev_close: Called when the ndev is closed
*/
struct ravb_gptp_info {
+ int (*probe)(struct net_device *ndev);
int (*set_config_mode)(struct net_device *ndev);
void (*dmac_start)(struct net_device *ndev);
void (*dmac_stop)(struct net_device *ndev);
@@ -1084,7 +1086,6 @@ struct ravb_hw_info {
unsigned multi_irqs:1; /* AVB-DMAC and E-MAC has multiple irqs */
unsigned irq_en_dis:1; /* Has separate irq enable and disable regs */
unsigned err_mgmt_irqs:1; /* Line1 (Err) and Line2 (Mgmt) irqs are separate */
- unsigned gptp_ref_clk:1; /* gPTP has separate reference clock */
unsigned nc_queues:1; /* AVB-DMAC has RX and TX NC queues */
unsigned magic_pkt:1; /* E-MAC supports magic packet detection */
unsigned half_duplex:1; /* E-MAC supports half duplex mode */
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 577cd2245e60..85020c943e10 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1842,21 +1842,14 @@ static int ravb_set_config_mode(struct net_device *ndev)
return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
}
-static int ravb_compute_gti(struct net_device *ndev)
+static int ravb_compute_gti(struct net_device *ndev, struct clk *clk)
{
struct ravb_private *priv = netdev_priv(ndev);
- const struct ravb_hw_info *info = priv->info;
struct device *dev = ndev->dev.parent;
unsigned long rate;
u64 inc;
- if (!info->ptp)
- return 0;
-
- if (info->gptp_ref_clk)
- rate = clk_get_rate(priv->gptp_clk);
- else
- rate = clk_get_rate(priv->clk);
+ rate = clk_get_rate(clk);
if (!rate)
return -EINVAL;
@@ -2650,6 +2643,13 @@ static int ravb_mdio_release(struct ravb_private *priv)
return 0;
}
+static int ravb_gen2_ptp_probe(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ return ravb_compute_gti(ndev, priv->clk);
+}
+
static int ravb_gen2_ptp_set_config_mode(struct net_device *ndev)
{
int ret;
@@ -2665,6 +2665,7 @@ static int ravb_gen2_ptp_set_config_mode(struct net_device *ndev)
}
static const struct ravb_gptp_info ravb_gen2_ptp_info = {
+ .probe = ravb_gen2_ptp_probe,
.set_config_mode = ravb_gen2_ptp_set_config_mode,
.dmac_start = ravb_ptp_init,
.dmac_stop = ravb_ptp_stop,
@@ -2701,6 +2702,7 @@ static int ravb_gen3_ptp_set_config_mode(struct net_device *ndev)
}
static const struct ravb_gptp_info ravb_gen3_ptp_info = {
+ .probe = ravb_gen2_ptp_probe,
.set_config_mode = ravb_gen3_ptp_set_config_mode,
.ndev_open = ravb_ptp_init,
.ndev_close = ravb_ptp_stop,
@@ -2760,6 +2762,24 @@ static const struct ravb_hw_info ravb_gen4_hw_info = {
.magic_pkt = 1,
};
+static int ravb_rzv2m_ptp_probe(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ priv->gptp_clk = devm_clk_get(&priv->pdev->dev, "gptp");
+ if (IS_ERR(priv->gptp_clk))
+ return PTR_ERR(priv->gptp_clk);
+
+ return ravb_compute_gti(ndev, priv->gptp_clk);
+}
+
+static const struct ravb_gptp_info ravb_rzv2m_ptp_info = {
+ .probe = ravb_rzv2m_ptp_probe,
+ .set_config_mode = ravb_gen2_ptp_set_config_mode,
+ .dmac_start = ravb_ptp_init,
+ .dmac_stop = ravb_ptp_stop,
+};
+
static const struct ravb_hw_info ravb_rzv2m_hw_info = {
.receive = ravb_rx_rcar,
.set_rate = ravb_set_rate_rcar,
@@ -2780,8 +2800,7 @@ static const struct ravb_hw_info ravb_rzv2m_hw_info = {
.dbat_entry_num = 22,
.multi_irqs = 1,
.err_mgmt_irqs = 1,
- .ptp = &ravb_gen2_ptp_info,
- .gptp_ref_clk = 1,
+ .ptp = &ravb_rzv2m_ptp_info,
.nc_queues = 1,
.magic_pkt = 1,
};
@@ -2971,12 +2990,10 @@ static int ravb_probe(struct platform_device *pdev)
goto out_reset_assert;
}
- if (info->gptp_ref_clk) {
- priv->gptp_clk = devm_clk_get(&pdev->dev, "gptp");
- if (IS_ERR(priv->gptp_clk)) {
- error = PTR_ERR(priv->gptp_clk);
+ if (info->ptp && info->ptp->probe) {
+ error = info->ptp->probe(ndev);
+ if (error)
goto out_reset_assert;
- }
}
priv->refclk = devm_clk_get_optional(&pdev->dev, "refclk");
@@ -3029,10 +3046,6 @@ static int ravb_probe(struct platform_device *pdev)
ndev->netdev_ops = &ravb_netdev_ops;
ndev->ethtool_ops = &ravb_ethtool_ops;
- error = ravb_compute_gti(ndev);
- if (error)
- goto out_rpm_put;
-
ravb_parse_delay_mode(np, ndev);
/* Allocate descriptor base address table */
--
2.54.0
^ permalink raw reply related
* [net-next 7/9] net: ethernet: ravb: Add callback for gPTP clock index
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
Prepare for adding Gen4 support which have an optional external gPTP
clock. Add a callback to get the clock index and use it to determine if
the device shall report gPTP support.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb.h | 2 ++
drivers/net/ethernet/renesas/ravb_main.c | 19 +++++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index f063f4ba5714..caad95a9c3c5 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -1042,6 +1042,7 @@ struct ravb_ptp {
* critical points in the RAVB driver.
*
* @probe: Probe the gPTP clock
+ * @clock_index: Get the PTP clock index, if any
* @set_config_mode: Enter config mode
* @dmac_start: Called when the DMAC starts
* @dmac_stop: Called when the DMAC stops
@@ -1050,6 +1051,7 @@ struct ravb_ptp {
*/
struct ravb_gptp_info {
int (*probe)(struct net_device *ndev);
+ int (*clock_index)(struct net_device *ndev);
int (*set_config_mode)(struct net_device *ndev);
void (*dmac_start)(struct net_device *ndev);
void (*dmac_stop)(struct net_device *ndev);
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 85020c943e10..4b0d06fb5f4c 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1773,8 +1773,13 @@ static int ravb_get_ts_info(struct net_device *ndev,
{
struct ravb_private *priv = netdev_priv(ndev);
const struct ravb_hw_info *hw_info = priv->info;
+ int index = -1;
- if (hw_info->ptp) {
+ if (hw_info->ptp && hw_info->ptp->clock_index)
+ index = hw_info->ptp->clock_index(ndev);
+
+ /* Only advertise ptp clock if present. */
+ if (index >= 0) {
info->so_timestamping =
SOF_TIMESTAMPING_TX_SOFTWARE |
SOF_TIMESTAMPING_TX_HARDWARE |
@@ -1785,7 +1790,7 @@ static int ravb_get_ts_info(struct net_device *ndev,
(1 << HWTSTAMP_FILTER_NONE) |
(1 << HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |
(1 << HWTSTAMP_FILTER_ALL);
- info->phc_index = ptp_clock_index(priv->ptp.clock);
+ info->phc_index = index;
}
return 0;
@@ -2650,6 +2655,13 @@ static int ravb_gen2_ptp_probe(struct net_device *ndev)
return ravb_compute_gti(ndev, priv->clk);
}
+static int ravb_gen2_ptp_clock_index(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ return ptp_clock_index(priv->ptp.clock);
+}
+
static int ravb_gen2_ptp_set_config_mode(struct net_device *ndev)
{
int ret;
@@ -2666,6 +2678,7 @@ static int ravb_gen2_ptp_set_config_mode(struct net_device *ndev)
static const struct ravb_gptp_info ravb_gen2_ptp_info = {
.probe = ravb_gen2_ptp_probe,
+ .clock_index = ravb_gen2_ptp_clock_index,
.set_config_mode = ravb_gen2_ptp_set_config_mode,
.dmac_start = ravb_ptp_init,
.dmac_stop = ravb_ptp_stop,
@@ -2703,6 +2716,7 @@ static int ravb_gen3_ptp_set_config_mode(struct net_device *ndev)
static const struct ravb_gptp_info ravb_gen3_ptp_info = {
.probe = ravb_gen2_ptp_probe,
+ .clock_index = ravb_gen2_ptp_clock_index,
.set_config_mode = ravb_gen3_ptp_set_config_mode,
.ndev_open = ravb_ptp_init,
.ndev_close = ravb_ptp_stop,
@@ -2775,6 +2789,7 @@ static int ravb_rzv2m_ptp_probe(struct net_device *ndev)
static const struct ravb_gptp_info ravb_rzv2m_ptp_info = {
.probe = ravb_rzv2m_ptp_probe,
+ .clock_index = ravb_gen2_ptp_clock_index,
.set_config_mode = ravb_gen2_ptp_set_config_mode,
.dmac_start = ravb_ptp_init,
.dmac_stop = ravb_ptp_stop,
--
2.54.0
^ permalink raw reply related
* [net-next 8/9] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
The RAVB module on Gen4 have no gPTP clock as part of the RAVB module
itself, instead it relies on an external system wide gPTP clock. The
gPTP clock is shared with RTSN on V4H and RSWITCH on S4.
Add an optional phandle so that the RAVB driver can find and use the
gPTP clock. Ideally this should have been an mandatory property but for
backward compatible it is optional. The RAVB module is capable of
functioning without it, but can in such cases not provided PTP
functionality.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
.../bindings/net/renesas,etheravb.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index 1e00ef5b3acd..7bc910ab3ae0 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -122,6 +122,13 @@ properties:
Specify when the AVB_LINK signal is active-low instead of normal
active-high.
+ renesas,gptp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to an external gPTP clock for Gen4 platforms. The property is
+ optional for backwards compatibility, but without it gPTP timestamps are
+ disabled as Gen4 have no gPTP as part of the RAVB module itself.
+
rx-internal-delay-ps:
enum: [0, 1800]
@@ -305,6 +312,15 @@ allOf:
items:
- const: fck
- const: refclk
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: renesas,etheravb-rcar-gen4
+ then:
+ properties:
+ renesas,gptp: false
additionalProperties: false
--
2.54.0
^ permalink raw reply related
* [net-next 9/9] net: ethernet: ravb: Add gPTP support for Gen4
From: Niklas Söderlund @ 2026-06-10 10:24 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
Cc: Niklas Söderlund
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
While driver advertise gPTP support on Gen4 platforms it is in fact
completely broken. On R-Car Gen4 devices the RAVB module have no
internal gPTP clock as generations before it. Instead it utilizes a
system wide gPTP clock.
This change utilizes the refactoring of the RAVB gPTP code to add
support for a system wide clock and stops the Gen4 devices trying to use
the non-existing internal gPTP clock.
To remain backward compatible the device tree property needed
(renesas,gptp) to get hold of the system gPTP clock is optional. If the
property is not present, or not enabled, the RAVB driver will no longer
advertise gPTP support to user-space.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb.h | 3 ++
drivers/net/ethernet/renesas/ravb_main.c | 55 +++++++++++++++++++++++-
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index caad95a9c3c5..acdfb56bb135 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -249,6 +249,8 @@ enum APSR_BIT {
APSR_RDM = 0x00002000,
APSR_TDM = 0x00004000,
APSR_MIISELECT = 0x01000000, /* R-Car V4M only */
+ APSR_GPTPTIMER_SOURCE = BIT(25), /* Gen4 */
+ APSR_GPTPCLOCK = BIT(29), /* Gen4 */
};
/* RCR */
@@ -1132,6 +1134,7 @@ struct ravb_private {
struct list_head ts_skb_list;
u32 ts_skb_tag;
struct ravb_ptp ptp;
+ struct device_node *of_gptp; /* Reference to external gPTP clock, if any. */
spinlock_t lock; /* Register access lock */
u32 cur_rx[NUM_RX_QUEUE]; /* Consumer ring indices */
u32 dirty_rx[NUM_RX_QUEUE]; /* Producer ring indices */
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 4b0d06fb5f4c..985b2cb93617 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2749,6 +2749,58 @@ static const struct ravb_hw_info ravb_gen3_hw_info = {
.magic_pkt = 1,
};
+static int ravb_gen4_ptp_probe(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ priv->of_gptp = of_parse_phandle(priv->pdev->dev.of_node, "renesas,gptp", 0);
+ if (!priv->of_gptp)
+ return 0;
+
+ if (!of_device_is_available(priv->of_gptp)) {
+ of_node_put(priv->of_gptp);
+ priv->of_gptp = NULL;
+ return 0;
+ }
+
+ return 0;
+}
+
+static int ravb_gen4_ptp_clock_index(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ /* If no clock, mimic ptp_clock_index_by_of_node() fail and return -1 */
+ if (!priv->of_gptp)
+ return -1;
+
+ return ptp_clock_index_by_of_node(priv->of_gptp);
+}
+
+static int ravb_gen4_ptp_set_config_mode(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ int ret;
+
+ /* Enable gPTP Clock and Select High-speed peripheral bus clock. */
+ ret = ravb_set_opmode(ndev, CCC_OPC_CONFIG | CCC_GAC | CCC_CSEL_HPB);
+ if (ret)
+ return ret;
+
+ /* Set PTP source to GPTP module, only option on Gen4. */
+ if (priv->of_gptp)
+ ravb_modify(ndev, APSR, APSR_GPTPTIMER_SOURCE | APSR_GPTPCLOCK,
+ APSR_GPTPTIMER_SOURCE | APSR_GPTPCLOCK);
+
+ return 0;
+}
+
+static const struct ravb_gptp_info ravb_gen4_ptp_info = {
+ .probe = ravb_gen4_ptp_probe,
+ .clock_index = ravb_gen4_ptp_clock_index,
+ .set_config_mode = ravb_gen4_ptp_set_config_mode,
+};
+
static const struct ravb_hw_info ravb_gen4_hw_info = {
.receive = ravb_rx_rcar,
.set_rate = ravb_set_rate_rcar,
@@ -2771,7 +2823,7 @@ static const struct ravb_hw_info ravb_gen4_hw_info = {
.tx_counters = 1,
.multi_irqs = 1,
.irq_en_dis = 1,
- .ptp = &ravb_gen3_ptp_info,
+ .ptp = &ravb_gen4_ptp_info,
.nc_queues = 1,
.magic_pkt = 1,
};
@@ -3183,6 +3235,7 @@ static void ravb_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(dev);
clk_unprepare(priv->refclk);
+ of_node_put(priv->of_gptp);
reset_control_assert(priv->rstc);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
From: Manivannan Sadhasivam @ 2026-06-10 10:27 UTC (permalink / raw)
To: Sherry Sun
Cc: Krzysztof Kozlowski, sashiko-reviews@lists.linux.dev,
manivannan.sadhasivam@oss.qualcomm.com, linux-pci@vger.kernel.org,
robh@kernel.org, Frank.Li@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev
In-Reply-To: <VI0PR04MB12114DBDD65F25FB615EA8967921A2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > > > > Thank you for your contribution! Sashiko AI review found 1
> > > > > potential
> > > > issue(s) to consider:
> > > > > - [Medium] The `vpcie3v3aux-supply` property describes a
> > > > > non-existent
> > > > hardware feature on the M.2 Key E connector to work around a
> > > > software policy.
> > > >
> > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > >
> > >
> > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > > Grounds.
> > >
> > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > > source, 3.3 V, is expected to be available during the system’s
> > > stand-by/suspend state to support wake event processing on the
> > > communications card.
> > >
> > > But the current vpcie3v3-supply may be gated off during system suspend.
> > > So I tried to add vpcie3v3aux-supply to let this 3.3 V power source
> > > always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
> > > and vpcie3v3-supply actually refer to the same 3.3 V power source.
> > >
> > > @Mani, do you think this is reasonable? Or do you have any other
> > > better solutions? Thanks!
> > >
> >
> > There is no Vaux defined in the M.2 spec. So you cannot define that supply in
> > the binding. You can define the custom Vaux supply as a fixed regulator in DT
> > and mark it always on so that it is keeps supplying 3.3v to the card.
> >
>
> Hi Mani, thanks for the suggestion, but adding an always on regulator may
> cause board power waste, current solution ensures the 3.3v regulator is
> only enabled when M.2 connector needs to work .
>
What do you mean by 'need to work'? For getting the M.2 card to work, you
already have 3.3v supply. If you want the board to be always ON, then you need
to supply 3.3Vaux, which should be always ON too.
But who is turning off vpcie3v3-supply? M.2 connector driver or the platform?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [net-next 0/9] ravb: Add gPTP support for Gen4
From: Krzysztof Kozlowski @ 2026-06-10 10:27 UTC (permalink / raw)
To: Niklas Söderlund, Paul Barker, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Richard Cochran,
Geert Uytterhoeven, Magnus Damm, Sergei Shtylyov, netdev,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se>
On 10/06/2026 12:24, Niklas Söderlund wrote:
> Hello,
>
> This series is the second part cleaning up how PTP timer support is
> implemented on R-Car Gen4. Currently there is partial support for it in
> some of the Ethernet devices that can use it, but not all.
>
Second series doing the same...
Please use standard email subjects, so with the PATCH keyword in the
title. `git format-patch -vX` helps here to create proper versioned
patches. Another useful tool is b4. Skipping the PATCH keyword makes
filtering of emails more difficult thus making the review process less
convenient.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sdm670-google: add lpi reserved gpios
From: Konrad Dybcio @ 2026-06-10 10:33 UTC (permalink / raw)
To: Richard Acayan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, linux-arm-msm,
devicetree
In-Reply-To: <20260602021722.30760-1-mailingradian@gmail.com>
On 6/2/26 4:17 AM, Richard Acayan wrote:
> Add reserved GPIOs for the Pixel 3a, which blocks access to the sensor
> GPIOs. The hunk in the original patch was dropped in the commit because
> it depended on an unapplied patch, which is now commit fe9f4a46895d
> ("arm64: dts: qcom: sdm670-google: add common device tree include").
>
> Fixes: c4b423835ee7 ("arm64: dts: qcom: sdm670: add lpi pinctrl")
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
that's a lot of GPIOs..
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: (subset) [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Thierry Reding @ 2026-06-10 10:34 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel,
Akhil R
In-Reply-To: <20260331102303.33181-1-akhilrajeev@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
On Tue, 31 Mar 2026 15:52:53 +0530, Akhil R wrote:
> This series adds support for GPCDMA in Tegra264 with additional
> support for separate stream ID for each channel. Tegra264 GPCDMA
> controller has changes in the register offsets and uses 41-bit
> addressing for memory. Add changes in the tegra186-gpc-dma driver
> to support these.
>
> v5->v6:
> - Replace dev_err() with dev_err_probe() in the probe function for fixed
> return values also.
> v4->v5:
> - Use dev_err_probe() when returning error from the probe function.
> - Remove tegra194 and tegra234 compatible from the reset 'if' condition
> in the bindings as suggested in v2 (which I missed).
> v3->v4:
> - Split device tree changes to two patches.
> - Reordered patches to have fixes first.
> - Added fixes tag to dt-bindings and device tree changes.
> v2->v3:
> - Add description for iommu-map property and update commit descriptions.
> - Use enum for compatible string instead of const.
> - Remove unused registers from struct tegra_dma_channel_regs.
> - Use devm_of_dma_controller_register() to register the DMA controller.
> - Remove return value check for mask setting in the driver as the bitmask
> value is always greater than 32.
> v1->v2:
> - Fix dt_bindings_check warnings
> - Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
> - Use dma_addr_t for sg_req src/dst fields and drop separate high_add
> variable and check for the addr_bits only when programming the
> registers.
> - Update address width to 39 bits for Tegra234 and before since the SMMU
> supports only up to 39 bits till Tegra234.
> - Add a patch to do managed DMA controller registration.
> - Describe the second iteration in the probe.
> - Update commit descriptions.
>
> [...]
Applied, thanks!
[02/10] arm64: tegra: Remove fallback compatible for GPCDMA
commit: ee7863e43228a3143398dc5bbb943c9a735a8fca
[10/10] arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
commit: d2bca791d5a6c00ed24e92fa71f829553b1b1674
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2026-06-10 10:36 UTC (permalink / raw)
To: Arnd Bergmann, Frank Li, sashiko-reviews@lists.linux.dev
Cc: Conor Dooley, Rob Herring, Frank Li, devicetree@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <4f7cc399-785f-4967-adec-714ccc69ada8@app.fastmail.com>
Hi Arnd, Frank,
Am 10.06.26 um 09:43 schrieb Arnd Bergmann:
> On Wed, Jun 10, 2026, at 00:13, Frank Li wrote:
>> On 6/9/2026 4:31 PM, Arnd Bergmann wrote:
>>
>> If EP itself is PCIe bridge, it may be problem. It'd better to
>> keep 32bit range unchange.
> Ok. It is not uncommon to have PCIe bridges either in physical
> form, or inside of devices that have multiple PCIe functions,
> so this does seem like a real problem to me even when more commonly
> you'd only have a single PCIe function with a single memory BAR
> on each host bridge.
>
>> Do you need rework pull request? Or you can drop this patch.
> I can't easily drop the commit without losing your signed tag
> on the pull request. Please update the pull request to either
> drop this on your end or add a fixup patch on top that reverts
> to a 1GB non-prefetchable window for each of the controllers.
>
> On a related note, please make sure that you don't send
> a large series like this late in the development cycle
> so we have enough time to resolve any issues that may come
> up. You can also send a follow-up pull request with last
> minute fixups and changes that were still waiting for
> review. The bulk of the branch contents look like they
> have been stable for a while, so the best thing would have
> been to send those in a first PR.
>
> If everything goes well otherwise, this PR should still make
> it in time, but it would be nice to avoid such minute
> excitement in the future.
Thank you for discussing this issue in detail!
If you need me to send a fixup, kindly let me know.
^ permalink raw reply
* Re: [net-next 0/9] ravb: Add gPTP support for Gen4
From: Niklas Söderlund @ 2026-06-10 10:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <d525a1f4-9e87-40cc-9878-2044e5d6dea6@kernel.org>
Hi Krzysztof,
On 2026-06-10 12:27:55 +0200, Krzysztof Kozlowski wrote:
> On 10/06/2026 12:24, Niklas Söderlund wrote:
> > Hello,
> >
> > This series is the second part cleaning up how PTP timer support is
> > implemented on R-Car Gen4. Currently there is partial support for it in
> > some of the Ethernet devices that can use it, but not all.
> >
>
> Second series doing the same...
>
> Please use standard email subjects, so with the PATCH keyword in the
> title. `git format-patch -vX` helps here to create proper versioned
> patches. Another useful tool is b4. Skipping the PATCH keyword makes
> filtering of emails more difficult thus making the review process less
> convenient.
I'm sorry about that, but as this (and the previous) series targets
netdev where as I understand it the convection is to use net-next, or
net, to indicate which tree it targets. When not posting to netdev I
indeed use -vX.
I'm not sure how to resolve these two. Would [PATCH,net-next,vX 0/9]
make life easier for you?
>
> Best regards,
> Krzysztof
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v11 1/6] soc: qcom: ice: Add OPP-based clock scaling support for ICE
From: Manivannan Sadhasivam @ 2026-06-10 10:40 UTC (permalink / raw)
To: Abhinaba Rakshit
Cc: Bjorn Andersson, Konrad Dybcio, James E.J. Bottomley,
Martin K. Petersen, Adrian Hunter, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neeraj Soni, Harshal Dev,
Kuldeep Singh, linux-arm-msm, linux-kernel, linux-scsi, linux-mmc,
devicetree
In-Reply-To: <20260609-enable-ice-clock-scaling-v11-1-1cebc8b3275b@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 03:17:23AM +0530, Abhinaba Rakshit wrote:
> Register optional operation-points-v2 table for ICE device
> during device probe. Attach the OPP-table with only the ICE
> core clock. Since, dtbinding is on a transition phase to include
> iface clock and clock-names, attaching the opp-table to core clock
> remains optional such that it does not cause probe failures.
>
> Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> core clock based on the target frequency provided and if a valid
> OPP-table is registered. Use round_ceil passed to decide on the
> rounding of the clock freq against OPP-table. Clock scaling is
> disabled when a valid OPP-table is not registered.
>
> This ensures when an ICE-device specific OPP table is available,
> use the PM OPP framework to manage frequency scaling and maintain
> proper power-domain constraints.
>
> Also, ensure to drop the votes in suspend to prevent power/thermal
> retention. Subsequently restore the frequency in resume from
> core_clk_freq which stores the last ICE core clock operating frequency.
>
> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ice.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/soc/qcom/ice.h | 2 ++
> 2 files changed, 95 insertions(+)
>
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index 5f20108aa03ebe9a47a10fba9afde420add0f34a..519d08c4727a6cb2dc5991216a2c042ed6218857 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -17,6 +17,7 @@
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/xarray.h>
> +#include <linux/pm_opp.h>
>
> #include <linux/firmware/qcom/qcom_scm.h>
>
> @@ -113,6 +114,8 @@ struct qcom_ice {
> bool use_hwkm;
> bool hwkm_init_complete;
> u8 hwkm_version;
> + unsigned long core_clk_freq;
> + bool has_opp;
> };
>
> static DEFINE_XARRAY(ice_handles);
> @@ -315,6 +318,10 @@ int qcom_ice_resume(struct qcom_ice *ice)
> struct device *dev = ice->dev;
> int err;
>
> + /* Restore the ICE core clk freq */
Redundant comment.
> + if (ice->has_opp && ice->core_clk_freq)
Can core clk be 0 if OPP is used?
> + dev_pm_opp_set_rate(ice->dev, ice->core_clk_freq);
> +
> err = clk_prepare_enable(ice->core_clk);
> if (err) {
> dev_err(dev, "Failed to enable core clock: %d\n", err);
> @@ -335,6 +342,11 @@ int qcom_ice_suspend(struct qcom_ice *ice)
> {
> clk_disable_unprepare(ice->iface_clk);
> clk_disable_unprepare(ice->core_clk);
> +
> + /* Drop the clock votes while suspend */
Redundant comment.
> + if (ice->has_opp)
> + dev_pm_opp_set_rate(ice->dev, 0);
> +
> ice->hwkm_init_complete = false;
>
> return 0;
> @@ -560,6 +572,51 @@ int qcom_ice_import_key(struct qcom_ice *ice,
> }
> EXPORT_SYMBOL_GPL(qcom_ice_import_key);
>
> +/**
> + * qcom_ice_scale_clk() - Scale ICE clock for DVFS-aware operations
> + * @ice: ICE driver data
> + * @target_freq: requested frequency in Hz
> + * @round_ceil: when true, selects nearest freq >= @target_freq;
> + * otherwise, selects nearest freq <= @target_freq
> + *
> + * Selects an OPP frequency based on @target_freq and the rounding direction
> + * specified by @round_ceil, then programs it using dev_pm_opp_set_rate(),
> + * including any voltage or power-domain transitions handled by the OPP
> + * framework. Updates ice->core_clk_freq on success.
> + *
> + * Return: 0 on success; -EOPNOTSUPP if no OPP table; or error from
s/error/errno
> + * dev_pm_opp_set_rate()/OPP lookup.
> + */
> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> + bool round_ceil)
> +{
> + unsigned long ice_freq = target_freq;
> + struct dev_pm_opp *opp;
> + int ret;
> +
> + if (!ice->has_opp)
> + return -EOPNOTSUPP;
> +
> + if (round_ceil)
> + opp = dev_pm_opp_find_freq_ceil(ice->dev, &ice_freq);
> + else
> + opp = dev_pm_opp_find_freq_floor(ice->dev, &ice_freq);
> +
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> + dev_pm_opp_put(opp);
> +
> + ret = dev_pm_opp_set_rate(ice->dev, ice_freq);
> + if (ret) {
> + dev_err(ice->dev, "Unable to scale ICE clock rate\n");
> + return ret;
> + }
> + ice->core_clk_freq = ice_freq;
> +
> + return ret;
return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_scale_clk);
> +
> static struct qcom_ice *qcom_ice_create(struct device *dev,
> void __iomem *base)
> {
> @@ -738,6 +795,7 @@ static int qcom_ice_probe(struct platform_device *pdev)
> unsigned long phandle = pdev->dev.of_node->phandle;
> struct qcom_ice *engine;
> void __iomem *base;
> + int err;
>
> guard(mutex)(&ice_mutex);
>
> @@ -756,6 +814,41 @@ static int qcom_ice_probe(struct platform_device *pdev)
> return PTR_ERR(engine);
> }
>
> + err = devm_pm_opp_set_clkname(&pdev->dev, "core");
> + if (err && err != -ENOENT) {
> + dev_err(&pdev->dev, "Unable to set core clkname to OPP-table\n");
> + /* Store the error pointer for devm_of_qcom_ice_get() */
> + xa_store(&ice_handles, phandle, ERR_PTR(err), GFP_KERNEL);
> + return err;
> + }
> +
> + /* OPP table is optional */
> + err = devm_pm_opp_of_add_table(&pdev->dev);
> + if (err && err != -ENODEV) {
> + dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> + /* Store the error pointer for devm_of_qcom_ice_get() */
> + xa_store(&ice_handles, phandle, ERR_PTR(err), GFP_KERNEL);
> + return err;
> + }
> +
> + /*
> + * The OPP table is optional. devm_pm_opp_of_add_table() returns
> + * -ENODEV when no OPP table is present in DT, which is not treated
> + * as an error. Therefore, track successful OPP registration only
> + * when err is not -ENODEV.
> + */
> + if (err == -ENODEV)
> + dev_info(&pdev->dev, "ICE OPP table is not registered, please update your DT\n");
dev_dbg() please. No need to spam old DTs.
> + else
> + engine->has_opp = true;
> +
> + /*
> + * Store the core clock rate for suspend resume cycles,
> + * against OPP aware DVFS operations. core_clk_freq will
> + * have a valid value only for non-legacy bindings.
use full 80 column width for comments.
> + */
> + engine->core_clk_freq = clk_get_rate(engine->core_clk);
Why can't you conditionally cache the freq by moving it to the above else
condition?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 12/12] iio: dac: ad5686: add gain control support
From: Andy Shevchenko @ 2026-06-10 10:44 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich,
Jonathan Cameron, David Lechner, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <kzfu37rchq7zjus7jpsy745zfvw3zvpz57l7yqvddolwhb4yth@c7qx3pdq7tjy>
On Wed, Jun 10, 2026 at 09:25:25AM +0100, Rodrigo Alencar wrote:
> On 09/06/26 21:15, Andy Shevchenko wrote:
> > On Tue, Jun 09, 2026 at 11:13:07AM +0100, Rodrigo Alencar via B4 Relay wrote:
...
> > > + unsigned short vref_mv;
> >
> > _mV
>
> Renaming would need to be a separate refactoring patch. I'll just keep
> as is and just have the field moved down.
I haven't noticed that it is in the original code. Yeah, in such a case it's
fine as is.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [net-next 0/9] ravb: Add gPTP support for Gen4
From: Krzysztof Kozlowski @ 2026-06-10 10:47 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260610103812.GE2465390@ragnatech.se>
On 10/06/2026 12:38, Niklas Söderlund wrote:
> Hi Krzysztof,
>
> On 2026-06-10 12:27:55 +0200, Krzysztof Kozlowski wrote:
>> On 10/06/2026 12:24, Niklas Söderlund wrote:
>>> Hello,
>>>
>>> This series is the second part cleaning up how PTP timer support is
>>> implemented on R-Car Gen4. Currently there is partial support for it in
>>> some of the Ethernet devices that can use it, but not all.
>>>
>>
>> Second series doing the same...
>>
>> Please use standard email subjects, so with the PATCH keyword in the
>> title. `git format-patch -vX` helps here to create proper versioned
>> patches. Another useful tool is b4. Skipping the PATCH keyword makes
>> filtering of emails more difficult thus making the review process less
>> convenient.
>
> I'm sorry about that, but as this (and the previous) series targets
> netdev where as I understand it the convection is to use net-next, or
> net, to indicate which tree it targets. When not posting to netdev I
> indeed use -vX.
>
> I'm not sure how to resolve these two. Would [PATCH,net-next,vX 0/9]
> make life easier for you?
Look at mailing list - it will guide you. b4 also solves that for you,
so just don't do something completely different.
Best regards,
Krzysztof
^ 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