Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4883793ybb; Tue, 24 Mar 2020 07:06:43 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtva3pyQ9/OYYOngvpKd62BFQvwTQL2b+lbRuR2cRy9K1cfQMhcxB19vNpFrPaGaMGEQspn X-Received: by 2002:a9d:12d:: with SMTP id 42mr9494147otu.2.1585058803815; Tue, 24 Mar 2020 07:06:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585058803; cv=none; d=google.com; s=arc-20160816; b=b+/ZgffPN+cuoAXQwXTx1J8pAQHMr7RqUhfAF22fMR5ZbDY60e8lkc0uelTq3NDBwK jA4OL+kmBEf/zaAkIfvJfjJl8nlt2tJnkopmWosqSY9+I967AGxYAzs0H46//z74Vh78 xiB0pJu8rmFVgH2YtIJmwKzD4TLgHNAnfnEP5kHfmkkYhXwdZceWp5gX4I6+IGZEaWsn JiBbLFjXnRHXz9mVST4V5/axKwNiluFnxnJMCERjmiuJU9/NY9gDUmZwiG3TRVhwK0c8 OyjrVsh2X9wMYjQzJb/WpukfvifUF9TF+8Idl1i6sh1uRW/aYQ01ABWU3QepqT4jT74I RSrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:to:from:subject:message-id; bh=DGaD8ZMK7NZ+JyKd+hdh2EwUAH9QK7MeDjTtrJU80xk=; b=eTaPobNSmMduVCn5h21YGmpzr+WdHFZ+XePm4lF1ggx2hzt33+KfVb/+yLWg8/0cQA oumH8Y2vC+sztClcsqBQdQI28xm+3vx0MR/Ag0uxrGZ6oR6nOBZ6uT2vt+bEpwZxGLw+ MwU8X3m6ukCtAGtRxajYgrh1ZCGGTnWIK80cOdmmMnvrdlXEu2HumMiKdX0FDkVXOcyE H+cEfi4kyzSN0tK3jC5eobSjEqIx0+r/1PArqRzpukb3yjqxmKCkkmGIxDjehufvXUsE SdQwqBIglZlrGkcuBZJrjS+gWsHBf0F3p4nIUKID5lGIO0H6NjGdANOobM0tGzACVaIY kNqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d22si777640oos.47.2020.03.24.07.06.21; Tue, 24 Mar 2020 07:06:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727742AbgCXOD2 (ORCPT + 99 others); Tue, 24 Mar 2020 10:03:28 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:38815 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727213AbgCXOD2 (ORCPT ); Tue, 24 Mar 2020 10:03:28 -0400 X-Originating-IP: 83.155.44.161 Received: from classic (mon69-7-83-155-44-161.fbx.proxad.net [83.155.44.161]) (Authenticated sender: hadess@hadess.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 2DA9BC0017; Tue, 24 Mar 2020 14:03:24 +0000 (UTC) Message-ID: <220e8421f8ee0cf80375bfc4635e3eaa2bb8daf1.camel@hadess.net> Subject: Re: [PATCH v2] HID: logitech-dj: issue udev change event on device connection From: Bastien Nocera To: Filipe =?ISO-8859-1?Q?La=EDns?= , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Hutterer , Hans de Goede , Mario Limonciello , Richard Hughes Date: Tue, 24 Mar 2020 15:03:24 +0100 In-Reply-To: References: <20200318161906.3340959-1-lains@archlinux.org> <20200318192721.390630-1-lains@archlinux.org> <92f48f409e913299c12322d195c88792bb4e5c9c.camel@hadess.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.0 (3.36.0-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-03-24 at 13:46 +0000, Filipe Laíns wrote: > On Tue, 2020-03-24 at 11:20 +0100, Bastien Nocera wrote: > > On Wed, 2020-03-18 at 19:27 +0000, Filipe Laíns wrote: > > > As discussed in the mailing list: > > > > > > > Right now the hid-logitech-dj driver will export one node for > > > > each > > > > connected device, even when the device is not connected. That > > > > causes > > > > some trouble because in userspace we don't have have any way to > > > > know if > > > > the device is connected or not, so when we try to communicate, > > > > if > > > > the > > > > device is disconnected it will fail. > > > > Why is it a problem that user-space communication fails? Note that > > sending a signal without any way to fetch the state means that it's > > always going to be racy. > > It failing is not the problem. The problem is knowing when the device > is available again. Right now the only way to do that is to listen > for > events or periodically ping it. > > We want to only export the HID++ hidraw node when the device is > available but that will take a while. We will have to test and sync > up > userspace. I also want to write tests for the driver before, to make > sure there are no regressions. We had a thread discussing this, IIRC > you were in CC. If I need to remember some old thread to know what we're talking about, then that means that the commit message is probably not good enough... Please add some links to the relevant discussion on bug forums if there's interesting data there too. > > > > The solution reached to solve this issue is to trigger an udev > > > change > > > event when the device connects, this way userspace can just wait > > > on > > > those connections instead of trying to ping the device. > > > > > > Signed-off-by: Filipe Laíns > > > > > > --- > > > > > > v2: > > > - Issue udev change event on the connected hid device, not on > > > the > > > receiver > > > > > > --- > > > drivers/hid/hid-logitech-dj.c | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid- > > > logitech-dj.c > > > index 48dff5d6b605..282e57dd467d 100644 > > > --- a/drivers/hid/hid-logitech-dj.c > > > +++ b/drivers/hid/hid-logitech-dj.c > > > @@ -1412,6 +1412,7 @@ static int logi_dj_dj_event(struct > > > hid_device > > > *hdev, > > > { > > > struct dj_receiver_dev *djrcv_dev = hid_get_drvdata(hdev); > > > struct dj_report *dj_report = (struct dj_report *) data; > > > + struct dj_device *dj_dev; > > > unsigned long flags; > > > > > > /* > > > @@ -1447,7 +1448,9 @@ static int logi_dj_dj_event(struct > > > hid_device > > > *hdev, > > > > > > spin_lock_irqsave(&djrcv_dev->lock, flags); > > > > > > - if (!djrcv_dev->paired_dj_devices[dj_report->device_index]) { > > > + dj_dev = djrcv_dev->paired_dj_devices[dj_report->device_index]; > > > + > > > + if (!dj_dev) { > > > /* received an event for an unknown device, bail out */ > > > logi_dj_recv_queue_notification(djrcv_dev, dj_report); > > > goto out; > > > @@ -1464,6 +1467,8 @@ static int logi_dj_dj_event(struct > > > hid_device > > > *hdev, > > > if (dj_report- > > > > report_params[CONNECTION_STATUS_PARAM_STATUS] == > > > STATUS_LINKLOSS) { > > > logi_dj_recv_forward_null_report(djrcv_dev, > > > dj_report); > > > + } else { > > > + kobject_uevent(&dj_dev->hdev->dev.kobj, > > > KOBJ_CHANGE); > > > } > > > break; > > > default: