lkml.org 
[lkml]   [2020]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [PATCH 13/18] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
Date
Hi Laurent - thanks for reviewing

On 30/11/2020 17:09, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, Nov 30, 2020 at 01:31:24PM +0000, Daniel Scally wrote:
>> Currently on platforms designed for Windows, connections between CIO2 and
>> sensors are not properly defined in DSDT. This patch extends the ipu3-cio2
>> driver to compensate by building software_node connections, parsing the
>> connection properties from the sensor's SSDB buffer.
>>
>> Suggested-by: Jordan Hand <jorhand@linux.microsoft.com>
>> Signed-off-by: Daniel Scally <djrscally@gmail.com>
>> ---
>> Changes since RFC v3:
>>
>> - Removed almost all global variables, dynamically allocated
>> the cio2_bridge structure, plus a bunch of associated changes
>> like
>> - Added a new function to ipu3-cio2-main.c to check for an
>> existing fwnode_graph before calling cio2_bridge_init()
>> - Prefixed cio2_bridge_ to any variables and functions that
>> lacked it
>> - Assigned the new fwnode directly to the sensor's ACPI device
>> fwnode as secondary. This removes the requirement to delay until
>> the I2C devices are instantiated before ipu3-cio2 can probe, but
>> it has a side effect, which is that those devices then grab a ref
>> to the new software_node. This effectively prevents us from
>> unloading the driver, because we can't free the memory that they
>> live in whilst the device holds a reference to them. The work
>> around at the moment is to _not_ unregister the software_nodes
>> when ipu3-cio2 is unloaded; this becomes a one-time 'patch', that
>> is simply skipped if the module is reloaded.
>> - Moved the sensor's SSDB struct to be a member of cio2_sensor
>> - Replaced ints with unsigned ints where appropriate
>> - Iterated over all ACPI devices of a matching _HID rather than
>> just the first to ensure we handle a device with multiple sensors
>> of the same model.
>>
>> MAINTAINERS | 1 +
>> drivers/media/pci/intel/ipu3/Kconfig | 18 ++
>> drivers/media/pci/intel/ipu3/Makefile | 1 +
>> drivers/media/pci/intel/ipu3/cio2-bridge.c | 260 ++++++++++++++++++
>> drivers/media/pci/intel/ipu3/cio2-bridge.h | 108 ++++++++
>> drivers/media/pci/intel/ipu3/ipu3-cio2-main.c | 27 ++
>> drivers/media/pci/intel/ipu3/ipu3-cio2.h | 6 +
>> 7 files changed, 421 insertions(+)
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
>> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9702b886d6a4..188559a0a610 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8927,6 +8927,7 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
>> M: Yong Zhi <yong.zhi@intel.com>
>> M: Sakari Ailus <sakari.ailus@linux.intel.com>
>> M: Bingbu Cao <bingbu.cao@intel.com>
>> +M: Dan Scally <djrscally@gmail.com>
>> R: Tianshu Qiu <tian.shu.qiu@intel.com>
>> L: linux-media@vger.kernel.org
>> S: Maintained
>> diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig
>> index 82d7f17e6a02..2b3350d042be 100644
>> --- a/drivers/media/pci/intel/ipu3/Kconfig
>> +++ b/drivers/media/pci/intel/ipu3/Kconfig
>> @@ -16,3 +16,21 @@ config VIDEO_IPU3_CIO2
>> Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
>> connected camera.
>> The module will be called ipu3-cio2.
>> +
>> +config CIO2_BRIDGE
>> + bool "IPU3 CIO2 Sensors Bridge"
>> + depends on VIDEO_IPU3_CIO2
>> + help
>> + This extension provides an API for the ipu3-cio2 driver to create
>> + connections to cameras that are hidden in SSDB buffer in ACPI. It
>> + can be used to enable support for cameras in detachable / hybrid
>> + devices that ship with Windows.
>> +
>> + Say Y here if your device is a detachable / hybrid laptop that comes
>> + with Windows installed by the OEM, for example:
>> +
>> + - Microsoft Surface models (except Surface Pro 3)
>> + - The Lenovo Miix line (for example the 510, 520, 710 and 720)
>> + - Dell 7285
>> +
>> + If in doubt, say N here.
>> diff --git a/drivers/media/pci/intel/ipu3/Makefile b/drivers/media/pci/intel/ipu3/Makefile
>> index 429d516452e4..933777e6ea8a 100644
>> --- a/drivers/media/pci/intel/ipu3/Makefile
>> +++ b/drivers/media/pci/intel/ipu3/Makefile
>> @@ -2,3 +2,4 @@
>> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>>
>> ipu3-cio2-y += ipu3-cio2-main.o
>> +ipu3-cio2-$(CONFIG_CIO2_BRIDGE) += cio2-bridge.o
>> diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c b/drivers/media/pci/intel/ipu3/cio2-bridge.c
>> new file mode 100644
>> index 000000000000..fd3f8ba07274
>> --- /dev/null
>> +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c
>> @@ -0,0 +1,260 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Author: Dan Scally <djrscally@gmail.com> */
>
> Could you please add a blank line here ?

