linux-kernel - Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b85ec736-6e02-4dd8-d7ce-b71c673e2b05@gmail.com>
Date:   Thu, 17 Sep 2020 22:25:03 +0100
From:   Daniel Scally <djrscally@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Yong Zhi <yong.zhi@...el.com>,
        Bingbu Cao <bingbu.cao@...el.com>,
        Tian Shu Qiu <tian.shu.qiu@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        "open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
        jorhand@...ux.microsoft.com, Tsuchiya Yuto <kitakar@...il.com>,
        kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device
 via software nodes on ACPI platforms

On 17/09/2020 15:14, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 4:53 PM Dan Scally <djrscally@...il.com> wrote:
>> Hi Andy, thanks for input (as always)
> You're welcome! I'm really impressed by your activity in this area.
Thanks - it's pretty fun so far
>>> Ah, I think you misinterpreted the meaning of above. The above is a switch how
>>> camera device appears either as PCI or an ACPI. So, it effectively means you
>>> should *not* have any relation for this HID until you find a platform where the
>>> device is for real enumerated via ACPI.
>>>
>> Ah, ok. So that was never going to work. Thanks. That does raise another
>> question; we have had some testers report failure, which turns out to be
>> because on their platforms the definition of their cameras in ACPI is
>> never translated into an i2c_client so the cio2-bridge doesn't bind.
>> Those have a similar conditional in the _STA method, see CAM1 in this
>> DSDT for example:
>> https://raw.githubusercontent.com/linux-surface/acpidumps/master/surface_go/dsdt.dsl.
>> Is there anything we can do to enable those cameras to be discovered too?
> It means that this
Is the rest of this comment missing?
>>>>>> +#define PROPERTY_ENTRY_NULL                       \
>>>>>> +((const struct property_entry) { })
>>>>> Alignment. Same appears to apply to other macros (please indent).
>>>> Yep
>>>>>> +#define SOFTWARE_NODE_NULL                        \
>>>>>> +((const struct software_node) { })
>>> Why?!
>>>
>> It felt ugly to have the other definitions be macros and not this one,
>> but I can change it.
> My point is that those macros are simply redundant. The point is to
> have a terminator record (all 0:s in the last entry of an array) which
> is usually being achieved by allocating memory with kcalloc() which
> does implicitly this for you.
Ah I see. TIL - thanks, I'll make that change too.