linux-kernel - Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

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:   Thu, 17 Jun 2021 17:47:29 +0200
From:   Jernej Škrabec <jernej.skrabec@...il.com>
To:     Andre Przywara <andre.przywara@....com>,
        Maxime Ripard <maxime@...no.tech>
Cc:     Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh@...nel.org>,
        Icenowy Zheng <icenowy@...c.io>,
        Samuel Holland <samuel@...lland.org>,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...glegroups.com,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Ondrej Jirman <megous@...ous.com>, devicetree@...r.kernel.org
Subject: Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

Dne četrtek, 17. junij 2021 ob 17:42:42 CEST je Maxime Ripard napisal(a):
> On Wed, Jun 16, 2021 at 11:06:30AM +0100, Andre Przywara wrote:
> > > > +	reserved-memory {
> > > > +		#address-cells = <2>;
> > > > +		#size-cells = <2>;
> > > > +		ranges;
> > > > +
> > > > +		/* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > +		secmon_reserved: secmon@...00000 {
> > > > +			reg = <0x0 0x40000000 0x0 0x80000>;
> > > > +			no-map;
> > > > +		};
> > > > +	};
> > > 
> > > Can't this be added by ATF directly?
> > 
> > It actually is, and if you use U-Boot's DT ($fdtcontroladdr), that
> > actually works. But as it stands right now, U-Boot fails to propagate
> > this to any DTB that gets *loaded*. Fixing this requires generic code
> > fixes, so I can't just hack this in for sunxi quickly.
> > So I wanted to keep this around for a while, as missing this is a
> > showstopper for booting Linux.
> 
> It looks like we didn't need it for the H6, what makes it any different?

H616 TF-A resides in DRAM and H6 resides in SRAM A2 (IIRC). H616 has much less 
useful SRAM due to ARISC removal.

Best regards,
Jernej

> 
> > > > +		mmc0: mmc@...0000 {
> > > > +			compatible = "allwinner,sun50i-h616-mmc",
> > > > +				     "allwinner,sun50i-a100-
mmc";
> > > > +			reg = <0x04020000 0x1000>;
> > > > +			clocks = <&ccu CLK_BUS_MMC0>, <&ccu 
CLK_MMC0>;
> > > > +			clock-names = "ahb", "mmc";
> > > > +			resets = <&ccu RST_BUS_MMC0>;
> > > > +			reset-names = "ahb";
> > > > +			interrupts = <GIC_SPI 35 
IRQ_TYPE_LEVEL_HIGH>;
> > > > +			pinctrl-names = "default";
> > > > +			pinctrl-0 = <&mmc0_pins>;
> > > > +			status = "disabled";
> > > > +			max-frequency = <150000000>;
> > > > +			cap-sd-highspeed;
> > > > +			cap-mmc-highspeed;
> > > > +			mmc-ddr-3_3v;
> > > > +			mmc-ddr-1_8v;
> > > 
> > > This is not something you know in the DTSI? It entirely depends on how
> > > the board has been designed.
> > 
> > Are you referring just to the last property?
> 
> Initially, yes, but the argument is for both...
> 
> > This is copying what the driver unconditionally sets for the other
> > 
> > SoCs at the moment (minus the H5 screwup):
> > 	mmc->caps      |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
> > 
> > IIUC 1.8V operation requires a 1.8V regulator for vqmmc to actually
> > work, so this property alone won't enable anything.
> > But if it's just about the 1.8V property, I can of course move this to
> > the board dts files.
> 
> ... Since we've seen boards with only 3.3v or 1.8v wired to vqmmc, so we
> should really just push this to the boards for new SoCs
> 
> Maxime