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: <CAAOTY__4Qs93EMjrpK_jW4NsxyZf7w3RHa7vDSRecea_JwAxKw@mail.gmail.com>
Date:   Tue, 11 Aug 2020 07:28:25 +0800
From:   Chun-Kuang Hu <chunkuang.hu@...nel.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Chun-Kuang Hu <chunkuang.hu@...nel.org>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        devicetree@...r.kernel.org, Ryder Lee <ryder.lee@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Frank Wunderlich <linux@...web.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi

Hi, David:

David Woodhouse <dwmw2@...radead.org> 於 2020年8月10日 週一 下午3:48寫道:
>
> On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote:
> > I would like to put all device in mt7623.dtsi with some device's
> > status is "disabled" and change its status in platform dtsi.
> > I would like to see all device in mt7623.dtsi because of its name. If
> > you move some device to platform dtsi, we would trace all platform
> > dtsi to find out how many device in mt7623. One day a new platform
> > enable different devices, you would reorganize all these platform
> > dtsi?
>
> No, this isn't "platform dtsi", surely? This is mt7623a and mt7623n
> dtsi for the two different SoCs, and platforms then just include
> mt7623a.dtsi or mt7623n.dtsi as appropriate for the SoC they are using.
>
> If you really want *all* the nodes for both MT7623A and MT7623N chips
> in a single mt7623.dtsi but disabled, could we still have mt7623a.dtsi
> and mt7623n.dtsi for the chips, enabling the nodes that are only-for-A
> or only-for-N, so that each platform doesn't have to do that for
> itself?
>
> Although putting those nodes that exist only in one chip or the other
> directly into the mt7623[an].dtsi still seems to make more sense to
> me.

Sorry I does not notice that mt7623a and mt7623n are different SoC.
Because they are different SoC, I think the first step is to upstream
mt7623a.dtsi and mt7623n.dtsi independently. That means in each dtsi,
it include all devices of its SoC. After both dtsi is upsteamed, we
could find out what is the common part, then we create a common dtsi
these two SoC, for example mt7623a_mt7623n_common.dtsi. (Maybe there
is a SoC's name is exactly 'mt7623', so I prefer mt7623.dtsi is
reserved for that SoC, and mt7623_common.dtsi is not preferred because
I don't know there are how many mt7623 family SoC and
mt7623_common.dtsi should be use for all mt7623 family)

Regards,
Chun-Kuang.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