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]
Message-ID: <20190408124645.gv2tezjqhoxxx2yg@core.my.home>
Date:   Mon, 8 Apr 2019 14:46:45 +0200
From:   Ondřej Jirman <megous@...ous.com>
To:     Jagan Teki <jagan@...rulasolutions.com>
Cc:     Clément Péron <peron.clem@...il.com>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Mark Rutland <mark.rutland@....com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S. Miller" <davem@...emloft.net>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Naveen Gupta <naveen.gupta@...ress.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
        linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        brcm80211-dev-list@...ress.com, linux-gpio@...r.kernel.org
Subject: Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3

Hi Jagan,

On Mon, Apr 08, 2019 at 11:31:22AM +0530, Jagan Teki wrote:
> On Sun, Apr 7, 2019 at 8:02 PM 'Ondřej Jirman' via linux-sunxi
> <linux-sunxi@...glegroups.com> wrote:
> >
> > On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote:
> > > Hi,
> > >
> > > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> > > <linux-sunxi@...glegroups.com> wrote:
> > > >
> > > > From: Ondrej Jirman <megous@...ous.com>
> > > >
> > > > This series implements support for Xunlong Orange Pi 3 board.
> > >
> > > OrangePi 3 Lite2 and One Plus boards support has already been merged.
> > > The support is not complete but you should rebase your patches on top
> > > of sunxi/for-next
> >
> > Hi,
> >
> > OrangePi 3 is somewhat different from these two boards (mostly it has a differnt
> > power tree). It doesn't use the AXP regulators that are defined in the
> > sun50i-h6-orangepi.dtsi in the same way.
> >
> > For example:
> >
> > - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3)
> > - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi
> > - aldo3 is not for dram
> > - bldo1 on the other hand is for dram on opi3
> > - some other regulators are used for different/more functions and thus
> >   named differntly
> > - USB id-det pin is differnt
> > - ...
> 
> Based on my communication with OrangePI, OPI-3 has PCIE, 4 USB-3.0
> ports and AV are the key differences and rest seems to be similar. but
> if we have a diff or unused regulators may be we can't enable them in
> dtsi (I never looked that close as of now)

These regulators are not just disabled on Opi 3, they have different/no meaning.

Schematics allow for high amount of variability in the power tree (see all the
NC (not connected) / 0R resistors) in the schematic around AXP805. Every board
based on this Xunlong design can be subtly different. 

I already suggested a maintainable solution, below. Where base dtsi has empty
config for regulators and every board based on that just defines it completely
for itself.

A few regulators (for CPU/GPU) will most probably have the same meaning on every
derived board, so these can probably be kept in dtsi without causing too much
annoyance.

It's unpleasant to have wrong regulator setup defined in an underlying dtsi, and
then trying to override it by removing/adding random properties in the board dts
for the new boards based on that, so that it fits.

The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be
shared (as of now).

thank you and regards,
  o.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