linux.git/drivers/net/fddi, branch master

FDDI: defza: Sanitise the reset safety timer

2026-05-14T00:31:01+00:00

The reset actions of the DEFZA adapters are exceedingly slow, taking up
to 30 seconds to complete by the device spec and typically in the range
of 10 seconds in reality, as required for the device RTOS to boot, still
quite a lot.  Therefore a state machine is used that's interrupt driven,
however a safety mechanism is required in case of adapter malfunction,
so that if no state change interrupt has arrived in time, then the
situation is taken care of.

The safety mechanism depends on the origin of the reset.  For regular
adapter initialisation at the device probe time a sleep is requested.
However a reset is also required by the device spec when the adapter has
transitioned into the halted state, such as in response to a PC Trace
event in the course of ring fault recovery, possibly a common network
event.  In that case no sleep is possible as a device halt is reported
at the hardirq level.

A timer is therefore set up to ensure progress in case no adapter state
change interrupt has arrived in time, but as from commit 168f6b6ffbee
("timers: Use del_timer_sync() even on UP") a warning is issued as the
timer is deleted in the hardirq handler upon an expected state change:

  defza: v.1.1.4  Oct  6 2018  Maciej W. Rozycki
  tc2: DEC FDDIcontroller 700 or 700-C at 0x18000000, irq 4
  tc2: resetting the board...
  ------------[ cut here ]------------
  WARNING: kernel/time/timer.c:1611 at __timer_delete_sync+0x104/0x120, CPU#0: swapper/0/0
  Modules linked in:
  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.0.0-dirty #2 VOLUNTARY
  Stack : 9800000002027d08 00000000140120e0 0000000000000000 ffffffff8089d468
          0000000000000000 0000000000000000 ffffffff807ed6b8 ffffffff80897458
          ffffffff80897400 9800000002027b88 0000000000000000 7070617773203a6d
          0000000000000000 9800000002027ba4 0000000000001000 6465746e69617420
          0000000000000000 ffffffff807ed6b8 00000000140120e0 0000000000000009
          000000000000064b ffffffff800dd14c 0000000000000036 9800000002184000
          0000000000000000 0000000000000020 0000000000000000 ffffffff80910000
          ffffffff8085c000 9800000002027c70 0000000000000001 ffffffff80045fa0
          0000000000000000 0000000000000000 0000000000000000 0000000000000009
          000000000000064b ffffffff800502b8 ffffffff807ed6b8 ffffffff80045fa0
          ...
  Call Trace:
  [] show_stack+0x28/0xf0
  [] dump_stack_lvl+0x48/0x7c
  [] __warn+0xa0/0x128
  [] warn_slowpath_fmt+0x64/0xa4
  [] __timer_delete_sync+0x104/0x120
  [] fza_interrupt+0xc74/0xeb8
  [] __handle_irq_event_percpu+0x70/0x228
  [] handle_irq_event_percpu+0x18/0x78
  [] handle_percpu_irq+0x50/0x80
  [] generic_handle_irq+0x90/0xd0
  [] do_IRQ+0x1c/0x30
  [] handle_int+0x148/0x154
  [] do_idle+0x40/0x108
  [] cpu_startup_entry+0x2c/0x38
  [] kernel_init+0x0/0x108

  ---[ end trace 0000000000000000 ]---
  tc2: OK
  tc2: model 700 (DEFZA-AA), MMF PMD, address 08-00-2b-xx-xx-xx
  tc2: ROM rev. 1.0, firmware rev. 1.2, RMC rev. A, SMT ver. 1
  tc2: link unavailable
  ------------[ cut here ]------------
  WARNING: kernel/time/timer.c:1611 at __timer_delete_sync+0x104/0x120, CPU#0: swapper/0/0
  Modules linked in:
  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G        W           7.0.0-dirty #2 VOLUNTARY
  Tainted: [W]=WARN
  Stack : 9800000002027d08 00000000140120e0 0000000000000000 ffffffff8089d468
          0000000000000000 0000000000000000 ffffffff807ed6b8 ffffffff80897458
          ffffffff80897400 9800000002027b88 0000000000000000 0000000000000000
          0000000000000000 9800000002027ba4 0000000000001000 0000000000000000
          0000000000000000 ffffffff807ed6b8 00000000140120e0 0000000000000009
          000000000000064b ffffffff800dd14c 0000000000000036 9800000002184000
          0000000000000000 0000000000000020 0000000000000000 ffffffff80910000
          ffffffff8085c000 9800000002027c70 0000000000000001 ffffffff80045fa0
          0000000000000000 0000000000000000 0000000000000000 0000000000000009
          000000000000064b ffffffff800502b8 ffffffff807ed6b8 ffffffff80045fa0
          ...
  Call Trace:
  [] show_stack+0x28/0xf0
  [] dump_stack_lvl+0x48/0x7c
  [] __warn+0xa0/0x128
  [] warn_slowpath_fmt+0x64/0xa4
  [] __timer_delete_sync+0x104/0x120
  [] fza_interrupt+0xc74/0xeb8
  [] __handle_irq_event_percpu+0x70/0x228
  [] handle_irq_event_percpu+0x18/0x78
  [] handle_percpu_irq+0x50/0x80
  [] generic_handle_irq+0x90/0xd0
  [] do_IRQ+0x1c/0x30
  [] handle_int+0x148/0x154
  [] arch_local_irq_disable+0x4/0x28
  [] do_idle+0x50/0x108
  [] cpu_startup_entry+0x2c/0x38
  [] kernel_init+0x0/0x108

  ---[ end trace 0000000000000000 ]---
  tc2: registered as fddi0

