From owner-freebsd-usb@freebsd.org Thu Jul 2 08:42:13 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 46CF334DEB8 for ; Thu, 2 Jul 2020 08:42:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yBRS273Lz4Vmf for ; Thu, 2 Jul 2020 08:42:11 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B242E2601F3; Thu, 2 Jul 2020 10:42:03 +0200 (CEST) Subject: Re: USB reset fails when using a LimeSDR Mini on FreeBSD To: Jan Behrens , "freebsd-usb@FreeBSD.org" References: <20200625121052.e9f7e7cbeb68fad264ec80a9@magnetkern.de> <20200625200849.6af81489a80c2f97d4f89ee6@magnetkern.de> <20200625224522.44d6584465cb6e20d17be320@magnetkern.de> <0ec3e5a3-7f31-d1cd-6862-6066c431aa80@selasky.org> <20200626135151.e5542cf97fad213c4ad661f2@magnetkern.de> <5c0729f9-9e98-52f7-a5cb-6c5dfd2287a3@selasky.org> <20200626172851.872f3a08fa6e632666683230@magnetkern.de> <20200627144419.f14371695d9b62ea99106c4a@magnetkern.de> <20200627173604.7f7b7777140e66dbad812fc7@magnetkern.de> <20200627180420.4b8012fb@ernst.home> <20200702103523.adb0566bcc7b6e354905a8a5@magnetkern.de> From: Hans Petter Selasky Message-ID: <97c8fd11-9200-dff7-4c68-b0b80cc44871@selasky.org> Date: Thu, 2 Jul 2020 10:41:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200702103523.adb0566bcc7b6e354905a8a5@magnetkern.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yBRS273Lz4Vmf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.36 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.05)[-0.053]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 08:42:13 -0000 On 2020-07-02 10:35, Jan Behrens wrote: > Thus Linux definitely behaves differently here. My question is: Can > and/or should FreeBSD be fixed to allow libusb_reset_device() as a user > or should a driver library be fixed to not use that call. This is an architectural problem. USB devices may have interfaces with independent drivers attached. If one USB interface driver is running as root and another USB interface driver is running as non-root, it doesn't make sense that the non-root device driver should be able to affect the root-one. Your LimeSDR device appears to be very simple, having just one USB device driver attaching to it. Just imagine some web-page trying to reset your USB device, just because it can! Yes, USB is also exposed to firefox nowadays :-) What we could do is to add a sysctl which controls the behaviour for this specific case. Would that be of any use to you? --HPS