Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <554ebf0a-2304-6fd0-555a-0ce1b4615bf0@theobroma-systems.com>
Date:   Mon, 21 Nov 2022 16:06:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [RFC PATCH 1/7] Input: goodix - fix reset polarity
Content-Language: en-US
To:     Hans de Goede <hdegoede@redhat.com>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc:     Quentin Schulz <foss+kernel@0leil.net>, hadess@hadess.net,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de,
        festevam@gmail.com, linux-imx@nxp.com, wens@csie.org,
        jernej.skrabec@gmail.com, samuel@sholland.org, agross@kernel.org,
        andersson@kernel.org, konrad.dybcio@somainline.org,
        heiko@sntech.de, linux-input@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        arm-mail-list <linux-arm-kernel@lists.infradead.org>,
        linux-sunxi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>
References: <20221103-upstream-goodix-reset-v1-0-87b49ae589f1@theobroma-systems.com>
 <20221103-upstream-goodix-reset-v1-1-87b49ae589f1@theobroma-systems.com>
 <1fa371bd-78a6-bb7c-4692-1d8132ec2ab1@redhat.com>
 <Y2P7SsPa04975Rkm@google.com>
 <692fd16e-4183-d58d-802e-2b83563aee4b@redhat.com>
 <267de96a-0129-a97d-9bf6-e1001b422a1a@theobroma-systems.com>
 <16c7f876-102c-60e1-4a81-3378b6c726fb@redhat.com>
From:   Quentin Schulz <quentin.schulz@theobroma-systems.com>
In-Reply-To: <16c7f876-102c-60e1-4a81-3378b6c726fb@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cDdVSEc5SkZqV2RBbTNRNkdnbStEUnFnSERpTys5YURZQ2RnM3Y0NVRMMkt5?=
 =?utf-8?B?alo1Z0I1VDhzSzBYUlFTR0ZoNXlLM1ZURno3S2NCb2RzMlRURHRMMXh0ZHlF?=
 =?utf-8?B?QXNEajUvT285L2g5NXRaNXJuVG1PQXo3TTRXMllDT3FqV0laNis1VlVoTFhv?=
 =?utf-8?B?Y0VJRVN3S3NmR3RUd1hnT3JoMk5XSWx5SC9MNmFPdVZTdzd2dnVZdzJOdHBK?=
 =?utf-8?B?MG9UZWxrU3J0SlZFTmZCV0gvRUw4Qi9oQVIyM1FHOGFhTVJBbm5zUWw2OXVp?=
 =?utf-8?B?UjVPR2h3dWZtNnZpN24zVS83bmZzVVdzaW5wd0NXTW95UCtUUy9xWEF5TWQz?=
 =?utf-8?B?c3hVaFZ6K1pVS2p3blM0TVRtQ1huR2Fwb0FxcUNvZERXVlpFQUtLWkNJVUVC?=
 =?utf-8?B?Sm1STTYzWGRCQWc3aHFnenJTbHYvdjU0Nm9wZTFUK0dOQndiRTAzSGZpN2dH?=
 =?utf-8?B?VWVZQ29xSUZLUE83RldWMDhiKzJHYnViUythcExrWTAxQXd5ZG4vdWNlNFUr?=
 =?utf-8?B?SEI2ZUxzN0U3RWFHemsyM1pyQy9QcWNIYkNEVHp2RGlYdUVyeWREMjhRK2Nx?=
 =?utf-8?B?Ymo0ZlZvRnZ2L0NmbGdMbTVCM0xzTXVwbTh5ZHhNYlliSVFlREtqUEFKd1lV?=
 =?utf-8?B?QnNlcnBQV1hjcnJyODQ3SlF1NUFNT0JPam41aDBkcjJTdlZYVVQ0NC9BeEZW?=
 =?utf-8?B?SkZ0dVQ3K3dxUkRXUWUxYm9vcUZEaFJoTmhxL0tDSm1IUG8rYkUwRWx5ZzUx?=
 =?utf-8?B?VUtsVnBhZWp3NkFuVXdBZmlnS3NKT2FaRnlvRVBHSEV0ZXdmWFEvS0JHRC91?=
 =?utf-8?B?aTJRNVAxWXczNW92dTNoUnFlRVV4TlJxZFVkRGRTQ1JTb2tkd0NqQlk1U0ZN?=
 =?utf-8?B?RnE0d2JxTUFNQkkrK01OdjhsWWxkQVZMOUpnOVZ4bm0yaHQ1NEV4bXlMTjl4?=
 =?utf-8?B?MkI1Z2JXVmpNblVmd3BkMjM1WTlYOFdEakFDN0JVN1Z4dk52K1RCWE5hd1N4?=
 =?utf-8?B?KzI1RmVONmJRZmFWVzk5cEFzSkdDakR6ZWV6WnhmWGxMRkFZY2cxeVF6aG5I?=
 =?utf-8?B?dExuSVlVY3Jaa2VibTNnZzFwTS90TmIzRWNzQVhXSkdjZFpuUmV2OE5yV1hu?=
 =?utf-8?B?ZVJxb2xuSlZRZ1V2emhBOXc0QlpyVlpWRmp5ZUg0NGJ3VlNLRGhTRkJ4NVZp?=
 =?utf-8?B?VisxTWx3TnZEUXN3d3J4ZWxYV3NCMWhuSWR5VDNabjVSakppR0p4UEFOMVFa?=
 =?utf-8?B?Ny9zQytER0FrWDd6WThpemFJa0cyRzF0b2lKTFF5SURtU0NURVNsZS9pWFpS?=
 =?utf-8?B?d2VyN1MvNWx2eWx1MWlTb29EWHI4d0I2N2hRZ3BBRHZIRjZLdzlnQ3lqMDFR?=
 =?utf-8?B?bys5OHE4d3lVMW5rR1RRUkVZclJyVmZIbXRsZGRjMktjN3Z0ZUU3Zk1Pb2VH?=
 =?utf-8?B?YWtJSUZSTjA1TkZ2M1Q4c1F5UHRTb2FpU2tIQlpRNFpCZXlVOTFaVU1SU0Zv?=
 =?utf-8?B?ZDVzVlk4cmVSQ1N4bUNXSHV2N0tPY09DcTBDaVhOY2JYSEdML0ZKSWhiQ0tM?=
 =?utf-8?B?cXdhVFdMMktobUVFVDJ4Vi9vbUhzc1dMTHlaeHNuWFFOUzE4Y2ZrNzJLbGhk?=
 =?utf-8?B?RGFMaWxacVIxa1hxeDZVcHFVUUJQR2IzVkptSnd2NFhPcDNtV0c5OFhxcmZw?=
 =?utf-8?B?TjdDbzMvdnY0Z08rNkFXQ0hjWXQrMVBiR1dmejZXN1N3aFZ2NEgyN1hGSDRt?=
 =?utf-8?B?dVZNbWlKdnd4a0cvbDg3ektOdVRDRFNuQ2c3R1JTeDUrWXRUSHFMYy9HSFJF?=
 =?utf-8?B?UDdUY1NmcVE0TEwvMUFLTmh3eGt0YkZjWUgvTnVRemFrdHE2VXdMNm5HWnRP?=
 =?utf-8?B?VUxPWFQwUndONlRZZVlSNXJHbXEzQ3JVT3RFVFJtWVM1V3FpS2JtSjJqd1Jh?=
 =?utf-8?B?S1RmRTJ1bFdXVnVHazRleXcvQ1I1T2xMa0x3TWEyaTlCNkRWT1RPS2JHbWVn?=
 =?utf-8?B?Uk9IZlVsQnJ4Y0RmN1ZQU1IxQklTVzByVnFGbXFxd3VpMStRYWQrcElMd3Qr?=
 =?utf-8?B?M1Y4UTVramc1YVA3Q0NveitOOUd4TGJ4ekFXcmoxaVpEaUpwQzZyTTkzL25u?=
 =?utf-8?B?eVRVWFdyWUlnU0RQcUNweVFtcnBpZUVUQ0RINHRnenBwQWVTWHVLQ1dndGZR?=
 =?utf-8?Q?Z1q0pj/3fEVoP7Mix2iExqo=3D?=