The immediate origin of the new warning is the switch away from aliasing
del_timer_sync() to del_timer() (timer_delete_sync() to timer_delete()
in terms of current function names) for UP configurations, which however
is the only choice for this driver anyway as no SMP hardware supports
the TURBOchannel bus this device interfaces to.  Therefore there is a
very remote issue only this is a sign of.

Specifically if an adapter reset issued upon a transition to the halted
state times out and first triggers fza_reset_timer() for another reset
assertion, which then schedules fza_reset_timer() for reset deassertion
and then that second call is pre-empted after poking at the hardware,
but before the timer has been rearmed and owing to high system load
causing exceedingly high scheduling latency control is not handed back
before a transition to the uninitialised state has caused the timer to
be deleted even before it has been started, then fza_reset_timer() will
be called yet again and issue another reset even though by then the
adapter has already recovered.

Prevent this situation from happening by switching to timer_delete() for
the transition to the halted state and protect the code region affected
with a spinlock, also to make sure add_timer() has not been called twice
in a row due to an execution race between the interrupt handler and the
timer handler (though it could only happen on SMP, but let's keep the
driver clean).  It's a very unlikely sequence of events to happen and
therefore there's no point in trying to be overly clever about it, such
as by placing printk() calls outside the protection.  For the transition
to the uninitialised state switch to timer_delete_sync_try() instead, so
that a timer isn't deleted that's just been rearmed by the timer handler
and needs to watch for the device to come out of reset again (again, an
SMP scenario only).

Retain timer_delete_sync() invocations outside the hardirq context for a
stray timer not to fire once device structures have been released.

Fixes: 61414f5ec9834 ("FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter")
Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Jakub Kicinski

FDDI: defxx: Rate-limit memory allocation errors

2026-03-31T01:11:37+00:00

Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure, e.g.:

[...]
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
fddi0: Could not allocate receive buffer.  Dropping packet.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 	0-...!: (332 ticks this GP) idle=255c/1/0x40000000 softirq=16420123/16420123 fqs=0
rcu: 	(t=2103 jiffies g=35680089 q=4 ncpus=1)
rcu: rcu_sched kthread timer wakeup didn't happen for 2102 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: 	Possible timer handling issue on cpu=0 timer-softirq=12779658
rcu: rcu_sched kthread starved for 2103 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: 	Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_sched       state:I stack:0     pid:14    tgid:14    ppid:2      flags:0x00004000
Call Trace:
 __schedule+0x258/0x580
 schedule+0x19/0xa0
 schedule_timeout+0x4a/0xb0
 ? hrtimers_cpu_dying+0x1b0/0x1b0
 rcu_gp_fqs_loop+0xb1/0x450
 rcu_gp_kthread+0x9d/0x130
 kthread+0xb2/0xe0
 ? rcu_gp_init+0x4a0/0x4a0
 ? kthread_park+0x90/0x90
 ret_from_fork+0x2d/0x50
 ? kthread_park+0x90/0x90
 ret_from_fork_asm+0x12/0x20
 entry_INT80_32+0x10d/0x10d
CPU: 0 UID: 500 PID: 21895 Comm: 31370.exe Not tainted 6.13.0-dirty #2

(here running the libstdc++-v3 testsuite).

Signed-off-by: Maciej W. Rozycki 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/alpine.DEB.2.21.2603291236590.60268@angie.orcam.me.uk
Signed-off-by: Jakub Kicinski

FDDI: defza: Rate-limit memory allocation errors

2026-03-31T01:11:31+00:00

Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure.

Signed-off-by: Maciej W. Rozycki 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/alpine.DEB.2.21.2603291252380.60268@angie.orcam.me.uk
Signed-off-by: Jakub Kicinski

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37+00:00

Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

treewide: Switch/rename to timer_delete[_sync]()

2025-04-05T08:30:12+00:00

timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

net: handle HAS_IOPORT dependencies

2024-04-08T10:56:56+00:00

In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for
those drivers requiring them. For the DEFXX driver the use of I/O
ports is optional and we only need to fence specific code paths. It also
turns out that with HAS_IOPORT handled explicitly HAMRADIO does not need
the !S390 dependency and successfully builds the bpqether driver.

Acked-by: Marc Kleine-Budde 
Acked-by: Jakub Kicinski 
Acked-by: Maciej W. Rozycki 
Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
Signed-off-by: David S. Miller

net: fill in MODULE_DESCRIPTION()s for fddik/skfp

2024-02-15T16:03:46+00:00

W=1 builds now warn if module is built without a MODULE_DESCRIPTION().
Add descriptions to the SysKonnect FDDI PCI module.

Signed-off-by: Breno Leitao 
Link: https://lore.kernel.org/r/20240214152741.670178-5-leitao@debian.org
Signed-off-by: Jakub Kicinski

net: fddi: skfp: rmt: Clean up some inconsistent indenting

2023-04-11T10:46:26+00:00

No functional modification involved.

drivers/net/fddi/skfp/rmt.c:236 rmt_fsm() warn: if statement not indented.

Reported-by: Abaci Robot 
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4736
Signed-off-by: Jiapeng Chong 
Link: https://lore.kernel.org/r/20230407034157.61276-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Paolo Abeni

net: defxx: Fix missing err handling in dfx_init()

2022-12-09T10:44:27+00:00

When eisa_driver_register() or tc_register_driver() failed,
the modprobe defxx would fail with some err log as follows:

 Error: Driver 'defxx' is already registered, aborting...

Fix this issue by adding err hanling in dfx_init().

Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support")
Signed-off-by: Yongqiang Liu 
Reviewed-by: Jiri Pirko 
Signed-off-by: David S. Miller

skfp/h: fix repeated words in comments

2022-08-12T10:20:29+00:00

Delete the redundant word 'the'.

Signed-off-by: Jilin Yuan 
Signed-off-by: David S. Miller