| 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
| ||
|
Message-ID: <1537954469.18381.0.camel@mtkswgap22>
Date: Wed, 26 Sep 2018 17:34:29 +0800
From: Ryder Lee <ryder.lee@...iatek.com>
To: Matthias Brugger <matthias.bgg@...il.com>
CC: CK Hu <ck.hu@...iatek.com>, Rob Herring <robh+dt@...nel.org>,
Sean Wang <sean.wang@...iatek.com>,
Roy Luo <cheng-hao.luo@...iatek.com>,
Weijie Gao <weijie.gao@...iatek.com>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-mediatek@...ts.infradead.org>,
chunhui dai <chunhui.dai@...iatek.com>,
Bibby Hsieh <bibby.hsieh@...iatek.com>
Subject: Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem
related device nodes
On Wed, 2018-09-26 at 10:50 +0200, Matthias Brugger wrote:
>
> On 26/09/2018 07:21, CK Hu wrote:
> > Hi, Ryder:
> >
> > On Wed, 2018-09-26 at 10:38 +0800, Ryder Lee wrote:
> >> On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote:
> >>> Hi, Ryder:
> >>>
> >>> On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote:
> >>>> Add display subsystem related device nodes for MT7623.
> >>>>
> >>>> Cc: CK Hu <ck.hu@...iatek.com>
> >>>> Signed-off-by: chunhui dai <chunhui.dai@...iatek.com>
> >>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@...iatek.com>
> >>>> Signed-off-by: Ryder Lee <ryder.lee@...iatek.com>
> >>>> ---
> >>>> I forgot to sort nodes in my previous mail. Sorry for the inconvenience.
> >>>>
> >>>> This patch depends on the series: https://lkml.org/lkml/2018/9/5/223
> >>>>
> >>>> @Matthias,
> >>>> I know you're working on broken MMSYS - just want to ask whether it's possible
> >>>> to let the patch to go to your tree (if others are okay with it), and send a
> >>>> fixup one for MT7623 MMSYS later?
> >>>> ---
> >>>> arch/arm/boot/dts/mt7623.dtsi | 177 ++++++++++++++++++++++++++
> >>>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83 ++++++++++++
> >>>> arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 83 ++++++++++++
> >>>> 3 files changed, 343 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> >>>> index d01bdee..fdf9078 100644
> >>>> --- a/arch/arm/boot/dts/mt7623.dtsi
> >>>> +++ b/arch/arm/boot/dts/mt7623.dtsi
> >>>> @@ -23,6 +23,11 @@
> >>>> #address-cells = <2>;
> >>>> #size-cells = <2>;
> >>>>
> >>>> + aliases {
> >>>> + rdma0 = &rdma0;
> >>>> + rdma1 = &rdma1;
> >>>> + };
> >>>> +
> >>>> cpu_opp_table: opp-table {
> >>>> compatible = "operating-points-v2";
> >>>> opp-shared;
> >>>> @@ -311,6 +316,25 @@
> >>>> clock-names = "spi", "wrap";
> >>>> };
> >>>>
> >>>> + mipi_tx0: mipi-dphy@...10000 {
> >>>> + compatible = "mediatek,mt7623-mipi-tx",
> >>>> + "mediatek,mt2701-mipi-tx";
> >>>> + reg = <0 0x10010000 0 0x90>;
> >>>> + clocks = <&clk26m>;
> >>>> + clock-output-names = "mipi_tx0_pll";
> >>>> + #clock-cells = <0>;
> >>>> + #phy-cells = <0>;
> >>>> + };
> >>>> +
> >>>> + cec: cec@...12000 {
> >>>> + compatible = "mediatek,mt7623-cec",
> >>>> + "mediatek,mt8173-cec";
> >>>> + reg = <0 0x10012000 0 0xbc>;
> >>>> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>;
> >>>> + clocks = <&infracfg CLK_INFRA_CEC>;
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> cir: cir@...13000 {
> >>>> compatible = "mediatek,mt7623-cir";
> >>>> reg = <0 0x10013000 0 0x1000>;
> >>>> @@ -359,6 +383,18 @@
> >>>> #clock-cells = <1>;
> >>>> };
> >>>>
> >>>> + hdmi_phy: phy@...09100 {
> >>>> + compatible = "mediatek,mt7623-hdmi-phy",
> >>>> + "mediatek,mt2701-hdmi-phy";
> >>>> + reg = <0 0x10209100 0 0x24>;
> >>>> + clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
> >>>> + clock-names = "pll_ref";
> >>>> + clock-output-names = "hdmitx_dig_cts";
> >>>> + #clock-cells = <0>;
> >>>> + #phy-cells = <0>;
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> rng: rng@...0f000 {
> >>>> compatible = "mediatek,mt7623-rng";
> >>>> reg = <0 0x1020f000 0 0x1000>;
> >>>> @@ -558,6 +594,16 @@
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>> + hdmiddc0: i2c@...13000 {
> >>>> + compatible = "mediatek,mt7623-hdmi-ddc",
> >>>> + "mediatek,mt8173-hdmi-ddc";
> >>>> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
> >>>> + reg = <0 0x11013000 0 0x1C>;
> >>>> + clocks = <&pericfg CLK_PERI_I2C3>;
> >>>> + clock-names = "ddc-i2c";
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> nor_flash: spi@...14000 {
> >>>> compatible = "mediatek,mt7623-nor",
> >>>> "mediatek,mt8173-nor";
> >>>> @@ -732,6 +778,84 @@
> >>>> #clock-cells = <1>;
> >>>> };
> >>>>
> >>>> + display_components: dispsys@...00000 {
> >>>> + compatible = "mediatek,mt7623-mmsys",
> >>>
> >>> Checkpatch warning:
> >>>
> >>> WARNING: DT compatible string "mediatek,mt7623-mmsys" appears
> >>> un-documented -- check ./Documentation/devicetree/bindings/
> >>> #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782:
> >>> + compatible = "mediatek,mt7623-mmsys",
> >>>
> >>>
> >>>> + "mediatek,mt2701-mmsys";
> >>>> + reg = <0 0x14000000 0 0x1000>;
> >>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> >>>> + };
> >>>> +
> >>>> + ovl@...07000 {
> >>>> + compatible = "mediatek,mt7623-disp-ovl",
> >>>
> >>> I think this is also un-documented, but I don't know why checkpatch does
> >>> not show any warning.
> >>>
> >>> Regards,
> >>> CK
> >>>> + "mediatek,mt2701-disp-ovl";
> >>>> + reg = <0 0x14007000 0 0x1000>;
> >>>> + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
> >>>> + clocks = <&mmsys CLK_MM_DISP_OVL>;
> >>>> + iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>;
> >>>> + mediatek,larb = <&larb0>;
> >>>> + };
> >>>> +
> >>
> >> I fallback to use the MT2701's compatible string here and there, but I
> >> could add a new one for MT7623.
> >>
> >> BTW, I've had this question for a long time - should I add a new
> >> compatible for the very same IPs, or could we just use the old one in
> >> DTS?
> >>
> >> Ryder
> >>
> >
> > From [1], there is a description for the multiple compatible string
> > scheme:
> >
> > ====
> > The reasoning behind this scheme is the observation that in the majority
> > of cases, a single machine_desc can support a large number of boards
> > if they all use the same SoC, or same family of SoCs. However,
> > invariably there will be some exceptions where a specific board will
> > require special setup code that is not useful in the generic case.
> > Special cases could be handled by explicitly checking for the
> > troublesome board(s) in generic setup code, but doing so very quickly
> > becomes ugly and/or unmaintainable if it is more than just a couple of
> > cases.
> >
> > Instead, the compatible list allows a generic machine_desc to provide
> > support for a wide common set of boards by specifying "less
> > compatible" values in the dt_compat list. In the example above,
> > generic board support can claim compatibility with "ti,omap3" or
> > "ti,omap3450". If a bug was discovered on the original beagleboard
> > that required special workaround code during early boot, then a new
> > machine_desc could be added which implements the workarounds and only
> > matches on "ti,omap3-beagleboard".
> > ====
> >
> > I don't know would there be a problem happened only in MT7623 even
> > though this hardware is identical in both MT2701 and MT7623. Maybe the
> > system-wide configuration would influence this driver. So the easy way
> > is to add the compatible string for MT7623. If you could prove that
> > this driver would never be influenced by system-wide configuration,
> > using only MT2701 compatible string is acceptable for me.
> >
> > This is my opinion, but the most important is maintainer's opinion.
> >
>
> The compatible string looks good. But you should update the binding documentation :)
Okay, I will update it.
> Regards,
> Matthias
Powered by blists - more mailing lists