From: Andrew Lunn <andrew@lunn.ch>
To: admiyo@os.amperecomputing.com
Cc: Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mctp pcc: Implement MCTP over PCC Transport
Date: Mon, 13 May 2024 22:08:16 +0200 [thread overview]
Message-ID: <6d3aed83-ee56-4c3c-bb23-0f7d1f471ea4@lunn.ch> (raw)
In-Reply-To: <20240513173546.679061-2-admiyo@os.amperecomputing.com>
> +struct mctp_pcc_hdr {
> + u32 signature;
> + u32 flags;
There looks to be an extra space here, or a tab vs space issue.
> + u32 length;
> + char mctp_signature[4];
> +};
> +
> +struct mctp_pcc_packet {
> + struct mctp_pcc_hdr pcc_header;
> + union {
> + struct mctp_hdr mctp_header;
and more here. I would expect checkpatch to point these out.
> +struct mctp_pcc_hw_addr {
> + int inbox_index;
> + int outbox_index;
> +};
> + physical_link_addr.inbox_index =
> + htonl(mctp_pcc_dev->hw_addr.inbox_index);
These are {in|out}box_index are u32s right? Otherwise you would not be
using htonl() on them. Maybe specify the type correctly.
> + physical_link_addr.outbox_index =
> + htonl(mctp_pcc_dev->hw_addr.outbox_index);
You should also mark the physical_link_addr members as being big
endian so sparse can check you are not missing any byte swaps.
> + dev_addr_set(ndev, (const u8 *)&physical_link_addr);
> + rc = register_netdev(ndev);
> + if (rc)
> + goto cleanup_in_channel;
> + list_add_tail(&mctp_pcc_dev->head, &mctp_pcc_ndevs);
> + return 0;
> +cleanup_in_channel:
It would be normal to add a blink line after the return, just to make
it easier to see where the error cleanup code starts.
> + mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->in_chan);
> +cleanup_out_channel:
> + mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->out_chan);
> +free_netdev:
> + unregister_netdev(ndev);
Can you get here with the ndev actually registered?
> +static acpi_status lookup_pcct_indices(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_resource_address32 *addr;
> + struct lookup_context *luc = context;
> +
> + switch (ares->type) {
> + case 0x0c:
> + case 0x0a:
Please replace these magic numbers of #defines.
> +static int mctp_pcc_driver_add(struct acpi_device *adev)
> +{
> + int inbox_index;
> + int outbox_index;
> + acpi_handle dev_handle;
> + acpi_status status;
> + struct lookup_context context = {0, 0, 0};
> +
> + dev_info(&adev->dev, "Adding mctp_pcc device for HID %s\n", acpi_device_hid(adev));
It would be better to not spam the logs when a driver probes, unless
there is an actual error.
> + dev_handle = acpi_device_handle(adev);
> + status = acpi_walk_resources(dev_handle, "_CRS", lookup_pcct_indices, &context);
> + if (ACPI_SUCCESS(status)) {
> + inbox_index = context.inbox_index;
> + outbox_index = context.outbox_index;
> + return create_mctp_pcc_netdev(adev, &adev->dev, inbox_index, outbox_index);
> + }
> + dev_err(&adev->dev, "FAILURE to lookup PCC indexes from CRS");
> + return -EINVAL;
> +};
> +
> +/* pass in adev=NULL to remove all devices
> + */
> +static void mctp_pcc_driver_remove(struct acpi_device *adev)
> +{
> + struct mctp_pcc_ndev *mctp_pcc_dev = NULL;
> + struct list_head *ptr;
> + struct list_head *tmp;
> +
> + list_for_each_safe(ptr, tmp, &mctp_pcc_ndevs) {
> + mctp_pcc_dev = list_entry(ptr, struct mctp_pcc_ndev, head);
> + if (!adev || mctp_pcc_dev->acpi_device == adev) {
> + struct net_device *ndev;
> +
> + mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->out_chan);
> + mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->in_chan);
> + ndev = mctp_pcc_dev->mdev.dev;
> + if (ndev)
> + mctp_unregister_netdev(ndev);
> + list_del(ptr);
> + if (adev)
> + break;
> + }
> + }
> +};
> +
> +static const struct acpi_device_id mctp_pcc_device_ids[] = {
> + { "DMT0001", 0},
> + { "", 0},
> +};
> +
> +static struct acpi_driver mctp_pcc_driver = {
> + .name = "mctp_pcc",
> + .class = "Unknown",
> + .ids = mctp_pcc_device_ids,
> + .ops = {
> + .add = mctp_pcc_driver_add,
> + .remove = mctp_pcc_driver_remove,
> + .notify = NULL,
> + },
> + .owner = THIS_MODULE,
> +
> +};
> +
> +static int __init mctp_pcc_mod_init(void)
> +{
> + int rc;
> +
> + pr_info("initializing MCTP over PCC\n");
More useless log spamming... pr_dbg(), or remove altogether.
Andrew
next prev parent reply other threads:[~2024-05-13 20:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 17:35 [PATCH 0/3] MCTP over PCC admiyo
2024-05-13 17:35 ` [PATCH 1/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-05-13 18:31 ` Simon Horman
2024-05-13 20:08 ` Andrew Lunn [this message]
2024-05-13 20:17 ` Andrew Lunn
2024-05-13 20:22 ` Andrew Lunn
2024-05-14 5:24 ` Jeremy Kerr
2024-05-14 10:12 ` kernel test robot
2024-05-14 11:36 ` kernel test robot
2024-05-14 16:29 ` kernel test robot
2024-05-29 13:10 ` kernel test robot
2024-05-29 14:56 ` kernel test robot
2024-05-13 17:35 ` [PATCH 2/3] mctp pcc: Allow PCC Data Type in MCTP resource admiyo
2024-05-13 20:23 ` Andrew Lunn
2024-05-13 17:35 ` [PATCH 3/3] mctp pcc: RFC Check before sending MCTP PCC response ACK admiyo
2024-05-13 20:26 ` Andrew Lunn
2024-05-28 19:18 ` [PATCH v2 0/3] MCTP over PCC admiyo
2024-05-28 19:18 ` [PATCH v2 1/3] mctp pcc: Check before sending MCTP PCC response ACK admiyo
2024-05-29 3:26 ` Ratheesh Kannoth
2024-06-03 9:07 ` Sudeep Holla
2024-05-28 19:18 ` [PATCH v2 2/3] mctp pcc: Allow PCC Data Type in MCTP resource admiyo
2024-05-29 3:25 ` Ratheesh Kannoth
2024-05-30 16:24 ` Adam Young
2024-05-28 19:18 ` [PATCH v2 3/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-05-29 2:45 ` Jakub Kicinski
2024-05-29 3:30 ` Jeremy Kerr
2024-05-30 23:51 ` Adam Young
2024-05-29 3:02 ` Jeremy Kerr
2024-06-03 17:53 ` Adam Young
2024-06-04 1:15 ` Jeremy Kerr
2024-05-29 13:21 ` kernel test robot
2024-05-29 14:03 ` kernel test robot
2024-06-07 7:06 ` [PATCH v2 0/3] MCTP over PCC John Chung
2024-06-19 20:05 ` admiyo
2024-06-19 20:05 ` [PATCH v2 1/3] mctp pcc: Check before sending MCTP PCC response ACK admiyo
2024-06-19 20:05 ` [PATCH v2 2/3] mctp pcc: Allow PCC Data Type in MCTP resource admiyo
2024-06-19 20:05 ` [PATCH v2 3/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-06-19 23:26 ` Jakub Kicinski
2024-06-20 3:24 ` Adam Young
2024-06-20 13:26 ` Jakub Kicinski
2024-06-20 11:05 ` kernel test robot
2024-06-20 15:13 ` kernel test robot
2024-06-20 3:10 ` [PATCH v2 0/3] MCTP over PCC Adam Young
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=6d3aed83-ee56-4c3c-bb23-0f7d1f471ea4@lunn.ch \
--to=andrew@lunn.ch \
--cc=admiyo@os.amperecomputing.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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
all inboxes | Powered by JetHome®