linux-kernel - Re: [PATCH 1/2] HISI LPC: Reference static MFD cells for ACPI support

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: <4a15b0b4-5707-d51b-4762-02df8e153bd9@huawei.com>
Date:   Fri, 4 May 2018 10:27:10 +0100
From:   John Garry <john.garry@...wei.com>
To:     Lee Jones <lee.jones@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     <xuwei5@...wei.com>, <mika.westerberg@...ux.intel.com>,
        <rjw@...ysocki.net>, <linux-kernel@...r.kernel.org>,
        <arnd@...db.de>, <graeme.gregory@...aro.org>, <helgaas@...nel.org>,
        <z.liuxinliang@...ilicon.com>, <linuxarm@...wei.com>
Subject: Re: [PATCH 1/2] HISI LPC: Reference static MFD cells for ACPI support

On 04/05/2018 10:02, Lee Jones wrote:
> On Thu, 03 May 2018, Andy Shevchenko wrote:
>
>> On Thu, 2018-05-03 at 23:08 +0800, John Garry wrote:
>>> Currently for ACPI support the driver models the host as
>>> an MFD. For a device connected to the LPC bus, we dynamically
>>> create an MFD cell for that device, configuring the cell
>>> name and ACPI match parameters manually. This makes supporting
>>> named devices and also special setup handling for certain devices
>>> awkward, as we would need to introduce some special ACPI device
>>> handling according to device HID.
>>>
>>> To avoid this, create reference static MFD cells for known
>>> child devices, so when adding an MFD cell we can fix the cell
>>> platform data as required. For this, a setup callback function
>>> is added.
>>>
>>> For now, only the IPMI cell is added.
>>
>>> +static const struct mfd_cell *hisi_lpc_acpi_mfd_get_cell(const char
>>> *hid)
>>> +{
>>> +	const struct hisi_lpc_acpi_mfd_cell *cell =
>>> hisi_lpc_acpi_mfd_cells;
>>> +
>>> +	for (; cell && cell->mfd_cell.name; cell++) {
>>> +		const struct mfd_cell *mfd_cell = &cell->mfd_cell;
>>> +		const struct mfd_cell_acpi_match *acpi_match;
>>> +
>>> +		acpi_match = mfd_cell->acpi_match;
>>> +		if (!strcmp(acpi_match->pnpid, hid))
>>> +			return mfd_cell;
>>> +	}
>>> +
>>> +	return NULL;
>>> +}
>>
>> I'm not sure I understand why MFD core can't do it (as seen in lines
>> drivers/mfd/core.c:105 and below).
>

Hi Lee,

> You shouldn't be using the MFD API outside of MFD anyway.  Either it
> is an MFD driver, or it isn't.  If it is, please move it. If it's not,
> please don't use the API.

We're modelling as an MFD, but it's not an MFD in the classic sense. 
We're just using the MFD API for convenience (and to avoid code 
duplication), as the MFD API does what we require for this driver.

>
> My current suspicion is that the driver needs splitting and only part
> of it ends up in MFD.
>

How would you propose splitting the driver? By adding a lib function 
specific for this driver for the ACPI probe?

Cheers,
John