Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3292394pxb; Mon, 9 Nov 2020 07:31:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJx819cKdN6Bxoa4ynb6ekN6492xIX6IK7YdPAQeFzOtV7fzAeMsGDVNnSiba8RifIBjnNSb X-Received: by 2002:a05:6402:236e:: with SMTP id a14mr16255458eda.103.1604935914089; Mon, 09 Nov 2020 07:31:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604935914; cv=none; d=google.com; s=arc-20160816; b=PnqIQBPRbX8atHWP4S5kjNfQ67qD3ir+bdmcHbUYuN9B4d7InoXnyRKfnCHWxdJjYe taA9/W29h+usKP0MU1wi/4mtWGdzQoXM4iqFF11GmWdwCDFhCIIkvoMFa28+COsm9TY+ tKCXdxn2qXIju1/eJTA4R/rpmj2kDudiQENt2qhb86i5GwthVXHRuc+DH6Wwr9/J8rF/ phEmIyAT2SnFhKa5KXcdtey+5gZ/pPybRr4b7p8YSgZVy7WKLMjmQXmLOqxT2IKbbkIl Y3MIhdD8hNyCBuZ7AO3Yr7aj82x65H3PlAyYCiP9QccloNiaFtq5456/lnwp63kv1QgJ kpQg== 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:date; bh=cISqohf6NjjD8Xc9wIsWSGGwgH8kE7g0pP0cId7inAM=; b=JQSCC9nYBcr8+3Wy/t80tbvQuJnnf8Xr/NMj6rVRkAg4wH0YJusaVc0I+jFT767Ds6 pM5gqIliNryXahCPb5LAnV/Zzyr4P/gxwBCC2jTzemXKTy0xGfWAhs9hSQIJbGzV1X4f 2HRbT4HtBBQI1k4COT8losG7yPcTiRAeV6VbHi6VAg5sQW62ifBj/LrrcQ8QgSl5i0tU Q8n+0D6nIxlwrWK1E3xSthFlJuaIVev6LwpYPj8d1jqKPouUXgwFNGgs3DUv9qjH3FM5 R2GmxiY4+E+ojlVQTXYcZdwi0IzYa0EvAcPNZgDus+sZiV7w8cJ8BW0Snmck3Niu+gMC I8xA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s17si7267241ejf.122.2020.11.09.07.31.30; Mon, 09 Nov 2020 07:31:54 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731645AbgKIP1w (ORCPT + 99 others); Mon, 9 Nov 2020 10:27:52 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:53527 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729776AbgKIP1v (ORCPT ); Mon, 9 Nov 2020 10:27:51 -0500 X-Originating-IP: 86.194.74.19 Received: from localhost (lfbn-lyo-1-997-19.w86-194.abo.wanadoo.fr [86.194.74.19]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 436A7C000E; Mon, 9 Nov 2020 15:27:49 +0000 (UTC) Date: Mon, 9 Nov 2020 16:27:48 +0100 From: Alexandre Belloni To: Andy Shevchenko Cc: Lars Povlsen , Linus Walleij , Microchip Linux Driver Support , devicetree , "open list:GPIO SUBSYSTEM" , linux-arm Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH v8 2/3] pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO Message-ID: <20201109152748.GA1691943@piout.net> References: <20201109132643.457932-1-lars.povlsen@microchip.com> <20201109132643.457932-3-lars.povlsen@microchip.com> <20201109143237.GJ1257108@piout.net> 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 09/11/2020 17:16:49+0200, Andy Shevchenko wrote: > On Mon, Nov 9, 2020 at 4:32 PM Alexandre Belloni > wrote: > > On 09/11/2020 16:17:40+0200, Andy Shevchenko wrote: > > > > + if (input != bank->is_input) { > > > > > > > + dev_err(pctldev->dev, "Pin %d direction as %s is not possible\n", > > > > + pin, input ? "input" : "output"); > > > > > > Do we need this noise? Isn't user space getting a proper error code as > > > per doc and can handle this? > > > > Why would userspace get the error code? > > Huh?! Why it shouldn't. How will users know if they are doing something wrong? > > > Userspace should never have to > > handle gpios directly or you are doing something wrong. > > This is true, but check how error codes are propagated to the user space. > your point is to remove an error message because the error may be propagated to userspace. My point is that userspace should never use gpios and the kernel has to be the consumer. I don't see how your answer is relevant here. Did you already check all the call sites from the kernel too? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com