Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp636101pxu; Fri, 11 Dec 2020 10:29:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJzpmLRc5bsc53E5k9uqesgkhceg/tu+eNx0gtJ5EF5xGVZpKCMwjjkmPdcVpi/9KSPTcW5x X-Received: by 2002:a17:906:c006:: with SMTP id e6mr12183596ejz.374.1607711340747; Fri, 11 Dec 2020 10:29:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607711340; cv=none; d=google.com; s=arc-20160816; b=JSRMccYc6le1xXUhP+XR1N0Ia1YeiDZwSxrsMpu+7tfhT3DRACDGN8f1WC5aKlfnkt EnYHlw+UlMfSPW0H4K1CwWV4pSp1FM4x5oR+/fZiEBuwXT1f1a3rpq2f9PLP+XFiMtYm vF94wxWvz8BUdkvXpUbIl/a2d/0HwrzoDBo7P7DATQfk77OO/7jWSRmpLysUbC3M0XND VNxoXCZFWvBUGeyBzpbrIZ/xVmtvjF1FWq62d7geYaCg7iSd0ZUm3FvXQXnCD3t66zBG Ynz3qi+sWvkn+VKdTOnkWTY0C2R4EPVza8z5dnZbs37UsMLV+uFe0GHdL/ku1Jib1ozP SUiA== 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:dkim-signature:date; bh=CRF+KAJZrfVmfvWM1xJwaWFGCX5d0SQA7aW7PpXano4=; b=m/xncBISfqJVm+uXxz0T25I9gvuFFMYY06ISYKa6I8zTeBWR0XTwyGPjGRB1zsD06B GXpDFd2iqoeykDGhJQp/7NMEcZPV4eole2snVD2Y6FvbX4D5M2HSV+b8F3reg1F1UYTB 3UZ52rYXQeh1UwT/XSPGbZdut1h4Ds2Wge7Nd7ZIXmgKmHweY4v4sMlL3BqVF5SdnEur AYFr/NproQ0mOskJKFVsno5HiK8665wU0u6hDUNplaGT0iOBjDHieIgUo/ZNoa9N7hGV uq6Qqx4eqXU8LTpnbaiozHfRimQeB9i3TaQpCIF5+Y8SucWg2mV+SKCRhdnnqL6Mxa0g EcyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BsIaVEp3; 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 f5si4936961ejw.117.2020.12.11.10.28.37; Fri, 11 Dec 2020 10:29:00 -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=BsIaVEp3; 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 S2390417AbgLKQIJ (ORCPT + 99 others); Fri, 11 Dec 2020 11:08:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:35230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728560AbgLKQHu (ORCPT ); Fri, 11 Dec 2020 11:07:50 -0500 Date: Fri, 11 Dec 2020 17:08:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1607702827; bh=8K0AfIOlGYfDnbwCgLtNMgoVihEssPErUyL/IHSIz9k=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=BsIaVEp3uqEAYNZk99Io6CDWA37Cm8A4g7a3B87UNlku8RHzGjqhpuNodglNP+fXK w8tnKhXsmk50UTXMtrHng+k66xY85uvXrEeJGZhgRXLlEQ7ri7crTlXTeQ59VBKaFP aoVjuB3t70dYzaTfbUMaC2WKILbsEN1AVWnD9eJw= From: Greg Kroah-Hartman To: Mychaela Falconia Cc: Maarten Brock , Johan Hovold , 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 Thu, Dec 10, 2020 at 10:59:41AM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > Companies/devices lie about vid:pid all the time, > > Wait, are you accusing *me* of lying? PID range 0x7150 through 0x7157 > out of FTDI's VID 0x0403 has been officially allocated by FTDI (please > feel free to confirm with FTDI, no need to take my word blindly) to > Falconia Partners LLC, which is *my* company - Falconia is my last > name. Therefore, any accusation of lying in connection with any > VID:PID in this range, including DUART28C VID:PID of 0x0403:0x7152, is > an accusation of lying against me personally, which I take very > seriously. I am not saying you are using an "invalid id", or copying anything, see below: > > wait until your > > specific vid:pid is repurposed for some other device and then what > > happens? :) > > Let's break it down: > > 1) I do have an idea for a future hw product that could indeed reuse > DUART28C VID:PID - however, the reason for reusing the same USB ID is > that the potential product in question would have exactly the same > wiring inside and require the exact same handling from Linux, i.e., > suppress automatic DTR/RTS assertion on Channel B, but retain standard > behaviour on Channel A. > > 2) If I were to reuse the same USB ID for a different hw product that > should NOT receive the exact same quirk treatment, it would be 100% my > fault and I would have no right to run to OS maintainers complaining, > or even to sell such product, I would argue. > > 3) If some other party illegally squats on a PID out of FTDI's VID > range which FTDI officially allocated to me, and then comes to Linux > maintainers with a complaint however many years from now, whoever will > be the maintainer at that time will be able to check with FTDI, get an > official answer as to whom that PID rightfully belongs to, and that > will be the resolution. 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. We also have fuzzing devices that spoof vid/pid pairs in order to test kernel code, as well as being used as malicious devices to hack systems or do other "fun" things. Blindly trusting these numbers are something we can no longer do. The point being, while it is nice to trigger off of these values, beware that it is not the only way that something like a userspace visable change should trigger off of because this is something that a user wants to have happen. This also makes it easier as it "should" work for all serial devices, and not be tied to specific hardware ids, requiring kernel updates for new devices that want to do this. hope this helps explain this a bit more. > > O_DIRECT is an interesting hack, has anyone seen if it violates the > > posix rules for us to use it on a character device like this? > > According to open(2) Linux man page, O_DIRECT does not come from POSIX > at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus > it seems like there aren't any POSIX rules to be violated here. Ah, for some reason I thought that newer POSIX releases finally defined this, as vendors wanted that written down so they could "rely" on it. Maybe not... thanks, greg k-h