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: <20191021171013.GX5610@atomide.com>
Date:   Mon, 21 Oct 2019 10:10:13 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Rob Herring <robh+dt@...nel.org>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Mark Rutland <mark.rutland@....com>,
        BenoƮt Cousson <bcousson@...libre.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com
Subject: Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller <hns@...delico.com> [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring <robh+dt@...nel.org>:
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller <hns@...delico.com> wrote:
> >> +- reg:         Physical base addresses and lengths of the register areas.
> > 
> > How many?
> 
> I assume there is only one. At least it suffices to make the existing
> driver work with it.
> 
> > 
> >> +- reg-names:   Names for the register areas.
> > 
> > If only 1 as the example suggests, then you don't need this.
> 
> ok.

My guess is that sgx is just a private interconnect instance
with few control modules like mmu and clocks, and the driver(s)
should consist of independent modules like iommu and clock
driver.

So yeah I agree, it's best to leave reg names out of the
dts at least for now.

> >> +                       compatible = "ti,sysc-omap4", "ti,sysc";
> >> +                       reg = <0x5600fe00 0x4>,
> >> +                             <0x5600fe10 0x4>;
> > 
> > How does it work that these registers overlap the GPU registers?
> 
> Both drivers have access to these registers. Likely, the gpu driver
> ignores them and does access other ranges.

Unfortunately TI is stuffing the interconnect target module
control registers at random places within the unused register
space of the child module(s). So the module control registers
are all over the map at various offsets.

Adding holes for each module control register to the child nodes
seems like an overkill to work around this IMO. Especially
considering many drivers only understand one IO range currently.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