| 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: <67eb0b9c-f2a3-a9c4-202f-d3c64b6a2b3e@gmail.com>
Date: Wed, 26 Sep 2018 10:50:13 +0200
From: Matthias Brugger <matthias.bgg@...il.com>
To: CK Hu <ck.hu@...iatek.com>, Ryder Lee <ryder.lee@...iatek.com>
Cc: 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 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 :)
Regards,
Matthias
Powered by blists - more mailing lists