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] [day] [month] [year] [list]

Date:   Thu, 7 Nov 2019 09:40:47 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        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 Wed, Nov 06, 2019 at 09:53:40PM -0800, Saravana Kannan wrote:
> 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.

Renaming makes sense to me, and all of the above is fine as well.

thanks,

greg k-h