From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by befuddled.reisers.ca (Postfix, from userid 65534) id 4AD7E1F05B5; Tue, 28 Mar 2017 11:35:43 -0400 (EDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) by befuddled.reisers.ca (Postfix) with ESMTPS id 68FF91F05B0 for ; Tue, 28 Mar 2017 11:35:41 -0400 (EDT) Received: by mail-it0-x243.google.com with SMTP id e75so4103945itd.1 for ; Tue, 28 Mar 2017 08:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zIE7A9NXJhP8iinojrm3PfA4oCkQcAp/TJSccPl7LQY=; b=XBtpfg+KgCcPwa1+Gvrkv+LFGOmzlYZ7aN/VCqGVgoBrTwYsJkT4hLegWpegvnEs8U /qiUv7KrOup6aszaFQr93+dbuv4z866UkLlz9gMCRLvxwS1jIq+jsuFppu1edDo/5h1A 4mrPUS7CkHxtVo8T1CZFj3TqdwSHVln/a4yCfdPnDoKa4htAaGv0DClh9EU8/TqUMTlS UKfaC5quX8NjQOzwBcE9s6DTvObQEZwwD8XfphNvxPIfLLQO7207wRFRtKUl9vfEbEtM vt5cFV5rV6H1R4QZiheidNuzGHj+J1eq1aXcT4Uq2ZSbWvIVErv33dxKFH3zFLSe85Mt ysWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zIE7A9NXJhP8iinojrm3PfA4oCkQcAp/TJSccPl7LQY=; b=UE0sQTbHFcx1hWKwBJ3uh0WhOMX49BZ/kSiXL6p07p8jFdwaOoU2EhoODLgPnv3g3E y3p0tRonIOguLrPwBPkYPBewNDwmLJgVk2csO9U+P50fKb/U7enngJxONVn+6+48K6aG sxkXs0gdh+GW1DRvVjJ9vq9dVDBQJlNdi5Xz9z9eeNwad4ZLwxNNPOr2lPyp1fB9bvLU UqWqigI2Oj51nPSOMcq8zbb+UHEa+5nu8r3xXSYlhJC53hx+h+AnvF5L/qxq7tuis7St 7NZ/E+pGX9kULN3E/zbAjuBnI1Cdw6/ixfrgVKN4/6Y/zi2kB+gR8VsF/ATEoD5SsbOi crvg== X-Gm-Message-State: AFeK/H1cAAYVH3UZBMXkPiLp1UftFGjW53k6XQR1zCgQ36iEXLP0XBUrD/PObZQNFucrZii1xYq18hPCFla3Rw== X-Received: by 10.36.253.4 with SMTP id m4mr14151370ith.19.1490715340332; Tue, 28 Mar 2017 08:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.158.81 with HTTP; Tue, 28 Mar 2017 08:35:39 -0700 (PDT) In-Reply-To: <20170328151143.4yv2qx2byg32ayv4@var.youpi.perso.aquilenet.fr> References: <20170225192842.GA4519@sanghar> <20170225193031.GA4525@sanghar> <20170226015005.25u3ea7ag5ub5ulc@var.youpi.perso.aquilenet.fr> <20170226024832.ly3mogxxrktjehzf@var.youpi.perso.aquilenet.fr> <20170328151143.4yv2qx2byg32ayv4@var.youpi.perso.aquilenet.fr> From: Okash Khawaja Date: Tue, 28 Mar 2017 16:35:39 +0100 Message-ID: Subject: Re: [patch 6/6] staging: speakup: Migrate acntsa, bns, dectlk and txprt to ttyio To: Samuel Thibault Cc: "Speakup is a screen review system for Linux." Content-Type: text/plain; charset=UTF-8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:35:43 -0000 On Tue, Mar 28, 2017 at 4:11 PM, Samuel Thibault wrote: > Hello, > > Okash Khawaja, on mar. 28 mars 2017 15:35:08 +0100, wrote: >> On Sun, Feb 26, 2017 at 2:48 AM, Samuel Thibault >> wrote: >> > - in the receive_buf2 method, >> > - if read_buff_add is defined, just call it for each character and be >> > done >> > - otherwise, store the first received character in >> > ((struct spk_ldisc_data *)tty->disc_data)->buf >> > , call up() on the semaphore, and return 1 (to tell that you ate the >> > character). >> >> >> I don't fully understand how the return value of receive_buf2 is used >> in flow control. According to Documentation/serial/tty.txt it is the >> number of bytes processed by it, whereas comments on top of >> tty_ldisc_receive_buf function's definition - which returns value >> returned by receive_buf2 - say it is the number of bytes not >> processed. > > I believe the comment is wrong: for instance n_tty_receive_buf_common > clearly returns the number of processed bytes, and users (such as > paste_selection, receive_buf from flush_to_ldisc) use it that way. You > can probably submit a patch that fixes the comment already. > >> Also, is the call to tty_schedule_flip in spk_serial_in because we >> returned 1 receive_buf2 so we have to manually tell it to flip buffer? > > (note: I meant spk_ttyio_in, of course) > > It's because we only returned 1, yes, i.e. we only ate 1 character, > while there probably were more to read, but we didn't eat them, so we > have to tell the tty layer when we are ready to eat more. Right, so either we process all characters, return count (the argument to receive_buf2) and don't bother with tty_schedule_flip, or we process less than count and call tty_schedule_flip. Thanks very much for explaining Okash