hvc_iucv_hangup(9)

💅 hvc_iucv_hangup — the manual page, bestie edition 🎀

okay so this is hvc_iucv_hangup(9) from the Kernel API Manual, and honestly? she's a little chaotic but she gets the job done ✨

---

✨ NAME ✨

hvc_iucv_hangup — sever that IUCV path and schedule the hvc tty hang up, periodt 💅

---

🌸 SYNOPSIS 🌸

void hvc_iucv_hangup (struct hvc_iucv_private *priv );

---

🦋 ARGUMENTS 🦋

• priv — a pointer to the hvc_iucv_private structure. that's it, that's the whole argument list, she's low maintenance 🫶

---

💖 DESCRIPTION 💖

okay so here's the tea ☕ — this routine severs an existing IUCV communication path and hangs up the underlying HVC terminal device. but bestie, listen: the hang-up only happens if an IUCV communication path is actually established. if there's no path, there's literally nothing to hang up, so no need to touch the terminal device. no cap 🙈

the IUCV HVC hang-up is split into two steps, and the way that it works is:

1. after the IUCV path has been severed, the iucv_state is set to IUCV_SEVERED.
2. later, when the HVC thread calls hvc_iucv_get_chars, that IUCV_SEVERED state is what causes the tty hang-up in the HVC layer. like, it's giving delayed gratification 💅

now for the "has the tty even been opened yet" vibe check:

• if the tty has not yet been opened, clean up the hvc_iucv_private structure so re-connects are allowed. slay, tidy, iconic ✨
• if the tty has been opened, let get_chars return -EPIPE to signal the HVC layer to hang up the tty and, if so, wake up the HVC thread to call get_chars... 😭 (yes, the original really does trail off like that, we love an ellipsis queen)

👑 Special notes on hanging up a HVC terminal instantiated as console 👑

this part is highkey the main character energy of the whole page, so pay attention 🫶

Hang-up:

1. do_tty_hangup replaces file ops (= hung_up_tty_fops)
2. do_tty_hangup calls tty->ops->close for console_filp => no hangup notifier is called by HVC (default)
2. hvc_close returns because of tty_hung_up_p(filp) => no delete notifier is called! finally, the back-end is not being notified, thus, the tty session is kept active (TTY_OPEN) to be ready for re-connects 👑

⚠️ just a heads up, the numbering is literally 1, 2, 2 in the original — we're preserving that exactly, no editing, not me fixing it, nope 💀

Locking: spin_lock(priv->lock) w/o disabling bh 🔒

---

🌈 SEE ALSO 🌈

Kernel file ./drivers/tty/hvc/hvc_iucv.c plus, like, the whole friend group:

• hvc_iucv_get_private(9)
• alloc_tty_buffer(9)
• destroy_tty_buffer(9)
• destroy_tty_buffer_list(9)
• hvc_iucv_write(9)
• hvc_iucv_get_chars(9)
• hvc_iucv_queue(9)
• hvc_iucv_send(9)
• hvc_iucv_sndbuf_work(9)
• hvc_iucv_put_chars(9)
• hvc_iucv_notifier_add(9)
• hvc_iucv_cleanup(9)
• tty_outqueue_empty(9)
• flush_sndbuf_sync(9)
• hvc_iucv_notifier_hangup(9)
• hvc_iucv_dtr_rts(9)
• hvc_iucv_notifier_del(9)
• hvc_iucv_filter_connreq(9)
• hvc_iucv_path_pending(9)
• hvc_iucv_path_severed(9)
• hvc_iucv_msg_pending(9)
• hvc_iucv_msg_complete(9)
• hvc_iucv_alloc(9)
• hvc_iucv_destroy(9)
• hvc_iucv_parse_filter(9)
• hvc_iucv_setup_filter(9)
• param_set_vmidfilter(9)
• param_get_vmidfilter(9)
• hvc_iucv_init(9)
• hvc_iucv_config(9)

---

and that's the whole page, bestie 💜 this lil gem lives in ./drivers/tty/hvc, dated October 2026, and the page itself is hvc_iucv_hangup(9) — go forth and hang up those ttys responsibly 🧚‍♀️🍓