[PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Kurt Kanzenbach]

TSO and TBS cannot coexist. Use the first queue with TSO and the rest for
TBS. Tx queues with TBS can support etf qdisc hw offload. This is done
similar to dwmac-imx and dwmac-intel.

Tested on stm32mp257f-dk with AF_XDP and Tx Launch Time on queue 1.

Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index e1b260ed4790..8e15094eeab9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -557,6 +557,12 @@ static int stm32_dwmac_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	/* Default TX Q0 to use TSO and rest TXQ for TBS */
+	if (dwmac->ops->is_mp2) {
+		for (int i = 1; i < plat_dat->tx_queues_to_use; i++)
+			plat_dat->tx_queues_cfg[i].tbs_en = 1;
+	}
+
 	plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
 	plat_dat->bsp_priv = dwmac;
 	plat_dat->suspend = stm32_dwmac_suspend;

---
base-commit: ac155a26750a595703e7dadff84735456d75a479
change-id: 20260811-stm32mp2_txtime-6bf9e01c968e

Best regards,
--  
Kurt Kanzenbach <kurt@linutronix.de>

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Jakub Kicinski]

On Wed, 12 Aug 2026 08:28:57 +0200 Kurt Kanzenbach wrote:
> TSO and TBS cannot coexist. Use the first queue with TSO and the rest for
> TBS. Tx queues with TBS can support etf qdisc hw offload. This is done
> similar to dwmac-imx and dwmac-intel.

Can you explain your use case? And how many queues the device has 
in total?

You say "TSO and TBS cannot coexist" but can any queue on your
platform be configured to support either feature? If yes why are
we configuring this statically instead of making appropriate
configuration based on qdisc or some other uAPI knob?

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Mon Aug 17 2026, Jakub Kicinski wrote:
> On Wed, 12 Aug 2026 08:28:57 +0200 Kurt Kanzenbach wrote:
>> TSO and TBS cannot coexist. Use the first queue with TSO and the rest for
>> TBS. Tx queues with TBS can support etf qdisc hw offload. This is done
>> similar to dwmac-imx and dwmac-intel.
>
> Can you explain your use case?

I want to use ETF Qdisc with hardware offload, which is currently not
possible on the stm32mp2.

> And how many queues the device has in total?

The stm32mp2 has four Tx and two Rx queues.

>
> You say "TSO and TBS cannot coexist" but can any queue on your
> platform be configured to support either feature?

I think so. The data sheet says: "Do not enable time-based scheduling for
channels on which the TSO feature is enabled.". But, I didn't find any
limitations on what queue/channel can enable TBS.

> If yes why are we configuring this statically instead of making
> appropriate configuration based on qdisc or some other uAPI knob?

It seems like a static configuration in the driver today. I basically
followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.

Tx Launch Time requires a different DMA descriptor layout. Currently
tc_setup_etf() just returns -EINVAL if the DMA configuration is not
setup appropriately. I guess a dynamic configuration requires to change
the DMA config and perform a full release/open cycle.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Jakub Kicinski]

On Tue, 18 Aug 2026 08:57:08 +0200 Kurt Kanzenbach wrote:
> On Mon Aug 17 2026, Jakub Kicinski wrote:
> > On Wed, 12 Aug 2026 08:28:57 +0200 Kurt Kanzenbach wrote:  
> >> TSO and TBS cannot coexist. Use the first queue with TSO and the rest for
> >> TBS. Tx queues with TBS can support etf qdisc hw offload. This is done
> >> similar to dwmac-imx and dwmac-intel.  
> >
> > Can you explain your use case?  
> 
> I want to use ETF Qdisc with hardware offload, which is currently not
> possible on the stm32mp2.

Do you need multiple queues for ETF/normal traffic?
Or one ETF and one "normal"?

How do you sort the traffic between the queues?

