| 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
| ||
|
Message-ID: <ktnqf4s4hw2o6x6ir4n5hsrvbxri5cxgjyofrl76by6fwazda3@4ejw2k7k2ush>
Date: Wed, 5 Mar 2025 12:43:54 +0800
From: Inochi Amaoto <inochiama@...il.com>
To: Conor Dooley <conor@...nel.org>, Inochi Amaoto <inochiama@...il.com>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Chen Wang <unicorn_wang@...look.com>, Philipp Zabel <p.zabel@...gutronix.de>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Niklas Cassel <cassel@...nel.org>,
Shashank Babu Chinta Venkata <quic_schintav@...cinc.com>, linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
sophgo@...ts.linux.dev, linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
Yixun Lan <dlan@...too.org>, Longbin Li <looong.bin@...il.com>
Subject: Re: [PATCH 1/2] dt-bindings: pci: Add Sophgo SG2044 PCIe host
On Mon, Mar 03, 2025 at 05:04:28PM +0000, Conor Dooley wrote:
> On Fri, Feb 28, 2025 at 05:20:28PM +0800, Inochi Amaoto wrote:
> > On Fri, Feb 28, 2025 at 04:46:22PM +0800, Inochi Amaoto wrote:
> > > On Fri, Feb 28, 2025 at 02:34:00PM +0800, Inochi Amaoto wrote:
> > > > On Tue, Feb 25, 2025 at 11:35:23PM +0000, Conor Dooley wrote:
> > > > > On Tue, Feb 25, 2025 at 07:48:59AM +0800, Inochi Amaoto wrote:
> > > > > > On Mon, Feb 24, 2025 at 06:54:51PM +0000, Conor Dooley wrote:
> > > > > > > On Sat, Feb 22, 2025 at 08:34:10AM +0800, Inochi Amaoto wrote:
> > > > > > > > On Fri, Feb 21, 2025 at 05:01:41PM +0000, Conor Dooley wrote:
> > > > > > > > > On Fri, Feb 21, 2025 at 09:37:55AM +0800, Inochi Amaoto wrote:
> > > > > > > > > > The pcie controller on the SG2044 is designware based with
> > > > > > > > > > custom app registers.
> > > > > > > > > >
> > > > > > > > > > Add binding document for SG2044 PCIe host controller.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Inochi Amaoto <inochiama@...il.com>
> > > > > > > > > > ---
> > > > > > > > > > .../bindings/pci/sophgo,sg2044-pcie.yaml | 125 ++++++++++++++++++
> > > > > > > > > > 1 file changed, 125 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml
> > > > > > > > > >
> > > > > > > > > > diff --git a/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml b/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000000..040dabe905e0
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml
> > > > > > > > > > @@ -0,0 +1,125 @@
> > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > > > > +%YAML 1.2
> > > > > > > > > > +---
> > > > > > > > > > +$id: http://devicetree.org/schemas/pci/sophgo,sg2044-pcie.yaml#
> > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > +
> > > > > > > > > > +title: DesignWare based PCIe Root Complex controller on Sophgo SoCs
> > > > > > > > > > +
> > > > > > > > > > +maintainers:
> > > > > > > > > > + - Inochi Amaoto <inochiama@...il.com>
> > > > > > > > > > +
> > > > > > > > > > +description: |+
> > > > > > > > > > + SG2044 SoC PCIe Root Complex controller is based on the Synopsys DesignWare
> > > > > > > > > > + PCIe IP and thus inherits all the common properties defined in
> > > > > > > > > > + snps,dw-pcie.yaml.
> > > > > > > > > > +
> > > > > > > > > > +allOf:
> > > > > > > > > > + - $ref: /schemas/pci/pci-host-bridge.yaml#
> > > > > > > > > > + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > > > > > > > > > +
> > > > > > > > > > +properties:
> > > > > > > > > > + compatible:
> > > > > > > > > > + const: sophgo,sg2044-pcie
> > > > > > > > > > +
> > > > > > > > > > + reg:
> > > > > > > > > > + items:
> > > > > > > > > > + - description: Data Bus Interface (DBI) registers
> > > > > > > > > > + - description: iATU registers
> > > > > > > > > > + - description: Config registers
> > > > > > > > > > + - description: Sophgo designed configuration registers
> > > > > > > > > > +
> > > > > > > > > > + reg-names:
> > > > > > > > > > + items:
> > > > > > > > > > + - const: dbi
> > > > > > > > > > + - const: atu
> > > > > > > > > > + - const: config
> > > > > > > > > > + - const: app
> > > > > > > > > > +
> > > > > > > > > > + clocks:
> > > > > > > > > > + items:
> > > > > > > > > > + - description: core clk
> > > > > > > > > > +
> > > > > > > > > > + clock-names:
> > > > > > > > > > + items:
> > > > > > > > > > + - const: core
> > > > > > > > > > +
> > > > > > > > > > + dma-coherent: true
> > > > > > > > >
> > > > > > > > > Why's this here? RISC-V is dma-coherent by default, with dma-noncoherent
> > > > > > > > > used to indicate systems/devices that are not.
> > > > > > > >
> > > > > > > > The PCIe is dma coherent, but the SoC itself is marked as
> > > > > > > > dma-noncoherent.
> > > > > > >
> > > > > > > By "the SoC itself", do you mean that the bus that this device is on is
> > > > > > > marked as dma-noncoherent?
> > > > > >
> > > > > > Yeah, I was told only PCIe device on SG2044 is dma coherent.
> > > > > > The others are not.
> > > > > >
> > > > > > > IMO, that should not be done if there are devices on it that are coherent.
> > > > > > >
> > > > > >
> > > > > > It is OK for me. But I wonder how to handle the non coherent device
> > > > > > in DT? Just Mark the bus coherent and mark all devices except the
> > > > > > PCIe device non coherent?
> > > > >
> > > > > Don't mark the bus anything (default is coherent) and mark the devices.
> > > >
> > > > I think this is OK for me.
> > > >
> > >
> > > In technical, I wonder a better way to "handle dma-noncoherent".
> > > In the binding check, all devices with this property complains
> > >
> > > "Unevaluated properties are not allowed ('dma-noncoherent' was unexpected)"
> > >
> >
> > > It is a pain as at least 10 devices' binding need to be modified.
> > > So I wonder whether there is a way to simplify this.
> > >
> >
> > Ignore this, I misunderstood the dma device. it seems like
> > only dmac and eth needs it.
>
> Nah, not gonna ignore it ;) You do make a valid point about it being
> painful, but given you mention a different master for the pci device,
> having two different soc@<foo> nodes sounds like it might make sense.
> One marked dma-noncoherent w/ the existing devices and one that is
> unmarked (since that's default) to represent the master than pci is on?
Hi, Conor,
After some testing. It has some new problems. As the pcie
register area and ranges mapping are not isolated. It is a
disaster to figure the right mapping. If writing this with
soc ranges, the thing may look like the following:
/* this is for pcie */
soc@...0000000 {
/* pcie ip register area */
ranges = <0x6c 0x00000000 0x6c 0x00000000 0x0 0xc0000000>,
/* pcie vendor registes area and other mapping */
<0x40 0x00000000 0x40 0x00000000 0x28 0x00000000>,
/* for 32 bit memory */
<0x0 0x00000000 0x0 0x00000000 0x0 0x70000000>;
};
/* this is for others */
soc@...0000000 {
/* clint and some peripherals */
ranges = <0x68 0x00000000 0x68 0x00000000 0x4 0x0000000>,
/* other peripherals */
<0x6d 0x00000000 0x6d 0x00000000 0x13 0x00000040>,
/* this one is for the external msi controller */
<0x0 0x7ee00000 0x0 0x7ee00000 0x0 0x00000040>;
dma-noncoherent;
};
It is complete a mess. I think it is more clear to just make the
dmac and eth device as noncoherent, and use one soc bus for all.
Do you have any suggestions on it?
Regards,
Inochi
Powered by blists - more mailing lists