diff --git a/examples/systemd/99-udc.rules b/examples/systemd/99-udc.rules
deleted file mode 100644
index 26cd5e6..0000000
--- a/examples/systemd/99-udc.rules
+++ /dev/null
@@ -1,5 +0,0 @@
-#  SPDX-License-Identifier: MIT or LGPL-2.1+
-#
-# Copyright 2019 Collabora Ltd
-#
-SUBSYSTEM=="udc", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="gt.target"
diff --git a/examples/systemd/README.rst b/examples/systemd/README.rst
index 5a4b535..c821fe5 100644
--- a/examples/systemd/README.rst
+++ b/examples/systemd/README.rst
@@ -91,14 +91,14 @@ Udev rule
 .. code-block:: console
 
 	SUBSYSTEM=="udc", ACTION=="add", \
-		 TAG+="systemd", ENV{SYSTEMD_WANTS}+="gt.target"
+		 TAG+="systemd", ENV{SYSTEMD_WANTS}+="usb-gadget.target"
 
 
 The condition for taking the activity is that there is a kernel "add" event
 from the "udc" subsystem, which means a new udc has just been made available.
 The device in question is tagged with "systemd", which makes systemd
 aware of the new device, and SYSTEMD_WANTS is set to the name of the target we
-want to reach if the condition is met.
+want to reach if the condition is met. This is provided by systemd since 242.
 
 Systemd
 =======
@@ -113,7 +113,7 @@ Target unit
 
 The target is a simple target to be reached when the udev rule fires.
 The service unit will use a "WantedBy" dependency to lend itself for being
-managed with systemctl enable/disable.
+managed with systemctl enable/disable. This is provided by systemd since 242.
 
 Service unit
 ------------
@@ -134,7 +134,7 @@ The unit file is named gt@.service and is a template unit.
 	Type=simple
 
 	[Install]
-	WantedBy=gt.target
+	WantedBy=usb-gadget.target
 
 This unit is a template unit, so system administrator is supposed to issue
 
@@ -142,8 +142,8 @@ This unit is a template unit, so system administrator is supposed to issue
 
 	systemctl enable gt@<gadget scheme file basename>
 
-This sets up appropriate symbolic links in gt.target.wants directory, which
-in turn triggers executing the service unit the usual systemd way.
+This sets up appropriate symbolic links in usb-gadget.target.wants directory,
+which in turn triggers executing the service unit the usual systemd way.
 
 The service itself uses gt to load gadget scheme with the name implied from
 the template parameter, name the gadget accordingly and activate it. Upon
@@ -296,8 +296,8 @@ Discussion
 ==========
 
 This document assumes there is only one UDC available in the gadget system.
-If there are more, the first one to appear will cause reaching the gt.target,
-so the first UDC becoming available will be used for running the gadget.service
+The first UDC that becomes available will lead to reaching usb-gadget.target,
+so the first UDC becoming available will be used for running the gadget service
 on it. This might or might not be what you want.
 
 This document does not address the case where actual USB device functionality
diff --git a/examples/systemd/gt.target b/examples/systemd/gt.target
deleted file mode 100644
index b3c20b9..0000000
--- a/examples/systemd/gt.target
+++ /dev/null
@@ -1,6 +0,0 @@
-#  SPDX-License-Identifier: MIT or LGPL-2.1+
-#
-# Copyright 2019 Collabora Ltd
-#
-[Unit]
-Description=Hardware activated USB gadget
diff --git a/examples/systemd/gt@.service b/examples/systemd/gt@.service
index 082218b..597ee92 100644
--- a/examples/systemd/gt@.service
+++ b/examples/systemd/gt@.service
@@ -14,4 +14,4 @@ ExecStop=gt rm -rf %i
 Type=simple
 
 [Install]
-WantedBy=gt.target
+WantedBy=usb-gadget.target