linux-kernel - Re: [PATCH V2] ACPI / LPSS: Add device link for CHT SD card dependency on I2C

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]

Date:   Fri, 15 Dec 2017 11:10:39 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Carlo Caione <carlo@...lessm.com>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH V2] ACPI / LPSS: Add device link for CHT SD card
 dependency on I2C

On 14/12/17 16:16, Andy Shevchenko wrote:
> On Thu, 2017-12-07 at 11:03 +0200, Adrian Hunter wrote:
>> Some Cherry Trail boards have a dependency between the SDHCI host
>> controller used for SD cards and an external PMIC accessed via I2C.
>> Add a
>> device link between the SDHCI host controller (consumer) and the I2C
>> adapter (supplier).
>>
>> This patch depends on a fix to devices links, namely commit
>> 0ff26c662d5f
>> ("driver core: Fix device link deferred probe"). And also either,
>> commit 126dbc6b49c8 ("PM: i2c-designware-platdrv: Clean up PM handling
>> in
>> probe"), or patch "PM / runtime: Fix handling of suppliers with
>> disabled
>> runtime PM".
>>
> 
> Fine with me, though I think below comment worth to address.
> 
>>  
>> +static const struct x86_cpu_id cht_cpu[] = {
>> +	ICPU(INTEL_FAM6_ATOM_AIRMONT),	/* Braswell, Cherry
>> Trail */
>> +	{}
>> +};
> 
> I would rather to modify ICPU() macro to accept driver data where we
> just pass an unsigned long value to be assigned as lpss_quirks and
> introduce another quirk.
> 
>> +
>> +		if (link->cpus && !x86_match_cpu(link->cpus))
>> +			continue;
> 
> ...thus, 
> 
> if (!(lpss_quirks & LPSS_QUIRK_NEED_DEVICE_LINKS))
>  continue;

The intention is to associate the cpu with the link information i.e. that
link is needed on that cpu.  What you are proposing is slightly different.