Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp383866pxu; Thu, 7 Jan 2021 07:25:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPbTgPpi/bEnUlaiNAoe/0jb1Di6v/jzSJ9hDEg4SExS6lJfE1u+xkFcFq5oUea5iW63BV X-Received: by 2002:a17:906:4e45:: with SMTP id g5mr6685324ejw.391.1610033152276; Thu, 07 Jan 2021 07:25:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610033152; cv=none; d=google.com; s=arc-20160816; b=C+mlEygCBkx9VAcM3T++9Sfvn5Zd3rYB1WyjAHloWv7D4raCsb60A0/u88pPUlXtmh 2rfgyJpiBzrdA2Iu+itZMIO68DgCduP1rg0WUcm8z8xirkZRIkUq2LmzQP5IbMRLIjDq ykyPzF+ZxVa37UjX8zwLdKc0PCl8jiH5GhU+7Nn+ZRhhgsjQEQ+F8wdNMgsn06Ns1xQc mUJy98CpYqiMyNmdYqCu+ooUId2zEIlz1M78KNtVI+ze/hhYOwnAZ4f+RDr8+NEVVuug sioym5F/t79NrY/h5S2O985SgdeXRrKyO5b+o53wEhfCFFDE+vMAXYuX5yfoIG+kjMUh rVNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=48eXy3Kki1MLAvCEUZivOJufPpw5SOk8K4oncNpzOfs=; b=sJIgck+DPXat3n8dVBmJabOU7wC8fKZj7vjZ3Ix8KMrRS5KyAmXaUkX50h8yu1TPGo QOIkay+YLqFSWd7u6MQZOvKlsLQV/ZoxrQ+EAelVwKhT8X8HcZl5MuSMwIeF0CKVAdwr Zw5YtOZMRU/AnM5bSpArxW/sS8p2xVBspxjtxNCIbxYvGkbe0r6U3W/Zj3umQKZJ90jD RgTlzcxzYKE0+u3/qXMsGUYAoaFwL57hIzIDFmHp9HMgKSCRkduLT5sd9VZ2dDJEkf/W f7Oc8gf+qr3HjNh3FthrovLaZ6gojDIsDEjLF6SoupY9jk2LivNXJsERlHRKmlhBhynm cLvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hvYxI5Vc; 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=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a12si2307950ejg.220.2021.01.07.07.25.28; Thu, 07 Jan 2021 07:25:52 -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=@linuxfoundation.org header.s=korg header.b=hvYxI5Vc; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727590AbhAGPYi (ORCPT + 99 others); Thu, 7 Jan 2021 10:24:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:59802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726165AbhAGPYh (ORCPT ); Thu, 7 Jan 2021 10:24:37 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 490C0224B0; Thu, 7 Jan 2021 15:23:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1610033036; bh=f+RvX/8PLKLcATPKcNCbrp8iv9sFa7OxE+/hcfSwHOY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hvYxI5VcYh5vz74cw/yMwWDAOL8KV73cVhkXn7BInLaPM2R6lTKpaEsTy3eie84v0 Osdj0HWs/rTfcA+pLGcnEJUUr16gk7WiKd7c+FbcGsspblsei8vMs6bH+OC2I2Fifa NxYKnT5oLsqnwP3ynrnv9INGYjHH+oabhMuXZRmM= Date: Thu, 7 Jan 2021 16:25:16 +0100 From: Greg Kroah-Hartman To: Mychaela Falconia Cc: Johan Hovold , Maarten Brock , Jiri Slaby , "Mychaela N . Falconia" , linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open Message-ID: References: <20201202113942.27024-1-johan@kernel.org> <6b81cca21561305b55ba8f019b78da28@vanmierlo.com> <3fc3097ce1d35ce1e45fa5a3c7173666@vanmierlo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 18, 2020 at 10:03:59AM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > We see devices that are "obviously" not the real vid/pid all the time in > > the wild. There's nothing "illegal" about another company using your > > vid/pid, look at all of the ones out there already that use the FTDI > > vendor id yet are "clones", same with pl2303 devices. > > But are those reusers of someone else's VID or PID coming to Linux > kernel maintainers with requests to modify ftdi_sio or pl2303 drivers > to work with their clones? Do you ever see LKML posts along the lines > of "Hi, I am so and so from such and such company, we are not FTDI but > we reuse FTDI's VID and PIDs, but our clone chip does not match the > original and we need to modify the ftdi_sio driver to work with our > poor man's clone chip" - do reusers of someone else's VID or PID come > here with such requests? Users of devices with cloned ids come to us asking why their devices do not work on Linux and how to fix them. Happens all the time, and as the job of a kernel is to enable hardware, we work to make this happen. The vendors who do this are no where to be found, of course, and telling people that the device they just purchased is "counterfit" doesn't really fall in our job description. We have all sorts of work-arounds in Linux drivers to support "fake" devices, our job is to make Linux work for everyone. Anyway, this is far off-topic for this thread, sorry, just letting you know why trying to rely on vid/pid is not the "final solution" people might think it is. I wish someone else would have weighed in on the different api options here, oh well, let me think about this over the next week or so... thanks, greg k-h