X-OriginatorOrg: theobroma-systems.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c76cd158-6702-4f2e-52e1-08dacbd1f4c7
X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8536.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2022 15:06:24.3371
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5e0e1b52-21b5-4e7b-83bb-514ec460677e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yxXXLmFaYoCRjGVAMOBcAUfzK6kj/68zH8cCiFNMnG9IcH/topCPvDzAqEVwkkfOGKzuaS56N6x5Hn8oooyAszxl4+y5exXakVh23yZtmKTi/iaHhi+53sUPrVl+GhSW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR04MB7828
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Hans,

Sorry for the delay.

On 11/3/22 20:28, Hans de Goede wrote:
[...]
> Ok, so I've been taking a look at how we can invert the 'x' passed
> to the gpiod_direction_output(ts->gpiod_rst, x) calls and not break
> things with ACPI.
> 
> The rst pin is looked up through a acpi_gpio_mapping which
> contains acpi_gpio_params as one of the per pin parameters
> and that does have an active_low flag.
> 

I just read the kernel docs about GPIO and ACPI and I'm not entirely 
sure this is always 100% safe to do:

https://docs.kernel.org/firmware-guide/acpi/gpio-properties.html

Specifically:
"""
The GpioIo() resource unfortunately doesn't explicitly provide an 
initial state of the output pin which driver should use during its 
initialization.

Linux tries to use common sense here and derives the state from the bias 
and polarity settings. The table below shows the expectations:

=========  =============  ==============
Pull Bias     Polarity     Requested...
=========  =============  ==============
Implicit     x            AS IS (assumed firmware configured for us)
Explicit     x (no _DSD)  as Pull Bias (Up == High, Down == Low),
                           assuming non-active (Polarity = !Pull Bias)
Down         Low          as low, assuming active
Down         High         as low, assuming non-active
Up           Low          as high, assuming non-active
Up           High         as high, assuming active
=========  =============  ==============
"""

But since we actually override this during our devm_gpiod_get_optional 
by passing forcing the flag to be either GPIOD_IN or GPIOD_ASIS, we 
should be good for this driver IIUC?

Thanks for the pointers,
Cheers,
Quentin