Yes
>> +#include <linux/acpi.h>
>> +#include <linux/device.h>
>> +#include <linux/i2c.h>
>
> Is this header needed ?
>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>
> And this one ?
>
>> +#include <linux/pci.h>
>> +#include <linux/property.h>
>> +#include <media/v4l2-subdev.h>
>
> And this one ?

Ah yes - bit sloppy, they're orphaned from earlier versions, sorry about
that.

>> +
>> +#include "cio2-bridge.h"
>> +
>> +/*
>> + * Extend this array with ACPI Hardware ID's of devices known to be working.
>> + * Do not add a HID for a sensor that is not actually supported.
>> + */
>> +static const char * const cio2_supported_devices[] = {
>
> Maybe cio2_supported_sensors ?

Sure

>> + "INT33BE",
>> + "OVTI2680",
>> +};
>> +
>> +static int cio2_bridge_read_acpi_buffer(struct acpi_device *adev, char *id,
>> + void *data, u32 size)
>> +{
>> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
>> + union acpi_object *obj;
>> + acpi_status status;
>> + int ret;
>> +
>> + status = acpi_evaluate_object(adev->handle, id, NULL, &buffer);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + obj = buffer.pointer;
>> + if (!obj) {
>> + dev_err(&adev->dev, "Couldn't locate ACPI buffer\n");
>> + return -ENODEV;
>> + }
>> +
>> + if (obj->type != ACPI_TYPE_BUFFER) {
>> + dev_err(&adev->dev, "Not an ACPI buffer\n");
>> + ret = -ENODEV;
>> + goto out_free_buff;
>> + }
>> +
>> + if (obj->buffer.length > size) {
>> + dev_err(&adev->dev, "Given buffer is too small\n");
>> + ret = -EINVAL;
>> + goto out_free_buff;
>> + }
>> +
>> + memcpy(data, obj->buffer.pointer, obj->buffer.length);
>> + ret = obj->buffer.length;
>> +
>> +out_free_buff:
>> + kfree(buffer.pointer);
>> + return ret;
>> +}
>> +
>> +static void cio2_bridge_init_property_names(struct cio2_sensor *sensor)
>> +{
>> + strcpy(sensor->prop_names.clock_frequency, "clock-frequency");
>> + strcpy(sensor->prop_names.rotation, "rotation");
>> + strcpy(sensor->prop_names.bus_type, "bus-type");
>> + strcpy(sensor->prop_names.data_lanes, "data-lanes");
>> + strcpy(sensor->prop_names.remote_endpoint, "remote-endpoint");
>
> This is a bit fragile, as there's no len check. How about the following
> ?
> static const struct cio2_property_names prop_names = {
> .clock_frequency = "clock-frequency",
> .rotation = "rotation",
> .bus_type = "bus-type",
> .data_lanes = "data-lanes",
> .remote_endpoint = "remote-endpoint",
> };
>
> static void cio2_bridge_init_property_names(struct cio2_sensor *sensor)
> {
> sensor->prop_names = prop_names;
> }
>
> This shoudl generate a compilation warning if the string is too long.
>
> You could even inline that line in
> cio2_bridge_create_fwnode_properties().

Yes, I like that, thanks - I'll make the change.

>> +}
>> +
>> +static void cio2_bridge_create_fwnode_properties(struct cio2_sensor *sensor)
>> +{
>> + unsigned int i;
>> +
>> + cio2_bridge_init_property_names(sensor);
>> +
>> + for (i = 0; i < 4; i++)
>> + sensor->data_lanes[i] = i + 1;
>
> Is there no provision in the SSDB for data lane remapping ?

Sorry; don't follow what you mean by data lane remapping here.

>> +
>> + /*
>> + * Can't use PROPERTY_ENTRY_REF because it creates a new variable to
>> + * point to, which doesn't survive the function.
>> + */
>> + sensor->local_ref[0] = (struct software_node_ref_args){
>> + .node = &sensor->swnodes[SWNODE_CIO2_ENDPOINT]
>> + };
>
> I'd remove one tab here. Or just write
>
> sensor->local_ref[0].node = &sensor->swnodes[SWNODE_CIO2_ENDPOINT];

Yep, changed.

>> + sensor->remote_ref[0] = (struct software_node_ref_args){
>> + .node = &sensor->swnodes[SWNODE_SENSOR_ENDPOINT]
>> + };
>> +
>> + sensor->dev_properties[0] = PROPERTY_ENTRY_U32(sensor->prop_names.clock_frequency,
>> + sensor->ssdb.mclkspeed);
>> + sensor->dev_properties[1] = PROPERTY_ENTRY_U8(sensor->prop_names.rotation,
>> + sensor->ssdb.degree);
>> +
>> + sensor->ep_properties[0] = PROPERTY_ENTRY_U32(sensor->prop_names.bus_type, 5);
>> + sensor->ep_properties[1] = PROPERTY_ENTRY_U32_ARRAY_LEN(sensor->prop_names.data_lanes,
>> + sensor->data_lanes,
>> + sensor->ssdb.lanes);
>> + sensor->ep_properties[2] = PROPERTY_ENTRY_REF_ARRAY(sensor->prop_names.remote_endpoint,
>> + sensor->local_ref);
>> +
>> + sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(sensor->prop_names.data_lanes,
>> + sensor->data_lanes,
>> + sensor->ssdb.lanes);
>> + sensor->cio2_properties[1] = PROPERTY_ENTRY_REF_ARRAY(sensor->prop_names.remote_endpoint,
>> + sensor->remote_ref);
>> +}
>> +
>> +static void cio2_bridge_init_swnode_names(struct cio2_sensor *sensor)
>> +{
>> + snprintf(sensor->node_names.remote_port, 6, "port%u", sensor->ssdb.link);
>> + strcpy(sensor->node_names.port, "port0");
>> + strcpy(sensor->node_names.endpoint, "endpoint0");
>> +}
>> +
>> +static void cio2_bridge_create_connection_swnodes(struct cio2_bridge *bridge,
>> + struct cio2_sensor *sensor)
>> +{
>> + struct software_node *nodes = sensor->swnodes;
>> +
>> + cio2_bridge_init_swnode_names(sensor);
>> +
>> + nodes[SWNODE_SENSOR_HID] = NODE_SENSOR(sensor->name,
>> + sensor->dev_properties);
>> + nodes[SWNODE_SENSOR_PORT] = NODE_PORT(sensor->node_names.port,
>> + &nodes[SWNODE_SENSOR_HID]);
>> + nodes[SWNODE_SENSOR_ENDPOINT] = NODE_ENDPOINT(sensor->node_names.endpoint,
>> + &nodes[SWNODE_SENSOR_PORT],
>> + sensor->ep_properties);
>> + nodes[SWNODE_CIO2_PORT] = NODE_PORT(sensor->node_names.remote_port,
>> + &bridge->cio2_hid_node);
>> + nodes[SWNODE_CIO2_ENDPOINT] = NODE_ENDPOINT(sensor->node_names.endpoint,
>> + &nodes[SWNODE_CIO2_PORT],
>> + sensor->cio2_properties);
>> +}
>> +
>> +static void cio2_bridge_unregister_sensors(struct cio2_bridge *bridge)
>> +{
>> + struct cio2_sensor *sensor;
>> + unsigned int i;
>> +
>> + for (i = 0; i < bridge->n_sensors; i++) {
>> + sensor = &bridge->sensors[i];
>> + software_node_unregister_nodes(sensor->swnodes);
>> + acpi_dev_put(sensor->adev);
>> + }
>> +}
>> +
>> +static int cio2_bridge_connect_sensors(struct cio2_bridge *bridge)
>> +{
>> + struct fwnode_handle *fwnode;
>> + struct cio2_sensor *sensor;
>> + struct acpi_device *adev;
>> + unsigned int i;
>> + int ret = 0;
>> +
>> + for (i = 0; i < ARRAY_SIZE(cio2_supported_devices); i++) {
>> + const char *this_device = cio2_supported_devices[i];
>
> s/this_device/name/ (or sensor_name, ...) ?

I went for hid as Andy suggested.
>
>> +
>> + for_each_acpi_dev_match(adev, this_device, NULL, -1) {
>> + if (!adev || !(adev->status.present && adev->status.enabled))
>
> if (!adev || !adev->status.present || !adev->status.enabled))
>
> may be a bit more readable. Does for_each_acpi_dev_match() return NULL
> devices though ? If no, you could drop the !adev check. You may also be
> able to drop the !present check, as I don't think ACPI allows !present
> && enabled.

You're right, the spec mandates enabled be 0 if present is 0. The
iterator will return NULL when the previous return value was the last
matching device, so that part needs to stay, but it can become:

if (!adev || !adev->status.enabled)

>> + continue;
>> +
>> + sensor = &bridge->sensors[bridge->n_sensors];
>> + sensor->adev = adev;
>> + strscpy(sensor->name, this_device, sizeof(sensor->name));
>> +
>> + ret = cio2_bridge_read_acpi_buffer(adev, "SSDB",
>> + &sensor->ssdb,
>> + sizeof(sensor->ssdb));
>> + if (ret < 0)
>> + goto err_put_adev;
>> +
>> + if (sensor->ssdb.lanes > 4) {
>> + dev_err(&adev->dev,
>> + "Number of lanes in SSDB is invalid\n");
>> + goto err_put_adev;
>> + }
>> +
>> + cio2_bridge_create_fwnode_properties(sensor);
>> + cio2_bridge_create_connection_swnodes(bridge, sensor);
>> +
>> + ret = software_node_register_nodes(sensor->swnodes);
>> + if (ret)
>> + goto err_put_adev;
>> +
>> + fwnode = software_node_fwnode(&sensor->swnodes[SWNODE_SENSOR_HID]);
>> + if (!fwnode) {
>> + ret = -ENODEV;
>> + goto err_free_swnodes;
>> + }
>> +
>> + adev->fwnode.secondary = fwnode;
>> +
>> + dev_info(&bridge->cio2->dev,
>> + "Found supported sensor %s\n",
>> + acpi_dev_name(adev));
>> +
>> + bridge->n_sensors++;
>
> We probably want a check here to avoid overflowing bridge->sensors. The
> other option is to make bridge->sensors a struct list_head and allocate
> sensors dynamically.

Err - agree on a check. There's only 4 ports in a CIO2 device, so that's
the maximum. Seems easier to just do a check, unless the wasted memory
is enough that it's worth allocating dynamically. I don't mind either
approach.

>> + }
>> + }
>> +
>> + return ret;
>> +
>> +err_free_swnodes:
>> + software_node_unregister_nodes(sensor->swnodes);
>> +err_put_adev:
>> + acpi_dev_put(sensor->adev);
>> +
>> + return ret;
>> +}
>> +
>> +int cio2_bridge_init(struct pci_dev *cio2)
>> +{
>> + struct device *dev = &cio2->dev;
>> + struct fwnode_handle *fwnode;
>> + struct cio2_bridge *bridge;
>> + int ret;
>> +
>> + bridge = kzalloc(sizeof(*bridge), GFP_KERNEL);
>> + if (!bridge)
>> + return -ENOMEM;
>> +
>> + strscpy(bridge->cio2_node_name, CIO2_HID, sizeof(bridge->cio2_node_name));
>> + bridge->cio2_hid_node = (const struct software_node){ bridge->cio2_node_name };
>
> Maybe just
>
> bridge->cio2_hid_node.name = bridge->cio2_node_name;
>
> as the rest is already zeroed by the kzalloc() call ?
>
>> + bridge->cio2 = pci_dev_get(cio2);
>
> As the cio2 pointer is only used to print a message in
> cio2_bridge_connect_sensors(), do we need to store it in the bridge
> structure, and take a reference to the device ?
>
>> +
>> + ret = software_node_register(&bridge->cio2_hid_node);
>> + if (ret < 0) {
>> + dev_err(dev, "Failed to register the CIO2 HID node\n");
>> + goto err_put_cio2;
>> + }
>> +
>> + ret = cio2_bridge_connect_sensors(bridge);
>> + if (ret || bridge->n_sensors == 0)
>> + goto err_unregister_cio2;
>> +
>> + dev_info(dev, "Connected %d cameras\n", bridge->n_sensors);
>> +
>> + fwnode = software_node_fwnode(&bridge->cio2_hid_node);
>> + if (!fwnode) {
>> + dev_err(dev, "Error getting fwnode from cio2 software_node\n");
>> + ret = -ENODEV;
>> + goto err_unregister_sensors;
>
> Can this happen ?

It _shouldn't_ happen, as long as nothing else is touching the swnodes
I've registered or anything. I've never seen it happen. That didn't feel
like quite enough to say it can't ever happen - but I'm happy to skip
the check if you think thats ok.

>> + }
>> +
>> + set_secondary_fwnode(dev, fwnode);
>> +
>> + return 0;
>> +
>> +err_unregister_sensors:
>> + cio2_bridge_unregister_sensors(bridge);
>> +err_unregister_cio2:
>> + software_node_unregister(&bridge->cio2_hid_node);
>> +err_put_cio2:
>> + pci_dev_put(bridge->cio2);
>> +
>> + kfree(bridge);
>> + return ret;
>> +}
>> diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.h b/drivers/media/pci/intel/ipu3/cio2-bridge.h
>> new file mode 100644
>> index 000000000000..96f5c8a12be0
>> --- /dev/null
>> +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.h
>
> This file is only included by cio2-bridge.c, so you could inline it
> there. Up to you.

