From patchwork Mon Apr 23 19:50:54 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elvinas X-Patchwork-Id: 10358043 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A6F9660209 for ; Mon, 23 Apr 2018 19:57:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 97A0928C24 for ; Mon, 23 Apr 2018 19:57:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8C4A328C27; Mon, 23 Apr 2018 19:57:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 91B4728C24 for ; Mon, 23 Apr 2018 19:57:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932314AbeDWT5T (ORCPT ); Mon, 23 Apr 2018 15:57:19 -0400 Received: from mail.veikia.net ([212.117.10.129]:49418 "EHLO mail.veikia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932306AbeDWT5T (ORCPT ); Mon, 23 Apr 2018 15:57:19 -0400 X-Greylist: delayed 377 seconds by postgrey-1.27 at vger.kernel.org; Mon, 23 Apr 2018 15:57:19 EDT Received: from localhost (localhost [127.0.0.1]) by mail.veikia.net (Postfix) with ESMTP id 53D711FD69 for ; Mon, 23 Apr 2018 22:50:59 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=veikia.lt; s=sm; t=1524513059; bh=sS+bgNV4VXIWdvdYAu+syRoRMMkSNvWLl1Vj6W8DyQk=; h=From:Subject:To:Date; b=S7unbomCDCDbvtd0ng+Mi4dZ/ReY+5VC0WQEpvJ57Iz387oJjdqBBllFdfZPaZrsi F6zaAD87lfoUeAbTCyXevxhCZkG3rtwI3tmhQKhZbF6DNRTChVqnybRvmnwURfm10U 94/kvYYRCuKK0R2bA7U2bDkwgfc3E9rwDFYRPtvc= Received: from [192.168.4.2] (94-232-122-150.ip.airnet.lt [94.232.122.150]) by mail.veikia.net (Postfix) with ESMTPSA id AC5781FD68 for ; Mon, 23 Apr 2018 22:50:56 +0300 (EEST) From: Elvinas Subject: Request for information how to disable USB bulk endpoint transfer validation To: linux-usb@vger.kernel.org Message-ID: <93d5aeb4-f1c7-9342-7bc5-4b277b4ec55e@veikia.lt> Date: Mon, 23 Apr 2018 22:50:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, I have a somewhat strange request: how to break Linux USB support and disable some validation. Recently I have become a "lucky" owner of the badly designed hardware (ZWO 120MM astronomy camera to be specific) and stumbled upon classic issue: hardware was designed not according to specifications, but to work on Windows. From what I was able to dig on ZWO forums , camera uses bulk transfer mode, but uses incorrect packet size of 1024 bytes. Windows ignores that, Linux - does not. As a result camera does not work in Linux. There are repeated messages in kern.log "usb 1-1: reset high-speed USB device number 8 using ehci_hcd" and "usb usb1-port1: disabled by hub (EMI?), re-enabling..." each time I attempted to use camera. In ZWO forums there was a suggestion to revert USB packet validation by applying a "break" to Linux kernel. With some changes to line locations I have applied the patch below and camera started to work on a desktop with USB 2.0 host. However this patch does not help if camera is attached to a laptop with USB 3.0 host. Each time I try to use camera, I see similar error messages, but now originating from xhci_hcd. Question: can anyone point what lines should be commented out to ignore packet sizes for USB 2.0 device, when attached to USB 3.0 host? As I am not much of C programmer I have not been able to locate those myself and did not want to play "whack a mole" by commenting out some random line, wait ~1 hour to compile kernel and see that nothing good happens. -------------------- CUT LINE ------------------- PS I know that not the ideal way to solve the problem, but booting customized kernel just for the imaging sessions for me seems to be a good trade off. Thank you --- config.c.ORIG 2018-03-14 19:48:11.000000000 +0200 +++ config.c 2018-04-16 19:45:24.538599024 +0300 @@ -374,10 +374,12 @@ j = maxpacket_maxes[usb_endpoint_type(&endpoint->desc)]; if (maxp > j) { - dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid maxpacket %d, setting to %d\n", + dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid maxpacket %d, setting to %d (IGNORED!)\n", cfgno, inum, asnum, d->bEndpointAddress, maxp, j); + #if 0 maxp = j; endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp); -------------------- CUT LINE -------------------