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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 34584C5517A for ; Tue, 10 Nov 2020 16:01:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A6C8720678 for ; Tue, 10 Nov 2020 16:01:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="om4FOw2Y"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="oQCl64j1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6C8720678 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:In-Reply-To:Subject:To: From:References:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cUyewgZ9pQQYWPfpF0U/tOWEF6Ylr1nRmrKZNidweaE=; b=om4FOw2YECJ7WzhldkkhEwNdz gT0nnn3kL6Um1awZIIqVkyR+/3EYdKCoXZ2kv1Kisi6HVUV7yjALwUF7Pq8nn9H3cRyHDdhG7i6Pu 5NFK8vQ8HuhZL8b9FGlFqXq915/okqnTcOLn5k5ZF72QTHKWbw3R6T4XauBFt6KY+gOlw2bmUjATD nGU0Uv2CGYc511rBXwZiHS9tzT/KlHQ8O5jv9Ej28MLVodX8g308/zca0RNHnIN5IlVaur/Mj6vCc UJwkD9hH4VEO+S2BPp98lxZn9a5Vhq1/uI/eNnxFKRsTLHL6GtJ6S/2Jzv/f9TqKsK+3OaMFXeBZ/ fA/cOO4aQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcW3X-0000yt-1r; Tue, 10 Nov 2020 15:59:39 +0000 Received: from esa6.microchip.iphmx.com ([216.71.154.253]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcW3U-0000xL-G1 for linux-arm-kernel@lists.infradead.org; Tue, 10 Nov 2020 15:59:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1605023976; x=1636559976; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=0N7Na9r2kbBio0hWYqQA7bcLYhDmR5yStTYA7d1YCeA=; b=oQCl64j1nKh8JzN4+zLqG1LHEUqC7fsW9knrZ6kGIsn8yDmBU1YU7PRU 4/vch7qyOv7OHllbVmoqg6TFGqkB03I4S3gmt0LFSCPFmPDZj0tRJMwb7 awrumT0/DWMf8D9KFnUnu2x5ERBgPj7Hn5gdjEM5KfoPLJ/pAY9Fgxn/f Pfjf1+veuMSyz/r9IcxlQnoiZdXLOU4h5jGWx3yk1o7SHIto4FOOEIHgD ByxMrNaMUB439GTmUs+0UQRG18kqcXL2gfizTKmugfd4aQaWV9Y0tU2Wr CcC8x0uyjVpwZHeMvFEEOUVtM4j5irhGBEZMwr1dNKQJWOJtZYCx1DM/I g==; 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 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201110_105936_717372_ADBD2609 X-CRM114-Status: GOOD ( 25.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Alexandre Belloni , Linus Walleij , Linux Kernel Mailing List , Microchip Linux Driver Support , "open list:GPIO SUBSYSTEM" , linux-arm Mailing List , Lars Povlsen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel