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  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:   Thu, 14 Mar 2019 19:26:18 -0700
From:   Andrey Smirnov <andrew.smirnov@...il.com>
To:     Richard Zhu <hongxing.zhu@....com>
Cc:     "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/2] dt-bindings: imx6q-pcie: Add support for i.MX8QM/QXP PCIe

On Wed, Mar 13, 2019 at 2:15 AM Richard Zhu <hongxing.zhu@....com> wrote:
>
> Add codes needed to support i.MX8QM/QXP PCIe.
> - HSIO(High Speed IO) subsystem is new defined on i.MX8QM/QXP.
>   The PCIe and SATA modules are contained in the HSIO subsystem. There
>   are two PCIe, one SATA controllers and three mixed lane PHYs on
>   i.MX8QM. There are three use cases of the HSIO subsystem on i.MX8QM.
>   1. PCIea 2 lanes and one SATA AHCI port.
>   2. PCIea 1 lane, PCIeb 1 lane and one SATA AHCI port.
>   3. PCIea 2 lanes, PCIeb 1 lane.
>   i.MX8QXP only has PCIeb controller and one lane PHY.
>   Use the hsio-cfg property to specify the different modes.
> - The HSIO address map as viewed from system level is as shown below.
>   address [31:24]    Local address    Target    Address Size
>   5F                 0                HSIO      16MB
>   60-6F              40-4F            HSIO      256MB
>   70-7F              80-8F            HSIO      256MB
>   The property local-addr is required to specify it.
> - Both external OSC and internal PLL can be used as PCIe reference
>   clock, use the ext_osc property to distinguish them.
> - clock request GPIO for controlling the PCI reference clock request
>   signal. And should be configure OD when L1SS maybe enabled later.
> - One more power domain HSIO_GPIO and clock PCIE_PER are required by
>   i.MX8QM/QXP PCIe.
>   Add these specific properties to enable i.MX8QM/QXP PCIe.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@....com>
> ---
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt      | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index a7f5f5a..f7586c9 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -10,6 +10,8 @@ Required properties:
>         - "fsl,imx6qp-pcie"
>         - "fsl,imx7d-pcie"
>         - "fsl,imx8mq-pcie"
> +       - "fsl,imx8qm-pcie"
> +       - "fsl,imx8qxp-pcie"
>  - reg: base address and length of the PCIe controller
>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>    entry for each entry in the interrupt-names property.
> @@ -38,6 +40,10 @@ Optional properties:
>    The regulator will be enabled when initializing the PCIe host and
>    disabled either as part of the init process or when shutting down the
>    host.
> +- clkreq-gpio: Should specify the GPIO for controlling the PCI reference clock
> +  request signal.
> +- ext_osc: External OSC is used as PCIe reference clock or not. 0: Internal
> +  PLL. 1: External OSC.

Forgot to mention one thing in my very first reply, so I'll mention it
here. I think figuring out the way to add support for external vs
internal reference bus clock (that "ext_osc" binding above) is going
to be a whole other discussion. It might be easier/more expedient to
focus on just one particular use-case first (say external oscillator
only), get it all done and accepted and then return to this particular
feature in a separate series/discussion. However, that's just how I'd
approach this, so, please don't feel compelled to do it that way just
because I suggested it.

Thanks,
Andrey Smirnov

Powered by blists - more mailing lists