linux-kernel - Re: [PATCH v6 0/5] Functional dependencies between devices

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: <23e4a2bd-41d4-5e14-9539-2acf326dd534@samsung.com>
Date:   Tue, 08 Nov 2016 07:36:45 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Mark Brown <broonie@...nel.org>,
        Lukas Wunner <lukas@...ner.de>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Joerg Roedel <joro@...tes.org>, Jiri Kosina <jkosina@...e.cz>,
        Jiri Slaby <jslaby@...e.com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v6 0/5] Functional dependencies between devices

Hi Luis,


On 2016-11-07 22:15, Luis R. Rodriguez wrote:
> On Wed, Nov 02, 2016 at 08:58:38AM +0100, Marek Szyprowski wrote:
>> On 2016-10-31 18:47, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote:
>>>> Let me quote from the previous intro messages for this series first:
>>>>
>>>>>> Time for another update. :-)
>>>>>>
>>>>>> Fewer changes this time, mostly to address issues found by Lukas and
>>>>>> Marek.
>>>>>>
>>>>>> The most significant one is to make device_link_add() cope with the case
>>>>>> when
>>>>>> the consumer device has not been registered yet when it is called.  The
>>>>>> supplier device still is required to be registered and the function will
>>>>>> return NULL if that is not the case.
>>>>>>
>>>>>> Another significant change is in patch [4/5] that now makes the core apply
>>>>>> pm_runtime_get_sync()/pm_runtime_put() to supplier devices around the
>>>>>> probing of a consumer one (in analogy with the parent).
>>>>> One more update after some conversations during LinuxCon Europe.
>>>>>
>>>>> The main point was to make it possible for device_link_add() to figure out
>>>>> the initial state of the link instead of expecting the caller to provide it
>>>>> which might not be reliable enough in general.
>>>>>
>>>>> In this version device_link_add() takes three arguments, the supplier and
>>>>> consumer pointers and flags and it sets the correct initial state of the
>>>>> link automatically (unless invoked with the "stateless" flag, of course).
>>>>> The cost is one additional field in struct device (I moved all of the
>>>>> links-related fields in struct device to a separate sub-structure while at
>>>>> it) to track the "driver presence status" of the device (to be used by
>>>>> device_link_add()).
>>>>>
>>>>> In addition to that, the links list walks in the core.c and dd.c code are
>>>>> under the device links mutex now, so the iternal link spinlock is not needed
>>>>> any more and I have renamed symbols to distinguish between flags, link
>>>>> states and device "driver presence statuses".
>>>> The most significant change in this revision with respect to the previous one is
>>>> related to the fact that SRCU is not available on some architectures, so the
>>>> code falls back to using an RW semaphore for synchronization if SRCU is not
>>>> there.  Fortunately, the code changes needed for that turned out to be quite
>>>> straightforward and confined to the second patch.
>>>>
>>>> Apart from this, the flags are defined using BIT(x) now (instead of open coding
>>>> the latter in the flag definitions).
>>>>
>>>> Updated is mostly patch [2/5].  Patches [1,3,5/5] have not changed (except for
>>>> trivial rebasing) and patch [4/5] needed to be refreshed on top of the modified
>>>> [2/5].
>>>>
>>>> FWIW, I've run the series through 0-day which has not reported any problems
>>>> with it.
>>> Great, they are now applied to my tree, thanks again for doing this
>>> work.
>> Thanks for merging those patches! Could you provide a stable tag with them,
>> so I can
>> ask Joerg to merge my Exynos IOMMU PM patches on top of it via IOMMU tree?
> You want these patches to be merged into stable?! This is a whole new set of
> functionality, the patches in no way describe any *fixes* or critical issues,
> why are you saying this is needed? What makes you believe this is a stable
> candidate?

I don't want to merge those patches to stale kernel release. By 'stable 
tag' I just
meant something that can be pulled by Joerg to have a base for my Exynos 
IOMMU
patches.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland