Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7114085ybi; Thu, 13 Jun 2019 09:47:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqxOjXv+x9i5+cWrEzOEvkjHEIyF8BnA3eD4Mt3VhW+54c2gk9P7kbyxywXAbyCmOpb6Rcy+ X-Received: by 2002:a65:648e:: with SMTP id e14mr6114129pgv.317.1560444460606; Thu, 13 Jun 2019 09:47:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560444460; cv=none; d=google.com; s=arc-20160816; b=ZfX3RyWyQ+EFfATQAeNnvzs9bC/UvhvA/hri4q/esRy+e0DSxpw541gUMm6zW+jUwE kGGuiDOK72u2H6FadRjsaqQv7KLwizFAnDzHIE0RrR0Dq8ux+PXkIVR1Q3XaqXDaqETF g6C4j3EXS84wRmtUQTT7HyRIjHvT8f0u6CQeyNZGW3zTqv/5Xq8OI6/rYcoj+b5fT+57 WJ9h3/LOCBEEL3UQRMseA7MMkXZuFTLlFMoFDruYV+97Yi7gU66GW9r7+MHaKMmiDhjh K7I6yROJiHVPiBnv7vmPTb63AHyvoeIHnv/lj0eRPfgt7fpL4yvSwIPuXrdHNJD8KVtu 8ZoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject; bh=Lz6zcA7LXLwb8cPiOhtZ3+YZpus4c84JSMtkdshzF1g=; b=J6G6lQc8p+H4030DQjOk4ZX9kTmN8ugBb5aPBFEJeXjshdhZsOk/3woxHYqaLKs0Jf D94uQyYMWqBkDcCkDqrPRlQGPfsVcD8mzDr6HihE5ZSmI1rnuZ1CTKx+TitYSEmb0ry/ zdnN6MO/Epfmwxe5OL3AbiFFU0MTaEcDxcw//XHEINnhfYSZzItieuKDOv0jbMaXf5eb FAUTzBDXXQK6e7HCd2B35rD3JgTYuNYzSiqCefmKeg1bVqq+TqFWOvMVX/uoRPChnJ+A FQan+8YpOQGI5pCMYwzvZyVnjCcTlVsIm6CdZYLvDtfL04a72OjbMxs+QCVoGLknhdZ+ 8LTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1si196560pgi.432.2019.06.13.09.47.25; Thu, 13 Jun 2019 09:47:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392997AbfFMQqZ (ORCPT + 99 others); Thu, 13 Jun 2019 12:46:25 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:16972 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730307AbfFMFdS (ORCPT ); Thu, 13 Jun 2019 01:33:18 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id AE6674FFC4; Thu, 13 Jun 2019 07:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id x8XDMHiD5zbs; Thu, 13 Jun 2019 07:32:48 +0200 (CEST) Subject: Re: [PATCH 2/2 v5] tty/serial/8250: use mctrl_gpio helpers To: Andy Shevchenko Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Yegor Yefremov , Mika Westerberg , Giulio Benetti , Greg Kroah-Hartman References: <20190611105603.4435-1-sr@denx.de> <20190611105603.4435-2-sr@denx.de> <20190611124415.GT9224@smile.fi.intel.com> <85f0d39c-e5d8-320b-e611-d956630a629f@denx.de> <20190611144828.GX9224@smile.fi.intel.com> <12e5180e-b4a0-e5fa-bcad-ddc8103d644c@denx.de> <20190612091621.GA9224@smile.fi.intel.com> From: Stefan Roese Message-ID: <6a4f1001-b023-c972-7b36-6d2f8f9a3fa8@denx.de> Date: Thu, 13 Jun 2019 07:32:39 +0200 MIME-Version: 1.0 In-Reply-To: <20190612091621.GA9224@smile.fi.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.06.19 11:16, Andy Shevchenko wrote: > On Wed, Jun 12, 2019 at 10:13:05AM +0200, Stefan Roese wrote: >> On 11.06.19 16:48, Andy Shevchenko wrote: >>> On Tue, Jun 11, 2019 at 04:02:54PM +0200, Stefan Roese wrote: >>>> On 11.06.19 14:44, Andy Shevchenko wrote: >>>>> On Tue, Jun 11, 2019 at 12:56:03PM +0200, Stefan Roese wrote: >>> >>>>>> static inline void serial8250_out_MCR(struct uart_8250_port *up, int value) >>>>>> { >>>>>> serial_out(up, UART_MCR, value); >>>>>> + >>>>>> + if (up->gpios) { >>>>>> + int mctrl_gpio = 0; >>>>>> + >>>>>> + if (value & UART_MCR_RTS) >>>>>> + mctrl_gpio |= TIOCM_RTS; >>>>>> + if (value & UART_MCR_DTR) >>>>>> + mctrl_gpio |= TIOCM_DTR; >>>>>> + >>>>>> + mctrl_gpio_set(up->gpios, mctrl_gpio); >>>>>> + } >>>>>> } >>> >>>>>> static inline int serial8250_in_MCR(struct uart_8250_port *up) >>>>>> { >>>>>> - return serial_in(up, UART_MCR); >>>>>> + int mctrl; >>>>>> + >>>>>> + mctrl = serial_in(up, UART_MCR); >>>>>> + >>>>>> + if (up->gpios) { >>>>>> + int mctrl_gpio = 0; >>>>>> + >>>>>> + /* save current MCR values */ >>>>>> + if (mctrl & UART_MCR_RTS) >>>>>> + mctrl_gpio |= TIOCM_RTS; >>>>>> + if (mctrl & UART_MCR_DTR) >>>>>> + mctrl_gpio |= TIOCM_DTR; >>>>>> + >>>>>> + mctrl_gpio = mctrl_gpio_get_outputs(up->gpios, &mctrl_gpio); >>>>>> + if (mctrl_gpio & TIOCM_RTS) >>>>>> + mctrl |= UART_MCR_RTS; >>>>>> + else >>>>>> + mctrl &= ~UART_MCR_RTS; >>>>>> + >>>>>> + if (mctrl_gpio & TIOCM_DTR) >>>>>> + mctrl |= UART_MCR_DTR; >>>>>> + else >>>>>> + mctrl &= ~UART_MCR_DTR; >>>>>> + } >>>>>> + >>>>>> + return mctrl; >>>>>> } >>>>> >>>>> These are using OR logic with potentially volatile data. Shouldn't we mask >>>>> unused bits in UART_MCR in case of up->gpios != NULL? >>>> >>>> Sorry, I don't see, which bits you are referring to? Could you please be >>>> a bit more specific with the variable / macro meant (example)? >>> >>> I meant that we double write values in the out() which might have some >>> consequences, though I hope nothing wrong with it happens. >> >> Where is the double write to a register? Sorry, I fail to spot it. > > Not to the one register. From the functional point of view the same signal is > set up twice: once per UART register, once per GPIO pins. > >>> In the in() we read the all bits in the register. >>> >>> As now I look at the implementation of mctrl_gpio_get_outputs(), >>> I think we rather get helpers for conversion between TIOCM and UART_MCR values, >>> so, they can be used in get_mctrl() / set_mctrl() and above. >> >> Do you something like this in mind? > > More likely > > static inline int serial8250_MCR_to_TIOCM(int mcr) MSR_to_TIOCM (see below) ... > { > int tiocm = 0; > > if (mcr & ...) > tiocm |= ...; > ... > > return tiocm; > } > > static inline int serial8250_TIOCM_to_MCR(int tiocm) > { > ... in a similar way ... > } While implementing such wrapper functions I noticed, that get_mctrl() / set_mctrl() need TIOCM->MCR and MSR->TIOCM (notice MSR vs MCR here) but serial8250_in_MCR() needs MCR->TIOCM. So there is not that much overlay here. Additionally the wrappers would need to handle all bits and only some of them are needed in serial8250_in/out_MCR(), so I would need to add masking here as well. For my taste its not really worth adding these wrappers as they won't make things much clearer (if at all). Thanks, Stefan