> > And how many queues the device has in total?  
> 
> The stm32mp2 has four Tx and two Rx queues.
> 
> > You say "TSO and TBS cannot coexist" but can any queue on your
> > platform be configured to support either feature?  
> 
> I think so. The data sheet says: "Do not enable time-based scheduling for
> channels on which the TSO feature is enabled.". But, I didn't find any
> limitations on what queue/channel can enable TBS.

👍️

> > If yes why are we configuring this statically instead of making
> > appropriate configuration based on qdisc or some other uAPI knob?  
> 
> It seems like a static configuration in the driver today. I basically
> followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
> and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.
> 
> Tx Launch Time requires a different DMA descriptor layout. Currently
> tc_setup_etf() just returns -EINVAL if the DMA configuration is not
> setup appropriately. I guess a dynamic configuration requires to change
> the DMA config and perform a full release/open cycle.

release/open is not ideal but still better than hardcoding?

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

On Tue Aug 18 2026, Jakub Kicinski wrote:
> On Tue, 18 Aug 2026 08:57:08 +0200 Kurt Kanzenbach wrote:
>> On Mon Aug 17 2026, Jakub Kicinski wrote:
>> > On Wed, 12 Aug 2026 08:28:57 +0200 Kurt Kanzenbach wrote:  
>> >> TSO and TBS cannot coexist. Use the first queue with TSO and the rest for
>> >> TBS. Tx queues with TBS can support etf qdisc hw offload. This is done
>> >> similar to dwmac-imx and dwmac-intel.  
>> >
>> > Can you explain your use case?  
>> 
>> I want to use ETF Qdisc with hardware offload, which is currently not
>> possible on the stm32mp2.
>
> Do you need multiple queues for ETF/normal traffic?
> Or one ETF and one "normal"?
>
> How do you sort the traffic between the queues?

So the stm32mp2 has two CPU cores. I've isolated CPU1 for Profinet. That
one uses Tx/Rx queue 1 with ETF to reduce the Tx jitter. Everything else
is routed to Tx/Rx queue 0.

Config looks like this:

#
# Tx Assignment with SP.
#
# Tx Q 0 - Everything else
# Tx Q 1 - RTC
#
tc qdisc replace dev ${INTERFACE} handle 100 parent root mqprio num_tc 2 \
  map 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 \
  queues 1@0 1@1 \
  hw 1

#
# Enable Tx launch time support for TC 1.
#
tc qdisc replace dev ${INTERFACE} parent 100:2 etf \
  clockid CLOCK_TAI \
  delta 500000 \
  offload

On Rx incoming frames are steered via PCP field (vlan tagged).

>> > If yes why are we configuring this statically instead of making
>> > appropriate configuration based on qdisc or some other uAPI knob?  
>> 
>> It seems like a static configuration in the driver today. I basically
>> followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
>> and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.
>> 
>> Tx Launch Time requires a different DMA descriptor layout. Currently
>> tc_setup_etf() just returns -EINVAL if the DMA configuration is not
>> setup appropriately. I guess a dynamic configuration requires to change
>> the DMA config and perform a full release/open cycle.
>
> release/open is not ideal but still better than hardcoding?

For sure it's better than hardcoding :). But, again the driver does it
statically. Maybe there's a good reason for it. Maybe not. I'm not that
familiar with the stmmac driver. I'll prototype something to see whether
we can enable TBS at run time using the ETF Qdisc callback. It may take
some time though.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Jakub Kicinski]

On Wed, 19 Aug 2026 09:35:40 +0200 Kurt Kanzenbach wrote:
> >> I want to use ETF Qdisc with hardware offload, which is currently not
> >> possible on the stm32mp2.  
> >
> > Do you need multiple queues for ETF/normal traffic?
> > Or one ETF and one "normal"?
> >
> > How do you sort the traffic between the queues?  
> 
> So the stm32mp2 has two CPU cores. I've isolated CPU1 for Profinet. That
> one uses Tx/Rx queue 1 with ETF to reduce the Tx jitter. Everything else
> is routed to Tx/Rx queue 0.
> 
> Config looks like this:
> 
> #
> # Tx Assignment with SP.
> #
> # Tx Q 0 - Everything else
> # Tx Q 1 - RTC
> #
> tc qdisc replace dev ${INTERFACE} handle 100 parent root mqprio num_tc 2 \
>   map 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 \
>   queues 1@0 1@1 \
>   hw 1
> 
> #
> # Enable Tx launch time support for TC 1.
> #
> tc qdisc replace dev ${INTERFACE} parent 100:2 etf \
>   clockid CLOCK_TAI \
>   delta 500000 \
>   offload
> 
> On Rx incoming frames are steered via PCP field (vlan tagged).

