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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 4E3CAC433E7 for ; Thu, 15 Oct 2020 02:14:13 +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 5C3C022255 for ; Thu, 15 Oct 2020 02:14:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="grII8j/e"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="O40sYf0U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C3C022255 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=gh2QgOLQ5ET7JGP7mus+FDvNgO1/Uva8YxICDLhbyuU=; b=grII8j/eDOyfUcEfSRxn5jZ4L acJr30zKobh+vwaExd+Xy/xJ+O/T7YDuImxgffhjt+/YDMORVdLDFzHT3OHf2DgxMvMwOC7LTVTpG WY+gOF3SClTH2Cl5l6tFSBX6GqdFDbtMS4ntHfQtUTqpTUJacz3VoguNZTEJBAZuVj587Pduo0JqD E3iHASXLdRgA3nODhXfwFkmEP6T3LlmXhQizrbGkMBx4RUqB6zLLTGTtfrM+n/rjE0BBiHQuBU3DS 6R40FD1ypT2iXi5RAVP8ljq0fhP+Oido1nWhdfiEEEDFYX4j5dY/8X0BLJvBDU+pf0wIfGugZwvzW N1bhETj2w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSsmH-0000qF-NW; Thu, 15 Oct 2020 02:14:01 +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 1kSsmE-0000p1-4O; Thu, 15 Oct 2020 02:13:59 +0000 X-UUID: 58c9fc5a5ce44b798b33592b424b2aef-20201014 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=IZyDYUlfeht5gnS9jjLlYuC/tfwrT3+I9bjOaLFcuGg=; b=O40sYf0Uovi/mBipz7ijWA7QZKMwglN5hf3ux+uUDiUFMvkgxwSXrdYhQfbdTv67Dmjai9MQ3KkhYIQvnY3ByIJd5tSRGkwIRqi/eWIfBM1bOKL/B1XlAKTW7ZYNQzgwg3OMcQdsPEzEOfYarmVV/Z4RpX1YroRAG2ZJxkC7CHo=; X-UUID: 58c9fc5a5ce44b798b33592b424b2aef-20201014 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 1576527738; Wed, 14 Oct 2020 18:13:46 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Oct 2020 19:13:43 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 10:13:37 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 10:13:35 +0800 Message-ID: <1602728017.11536.5.camel@mtkswgap22> Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver From: Neal Liu To: Matthias Brugger Date: Thu, 15 Oct 2020 10:13:37 +0800 In-Reply-To: <1602124514.28301.17.camel@mtkswgap22> 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-20201014_221358_305716_E1FB2404 X-CRM114-Status: GOOD ( 37.17 ) 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 , "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:35 +0800, Neal Liu wrote: > On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote: > > > > On 27/08/2020 05:06, Neal Liu wrote: [...] > > > +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? > Sorry, I missed the most common part. Is function is in the while loop: while (devapc_sync_vio_dbg(ctx)) ... We keep find the minimum bit in pd_vio_shift_sta_reg to get the violation information, (pd_vio_shift_sta_reg might raise multiple bits) until all raised bit (shift group) has been handled. So I don't think it's necessary to add WARN message in this case. 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? > > > > > > + 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. > > > > > > + if (!ctx->infra_base) > > > + return -EINVAL; > > > + > > > + devapc_irq = irq_of_parse_and_map(node, 0); > > > + if (!devapc_irq) > > > + return -EINVAL; > > > + > > > + ctx->infra_clk = devm_clk_get(&pdev->dev, "devapc-infra-clock"); > > > + if (IS_ERR(ctx->infra_clk)) > > > + return -EINVAL; > > > + > > > + if (clk_prepare_enable(ctx->infra_clk)) > > > + return -EINVAL; > > > + > > > + ret = devm_request_irq(&pdev->dev, devapc_irq, > > > + (irq_handler_t)devapc_violation_irq, > > > > No cast should be needed. > > Okay, I'll remove it on next patch. > Thanks > > > > > > + IRQF_TRIGGER_NONE, "devapc", ctx); > > > + if (ret) { > > > + clk_disable_unprepare(ctx->infra_clk); > > > + return ret; > > > + } > > > + > > > + platform_set_drvdata(pdev, ctx); > > > + > > > + start_devapc(ctx); > > > + > > > + return 0; > > > +} > > > + > > > +static int mtk_devapc_remove(struct platform_device *pdev) > > > +{ > > > + struct mtk_devapc_context *ctx = platform_get_drvdata(pdev); > > > + > > > + stop_devapc(ctx); > > > + > > > + clk_disable_unprepare(ctx->infra_clk); > > > + > > > + return 0; > > > +} > > > + > > > +static struct platform_driver mtk_devapc_driver = { > > > + .probe = mtk_devapc_probe, > > > + .remove = mtk_devapc_remove, > > > + .driver = { > > > + .name = KBUILD_MODNAME, > > > > .name = "mtk-devapc", > > Okay, I'll add it on next patch. > Thanks > > > > > Regards, > > Matthias > > _______________________________________________ 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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 B19B8C433DF for ; Thu, 15 Oct 2020 02:15:59 +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 0EA6322255 for ; Thu, 15 Oct 2020 02:15:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FK1GNDu/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="O40sYf0U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EA6322255 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=8sh4QyzZRF5H1emiOSwobaFJgw1qlWwJ+oKz2CQy0do=; b=FK1GNDu/vskYl1Gw9F9yz3QxY ZYuevqTYIZ6VZXDhWZk7vZw6a6ahvS7e2S6kdfB8OzUliy4MY9SA7kUD6nNhFfFh0B7JT0dzZebJS IsPC7uW6JAoEDiUMK6758JZxa5AMGlU4O5Ug5Gci5KzX+CGFlgVMePBvCzJS7iFXo0+of08WFKrjO BxMlCH8XSLcS7crc6FikLHdWZM4A6rWsiKIomohnRU6zwQWgmqvQjemJoB+VfopM0WseMVVGy2h/3 u07PMJW8pdirbGRs071b55a0vb8jNUaZIlRvL6UjoaRfzd2xcz/DSmF/kYX1casDumm3NWg4B+Jhc TzjAJ5F1Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSsmG-0000q2-Kh; Thu, 15 Oct 2020 02:14:00 +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 1kSsmE-0000p1-4O; Thu, 15 Oct 2020 02:13:59 +0000 X-UUID: 58c9fc5a5ce44b798b33592b424b2aef-20201014 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=IZyDYUlfeht5gnS9jjLlYuC/tfwrT3+I9bjOaLFcuGg=; b=O40sYf0Uovi/mBipz7ijWA7QZKMwglN5hf3ux+uUDiUFMvkgxwSXrdYhQfbdTv67Dmjai9MQ3KkhYIQvnY3ByIJd5tSRGkwIRqi/eWIfBM1bOKL/B1XlAKTW7ZYNQzgwg3OMcQdsPEzEOfYarmVV/Z4RpX1YroRAG2ZJxkC7CHo=; X-UUID: 58c9fc5a5ce44b798b33592b424b2aef-20201014 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 1576527738; Wed, 14 Oct 2020 18:13:46 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Oct 2020 19:13:43 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 10:13:37 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 10:13:35 +0800 Message-ID: <1602728017.11536.5.camel@mtkswgap22> Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver From: Neal Liu To: Matthias Brugger Date: Thu, 15 Oct 2020 10:13:37 +0800 In-Reply-To: <1602124514.28301.17.camel@mtkswgap22> 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-20201014_221358_305716_E1FB2404 X-CRM114-Status: GOOD ( 37.17 ) 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 , "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:35 +0800, Neal Liu wrote: > On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote: > > > > On 27/08/2020 05:06, Neal Liu wrote: [...] > > > +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? > Sorry, I missed the most common part. Is function is in the while loop: while (devapc_sync_vio_dbg(ctx)) ... We keep find the minimum bit in pd_vio_shift_sta_reg to get the violation information, (pd_vio_shift_sta_reg might raise multiple bits) until all raised bit (shift group) has been handled. So I don't think it's necessary to add WARN message in this case. 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? > > > > > > + 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. > > > > > > + if (!ctx->infra_base) > > > + return -EINVAL; > > > + > > > + devapc_irq = irq_of_parse_and_map(node, 0); > > > + if (!devapc_irq) > > > + return -EINVAL; > > > + > > > + ctx->infra_clk = devm_clk_get(&pdev->dev, "devapc-infra-clock"); > > > + if (IS_ERR(ctx->infra_clk)) > > > + return -EINVAL; > > > + > > > + if (clk_prepare_enable(ctx->infra_clk)) > > > + return -EINVAL; > > > + > > > + ret = devm_request_irq(&pdev->dev, devapc_irq, > > > + (irq_handler_t)devapc_violation_irq, > > > > No cast should be needed. > > Okay, I'll remove it on next patch. > Thanks > > > > > > + IRQF_TRIGGER_NONE, "devapc", ctx); > > > + if (ret) { > > > + clk_disable_unprepare(ctx->infra_clk); > > > + return ret; > > > + } > > > + > > > + platform_set_drvdata(pdev, ctx); > > > + > > > + start_devapc(ctx); > > > + > > > + return 0; > > > +} > > > + > > > +static int mtk_devapc_remove(struct platform_device *pdev) > > > +{ > > > + struct mtk_devapc_context *ctx = platform_get_drvdata(pdev); > > > + > > > + stop_devapc(ctx); > > > + > > > + clk_disable_unprepare(ctx->infra_clk); > > > + > > > + return 0; > > > +} > > > + > > > +static struct platform_driver mtk_devapc_driver = { > > > + .probe = mtk_devapc_probe, > > > + .remove = mtk_devapc_remove, > > > + .driver = { > > > + .name = KBUILD_MODNAME, > > > > .name = "mtk-devapc", > > Okay, I'll add it on next patch. > Thanks > > > > > Regards, > > Matthias > > _______________________________________________ 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=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 882C3C433DF for ; Thu, 15 Oct 2020 02:13:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DDA4D22257 for ; Thu, 15 Oct 2020 02:13:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="O40sYf0U" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726711AbgJOCNo (ORCPT ); Wed, 14 Oct 2020 22:13:44 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:43267 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726028AbgJOCNo (ORCPT ); Wed, 14 Oct 2020 22:13:44 -0400 X-UUID: 8b83bb30da2b46e09444a0fa03bcd9ff-20201015 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=IZyDYUlfeht5gnS9jjLlYuC/tfwrT3+I9bjOaLFcuGg=; b=O40sYf0Uovi/mBipz7ijWA7QZKMwglN5hf3ux+uUDiUFMvkgxwSXrdYhQfbdTv67Dmjai9MQ3KkhYIQvnY3ByIJd5tSRGkwIRqi/eWIfBM1bOKL/B1XlAKTW7ZYNQzgwg3OMcQdsPEzEOfYarmVV/Z4RpX1YroRAG2ZJxkC7CHo=; X-UUID: 8b83bb30da2b46e09444a0fa03bcd9ff-20201015 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] 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 1224820190; Thu, 15 Oct 2020 10:13:39 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 10:13:37 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 10:13:35 +0800 Message-ID: <1602728017.11536.5.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 , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mediatek@lists.infradead.org" , lkml , wsd_upstream Date: Thu, 15 Oct 2020 10:13:37 +0800 In-Reply-To: <1602124514.28301.17.camel@mtkswgap22> 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 T24gVGh1LCAyMDIwLTEwLTA4IGF0IDEwOjM1ICswODAwLCBOZWFsIExpdSB3cm90ZToNCj4gT24g V2VkLCAyMDIwLTEwLTA3IGF0IDEyOjQ0ICswMjAwLCBNYXR0aGlhcyBCcnVnZ2VyIHdyb3RlOg0K PiA+IA0KPiA+IE9uIDI3LzA4LzIwMjAgMDU6MDYsIE5lYWwgTGl1IHdyb3RlOg0KWy4uLl0NCg0K PiA+ID4gK3N0YXRpYyBpbnQgZGV2YXBjX3N5bmNfdmlvX2RiZyhzdHJ1Y3QgbXRrX2RldmFwY19j b250ZXh0ICpjdHgpDQo+ID4gPiArew0KPiA+ID4gKwl2b2lkIF9faW9tZW0gKnBkX3Zpb19zaGlm dF9zdGFfcmVnOw0KPiA+ID4gKwl2b2lkIF9faW9tZW0gKnBkX3Zpb19zaGlmdF9zZWxfcmVnOw0K PiA+ID4gKwl2b2lkIF9faW9tZW0gKnBkX3Zpb19zaGlmdF9jb25fcmVnOw0KPiA+ID4gKwlpbnQg bWluX3NoaWZ0X2dyb3VwOw0KPiA+ID4gKwlpbnQgcmV0Ow0KPiA+ID4gKwl1MzIgdmFsOw0KPiA+ ID4gKw0KPiA+ID4gKwlwZF92aW9fc2hpZnRfc3RhX3JlZyA9IGN0eC0+aW5mcmFfYmFzZSArDQo+ ID4gPiArCQkJICAgICAgIGN0eC0+ZGF0YS0+dmlvX3NoaWZ0X3N0YV9vZmZzZXQ7DQo+ID4gPiAr CXBkX3Zpb19zaGlmdF9zZWxfcmVnID0gY3R4LT5pbmZyYV9iYXNlICsNCj4gPiA+ICsJCQkgICAg ICAgY3R4LT5kYXRhLT52aW9fc2hpZnRfc2VsX29mZnNldDsNCj4gPiA+ICsJcGRfdmlvX3NoaWZ0 X2Nvbl9yZWcgPSBjdHgtPmluZnJhX2Jhc2UgKw0KPiA+ID4gKwkJCSAgICAgICBjdHgtPmRhdGEt PnZpb19zaGlmdF9jb25fb2Zmc2V0Ow0KPiA+ID4gKw0KPiA+ID4gKwkvKiBGaW5kIHRoZSBtaW5p bXVtIHNoaWZ0IGdyb3VwIHdoaWNoIGhhcyB2aW9sYXRpb24gKi8NCj4gPiA+ICsJdmFsID0gcmVh ZGwocGRfdmlvX3NoaWZ0X3N0YV9yZWcpOw0KPiA+ID4gKwlpZiAoIXZhbCkNCj4gPiA+ICsJCXJl dHVybiBmYWxzZTsNCj4gPiANCj4gPiBTbyBiaXQgMCBvZiBzZWxlY3Rpb24gcmVnaXN0ZXIgKHBk X3Zpb19zaGlmdF9zZWxfcmVnKSBkb2VzIG5vdCByZXByZXNlbnQgYSANCj4gPiB2aW9sYXRpb24g Z3JvdXA/DQo+ID4gSSBkb24ndCBrbm93IGhvdyB0aGUgSFcgd29ya3MsIGJ1dCBpcyBzZWVtcyBv ZGQgdG8gbWUuIEluIGNhc2UgdGhhdCdzIGJpdCAwIA0KPiA+IGFjdHVhbGx5IGRvZXNuJ3QgcmVw cmVzZW50IGFueXRoaW5nOiBob3cgY2FuIGFuIGludGVycnVwdCBiZSB0cmlnZ2VyZWQgd2l0aG91 dCANCj4gPiBhbnkgZGVidWcgaW5mb3JtYXRpb24gcHJlc2VudCAobWVhbnMgdmFsID09IDApPw0K PiANCj4gVGhpcyBjaGVjayBpbXBsaWVzIEhXIHN0YXR1cyBoYXMgc29tZXRoaW5nIHdyb25nLiBJ dCBjYW5ub3QgZ2V0IGFueQ0KPiBkZWJ1ZyBpbmZvcm1hdGlvbiBmb3IgdGhpcyBjYXNlLg0KPiBJ dCB3b24ndCBoYXBwZW4gaW4gbm9ybWFsIHNjZW5hcmlvLiBTaG91bGQgd2UgcmVtb3ZlIHRoaXMg Y2hlY2s/DQo+IA0KDQpTb3JyeSwgSSBtaXNzZWQgdGhlIG1vc3QgY29tbW9uIHBhcnQuIElzIGZ1 bmN0aW9uIGlzIGluIHRoZSB3aGlsZSBsb29wOg0Kd2hpbGUgKGRldmFwY19zeW5jX3Zpb19kYmco Y3R4KSkNCi4uLg0KDQpXZSBrZWVwIGZpbmQgdGhlIG1pbmltdW0gYml0IGluIHBkX3Zpb19zaGlm dF9zdGFfcmVnIHRvIGdldCB0aGUNCnZpb2xhdGlvbiBpbmZvcm1hdGlvbiwgKHBkX3Zpb19zaGlm dF9zdGFfcmVnIG1pZ2h0IHJhaXNlIG11bHRpcGxlIGJpdHMpDQp1bnRpbCBhbGwgcmFpc2VkIGJp dCAoc2hpZnQgZ3JvdXApIGhhcyBiZWVuIGhhbmRsZWQuDQpTbyBJIGRvbid0IHRoaW5rIGl0J3Mg bmVjZXNzYXJ5IHRvIGFkZCBXQVJOIG1lc3NhZ2UgaW4gdGhpcyBjYXNlLg0KVGhhbmtzDQoNCj4g PiANCj4gPiA+ICsNCj4gPiA+ICsJbWluX3NoaWZ0X2dyb3VwID0gX19mZnModmFsKTsNCj4gPiA+ ICsNCj4gPiA+ICsJLyogQXNzaWduIHRoZSBncm91cCB0byBzeW5jICovDQo+ID4gPiArCXdyaXRl bCgweDEgPDwgbWluX3NoaWZ0X2dyb3VwLCBwZF92aW9fc2hpZnRfc2VsX3JlZyk7DQo+ID4gPiAr DQo+ID4gPiArCS8qIFN0YXJ0IHN5bmNpbmcgKi8NCj4gPiA+ICsJd3JpdGVsKDB4MSwgcGRfdmlv X3NoaWZ0X2Nvbl9yZWcpOw0KPiA+ID4gKw0KPiA+ID4gKwlyZXQgPSByZWFkbF9wb2xsX3RpbWVv dXQocGRfdmlvX3NoaWZ0X2Nvbl9yZWcsIHZhbCwgdmFsID09IDB4MywgMCwNCj4gPiA+ICsJCQkJ IFBIWV9ERVZBUENfVElNRU9VVCk7DQo+ID4gPiArCWlmIChyZXQpIHsNCj4gPiA+ICsJCWRldl9l cnIoY3R4LT5kZXYsICIlczogU2hpZnQgdmlvbGF0aW9uIGluZm8gZmFpbGVkXG4iLCBfX2Z1bmNf Xyk7DQo+ID4gDQo+ID4gSW4gd2hpY2ggY2FzZSB0aGlzIGNhbiBoYXBwZW4/IEknbSBhc2tpbmcs IGJlY2F1c2Ugd2UgYXJlIGNhbGxpbmcgDQo+ID4gZGV2YXBjX3N5bmNfdmlvX2RiZygpIGluIGEg d2hpbGUgbG9vcCB0aGF0IGNvdWxkIG1ha2UgdGhlIGtlcm5lbCBoYW5nIGhlcmUuDQo+ID4gDQo+ ID4gRG8gSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhhdCB3ZSBhcmUgdXNpbmcgdGhlIHdoaWxl IGxvb3AsIGJlY2F1c2UgdGhlcmUgY2FuIA0KPiA+IGJlIG1vcmUgdGhlbiBvbmUgdmlvbGF0aW9u IGdyb3VwIHdoaWNoIGdvdCB0cmlnZ2VyZWQgKHJlYWQsIG1vcmUgdGhlbiBvbmUgYml0IGlzIA0K PiA+IHNldCBpbiBwZF92aW9fc2hpZnRfc3RhX3JlZyk/IFdvdWxkIGl0IG1ha2UgbW9yZSBzZW5z ZSB0aGVuIHRvIHJlYWQgdGhlIHJlZ2lzdGVyIA0KPiA+IG9uY2UgYW5kIGRvIGFsbCB0aGUgc2hp ZnQgb3BlcmF0aW9uIGZvciBhbGwgZ3JvdXBzIHdoaWNoIGJpdCBzZXQgdG8gMSBpbiB0aGUgDQo+ ID4gc2hpZnQgc3RhdHVzIHJlZ2lzdGVyPw0KPiANCj4gWWVzLCB5b3VyIHVuZGVyc3RhbmRpbmcg aXMgY29ycmVjdC4NCj4gVGhpcyBjaGVjayBhbHNvIGltcGxpZXMgSFcgc3RhdHVzIGhhcyBzb21l dGhpbmcgd3JvbmcuIFdlIHJldHVybiBmYWxzZQ0KPiB0byBza2lwIGZ1cnRoZXIgdmlvbGF0aW9u IGluZm8gZHVtcC4NCj4gSG93IGNvdWxkIHRoaXMgY2FzZSBtYWtlIHRoZSBrZXJuZWwgaGFuZz8N Cj4gDQo+ID4gDQo+ID4gPiArCQlyZXR1cm4gZmFsc2U7DQo+ID4gPiArCX0NCj4gPiA+ICsNCj4g PiA+ICsJLyogU3RvcCBzeW5jaW5nICovDQo+ID4gPiArCXdyaXRlbCgweDAsIHBkX3Zpb19zaGlm dF9jb25fcmVnKTsNCj4gPiA+ICsNCj4gPiA+ICsJLyogV3JpdGUgY2xlYXIgKi8NCj4gPiA+ICsJ d3JpdGVsKDB4MSA8PCBtaW5fc2hpZnRfZ3JvdXAsIHBkX3Zpb19zaGlmdF9zdGFfcmVnKTsNCj4g PiA+ICsNCj4gPiA+ICsJcmV0dXJuIHRydWU7DQo+ID4gPiArfQ0KPiA+ID4gKw0KPiA+ID4gKy8q DQo+ID4gPiArICogZGV2YXBjX2V4dHJhY3RfdmlvX2RiZyAtIGV4dHJhY3QgZnVsbCB2aW9sYXRp b24gaW5mb3JtYXRpb24gYWZ0ZXIgZG9pbmcNCj4gPiA+ICsgKiAgICAgICAgICAgICAgICAgICAg ICAgICAgc2hpZnQgbWVjaGFuaXNtLg0KPiA+ID4gKyAqLw0KPiA+ID4gK3N0YXRpYyB2b2lkIGRl dmFwY19leHRyYWN0X3Zpb19kYmcoc3RydWN0IG10a19kZXZhcGNfY29udGV4dCAqY3R4KQ0KPiA+ ID4gK3sNCj4gPiA+ICsJc3RydWN0IG10a19kZXZhcGNfdmlvX2RiZ3MgdmlvX2RiZ3M7DQo+ID4g PiArCXZvaWQgX19pb21lbSAqdmlvX2RiZzBfcmVnOw0KPiA+ID4gKwl2b2lkIF9faW9tZW0gKnZp b19kYmcxX3JlZzsNCj4gPiA+ICsNCj4gPiA+ICsJdmlvX2RiZzBfcmVnID0gY3R4LT5pbmZyYV9i YXNlICsgY3R4LT5kYXRhLT52aW9fZGJnMF9vZmZzZXQ7DQo+ID4gPiArCXZpb19kYmcxX3JlZyA9 IGN0eC0+aW5mcmFfYmFzZSArIGN0eC0+ZGF0YS0+dmlvX2RiZzFfb2Zmc2V0Ow0KPiA+ID4gKw0K PiA+ID4gKwl2aW9fZGJncy52aW9fZGJnMCA9IHJlYWRsKHZpb19kYmcwX3JlZyk7DQo+ID4gPiAr CXZpb19kYmdzLnZpb19kYmcxID0gcmVhZGwodmlvX2RiZzFfcmVnKTsNCj4gPiA+ICsNCj4gPiA+ ICsJLyogUHJpbnQgdmlvbGF0aW9uIGluZm9ybWF0aW9uICovDQo+ID4gPiArCWlmICh2aW9fZGJn cy5kYmcwX2JpdHMudmlvX3cpDQo+ID4gPiArCQlkZXZfaW5mbyhjdHgtPmRldiwgIldyaXRlIFZp b2xhdGlvblxuIik7DQo+ID4gPiArCWVsc2UgaWYgKHZpb19kYmdzLmRiZzBfYml0cy52aW9fcikN Cj4gPiA+ICsJCWRldl9pbmZvKGN0eC0+ZGV2LCAiUmVhZCBWaW9sYXRpb25cbiIpOw0KPiA+ID4g Kw0KPiA+ID4gKwlkZXZfaW5mbyhjdHgtPmRldiwgIkJ1cyBJRDoweCV4LCBEb20gSUQ6MHgleCwg VmlvIEFkZHI6MHgleFxuIiwNCj4gPiA+ICsJCSB2aW9fZGJncy5kYmcwX2JpdHMubXN0aWQsIHZp b19kYmdzLmRiZzBfYml0cy5kbW5pZCwNCj4gPiA+ICsJCSB2aW9fZGJncy52aW9fZGJnMSk7DQo+ ID4gPiArfQ0KPiA+ID4gKw0KPiA+ID4gKy8qDQo+ID4gPiArICogZGV2YXBjX3Zpb2xhdGlvbl9p cnEgLSB0aGUgZGV2YXBjIEludGVycnVwdCBTZXJ2aWNlIFJvdXRpbmUgKElTUikgd2lsbCBkdW1w DQo+ID4gPiArICogICAgICAgICAgICAgICAgICAgICAgICB2aW9sYXRpb24gaW5mb3JtYXRpb24g aW5jbHVkaW5nIHdoaWNoIG1hc3RlciB2aW9sYXRlcw0KPiA+ID4gKyAqICAgICAgICAgICAgICAg ICAgICAgICAgYWNjZXNzIHNsYXZlLg0KPiA+ID4gKyAqLw0KPiA+ID4gK3N0YXRpYyBpcnFyZXR1 cm5fdCBkZXZhcGNfdmlvbGF0aW9uX2lycShpbnQgaXJxX251bWJlciwNCj4gPiA+ICsJCQkJCXN0 cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0eCkNCj4gPiANCj4gPiBzdGF0aWMgaXJxcmV0dXJu X3QgZGV2YXBjX3Zpb2xhdGlvbl9pcnEoaW50IGlycV9udW1iZXIsIHZvaWQgKmRhdGEpDQo+ID4g ew0KPiA+IAlzdHJ1Y3QgbXRrX2RldmFwY19jb250ZXh0ICpjdHggPSBkYXRhOw0KPiANCj4gT2th eSwgSSdsbCBmaXggaXQgb24gbmV4dCBwYXRjaC4NCj4gVGhhbmtzDQo+IA0KPiA+IA0KPiA+ID4g K3sNCj4gPiA+ICsJd2hpbGUgKGRldmFwY19zeW5jX3Zpb19kYmcoY3R4KSkNCj4gPiA+ICsJCWRl dmFwY19leHRyYWN0X3Zpb19kYmcoY3R4KTsNCj4gPiA+ICsNCj4gPiA+ICsJY2xlYXJfdmlvX3N0 YXR1cyhjdHgpOw0KPiA+ID4gKw0KPiA+ID4gKwlyZXR1cm4gSVJRX0hBTkRMRUQ7DQo+ID4gPiAr fQ0KPiA+ID4gKw0KPiA+ID4gKy8qDQo+ID4gPiArICogc3RhcnRfZGV2YXBjIC0gdW5tYXNrIHNs YXZlJ3MgaXJxIHRvIHN0YXJ0IHJlY2VpdmluZyBkZXZhcGMgdmlvbGF0aW9uLg0KPiA+ID4gKyAq Lw0KPiA+ID4gK3N0YXRpYyB2b2lkIHN0YXJ0X2RldmFwYyhzdHJ1Y3QgbXRrX2RldmFwY19jb250 ZXh0ICpjdHgpDQo+ID4gPiArew0KPiA+ID4gKwl3cml0ZWwoQklUKDMxKSwgY3R4LT5pbmZyYV9i YXNlICsgY3R4LT5kYXRhLT5hcGNfY29uX29mZnNldCk7DQo+ID4gPiArDQo+ID4gPiArCW1hc2tf bW9kdWxlX2lycShjdHgsIGZhbHNlKTsNCj4gPiA+ICt9DQo+ID4gPiArDQo+ID4gPiArLyoNCj4g PiA+ICsgKiBzdG9wX2RldmFwYyAtIG1hc2sgc2xhdmUncyBpcnEgdG8gc3RvcCBzZXJ2aWNlLg0K PiA+ID4gKyAqLw0KPiA+ID4gK3N0YXRpYyB2b2lkIHN0b3BfZGV2YXBjKHN0cnVjdCBtdGtfZGV2 YXBjX2NvbnRleHQgKmN0eCkNCj4gPiA+ICt7DQo+ID4gPiArCW1hc2tfbW9kdWxlX2lycShjdHgs IHRydWUpOw0KPiA+ID4gKw0KPiA+ID4gKwl3cml0ZWwoQklUKDIpLCBjdHgtPmluZnJhX2Jhc2Ug KyBjdHgtPmRhdGEtPmFwY19jb25fb2Zmc2V0KTsNCj4gPiA+ICt9DQo+ID4gPiArDQo+ID4gPiAr c3RhdGljIGNvbnN0IHN0cnVjdCBtdGtfZGV2YXBjX2RhdGEgZGV2YXBjX210Njc3OSA9IHsNCj4g PiA+ICsJLnZpb19pZHhfbnVtID0gNTExLA0KPiA+ID4gKwkudmlvX21hc2tfb2Zmc2V0ID0gMHgw LA0KPiA+ID4gKwkudmlvX3N0YV9vZmZzZXQgPSAweDQwMCwNCj4gPiA+ICsJLnZpb19kYmcwX29m ZnNldCA9IDB4OTAwLA0KPiA+ID4gKwkudmlvX2RiZzFfb2Zmc2V0ID0gMHg5MDQsDQo+ID4gPiAr CS5hcGNfY29uX29mZnNldCA9IDB4RjAwLA0KPiA+ID4gKwkudmlvX3NoaWZ0X3N0YV9vZmZzZXQg PSAweEYxMCwNCj4gPiA+ICsJLnZpb19zaGlmdF9zZWxfb2Zmc2V0ID0gMHhGMTQsDQo+ID4gPiAr CS52aW9fc2hpZnRfY29uX29mZnNldCA9IDB4RjIwLA0KPiA+ID4gK307DQo+ID4gPiArDQo+ID4g PiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2VfaWQgbXRrX2RldmFwY19kdF9tYXRjaFtd ID0gew0KPiA+ID4gKwl7DQo+ID4gPiArCQkuY29tcGF0aWJsZSA9ICJtZWRpYXRlayxtdDY3Nzkt ZGV2YXBjIiwNCj4gPiA+ICsJCS5kYXRhID0gJmRldmFwY19tdDY3NzksDQo+ID4gPiArCX0sIHsN Cj4gPiA+ICsJfSwNCj4gPiA+ICt9Ow0KPiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQgbXRrX2Rl dmFwY19wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiA+ID4gK3sNCj4gPiA+ ICsJc3RydWN0IGRldmljZV9ub2RlICpub2RlID0gcGRldi0+ZGV2Lm9mX25vZGU7DQo+ID4gPiAr CXN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0eDsNCj4gPiA+ICsJdTMyIGRldmFwY19pcnE7 DQo+ID4gPiArCWludCByZXQ7DQo+ID4gPiArDQo+ID4gPiArCWlmIChJU19FUlIobm9kZSkpDQo+ ID4gPiArCQlyZXR1cm4gLUVOT0RFVjsNCj4gPiA+ICsNCj4gPiA+ICsJY3R4ID0gZGV2bV9remFs bG9jKCZwZGV2LT5kZXYsIHNpemVvZigqY3R4KSwgR0ZQX0tFUk5FTCk7DQo+ID4gPiArCWlmICgh Y3R4KQ0KPiA+ID4gKwkJcmV0dXJuIC1FTk9NRU07DQo+ID4gPiArDQo+ID4gPiArCWN0eC0+ZGF0 YSA9IG9mX2RldmljZV9nZXRfbWF0Y2hfZGF0YSgmcGRldi0+ZGV2KTsNCj4gPiA+ICsJY3R4LT5k ZXYgPSAmcGRldi0+ZGV2Ow0KPiA+ID4gKw0KPiA+ID4gKwljdHgtPmluZnJhX2Jhc2UgPSBvZl9p b21hcChub2RlLCAwKTsNCj4gPiANCj4gPiBEb2VzIHRoaXMgbWVhbiB0aGUgZGV2aWNlIGlzIHBh cnQgb2YgdGhlIGluZnJhY2ZnIGJsb2NrPw0KPiA+IEkgd2Fzbid0IGFibGUgdG8gZmluZCBhbnkg aW5mb3JtYXRpb24gYWJvdXQgaXQuDQo+IA0KPiBJJ20gbm90IHN1cmUgd2h5IHlvdSB3b3VsZCBh c2sgaW5mcmFjZmcgYmxvY2suIGRldmFwYyBpcyBwYXJ0cyBvZiBvdXINCj4gU29DIGluZnJhLCBp dCdzIGRpZmZlcmVudCB3aXRoIGluZnJhY2ZnLg0KPiANCj4gPiANCj4gPiA+ICsJaWYgKCFjdHgt PmluZnJhX2Jhc2UpDQo+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiA+ICsNCj4gPiA+ICsJ ZGV2YXBjX2lycSA9IGlycV9vZl9wYXJzZV9hbmRfbWFwKG5vZGUsIDApOw0KPiA+ID4gKwlpZiAo IWRldmFwY19pcnEpDQo+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiA+ICsNCj4gPiA+ICsJ Y3R4LT5pbmZyYV9jbGsgPSBkZXZtX2Nsa19nZXQoJnBkZXYtPmRldiwgImRldmFwYy1pbmZyYS1j bG9jayIpOw0KPiA+ID4gKwlpZiAoSVNfRVJSKGN0eC0+aW5mcmFfY2xrKSkNCj4gPiA+ICsJCXJl dHVybiAtRUlOVkFMOw0KPiA+ID4gKw0KPiA+ID4gKwlpZiAoY2xrX3ByZXBhcmVfZW5hYmxlKGN0 eC0+aW5mcmFfY2xrKSkNCj4gPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiA+ID4gKw0KPiA+ID4g KwlyZXQgPSBkZXZtX3JlcXVlc3RfaXJxKCZwZGV2LT5kZXYsIGRldmFwY19pcnEsDQo+ID4gPiAr CQkJICAgICAgIChpcnFfaGFuZGxlcl90KWRldmFwY192aW9sYXRpb25faXJxLA0KPiA+IA0KPiA+ IE5vIGNhc3Qgc2hvdWxkIGJlIG5lZWRlZC4NCj4gDQo+IE9rYXksIEknbGwgcmVtb3ZlIGl0IG9u IG5leHQgcGF0Y2guDQo+IFRoYW5rcw0KPiANCj4gPiANCj4gPiA+ICsJCQkgICAgICAgSVJRRl9U UklHR0VSX05PTkUsICJkZXZhcGMiLCBjdHgpOw0KPiA+ID4gKwlpZiAocmV0KSB7DQo+ID4gPiAr CQljbGtfZGlzYWJsZV91bnByZXBhcmUoY3R4LT5pbmZyYV9jbGspOw0KPiA+ID4gKwkJcmV0dXJu IHJldDsNCj4gPiA+ICsJfQ0KPiA+ID4gKw0KPiA+ID4gKwlwbGF0Zm9ybV9zZXRfZHJ2ZGF0YShw ZGV2LCBjdHgpOw0KPiA+ID4gKw0KPiA+ID4gKwlzdGFydF9kZXZhcGMoY3R4KTsNCj4gPiA+ICsN Cj4gPiA+ICsJcmV0dXJuIDA7DQo+ID4gPiArfQ0KPiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQg bXRrX2RldmFwY19yZW1vdmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikNCj4gPiA+ICt7 DQo+ID4gPiArCXN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmN0eCA9IHBsYXRmb3JtX2dldF9k cnZkYXRhKHBkZXYpOw0KPiA+ID4gKw0KPiA+ID4gKwlzdG9wX2RldmFwYyhjdHgpOw0KPiA+ID4g Kw0KPiA+ID4gKwljbGtfZGlzYWJsZV91bnByZXBhcmUoY3R4LT5pbmZyYV9jbGspOw0KPiA+ID4g Kw0KPiA+ID4gKwlyZXR1cm4gMDsNCj4gPiA+ICt9DQo+ID4gPiArDQo+ID4gPiArc3RhdGljIHN0 cnVjdCBwbGF0Zm9ybV9kcml2ZXIgbXRrX2RldmFwY19kcml2ZXIgPSB7DQo+ID4gPiArCS5wcm9i ZSA9IG10a19kZXZhcGNfcHJvYmUsDQo+ID4gPiArCS5yZW1vdmUgPSBtdGtfZGV2YXBjX3JlbW92 ZSwNCj4gPiA+ICsJLmRyaXZlciA9IHsNCj4gPiA+ICsJCS5uYW1lID0gS0JVSUxEX01PRE5BTUUs DQo+ID4gDQo+ID4gLm5hbWUgPSAibXRrLWRldmFwYyIsDQo+IA0KPiBPa2F5LCBJJ2xsIGFkZCBp dCBvbiBuZXh0IHBhdGNoLg0KPiBUaGFua3MNCj4gDQo+ID4gDQo+ID4gUmVnYXJkcywNCj4gPiBN YXR0aGlhcw0KPiANCj4gDQoNCg==