From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6711C43140 for ; Wed, 20 Jun 2018 16:46:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 71B0120846 for ; Wed, 20 Jun 2018 16:46:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71B0120846 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932425AbeFTQq1 (ORCPT ); Wed, 20 Jun 2018 12:46:27 -0400 Received: from mga07.intel.com ([134.134.136.100]:56896 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932082AbeFTQq0 (ORCPT ); Wed, 20 Jun 2018 12:46:26 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2018 09:46:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,248,1526367600"; d="scan'208";a="65808312" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 20 Jun 2018 09:46:22 -0700 Received: by stinkbox (sSMTP sendmail emulation); Wed, 20 Jun 2018 19:46:21 +0300 Date: Wed, 20 Jun 2018 19:46:21 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= Cc: linux-bluetooth@vger.kernel.org, Kay Sievers , systemd-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [systemd-devel] [PATCH bluez] hid2hci: Fix udev rules for linux-4.14+ Message-ID: <20180620164621.GM20518@intel.com> References: <20180507130638.3516-1-ville.syrjala@linux.intel.com> <20180507174459.GH8805@in.waw.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180507174459.GH8805@in.waw.pl> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2018 at 05:44:59PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 07, 2018 at 04:06:38PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Since commit 1455cf8dbfd0 ("driver core: emit uevents when > > device is bound to a driver") the kernel started emitting > > "bound" and "unbound" uevents which confuse the hid2hci > > udev rules. > > > > The symptoms on an affected machine (Dell E5400 in my case) > > include bluetooth devices not appearing and udev hogging > > the cpu as it's busy processing a constant stream of these > > "bound"+"unbound" uevents. > > > > Change the udev rules only kick in for an "add" event. > > This seems to cure my machine at least. > > > > Cc: Dmitry Torokhov > > Cc: Greg Kroah-Hartman > > Cc: Marcel Holtmann > > Cc: Kay Sievers > > Cc: systemd-devel@lists.freedesktop.org > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-bluetooth@vger.kernel.org > > Signed-off-by: Ville Syrjälä > > --- > > tools/hid2hci.rules | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/hid2hci.rules b/tools/hid2hci.rules > > index db6bb03d2ef3..daa381d77387 100644 > > --- a/tools/hid2hci.rules > > +++ b/tools/hid2hci.rules > > @@ -1,6 +1,6 @@ > > # do not edit this file, it will be overwritten on update > > > > -ACTION=="remove", GOTO="hid2hci_end" > > +ACTION!="add", GOTO="hid2hci_end" > > SUBSYSTEM!="usb*", GOTO="hid2hci_end" > > This will skip over lines 22-23. Is the rule there supposed to > work for ACTION==add only (in which case your patch would be OK), > or also for ACTION==change? Maybe it'd be safer to just add the GOTO > for bind/unbind. Forgot about this one. Thanks for catching that. I think checking for "add|change" is the sanest approach. I fired off a v2 with that approach. Actually I'm not sure if this change stuff is working at all in any case. On my systems udevadm is in /bin, but this rules file hardcodes /sbin/udevadm as the path. -- Ville Syrjälä Intel