From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
To: Leo Li <leoyang.li@nxp.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Netdev <netdev@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Roy Pledge <roy.pledge@nxp.com>,
Madalin-cristian Bucur <madalin.bucur@nxp.com>,
David Miller <davem@davemloft.net>,
Shawn Guo <shawnguo@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
Bharat Bhushan <bharat.bhushan@nxp.com>
Subject: Re: [PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status
Date: Wed, 3 Oct 2018 10:50:46 +0000 [thread overview]
Message-ID: <c4ff9977-c730-be48-8046-97da663c5a23@nxp.com> (raw)
In-Reply-To: <CADRPPNTD=SNpSqz=zoLyGP1tvh_xDr5E1NDHF_P0bcSPyx9X1A@mail.gmail.com>
Hi Leo,
On 27.09.2018 23:03, Li Yang wrote:
> On Wed, Sep 26, 2018 at 8:26 AM <laurentiu.tudor@nxp.com> wrote:
>>
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Add a couple of new APIs to check the probing status of the required
>> cpu bound qman and bman portals:
>> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
>> They return the following values.
>> * 1 if qman/bman portals were all probed correctly
>> * 0 if qman/bman portals were not yet probed
>> * -1 if probing of qman/bman portals failed
>> Drivers that use qman/bman portal driver services are required to use
>> these APIs before calling any functions exported by these drivers or
>> otherwise they will crash the kernel.
>> First user will be the dpaa1 ethernet driver, coming in a subsequent
>> patch.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>> drivers/soc/fsl/qbman/bman_portal.c | 10 ++++++++++
>> drivers/soc/fsl/qbman/qman_portal.c | 10 ++++++++++
>> include/soc/fsl/bman.h | 8 ++++++++
>> include/soc/fsl/qman.h | 9 +++++++++
>> 4 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
>> index f9edd28894fd..8048d35de8a2 100644
>> --- a/drivers/soc/fsl/qbman/bman_portal.c
>> +++ b/drivers/soc/fsl/qbman/bman_portal.c
>> @@ -32,6 +32,7 @@
>>
>> static struct bman_portal *affine_bportals[NR_CPUS];
>> static struct cpumask portal_cpus;
>> +static int __bman_portals_probed;
>> /* protect bman global registers and global data shared among portals */
>> static DEFINE_SPINLOCK(bman_lock);
>>
>> @@ -85,6 +86,12 @@ static int bman_online_cpu(unsigned int cpu)
>> return 0;
>> }
>>
>> +int bman_portals_probed(void)
>> +{
>> + return __bman_portals_probed;
>> +}
>> +EXPORT_SYMBOL_GPL(bman_portals_probed);
>> +
>> static int bman_portal_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -148,6 +155,7 @@ static int bman_portal_probe(struct platform_device *pdev)
>> spin_lock(&bman_lock);
>> cpu = cpumask_next_zero(-1, &portal_cpus);
>> if (cpu >= nr_cpu_ids) {
>> + __bman_portals_probed = 1;
>
> What if the last CPU is not used for portals? Is there a hard
> requirement that all CPUs need to be used for portal?
As far as I know, in the current driver design a portal is required for
each CPU.
> What happens if the last CPU is offline?
Can this happen at probe time?
Anyway, I'm not sure that the driver is even aware of cpu hotplug but
I'll let Roy comment on this one.
>
>> /* unassigned portal, skip init */
>> spin_unlock(&bman_lock);
>> return 0;
>> @@ -173,6 +181,8 @@ static int bman_portal_probe(struct platform_device *pdev)
>> err_ioremap2:
>> memunmap(pcfg->addr_virt_ce);
>> err_ioremap1:
>> + __bman_portals_probed = 1;
>> +
>
> There are other error paths that not covered.
Right, thanks for pointing. On top of that, the assigned value here
should be -1 to signal error (instead of 1 which signals success).
---
Best Regards, Laurentiu
next prev parent reply other threads:[~2018-10-03 10:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 13:22 [PATCH v2 00/22] SMMU enablement for NXP LS1043A and LS1046A laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 01/22] soc/fsl/qman: fixup liodns only on ppc targets laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 02/22] soc/fsl/bman: map FBPR area in the iommu laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 03/22] soc/fsl/qman: map FQD and PFDR areas " laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 04/22] soc/fsl/qman-portal: map CENA area " laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 05/22] soc/fsl/qbman: add APIs to retrieve the probing status laurentiu.tudor
2018-09-27 20:37 ` Li Yang
2018-09-26 13:22 ` [PATCH v2 06/22] soc/fsl/qman_portals: defer probe after qman's probe laurentiu.tudor
2018-09-27 20:37 ` Li Yang
2018-09-26 13:22 ` [PATCH v2 07/22] soc/fsl/bman_portals: defer probe after bman's probe laurentiu.tudor
2018-09-27 20:40 ` Li Yang
2018-09-26 13:22 ` [PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status laurentiu.tudor
2018-09-27 20:03 ` Li Yang
2018-10-03 10:50 ` Laurentiu Tudor [this message]
2018-10-03 12:27 ` Robin Murphy
2018-09-26 13:22 ` [PATCH v2 09/22] fsl/fman: backup and restore ICID registers laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 10/22] fsl/fman: add API to get the device behind a fman port laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 11/22] dpaa_eth: defer probing after qbman laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 12/22] dpaa_eth: base dma mappings on the fman rx port laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 13/22] dpaa_eth: fix iova handling for contiguous frames laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 14/22] dpaa_eth: fix iova handling for sg frames laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 15/22] dpaa_eth: fix SG frame cleanup laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 16/22] arm64: dts: ls1046a: add smmu node laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 17/22] arm64: dts: ls1043a: " laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 18/22] arm64: dts: ls104xa: set mask to drop TBU ID from StreamID laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 19/22] arm64: dts: ls104x: add missing dma ranges property laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 20/22] arm64: dts: ls104x: add iommu-map to pci controllers laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 21/22] arm64: dts: ls104x: make dma-coherent global to the SoC laurentiu.tudor
2018-09-26 13:22 ` [PATCH v2 22/22] arm64: dts: ls104x: use a pseudo-bus to constrain usb dma size laurentiu.tudor
2018-09-27 13:39 ` [PATCH v2 00/22] SMMU enablement for NXP LS1043A and LS1046A Madalin-cristian Bucur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4ff9977-c730-be48-8046-97da663c5a23@nxp.com \
--to=laurentiu.tudor@nxp.com \
--cc=bharat.bhushan@nxp.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madalin.bucur@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=roy.pledge@nxp.com \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®