| 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
| ||
|
Date: Tue, 17 May 2022 17:44:07 +0800
From: Yong Wu <yong.wu@...iatek.com>
To: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Krzysztof Kozlowski <krzk@...nel.org>
CC: <krzysztof.kozlowski@...aro.org>, <robh+dt@...nel.org>,
<matthias.bgg@...il.com>, <linux-mediatek@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<konrad.dybcio@...ainline.org>, <marijn.suijten@...ainline.org>,
<martin.botka@...ainline.org>,
<~postmarketos/upstreaming@...ts.sr.ht>,
<phone-devel@...r.kernel.org>, <paul.bouchara@...ainline.org>,
<kernel@...labora.com>, <yi.kuo@...iatek.com>,
<anthony.huang@...iatek.com>, <wendy-st.lin@...iatek.com>
Subject: Re: [PATCH v2 2/2] memory: mtk-smi: Add support for MT6795 Helio X10
On Tue, 2022-05-17 at 10:27 +0200, AngeloGioacchino Del Regno wrote:
> Il 17/05/22 08:37, Yong Wu ha scritto:
> > On Fri, 2022-05-13 at 17:06 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > The MediaTek Helio X10 (MT6795) SoC has 5 LARBs and one common
> > > SMI
> > > instance without any sub-common and without GALS.
> > >
> > > While the smi-common configuration is specific to this SoC, on
> > > the
> > > LARB side, this is similar to MT8173, in the sense that it
> > > doesn't
> > > need the port in LARB, and the register layout is also compatible
> > > with that one, which makes us able to fully reuse the smi-larb
> > > platform data struct that was introduced for MT8173.
> > >
> > > Signed-off-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno@...labora.com>
> > > ---
> > > drivers/memory/mtk-smi.c | 17 +++++++++++++++++
> > > 1 file changed, 17 insertions(+)
> > >
> > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> > > index 86a3d34f418e..7e7c3ede19e4 100644
> > > --- a/drivers/memory/mtk-smi.c
> > > +++ b/drivers/memory/mtk-smi.c
> > > @@ -21,11 +21,13 @@
> > > /* SMI COMMON */
> > > #define SMI_L1LEN 0x100
> > >
> > > +#define SMI_L1_ARB 0x200
> > > #define SMI_BUS_SEL 0x220
> > > #define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
> > > /* All are MMU0 defaultly. Only specialize mmu1 here. */
> > > #define F_MMU1_LARB(larbid) (0x1 <<
> > > SMI_BUS_LARB_SHIFT(larbid))
> > >
> > > +#define SMI_FIFO_TH0 0x230
> >
> > Does the name come from the coda you got?
> > It is called SMI_READ_FIFO_TH in my coda.
> >
>
> Documentation for this SoC is not public and I have no access to it,
> so
> everything that you see here comes from reading downstream kernel
> code :-(
>
> I'll change the name to SMI_READ_FIFO_TH as suggested, thanks!
>
> > > #define SMI_M4U_TH 0x234
> > > #define SMI_FIFO_TH1 0x238
> > > #define SMI_FIFO_TH2 0x23c
> > > @@ -360,6 +362,7 @@ static const struct of_device_id
> > > mtk_smi_larb_of_ids[] = {
> > > {.compatible = "mediatek,mt2701-smi-larb", .data =
> > > &mtk_smi_larb_mt2701},
> > > {.compatible = "mediatek,mt2712-smi-larb", .data =
> > > &mtk_smi_larb_mt2712},
> > > {.compatible = "mediatek,mt6779-smi-larb", .data =
> > > &mtk_smi_larb_mt6779},
> > > + {.compatible = "mediatek,mt6795-smi-larb", .data =
> > > &mtk_smi_larb_mt8173},
> > > {.compatible = "mediatek,mt8167-smi-larb", .data =
> > > &mtk_smi_larb_mt8167},
> > > {.compatible = "mediatek,mt8173-smi-larb", .data =
> > > &mtk_smi_larb_mt8173},
> > > {.compatible = "mediatek,mt8183-smi-larb", .data =
> > > &mtk_smi_larb_mt8183},
> > > @@ -541,6 +544,13 @@ static struct platform_driver
> > > mtk_smi_larb_driver = {
> > > }
> > > };
> > >
> > > +static const struct mtk_smi_reg_pair
> > > mtk_smi_common_mt6795_init[SMI_COMMON_INIT_REGS_NR] = {
> > > + {SMI_L1_ARB, 0x1b},
> > > + {SMI_M4U_TH, 0xce810c85},
> > > + {SMI_FIFO_TH1, 0x43214c8},
> > > + {SMI_FIFO_TH0, 0x191f},
> > > +};
> > > +
> > > static const struct mtk_smi_reg_pair
> > > mtk_smi_common_mt8195_init[SMI_COMMON_INIT_REGS_NR] = {
> > > {SMI_L1LEN, 0xb},
> > > {SMI_M4U_TH, 0xe100e10},
> > > @@ -565,6 +575,12 @@ static const struct mtk_smi_common_plat
> > > mtk_smi_common_mt6779 = {
> > > F_MMU1_LARB(5) | F_MMU1_LARB(6) |
> > > F_MMU1_LARB(7),
> > > };
> > >
> > > +static const struct mtk_smi_common_plat mtk_smi_common_mt6795 =
> > > {
> > > + .type = MTK_SMI_GEN2,
> > > + .bus_sel = BIT(0),
> >
> > Like the other larbs, use F_MMU1_LARB(0) here?
> >
>
> I agree that F_MMU1_LARB(0) == (1 << (0 << 1)) == BIT(0), but that
> would
> not be correct and induce other people to mistake, I think?
F_MMU1_LARB(x) means larbx enter MMU1. this is correct for me.
OK. Maybe the macro name is not good. About the macro background,
please see:
567e58cf96dd (memory: mtk-smi: Add bus_sel for mt8183)
If you have better name for this, please tell me:)
> Downstream doesn't do MMU1 bits, but MMU0 in this case... but if you
> can
> check on internal documentation and confirm that the downstream
> kernel's
> logic is wrong on that - and that you've verified that this should
I don't know the detailed downstream code, But I find a internal branch
about this SoC. I see the bus_sel did set to 0x1 as you did here. thus
I don't think the downstream kernel is wrong. 0x1 means larb0 enter
MMU1 while the others still enter MMU0. we could use F_MMU1_LARB(0)
here.
> indeed
> be F_MMU1_LARB(x), you'll get a big(bigger) thank you from me :-)
>
> Meanwhile...
>
> Thanks!
> Angelo
>
> >
> > After the two changes,
> >
> > Reviewed-by: Yong Wu <yong.wu@...iatek.com>
> >
> > Thanks.
Powered by blists - more mailing lists