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:42:42 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Andre Przywara <andre.przywara@....com>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        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

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?

> > > +		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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)