Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp626499pxb; Tue, 3 Nov 2020 08:19:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJxt1qP6I/EnVAfYWvKE4/hp5nm+bPFjuCNoTPl+kFCvgKQLOyp76LrJPEeWI+6+y+ZW9Hn1 X-Received: by 2002:aa7:d514:: with SMTP id y20mr18082168edq.384.1604420398761; Tue, 03 Nov 2020 08:19:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604420398; cv=none; d=google.com; s=arc-20160816; b=S3FlAPymxFX5v9+8c2vUvvUkk4cyUw25ed8RqWxIXeKgENrB3pDnxJ1dcREM0UL05t qvN7XIUE+MeBWhzXUjXIqO+ZsdGW0PEuHjdfEuJdljnkDnywaClpDis+1W1E76Mn+04a RqxmYoJnb0C5N8SiQeqEVHJTf4cBxSe4kHeWduWWD0Fm7uuxqQukEXBz79Zmg6c0kViy 33G33d891qIgUVQJ2GAcKuTy7j9kSrxJIJXowgiUcJsr6NqzZVkamHVzYU0NPJ4Ryi7+ hrFOXmDorzxi8vvvbp8vBKbqTa9weuUFBo+jR1H/+dWX2qRWZyGDCWqzO/eY0lNHXoVn NNjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=t4qKcEv/kAy0/mYgzIdz7bG4e0wLH+yHYuAmE4YRUnw=; b=TCN+S94olmnG5+1Oau3+IzWsSY6oTsUq0t6OHhJA5Qa0O1vJub0l4LTtB2cd8WFu2/ lv0mX4+/or/mdTgaIbASGuit2inca02zn8oRjHMuK6HXYsBOcT+nI6oogpshv74LoBhH iRv95WalYN64qbLMSz9PJlgd/kyKZhNwQitoGmUZAAQ1g0FI1I2FGdfXLnBkz1yRd1XE VLq3ie9VpLVPiC7MlphSKMFIgvnpi8LOl3yNUtD6cqhQ2wdB/CS1lbR5JA+0CxsAdTUq e62Oli4tWUfR3aO0VHWZ4AQCAIWHcprqD292VcT5lIHFRNxYfpQqoL99tQ5NC9Dc+qXC sGAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="gAG/XNiV"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si15049739eji.382.2020.11.03.08.19.11; Tue, 03 Nov 2020 08:19:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="gAG/XNiV"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728119AbgKCQPi (ORCPT + 99 others); Tue, 3 Nov 2020 11:15:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:48686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727385AbgKCQPi (ORCPT ); Tue, 3 Nov 2020 11:15:38 -0500 Received: from kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net (unknown [163.114.132.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EDFB8206CB; Tue, 3 Nov 2020 16:15:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604420137; bh=dDSnEZsWeRQuzp5A2JaHrJaoDH+U2yZat/4bMvsaZj4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gAG/XNiVvMMkHRgOWWHXMdJ1xNP4/zBqNHCedZoWa9/vTnORRwvFKm8UCbdYynj5G 01ECL3TJKshN2Zo7tr/7XBkkRdAC8J1SCHgg96ob22wgN0BgT1KILPet1GRAWt8xV9 3YVC0k6df05/yCHKanHyCtKWM4nMIWL1RyrcpLV0= Date: Tue, 3 Nov 2020 08:15:35 -0800 From: Jakub Kicinski To: Greg Kroah-Hartman Cc: Hayes Wang , "netdev@vger.kernel.org" , nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , Oliver Neukum Subject: Re: [PATCH net-next v2] net/usb/r8153_ecm: support ECM mode for RTL8153 Message-ID: <20201103081535.7e92a495@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: <20201103093241.GA79239@kroah.com> References: <1394712342-15778-387-Taiwan-albertk@realtek.com> <1394712342-15778-388-Taiwan-albertk@realtek.com> <20201031160838.39586608@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <20201102114718.0118cc12@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <20201103093241.GA79239@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 Nov 2020 10:32:41 +0100 Greg Kroah-Hartman wrote: > On Mon, Nov 02, 2020 at 11:47:18AM -0800, Jakub Kicinski wrote: > > On Mon, 2 Nov 2020 07:20:15 +0000 Hayes Wang wrote: > > > Jakub Kicinski > > > > Can you describe the use case in more detail? > > > > > > > > AFAICT r8152 defines a match for the exact same device. > > > > Does it not mean that which driver is used will be somewhat random > > > > if both are built? > > > > > > I export rtl_get_version() from r8152. It would return none zero > > > value if r8152 could support this device. Both r8152 and r8153_ecm > > > would check the return value of rtl_get_version() in porbe(). > > > Therefore, if rtl_get_version() return none zero value, the r8152 > > > is used for the device with vendor mode. Otherwise, the r8153_ecm > > > is used for the device with ECM mode. > > > > Oh, I see, I missed that the rtl_get_version() checking is the inverse > > of r8152. > > > > > > > +/* Define these values to match your device */ > > > > > +#define VENDOR_ID_REALTEK 0x0bda > > > > > +#define VENDOR_ID_MICROSOFT 0x045e > > > > > +#define VENDOR_ID_SAMSUNG 0x04e8 > > > > > +#define VENDOR_ID_LENOVO 0x17ef > > > > > +#define VENDOR_ID_LINKSYS 0x13b1 > > > > > +#define VENDOR_ID_NVIDIA 0x0955 > > > > > +#define VENDOR_ID_TPLINK 0x2357 > > > > > > > > $ git grep 0x2357 | grep -i tplink > > > > drivers/net/usb/cdc_ether.c:#define TPLINK_VENDOR_ID 0x2357 > > > > drivers/net/usb/r8152.c:#define VENDOR_ID_TPLINK 0x2357 > > > > drivers/usb/serial/option.c:#define TPLINK_VENDOR_ID 0x2357 > > > > > > > > $ git grep 0x17ef | grep -i lenovo > > > > drivers/hid/hid-ids.h:#define USB_VENDOR_ID_LENOVO 0x17ef > > > > drivers/hid/wacom.h:#define USB_VENDOR_ID_LENOVO 0x17ef > > > > drivers/net/usb/cdc_ether.c:#define LENOVO_VENDOR_ID 0x17ef > > > > drivers/net/usb/r8152.c:#define VENDOR_ID_LENOVO 0x17ef > > > > > > > > Time to consolidate those vendor id defines perhaps? > > > > > > It seems that there is no such header file which I could include > > > or add the new vendor IDs. > > > > Please create one. (Adding Greg KH to the recipients, in case there is > > a reason that USB subsystem doesn't have a common vendor id header.) > > There is a reason, it's a nightmare to maintain and handle merges for, > just don't do it. Ah! Good that we asked :) > Read the comments at the top of the pci_ids.h file if you are curious > why we don't even do this for PCI device ids anymore for the past 10+ > years. > > So no, please do not create such a common file, it is not needed or a > good idea. I wouldn't go that far, PCI subsystem just doesn't want everyone to add IDs to the shared file unless there is a reason. * Do not add new entries to this file unless the definitions * are shared between multiple drivers. Which seems quite reasonable. But it is most certainly your call :)