HID: logitech-dj: add logi_dj_recv_queue_unknown_work helper

Add a logi_dj_recv_queue_unknown_work helper and implement query
rate-limiting inside this helper.

The motivations behind this are:

1) We need to queue workitems for reports with no place to forward them
from more places with the upcoming non-unifying receiver support, hence
the addition of the helper function.

2) When we've missed a pairing info report (or there is a race between
the report and input-events) and the input report is e.g. from a mouse
being moved, we will get a lot of these before we've finished (re-)
querying and enumerating the devices, hence the rate-limiting.

Note this also removes the:

if (!djrcv_dev->paired_dj_devices[hidpp_report->device_index])

check previously guarding the sending of an unknown workitem, the caller
of logi_dj_recv_queue_notification already does this check before calling
logi_dj_recv_queue_notification.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

drivers/hid/hid-logitech-dj.c

@@ -128,6 +128,7 @@ struct dj_receiver_dev {
 	struct kref kref;
 	struct work_struct work;
 	struct kfifo notif_fifo;
+	unsigned long last_query; /* in jiffies */
 	bool ready;
 	spinlock_t lock;
 };
@@ -458,6 +459,7 @@ static struct dj_receiver_dev *dj_get_receiver_dev(struct hid_device *hdev,
 		}
 		kref_init(&djrcv_dev->kref);
 		list_add_tail(&djrcv_dev->list, &dj_hdev_list);
+		djrcv_dev->last_query = jiffies;
 	}
 
 	if (application == HID_GD_KEYBOARD)
@@ -637,6 +639,30 @@ static void delayedwork_callback(struct work_struct *work)
 	}
 }
 
+/*
+ * Sometimes we receive reports for which we do not have a paired dj_device
+ * associated with the device_index or report-type to forward the report to.
+ * This means that the original "device paired" notification corresponding
+ * to the dj_device never arrived to this driver. Possible reasons for this are:
+ * 1) hid-core discards all packets coming from a device during probe().
+ * 2) if the receiver is plugged into a KVM switch then the pairing reports
+ * are only forwarded to it if the focus is on this PC.
+ * This function deals with this by re-asking the receiver for the list of
+ * connected devices in the delayed work callback.
+ * This function MUST be called with djrcv->lock held.
+ */
+static void logi_dj_recv_queue_unknown_work(struct dj_receiver_dev *djrcv_dev)
+{
+	struct dj_workitem workitem = { .type = WORKITEM_TYPE_UNKNOWN };
+
+	/* Rate limit queries done because of unhandeled reports to 2/sec */
+	if (time_before(jiffies, djrcv_dev->last_query + HZ / 2))
+		return;
+
+	kfifo_in(&djrcv_dev->notif_fifo, &workitem, sizeof(workitem));
+	schedule_work(&djrcv_dev->work);
+}
+
 static void logi_dj_recv_queue_notification(struct dj_receiver_dev *djrcv_dev,
 					   struct dj_report *dj_report)
 {
@@ -666,21 +692,8 @@ static void logi_dj_recv_queue_notification(struct dj_receiver_dev *djrcv_dev,
 			workitem.type = WORKITEM_TYPE_UNPAIRED;
 		break;
 	default:
-	/* A normal report (i. e. not belonging to a pair/unpair notification)
-	 * arriving here, means that the report arrived but we did not have a
-	 * paired dj_device associated to the report's device_index, this
-	 * means that the original "device paired" notification corresponding
-	 * to this dj_device never arrived to this driver. The reason is that
-	 * hid-core discards all packets coming from a device while probe() is
-	 * executing. */
-		if (!djrcv_dev->paired_dj_devices[dj_report->device_index]) {
-			/*
-			 * ok, we don't know the device, just re-ask the
-			 * receiver for the list of connected devices in
-			 * the delayed work callback.
-			 */
-			workitem.type = WORKITEM_TYPE_UNKNOWN;
-		}
+		logi_dj_recv_queue_unknown_work(djrcv_dev);
+		return;
 	}
 
 	kfifo_in(&djrcv_dev->notif_fifo, &workitem, sizeof(workitem));
@@ -776,6 +789,8 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 	struct dj_report *dj_report;
 	int retval;
 
+	djrcv_dev->last_query = jiffies;
+
 	dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
 	if (!dj_report)
 		return -ENOMEM;