linux-kernel - Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by

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: <75eae3ac-228f-d6a4-bb0e-4bd27e35c55d@huawei.com>
Date:   Fri, 20 Apr 2018 15:09:30 +0100
From:   John Garry <john.garry@...wei.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:     <rjw@...ysocki.net>, <andriy.shevchenko@...ux.intel.com>,
        <linux-acpi@...r.kernel.org>, <lenb@...nel.org>,
        <lorenzo.pieralisi@....com>, <linux-kernel@...r.kernel.org>,
        <arnd@...db.de>, <graeme.gregory@...aro.org>, <helgaas@...nel.org>,
        <linuxarm@...wei.com>, <z.liuxinliang@...ilicon.com>
Subject: Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent"
 devices

On 20/04/2018 14:52, Mika Westerberg wrote:
> On Fri, Apr 20, 2018 at 02:24:18PM +0100, John Garry wrote:
>> Hi Mika,
>>
>> On 20/04/2018 14:07, Mika Westerberg wrote:
>>> On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote:
>>>> +	} else {
>>>> +		device->driver_data = dev;
>>>
>>> I think this deserves a comment explaining why we (ab)use driver_data
>>> like this.
>>
>> Sure, could add. I didn't see any other way for the acpi_device structure to
>> reference the derived PNP device.
>>
>> TBH, This overall approach is not good since we are creating the PNP device
>> in the scan, and then leaving the device in limbo, waiting for the parent to
>> add it, if at all. There's no rule for this.
>>
>> So I'm looking for ideas on how to improve this.
>

Hi Mika,

> One idea is to make pnpacpi_add_device() available outside of PNP and
> call it directly (or some variation) in hisi_lpc.c when it walks over
> its children.
>

I did consider this initially and it seems quite straightforward.

However I think the problem is that we would need to modify the 
acpi_device child resources from FW with kernel-specific resources, 
which does not seem right (I think that is what you meant). As I see, 
this is one reason that we went in the direction of modelling the host 
as an MFD, as we could set the resources of the mfd_cells.

So adding a variant of pnpacpi_add_device() could work, or modifying 
pnpacpi_add_device() to accept a callback to translate the resources. 
But this feature is specific to our very special requirement...

Thanks,
John

> .
>