From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 448FDC5517A for ; Tue, 10 Nov 2020 15:59:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9ED420678 for ; Tue, 10 Nov 2020 15:59:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="NZGhY/q0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731016AbgKJP7c (ORCPT ); Tue, 10 Nov 2020 10:59:32 -0500 Received: from esa6.microchip.iphmx.com ([216.71.154.253]:58662 "EHLO esa6.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729909AbgKJP7b (ORCPT ); Tue, 10 Nov 2020 10:59:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1605023970; x=1636559970; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=0N7Na9r2kbBio0hWYqQA7bcLYhDmR5yStTYA7d1YCeA=; b=NZGhY/q09Wdxl1FcpTN7J8FHhqpUUVPuTSaps2dwspbJph39OWNs8Mj7 slgFiZIH89GuwFmGdXwRqcXrIFmFTcfD9bqhjeTje9GDjrwovOxeqScQl eSgTbmZQtQFsobI9goeqOytA61wwa5MuqPA3IRtnVEqld0/5P8R/0VMag g87LRKNvGu7wFGo4tt88Zxk3tO56uzzyijZz75eGEd3Jwce2mhI1Tjoom ZonOb15/vNWUtZEGeY9xxkb5hmljcJovvGsNKqQZyMn6vr2PQOAIxGRaR Wr87SjJxBRbG2l2FbKxDRmvrCmR48sj5zAt7cnz+GNEXJiOnHRi4BeDVn Q==; IronPort-SDR: hUbx+DnmA6cl3etvUuo+n8XIIKZvweW69dTEplN78vhEypddzFKZlpQbmsWUrvfF8F4o9bnLaF Ugh7zKK0w+Zp1pbC5sUYrx4HTWLoih1y5hKN6WrEKJaDw9EVyHlgp69V2L4mxuzJJhv1MwYaHt Y0GNY57BYcM6ClkBWx0N9blplphtos1P98mbra1/JbofkF52e0WBL8njL1sPpHMPrELt57fCRg Aiz04CEDIShYgHnzAmxu0ofIKK7CINeDuO/Emcjarb2Xs5BHTMmQWqBbz5qOeiQL4GxCyAAxf0 DVo= X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="33098925" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 10 Nov 2020 08:59:30 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 10 Nov 2020 08:59:30 -0700 Received: from soft-dev10.microchip.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3 via Frontend Transport; Tue, 10 Nov 2020 08:59:28 -0700 References: <20201109132643.457932-1-lars.povlsen@microchip.com> <20201109132643.457932-3-lars.povlsen@microchip.com> <20201109143237.GJ1257108@piout.net> <20201109152748.GA1691943@piout.net> User-agent: mu4e 1.2.0; emacs 26.3 From: Lars Povlsen To: Andy Shevchenko CC: Alexandre Belloni , 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 In-Reply-To: Date: Tue, 10 Nov 2020 16:59:12 +0100 Message-ID: <871rh1fbjj.fsf@microchip.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Shevchenko writes: > On Mon, Nov 9, 2020 at 5:27 PM Alexandre Belloni > wrote: >> 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: > > ... > >> > > > > + 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. > > Tell this to plenty of users of old sysfs interface and to libgpiod ones. > If what you are saying had been true, we would have never had the new > ABI for GPIOs. > >> I don't see how your answer >> is relevant here. > > I have an opposite opinion. > >> Did you already check all the call sites from the >> kernel too? > > If you think we have to print a message on each possible error case > (but not always the one) we will get lost in the messages disaster and > dmesg overflow. > It is consumer who should decide if the setting is critical or not to > be printed to user. I think the message is a valid one. I will change it to dev_err_ratelimited() - that should prevent the dmesg flooding. ---Lars -- Lars Povlsen, Microchip