[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2bb9d22-6914-ed59-6c77-a0020e2faed5@gmail.com>
Date: Wed, 23 Sep 2020 10:39:16 +0100
From: Dan Scally <djrscally@...il.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: yong.zhi@...el.com, bingbu.cao@...el.com, tian.shu.qiu@...el.com,
mchehab@...nel.org, gregkh@...uxfoundation.org,
davem@...emloft.net, robh@...nel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, devel@...verdev.osuosl.org,
jorhand@...ux.microsoft.com, kitakar@...il.com,
kieran.bingham@...asonboard.com, andriy.shevchenko@...ux.intel.com
Subject: Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device
via software nodes on ACPI platforms
Hi Sakari
On 17/09/2020 11:33, Sakari Ailus wrote:
>> + ret = software_node_register_nodes(nodes);
>> + if (ret) {
>> + dev_err(dev,
>> + "Failed to register software nodes for %s\n",
>> + supported_devices[i]);
>> + return ret;
>> + }
>> +
>> + fwnode = software_node_fwnode(&nodes[SWNODE_SENSOR_HID]);
>> + if (!fwnode) {
>> + dev_err(dev,
>> + "Failed to get software node for %s\n",
>> + supported_devices[i]);
>> + return ret;
>> + }
>> +
>> + fwnode->secondary = ERR_PTR(-ENODEV);
>> + dev->fwnode = fwnode;
>> +
>> + /*
>> + * The device should by this point has driver_data set to an
>> + * instance of struct v4l2_subdev; set the fwnode for that too.
>> + */
>> +
>> + sd = dev_get_drvdata(dev);
>> + sd->fwnode = fwnode;
> I'm a bit lost here. Isn't it enough to have the sensor device's fwnode,
> and to use that for V4L2 async fwnode matching (as usual)?
Just working through the changes everyone's suggested for the v2. For
this one the reason it had to be this way is that
v4l2_async_register_subdev() just picks up the fwnode from the device.
If we wanted to just rely on that call as part of the sensor driver's
probe() then we need to reprobe() the sensor in case it already probed
before this code has managed to run, and reprobing after assigning the
software_nodes as fwnode to the sensor no longer works - the long and
short of that is that the ACPI matching portion of i2c_device_match()
calls ACPI_COMPANION(dev), and that macro relies on dev->fwnode->ops
being acpi_device_fwnode_ops which they no longer are. This is also the
reason I was storing the original fwnode's of the sensor device and cio2
device in the cio2-bridge; so that they could be restored if the module
was removed.
Powered by blists - more mailing lists