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:   Wed, 5 Oct 2022 08:21:55 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Elliot Berman <quic_eberman@...cinc.com>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Murali Nalajala <quic_mnalajal@...cinc.com>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        Carl van Schaik <quic_cvanscha@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 13/14] gunyah: rsc_mgr: Add auxiliary devices for
 console

On Tue, Oct 04, 2022 at 04:49:27PM -0700, Elliot Berman wrote:
> On 9/30/2022 5:19 AM, Greg Kroah-Hartman wrote:
> > On Wed, Sep 28, 2022 at 12:56:32PM -0700, Elliot Berman wrote:
> > > Gunyah resource manager exposes a concrete functionalities which
> > > complicate a single resource manager driver.
> > 
> > I am sorry, but I do not understand this sentance.  What is so
> > complicated about individual devices being created?  Where are they
> > created?  What bus?
> 
> There's no complexity here with using individual devices, that's why I
> wanted to create secondary (auxiliary devices).
> 
> IOW -- "I have a platform device that does a lot of different things. Split
> up the different functionalities of that device into sub devices using the
> auxiliary bus."

Why not just have multiple platform devices?  You control them, don't
make it more complex than it should be.

And why are these platform devices at all?

As you say:

> A key requirement for utilizing the auxiliary bus is that there is no
> dependency on a physical bus, device, register accesses or regmap support.
> These individual devices split from the core cannot live on the platform bus
> as they are not physical devices that are controlled by DT/ACPI.

These are not in the DT.  So just make your own bus for them instead of
using a platform device.  Don't abuse a platform device please.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