Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp638697pxu; Fri, 11 Dec 2020 10:32:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJyW0zxzNznbqz5RZOSmKy07+zsgeNlOMVErpl8iBUUP3vWf6ANGYdb+nrQ2Ir4gssU4nut2 X-Received: by 2002:a17:906:27d1:: with SMTP id k17mr12527294ejc.325.1607711542969; Fri, 11 Dec 2020 10:32:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607711542; cv=none; d=google.com; s=arc-20160816; b=b70Tz4Gbk/Ktwfdd49q8yqzQl5dKzJaDOBZyqLSJaGx1OfqJexu9HnUijNZpQUohgY x3Tk8wijvPCLnRDfa02+jZRsPBTAI22K+edpEIF5wfkkDWWvgOuCkBLl7chq2WRrqMqT D4gKl0WjXQ8JbayuIjsrbjjn3MLPElxdk7ZjyB8yBt2wjUB8pXEVXzHz+IWPvhW+B66q c98VeQwwYtm9TQaEs2j2GVY01TDrYS8PWn7gfglHxIiIRXAAF18eAqXVoFOO/R3+v2r8 qeCZx0J+qJW/0tro05fjcU8pAuC66Yda5bFohKyYNxR6XpWmfmKE+juXmMDWyAucQiN5 eFDw== 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=Rrj7Ac71QyUOrAFy2vHU1n7tROQ5QqfR59tqXEb0rss=; b=X5DVqUIf77KQxLcDROTv+jb1rQcOdBF4LqEI+F3EzFWUSfit8TI9LGwMzIw5HFNAoC okJOucBHKpcPDfx6hnWjOWcKLSEeQX3LwDDXashu3NzEg7OdJhz8+T6BC0rX9AKugda0 dSNcPk6jvsw4T12CkskmTWTiC2oHlbtbxFqgJ0nclTrWteULee0n/gY1UJ5AEZ/RelHO ippnEpfekY55dhiSxMfWxp6JkzNyd0Gnvom/F6wx4y/lQiI7tWHSNg5fOCKB5aouXEjM Ej58rGaGT2CWzekv1oRjs/G/3ttM1X/s+QDB1nQ/jmqgsmuJSFAkuiROtnwMdA/WBA0G 5h+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hXu+o2p+; 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 h14si6650611edl.381.2020.12.11.10.31.58; Fri, 11 Dec 2020 10:32:22 -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=hXu+o2p+; 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 S2391005AbgLKQIw (ORCPT + 99 others); Fri, 11 Dec 2020 11:08:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:35452 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728560AbgLKQIW (ORCPT ); Fri, 11 Dec 2020 11:08:22 -0500 Date: Fri, 11 Dec 2020 17:08:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1607702861; bh=1WeVfIHrj5CTqkyBJR1jYYf3odkPTbkUW4EIu+xgpu0=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=hXu+o2p+c8Es89OJnWhGUnKBiLsLTFQzOl3PfdcDZONEdP80JF/OVtrJND5j8ceSX 90pfMqiaSc3d2qLadRHSx0MjHLEnaczDufoEL6s4sAK7W+WYXOLPzHq7AMoaujp+4F 9A18/0pUy+yNs4fmjTX5ap5SeDmwpe+Og4K78OsY= From: Greg Kroah-Hartman To: Jiri Slaby Cc: Mychaela Falconia , Maarten Brock , Johan Hovold , "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> <54f40116-9a11-8daa-d3cd-5557cc60a4ef@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54f40116-9a11-8daa-d3cd-5557cc60a4ef@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11, 2020 at 09:46:54AM +0100, Jiri Slaby wrote: > On 10. 12. 20, 19:59, Mychaela Falconia wrote: > > > 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. > > > > If we go with O_DIRECT, what semantics are we going to implement? > > There are 3 possibilities that come to mind most readily: > > > > 1) O_DIRECT applies only to the open call in which this flag is set, > > and suppresses DTR/RTS assertion on that open. If someone needs to do > > multiple opens with DTR/RTS suppression being required every time, > > then they need to include O_DIRECT every time. > > > > 2) O_DIRECT applies not only immediately, but also sets a latched flag > > whereby all subsequent opens continue to suppress auto-assertion > > without requiring O_DIRECT every time. This approach by itself runs > > counter to the generic Unix way of doing things, but it may be OK if > > there is also some ioctl to explicitly set or clear the latched flag. > > > > 3) O_DIRECT applies only to the open call in which it is set, no > > built-in latching, but there is also some ioctl to control a flag > > enabling or disabling DTR/RTS auto-assertion on subsequent opens. > > 3) -- to allow standard tools to work on the device after the quirk is set > up once. I'm lost, what do you mean here? thanks, greg k-h