From: Long Li <longli@microsoft.com>
To: Dexuan Cui <decui@microsoft.com>,
"longli@linuxonhyperv.com" <longli@linuxonhyperv.com>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Sasha Levin <sashal@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Andrew Murray <andrew.murray@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [EXTERNAL] [PATCH 1/2] PCI: hv: decouple the func definition in hv_dr_state from VSP message
Date: Tue, 3 Dec 2019 00:39:30 +0000 [thread overview]
Message-ID: <MW2PR2101MB1132A6039C540F473C9AD55BCE420@MW2PR2101MB1132.namprd21.prod.outlook.com> (raw)
In-Reply-To: <PU1P153MB016971582C7371E29065D83DBF430@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
>Subject: RE: [EXTERNAL] [PATCH 1/2] PCI: hv: decouple the func definition in
>hv_dr_state from VSP message
>
>> From: linux-hyperv-owner@vger.kernel.org
>> Sent: Friday, November 22, 2019 5:57 PM ...
>> +struct hv_pcidev_description {
>> + u16 v_id; /* vendor ID */
>> + u16 d_id; /* device ID */
>> + u8 rev;
>> + u8 prog_intf;
>> + u8 subclass;
>> + u8 base_class;
>> + u32 subsystem_id;
>> + union win_slot_encoding win_slot;
>
>Change the spact to a TAB? :-)
>
>> /**
>> - * hv_pci_devices_present() - Handles list of new children
>> + * hv_pci_start_relations_work() - Queue work to start device
>> + discovery
>> * @hbus: Root PCI bus, as understood by this driver
>> - * @relations: Packet from host listing children
>> + * @dr: The list of children returned from host
>> *
>> - * This function is invoked whenever a new list of devices for
>> - * this bus appears.
>> + * Return: 0 on success, 1 on failure
>> */
>
>Usually we return a negative value upon error, if possible.
>
>> -static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
>> - struct pci_bus_relations *relations)
>> +static int hv_pci_start_relations_work(struct hv_pcibus_device *hbus,
>> + struct hv_dr_state *dr)
>> {
>> - struct hv_dr_state *dr;
>> struct hv_dr_work *dr_wrk;
>> - unsigned long flags;
>> bool pending_dr;
>> + unsigned long flags;
>>
>> dr_wrk = kzalloc(sizeof(*dr_wrk), GFP_NOWAIT);
>> if (!dr_wrk)
>> - return;
>> -
>> - dr = kzalloc(offsetof(struct hv_dr_state, func) +
>> - (sizeof(struct pci_function_description) *
>> - (relations->device_count)), GFP_NOWAIT);
>> - if (!dr) {
>> - kfree(dr_wrk);
>> - return;
>> - }
>> + return 1;
>
>How about "return -ENOMEM;" ?
>
>> @@ -3018,7 +3055,7 @@ static void hv_pci_bus_exit(struct hv_device
>*hdev)
>> struct pci_packet teardown_packet;
>> u8 buffer[sizeof(struct pci_message)];
>> } pkt;
>> - struct pci_bus_relations relations;
>> + struct hv_dr_state *dr;
>> struct hv_pci_compl comp_pkt;
>> int ret;
>>
>> @@ -3030,8 +3067,9 @@ static void hv_pci_bus_exit(struct hv_device
>*hdev)
>> return;
>>
>> /* Delete any children which might still exist. */
>> - memset(&relations, 0, sizeof(relations));
>> - hv_pci_devices_present(hbus, &relations);
>> + dr = kzalloc(sizeof(*dr), GFP_ATOMIC);
>
>Here we are in a process context, so GFP_KERNEL is preferred.
>
>> + if (dr && hv_pci_start_relations_work(hbus, dr))
>> + kfree(dr);
>
>Thanks,
>-- Dexuan
Thanks! I will send v2 to address those comments.
Long
prev parent reply other threads:[~2019-12-03 0:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-23 1:57 [PATCH 1/2] PCI: hv: decouple the func definition in hv_dr_state from VSP message longli
2019-11-23 1:57 ` [PATCH 2/2] PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2 longli
2019-11-30 4:45 ` [EXTERNAL] " Michael Kelley
2019-12-02 21:23 ` Long Li
2019-12-02 23:59 ` Dexuan Cui
2019-12-03 0:49 ` Long Li
2019-11-30 4:30 ` [EXTERNAL] [PATCH 1/2] PCI: hv: decouple the func definition in hv_dr_state from VSP message Michael Kelley
2019-12-02 23:29 ` Dexuan Cui
2019-12-03 0:39 ` Long Li [this message]
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=MW2PR2101MB1132A6039C540F473C9AD55BCE420@MW2PR2101MB1132.namprd21.prod.outlook.com \
--to=longli@microsoft.com \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=longli@linuxonhyperv.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=sashal@kernel.org \
--cc=sthemmin@microsoft.com \
/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).