Thanks for explaining!

> >> It seems like a static configuration in the driver today. I basically
> >> followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
> >> and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.
> >> 
> >> Tx Launch Time requires a different DMA descriptor layout. Currently
> >> tc_setup_etf() just returns -EINVAL if the DMA configuration is not
> >> setup appropriately. I guess a dynamic configuration requires to change
> >> the DMA config and perform a full release/open cycle.  
> >
> > release/open is not ideal but still better than hardcoding?  
> 
> For sure it's better than hardcoding :). But, again the driver does it
> statically. Maybe there's a good reason for it. Maybe not. I'm not that
> familiar with the stmmac driver. I'll prototype something to see whether
> we can enable TBS at run time using the ETF Qdisc callback. It may take
> some time though.

I think the m in stmmac stand for 'mistake'. 
We need to start cleaning it up.

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

On Thu Aug 20 2026, Jakub Kicinski wrote:
> On Wed, 19 Aug 2026 09:35:40 +0200 Kurt Kanzenbach wrote:
>> >> I want to use ETF Qdisc with hardware offload, which is currently not
>> >> possible on the stm32mp2.  
>> >
>> > Do you need multiple queues for ETF/normal traffic?
>> > Or one ETF and one "normal"?
>> >
>> > How do you sort the traffic between the queues?  
>> 
>> So the stm32mp2 has two CPU cores. I've isolated CPU1 for Profinet. That
>> one uses Tx/Rx queue 1 with ETF to reduce the Tx jitter. Everything else
>> is routed to Tx/Rx queue 0.
>> 
>> Config looks like this:
>> 
>> #
>> # Tx Assignment with SP.
>> #
>> # Tx Q 0 - Everything else
>> # Tx Q 1 - RTC
>> #
>> tc qdisc replace dev ${INTERFACE} handle 100 parent root mqprio num_tc 2 \
>>   map 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 \
>>   queues 1@0 1@1 \
>>   hw 1
>> 
>> #
>> # Enable Tx launch time support for TC 1.
>> #
>> tc qdisc replace dev ${INTERFACE} parent 100:2 etf \
>>   clockid CLOCK_TAI \
>>   delta 500000 \
>>   offload
>> 
>> On Rx incoming frames are steered via PCP field (vlan tagged).
>
> Thanks for explaining!

No problem.

>
>> >> It seems like a static configuration in the driver today. I basically
>> >> followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
>> >> and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.
>> >> 
>> >> Tx Launch Time requires a different DMA descriptor layout. Currently
>> >> tc_setup_etf() just returns -EINVAL if the DMA configuration is not
>> >> setup appropriately. I guess a dynamic configuration requires to change
>> >> the DMA config and perform a full release/open cycle.  
>> >
>> > release/open is not ideal but still better than hardcoding?  
>> 
>> For sure it's better than hardcoding :). But, again the driver does it
>> statically. Maybe there's a good reason for it. Maybe not. I'm not that
>> familiar with the stmmac driver. I'll prototype something to see whether
>> we can enable TBS at run time using the ETF Qdisc callback. It may take
>> some time though.
>
> I think the m in stmmac stand for 'mistake'. 

:D

> We need to start cleaning it up.

No objections here. I've briefly looked at the TBS thingy. I think we
just need to reconfigure one Tx queue instead of doing a full
release/open cycle. The XDP/ZC code does something similar. So the
infrastructure seems to be in place.

