Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v3 5/6] platform/x86: Add intel_skl_int3472 driver
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Tomasz Figa <tfiga@chromium.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Rajmohan Mani <rajmohan.mani@intel.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Len Brown <lenb@kernel.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Wolfram Sang <wsa@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        kieran.bingham+renesas@ideasonboard.com,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Mark Gross <mgross@linux.intel.com>,
        Maximilian Luz <luzmaximilian@gmail.com>,
        Robert Moore <robert.moore@intel.com>,
        Erik Kaneda <erik.kaneda@intel.com>, me@fabwu.ch,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        linux-i2c <linux-i2c@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>,
        devel@acpica.org
References: <20210222130735.1313443-1-djrscally@gmail.com>
 <20210222130735.1313443-6-djrscally@gmail.com>
 <CAHp75Vd2Dc2Poq7VNRXRT-0VjkYdEFY2WKpz8fWpAQViQRO4jA@mail.gmail.com>
 <534849f6-c7b5-19b0-a09f-cd410cde93bd@gmail.com>
 <YDTuldAG9FB8+RAd@smile.fi.intel.com>
From:   Daniel Scally <djrscally@gmail.com>
Message-ID: <febc7af6-96ee-a5a0-f0c9-6e7f89908535@gmail.com>
Date:   Tue, 23 Feb 2021 13:06:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YDTuldAG9FB8+RAd@smile.fi.intel.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 23/02/2021 12:01, Andy Shevchenko wrote:
>>>> +       if (ares->type != ACPI_RESOURCE_TYPE_GPIO ||
>>>> +           ares->data.gpio.connection_type != ACPI_RESOURCE_GPIO_TYPE_IO)
>>>> +               return 1; /* Deliberately positive so parsing continues */
>>> I don't like to lose control over ACPI_RESOURCE_TYPE_GPIO, i.e.
>>> spreading it over kernel code (yes, I know about one existing TS
>>> case).
>>> Consider to provide a helper in analogue to acpi_gpio_get_irq_resource().
>> Sure, but I probably name it acpi_gpio_is_io_resource() - a function
>> named "get" which returns a bool seems a bit funny to me.
> But don't you need the resource itself?
>
> You may extract and check resource at the same time as
> acpi_gpio_get_irq_resource() does.


Oh! Reading comprehension fail; I didn't notice it was returning the
pointer through agpio; you're right of course.

>
> ...
>
>>>> +       struct int3472_discrete_device *int3472 = platform_get_drvdata(pdev);
>>>> +       if (int3472->gpios.dev_id)
>>>> +               gpiod_remove_lookup_table(&int3472->gpios);
>>> gpiod_remove_lookup_table() is now NULL-aware.
>>> But in any case I guess you don't need the above check.
>> Sorry; forgot to call out that I didn't follow that suggestion;
>> int3472->gpios is a _struct_ rather than a pointer, so &int3472->gpios
>> won't be NULL, even if I haven't filled anything in to there yet because
>> it failed before it got to that point. So, not sure that it quite works
>> there.
> I think if you initialize the ->list member you can remove without check.


I'll give that a try - thanks

>