Re: [RFC PATCH v3 0/9] Add functionality to ipu3-cio2 driver allowing software_node connections to sensors on platforms designed for Windows

From: Daniel Scally
Date: Wed Oct 21 2020 - 16:59:14 EST


On 20/10/2020 14:38, Rafael J. Wysocki wrote:
> [Fix the Linus Walleij's address.]
Thanks - much appreciated
> On Tue, Oct 20, 2020 at 12:59 AM Daniel Scally <djrscally@xxxxxxxxx> wrote:
>> Hello all
>>
>> This series adds support to the ipu3-cio2 driver for fwnode connections
>> between cio2 and sensors to be defined via software_nodes. The final patch
>> in the series deals wholly with those changes - the preceding patches are
>> either supporting changes to accommodate that or incidental fixes along
>> the way:
>>
>> 1/9 adds a function to drivers/base/swnode.c unwinding arrays of software
>> nodes in reverse order
>>
>> 2/9 uses that function in lib/test_printf.c
>>
>> 3/9 fixes what seems to me to be a bug in the existing swnode.c code in
>> that software_node_get_next_child() does not increase the refcount of the
>> returned node (in contrast to, for example, of_get_next_child_node() which
>> does increase the count)
>>
>> 4/9 adds the fwnode_graph*() family of functions to the software_node
>> implementation
>>
>> 5/9 adds a T: entry to MAINTAINERS for the ipu3-cio2 driver
>>
>> 6/9 renames the ipu3-cio2.c file to ipu3-cio2-main.c and fixes Makefile
>> to accommodate that change
>>
>> 7/9 alters the ipu3-cio2 driver to check if the pci_dev's fwnode is a
>> software_node and pass flags to fwnode_graph_get_endpoint_by_id() if so
>>
>> 8/9 alters match_fwnode() in v4l2-async.c to additionally try to match on
>> a fwnode_handle's secondary if the primary doesn't match
>>
>> 9/9 alters the ipu3-cio2 driver to do the actual building of software_node
>> connections between the sensor devices and the cio2 device.
>>
>> This is still not ready for integration - hence the RFC label - as there
>> is ongoing work to extend the ipu3-cio2 driver further to parse ACPI
>> to discover resources such as regulators and GPIOs that are defined there
>> in unusual ways and map them to the sensor devices so that their drivers
>> can consume them transparently through the usual frameworks. Given this
>> has changed quite extensively from v2 though, I wanted to submit it for
>> feedback at this point in case it needs further large scale change.
> I would appreciate it if you posted the next version of this series
> (all patches) to linux-acpi@xxxxxxxxxxxxxxx for easier review.
>
> Thanks!
Sure thing, I'll make sure to add that list to next version