However, we need to keep track of what SoC implementation can enable TBS
on which queue. For gmac4 we can probably reuse tbs_en and for xgmac
there's is capability field tbs_ch_num. Let's see.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Maxime Chevallier]

Hi Kurt,

On 8/21/26 09:22, Kurt Kanzenbach wrote:
> On Thu Aug 20 2026, Jakub Kicinski wrote:
>> On Wed, 19 Aug 2026 09:35:40 +0200 Kurt Kanzenbach wrote:
>>>>> I want to use ETF Qdisc with hardware offload, which is currently not
>>>>> possible on the stm32mp2.  
>>>>
>>>> Do you need multiple queues for ETF/normal traffic?
>>>> Or one ETF and one "normal"?
>>>>
>>>> How do you sort the traffic between the queues?  
>>>
>>> So the stm32mp2 has two CPU cores. I've isolated CPU1 for Profinet. That
>>> one uses Tx/Rx queue 1 with ETF to reduce the Tx jitter. Everything else
>>> is routed to Tx/Rx queue 0.
>>>
>>> Config looks like this:
>>>
>>> #
>>> # Tx Assignment with SP.
>>> #
>>> # Tx Q 0 - Everything else
>>> # Tx Q 1 - RTC
>>> #
>>> tc qdisc replace dev ${INTERFACE} handle 100 parent root mqprio num_tc 2 \
>>>   map 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 \
>>>   queues 1@0 1@1 \
>>>   hw 1
>>>
>>> #
>>> # Enable Tx launch time support for TC 1.
>>> #
>>> tc qdisc replace dev ${INTERFACE} parent 100:2 etf \
>>>   clockid CLOCK_TAI \
>>>   delta 500000 \
>>>   offload
>>>
>>> On Rx incoming frames are steered via PCP field (vlan tagged).
>>
>> Thanks for explaining!
> 
> No problem.
> 
>>
>>>>> It seems like a static configuration in the driver today. I basically
>>>>> followed the same convention as dwmac-imx, dwmac-intel, dwmac-mediatek
>>>>> and dwmac-qcom-ethqos. Only dwmac-socfpga does it differently.
>>>>>
>>>>> Tx Launch Time requires a different DMA descriptor layout. Currently
>>>>> tc_setup_etf() just returns -EINVAL if the DMA configuration is not
>>>>> setup appropriately. I guess a dynamic configuration requires to change
>>>>> the DMA config and perform a full release/open cycle.  
>>>>
>>>> release/open is not ideal but still better than hardcoding?  
>>>
>>> For sure it's better than hardcoding :). But, again the driver does it
>>> statically. Maybe there's a good reason for it. Maybe not. I'm not that
>>> familiar with the stmmac driver. I'll prototype something to see whether
>>> we can enable TBS at run time using the ETF Qdisc callback. It may take
>>> some time though.
>>
>> I think the m in stmmac stand for 'mistake'. 

let's rename it stmmmmmmmmmmmmmmmmmmmmmmmac then

> 
> :D
> 
>> We need to start cleaning it up.
> 
> No objections here. I've briefly looked at the TBS thingy. I think we
> just need to reconfigure one Tx queue instead of doing a full
> release/open cycle. The XDP/ZC code does something similar. So the
> infrastructure seems to be in place.
> 
> However, we need to keep track of what SoC implementation can enable TBS
> on which queue. For gmac4 we can probably reuse tbs_en and for xgmac
> there's is capability field tbs_ch_num. Let's see.

Thanks for tackling this, let me know if you need testing. In the past weeks
I've been looking deep in my drawers as well as on various online shops, and
I'm starting to have a farily comprehensive set of stmmac-enabled devices
(although I couldn't get my hands on XGMAC, AgileX5 devkits appear to be way
outside my budget).

Let me know if you need help in testing for this, and we can ask the Altera folks
for some help in XGMAC testing.

Maxime

> 
> Thanks,
> Kurt

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Maxime Chevallier]

Hi,

