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:   Tue, 10 Sep 2019 10:12:45 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Neil Armstrong <narmstrong@...libre.com>
Cc:     khilman@...libre.com, bhelgaas@...gle.com,
        lorenzo.pieralisi@....com, yue.wang@...ogic.com, kishon@...com,
        repk@...plefau.lt, linux-amlogic@...ts.infradead.org,
        linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] arm64: dts: khadas-vim3: add commented support for PCIe

On Mon, 09 Sep 2019 18:50:42 +0100,
Neil Armstrong <narmstrong@...libre.com> wrote:
> 
> Hi Marc,
> 
> Le 09/09/2019 à 18:37, Marc Zyngier a écrit :
> > On Sun, 08 Sep 2019 14:42:58 +0100,
> > Neil Armstrong <narmstrong@...libre.com> wrote:
> >>
> >> The VIM3 on-board  MCU can mux the PCIe/USB3.0 shared differential
> >> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> an USB3.0 Type A connector and a M.2 Key M slot.
> >> The PHY driving these differential lines is shared between
> >> the USB3.0 controller and the PCIe Controller, thus only
> >> a single controller can use it.
> >>
> >> The needed DT configuration when the MCU is configured to mux
> >> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
> >> added commented and may uncommented to disable USB3.0 from the
> >> USB Complex and enable the PCIe controller.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
> >> ---
> >>  .../amlogic/meson-g12b-a311d-khadas-vim3.dts  | 22 +++++++++++++++++++
> >>  .../amlogic/meson-g12b-s922x-khadas-vim3.dts  | 22 +++++++++++++++++++
> >>  .../boot/dts/amlogic/meson-khadas-vim3.dtsi   |  4 ++++
> >>  .../dts/amlogic/meson-sm1-khadas-vim3l.dts    | 22 +++++++++++++++++++
> >>  4 files changed, 70 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> index 3a6a1e0c1e32..0577b1435cbb 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> @@ -14,3 +14,25 @@
> >>  / {
> >>  	compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
> >>  };
> >> +
> >> +/*
> >> + * The VIM3 on-board  MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> +	status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> +	phys = <&usb2_phy0>, <&usb2_phy1>;
> >> +	phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >> + */
> > 
> > Although you can't do much more than this here, I'd expect firmware on
> > the machine to provide the DT that matches its configuration. Is it
> > the way it actually works? Or is the user actually expected to edit
> > this file?
> 
> It's the plan when initial VIM3 support will be merged in u-boot mainline,
> and the MCU driver will be added aswell :
> https://patchwork.ozlabs.org/cover/1156618/
> A custom board support altering the DT will be added when this patchset
> is merged upstream.
> 
> But since these are separate projects, leaving this as commented is ugly,
> but necessary.

I agree with the unfortunate necessity. However, could you please have
a comment here, indicating that the user isn't expected to change this
on their own, but instead rely on the firmware/bootloader to do it
accordingly?

Thanks,

	M.

-- 
Jazz is not dead, it just smells funny.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