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 11:14:20 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Marc Zyngier <marc.zyngier@....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 10/09/2019 11:12, Marc Zyngier wrote:
> 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?

Yes, sure.

Neil

> 
> Thanks,
> 
> 	M.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