Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp985619imm; Tue, 2 Oct 2018 00:16:06 -0700 (PDT) X-Google-Smtp-Source: ACcGV60Tio4cpjX36GnCpyCYCFxhd2X32/cvkFp/ijNngCC2hfDufmj6+u8bZBA1bvpV2yMd2/To X-Received: by 2002:a62:5251:: with SMTP id g78-v6mr1068501pfb.256.1538464566539; Tue, 02 Oct 2018 00:16:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538464566; cv=none; d=google.com; s=arc-20160816; b=V19FA11EFHe0WgvZ8sHk2KSx5zy2eHEjPtSFLi1oLaacq6gyXu6B6xuGUSn7hKcYeC wXFiBY2O1UGTZrn7dozkDCiQgDewrK3KLnXZhjDhXfudkgZHbWCu9OonUbiRLhTmyW7l 7uR9TJFJcl5zO6bFxH6G3/5t32A0DyennsP5CvgFnZDpMBDh/SwAKRobLGjfeoux3HxN uVMDAZKeOaPmBdkrpAhtbYUHqT2F3yyN2z424Pjorwj2X0ua2oZjlsxj/cHgeycfM+C+ 3lmm7LlThOPb8ZL8+VmBE67dRr7kJZnkNr4Ce8y6AH17fu5t0zjd9RvJxYF9jjR9uQ6J xavw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=EmWNADZTKC1ESUoZvuRSxXAvaewf36EagvpJmbk4zmg=; b=Br0MH6iTwT+ovRUV6jBrtzymQuLhXY8QUL98OkyYO6/asoNLmp+M9+Q8dgx0JXKOIs +JI0woeh5SOClo7fboX9K5iXtxT0T3XcirnlZdUXtuc0u3BrB993iyN36BIvRP0/RKwc aiL0lWIfiwXNjg+rbTuHVfPLvqXyf0lgfqSFbBTsQZk+4iK4S4Xg5Muel5Cfsbmw9lML IsUIKMiCwlFf/gyv4rR41nbpTpRdOlQyF8GSYAwu7d24bvYda+DaluJIhiq4oCaP9mJD BgePeU8XcOKUo9yXhYVoYM0Uz9Qgq6ox3S5MpQsMgelIhwYP68MDSDkX7U/yaVBixROL lu1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nCup4HLD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h2-v6si14784191plh.157.2018.10.02.00.15.50; Tue, 02 Oct 2018 00:16:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nCup4HLD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726814AbeJBN5c (ORCPT + 99 others); Tue, 2 Oct 2018 09:57:32 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:45603 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbeJBN5c (ORCPT ); Tue, 2 Oct 2018 09:57:32 -0400 Received: by mail-lj1-f195.google.com with SMTP id x16-v6so764002ljd.12; Tue, 02 Oct 2018 00:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EmWNADZTKC1ESUoZvuRSxXAvaewf36EagvpJmbk4zmg=; b=nCup4HLD8Ui2kudROV8knsjhrT7HCciYYY+Fg8NOHTvPnTbHA1ZZurdI9/Tm9ko4Pv xJAG4YzseKVRVJLt1CsyEUcvO6o2h69pP04U5ONgYvO9VPlMloqtsCRNfqCjU/Dc1VHA P8N5oHze+cy2bW4WFdDmsbEfN/41RGPepgQkNF0HUDQ0A82q9uSvdCJeovGJwzt1VU/8 ME6xwJrSLtrE16/j6JpJMca5a3kTvZeEGxj++p1m2YF/gWULXEd7qEycfzxt1C80tcW9 elZznZl8gmR9j9TecO2Dg3dlShh/3hU5sR7MfZzDWZOHJ5Pn0B1M7TfcrKQ2O7eRBopU +CvQ== 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=EmWNADZTKC1ESUoZvuRSxXAvaewf36EagvpJmbk4zmg=; b=np7TTPGivSu1c3bmnrX48lpeuHoD44FJEAx7fjIxdDDJXzyF5F+0EzYO5uUZCfa5px n0HV6e13m3xEIEjRrMXI++xtlbeWXDMvEkMa1UqPtXR2s9+jqfofjKiwap+mjL3/8xxl TQ9ehPeJ2m3DC+/72DXqHzRvy/7WXFj49XwOHjn8e5O3tKiEk1QBjn0w6EqFFUWih1JV wiOD7GJ1VkmnGSlSaRWLWHzHmcbJYpUJ+c0wTzDEgU11/jeRx9C4Syf+LmBaQjfn6lG5 OZ87n3UjOSN1ttWONiy/bir+OmZ2u4nyfG1VmDkqUz6kj/8NDicyWvBS9m26d8Ki8yx3 eYUg== X-Gm-Message-State: ABuFfogGVWxzlwXYPRHLVWYPR+Z2NCiJVII/qV7rBjFpAZJ9pp34JwqL qiqApKb/2nPL0V+gK/Pj1kNZ+5lt6baEdeXFmlQ= X-Received: by 2002:a2e:921a:: with SMTP id k26-v6mr8467477ljg.163.1538464543139; Tue, 02 Oct 2018 00:15:43 -0700 (PDT) MIME-Version: 1.0 References: <20180921103604.13361-1-ricardo.ribalda@gmail.com> <20180921103604.13361-2-ricardo.ribalda@gmail.com> <153803107307.119890.10052910965015646333@swboyd.mtv.corp.google.com> <3e07cab8-0f3e-7474-8f6d-e6bb16e8f998@codeaurora.org> <5aea282d-6fc9-cd70-cec4-10f28aa819b9@codeaurora.org> In-Reply-To: From: Ricardo Ribalda Delgado Date: Tue, 2 Oct 2018 09:15:26 +0200 Message-ID: Subject: Re: [PATCH v2] gpiolib: Show correct direction from the beginning To: Linus Walleij Cc: Timur Tabi , Jeffrey Hugo , Stephen Boyd , LKML , linux-gpio Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Mon, Oct 1, 2018 at 11:20 PM Linus Walleij wrote: > > On Mon, Oct 1, 2018 at 3:36 PM Ricardo Ribalda Delgado > wrote: > > On Mon, Oct 1, 2018 at 1:54 PM Linus Walleij wrote: > > > On Fri, Sep 28, 2018 at 9:30 PM Ricardo Ribalda Delgado > > > wrote: > > > > > > > How do we proceed from here? Can you fix your driver somehow to > > > > init the valid mask before enabling the gpio? > > > > > > Just include a hunk to the qcom driver reordering this call > > > at the same time. No need to make it separate patches, > > > it need to be tested together anyways. > > > > > > I guess just switch the order of these two: > > > > > > ret = gpiochip_add_data(&pctrl->chip, pctrl); > > > if (ret) { > > > dev_err(pctrl->dev, "Failed register gpiochip\n"); > > > return ret; > > > } > > > > > > ret = msm_gpio_init_valid_mask(chip, pctrl); > > > if (ret) { > > > dev_err(pctrl->dev, "Failed to setup irq valid bits\n"); > > > gpiochip_remove(&pctrl->chip); > > > return ret; > > > } > > > > > > > the problem is that valid_mask is not a long/integer, is a struct that > > needs to be malloced, and is malloc at gpiochip_add_data :( > > I don't get it, but maybe I'm not smart enough. Dont take my job, I am the not smart of the conversation :P > > gpiochip_add_data() doesn't allocate anything, it > just adds a already allocated (or static!) gpio_chip > to the gpiolib subsystem. > Take a look to gpiochip_add_data_with_key() ->gpiochip_init_valid_mask() -> gpiochip->valid_mask = gpiochip_allocate_mask(gpiochip); > In fact I think it is wrong to set up the mask after > calling gpiolob_add_data(), because of exactly the > type of problem you're seeing. I agree, and I believe that the cleaner way would be to add a function pointer that replaces: gpiochip_allocate_mask() bitmap_fill(p, chip->ngpio); with a proper initalization from the driver But as today the only driver that seems to be using valid_mask is msm, so perhaps a hack is something better and then when we have a second driver that requires it we figure out the real requirements. But it is definately your decision ;) > > Don't get confused by the &pctrl->chip > vs just chip variables, it's just some sloppiness. > > Yours, > Linus Walleij Thanks! -- Ricardo Ribalda