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: <6e71041d-1fc5-40b1-11b2-4af2f2d9c569@huawei.com>
Date:   Mon, 30 Apr 2018 10:35:13 +0100
From:   John Garry <john.garry@...wei.com>
To:     Lee Jones <lee.jones@...aro.org>
CC:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        <andriy.shevchenko@...ux.intel.com>, <rjw@...ysocki.net>,
        <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>,
        "Liguozhu (Kenneth)" <liguozhu@...ilicon.com>
Subject: Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent"
 devices

>>>> So we using the mfd_cell to match child devices using _HID. At a glance, I
>>>> don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
>>>>
>>>> Anyway we don't use static tables as we need to update the resources of the
>>>> cell dynamically. However I do look at a driver like intel_quark_i2c_gpio.c,
>>>> and this dynamically modifies the value of global mfd_cell array here:
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
>>>>
>>>> I know the cell array is only used at probe time, but this did not look to
>>>> be good standard practice to me.
>>>
>>> Lots of drivers do this to supply dynamic data.  If there is no other
>>> sane way of providing such data, it's fine to do.  Although each
>>> situation should be dealt with on a case-by-case basis.
>>>
>>
>> Hi Lee,
>>
>> Thanks for your input.
>>
>> I do see others drivers which use dynamic mem for the mfd_cells (like
>> cros_ec_dev.c), so what we're doing in this driver already is not totally
>> unchartered territory. But creating the MFD cells from the ACPI table could
>> be ...
>
> Right.  I don't normally like mixing platform data technologies (MFD,
> ACPI and DT).  I normally NACK patches which take information from
> Device Tree and populate MFD cells with it.  ACPI would be the same I
> guess.

Oh, well that is what we have in this driver. So what's the preferred 
approach? Just not use MFD model at all if ACPI/DT needs to be scanned 
for data to create the cells?

Thanks,
John

>
>> Anyway, I'll cc you in my next patchset and maybe you can kindly check it.
>>
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