On 8/21/26 15:41, Maxime Chevallier wrote:
> Hi Kurt,

(Sorry Kurt this has nothing to do with your patch, I'm following-up with
some stuff I said on that thread)

>> However, we need to keep track of what SoC implementation can enable TBS
>> on which queue. For gmac4 we can probably reuse tbs_en and for xgmac
>> there's is capability field tbs_ch_num. Let's see.
> 
> Thanks for tackling this, let me know if you need testing. In the past weeks
> I've been looking deep in my drawers as well as on various online shops, and
> I'm starting to have a farily comprehensive set of stmmac-enabled devices
> (although I couldn't get my hands on XGMAC, AgileX5 devkits appear to be way
> outside my budget).
Made an intersting finding yesterday, maybe it's already known stuff, but it turns
out it's easier to find a DRIVER for XGMAC than an actual device...

Looking at register layouts and at some then-removed copyright notices from the history,
it seems we have not one, not two, but three different drivers upstream for the same
DWXGMAC IP :

 - stmmac's dwxgmac
 - AMD's XGBE drives a designware XGMAC
 - Samsung's SXGBE also drives a designware XGMAC

No wonder the xgbe selftests were doing the same as the stmmac selftests :)

I think reuniting the codebases isn't gonna happen in the near future, however it
could be a good idea to hack stmmac to work on amd HW could be a good way to validate
the stmmac dwxgmac code, with another reference driver...

Maxime

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 5002 bytes --]

Hi Maxime,

On Fri Aug 21 2026, Maxime Chevallier wrote:
> Thanks for tackling this, let me know if you need testing. In the past weeks
> I've been looking deep in my drawers as well as on various online shops, and
> I'm starting to have a farily comprehensive set of stmmac-enabled devices
> (although I couldn't get my hands on XGMAC, AgileX5 devkits appear to be way
> outside my budget).
>
> Let me know if you need help in testing for this, and we can ask the Altera folks
> for some help in XGMAC testing.

Ok, I don't have a xgmac device either. Only stm32mp{1,2}, imx8mp and Intel
Elkhart Lake.

So, I've been looking into this TBS thingy and have a patch set for it. However,
there's one other issue which might be worth fixing first: When opening an
AF_XDP/ZC socket the kernel crashes rarely. Stacktrace see below. Seems like the
kernel is sending packets while the XSK socket is being configured.

Looking at stmmac_xdp_enable_pool(), there's napi_disable() and
stmmac_disable_tx_queue(). However, don't we miss something like
netif_tx_stop_queue() or synchronize_net()?

Also stmmac_enable_tx_queue() is of type void, but does memory allocations which
can fail. Shouldn't that function report the errors to the callers? ;-)

Thanks,
Kurt

Stacktrace on stm32mp2:

