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: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing
 software_node connections to sensors on platforms designed for Windows
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc:     linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
        linus.walleij@linaro.org, prabhakar.mahadev-lad.rj@bp.renesas.com,
        heikki.krogerus@linux.intel.com, dmitry.torokhov@gmail.com,
        laurent.pinchart+renesas@ideasonboard.com,
        kieran.bingham+renesas@ideasonboard.com, jacopo+renesas@jmondi.org,
        robh@kernel.org, davem@davemloft.net, linux@rasmusvillemoes.dk,
        andriy.shevchenko@linux.intel.com, sergey.senozhatsky@gmail.com,
        rostedt@goodmis.org, pmladek@suse.com, mchehab@kernel.org,
        tian.shu.qiu@intel.com, bingbu.cao@intel.com,
        sakari.ailus@linux.intel.com, yong.zhi@intel.com,
        rafael@kernel.org, gregkh@linuxfoundation.org, kitakar@gmail.com
References: <20201019225903.14276-1-djrscally@gmail.com>
 <20201019225903.14276-10-djrscally@gmail.com>
 <20201024012411.GT5979@pendragon.ideasonboard.com>
 <d188f8b5-ed3b-f91b-171a-26afeb7d213e@gmail.com>
 <20201024093702.GA3939@pendragon.ideasonboard.com>
 <748d34c3-a146-12fe-22c0-8dfef9006ea0@gmail.com>
 <20201024223628.GG3943@pendragon.ideasonboard.com>
From:   Daniel Scally <djrscally@gmail.com>
Message-ID: <98d1f782-9749-1de7-02d5-da51b57ffaef@gmail.com>
Date:   Sat, 24 Oct 2020 23:50:45 +0100
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: <20201024223628.GG3943@pendragon.ideasonboard.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

Hi Laurent

On 24/10/2020 23:36, Laurent Pinchart wrote:
> Hi Dan,
>
> On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote:
>> On 24/10/2020 10:37, Laurent Pinchart wrote:
>>
>>>>> I wonder if we could avoid depending on the I2C device being created by
>>>>> getting the fwnode from adev, and setting ->secondary manually. adev
>>>>> would need to be passed to get_acpi_ssdb_sensor_data() instead of dev.
>>>> Let me try that; I initially wanted to do
>>>> set_secondary_fwnode(&adev->dev, fwnode) to avoid depending on the I2C
>>>> dev being created but it turns out &adev->dev isn't the same pointer. I
>>>> shall try it and see.
>> Actually, thinking on this further I think maybe we can't avoid that -
>> it's not actually in this patch series but during assigning GPIO
>> resources parsed from PMIC's ACPI node to the sensor, I'm using
>> dev_name() on the i2c dev to pass to .dev_id member of gpiod_lookup_table
> Any chance we can construct the I2C device name from the ACPI device,
> the same way that the ACPI/I2C core does ? It may be a dead end, but if
> we could avoid depending on the I2C device, I think it will make
> initialization easier. I have a feeling that will be difficult though,
> as we'll need the I2C bus number, which won't be readily available.

I'd have to look into how the ACPI/I2C core does it to be confident, but
I think it would be ok. Doesn't look to me like the bus number is
involved; my sensor's device names come through as "i2c-OVTI2680:00";
that's just a prefix tacked on to dev_name(adev->dev). I'm sure there's
something that will stop it being quite so easy, but hopefully not
insurmountable.

> Maybe this calls for extending the gpiod lookup API, but that would then
> likely be something we would build on top. I'm thinking about a way to
> specify the GPIO mapping in the software node, and retrieving it from
> there, the same way this is done for GPIOs in OF-based systems.
Yeah that's an option too; I had had the same thought actually. Probably
an extensive piece of work in its own right though