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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 1485AC47080 for ; Sun, 23 May 2021 22:22:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0C8F60FDA for ; Sun, 23 May 2021 22:22:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231979AbhEWWXD (ORCPT ); Sun, 23 May 2021 18:23:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232016AbhEWWXC (ORCPT ); Sun, 23 May 2021 18:23:02 -0400 Received: from polaris.svanheule.net (polaris.svanheule.net [IPv6:2a00:c98:2060:a004:1::200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BEFDC061574 for ; Sun, 23 May 2021 15:21:35 -0700 (PDT) Received: from [IPv6:2a02:a03f:eafb:ee01:bd37:7535:eb00:6fa] (unknown [IPv6:2a02:a03f:eafb:ee01:bd37:7535:eb00:6fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sander@svanheule.net) by polaris.svanheule.net (Postfix) with ESMTPSA id 08A33202A44; Mon, 24 May 2021 00:21:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1621808493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jBeGHDP0Tz5eoqu47A7M4vJJjH5RoK+PyK940cMviYU=; b=IUDJSVE1BeBfPkWGNB/a/KeGc0ZKZoSeTrKZ782c9nTSun9G+D/R/rqpTQqcZ25m2+qbCF GBW4ptVnHawMdA80G6vXGXiCL6tk4CfTKE/p2rYA5wHke+2UCUiiQbS3NinC6ZnO29lWUU k/srPeIaRJQn04OwlA5FfcptgMgwLdp2ZJOZPZBMHaq8SwRVFnhuV9pJWab2jUIArYN6uu EhDByWCunGJ0wI9jbAQcjm6UcsMGdM2qfgfTsfV6MzJRE8af/wcmWH3BkktZV7rpqH7FED S/UxVKqVVTVMWHIZj6HaWEm3CK0nWuXg43ECZNj++1m/DBb5tjb1NzVcOfabog== Message-ID: <7536875f01b0420acb88de1ea3a48c31fdb26962.camel@svanheule.net> Subject: Re: [PATCH v2 2/7] gpio: regmap: Add configurable dir/value order From: Sander Vanheule To: Andrew Lunn Cc: Pavel Machek , Rob Herring , Lee Jones , Mark Brown , Greg Kroah-Hartman , "Rafael J . Wysocki" , Michael Walle , Linus Walleij , Bartosz Golaszewski , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, Andy Shevchenko , linux-kernel@vger.kernel.org Date: Mon, 24 May 2021 00:21:29 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org Hi Adrew, On Tue, 2021-05-18 at 03:40 +0200, Andrew Lunn wrote: > On Mon, May 17, 2021 at 09:28:04PM +0200, Sander Vanheule wrote: > > GPIO chips may not support setting the output value when a pin is > > configured as an input > > Could you describe what happens with the hardware you are playing > with. Not being able to do this means you will get glitches when > enabling the output so you should not use these GPIOs with bit banging > busses like i2c. As I reported earlier, using value-before-direction breaks the GPIO driven LEDs on one of my devices. I've tried to use another device to test if I could reproduce this. Using the gpioset and gpioget utilities, I can't seem to reproduce this however. Whether I enable the (new) quirk or not, doesn't seem to make any difference. The documentation we have on this chip is quite scarce, so I'm unaware of different chip revisions, or how I would distinguish between revisions. As far as I can see, Realtek's code (present in the GPL archives we got from some vendors) set the pin direction before setting the value. For now, I've made the implementation so that the quirk is always applied. Like the behaviour that is implicit in the origal code. If prefered, I could also supply a separate devicetree compatible or extra devictree flag. Regarding bit banged I2C, glitches may not actually be an issue. If a pull-up resistor is used for HIGH values, and an open drain for LOW values, the GPIO pin doesn't actually have to change value, only direction (IN for HIGH, OUT for LOW). A configuration like this would perhaps glitch once on the initial OUT-LOW configuration. Like I mentioned, bit banged I2C is frequently used in ethernet switches with these chips to talk to SFP modules. Best, Sander