linux-kernel - Re: [PATCH v1 0/3] of_devlink: Minor fixes and new properties

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: <CAGETcx-X4OTrGfBkP6CtC6=GV=KA147VO6jJL+o6hkC1iCkeeA@mail.gmail.com>
Date:   Wed, 6 Nov 2019 21:53:40 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>
Cc:     Android Kernel Team <kernel-team@...roid.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] of_devlink: Minor fixes and new properties

On Mon, Nov 4, 2019 at 10:50 PM Saravana Kannan <saravanak@...gle.com> wrote:
>
> Sending again since the cover letter missed everyone/mailing lists.
>
> First two patches are just code clean up and logging with no functional
> difference. The 3rd patch adds support for the following DT properties:
> iommus, mboxes and io-channels.
>
> These patches are on top of driver-core-next since that's where the rest
> of the of_devlink patches are.
>
> Greg and Rob,
> On a side note, I was wondering if I should rename the of_devlink kernel
> command line to fw_devlink and move it out of drivers/of/property.c and
> into drivers/base/core.c. This feature isn't really limited to
> devicetree, so I don't see a need to have devicetree specific kernel
> command line option.  Please let me know if that sounds okay to you.

Hi Rob,

Thanks for the reviews. Can you let me know what you think of this too?

Rob/Greg,

If I rename of_devlink to fw_devlink, I might also make it a setting
like fw_devlink=none/permissive/enforce
- none would be same as disabled completely.
- permissive would use SYNC_STATE_ONLY for all device links created by
firmware. So it won't block any probes even with cycles but
sync_state() will still work correctly.
- enforce would be the current "of_devlinkg=1" behavior where direct
dependencies would block probing and the child dependencies would use
SYNC_STATE_ONLY.

-Saravana