[ 1205.743707] stm32-dwmac 482c0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 1205.746103] stm32-dwmac 482c0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 1205.971709] Unable to handle kernel paging request at virtual address ffff800083a2d010
[ 1205.971736] Mem abort info:
[ 1205.971741]   ESR = 0x0000000096000047
[ 1205.971747]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1205.971756]   SET = 0, FnV = 0
[ 1205.971762]   EA = 0, S1PTW = 0
[ 1205.971767]   FSC = 0x07: level 3 translation fault
[ 1205.971774] Data abort info:
[ 1205.971778]   ISV = 0, ISS = 0x00000047, ISS2 = 0x00000000
[ 1205.971785]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 1205.971793]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1205.971801] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000008c517000
[ 1205.971809] [ffff800083a2d010] pgd=100000008cb71003, p4d=100000008cb71003, pud=100000008cb72003, pmd=10000001066eb403, pte=0000000000000000
[ 1205.971847] Internal error: Oops: 0000000096000047 [#1]  SMP
[ 1205.971847] stm32-dwmac 482c0000.ethernet end0: Register MEM_TYPE_XSK_BUFF_POOL RxQ-1
[ 1205.971856] Modules linked in:
[ 1205.971869] CPU: 1 UID: 0 PID: 112 Comm: kworker/1:2 Not tainted 7.2.0-rc4-00002-g36d3d0252886 #3 PREEMPT_RT 
[ 1205.971882] Hardware name: STMicroelectronics STM32MP257F-DK Discovery Board (DT)
[ 1205.971888] Workqueue: mld mld_ifc_work
[ 1205.971916] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1205.971926] pc : dwmac4_set_addr+0x8/0x20
[ 1205.971944] lr : stmmac_xmit+0x364/0x1950
[ 1205.971959] sp : ffff80008330b7f0
[ 1205.971963] x29: ffff80008330b800 x28: 0000000000000001 x27: ffff000082420b80
[ 1205.971977] x26: ffff0000842ed500 x25: 0000000000000001 x24: ffff000082420000
[ 1205.971991] x23: 0000000000000000 x22: 0000000000000020 x21: ffff000083afd002
[ 1205.972004] x20: 000000000000005a x19: 0000000000000001 x18: 0000000000000000
[ 1205.972017] x17: 008f000100000205 x16: 003a160000000000 x15: 0000000000000000
[ 1205.972030] x14: 02ff0017899bdb57 x13: 001789ff01000000 x12: 00000000000002ff
[ 1205.972043] x11: 0000000401000000 x10: 1816008f00010000 x9 : ffff800080e52c6c
[ 1205.972057] x8 : 80fe010024000000 x7 : 0060dd86ccd4e37a x6 : 0000000000000000
[ 1205.972070] x5 : ffff00007ae3405a x4 : 00000000ffffffff x3 : ffff0000873a0020
[ 1205.972083] x2 : ffff800080e5e3a8 x1 : 00000000fae34000 x0 : ffff800083a2d010
[ 1205.972098] Call trace:
[ 1205.972107]  dwmac4_set_addr+0x8/0x20 (P)
[ 1205.972123]  dev_hard_start_xmit+0xa8/0x300
[ 1205.972143]  sch_direct_xmit+0x9c/0x1f0
[ 1205.972157]  __dev_queue_xmit+0xb08/0x10e0
[ 1205.972168]  ip6_finish_output2+0x3b0/0x900
[ 1205.972189]  ip6_finish_output+0x1bc/0x370
[ 1205.972203]  ip6_output+0x88/0x1f8
[ 1205.972217]  NF_HOOK.constprop.0+0x54/0xf0
[ 1205.972234]  mld_sendpack+0x1c4/0x3a8
[ 1205.972247]  mld_ifc_work+0x1e0/0x420
[ 1205.972261]  process_one_work+0x164/0x4b0
[ 1205.972280]  worker_thread+0x194/0x318
[ 1205.972293]  kthread+0x138/0x150
[ 1205.972308]  ret_from_fork+0x10/0x20
[ 1205.972333] Code: 8156bd00 ffff8000 aa1e03e9 d503201f (f9000001) 
[ 1205.972349] ---[ end trace 0000000000000000 ]---
[ 1205.972363] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 1205.972371] SMP: stopping secondary CPUs
[ 1205.972393] Kernel Offset: disabled
[ 1205.972397] CPU features: 0x00000000,00000008,00040000,0400421b
[ 1205.972404] Memory Limit: none
[ 1206.253642] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
E/TC:0   Panic 'Watchdog' at /usr/src/debug/optee-os-stm32mp/4.0.0-stm32mp-r1-rc9/core/drivers/stm32_iwdg.c:228 <stm32_iwdg_it_handler>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next] net: stmmac: stm32: Set TSO/TBS Tx queues default settings

[Andrew Lunn]

> No objections here. I've briefly looked at the TBS thingy. I think we
> just need to reconfigure one Tx queue instead of doing a full
> release/open cycle. The XDP/ZC code does something similar. So the
> infrastructure seems to be in place.

I suggest you look back in the list. There have been a few emails
about people working in this area. You should try to do some
coordination.

There are some symmetry issues which would be nice to solve.

	Andrew