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
| ||
|
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 > . >
Powered by blists - more mailing lists