Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754509AbbHCQwt (ORCPT ); Mon, 3 Aug 2015 12:52:49 -0400 Received: from mail-ig0-f170.google.com ([209.85.213.170]:38398 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753164AbbHCQwq (ORCPT ); Mon, 3 Aug 2015 12:52:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1438024626-36448-1-git-send-email-reillyg@chromium.org> <20150802071341.GE32270@amd> Date: Mon, 3 Aug 2015 09:52:46 -0700 X-Google-Sender-Auth: 4EsXNuFrRLMw58Z_a5txeN1Gq5g Message-ID: Subject: Re: [PATCH] HID: use generic driver for ThingM blink(1) if !CONFIG_HID_THINGM From: Reilly Grant To: Jiri Kosina Cc: Pavel Machek , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1103 Lines: 28 If the software is using usbdevice_fs, no, it can simply detach the kernel driver. If the software is using hidraw then this blacklist becomes the issue because even if you unload the special driver the generic HID driver won't load. Is there a mechanism in the HID subsystem for drivers to build on top of the generic one instead of replacing it? On Mon, Aug 3, 2015, 2:25 AM Jiri Kosina wrote: > > On Sun, 2 Aug 2015, Reilly Grant wrote: > > > There is existing user space software (not just mine, also from the > > manufacturer) that does not use the special driver and instead uses hidraw > > or usbdevice_fs to control the device. LED class driver support for this > > device is useful but should be optional. > > Is there any problem for the userspace software to unbind the kernel > driver first? > > -- > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/