Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp325250ybi; Fri, 24 May 2019 04:31:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzB7tuOMYNOgB8zNiXr567J1trgNXKB27Y98a4ng9mGKfAkldZJdXFv4utZxOZOJssTzY4 X-Received: by 2002:aa7:8c1a:: with SMTP id c26mr111620322pfd.25.1558697482436; Fri, 24 May 2019 04:31:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558697482; cv=none; d=google.com; s=arc-20160816; b=tTalDvFx67CZomfof5nZnrcHSSWhuxUMKVETj1Ip+ElGK+vm0BPOBvNCS1w3fnFszV 3dx4et+vKfa6KxLl5U6v6ZESq9IIw4ebLL8S+4SlI8I/a8huaRzRJKLx3Rpwgx+lcENN v658qQZHYiKNXLM5RffqwgFOPZg5qVscvwv8d0W5jWzLVglemPEFET8DTqvnTsmnhXil MIA2kdNJcDAD/2wAaC5XUnH0Ya+zF724HeNgOeOu+t+hzEfdwCgoaKaEBOBu6JsWr4xZ dQgojyNDGA7ZOqx2Bev8Nvb5G3Wys3R2HxGRfFkB+EPZzhJq2sVZwx29klwtngVBkh2A r4tA== 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=XAiJmmtX/85r3+Jv+W8tj1ipp/SYqboNnM6Ln+HlPDY=; b=Vqq3Iwyf1B1+xBVpAoII7Y2TQQdI9qtMcVgcSTTrqXkt053XGVqnpBQMRpKJPJhbw8 qr17iaK5aOnG1dgT9NVAip37oXd5OkVRakMmiyBrqw/KZYKbZL1QMh86T0swRJuHHdkq raJK9tXlpVKIpE3RECNpNoPrvllsBeDBFSdXsLqgGqzEHZrbo2tcIePeD6M+8DFNIqha ImGi7u1QSUtkjQnjU37X7gcXDtb3jmuWtuqrX5A4dCSUTU3y8hvbuTWJXi500Ot4Gigt hHbIBwGiMdBs35Se6Qmj2Up/I/ffQpztorAKCZlgFJiLscw2VFbbmfDspXGRtl6Ajrjk hjFg== 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 y17si3463654plp.59.2019.05.24.04.31.06; Fri, 24 May 2019 04:31:22 -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 S2390935AbfEXL3y (ORCPT + 99 others); Fri, 24 May 2019 07:29:54 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:24394 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390654AbfEXL3x (ORCPT ); Fri, 24 May 2019 07:29:53 -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 341A550865; Fri, 24 May 2019 13:29:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id lIo4zlih5dcF; Fri, 24 May 2019 13:29:35 +0200 (CEST) Subject: Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it To: Andy Shevchenko , Mika Westerberg Cc: "open list:SERIAL DRIVERS" , Linux Kernel Mailing List , Andy Shevchenko , Yegor Yefremov , Greg Kroah-Hartman , Giulio Benetti References: <20190524094825.16151-1-sr@denx.de> <20190524102002.GT2781@lahna.fi.intel.com> From: Stefan Roese Message-ID: <287cdcc8-9a8f-4583-8be9-bd1f95936733@denx.de> Date: Fri, 24 May 2019 13:29:34 +0200 MIME-Version: 1.0 In-Reply-To: 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 24.05.19 13:11, Andy Shevchenko wrote: > On Fri, May 24, 2019 at 1:21 PM Mika Westerberg > wrote: >> >> On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote: >>> This patch adds a check for the GPIOs property existence, before the >>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio >>> support is added (2nd patch in this patch series) on x86 platforms using >>> ACPI. >>> >>> Here Mika's comments from 2016-08-09: >>> >>> " >>> I noticed that with v4.8-rc1 serial console of some of our Broxton >>> systems does not work properly anymore. I'm able to see output but input >>> does not work. >>> >>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 >>> ("tty/serial/8250: use mctrl_gpio helpers"). >>> >>> The reason why it fails is that in ACPI we do not have names for GPIOs >>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO >>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs >>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The >>> UART device in Broxton has following (simplified) ACPI description: >>> >>> Device (URT4) >>> { >>> ... >>> Name (_CRS, ResourceTemplate () { >>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>> { >>> 0x003A >>> } >>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, >>> "\\_SB.GPO0", 0x00, ResourceConsumer) >>> { >>> 0x003D >>> } >>> }) >>> >>> In this case it finds the first GPIO (0x003A which happens to be RX pin >>> for that UART), turns it into GPIO which then breaks input for the UART >>> device. This also breaks systems with bluetooth connected to UART (those >>> typically have some GPIOs in their _CRS). >>> >>> Any ideas how to fix this? >>> >>> We cannot just drop the _CRS index lookup fallback because that would >>> break many existing machines out there so maybe we can limit this to >>> only DT enabled machines. Or alternatively probe if the property first >>> exists before trying to acquire the GPIOs (using >>> device_property_present()). >>> " >>> >>> This patch implements the fix suggested by Mika in his statement above. >>> > > We have a board where ASL provides _DSD for CTS and RxD pins. > I'm afraid this won't work on it. With "won't work" you mean, that the GPIO can't be used for modem control in this case in the current implementation (with this patchset)? Or do you mean, that the breakage (input does not work on Broxton systems) will not be solved by this patch? If its the former, then I think that solving this issue is something for a new patch, to support modem-control on such platforms as well (if needed). Please note that this patch is not trying to get modem-control working on such ACPI based systems. Its targeted for device-tree enabled platforms, using the 8250 serial driver, here specifically a MIPS MT7688 based board. And just wants to fix the latter issue mentioned above so that the 8250 modem-control support can be accepted in mainline. > Basically we need to understand the use of the GPIOs in UART. In our > case it's an out-of-band wake up source for UART. > Simply requiring GPIOs to be present is not enough. > > Perhaps property like 'modem-control-gpio-in-use' (this seems a bad > name, given for sake of example). Thanks, Stefan