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.7 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,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 1FDBDC433E0 for ; Tue, 2 Feb 2021 19:26:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0D2360295 for ; Tue, 2 Feb 2021 19:26:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239637AbhBBT0A (ORCPT ); Tue, 2 Feb 2021 14:26:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238730AbhBBTW2 (ORCPT ); Tue, 2 Feb 2021 14:22:28 -0500 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC397C061786 for ; Tue, 2 Feb 2021 11:21:47 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id f2so25287706ljp.11 for ; Tue, 02 Feb 2021 11:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ea7rDE3iubBKRZgFdP9Rs4rz7Zn8SR/ombh7E1ZoYnk=; b=J8Axea178cTpmY5ApnnZ0gODAQh0DhK4vGyffddZPoBBxGiMvXjdaEl9zpqY4k7UVW 1H6Krn0JLJHIYornslY8vJtUd1GmtvwloJvdE6OmGt78ckvZWEYagNaMnka4KwiqsALX p98ovUQZrr2gPQX1MuD5RkSNZH70tu/cXQ1CYFcrpacO4AkqPBTJrec+i+rKfBKKtgUo EfP08CcascMJosb1AqjjxPWRA8b4q9Khfhhz1+HFVqmpLWWnMoHn+U37eDRiaATR06Le 4G7YSj1JK49cpQpKFWch/FnQrDdQrlT3wQZzekvOVMOkaP3vZd6Jz/vk6lPc4AZXt08H tLVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ea7rDE3iubBKRZgFdP9Rs4rz7Zn8SR/ombh7E1ZoYnk=; b=Ax314/9JUJEmacyTusazgWbp05AuezXoWiTi2DQZhyisgKYhJlPvyc3r6vGUJCdzzn kFQ1c2aJKaXKWeX5bFNFtBoGQXjZhV9EMWIJAHnOfI6eaOdgXi+4xUQWwN0vtT2mvFO3 O23uIvBoca0/M24kxsRDI1xv3TxiVNXIgVMP7g2cuq0DcJNMC+iedU8rgcHumJJlUae4 UnBQsnMm35srtbI/RoAJqr6SwFBvYRkaZLqmPIcNMqI687n2DCUhI8wiIxlZ9tBCg8fB 8GfFA3hqIvIA10b/G3rQGDgkUUM+L2D3B5xA3C0kgjTKuoXkQ046RFIRJNERiLSjSOXe YBQw== X-Gm-Message-State: AOAM5337zJOeinI6t0MqClnjEd4PzEc0GxrIE8X7POIZn29X5H6TmSDU 0J8aEqysCaMveXHaedjQ62Jou1s310MNwEUQ2Lp2gQ== X-Google-Smtp-Source: ABdhPJxRPks8UrhrUryzSURHvOWhpqZoQrctb9pBOLnd5Y8LMXB8jGBR2CbBmqxTq5nq+iE7z6wIkLro9xYZvBzXl24= X-Received: by 2002:a2e:9ec3:: with SMTP id h3mr13841334ljk.200.1612293705742; Tue, 02 Feb 2021 11:21:45 -0800 (PST) MIME-Version: 1.0 References: <20210128153601.153126-1-alban.bedel@aerq.com> <93036ef781d20df4c6017178cc545702bd0f42bc.camel@aerq.com> In-Reply-To: <93036ef781d20df4c6017178cc545702bd0f42bc.camel@aerq.com> From: Linus Walleij Date: Tue, 2 Feb 2021 20:21:34 +0100 Message-ID: Subject: Re: [PATCH] gpio: pca953x: add support for open drain pins on PCAL6524 To: "Bedel, Alban" Cc: "linux-gpio@vger.kernel.org" , "bgolaszewski@baylibre.com" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2021 at 6:45 PM Bedel, Alban wrote: > On Tue, 2021-02-02 at 14:57 +0100, Linus Walleij wrote: > > > + if (out_conf & BIT(offset / BANK_SZ)) > > > > I suppose this could be written if (out_conf & mask)? > > No, the mask in ODENn is per bank (group of 8 pins) and not per pin. Ah I see it now (confused % for / ...) > > The datasheet says: > > > > "If the ODENx bit is set at logic 0 (push-pull), any bit set to > > logic 1 > > in the IOCRx register will reverse the output state of that pin > > only > > to open-drain. When ODENx bit is set at logic 1 (open-drain), a > > logic 1 in IOCRx will set that pin to push-pull." > > > > So your logic is accounting for the fact that someone go and set > > one of the bits in ODENx to 1, but aren't they all by default set > > to zero (or should be programmed by the driver to zero) > > so that you can control open drain individually here by simply > > setting the corresponding bit to 1 for open drain and 0 for > > push-pull? > > Yes the ODENx bits are 0 by default, but the bootloader might have > changed them for example. Currently the driver doesn't do any reset so > I think it make sense to correctly handle this case as it doesn't bring > that much extra complexity. Hm. I guess you're right if that is the style of the driver overall (don't touch bootloader/reset defaults). We don't use that style for interrupt registers because we don't want interrupts to randomly fire, instead we usually disable them all so the driver and Linux keeps track on what is enabled. But for bias etc, I guess it is OK. But consider the option of just writing 0 into all the ODENx registers at probe(). I'm not gonna complain if you really want it like this though. Yours, Linus Walleij