I think I like them separate


>> @@ -0,0 +1,108 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Author: Dan Scally <djrscally@gmail.com> */
>> +#ifndef __CIO2_BRIDGE_H
>> +#define __CIO2_BRIDGE_H
>> +
>> +#include <linux/property.h>
>> +
>> +#define CIO2_HID "INT343E"
>> +#define CIO2_NUM_PORTS 4
> There are a few rogue spaces before '4'.

Argh, thanks, this is the curse of using VS code on multiple machines...
>
>> +
>> +#define NODE_SENSOR(_HID, _PROPS) \
>> + ((const struct software_node) { \
>> + .name = _HID, \
>> + .properties = _PROPS, \
>> + })
>> +
>> +#define NODE_PORT(_PORT, _SENSOR_NODE) \
>> + ((const struct software_node) { \
>> + _PORT, \
>> + _SENSOR_NODE, \
>> + })
>> +
>> +#define NODE_ENDPOINT(_EP, _PORT, _PROPS) \
>> + ((const struct software_node) { \
>> + _EP, \
>> + _PORT, \
>> + _PROPS, \
>> + })
>> +
>> +enum cio2_sensor_swnodes {
>> + SWNODE_SENSOR_HID,
>> + SWNODE_SENSOR_PORT,
>> + SWNODE_SENSOR_ENDPOINT,
>> + SWNODE_CIO2_PORT,
>> + SWNODE_CIO2_ENDPOINT,
>> + NR_OF_SENSOR_SWNODES
>> +};
>> +
>> +/* Data representation as it is in ACPI SSDB buffer */
>> +struct cio2_sensor_ssdb {
>> + u8 version;
>> + u8 sku;
>> + u8 guid_csi2[16];
>> + u8 devfunction;
>> + u8 bus;
>> + u32 dphylinkenfuses;
>> + u32 clockdiv;
>> + u8 link;
>> + u8 lanes;
>> + u32 csiparams[10];
>> + u32 maxlanespeed;
>> + u8 sensorcalibfileidx;
>> + u8 sensorcalibfileidxInMBZ[3];
>> + u8 romtype;
>> + u8 vcmtype;
>> + u8 platforminfo;
>> + u8 platformsubinfo;
>> + u8 flash;
>> + u8 privacyled;
>> + u8 degree;
>> + u8 mipilinkdefined;
>> + u32 mclkspeed;
>> + u8 controllogicid;
>> + u8 reserved1[3];
>> + u8 mclkport;
>> + u8 reserved2[13];
>> +} __packed__;
>> +
>> +struct cio2_property_names {
>> + char clock_frequency[16];
>> + char rotation[9];
>> + char bus_type[9];
>> + char data_lanes[11];
>> + char remote_endpoint[16];
>> +};
>> +
>> +struct cio2_node_names {
>> + char port[6];
>> + char endpoint[10];
>> + char remote_port[6];
>> +};
>> +
>> +struct cio2_sensor {
>> + char name[ACPI_ID_LEN];
>> + struct acpi_device *adev;
>> +
>> + struct software_node swnodes[6];
>> + struct cio2_node_names node_names;
>> +
>> + u32 data_lanes[4];
>> + struct cio2_sensor_ssdb ssdb;
>> + struct cio2_property_names prop_names;
>> + struct property_entry ep_properties[4];
>> + struct property_entry dev_properties[3];
>> + struct property_entry cio2_properties[3];
>> + struct software_node_ref_args local_ref[1];
>> + struct software_node_ref_args remote_ref[1];
>> +};
>> +
>> +struct cio2_bridge {
>> + struct pci_dev *cio2;
>> + char cio2_node_name[ACPI_ID_LEN];
>> + struct software_node cio2_hid_node;
>> + unsigned int n_sensors;
>> + struct cio2_sensor sensors[CIO2_NUM_PORTS];
>> +};
>> +
>> +#endif
>> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c b/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>> index 36e354ecf71e..0d69b593e9f0 100644
>> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>> @@ -1702,6 +1702,22 @@ static void cio2_queues_exit(struct cio2_device *cio2)
>> cio2_queue_exit(cio2, &cio2->queue[i]);
>> }
>>
>> +static bool cio2_check_fwnode_graph(struct fwnode_handle *fwnode)
>> +{
>> + struct fwnode_handle *endpoint;
>> +
>> + if (IS_ERR_OR_NULL(fwnode))
>> + return false;
>> +
>> + endpoint = fwnode_graph_get_next_endpoint(fwnode, NULL);
>> + if (endpoint) {
>> + fwnode_handle_put(endpoint);
>> + return true;
>> + }
>> +
>> + return cio2_check_fwnode_graph(fwnode->secondary);
>
> If we have a fwnode->secondary and this check fails there's something
> seriously wrong, I wonder if we should print an error message.

Yes, probably a good thought, since nothing will work in that case. I'll
add something appropriate.

>
> Overall this is nice. I think the next version will get my ack :-)

