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, 11 Feb 2020 08:09:57 +0100
From:   Jernej Škrabec <jernej.skrabec@...l.net>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     wens@...e.org, robh+dt@...nel.org, mark.rutland@....com,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [PATCH v2] arm64: dts: allwinner: h6: orangepi-3: Add eMMC node

Hi!

Dne torek, 11. februar 2020 ob 07:51:41 CET je Maxime Ripard napisal(a):
> On Mon, Feb 10, 2020 at 06:40:07PM +0100, Jernej Skrabec wrote:
> > OrangePi 3 can optionally have 8 GiB eMMC (soldered on board). Because
> > those pins are dedicated to eMMC exclusively, node can be added for both
> > variants (with and without eMMC). Kernel will then scan bus for presence
> > of eMMC and act accordingly.
> > 
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> > ---
> > Changes since v1:
> > - don't make separate DT just for -emmc variant - add node to existing
> > 
> >   orangepi 3 DT
> >  
> >  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts index
> > c311eee52a35..1e0abd9d047f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -144,6 +144,15 @@ brcm: sdio-wifi@1 {
> > 
> >  	};
> >  
> >  };
> > 
> > +&mmc2 {
> > +	vmmc-supply = <&reg_cldo1>;
> > +	vqmmc-supply = <&reg_bldo2>;
> > +	cap-mmc-hw-reset;
> > +	non-removable;
> 
> Given that non-removable is documented as "Non-removable slot (like
> eMMC); assume always present.", we should probably get rid of that
> property?

I checked mmc core code and this property means that bus will be scanned only 
once. In this form, node doesn't tell what kind of device is connected, so 
core has to scan it no matter if "non-removable" property is present or not. I 
maybe missed something though, so it would be great if someone can check it 
again.

Best regards,
Jernej


Powered by blists - more mailing lists