| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <b0a99dba-4176-009a-07c7-7ad6701c2b48@ideasonboard.com>
Date: Mon, 4 Jan 2021 16:13:32 +0000
From: Kieran Bingham <kieran.bingham@...asonboard.com>
To: Daniel Scally <djrscally@...il.com>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-media@...r.kernel.org,
devel@...ica.org, gregkh@...uxfoundation.org, rjw@...ysocki.net,
sergey.senozhatsky@...il.com, mchehab@...nel.org
Cc: lenb@...nel.org, yong.zhi@...el.com, sakari.ailus@...ux.intel.com,
bingbu.cao@...el.com, tian.shu.qiu@...el.com,
robert.moore@...el.com, erik.kaneda@...el.com, pmladek@...e.com,
rostedt@...dmis.org, andriy.shevchenko@...ux.intel.com,
linux@...musvillemoes.dk,
laurent.pinchart+renesas@...asonboard.com,
jacopo+renesas@...ndi.org, hverkuil-cisco@...all.nl,
m.felsch@...gutronix.de, niklas.soderlund+renesas@...natech.se,
slongerbeam@...il.com, heikki.krogerus@...ux.intel.com,
linus.walleij@...aro.org,
Jordan Hand <jorhand@...ux.microsoft.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
Hi Dan,
On 04/01/2021 15:31, Daniel Scally wrote:
> Hi Kieran
>
> On 04/01/2021 15:13, Kieran Bingham wrote:
>> Hi Dan,
>>
>> On 04/01/2021 13:55, Daniel Scally wrote:
>>> Hi Kieran
>>>
>>> On 04/01/2021 13:35, Kieran Bingham wrote:
>>>>> +/*
>>>>> + * Extend this array with ACPI Hardware IDs of devices known to be working
>>>>> + * plus the number of link-frequencies expected by their drivers, along with
>>>>> + * the frequency values in hertz. This is somewhat opportunistic way of adding
>>>>> + * support for this for now in the hopes of a better source for the information
>>>>> + * (possibly some encoded value in the SSDB buffer that we're unaware of)
>>>>> + * becoming apparent in the future.
>>>>> + *
>>>>> + * Do not add an entry for a sensor that is not actually supported.
>>>>> + */
>>>>> +static const struct cio2_sensor_config cio2_supported_sensors[] = {
>>>>> + CIO2_SENSOR_CONFIG("INT33BE", 0),
>>>>> + CIO2_SENSOR_CONFIG("OVTI2680", 0),
>>>> I don't know if these are expressed anywhere else but would it be
>>>> helpful to add a comment, or indicator as to what the actual sensor is
>>>> that is represented by this HID?
>>>>
>>>> I can make an assumption about what an OVTI2680 might be, but the
>>>> INT33BE is quite opaque. It's not clear what support that adds.
>>>>
>>>> Unless no one cares what the sensor is that is, but I would anticipate
>>>> anyone looking here to add a new sensor might want to investigate what
>>>> was already in the table?
>>> Yeah good point. I'll probably alternate comment and entry then, like:
>>>
>>>
>>> +static const struct cio2_sensor_config cio2_supported_sensors[] = {
>>> + /* Sensor OVTI5693 */
>>> + CIO2_SENSOR_CONFIG("INT33BE", 0),
>>> + /* Sensor OVTI2680 */
>>> + CIO2_SENSOR_CONFIG("OVTI2680", 0),
>>>
>>> As an inline comment won't fit for the sensors that we know link-frequencies for. That sound ok?
>> I might put the whole vendor name in, and no need to prefix 'Sensor' IMO.
>>
>> + /* Omnivision OV5693 */
>> + CIO2_SENSOR_CONFIG("INT33BE", 0),
>> + /* Omnivision OV2680 */
>> + CIO2_SENSOR_CONFIG("OVTI2680", 0),
>>
>> but otherwise, yes a comment the line before works for me, as you are
>> right - at the end would not be practical.
> Works for me
>>>>> +static void cio2_bridge_create_fwnode_properties(
>>>>> + struct cio2_sensor *sensor,
>>>>> + const struct cio2_sensor_config *cfg)
>>>>> +{
>>>>> + unsigned int i;
>>>>> +
>>>>> + sensor->prop_names = prop_names;
>>>>> +
>>>>> + for (i = 0; i < CIO2_MAX_LANES; i++)
>>>>> + sensor->data_lanes[i] = i + 1;
>>>> Does something support lane swapping somewhere?
>>>> I assume this is just mapping each lane directly through.
>>> I think Sakari said remapping isn't supported in the CIO2 - so yeah this
>>> is just mapping them directly
>> So is this needed? Or is it some future compatibility thing?
>>
>> I haven't seen where it's used yet, but I'm not too worried about it
>> though, just not sure what value an array of [1, 2, 3, 4] gives if it's
>> constant...
>
> The endpoints need to have the data-lanes property which passes an array
> of data lanes, but there may well be a better way of doing this. I'm
> just using the lanes member of the ssdb data structure to tell the
> property how many members of the array to look at:
>
>
> + sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
> + sensor->prop_names.data_lanes,
> + sensor->data_lanes,
> + sensor->ssdb.lanes);
>
>
> So if sensor->ssdb.lanes is 2, even though it's passed a pointer to the
> first member of an array of 4 members, the size calculation of that
> macro limits it to just those in use. I.E. if sensor->ssdb.lanes is 2
> then the property will be given the size 2 * sizeof(u32), and so when
> its parsed only [1, 2] will be read.
Aha, I see, ok - so we are populating an array of [1, 2, 3, 4] for each
sensor that we add.
What about creating the data_lanes once as a const static array and
mapping to that?
/*
* Map the lane arrangement, which is fixed for the IPU3.
*/
static const int data_lanes[CIO2_MAX_LANES] = { 1, 2, 3, 4 };
...
sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
sensor->prop_names.data_lanes,
data_lanes,
sensor->ssdb.lanes);
...
Then we don't need the loop to populate the array for each sensor
anymore, or the data_lanes in the sensor struct?
--
Regards
--
Kieran
Powered by blists - more mailing lists