Message ID | 20230816141008.535450-2-suzuki.poulose@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b82d:0:b0:3f2:4152:657d with SMTP id z13csp251418vqi; Wed, 16 Aug 2023 12:58:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGs/ww1UnL623GnGjSOxfFhYkRadmqJE7S7Yl5Vuf7x/2doqzKr8Wt17p18tSNz7I8ZP8Eh X-Received: by 2002:a05:6a00:810:b0:687:4de3:d6f7 with SMTP id m16-20020a056a00081000b006874de3d6f7mr3910070pfk.20.1692215928528; Wed, 16 Aug 2023 12:58:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692215928; cv=none; d=google.com; s=arc-20160816; b=ujfIZz6nGoGX2ejKqE4UBOMYiFYA5dYY+sOIU5TzIqDRC41d74jf3maLD0SCFiNU5K p2tBhM8BQUDzCvnPSj0fYihOdmYPZgA83ox72TkKz0q50Q4IX9x/z+q7Oz6W61CFvoDg NcaAnzLSY7cXg6BRdEsvqaleE2Nmu8yqe+chnzZkcZ3lqHNGq6KFPm/4Yw83xn3GshyZ MpxDG4Be63+l5kOdTlvAohbDT1L3/u05xrywaIYCKTwsrXMKXnEBe8Mdx/pqHpVE24IF uxjwS6ixvwX5NlSEbtvWCVDpk5UL2jYJn+IP6h5JX5LwWRU53ibGNGOStGRpq7+YEnVQ V8cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=VBDHQ0XFZoCSRy7Lgdiy2fGkD6OUSpMY2PzEAPtL+BY=; fh=eT3oZfkiC2Ug0ZOw+bbHPGDmilib+Q+m99wdfHpgLWQ=; b=si3PFaIX7G2aVT9D1hDOsw6nrtpLx5HGdAmXoMMOGHl9DDGZK3AdyRR0cmWcJm0op2 s4yT98RUsCQrL6UICjut9Czl9ZXDmWj/C6JFxcmddMlnVOtJDpYdSF8x56PoRnTskDYN z+KplDvvqSA4QBMV/O+ir/vwwixKQo7bl7nGGr3MB2780HSSaa3DEkbHKiZBQ+PkJr4z veTMnqA/SLIR+a2Bz3XWtoV0xNhbLG/2JEroYUa5LN593jorq4eR0mm3T8XgQXOHxAW4 t8elzUXkkpFxWnL3B+tuARmb87w3XuedJI6mfulQdD/9EMC7iVJWMokWrc1G5cTjjxa8 q5zg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b23-20020a630c17000000b005648d20203dsi11802738pgl.233.2023.08.16.12.58.34; Wed, 16 Aug 2023 12:58:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245564AbjHPOK2 (ORCPT <rfc822;somadevkernel@gmail.com> + 99 others); Wed, 16 Aug 2023 10:10:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343573AbjHPOK0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Aug 2023 10:10:26 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AAAEF26B5 for <linux-kernel@vger.kernel.org>; Wed, 16 Aug 2023 07:10:24 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2F2E1063; Wed, 16 Aug 2023 07:11:05 -0700 (PDT) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 999E93F762; Wed, 16 Aug 2023 07:10:22 -0700 (PDT) From: Suzuki K Poulose <suzuki.poulose@arm.com> To: hejunhao3@huawei.com Cc: coresight@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, jonathan.cameron@huawei.com, leo.yan@linaro.org, mike.leach@linaro.org, james.clark@arm.com, linuxarm@huawei.com, yangyicong@huawei.com, prime.zeng@hisilicon.com, Suzuki K Poulose <suzuki.poulose@arm.com>, Anshuman Khandual <anshuman.khandual@arm.com> Subject: [PATCH 2/2] coresight: trbe: Allocate platform data per device Date: Wed, 16 Aug 2023 15:10:08 +0100 Message-Id: <20230816141008.535450-2-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230816141008.535450-1-suzuki.poulose@arm.com> References: <20230814093813.19152-1-hejunhao3@huawei.com> <20230816141008.535450-1-suzuki.poulose@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774417009745565985 X-GMAIL-MSGID: 1774417009745565985 |
Series |
[v2,1/2] coresight: trbe: Fix TRBE potential sleep in atomic context
|
|
Commit Message
Suzuki K Poulose
Aug. 16, 2023, 2:10 p.m. UTC
Coresight TRBE driver shares a single platform data (which is empty btw).
However, with the commit 4e8fe7e5c3a5
("coresight: Store pointers to connections rather than an array of them")
the coresight core would free up the pdata, resulting in multiple attempts
to free the same pdata for TRBE instances. Fix this by allocating a pdata per
coresight_device.
Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
Link: https://lore.kernel.org/r/20230814093813.19152-3-hejunhao3@huawei.com
Reported-by: Junhao He <hejunhao3@huawei.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight-trbe.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
Comments
Hi Suzuki, Seems like this patch is going to conflict with the below proposed change https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ Please let me know how should we resolve this conflict. On 8/16/23 19:40, Suzuki K Poulose wrote: > Coresight TRBE driver shares a single platform data (which is empty btw). > However, with the commit 4e8fe7e5c3a5 > ("coresight: Store pointers to connections rather than an array of them") > the coresight core would free up the pdata, resulting in multiple attempts > to free the same pdata for TRBE instances. Fix this by allocating a pdata per > coresight_device. > > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") The above mentioned commit i.e 4e8fe7e5c3a5 seems to be a more recent one which has triggered this problem. But would the problem be still there without that ? Else 'Fixes:' tag would need changing. > Link: https://lore.kernel.org/r/20230814093813.19152-3-hejunhao3@huawei.com > Reported-by: Junhao He <hejunhao3@huawei.com> > Cc: Anshuman Khandual <anshuman.khandual@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 025f70adee47..d3d34a833f01 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1255,10 +1255,13 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > if (!desc.name) > goto cpu_clear; > > + desc.pdata = coresight_get_platform_data(dev); > + if (IS_ERR(desc.pdata)) > + goto cpu_clear; > + > desc.type = CORESIGHT_DEV_TYPE_SINK; > desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM; > desc.ops = &arm_trbe_cs_ops; > - desc.pdata = dev_get_platdata(dev); > desc.groups = arm_trbe_groups; > desc.dev = dev; > trbe_csdev = coresight_register(&desc); > @@ -1482,7 +1485,6 @@ static void arm_trbe_remove_irq(struct trbe_drvdata *drvdata) > > static int arm_trbe_device_probe(struct platform_device *pdev) > { > - struct coresight_platform_data *pdata; > struct trbe_drvdata *drvdata; > struct device *dev = &pdev->dev; > int ret; > @@ -1497,12 +1499,7 @@ static int arm_trbe_device_probe(struct platform_device *pdev) > if (!drvdata) > return -ENOMEM; > > - pdata = coresight_get_platform_data(dev); > - if (IS_ERR(pdata)) > - return PTR_ERR(pdata); > - > dev_set_drvdata(dev, drvdata); > - dev->platform_data = pdata; > drvdata->pdev = pdev; > ret = arm_trbe_probe_irq(pdev, drvdata); > if (ret)
On 2023/8/16 22:10, Suzuki K Poulose wrote: > Coresight TRBE driver shares a single platform data (which is empty btw). > However, with the commit 4e8fe7e5c3a5 > ("coresight: Store pointers to connections rather than an array of them") > the coresight core would free up the pdata, resulting in multiple attempts > to free the same pdata for TRBE instances. Fix this by allocating a pdata per > coresight_device. > > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") > Link: https://lore.kernel.org/r/20230814093813.19152-3-hejunhao3@huawei.com > Reported-by: Junhao He <hejunhao3@huawei.com> > Cc: Anshuman Khandual <anshuman.khandual@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Test-by: Junhao He <hejunhao3@huawei.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 025f70adee47..d3d34a833f01 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1255,10 +1255,13 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > if (!desc.name) > goto cpu_clear; > > + desc.pdata = coresight_get_platform_data(dev); > + if (IS_ERR(desc.pdata)) > + goto cpu_clear; > + > desc.type = CORESIGHT_DEV_TYPE_SINK; > desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM; > desc.ops = &arm_trbe_cs_ops; > - desc.pdata = dev_get_platdata(dev); > desc.groups = arm_trbe_groups; > desc.dev = dev; > trbe_csdev = coresight_register(&desc); > @@ -1482,7 +1485,6 @@ static void arm_trbe_remove_irq(struct trbe_drvdata *drvdata) > > static int arm_trbe_device_probe(struct platform_device *pdev) > { > - struct coresight_platform_data *pdata; > struct trbe_drvdata *drvdata; > struct device *dev = &pdev->dev; > int ret; > @@ -1497,12 +1499,7 @@ static int arm_trbe_device_probe(struct platform_device *pdev) > if (!drvdata) > return -ENOMEM; > > - pdata = coresight_get_platform_data(dev); > - if (IS_ERR(pdata)) > - return PTR_ERR(pdata); > - > dev_set_drvdata(dev, drvdata); > - dev->platform_data = pdata; > drvdata->pdev = pdev; > ret = arm_trbe_probe_irq(pdev, drvdata); > if (ret)
On 17/08/2023 07:37, Anshuman Khandual wrote: > Hi Suzuki, > > Seems like this patch is going to conflict with the below proposed change > > https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ > > Please let me know how should we resolve this conflict. We could merge them both, with the fixes: one first, just to acknowledge that there was a problem. But I suppose your one will have to be rebased on top. > > On 8/16/23 19:40, Suzuki K Poulose wrote: >> Coresight TRBE driver shares a single platform data (which is empty btw). >> However, with the commit 4e8fe7e5c3a5 >> ("coresight: Store pointers to connections rather than an array of them") >> the coresight core would free up the pdata, resulting in multiple attempts >> to free the same pdata for TRBE instances. Fix this by allocating a pdata per >> coresight_device. >> >> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") > > The above mentioned commit i.e 4e8fe7e5c3a5 seems to be a more recent one which > has triggered this problem. But would the problem be still there without that ? > Else 'Fixes:' tag would need changing. > Yes I think the fixes tag should point to 4e8fe7e5c3a5. >> Link: https://lore.kernel.org/r/20230814093813.19152-3-hejunhao3@huawei.com >> Reported-by: Junhao He <hejunhao3@huawei.com> >> Cc: Anshuman Khandual <anshuman.khandual@arm.com> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> >> --- >> drivers/hwtracing/coresight/coresight-trbe.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >> index 025f70adee47..d3d34a833f01 100644 >> --- a/drivers/hwtracing/coresight/coresight-trbe.c >> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >> @@ -1255,10 +1255,13 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp >> if (!desc.name) >> goto cpu_clear; >> >> + desc.pdata = coresight_get_platform_data(dev); >> + if (IS_ERR(desc.pdata)) >> + goto cpu_clear; >> + >> desc.type = CORESIGHT_DEV_TYPE_SINK; >> desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM; >> desc.ops = &arm_trbe_cs_ops; >> - desc.pdata = dev_get_platdata(dev); >> desc.groups = arm_trbe_groups; >> desc.dev = dev; >> trbe_csdev = coresight_register(&desc); >> @@ -1482,7 +1485,6 @@ static void arm_trbe_remove_irq(struct trbe_drvdata *drvdata) >> >> static int arm_trbe_device_probe(struct platform_device *pdev) >> { >> - struct coresight_platform_data *pdata; >> struct trbe_drvdata *drvdata; >> struct device *dev = &pdev->dev; >> int ret; >> @@ -1497,12 +1499,7 @@ static int arm_trbe_device_probe(struct platform_device *pdev) >> if (!drvdata) >> return -ENOMEM; >> >> - pdata = coresight_get_platform_data(dev); >> - if (IS_ERR(pdata)) >> - return PTR_ERR(pdata); >> - >> dev_set_drvdata(dev, drvdata); >> - dev->platform_data = pdata; >> drvdata->pdev = pdev; >> ret = arm_trbe_probe_irq(pdev, drvdata); >> if (ret)
On 17/08/2023 10:24, James Clark wrote: > > > On 17/08/2023 07:37, Anshuman Khandual wrote: >> Hi Suzuki, >> >> Seems like this patch is going to conflict with the below proposed change >> >> https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ >> >> Please let me know how should we resolve this conflict. > > We could merge them both, with the fixes: one first, just to acknowledge > that there was a problem. But I suppose your one will have to be rebased > on top. > >> >> On 8/16/23 19:40, Suzuki K Poulose wrote: >>> Coresight TRBE driver shares a single platform data (which is empty btw). >>> However, with the commit 4e8fe7e5c3a5 >>> ("coresight: Store pointers to connections rather than an array of them") >>> the coresight core would free up the pdata, resulting in multiple attempts >>> to free the same pdata for TRBE instances. Fix this by allocating a pdata per >>> coresight_device. >>> >>> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") >> >> The above mentioned commit i.e 4e8fe7e5c3a5 seems to be a more recent one which >> has triggered this problem. But would the problem be still there without that ? >> Else 'Fixes:' tag would need changing. >> > > Yes I think the fixes tag should point to 4e8fe7e5c3a5. Agreed, I will change the fixes tag and push this. Suzuki
On 17/08/2023 07:37, Anshuman Khandual wrote: > Hi Suzuki, > > Seems like this patch is going to conflict with the below proposed change > > https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ > > Please let me know how should we resolve this conflict. Please rebase your change on top of this one. Suzuki
On 8/17/23 15:31, Suzuki K Poulose wrote: > On 17/08/2023 10:24, James Clark wrote: >> >> >> On 17/08/2023 07:37, Anshuman Khandual wrote: >>> Hi Suzuki, >>> >>> Seems like this patch is going to conflict with the below proposed change >>> >>> https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ >>> >>> Please let me know how should we resolve this conflict. >> >> We could merge them both, with the fixes: one first, just to acknowledge >> that there was a problem. But I suppose your one will have to be rebased >> on top. >> >>> >>> On 8/16/23 19:40, Suzuki K Poulose wrote: >>>> Coresight TRBE driver shares a single platform data (which is empty btw). >>>> However, with the commit 4e8fe7e5c3a5 >>>> ("coresight: Store pointers to connections rather than an array of them") >>>> the coresight core would free up the pdata, resulting in multiple attempts >>>> to free the same pdata for TRBE instances. Fix this by allocating a pdata per >>>> coresight_device. >>>> >>>> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") >>> >>> The above mentioned commit i.e 4e8fe7e5c3a5 seems to be a more recent one which >>> has triggered this problem. But would the problem be still there without that ? >>> Else 'Fixes:' tag would need changing. >>> >> >> Yes I think the fixes tag should point to 4e8fe7e5c3a5. > > Agreed, I will change the fixes tag and push this. In the first patch, the last hunk might not be required to fix the IPI problem and in fact might be bit problematic as well. Besides, could you please hold off pushing this change into coresight tree for some time ?
On 17/08/2023 11:16, Anshuman Khandual wrote: > > > On 8/17/23 15:31, Suzuki K Poulose wrote: >> On 17/08/2023 10:24, James Clark wrote: >>> >>> >>> On 17/08/2023 07:37, Anshuman Khandual wrote: >>>> Hi Suzuki, >>>> >>>> Seems like this patch is going to conflict with the below proposed change >>>> >>>> https://lore.kernel.org/all/20230817055405.249630-4-anshuman.khandual@arm.com/ >>>> >>>> Please let me know how should we resolve this conflict. >>> >>> We could merge them both, with the fixes: one first, just to acknowledge >>> that there was a problem. But I suppose your one will have to be rebased >>> on top. >>> >>>> >>>> On 8/16/23 19:40, Suzuki K Poulose wrote: >>>>> Coresight TRBE driver shares a single platform data (which is empty btw). >>>>> However, with the commit 4e8fe7e5c3a5 >>>>> ("coresight: Store pointers to connections rather than an array of them") >>>>> the coresight core would free up the pdata, resulting in multiple attempts >>>>> to free the same pdata for TRBE instances. Fix this by allocating a pdata per >>>>> coresight_device. >>>>> >>>>> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") >>>> >>>> The above mentioned commit i.e 4e8fe7e5c3a5 seems to be a more recent one which >>>> has triggered this problem. But would the problem be still there without that ? >>>> Else 'Fixes:' tag would need changing. >>>> >>> >>> Yes I think the fixes tag should point to 4e8fe7e5c3a5. >> >> Agreed, I will change the fixes tag and push this. > > In the first patch, the last hunk might not be required to fix the > IPI problem and in fact might be bit problematic as well. Besides, Please could you comment your concerns on the patch ? Suzuki > could you please hold off pushing this change into coresight tree > for some time ?
diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c index 025f70adee47..d3d34a833f01 100644 --- a/drivers/hwtracing/coresight/coresight-trbe.c +++ b/drivers/hwtracing/coresight/coresight-trbe.c @@ -1255,10 +1255,13 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp if (!desc.name) goto cpu_clear; + desc.pdata = coresight_get_platform_data(dev); + if (IS_ERR(desc.pdata)) + goto cpu_clear; + desc.type = CORESIGHT_DEV_TYPE_SINK; desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM; desc.ops = &arm_trbe_cs_ops; - desc.pdata = dev_get_platdata(dev); desc.groups = arm_trbe_groups; desc.dev = dev; trbe_csdev = coresight_register(&desc); @@ -1482,7 +1485,6 @@ static void arm_trbe_remove_irq(struct trbe_drvdata *drvdata) static int arm_trbe_device_probe(struct platform_device *pdev) { - struct coresight_platform_data *pdata; struct trbe_drvdata *drvdata; struct device *dev = &pdev->dev; int ret; @@ -1497,12 +1499,7 @@ static int arm_trbe_device_probe(struct platform_device *pdev) if (!drvdata) return -ENOMEM; - pdata = coresight_get_platform_data(dev); - if (IS_ERR(pdata)) - return PTR_ERR(pdata); - dev_set_drvdata(dev, drvdata); - dev->platform_data = pdata; drvdata->pdev = pdev; ret = arm_trbe_probe_irq(pdev, drvdata); if (ret)