Excellent :)

>> +}
>> +
>> /**************** PCI interface ****************/
>>
>> static int cio2_pci_probe(struct pci_dev *pci_dev,
>> @@ -1715,6 +1731,17 @@ static int cio2_pci_probe(struct pci_dev *pci_dev,
>> return -ENOMEM;
>> cio2->pci_dev = pci_dev;
>>
>> + /*
>> + * On some platforms no connections to sensors are defined in firmware,
>> + * if the device has no endpoints then we can try to build those as
>> + * software_nodes parsed from SSDB.
>> + */
>> + if (!cio2_check_fwnode_graph(dev_fwnode(&pci_dev->dev))) {
>> + r = cio2_bridge_init(pci_dev);
>> + if (r)
>> + return r;
>> + }
>> +
>> r = pcim_enable_device(pci_dev);
>> if (r) {
>> dev_err(&pci_dev->dev, "failed to enable device (%d)\n", r);
>> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.h b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
>> index ccf0b85ae36f..520a27c9cdad 100644
>> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
>> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
>> @@ -437,4 +437,10 @@ static inline struct cio2_queue *vb2q_to_cio2_queue(struct vb2_queue *vq)
>> return container_of(vq, struct cio2_queue, vbq);
>> }
>>
>> +#if IS_ENABLED(CONFIG_CIO2_BRIDGE)
>> +int cio2_bridge_init(struct pci_dev *cio2);
>> +#else
>> +int cio2_bridge_init(struct pci_dev *cio2) { return 0; }
>> +#endif
>> +
>> #endif
>

\
 
 \ /
  Last update: 2020-12-01 23:12    [W:0.193 / U:13.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site