linux-kernel - Re: [PATCH v2 06/12] drivers/soc: Add Aspeed XDMA Engine Driver

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]

Message-Id: <601efc97-714b-40af-b3a0-e4687c43be46@www.fastmail.com>
Date:   Fri, 13 Dec 2019 12:12:38 +1030
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "Eddie James" <eajames@...ux.vnet.ibm.com>,
        "Eddie James" <eajames@...ux.ibm.com>, linux-kernel@...r.kernel.org
Cc:     devicetree@...r.kernel.org, "Jason Cooper" <jason@...edaemon.net>,
        linux-aspeed@...ts.ozlabs.org, "Marc Zyngier" <maz@...nel.org>,
        "Rob Herring" <robh+dt@...nel.org>, tglx@...utronix.de,
        mark.rutland@....com, "Joel Stanley" <joel@....id.au>
Subject: Re: [PATCH v2 06/12] drivers/soc: Add Aspeed XDMA Engine Driver



On Fri, 13 Dec 2019, at 05:46, Eddie James wrote:
> 
> On 12/11/19 10:52 PM, Andrew Jeffery wrote:
> >
> > On Thu, 12 Dec 2019, at 07:09, Eddie James wrote:
> >> On 12/10/19 9:47 PM, Andrew Jeffery wrote:
> >>> On Fri, 6 Dec 2019, at 03:45, Eddie James wrote:
> >>>> +
> >>>> +	regmap_update_bits(sdmc, SDMC_REMAP, ctx->chip->sdmc_remap,
> >>>> +			   ctx->chip->sdmc_remap);
> >>> I disagree with doing this. As mentioned on the bindings it should be up to
> >>> the platform integrator to ensure that this is configured appropriately.
> >>
> >> Probably so, but then how does one actually configure that elsewhere? Do
> >> you mean add code to the edac driver (and add support for the ast2600)
> >> to read some dts properties to set it?
> > Right. That's where I was going. I don't expect you to do that as part of this
> > patch series, but if you could separate this code out into separate patches
> > (dealing with the sdmc property in the devicetree binding as well) we can at
> > least concentrate on getting the core XDMA driver in and work out how to
> > move forward with configuring the memory controller later.
> 
> 
> Yea... my concern is that then we end up with a driver upstream that 
> doesn't actually work. Same concern with the reset thing you mentioned 
> below.

How would it not work? It would just be up to the platform integrator to make
sure the stars align right? If they do then there should be no problem. Whacking
the memory controller here is done out of convenience.

We can still carry the separate patches adding this and the reset behaviour in
e.g. the openbmc kernel tree if necessary.

Andrew