Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Larry Finger <larry.finger@gmail.com>
Message-ID: <dddc4967-18f8-7d61-a991-264d618dda40@lwfinger.net>
Date:   Sun, 9 Oct 2022 20:11:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Subject: Re: rtl8187 triggers usb device reset on kernel driver disconnect
To:     David Tomaschik <david@systemoverlord.com>,
        linux-wireless@vger.kernel.org, herton@canonical.com,
        htl10@users.sourceforge.net
References: <CAOy4VzfHRD0cw2jdL=pzukc1QFuXgaC55Zst7uc-dMFPrHr7Yw@mail.gmail.com>
Content-Language: en-US
From:   Larry Finger <Larry.Finger@lwfinger.net>
In-Reply-To: <CAOy4VzfHRD0cw2jdL=pzukc1QFuXgaC55Zst7uc-dMFPrHr7Yw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/7/22 23:33, David Tomaschik wrote:
> Hi all,
> 
> It seems that any time the rtl8187 driver is detached from an rtl8187
> interface, a USB device reset is triggered.  This is not a problem in
> the general case, but when working with libusb, calling
> libusb_detach_kernel_driver
> (https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html#ga5e0cc1d666097e915748593effdc634a)
> results in the device reset, which then causes the kernel driver to
> re-attach to the device.  This prevents, for example, forwarding the
> device into a VM using QEMU/KVM.  This seems to be due to
> rtl8187_disconnect calling usb_reset_device.
> 
> The 8187 driver seems to be the only realtek driver unconditionally
> resetting on disconnect -- is this technically necessary?  I'm not
> sure I would call this a bug, but it's definitely behavior that was
> very puzzling to me and I only understood after enough debugging to
> start reading kernel source.

David,

This behavior certainly is a bug. If one tries to attach the RTL8187 to a VM, it 
crashes. I will be looking into this issue.

Larry