From: Greg KH <gregkh@linuxfoundation.org>
To: richard.yu@hpe.com
Cc: verdun@hpe.com, nick.hawkins@hpe.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] usb: gadget: udc: gxp-udc: add HPE GXP USB HUB support
Date: Mon, 2 Oct 2023 14:21:15 +0200 [thread overview]
Message-ID: <2023100212-hyperlink-prolonged-3e18@gregkh> (raw)
In-Reply-To: <20230907210601.25284-3-richard.yu@hpe.com>
On Thu, Sep 07, 2023 at 04:06:00PM -0500, richard.yu@hpe.com wrote:
> +struct gxp_udc_drvdata {
> + void __iomem *base;
> + struct platform_device *pdev;
> + struct regmap *udcg_map;
> + struct gxp_udc_ep ep[GXP_UDC_MAX_NUM_EP];
> +
> + int irq;
> +
> + /* sysfs enclosure for the gadget gunk */
> + struct device *port_dev;
A "raw" struct device? That's not ok. It's also going to break things,
how was this tested? What does it look like in sysfs with this device?
> + /*
> + * The UDC core really needs us to have separate and uniquely
> + * named "parent" devices for each port so we create a sub device
> + * here for that purpose
> + */
> + drvdata->port_dev = kzalloc(sizeof(*drvdata->port_dev), GFP_KERNEL);
> + if (!drvdata->port_dev) {
> + rc = -ENOMEM;
> + goto fail_alloc;
> + }
> + device_initialize(drvdata->port_dev);
> + drvdata->port_dev->release = gxp_udc_dev_release;
> + drvdata->port_dev->parent = parent;
> + dev_set_name(drvdata->port_dev, "%s:p%d", dev_name(parent), idx + 1);
> +
> + /* DMA setting */
> + drvdata->port_dev->dma_mask = parent->dma_mask;
> + drvdata->port_dev->coherent_dma_mask = parent->coherent_dma_mask;
> + drvdata->port_dev->bus_dma_limit = parent->bus_dma_limit;
> + drvdata->port_dev->dma_range_map = parent->dma_range_map;
> + drvdata->port_dev->dma_parms = parent->dma_parms;
> + drvdata->port_dev->dma_pools = parent->dma_pools;
> +
> + rc = device_add(drvdata->port_dev);
So you createad a "raw" device that does not belong to any bus or type
and add it to sysfs? Why? Shouldn't it be a "virtual" device if you
really want/need one?
> + if (rc)
> + goto fail_add;
> +
> + /* Populate gadget */
> + gxp_udc_init(drvdata);
> +
> + rc = usb_add_gadget_udc(drvdata->port_dev, &drvdata->gadget);
> + if (rc != 0) {
> + dev_err(drvdata->port_dev, "add gadget failed\n");
> + goto fail_udc;
> + }
> + rc = devm_request_irq(drvdata->port_dev,
> + drvdata->irq,
> + gxp_udc_irq,
> + IRQF_SHARED,
> + gxp_udc_name[drvdata->vdevnum],
> + drvdata);
devm_request_irq() is _very_ tricky, are you _SURE_ you got it right
here? Why do you need to use it?
> + if (rc < 0) {
> + dev_err(drvdata->port_dev, "irq request failed\n");
> + goto fail_udc;
> + }
> +
> + return 0;
> +
> + /* ran code to simulate these three error exit, no double free */
What does this comment mean?
> +fail_udc:
> + device_del(drvdata->port_dev);
> +fail_add:
> + put_device(drvdata->port_dev);
> +fail_alloc:
> + devm_kfree(parent, drvdata);
> +
> + return rc;
> +}
Where is the device removed from the system when done?
thanks,
greg k-h
next prev parent reply other threads:[~2023-10-02 12:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 21:05 [PATCH v2 0/3] Add USB driver for HPE GXP Architecture richard.yu
2023-09-07 21:05 ` [PATCH v2 1/3] dt-bindings: usb: Add HPE GXP HUB Controller richard.yu
2023-09-11 14:57 ` Rob Herring
2023-09-07 21:06 ` [PATCH v2 2/3] usb: gadget: udc: gxp-udc: add HPE GXP USB HUB support richard.yu
2023-10-02 12:21 ` Greg KH [this message]
2023-10-25 22:14 ` Yu, Richard
2023-09-07 21:06 ` [PATCH v2 3/3] MAINTAINERS: add USB HUB support for GXP richard.yu
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=2023100212-hyperlink-prolonged-3e18@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nick.hawkins@hpe.com \
--cc=richard.yu@hpe.com \
--cc=robh+dt@kernel.org \
--cc=verdun@hpe.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).