From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "julien@xen.org" <julien@xen.org>,
"sstabellini@kernel.org" <sstabellini@kernel.org>,
Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Artem Mygaiev <Artem_Mygaiev@epam.com>,
"roger.pau@citrix.com" <roger.pau@citrix.com>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Rahul Singh <rahul.singh@arm.com>,
Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 05/11] xen/arm: Mark device as PCI while creating one
Date: Tue, 28 Sep 2021 08:09:15 +0000 [thread overview]
Message-ID: <2e8f4316-002f-17d8-b9ec-9886c6bc28fa@epam.com> (raw)
In-Reply-To: <6eefff6f-97ed-e7f5-37f2-96065bd1f27e@suse.com>
On 27.09.21 13:26, Jan Beulich wrote:
> On 27.09.2021 12:04, Oleksandr Andrushchenko wrote:
>> On 27.09.21 13:00, Jan Beulich wrote:
>>> On 27.09.2021 11:35, Oleksandr Andrushchenko wrote:
>>>> On 27.09.21 12:19, Jan Beulich wrote:
>>>>> On 27.09.2021 10:45, Oleksandr Andrushchenko wrote:
>>>>>> On 27.09.21 10:45, Jan Beulich wrote:
>>>>>>> On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
>>>>>>>> --- a/xen/drivers/passthrough/pci.c
>>>>>>>> +++ b/xen/drivers/passthrough/pci.c
>>>>>>>> @@ -328,6 +328,9 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>>>>>>>> *((u8*) &pdev->bus) = bus;
>>>>>>>> *((u8*) &pdev->devfn) = devfn;
>>>>>>>> pdev->domain = NULL;
>>>>>>>> +#ifdef CONFIG_ARM
>>>>>>>> + pci_to_dev(pdev)->type = DEV_PCI;
>>>>>>>> +#endif
>>>>>>> I have to admit that I'm not happy about new CONFIG_<arch> conditionals
>>>>>>> here. I'd prefer to see this done by a new arch helper, unless there are
>>>>>>> obstacles I'm overlooking.
>>>>>> Do you mean something like arch_pci_alloc_pdev(dev)?
>>>>> I'd recommend against "alloc" in its name; "new" instead maybe?
>>>> I am fine with arch_pci_new_pdev, but arch prefix points to the fact that
>>>> this is just an architecture specific part of the pdev allocation rather than
>>>> actual pdev allocation itself, so with this respect arch_pci_alloc_pdev seems
>>>> more natural to me.
>>> The bulk of the function is about populating the just allocated struct.
>>> There's no arch-specific part of the allocation (so far, leaving aside
>>> MSI-X), you only want and arch-specific part of the initialization. I
>>> would agree with "alloc" in the name if further allocation was to
>>> happen there.
>> Hm, then arch_pci_init_pdev sounds more reasonable
> Fine with me.
Do we want this to be void or returning an error code? If error code is needed,
then we would also need a roll-back function, e.g. arch_pci_free_pdev or
arch_pci_release_pdev or arch_pci_fini_pdev or something, so it can be used in
case of error or in free_pdev function.
If so, then what's your preference on the name of that function?
>
> Jan
>
>
Thank you,
Oleksandr
next prev parent reply other threads:[~2021-09-28 8:14 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-23 12:54 [PATCH v2 00/11] PCI devices passthrough on Arm, part 2 Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 01/11] xen/arm: Fix dev_is_dt macro definition Oleksandr Andrushchenko
2021-09-24 23:39 ` Stefano Stabellini
2021-09-28 7:31 ` Michal Orzel
2021-09-23 12:54 ` [PATCH v2 02/11] xen/arm: Add new device type for PCI Oleksandr Andrushchenko
2021-09-24 23:45 ` Stefano Stabellini
2021-09-27 7:41 ` Jan Beulich
2021-09-27 8:18 ` Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 03/11] xen/arm: Introduce pci_find_host_bridge_node helper Oleksandr Andrushchenko
2021-09-24 23:48 ` Stefano Stabellini
2021-09-23 12:54 ` [PATCH v2 04/11] xen/device-tree: Make dt_find_node_by_phandle global Oleksandr Andrushchenko
2021-09-24 23:51 ` Stefano Stabellini
2021-09-23 12:54 ` [PATCH v2 05/11] xen/arm: Mark device as PCI while creating one Oleksandr Andrushchenko
2021-09-24 23:54 ` Stefano Stabellini
2021-09-27 7:13 ` Oleksandr Andrushchenko
2021-09-27 7:45 ` Jan Beulich
2021-09-27 8:45 ` Oleksandr Andrushchenko
2021-09-27 9:19 ` Jan Beulich
2021-09-27 9:35 ` Oleksandr Andrushchenko
2021-09-27 10:00 ` Jan Beulich
2021-09-27 10:04 ` Oleksandr Andrushchenko
2021-09-27 10:26 ` Jan Beulich
2021-09-28 8:09 ` Oleksandr Andrushchenko [this message]
2021-09-28 8:26 ` Jan Beulich
2021-09-28 8:29 ` Oleksandr Andrushchenko
2021-09-28 8:39 ` Jan Beulich
2021-09-28 8:54 ` Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 06/11] xen/domain: Call pci_release_devices() when releasing domain resources Oleksandr Andrushchenko
2021-09-24 23:57 ` Stefano Stabellini
2021-09-23 12:54 ` [PATCH v2 07/11] libxl: Allow removing PCI devices for all types of domains Oleksandr Andrushchenko
2021-09-25 0:00 ` Stefano Stabellini
2021-09-27 7:17 ` Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 08/11] libxl: Only map legacy PCI IRQs if they are supported Oleksandr Andrushchenko
2021-09-25 0:06 ` Stefano Stabellini
2021-09-27 13:02 ` Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain Oleksandr Andrushchenko
2021-09-25 0:18 ` Stefano Stabellini
2021-09-27 8:47 ` Oleksandr Andrushchenko
2021-09-23 12:54 ` [PATCH v2 10/11] xen/arm: Do not map PCI ECAM and MMIO space to Domain-0's p2m Oleksandr Andrushchenko
2021-09-25 0:44 ` Stefano Stabellini
2021-09-27 12:44 ` Oleksandr Andrushchenko
2021-09-28 4:00 ` Stefano Stabellini
2021-09-28 4:51 ` Oleksandr Andrushchenko
2021-09-28 14:39 ` Oleksandr Andrushchenko
2021-09-28 16:11 ` Stefano Stabellini
2021-09-23 12:54 ` [PATCH v2 11/11] xen/arm: Process pending vPCI map/unmap operations Oleksandr Andrushchenko
2021-09-25 1:20 ` Stefano Stabellini
2021-09-27 8:06 ` Jan Beulich
2021-09-27 8:39 ` Oleksandr Andrushchenko
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=2e8f4316-002f-17d8-b9ec-9886c6bc28fa@epam.com \
--to=oleksandr_andrushchenko@epam.com \
--cc=Artem_Mygaiev@epam.com \
--cc=Oleksandr_Tyshchenko@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=rahul.singh@arm.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).