From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 706DCC433E7 for ; Thu, 8 Oct 2020 09:41:34 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CDB882177B for ; Thu, 8 Oct 2020 09:41:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kKhyXYtn"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="tzXB51Oz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDB882177B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=g3xWx7u5p8GfKPHjoVzZGZaRAC4zzb/8GiDfXPQsPak=; b=kKhyXYtnbTSIjCcbL/oKyt8ic jTeQhtq9v0F0NTK96wufASlAhsKEJA6S69qB3gtnHuF7t25tU6MShwMG77HCLjyxQNexn6unJyCIt V49f1m5AmcwSpmGoWwFScZwQN3OJYo3TXrlJkOujkAKkF5DcoD6E346+TdKndE7BgIHlv2cAWwG80 Kuwl/JTZmYtR7Zmlw0tIYJYPmlujQsAdwJx8kO4hiTSeGSoxUUuubCxGJn4EUneIiKuN+VUS3tycU beH/Qo/2f7O/wMZpz0cLhPsiCGKOSLE8JrF+mrexS22GedL9jtganba27CagaJ8rbVqpsk605OWo3 yGAUZEM5Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQSQN-0003Ub-Qi; Thu, 08 Oct 2020 09:41:23 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQSQH-0003SO-2G; Thu, 08 Oct 2020 09:41:19 +0000 X-UUID: f8c84fc60ed74c0497977fbeca52adda-20201008 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=1Ozpz9ZghRPEXVmLBbry4bfJslMm3ymiwvO7V65jL04=; b=tzXB51OzKySlCiBO0Wd9bdQ4yBhYUf+ofawiHI8M9urGyTi5ysFvhaKM3hsNYWwxbeafQVW38AhoHUqn7JJXzkSdU1O+t6Qz9hD4nFA3TiUkSC29Rqi2SOvBcsMu900WBYbi6c8PjMrbjnoN9BIXuKQoQEw0MkdVY0VRq+1TyAg=; X-UUID: f8c84fc60ed74c0497977fbeca52adda-20201008 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 359686759; Thu, 08 Oct 2020 01:41:09 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 02:39:33 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 17:39:24 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 17:39:25 +0800 Message-ID: <1602149965.8784.6.camel@mtkswgap22> Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver From: Neal Liu To: Matthias Brugger Date: Thu, 8 Oct 2020 17:39:25 +0800 In-Reply-To: References: <1598497593-15781-1-git-send-email-neal.liu@mediatek.com> <1598497593-15781-3-git-send-email-neal.liu@mediatek.com> <1602124514.28301.17.camel@mtkswgap22> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_054117_341817_8DDF2AF9 X-CRM114-Status: GOOD ( 44.19 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chun-Kuang Hu , wsd_upstream@mediatek.com, devicetree@vger.kernel.org, lkml , Rob Herring , linux-mediatek@lists.infradead.org, Neal Liu , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote: > > On 08/10/2020 04:35, Neal Liu wrote: > > On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote: > >> > >> On 27/08/2020 05:06, Neal Liu wrote: > >>> MediaTek bus fabric provides TrustZone security support and data > >>> protection to prevent slaves from being accessed by unexpected > >>> masters. > >>> The security violation is logged and sent to the processor for > >>> further analysis or countermeasures. > >>> > >>> Any occurrence of security violation would raise an interrupt, and > >>> it will be handled by mtk-devapc driver. The violation > >>> information is printed in order to find the murderer. > >> > >> "The violation information is printed in order to find the responsible component." > >> > >> Nobody got actually killed, right :) > > > > Correct ! > >> > >>> > >>> Signed-off-by: Neal Liu > >>> --- > >>> drivers/soc/mediatek/Kconfig | 9 ++ > >>> drivers/soc/mediatek/Makefile | 1 + > >>> drivers/soc/mediatek/mtk-devapc.c | 305 +++++++++++++++++++++++++++++++++++++ > >>> 3 files changed, 315 insertions(+) > >>> create mode 100644 drivers/soc/mediatek/mtk-devapc.c > >>> > >>> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > >>> index 59a56cd..1177c98 100644 > >>> --- a/drivers/soc/mediatek/Kconfig > >>> +++ b/drivers/soc/mediatek/Kconfig > >>> @@ -17,6 +17,15 @@ config MTK_CMDQ > >>> time limitation, such as updating display configuration during the > >>> vblank. > >>> > >>> +config MTK_DEVAPC > >>> + tristate "Mediatek Device APC Support" > >>> + help > >>> + Say yes here to enable support for Mediatek Device APC driver. > >>> + This driver is mainly used to handle the violation which catches > >>> + unexpected transaction. > >>> + The violation information is logged for further analysis or > >>> + countermeasures. > >>> + > >>> config MTK_INFRACFG > >>> bool "MediaTek INFRACFG Support" > >>> select REGMAP > >>> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > >>> index 01f9f87..abfd4ba 100644 > >>> --- a/drivers/soc/mediatek/Makefile > >>> +++ b/drivers/soc/mediatek/Makefile > >>> @@ -1,5 +1,6 @@ > >>> # SPDX-License-Identifier: GPL-2.0-only > >>> obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > >>> +obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o > >>> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o > >>> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > >>> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > >>> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c > >>> new file mode 100644 > >>> index 0000000..0ba61d7 > >>> --- /dev/null > >>> +++ b/drivers/soc/mediatek/mtk-devapc.c > >>> @@ -0,0 +1,305 @@ > >>> +// SPDX-License-Identifier: GPL-2.0 > >>> +/* > >>> + * Copyright (C) 2020 MediaTek Inc. > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#define VIO_MOD_TO_REG_IND(m) ((m) / 32) > >>> +#define VIO_MOD_TO_REG_OFF(m) ((m) % 32) > >>> + > >>> +struct mtk_devapc_vio_dbgs { > >>> + union { > >>> + u32 vio_dbg0; > >>> + struct { > >>> + u32 mstid:16; > >>> + u32 dmnid:6; > >>> + u32 vio_w:1; > >>> + u32 vio_r:1; > >>> + u32 addr_h:4; > >>> + u32 resv:4; > >>> + } dbg0_bits; > >>> + }; > >>> + > >>> + u32 vio_dbg1; > >>> +}; > >>> + > >>> +struct mtk_devapc_data { > >>> + u32 vio_idx_num; > >>> + u32 vio_mask_offset; > >>> + u32 vio_sta_offset; > >>> + u32 vio_dbg0_offset; > >>> + u32 vio_dbg1_offset; > >>> + u32 apc_con_offset; > >>> + u32 vio_shift_sta_offset; > >>> + u32 vio_shift_sel_offset; > >>> + u32 vio_shift_con_offset; > >>> +}; > >> > >> Please describe the fields of the struct, that will make it easier to understand > >> the driver. > > > > Okay, I'll try to add more description about this struct. May be like: > > > > struct mtk_devapc_data { > > /* numbers of violation index */ > > u32 vio_idx_num; > > > > /* reg offset */ > > u32 vio_mask_offset; > > u32 vio_sta_offset; > > u32 vio_dbg0_offset; > > u32 vio_dbg1_offset; > > u32 apc_con_offset; > > u32 vio_shift_sta_offset; > > u32 vio_shift_sel_offset; > > u32 vio_shift_con_offset; > > }; > > > >> > >>> + > >>> +struct mtk_devapc_context { > >>> + struct device *dev; > >>> + void __iomem *infra_base; > >>> + struct clk *infra_clk; > >>> + const struct mtk_devapc_data *data; > >>> +}; > >>> + > >>> +static void clear_vio_status(struct mtk_devapc_context *ctx) > >>> +{ > >>> + void __iomem *reg; > >>> + int i; > >>> + > >>> + reg = ctx->infra_base + ctx->data->vio_sta_offset; > >>> + > >>> + for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++) > >>> + writel(GENMASK(31, 0), reg + 4 * i); > >>> + > >>> + writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), 0), > >>> + reg + 4 * i); > >>> +} > >>> + > >>> +static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask) > >>> +{ > >>> + void __iomem *reg; > >>> + u32 val; > >>> + int i; > >>> + > >>> + reg = ctx->infra_base + ctx->data->vio_mask_offset; > >>> + > >>> + if (mask) > >>> + val = GENMASK(31, 0); > >>> + else > >>> + val = 0; > >>> + > >>> + for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++) > >> > >> Do I get that right? We have a number of virtual IO identifier. Their > >> correspondending interrupt are grouped in 32 bit registers. And we want to > >> enable/disable them by writing 0 or 1. We have to take care of the last > >> registers as it could be the case that vio_idx_num is not a multiple of 32, correct? > >> > >> In this case we should traverse VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1 > >> registers, which is (vio_idx_num / 32) - 1 and not (vio_idx_num - 1) / 32. > >> > > > > Yes, your understanding is correct. It should be > > VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1 instead of > > VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1). > > > >>> + writel(val, reg + 4 * i); > >>> + > >>> + val = readl(reg + 4 * i); > >>> + if (mask) > >>> + val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), > >>> + 0); > >> > >> We have 511 IRQs, which gives us 31 bits in the last register to set/unset. > >> Thats 510..0 bits, so from what I understand, once again we want > >> GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0) > >> which is (vio_idx_num % 32) - 1 > >> > >> Correct or do I understand something wrong? > >> If so, same applies to clear_vio_status(). > >> > > > > Correct. I'll fix it on next patch. > > Thanks > > > >> > >>> + else > >>> + val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), > >>> + 0); > >>> + > >>> + writel(val, reg + 4 * i); > >>> +} > >>> + > >>> +#define PHY_DEVAPC_TIMEOUT 0x10000 > >>> + > >>> +/* > >>> + * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation information. > >>> + * shift mechanism is depends on devapc hardware design. > >>> + * Mediatek devapc set multiple slaves as a group. > >>> + * When violation is triggered, violation info is kept > >>> + * inside devapc hardware. > >>> + * Driver should do shift mechansim to sync full violation > >>> + * info to VIO_DBGs registers. > >>> + * > >>> + */ > >>> +static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx) > >>> +{ > >>> + void __iomem *pd_vio_shift_sta_reg; > >>> + void __iomem *pd_vio_shift_sel_reg; > >>> + void __iomem *pd_vio_shift_con_reg; > >>> + int min_shift_group; > >>> + int ret; > >>> + u32 val; > >>> + > >>> + pd_vio_shift_sta_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_sta_offset; > >>> + pd_vio_shift_sel_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_sel_offset; > >>> + pd_vio_shift_con_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_con_offset; > >>> + > >>> + /* Find the minimum shift group which has violation */ > >>> + val = readl(pd_vio_shift_sta_reg); > >>> + if (!val) > >>> + return false; > >> > >> So bit 0 of selection register (pd_vio_shift_sel_reg) does not represent a > >> violation group? > >> I don't know how the HW works, but is seems odd to me. In case that's bit 0 > >> actually doesn't represent anything: how can an interrupt be triggered without > >> any debug information present (means val == 0)? > > > > This check implies HW status has something wrong. It cannot get any > > debug information for this case. > > It won't happen in normal scenario. Should we remove this check? > > > > No I think the check is fine. I'd add a WARN() message as this is an indicator > that the HW is not working corretly. Sure. add WARN() message is more helpful to understand. I'll add it on next patch. Thanks > > >> > >>> + > >>> + min_shift_group = __ffs(val); > >>> + > >>> + /* Assign the group to sync */ > >>> + writel(0x1 << min_shift_group, pd_vio_shift_sel_reg); > >>> + > >>> + /* Start syncing */ > >>> + writel(0x1, pd_vio_shift_con_reg); > >>> + > >>> + ret = readl_poll_timeout(pd_vio_shift_con_reg, val, val == 0x3, 0, > >>> + PHY_DEVAPC_TIMEOUT); > >>> + if (ret) { > >>> + dev_err(ctx->dev, "%s: Shift violation info failed\n", __func__); > >> > >> In which case this can happen? I'm asking, because we are calling > >> devapc_sync_vio_dbg() in a while loop that could make the kernel hang here. > >> > >> Do I understand correctly, that we are using the while loop, because there can > >> be more then one violation group which got triggered (read, more then one bit is > >> set in pd_vio_shift_sta_reg)? Would it make more sense then to read the register > >> once and do all the shift operation for all groups which bit set to 1 in the > >> shift status register? > > > > Yes, your understanding is correct. > > This check also implies HW status has something wrong. We return false > > to skip further violation info dump. > > How could this case make the kernel hang? > > > > The kernel can't hang, sorry my fault. In any case I'd add a WARN() here as > well. I understand that if we error out here, we have a HW/FW bug (my feeling > is, that behind this is a micro controller of some kind :) > I'll also add warn messages on next patch. > >> > >>> + return false; > >>> + } > >>> + > >>> + /* Stop syncing */ > >>> + writel(0x0, pd_vio_shift_con_reg); > >>> + > >>> + /* Write clear */ > >>> + writel(0x1 << min_shift_group, pd_vio_shift_sta_reg); > >>> + > >>> + return true; > >>> +} > >>> + > >>> +/* > >>> + * devapc_extract_vio_dbg - extract full violation information after doing > >>> + * shift mechanism. > >>> + */ > >>> +static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx) > >>> +{ > >>> + struct mtk_devapc_vio_dbgs vio_dbgs; > >>> + void __iomem *vio_dbg0_reg; > >>> + void __iomem *vio_dbg1_reg; > >>> + > >>> + vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset; > >>> + vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset; > >>> + > >>> + vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg); > >>> + vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg); > >>> + > >>> + /* Print violation information */ > >>> + if (vio_dbgs.dbg0_bits.vio_w) > >>> + dev_info(ctx->dev, "Write Violation\n"); > >>> + else if (vio_dbgs.dbg0_bits.vio_r) > >>> + dev_info(ctx->dev, "Read Violation\n"); > >>> + > >>> + dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n", > >>> + vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid, > >>> + vio_dbgs.vio_dbg1); > >>> +} > >>> + > >>> +/* > >>> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will dump > >>> + * violation information including which master violates > >>> + * access slave. > >>> + */ > >>> +static irqreturn_t devapc_violation_irq(int irq_number, > >>> + struct mtk_devapc_context *ctx) > >> > >> static irqreturn_t devapc_violation_irq(int irq_number, void *data) > >> { > >> struct mtk_devapc_context *ctx = data; > > > > Okay, I'll fix it on next patch. > > Thanks > > > >> > >>> +{ > >>> + while (devapc_sync_vio_dbg(ctx)) > >>> + devapc_extract_vio_dbg(ctx); > >>> + > >>> + clear_vio_status(ctx); > >>> + > >>> + return IRQ_HANDLED; > >>> +} > >>> + > >>> +/* > >>> + * start_devapc - unmask slave's irq to start receiving devapc violation. > >>> + */ > >>> +static void start_devapc(struct mtk_devapc_context *ctx) > >>> +{ > >>> + writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset); > >>> + > >>> + mask_module_irq(ctx, false); > >>> +} > >>> + > >>> +/* > >>> + * stop_devapc - mask slave's irq to stop service. > >>> + */ > >>> +static void stop_devapc(struct mtk_devapc_context *ctx) > >>> +{ > >>> + mask_module_irq(ctx, true); > >>> + > >>> + writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset); > >>> +} > >>> + > >>> +static const struct mtk_devapc_data devapc_mt6779 = { > >>> + .vio_idx_num = 511, > >>> + .vio_mask_offset = 0x0, > >>> + .vio_sta_offset = 0x400, > >>> + .vio_dbg0_offset = 0x900, > >>> + .vio_dbg1_offset = 0x904, > >>> + .apc_con_offset = 0xF00, > >>> + .vio_shift_sta_offset = 0xF10, > >>> + .vio_shift_sel_offset = 0xF14, > >>> + .vio_shift_con_offset = 0xF20, > >>> +}; > >>> + > >>> +static const struct of_device_id mtk_devapc_dt_match[] = { > >>> + { > >>> + .compatible = "mediatek,mt6779-devapc", > >>> + .data = &devapc_mt6779, > >>> + }, { > >>> + }, > >>> +}; > >>> + > >>> +static int mtk_devapc_probe(struct platform_device *pdev) > >>> +{ > >>> + struct device_node *node = pdev->dev.of_node; > >>> + struct mtk_devapc_context *ctx; > >>> + u32 devapc_irq; > >>> + int ret; > >>> + > >>> + if (IS_ERR(node)) > >>> + return -ENODEV; > >>> + > >>> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); > >>> + if (!ctx) > >>> + return -ENOMEM; > >>> + > >>> + ctx->data = of_device_get_match_data(&pdev->dev); > >>> + ctx->dev = &pdev->dev; > >>> + > >>> + ctx->infra_base = of_iomap(node, 0); > >> > >> Does this mean the device is part of the infracfg block? > >> I wasn't able to find any information about it. > > > > I'm not sure why you would ask infracfg block. devapc is parts of our > > SoC infra, it's different with infracfg. > > > > I'm asking because I want to understand the HW better. I'm not able to find any > information in the datasheets. I want to avoid a situation as we had with the > MMSYS where a clock driver was submitted first and later on we realized that > MMSYS is much more then that and we had to work hard to get the driver right. > > Now it's happening with SCPSYS, where a driver with the scpsys compatible was > send years ago. But SCPSYS is much more then the driver submitted. In this case > we opted to write a new driver, but moving from one driver to another one is > painfull and full of problems. For that I want to make sure we fully understand > Device APC (by the way, what does APC stands for?). Is it a totally independent > HW block or is it part of a subsystem, like for example SCP? > > Regards, > Matthias It's a totally independent HW block instead of a subsystem. I think it's more simple than MMSYS or SCPSYS. But if you would like to understand more about this HW, we could find another way/channel to introduce it. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 622DBC43467 for ; Thu, 8 Oct 2020 09:42:48 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B83E62177B for ; Thu, 8 Oct 2020 09:42:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="krIn+PCy"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="tzXB51Oz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B83E62177B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eOJKYAT1rFV66PyD3IwrjzpcKfun512poN1CHJtnZr8=; b=krIn+PCygyVmn6v9abdob0dS9 EjS1P2XO2jmMPUVi2gL+FdneLXZEYQH4ntYMGlh7GcEUVnaK2uLR9XzB5n8XcDzEgMoMtubjQWC7t nY/Zk5HZR93ZQ1NYG7srL1XnggTH28kWYM1ppo7V9Qv8rNXI0GhrgBa+UCpwZtE6cwxAZdPEEGugK 7s73zehz+uOSlForpMwWEHr89c3wKVhpih3zilmHQ5GAVXnXgG1Y99nOuoGtIEkH/2eFel4/bESOK tCVIQM5qbFRPtAHB9S5Ar7ryZIsYtWW/FOjdLM5TEn5a7+L0XVPjaKY+gxv8DLYHgxp+JIJY0Cd4V d/6qJ+sTw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQSQM-0003UD-5m; Thu, 08 Oct 2020 09:41:22 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQSQH-0003SO-2G; Thu, 08 Oct 2020 09:41:19 +0000 X-UUID: f8c84fc60ed74c0497977fbeca52adda-20201008 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=1Ozpz9ZghRPEXVmLBbry4bfJslMm3ymiwvO7V65jL04=; b=tzXB51OzKySlCiBO0Wd9bdQ4yBhYUf+ofawiHI8M9urGyTi5ysFvhaKM3hsNYWwxbeafQVW38AhoHUqn7JJXzkSdU1O+t6Qz9hD4nFA3TiUkSC29Rqi2SOvBcsMu900WBYbi6c8PjMrbjnoN9BIXuKQoQEw0MkdVY0VRq+1TyAg=; X-UUID: f8c84fc60ed74c0497977fbeca52adda-20201008 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 359686759; Thu, 08 Oct 2020 01:41:09 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 02:39:33 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 17:39:24 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 17:39:25 +0800 Message-ID: <1602149965.8784.6.camel@mtkswgap22> Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver From: Neal Liu To: Matthias Brugger Date: Thu, 8 Oct 2020 17:39:25 +0800 In-Reply-To: References: <1598497593-15781-1-git-send-email-neal.liu@mediatek.com> <1598497593-15781-3-git-send-email-neal.liu@mediatek.com> <1602124514.28301.17.camel@mtkswgap22> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_054117_341817_8DDF2AF9 X-CRM114-Status: GOOD ( 44.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chun-Kuang Hu , wsd_upstream@mediatek.com, devicetree@vger.kernel.org, lkml , Rob Herring , linux-mediatek@lists.infradead.org, Neal Liu , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote: > > On 08/10/2020 04:35, Neal Liu wrote: > > On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote: > >> > >> On 27/08/2020 05:06, Neal Liu wrote: > >>> MediaTek bus fabric provides TrustZone security support and data > >>> protection to prevent slaves from being accessed by unexpected > >>> masters. > >>> The security violation is logged and sent to the processor for > >>> further analysis or countermeasures. > >>> > >>> Any occurrence of security violation would raise an interrupt, and > >>> it will be handled by mtk-devapc driver. The violation > >>> information is printed in order to find the murderer. > >> > >> "The violation information is printed in order to find the responsible component." > >> > >> Nobody got actually killed, right :) > > > > Correct ! > >> > >>> > >>> Signed-off-by: Neal Liu > >>> --- > >>> drivers/soc/mediatek/Kconfig | 9 ++ > >>> drivers/soc/mediatek/Makefile | 1 + > >>> drivers/soc/mediatek/mtk-devapc.c | 305 +++++++++++++++++++++++++++++++++++++ > >>> 3 files changed, 315 insertions(+) > >>> create mode 100644 drivers/soc/mediatek/mtk-devapc.c > >>> > >>> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > >>> index 59a56cd..1177c98 100644 > >>> --- a/drivers/soc/mediatek/Kconfig > >>> +++ b/drivers/soc/mediatek/Kconfig > >>> @@ -17,6 +17,15 @@ config MTK_CMDQ > >>> time limitation, such as updating display configuration during the > >>> vblank. > >>> > >>> +config MTK_DEVAPC > >>> + tristate "Mediatek Device APC Support" > >>> + help > >>> + Say yes here to enable support for Mediatek Device APC driver. > >>> + This driver is mainly used to handle the violation which catches > >>> + unexpected transaction. > >>> + The violation information is logged for further analysis or > >>> + countermeasures. > >>> + > >>> config MTK_INFRACFG > >>> bool "MediaTek INFRACFG Support" > >>> select REGMAP > >>> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > >>> index 01f9f87..abfd4ba 100644 > >>> --- a/drivers/soc/mediatek/Makefile > >>> +++ b/drivers/soc/mediatek/Makefile > >>> @@ -1,5 +1,6 @@ > >>> # SPDX-License-Identifier: GPL-2.0-only > >>> obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > >>> +obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o > >>> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o > >>> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > >>> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > >>> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c > >>> new file mode 100644 > >>> index 0000000..0ba61d7 > >>> --- /dev/null > >>> +++ b/drivers/soc/mediatek/mtk-devapc.c > >>> @@ -0,0 +1,305 @@ > >>> +// SPDX-License-Identifier: GPL-2.0 > >>> +/* > >>> + * Copyright (C) 2020 MediaTek Inc. > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#define VIO_MOD_TO_REG_IND(m) ((m) / 32) > >>> +#define VIO_MOD_TO_REG_OFF(m) ((m) % 32) > >>> + > >>> +struct mtk_devapc_vio_dbgs { > >>> + union { > >>> + u32 vio_dbg0; > >>> + struct { > >>> + u32 mstid:16; > >>> + u32 dmnid:6; > >>> + u32 vio_w:1; > >>> + u32 vio_r:1; > >>> + u32 addr_h:4; > >>> + u32 resv:4; > >>> + } dbg0_bits; > >>> + }; > >>> + > >>> + u32 vio_dbg1; > >>> +}; > >>> + > >>> +struct mtk_devapc_data { > >>> + u32 vio_idx_num; > >>> + u32 vio_mask_offset; > >>> + u32 vio_sta_offset; > >>> + u32 vio_dbg0_offset; > >>> + u32 vio_dbg1_offset; > >>> + u32 apc_con_offset; > >>> + u32 vio_shift_sta_offset; > >>> + u32 vio_shift_sel_offset; > >>> + u32 vio_shift_con_offset; > >>> +}; > >> > >> Please describe the fields of the struct, that will make it easier to understand > >> the driver. > > > > Okay, I'll try to add more description about this struct. May be like: > > > > struct mtk_devapc_data { > > /* numbers of violation index */ > > u32 vio_idx_num; > > > > /* reg offset */ > > u32 vio_mask_offset; > > u32 vio_sta_offset; > > u32 vio_dbg0_offset; > > u32 vio_dbg1_offset; > > u32 apc_con_offset; > > u32 vio_shift_sta_offset; > > u32 vio_shift_sel_offset; > > u32 vio_shift_con_offset; > > }; > > > >> > >>> + > >>> +struct mtk_devapc_context { > >>> + struct device *dev; > >>> + void __iomem *infra_base; > >>> + struct clk *infra_clk; > >>> + const struct mtk_devapc_data *data; > >>> +}; > >>> + > >>> +static void clear_vio_status(struct mtk_devapc_context *ctx) > >>> +{ > >>> + void __iomem *reg; > >>> + int i; > >>> + > >>> + reg = ctx->infra_base + ctx->data->vio_sta_offset; > >>> + > >>> + for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++) > >>> + writel(GENMASK(31, 0), reg + 4 * i); > >>> + > >>> + writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), 0), > >>> + reg + 4 * i); > >>> +} > >>> + > >>> +static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask) > >>> +{ > >>> + void __iomem *reg; > >>> + u32 val; > >>> + int i; > >>> + > >>> + reg = ctx->infra_base + ctx->data->vio_mask_offset; > >>> + > >>> + if (mask) > >>> + val = GENMASK(31, 0); > >>> + else > >>> + val = 0; > >>> + > >>> + for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++) > >> > >> Do I get that right? We have a number of virtual IO identifier. Their > >> correspondending interrupt are grouped in 32 bit registers. And we want to > >> enable/disable them by writing 0 or 1. We have to take care of the last > >> registers as it could be the case that vio_idx_num is not a multiple of 32, correct? > >> > >> In this case we should traverse VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1 > >> registers, which is (vio_idx_num / 32) - 1 and not (vio_idx_num - 1) / 32. > >> > > > > Yes, your understanding is correct. It should be > > VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1 instead of > > VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1). > > > >>> + writel(val, reg + 4 * i); > >>> + > >>> + val = readl(reg + 4 * i); > >>> + if (mask) > >>> + val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), > >>> + 0); > >> > >> We have 511 IRQs, which gives us 31 bits in the last register to set/unset. > >> Thats 510..0 bits, so from what I understand, once again we want > >> GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0) > >> which is (vio_idx_num % 32) - 1 > >> > >> Correct or do I understand something wrong? > >> If so, same applies to clear_vio_status(). > >> > > > > Correct. I'll fix it on next patch. > > Thanks > > > >> > >>> + else > >>> + val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), > >>> + 0); > >>> + > >>> + writel(val, reg + 4 * i); > >>> +} > >>> + > >>> +#define PHY_DEVAPC_TIMEOUT 0x10000 > >>> + > >>> +/* > >>> + * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation information. > >>> + * shift mechanism is depends on devapc hardware design. > >>> + * Mediatek devapc set multiple slaves as a group. > >>> + * When violation is triggered, violation info is kept > >>> + * inside devapc hardware. > >>> + * Driver should do shift mechansim to sync full violation > >>> + * info to VIO_DBGs registers. > >>> + * > >>> + */ > >>> +static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx) > >>> +{ > >>> + void __iomem *pd_vio_shift_sta_reg; > >>> + void __iomem *pd_vio_shift_sel_reg; > >>> + void __iomem *pd_vio_shift_con_reg; > >>> + int min_shift_group; > >>> + int ret; > >>> + u32 val; > >>> + > >>> + pd_vio_shift_sta_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_sta_offset; > >>> + pd_vio_shift_sel_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_sel_offset; > >>> + pd_vio_shift_con_reg = ctx->infra_base + > >>> + ctx->data->vio_shift_con_offset; > >>> + > >>> + /* Find the minimum shift group which has violation */ > >>> + val = readl(pd_vio_shift_sta_reg); > >>> + if (!val) > >>> + return false; > >> > >> So bit 0 of selection register (pd_vio_shift_sel_reg) does not represent a > >> violation group? > >> I don't know how the HW works, but is seems odd to me. In case that's bit 0 > >> actually doesn't represent anything: how can an interrupt be triggered without > >> any debug information present (means val == 0)? > > > > This check implies HW status has something wrong. It cannot get any > > debug information for this case. > > It won't happen in normal scenario. Should we remove this check? > > > > No I think the check is fine. I'd add a WARN() message as this is an indicator > that the HW is not working corretly. Sure. add WARN() message is more helpful to understand. I'll add it on next patch. Thanks > > >> > >>> + > >>> + min_shift_group = __ffs(val); > >>> + > >>> + /* Assign the group to sync */ > >>> + writel(0x1 << min_shift_group, pd_vio_shift_sel_reg); > >>> + > >>> + /* Start syncing */ > >>> + writel(0x1, pd_vio_shift_con_reg); > >>> + > >>> + ret = readl_poll_timeout(pd_vio_shift_con_reg, val, val == 0x3, 0, > >>> + PHY_DEVAPC_TIMEOUT); > >>> + if (ret) { > >>> + dev_err(ctx->dev, "%s: Shift violation info failed\n", __func__); > >> > >> In which case this can happen? I'm asking, because we are calling > >> devapc_sync_vio_dbg() in a while loop that could make the kernel hang here. > >> > >> Do I understand correctly, that we are using the while loop, because there can > >> be more then one violation group which got triggered (read, more then one bit is > >> set in pd_vio_shift_sta_reg)? Would it make more sense then to read the register > >> once and do all the shift operation for all groups which bit set to 1 in the > >> shift status register? > > > > Yes, your understanding is correct. > > This check also implies HW status has something wrong. We return false > > to skip further violation info dump. > > How could this case make the kernel hang? > > > > The kernel can't hang, sorry my fault. In any case I'd add a WARN() here as > well. I understand that if we error out here, we have a HW/FW bug (my feeling > is, that behind this is a micro controller of some kind :) > I'll also add warn messages on next patch. > >> > >>> + return false; > >>> + } > >>> + > >>> + /* Stop syncing */ > >>> + writel(0x0, pd_vio_shift_con_reg); > >>> + > >>> + /* Write clear */ > >>> + writel(0x1 << min_shift_group, pd_vio_shift_sta_reg); > >>> + > >>> + return true; > >>> +} > >>> + > >>> +/* > >>> + * devapc_extract_vio_dbg - extract full violation information after doing > >>> + * shift mechanism. > >>> + */ > >>> +static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx) > >>> +{ > >>> + struct mtk_devapc_vio_dbgs vio_dbgs; > >>> + void __iomem *vio_dbg0_reg; > >>> + void __iomem *vio_dbg1_reg; > >>> + > >>> + vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset; > >>> + vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset; > >>> + > >>> + vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg); > >>> + vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg); > >>> + > >>> + /* Print violation information */ > >>> + if (vio_dbgs.dbg0_bits.vio_w) > >>> + dev_info(ctx->dev, "Write Violation\n"); > >>> + else if (vio_dbgs.dbg0_bits.vio_r) > >>> + dev_info(ctx->dev, "Read Violation\n"); > >>> + > >>> + dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n", > >>> + vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid, > >>> + vio_dbgs.vio_dbg1); > >>> +} > >>> + > >>> +/* > >>> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will dump > >>> + * violation information including which master violates > >>> + * access slave. > >>> + */ > >>> +static irqreturn_t devapc_violation_irq(int irq_number, > >>> + struct mtk_devapc_context *ctx) > >> > >> static irqreturn_t devapc_violation_irq(int irq_number, void *data) > >> { > >> struct mtk_devapc_context *ctx = data; > > > > Okay, I'll fix it on next patch. > > Thanks > > > >> > >>> +{ > >>> + while (devapc_sync_vio_dbg(ctx)) > >>> + devapc_extract_vio_dbg(ctx); > >>> + > >>> + clear_vio_status(ctx); > >>> + > >>> + return IRQ_HANDLED; > >>> +} > >>> + > >>> +/* > >>> + * start_devapc - unmask slave's irq to start receiving devapc violation. > >>> + */ > >>> +static void start_devapc(struct mtk_devapc_context *ctx) > >>> +{ > >>> + writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset); > >>> + > >>> + mask_module_irq(ctx, false); > >>> +} > >>> + > >>> +/* > >>> + * stop_devapc - mask slave's irq to stop service. > >>> + */ > >>> +static void stop_devapc(struct mtk_devapc_context *ctx) > >>> +{ > >>> + mask_module_irq(ctx, true); > >>> + > >>> + writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset); > >>> +} > >>> + > >>> +static const struct mtk_devapc_data devapc_mt6779 = { > >>> + .vio_idx_num = 511, > >>> + .vio_mask_offset = 0x0, > >>> + .vio_sta_offset = 0x400, > >>> + .vio_dbg0_offset = 0x900, > >>> + .vio_dbg1_offset = 0x904, > >>> + .apc_con_offset = 0xF00, > >>> + .vio_shift_sta_offset = 0xF10, > >>> + .vio_shift_sel_offset = 0xF14, > >>> + .vio_shift_con_offset = 0xF20, > >>> +}; > >>> + > >>> +static const struct of_device_id mtk_devapc_dt_match[] = { > >>> + { > >>> + .compatible = "mediatek,mt6779-devapc", > >>> + .data = &devapc_mt6779, > >>> + }, { > >>> + }, > >>> +}; > >>> + > >>> +static int mtk_devapc_probe(struct platform_device *pdev) > >>> +{ > >>> + struct device_node *node = pdev->dev.of_node; > >>> + struct mtk_devapc_context *ctx; > >>> + u32 devapc_irq; > >>> + int ret; > >>> + > >>> + if (IS_ERR(node)) > >>> + return -ENODEV; > >>> + > >>> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); > >>> + if (!ctx) > >>> + return -ENOMEM; > >>> + > >>> + ctx->data = of_device_get_match_data(&pdev->dev); > >>> + ctx->dev = &pdev->dev; > >>> + > >>> + ctx->infra_base = of_iomap(node, 0); > >> > >> Does this mean the device is part of the infracfg block? > >> I wasn't able to find any information about it. > > > > I'm not sure why you would ask infracfg block. devapc is parts of our > > SoC infra, it's different with infracfg. > > > > I'm asking because I want to understand the HW better. I'm not able to find any > information in the datasheets. I want to avoid a situation as we had with the > MMSYS where a clock driver was submitted first and later on we realized that > MMSYS is much more then that and we had to work hard to get the driver right. > > Now it's happening with SCPSYS, where a driver with the scpsys compatible was > send years ago. But SCPSYS is much more then the driver submitted. In this case > we opted to write a new driver, but moving from one driver to another one is > painfull and full of problems. For that I want to make sure we fully understand > Device APC (by the way, what does APC stands for?). Is it a totally independent > HW block or is it part of a subsystem, like for example SCP? > > Regards, > Matthias It's a totally independent HW block instead of a subsystem. I think it's more simple than MMSYS or SCPSYS. But if you would like to understand more about this HW, we could find another way/channel to introduce it. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE20BC433E7 for ; Thu, 8 Oct 2020 09:39:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 62EA02177B for ; Thu, 8 Oct 2020 09:39:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="tzXB51Oz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725887AbgJHJjf (ORCPT ); Thu, 8 Oct 2020 05:39:35 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:48815 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725849AbgJHJje (ORCPT ); Thu, 8 Oct 2020 05:39:34 -0400 X-UUID: 61258c031da84b0290d979c5424d499e-20201008 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=1Ozpz9ZghRPEXVmLBbry4bfJslMm3ymiwvO7V65jL04=; b=tzXB51OzKySlCiBO0Wd9bdQ4yBhYUf+ofawiHI8M9urGyTi5ysFvhaKM3hsNYWwxbeafQVW38AhoHUqn7JJXzkSdU1O+t6Qz9hD4nFA3TiUkSC29Rqi2SOvBcsMu900WBYbi6c8PjMrbjnoN9BIXuKQoQEw0MkdVY0VRq+1TyAg=; X-UUID: 61258c031da84b0290d979c5424d499e-20201008 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw01.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.14 Build 0819 with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 913390972; Thu, 08 Oct 2020 17:39:27 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 17:39:24 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 17:39:25 +0800 Message-ID: <1602149965.8784.6.camel@mtkswgap22> Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver From: Neal Liu To: Matthias Brugger CC: Neal Liu , Rob Herring , Chun-Kuang Hu , , , , lkml , Date: Thu, 8 Oct 2020 17:39:25 +0800 In-Reply-To: References: <1598497593-15781-1-git-send-email-neal.liu@mediatek.com> <1598497593-15781-3-git-send-email-neal.liu@mediatek.com> <1602124514.28301.17.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org T24gVGh1LCAyMDIwLTEwLTA4IGF0IDEwOjQ1ICswMjAwLCBNYXR0aGlhcyBCcnVnZ2VyIHdyb3Rl Og0KPiANCj4gT24gMDgvMTAvMjAyMCAwNDozNSwgTmVhbCBMaXUgd3JvdGU6DQo+ID4gT24gV2Vk LCAyMDIwLTEwLTA3IGF0IDEyOjQ0ICswMjAwLCBNYXR0aGlhcyBCcnVnZ2VyIHdyb3RlOg0KPiA+ Pg0KPiA+PiBPbiAyNy8wOC8yMDIwIDA1OjA2LCBOZWFsIExpdSB3cm90ZToNCj4gPj4+IE1lZGlh VGVrIGJ1cyBmYWJyaWMgcHJvdmlkZXMgVHJ1c3Rab25lIHNlY3VyaXR5IHN1cHBvcnQgYW5kIGRh dGENCj4gPj4+IHByb3RlY3Rpb24gdG8gcHJldmVudCBzbGF2ZXMgZnJvbSBiZWluZyBhY2Nlc3Nl ZCBieSB1bmV4cGVjdGVkDQo+ID4+PiBtYXN0ZXJzLg0KPiA+Pj4gVGhlIHNlY3VyaXR5IHZpb2xh dGlvbiBpcyBsb2dnZWQgYW5kIHNlbnQgdG8gdGhlIHByb2Nlc3NvciBmb3INCj4gPj4+IGZ1cnRo ZXIgYW5hbHlzaXMgb3IgY291bnRlcm1lYXN1cmVzLg0KPiA+Pj4NCj4gPj4+IEFueSBvY2N1cnJl bmNlIG9mIHNlY3VyaXR5IHZpb2xhdGlvbiB3b3VsZCByYWlzZSBhbiBpbnRlcnJ1cHQsIGFuZA0K PiA+Pj4gaXQgd2lsbCBiZSBoYW5kbGVkIGJ5IG10ay1kZXZhcGMgZHJpdmVyLiBUaGUgdmlvbGF0 aW9uDQo+ID4+PiBpbmZvcm1hdGlvbiBpcyBwcmludGVkIGluIG9yZGVyIHRvIGZpbmQgdGhlIG11 cmRlcmVyLg0KPiA+Pg0KPiA+PiAiVGhlIHZpb2xhdGlvbiBpbmZvcm1hdGlvbiBpcyBwcmludGVk IGluIG9yZGVyIHRvIGZpbmQgdGhlIHJlc3BvbnNpYmxlIGNvbXBvbmVudC4iDQo+ID4+DQo+ID4+ IE5vYm9keSBnb3QgYWN0dWFsbHkga2lsbGVkLCByaWdodCA6KQ0KPiA+IA0KPiA+IENvcnJlY3Qg IQ0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFNpZ25lZC1vZmYtYnk6IE5lYWwgTGl1IDxuZWFsLmxpdUBt ZWRpYXRlay5jb20+DQo+ID4+PiAtLS0NCj4gPj4+ICAgIGRyaXZlcnMvc29jL21lZGlhdGVrL0tj b25maWcgICAgICB8ICAgIDkgKysNCj4gPj4+ICAgIGRyaXZlcnMvc29jL21lZGlhdGVrL01ha2Vm aWxlICAgICB8ICAgIDEgKw0KPiA+Pj4gICAgZHJpdmVycy9zb2MvbWVkaWF0ZWsvbXRrLWRldmFw Yy5jIHwgIDMwNSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ID4+PiAg ICAzIGZpbGVzIGNoYW5nZWQsIDMxNSBpbnNlcnRpb25zKCspDQo+ID4+PiAgICBjcmVhdGUgbW9k ZSAxMDA2NDQgZHJpdmVycy9zb2MvbWVkaWF0ZWsvbXRrLWRldmFwYy5jDQo+ID4+Pg0KPiA+Pj4g ZGlmZiAtLWdpdCBhL2RyaXZlcnMvc29jL21lZGlhdGVrL0tjb25maWcgYi9kcml2ZXJzL3NvYy9t ZWRpYXRlay9LY29uZmlnDQo+ID4+PiBpbmRleCA1OWE1NmNkLi4xMTc3Yzk4IDEwMDY0NA0KPiA+ Pj4gLS0tIGEvZHJpdmVycy9zb2MvbWVkaWF0ZWsvS2NvbmZpZw0KPiA+Pj4gKysrIGIvZHJpdmVy cy9zb2MvbWVkaWF0ZWsvS2NvbmZpZw0KPiA+Pj4gQEAgLTE3LDYgKzE3LDE1IEBAIGNvbmZpZyBN VEtfQ01EUQ0KPiA+Pj4gICAgCSAgdGltZSBsaW1pdGF0aW9uLCBzdWNoIGFzIHVwZGF0aW5nIGRp c3BsYXkgY29uZmlndXJhdGlvbiBkdXJpbmcgdGhlDQo+ID4+PiAgICAJICB2YmxhbmsuDQo+ID4+ PiAgICANCj4gPj4+ICtjb25maWcgTVRLX0RFVkFQQw0KPiA+Pj4gKwl0cmlzdGF0ZSAiTWVkaWF0 ZWsgRGV2aWNlIEFQQyBTdXBwb3J0Ig0KPiA+Pj4gKwloZWxwDQo+ID4+PiArCSAgU2F5IHllcyBo ZXJlIHRvIGVuYWJsZSBzdXBwb3J0IGZvciBNZWRpYXRlayBEZXZpY2UgQVBDIGRyaXZlci4NCj4g Pj4+ICsJICBUaGlzIGRyaXZlciBpcyBtYWlubHkgdXNlZCB0byBoYW5kbGUgdGhlIHZpb2xhdGlv biB3aGljaCBjYXRjaGVzDQo+ID4+PiArCSAgdW5leHBlY3RlZCB0cmFuc2FjdGlvbi4NCj4gPj4+ ICsJICBUaGUgdmlvbGF0aW9uIGluZm9ybWF0aW9uIGlzIGxvZ2dlZCBmb3IgZnVydGhlciBhbmFs eXNpcyBvcg0KPiA+Pj4gKwkgIGNvdW50ZXJtZWFzdXJlcy4NCj4gPj4+ICsNCj4gPj4+ICAgIGNv bmZpZyBNVEtfSU5GUkFDRkcNCj4gPj4+ICAgIAlib29sICJNZWRpYVRlayBJTkZSQUNGRyBTdXBw b3J0Ig0KPiA+Pj4gICAgCXNlbGVjdCBSRUdNQVANCj4gPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJz L3NvYy9tZWRpYXRlay9NYWtlZmlsZSBiL2RyaXZlcnMvc29jL21lZGlhdGVrL01ha2VmaWxlDQo+ ID4+PiBpbmRleCAwMWY5Zjg3Li5hYmZkNGJhIDEwMDY0NA0KPiA+Pj4gLS0tIGEvZHJpdmVycy9z b2MvbWVkaWF0ZWsvTWFrZWZpbGUNCj4gPj4+ICsrKyBiL2RyaXZlcnMvc29jL21lZGlhdGVrL01h a2VmaWxlDQo+ID4+PiBAQCAtMSw1ICsxLDYgQEANCj4gPj4+ICAgICMgU1BEWC1MaWNlbnNlLUlk ZW50aWZpZXI6IEdQTC0yLjAtb25seQ0KPiA+Pj4gICAgb2JqLSQoQ09ORklHX01US19DTURRKSAr PSBtdGstY21kcS1oZWxwZXIubw0KPiA+Pj4gK29iai0kKENPTkZJR19NVEtfREVWQVBDKSArPSBt dGstZGV2YXBjLm8NCj4gPj4+ICAgIG9iai0kKENPTkZJR19NVEtfSU5GUkFDRkcpICs9IG10ay1p bmZyYWNmZy5vDQo+ID4+PiAgICBvYmotJChDT05GSUdfTVRLX1BNSUNfV1JBUCkgKz0gbXRrLXBt aWMtd3JhcC5vDQo+ID4+PiAgICBvYmotJChDT05GSUdfTVRLX1NDUFNZUykgKz0gbXRrLXNjcHN5 cy5vDQo+ID4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zb2MvbWVkaWF0ZWsvbXRrLWRldmFwYy5j IGIvZHJpdmVycy9zb2MvbWVkaWF0ZWsvbXRrLWRldmFwYy5jDQo+ID4+PiBuZXcgZmlsZSBtb2Rl IDEwMDY0NA0KPiA+Pj4gaW5kZXggMDAwMDAwMC4uMGJhNjFkNw0KPiA+Pj4gLS0tIC9kZXYvbnVs bA0KPiA+Pj4gKysrIGIvZHJpdmVycy9zb2MvbWVkaWF0ZWsvbXRrLWRldmFwYy5jDQo+ID4+PiBA QCAtMCwwICsxLDMwNSBAQA0KPiA+Pj4gKy8vIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwt Mi4wDQo+ID4+PiArLyoNCj4gPj4+ICsgKiBDb3B5cmlnaHQgKEMpIDIwMjAgTWVkaWFUZWsgSW5j Lg0KPiA+Pj4gKyAqLw0KPiA+Pj4gKw0KPiA+Pj4gKyNpbmNsdWRlIDxsaW51eC9jbGsuaD4NCj4g Pj4+ICsjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+DQo+ID4+PiArI2luY2x1ZGUgPGxpbnV4 L2lvcG9sbC5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCj4gPj4+ICsjaW5j bHVkZSA8bGludXgvcGxhdGZvcm1fZGV2aWNlLmg+DQo+ID4+PiArI2luY2x1ZGUgPGxpbnV4L29m X2RldmljZS5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxsaW51eC9vZl9pcnEuaD4NCj4gPj4+ICsjaW5j bHVkZSA8bGludXgvb2ZfYWRkcmVzcy5oPg0KPiA+Pj4gKw0KPiA+Pj4gKyNkZWZpbmUgVklPX01P RF9UT19SRUdfSU5EKG0pCSgobSkgLyAzMikNCj4gPj4+ICsjZGVmaW5lIFZJT19NT0RfVE9fUkVH X09GRihtKQkoKG0pICUgMzIpDQo+ID4+PiArDQo+ID4+PiArc3RydWN0IG10a19kZXZhcGNfdmlv X2RiZ3Mgew0KPiA+Pj4gKwl1bmlvbiB7DQo+ID4+PiArCQl1MzIgdmlvX2RiZzA7DQo+ID4+PiAr CQlzdHJ1Y3Qgew0KPiA+Pj4gKwkJCXUzMiBtc3RpZDoxNjsNCj4gPj4+ICsJCQl1MzIgZG1uaWQ6 NjsNCj4gPj4+ICsJCQl1MzIgdmlvX3c6MTsNCj4gPj4+ICsJCQl1MzIgdmlvX3I6MTsNCj4gPj4+ ICsJCQl1MzIgYWRkcl9oOjQ7DQo+ID4+PiArCQkJdTMyIHJlc3Y6NDsNCj4gPj4+ICsJCX0gZGJn MF9iaXRzOw0KPiA+Pj4gKwl9Ow0KPiA+Pj4gKw0KPiA+Pj4gKwl1MzIgdmlvX2RiZzE7DQo+ID4+ PiArfTsNCj4gPj4+ICsNCj4gPj4+ICtzdHJ1Y3QgbXRrX2RldmFwY19kYXRhIHsNCj4gPj4+ICsJ dTMyIHZpb19pZHhfbnVtOw0KPiA+Pj4gKwl1MzIgdmlvX21hc2tfb2Zmc2V0Ow0KPiA+Pj4gKwl1 MzIgdmlvX3N0YV9vZmZzZXQ7DQo+ID4+PiArCXUzMiB2aW9fZGJnMF9vZmZzZXQ7DQo+ID4+PiAr CXUzMiB2aW9fZGJnMV9vZmZzZXQ7DQo+ID4+PiArCXUzMiBhcGNfY29uX29mZnNldDsNCj4gPj4+ ICsJdTMyIHZpb19zaGlmdF9zdGFfb2Zmc2V0Ow0KPiA+Pj4gKwl1MzIgdmlvX3NoaWZ0X3NlbF9v ZmZzZXQ7DQo+ID4+PiArCXUzMiB2aW9fc2hpZnRfY29uX29mZnNldDsNCj4gPj4+ICt9Ow0KPiA+ Pg0KPiA+PiBQbGVhc2UgZGVzY3JpYmUgdGhlIGZpZWxkcyBvZiB0aGUgc3RydWN0LCB0aGF0IHdp bGwgbWFrZSBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZA0KPiA+PiB0aGUgZHJpdmVyLg0KPiA+IA0K PiA+IE9rYXksIEknbGwgdHJ5IHRvIGFkZCBtb3JlIGRlc2NyaXB0aW9uIGFib3V0IHRoaXMgc3Ry dWN0LiBNYXkgYmUgbGlrZToNCj4gPiANCj4gPiBzdHJ1Y3QgbXRrX2RldmFwY19kYXRhIHsNCj4g PiAJLyogbnVtYmVycyBvZiB2aW9sYXRpb24gaW5kZXggKi8NCj4gPiAJdTMyIHZpb19pZHhfbnVt Ow0KPiA+IA0KPiA+IAkvKiByZWcgb2Zmc2V0ICovDQo+ID4gCXUzMiB2aW9fbWFza19vZmZzZXQ7 DQo+ID4gCXUzMiB2aW9fc3RhX29mZnNldDsNCj4gPiAJdTMyIHZpb19kYmcwX29mZnNldDsNCj4g PiAJdTMyIHZpb19kYmcxX29mZnNldDsNCj4gPiAJdTMyIGFwY19jb25fb2Zmc2V0Ow0KPiA+IAl1 MzIgdmlvX3NoaWZ0X3N0YV9vZmZzZXQ7DQo+ID4gCXUzMiB2aW9fc2hpZnRfc2VsX29mZnNldDsN Cj4gPiAJdTMyIHZpb19zaGlmdF9jb25fb2Zmc2V0Ow0KPiA+IH07DQo+ID4gDQo+ID4+DQo+ID4+ PiArDQo+ID4+PiArc3RydWN0IG10a19kZXZhcGNfY29udGV4dCB7DQo+ID4+PiArCXN0cnVjdCBk ZXZpY2UgKmRldjsNCj4gPj4+ICsJdm9pZCBfX2lvbWVtICppbmZyYV9iYXNlOw0KPiA+Pj4gKwlz dHJ1Y3QgY2xrICppbmZyYV9jbGs7DQo+ID4+PiArCWNvbnN0IHN0cnVjdCBtdGtfZGV2YXBjX2Rh dGEgKmRhdGE7DQo+ID4+PiArfTsNCj4gPj4+ICsNCj4gPj4+ICtzdGF0aWMgdm9pZCBjbGVhcl92 aW9fc3RhdHVzKHN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0eCkNCj4gPj4+ICt7DQo+ID4+ PiArCXZvaWQgX19pb21lbSAqcmVnOw0KPiA+Pj4gKwlpbnQgaTsNCj4gPj4+ICsNCj4gPj4+ICsJ cmVnID0gY3R4LT5pbmZyYV9iYXNlICsgY3R4LT5kYXRhLT52aW9fc3RhX29mZnNldDsNCj4gPj4+ ICsNCj4gPj4+ICsJZm9yIChpID0gMDsgaSA8IFZJT19NT0RfVE9fUkVHX0lORChjdHgtPmRhdGEt PnZpb19pZHhfbnVtIC0gMSk7IGkrKykNCj4gPj4+ICsJCXdyaXRlbChHRU5NQVNLKDMxLCAwKSwg cmVnICsgNCAqIGkpOw0KPiA+Pj4gKw0KPiA+Pj4gKwl3cml0ZWwoR0VOTUFTSyhWSU9fTU9EX1RP X1JFR19PRkYoY3R4LT5kYXRhLT52aW9faWR4X251bSAtIDEpLCAwKSwNCj4gPj4+ICsJICAgICAg IHJlZyArIDQgKiBpKTsNCj4gPj4+ICt9DQo+ID4+PiArDQo+ID4+PiArc3RhdGljIHZvaWQgbWFz a19tb2R1bGVfaXJxKHN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0eCwgYm9vbCBtYXNrKQ0K PiA+Pj4gK3sNCj4gPj4+ICsJdm9pZCBfX2lvbWVtICpyZWc7DQo+ID4+PiArCXUzMiB2YWw7DQo+ ID4+PiArCWludCBpOw0KPiA+Pj4gKw0KPiA+Pj4gKwlyZWcgPSBjdHgtPmluZnJhX2Jhc2UgKyBj dHgtPmRhdGEtPnZpb19tYXNrX29mZnNldDsNCj4gPj4+ICsNCj4gPj4+ICsJaWYgKG1hc2spDQo+ ID4+PiArCQl2YWwgPSBHRU5NQVNLKDMxLCAwKTsNCj4gPj4+ICsJZWxzZQ0KPiA+Pj4gKwkJdmFs ID0gMDsNCj4gPj4+ICsNCj4gPj4+ICsJZm9yIChpID0gMDsgaSA8IFZJT19NT0RfVE9fUkVHX0lO RChjdHgtPmRhdGEtPnZpb19pZHhfbnVtIC0gMSk7IGkrKykNCj4gPj4NCj4gPj4gRG8gSSBnZXQg dGhhdCByaWdodD8gV2UgaGF2ZSBhIG51bWJlciBvZiB2aXJ0dWFsIElPIGlkZW50aWZpZXIuIFRo ZWlyDQo+ID4+IGNvcnJlc3BvbmRlbmRpbmcgaW50ZXJydXB0IGFyZSBncm91cGVkIGluIDMyIGJp dCByZWdpc3RlcnMuIEFuZCB3ZSB3YW50IHRvDQo+ID4+IGVuYWJsZS9kaXNhYmxlIHRoZW0gYnkg d3JpdGluZyAwIG9yIDEuIFdlIGhhdmUgdG8gdGFrZSBjYXJlIG9mIHRoZSBsYXN0DQo+ID4+IHJl Z2lzdGVycyBhcyBpdCBjb3VsZCBiZSB0aGUgY2FzZSB0aGF0IHZpb19pZHhfbnVtIGlzIG5vdCBh IG11bHRpcGxlIG9mIDMyLCBjb3JyZWN0Pw0KPiA+Pg0KPiA+PiBJbiB0aGlzIGNhc2Ugd2Ugc2hv dWxkIHRyYXZlcnNlIFZJT19NT0RfVE9fUkVHX0lORChjdHgtPmRhdGEtPnZpb19pZHhfbnVtKSAt IDENCj4gPj4gcmVnaXN0ZXJzLCB3aGljaCBpcyAodmlvX2lkeF9udW0gLyAzMikgLSAxIGFuZCBu b3QgKHZpb19pZHhfbnVtIC0gMSkgLyAzMi4NCj4gPj4NCj4gPiANCj4gPiBZZXMsIHlvdXIgdW5k ZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBJdCBzaG91bGQgYmUNCj4gPiBWSU9fTU9EX1RPX1JFR19J TkQoY3R4LT5kYXRhLT52aW9faWR4X251bSkgLSAxIGluc3RlYWQgb2YNCj4gPiBWSU9fTU9EX1RP X1JFR19JTkQoY3R4LT5kYXRhLT52aW9faWR4X251bSAtIDEpLg0KPiA+IA0KPiA+Pj4gKwkJd3Jp dGVsKHZhbCwgcmVnICsgNCAqIGkpOw0KPiA+Pj4gKw0KPiA+Pj4gKwl2YWwgPSByZWFkbChyZWcg KyA0ICogaSk7DQo+ID4+PiArCWlmIChtYXNrKQ0KPiA+Pj4gKwkJdmFsIHw9IEdFTk1BU0soVklP X01PRF9UT19SRUdfT0ZGKGN0eC0+ZGF0YS0+dmlvX2lkeF9udW0gLSAxKSwNCj4gPj4+ICsJCQkg ICAgICAgMCk7DQo+ID4+DQo+ID4+IFdlIGhhdmUgNTExIElSUXMsIHdoaWNoIGdpdmVzIHVzIDMx IGJpdHMgaW4gdGhlIGxhc3QgcmVnaXN0ZXIgdG8gc2V0L3Vuc2V0Lg0KPiA+PiBUaGF0cyA1MTAu LjAgYml0cywgc28gZnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgb25jZSBhZ2FpbiB3ZSB3YW50DQo+ ID4+IEdFTk1BU0soVklPX01PRF9UT19SRUdfT0ZGKGN0eC0+ZGF0YS0+dmlvX2lkeF9udW0pIC0g MSwgMCkNCj4gPj4gd2hpY2ggaXMgKHZpb19pZHhfbnVtICUgMzIpIC0gMQ0KPiA+Pg0KPiA+PiBD b3JyZWN0IG9yIGRvIEkgdW5kZXJzdGFuZCBzb21ldGhpbmcgd3Jvbmc/DQo+ID4+IElmIHNvLCBz YW1lIGFwcGxpZXMgdG8gY2xlYXJfdmlvX3N0YXR1cygpLg0KPiA+Pg0KPiA+IA0KPiA+IENvcnJl Y3QuIEknbGwgZml4IGl0IG9uIG5leHQgcGF0Y2guDQo+ID4gVGhhbmtzDQo+ID4gDQo+ID4+DQo+ ID4+PiArCWVsc2UNCj4gPj4+ICsJCXZhbCAmPSB+R0VOTUFTSyhWSU9fTU9EX1RPX1JFR19PRkYo Y3R4LT5kYXRhLT52aW9faWR4X251bSAtIDEpLA0KPiA+Pj4gKwkJCQkwKTsNCj4gPj4+ICsNCj4g Pj4+ICsJd3JpdGVsKHZhbCwgcmVnICsgNCAqIGkpOw0KPiA+Pj4gK30NCj4gPj4+ICsNCj4gPj4+ ICsjZGVmaW5lIFBIWV9ERVZBUENfVElNRU9VVAkweDEwMDAwDQo+ID4+PiArDQo+ID4+PiArLyoN Cj4gPj4+ICsgKiBkZXZhcGNfc3luY192aW9fZGJnIC0gZG8gInNoaWZ0IiBtZWNoYW5zaW0iIHRv IGdldCBmdWxsIHZpb2xhdGlvbiBpbmZvcm1hdGlvbi4NCj4gPj4+ICsgKiAgICAgICAgICAgICAg ICAgICAgICAgc2hpZnQgbWVjaGFuaXNtIGlzIGRlcGVuZHMgb24gZGV2YXBjIGhhcmR3YXJlIGRl c2lnbi4NCj4gPj4+ICsgKiAgICAgICAgICAgICAgICAgICAgICAgTWVkaWF0ZWsgZGV2YXBjIHNl dCBtdWx0aXBsZSBzbGF2ZXMgYXMgYSBncm91cC4NCj4gPj4+ICsgKiAgICAgICAgICAgICAgICAg ICAgICAgV2hlbiB2aW9sYXRpb24gaXMgdHJpZ2dlcmVkLCB2aW9sYXRpb24gaW5mbyBpcyBrZXB0 DQo+ID4+PiArICogICAgICAgICAgICAgICAgICAgICAgIGluc2lkZSBkZXZhcGMgaGFyZHdhcmUu DQo+ID4+PiArICogICAgICAgICAgICAgICAgICAgICAgIERyaXZlciBzaG91bGQgZG8gc2hpZnQg bWVjaGFuc2ltIHRvIHN5bmMgZnVsbCB2aW9sYXRpb24NCj4gPj4+ICsgKiAgICAgICAgICAgICAg ICAgICAgICAgaW5mbyB0byBWSU9fREJHcyByZWdpc3RlcnMuDQo+ID4+PiArICoNCj4gPj4+ICsg Ki8NCj4gPj4+ICtzdGF0aWMgaW50IGRldmFwY19zeW5jX3Zpb19kYmcoc3RydWN0IG10a19kZXZh cGNfY29udGV4dCAqY3R4KQ0KPiA+Pj4gK3sNCj4gPj4+ICsJdm9pZCBfX2lvbWVtICpwZF92aW9f c2hpZnRfc3RhX3JlZzsNCj4gPj4+ICsJdm9pZCBfX2lvbWVtICpwZF92aW9fc2hpZnRfc2VsX3Jl ZzsNCj4gPj4+ICsJdm9pZCBfX2lvbWVtICpwZF92aW9fc2hpZnRfY29uX3JlZzsNCj4gPj4+ICsJ aW50IG1pbl9zaGlmdF9ncm91cDsNCj4gPj4+ICsJaW50IHJldDsNCj4gPj4+ICsJdTMyIHZhbDsN Cj4gPj4+ICsNCj4gPj4+ICsJcGRfdmlvX3NoaWZ0X3N0YV9yZWcgPSBjdHgtPmluZnJhX2Jhc2Ug Kw0KPiA+Pj4gKwkJCSAgICAgICBjdHgtPmRhdGEtPnZpb19zaGlmdF9zdGFfb2Zmc2V0Ow0KPiA+ Pj4gKwlwZF92aW9fc2hpZnRfc2VsX3JlZyA9IGN0eC0+aW5mcmFfYmFzZSArDQo+ID4+PiArCQkJ ICAgICAgIGN0eC0+ZGF0YS0+dmlvX3NoaWZ0X3NlbF9vZmZzZXQ7DQo+ID4+PiArCXBkX3Zpb19z aGlmdF9jb25fcmVnID0gY3R4LT5pbmZyYV9iYXNlICsNCj4gPj4+ICsJCQkgICAgICAgY3R4LT5k YXRhLT52aW9fc2hpZnRfY29uX29mZnNldDsNCj4gPj4+ICsNCj4gPj4+ICsJLyogRmluZCB0aGUg bWluaW11bSBzaGlmdCBncm91cCB3aGljaCBoYXMgdmlvbGF0aW9uICovDQo+ID4+PiArCXZhbCA9 IHJlYWRsKHBkX3Zpb19zaGlmdF9zdGFfcmVnKTsNCj4gPj4+ICsJaWYgKCF2YWwpDQo+ID4+PiAr CQlyZXR1cm4gZmFsc2U7DQo+ID4+DQo+ID4+IFNvIGJpdCAwIG9mIHNlbGVjdGlvbiByZWdpc3Rl ciAocGRfdmlvX3NoaWZ0X3NlbF9yZWcpIGRvZXMgbm90IHJlcHJlc2VudCBhDQo+ID4+IHZpb2xh dGlvbiBncm91cD8NCj4gPj4gSSBkb24ndCBrbm93IGhvdyB0aGUgSFcgd29ya3MsIGJ1dCBpcyBz ZWVtcyBvZGQgdG8gbWUuIEluIGNhc2UgdGhhdCdzIGJpdCAwDQo+ID4+IGFjdHVhbGx5IGRvZXNu J3QgcmVwcmVzZW50IGFueXRoaW5nOiBob3cgY2FuIGFuIGludGVycnVwdCBiZSB0cmlnZ2VyZWQg d2l0aG91dA0KPiA+PiBhbnkgZGVidWcgaW5mb3JtYXRpb24gcHJlc2VudCAobWVhbnMgdmFsID09 IDApPw0KPiA+IA0KPiA+IFRoaXMgY2hlY2sgaW1wbGllcyBIVyBzdGF0dXMgaGFzIHNvbWV0aGlu ZyB3cm9uZy4gSXQgY2Fubm90IGdldCBhbnkNCj4gPiBkZWJ1ZyBpbmZvcm1hdGlvbiBmb3IgdGhp cyBjYXNlLg0KPiA+IEl0IHdvbid0IGhhcHBlbiBpbiBub3JtYWwgc2NlbmFyaW8uIFNob3VsZCB3 ZSByZW1vdmUgdGhpcyBjaGVjaz8NCj4gPiANCj4gDQo+IE5vIEkgdGhpbmsgdGhlIGNoZWNrIGlz IGZpbmUuIEknZCBhZGQgYSBXQVJOKCkgbWVzc2FnZSBhcyB0aGlzIGlzIGFuIGluZGljYXRvciAN Cj4gdGhhdCB0aGUgSFcgaXMgbm90IHdvcmtpbmcgY29ycmV0bHkuDQoNClN1cmUuIGFkZCBXQVJO KCkgbWVzc2FnZSBpcyBtb3JlIGhlbHBmdWwgdG8gdW5kZXJzdGFuZC4NCkknbGwgYWRkIGl0IG9u IG5leHQgcGF0Y2guDQpUaGFua3MNCg0KPiANCj4gPj4NCj4gPj4+ICsNCj4gPj4+ICsJbWluX3No aWZ0X2dyb3VwID0gX19mZnModmFsKTsNCj4gPj4+ICsNCj4gPj4+ICsJLyogQXNzaWduIHRoZSBn cm91cCB0byBzeW5jICovDQo+ID4+PiArCXdyaXRlbCgweDEgPDwgbWluX3NoaWZ0X2dyb3VwLCBw ZF92aW9fc2hpZnRfc2VsX3JlZyk7DQo+ID4+PiArDQo+ID4+PiArCS8qIFN0YXJ0IHN5bmNpbmcg Ki8NCj4gPj4+ICsJd3JpdGVsKDB4MSwgcGRfdmlvX3NoaWZ0X2Nvbl9yZWcpOw0KPiA+Pj4gKw0K PiA+Pj4gKwlyZXQgPSByZWFkbF9wb2xsX3RpbWVvdXQocGRfdmlvX3NoaWZ0X2Nvbl9yZWcsIHZh bCwgdmFsID09IDB4MywgMCwNCj4gPj4+ICsJCQkJIFBIWV9ERVZBUENfVElNRU9VVCk7DQo+ID4+ PiArCWlmIChyZXQpIHsNCj4gPj4+ICsJCWRldl9lcnIoY3R4LT5kZXYsICIlczogU2hpZnQgdmlv bGF0aW9uIGluZm8gZmFpbGVkXG4iLCBfX2Z1bmNfXyk7DQo+ID4+DQo+ID4+IEluIHdoaWNoIGNh c2UgdGhpcyBjYW4gaGFwcGVuPyBJJ20gYXNraW5nLCBiZWNhdXNlIHdlIGFyZSBjYWxsaW5nDQo+ ID4+IGRldmFwY19zeW5jX3Zpb19kYmcoKSBpbiBhIHdoaWxlIGxvb3AgdGhhdCBjb3VsZCBtYWtl IHRoZSBrZXJuZWwgaGFuZyBoZXJlLg0KPiA+Pg0KPiA+PiBEbyBJIHVuZGVyc3RhbmQgY29ycmVj dGx5LCB0aGF0IHdlIGFyZSB1c2luZyB0aGUgd2hpbGUgbG9vcCwgYmVjYXVzZSB0aGVyZSBjYW4N Cj4gPj4gYmUgbW9yZSB0aGVuIG9uZSB2aW9sYXRpb24gZ3JvdXAgd2hpY2ggZ290IHRyaWdnZXJl ZCAocmVhZCwgbW9yZSB0aGVuIG9uZSBiaXQgaXMNCj4gPj4gc2V0IGluIHBkX3Zpb19zaGlmdF9z dGFfcmVnKT8gV291bGQgaXQgbWFrZSBtb3JlIHNlbnNlIHRoZW4gdG8gcmVhZCB0aGUgcmVnaXN0 ZXINCj4gPj4gb25jZSBhbmQgZG8gYWxsIHRoZSBzaGlmdCBvcGVyYXRpb24gZm9yIGFsbCBncm91 cHMgd2hpY2ggYml0IHNldCB0byAxIGluIHRoZQ0KPiA+PiBzaGlmdCBzdGF0dXMgcmVnaXN0ZXI/ DQo+ID4gDQo+ID4gWWVzLCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4NCj4gPiBUaGlz IGNoZWNrIGFsc28gaW1wbGllcyBIVyBzdGF0dXMgaGFzIHNvbWV0aGluZyB3cm9uZy4gV2UgcmV0 dXJuIGZhbHNlDQo+ID4gdG8gc2tpcCBmdXJ0aGVyIHZpb2xhdGlvbiBpbmZvIGR1bXAuDQo+ID4g SG93IGNvdWxkIHRoaXMgY2FzZSBtYWtlIHRoZSBrZXJuZWwgaGFuZz8NCj4gPiANCj4gDQo+IFRo ZSBrZXJuZWwgY2FuJ3QgaGFuZywgc29ycnkgbXkgZmF1bHQuIEluIGFueSBjYXNlIEknZCBhZGQg YSBXQVJOKCkgaGVyZSBhcyANCj4gd2VsbC4gSSB1bmRlcnN0YW5kIHRoYXQgaWYgd2UgZXJyb3Ig b3V0IGhlcmUsIHdlIGhhdmUgYSBIVy9GVyBidWcgKG15IGZlZWxpbmcgDQo+IGlzLCB0aGF0IGJl aGluZCB0aGlzIGlzIGEgbWljcm8gY29udHJvbGxlciBvZiBzb21lIGtpbmQgOikNCj4gDQoNCkkn bGwgYWxzbyBhZGQgd2FybiBtZXNzYWdlcyBvbiBuZXh0IHBhdGNoLg0KDQo+ID4+DQo+ID4+PiAr CQlyZXR1cm4gZmFsc2U7DQo+ID4+PiArCX0NCj4gPj4+ICsNCj4gPj4+ICsJLyogU3RvcCBzeW5j aW5nICovDQo+ID4+PiArCXdyaXRlbCgweDAsIHBkX3Zpb19zaGlmdF9jb25fcmVnKTsNCj4gPj4+ ICsNCj4gPj4+ICsJLyogV3JpdGUgY2xlYXIgKi8NCj4gPj4+ICsJd3JpdGVsKDB4MSA8PCBtaW5f c2hpZnRfZ3JvdXAsIHBkX3Zpb19zaGlmdF9zdGFfcmVnKTsNCj4gPj4+ICsNCj4gPj4+ICsJcmV0 dXJuIHRydWU7DQo+ID4+PiArfQ0KPiA+Pj4gKw0KPiA+Pj4gKy8qDQo+ID4+PiArICogZGV2YXBj X2V4dHJhY3RfdmlvX2RiZyAtIGV4dHJhY3QgZnVsbCB2aW9sYXRpb24gaW5mb3JtYXRpb24gYWZ0 ZXIgZG9pbmcNCj4gPj4+ICsgKiAgICAgICAgICAgICAgICAgICAgICAgICAgc2hpZnQgbWVjaGFu aXNtLg0KPiA+Pj4gKyAqLw0KPiA+Pj4gK3N0YXRpYyB2b2lkIGRldmFwY19leHRyYWN0X3Zpb19k Ymcoc3RydWN0IG10a19kZXZhcGNfY29udGV4dCAqY3R4KQ0KPiA+Pj4gK3sNCj4gPj4+ICsJc3Ry dWN0IG10a19kZXZhcGNfdmlvX2RiZ3MgdmlvX2RiZ3M7DQo+ID4+PiArCXZvaWQgX19pb21lbSAq dmlvX2RiZzBfcmVnOw0KPiA+Pj4gKwl2b2lkIF9faW9tZW0gKnZpb19kYmcxX3JlZzsNCj4gPj4+ ICsNCj4gPj4+ICsJdmlvX2RiZzBfcmVnID0gY3R4LT5pbmZyYV9iYXNlICsgY3R4LT5kYXRhLT52 aW9fZGJnMF9vZmZzZXQ7DQo+ID4+PiArCXZpb19kYmcxX3JlZyA9IGN0eC0+aW5mcmFfYmFzZSAr IGN0eC0+ZGF0YS0+dmlvX2RiZzFfb2Zmc2V0Ow0KPiA+Pj4gKw0KPiA+Pj4gKwl2aW9fZGJncy52 aW9fZGJnMCA9IHJlYWRsKHZpb19kYmcwX3JlZyk7DQo+ID4+PiArCXZpb19kYmdzLnZpb19kYmcx ID0gcmVhZGwodmlvX2RiZzFfcmVnKTsNCj4gPj4+ICsNCj4gPj4+ICsJLyogUHJpbnQgdmlvbGF0 aW9uIGluZm9ybWF0aW9uICovDQo+ID4+PiArCWlmICh2aW9fZGJncy5kYmcwX2JpdHMudmlvX3cp DQo+ID4+PiArCQlkZXZfaW5mbyhjdHgtPmRldiwgIldyaXRlIFZpb2xhdGlvblxuIik7DQo+ID4+ PiArCWVsc2UgaWYgKHZpb19kYmdzLmRiZzBfYml0cy52aW9fcikNCj4gPj4+ICsJCWRldl9pbmZv KGN0eC0+ZGV2LCAiUmVhZCBWaW9sYXRpb25cbiIpOw0KPiA+Pj4gKw0KPiA+Pj4gKwlkZXZfaW5m byhjdHgtPmRldiwgIkJ1cyBJRDoweCV4LCBEb20gSUQ6MHgleCwgVmlvIEFkZHI6MHgleFxuIiwN Cj4gPj4+ICsJCSB2aW9fZGJncy5kYmcwX2JpdHMubXN0aWQsIHZpb19kYmdzLmRiZzBfYml0cy5k bW5pZCwNCj4gPj4+ICsJCSB2aW9fZGJncy52aW9fZGJnMSk7DQo+ID4+PiArfQ0KPiA+Pj4gKw0K PiA+Pj4gKy8qDQo+ID4+PiArICogZGV2YXBjX3Zpb2xhdGlvbl9pcnEgLSB0aGUgZGV2YXBjIElu dGVycnVwdCBTZXJ2aWNlIFJvdXRpbmUgKElTUikgd2lsbCBkdW1wDQo+ID4+PiArICogICAgICAg ICAgICAgICAgICAgICAgICB2aW9sYXRpb24gaW5mb3JtYXRpb24gaW5jbHVkaW5nIHdoaWNoIG1h c3RlciB2aW9sYXRlcw0KPiA+Pj4gKyAqICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXNzIHNs YXZlLg0KPiA+Pj4gKyAqLw0KPiA+Pj4gK3N0YXRpYyBpcnFyZXR1cm5fdCBkZXZhcGNfdmlvbGF0 aW9uX2lycShpbnQgaXJxX251bWJlciwNCj4gPj4+ICsJCQkJCXN0cnVjdCBtdGtfZGV2YXBjX2Nv bnRleHQgKmN0eCkNCj4gPj4NCj4gPj4gc3RhdGljIGlycXJldHVybl90IGRldmFwY192aW9sYXRp b25faXJxKGludCBpcnFfbnVtYmVyLCB2b2lkICpkYXRhKQ0KPiA+PiB7DQo+ID4+IAlzdHJ1Y3Qg bXRrX2RldmFwY19jb250ZXh0ICpjdHggPSBkYXRhOw0KPiA+IA0KPiA+IE9rYXksIEknbGwgZml4 IGl0IG9uIG5leHQgcGF0Y2guDQo+ID4gVGhhbmtzDQo+ID4gDQo+ID4+DQo+ID4+PiArew0KPiA+ Pj4gKwl3aGlsZSAoZGV2YXBjX3N5bmNfdmlvX2RiZyhjdHgpKQ0KPiA+Pj4gKwkJZGV2YXBjX2V4 dHJhY3RfdmlvX2RiZyhjdHgpOw0KPiA+Pj4gKw0KPiA+Pj4gKwljbGVhcl92aW9fc3RhdHVzKGN0 eCk7DQo+ID4+PiArDQo+ID4+PiArCXJldHVybiBJUlFfSEFORExFRDsNCj4gPj4+ICt9DQo+ID4+ PiArDQo+ID4+PiArLyoNCj4gPj4+ICsgKiBzdGFydF9kZXZhcGMgLSB1bm1hc2sgc2xhdmUncyBp cnEgdG8gc3RhcnQgcmVjZWl2aW5nIGRldmFwYyB2aW9sYXRpb24uDQo+ID4+PiArICovDQo+ID4+ PiArc3RhdGljIHZvaWQgc3RhcnRfZGV2YXBjKHN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0 eCkNCj4gPj4+ICt7DQo+ID4+PiArCXdyaXRlbChCSVQoMzEpLCBjdHgtPmluZnJhX2Jhc2UgKyBj dHgtPmRhdGEtPmFwY19jb25fb2Zmc2V0KTsNCj4gPj4+ICsNCj4gPj4+ICsJbWFza19tb2R1bGVf aXJxKGN0eCwgZmFsc2UpOw0KPiA+Pj4gK30NCj4gPj4+ICsNCj4gPj4+ICsvKg0KPiA+Pj4gKyAq IHN0b3BfZGV2YXBjIC0gbWFzayBzbGF2ZSdzIGlycSB0byBzdG9wIHNlcnZpY2UuDQo+ID4+PiAr ICovDQo+ID4+PiArc3RhdGljIHZvaWQgc3RvcF9kZXZhcGMoc3RydWN0IG10a19kZXZhcGNfY29u dGV4dCAqY3R4KQ0KPiA+Pj4gK3sNCj4gPj4+ICsJbWFza19tb2R1bGVfaXJxKGN0eCwgdHJ1ZSk7 DQo+ID4+PiArDQo+ID4+PiArCXdyaXRlbChCSVQoMiksIGN0eC0+aW5mcmFfYmFzZSArIGN0eC0+ ZGF0YS0+YXBjX2Nvbl9vZmZzZXQpOw0KPiA+Pj4gK30NCj4gPj4+ICsNCj4gPj4+ICtzdGF0aWMg Y29uc3Qgc3RydWN0IG10a19kZXZhcGNfZGF0YSBkZXZhcGNfbXQ2Nzc5ID0gew0KPiA+Pj4gKwku dmlvX2lkeF9udW0gPSA1MTEsDQo+ID4+PiArCS52aW9fbWFza19vZmZzZXQgPSAweDAsDQo+ID4+ PiArCS52aW9fc3RhX29mZnNldCA9IDB4NDAwLA0KPiA+Pj4gKwkudmlvX2RiZzBfb2Zmc2V0ID0g MHg5MDAsDQo+ID4+PiArCS52aW9fZGJnMV9vZmZzZXQgPSAweDkwNCwNCj4gPj4+ICsJLmFwY19j b25fb2Zmc2V0ID0gMHhGMDAsDQo+ID4+PiArCS52aW9fc2hpZnRfc3RhX29mZnNldCA9IDB4RjEw LA0KPiA+Pj4gKwkudmlvX3NoaWZ0X3NlbF9vZmZzZXQgPSAweEYxNCwNCj4gPj4+ICsJLnZpb19z aGlmdF9jb25fb2Zmc2V0ID0gMHhGMjAsDQo+ID4+PiArfTsNCj4gPj4+ICsNCj4gPj4+ICtzdGF0 aWMgY29uc3Qgc3RydWN0IG9mX2RldmljZV9pZCBtdGtfZGV2YXBjX2R0X21hdGNoW10gPSB7DQo+ ID4+PiArCXsNCj4gPj4+ICsJCS5jb21wYXRpYmxlID0gIm1lZGlhdGVrLG10Njc3OS1kZXZhcGMi LA0KPiA+Pj4gKwkJLmRhdGEgPSAmZGV2YXBjX210Njc3OSwNCj4gPj4+ICsJfSwgew0KPiA+Pj4g Kwl9LA0KPiA+Pj4gK307DQo+ID4+PiArDQo+ID4+PiArc3RhdGljIGludCBtdGtfZGV2YXBjX3By b2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ID4+PiArew0KPiA+Pj4gKwlzdHJ1 Y3QgZGV2aWNlX25vZGUgKm5vZGUgPSBwZGV2LT5kZXYub2Zfbm9kZTsNCj4gPj4+ICsJc3RydWN0 IG10a19kZXZhcGNfY29udGV4dCAqY3R4Ow0KPiA+Pj4gKwl1MzIgZGV2YXBjX2lycTsNCj4gPj4+ ICsJaW50IHJldDsNCj4gPj4+ICsNCj4gPj4+ICsJaWYgKElTX0VSUihub2RlKSkNCj4gPj4+ICsJ CXJldHVybiAtRU5PREVWOw0KPiA+Pj4gKw0KPiA+Pj4gKwljdHggPSBkZXZtX2t6YWxsb2MoJnBk ZXYtPmRldiwgc2l6ZW9mKCpjdHgpLCBHRlBfS0VSTkVMKTsNCj4gPj4+ICsJaWYgKCFjdHgpDQo+ ID4+PiArCQlyZXR1cm4gLUVOT01FTTsNCj4gPj4+ICsNCj4gPj4+ICsJY3R4LT5kYXRhID0gb2Zf ZGV2aWNlX2dldF9tYXRjaF9kYXRhKCZwZGV2LT5kZXYpOw0KPiA+Pj4gKwljdHgtPmRldiA9ICZw ZGV2LT5kZXY7DQo+ID4+PiArDQo+ID4+PiArCWN0eC0+aW5mcmFfYmFzZSA9IG9mX2lvbWFwKG5v ZGUsIDApOw0KPiA+Pg0KPiA+PiBEb2VzIHRoaXMgbWVhbiB0aGUgZGV2aWNlIGlzIHBhcnQgb2Yg dGhlIGluZnJhY2ZnIGJsb2NrPw0KPiA+PiBJIHdhc24ndCBhYmxlIHRvIGZpbmQgYW55IGluZm9y bWF0aW9uIGFib3V0IGl0Lg0KPiA+IA0KPiA+IEknbSBub3Qgc3VyZSB3aHkgeW91IHdvdWxkIGFz ayBpbmZyYWNmZyBibG9jay4gZGV2YXBjIGlzIHBhcnRzIG9mIG91cg0KPiA+IFNvQyBpbmZyYSwg aXQncyBkaWZmZXJlbnQgd2l0aCBpbmZyYWNmZy4NCj4gPiANCj4gDQo+IEknbSBhc2tpbmcgYmVj YXVzZSBJIHdhbnQgdG8gdW5kZXJzdGFuZCB0aGUgSFcgYmV0dGVyLiBJJ20gbm90IGFibGUgdG8g ZmluZCBhbnkgDQo+IGluZm9ybWF0aW9uIGluIHRoZSBkYXRhc2hlZXRzLiBJIHdhbnQgdG8gYXZv aWQgYSBzaXR1YXRpb24gYXMgd2UgaGFkIHdpdGggdGhlIA0KPiBNTVNZUyB3aGVyZSBhIGNsb2Nr IGRyaXZlciB3YXMgc3VibWl0dGVkIGZpcnN0IGFuZCBsYXRlciBvbiB3ZSByZWFsaXplZCB0aGF0 IA0KPiBNTVNZUyBpcyBtdWNoIG1vcmUgdGhlbiB0aGF0IGFuZCB3ZSBoYWQgdG8gd29yayBoYXJk IHRvIGdldCB0aGUgZHJpdmVyIHJpZ2h0Lg0KPiANCj4gTm93IGl0J3MgaGFwcGVuaW5nIHdpdGgg U0NQU1lTLCB3aGVyZSBhIGRyaXZlciB3aXRoIHRoZSBzY3BzeXMgY29tcGF0aWJsZSB3YXMgDQo+ IHNlbmQgeWVhcnMgYWdvLiBCdXQgU0NQU1lTIGlzIG11Y2ggbW9yZSB0aGVuIHRoZSBkcml2ZXIg c3VibWl0dGVkLiBJbiB0aGlzIGNhc2UgDQo+IHdlIG9wdGVkIHRvIHdyaXRlIGEgbmV3IGRyaXZl ciwgYnV0IG1vdmluZyBmcm9tIG9uZSBkcml2ZXIgdG8gYW5vdGhlciBvbmUgaXMgDQo+IHBhaW5m dWxsIGFuZCBmdWxsIG9mIHByb2JsZW1zLiBGb3IgdGhhdCBJIHdhbnQgdG8gbWFrZSBzdXJlIHdl IGZ1bGx5IHVuZGVyc3RhbmQgDQo+IERldmljZSBBUEMgKGJ5IHRoZSB3YXksIHdoYXQgZG9lcyBB UEMgc3RhbmRzIGZvcj8pLiBJcyBpdCBhIHRvdGFsbHkgaW5kZXBlbmRlbnQgDQo+IEhXIGJsb2Nr IG9yIGlzIGl0IHBhcnQgb2YgYSBzdWJzeXN0ZW0sIGxpa2UgZm9yIGV4YW1wbGUgU0NQPw0KPiAN Cj4gUmVnYXJkcywNCj4gTWF0dGhpYXMNCg0KSXQncyBhIHRvdGFsbHkgaW5kZXBlbmRlbnQgSFcg YmxvY2sgaW5zdGVhZCBvZiBhIHN1YnN5c3RlbS4NCkkgdGhpbmsgaXQncyBtb3JlIHNpbXBsZSB0 aGFuIE1NU1lTIG9yIFNDUFNZUy4gQnV0IGlmIHlvdSB3b3VsZCBsaWtlIHRvDQp1bmRlcnN0YW5k IG1vcmUgYWJvdXQgdGhpcyBIVywgd2UgY291bGQgZmluZCBhbm90aGVyIHdheS9jaGFubmVsIHRv DQppbnRyb2R1Y2UgaXQuDQoNCg0K