From: Peter Chen <peter.chen@nxp.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Peter Chen <peter.chen@kernel.org>,
Pawel Laszczak <pawell@cadence.com>,
Roger Quadros <rogerq@ti.com>,
Frank Rowand <frowand.list@gmail.com>,
Linux USB List <linux-usb@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
Aswath Govindraju <a-govindraju@ti.com>,
Frank Li <frank.li@nxp.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/2] of: platform: introduce platform data length for auxdata
Date: Fri, 11 Dec 2020 02:02:24 +0000 [thread overview]
Message-ID: <20201211020155.GA490@b29397-desktop> (raw)
In-Reply-To: <CAL_JsqKxcWjdxVHSSHKKRtshwOXeodjQWCYt6G7asJYjjuoWQQ@mail.gmail.com>
On 20-12-10 09:38:49, Rob Herring wrote:
> On Thu, Dec 10, 2020 at 7:42 AM Peter Chen <peter.chen@kernel.org> wrote:
> >
> > From: Peter Chen <peter.chen@nxp.com>
> >
> > When a platform device is released, it frees the device platform_data
> > memory region using kfree, if the memory is not allocated by kmalloc,
> > it may run into trouble. See the below comments from kfree API.
> >
> > * Don't free memory not originally allocated by kmalloc()
> > * or you will run into trouble.
> >
> > For the device which is created dynamically using of_platform_populate,
> > if the platform_data is existed at of_dev_auxdata structure, the OF code
> > simply assigns the platform_data pointer to newly created device, but
> > not using platform_device_add_data to allocate one. For most of platform
> > data region at device driver, which may not be allocated by kmalloc, they
> > are at global data region or at stack region at some situations.
>
> auxdata is a "temporary" thing for transitioning to DT which I want to
> remove. So I don't really want to see it expanded nor new users. We've
> got about a dozen arm32 platforms and 5 cases under drivers/.
>
How to handle the below user case:
Parent device creates child device through device tree node (eg, usb/dwc3,
usb/cdns3), there are some platform quirks at parent device(vendor glue
layer) need child device (core IP device) driver to handle. The quirks
are not limited to the hardware quirk, may include the callbacks, software
flag (eg: XHCI_DEFAULT_PM_RUNTIME_ALLOW/XHCI_SKIP_PHY_INIT, at
drivers/usb/host/xhci.h)
> > + int platform_data_length = 0;
> > int rc = 0;
> >
> > /* Make sure it has a compatible property */
> > @@ -378,6 +387,9 @@ static int of_platform_bus_create(struct device_node *bus,
> > if (auxdata) {
> > bus_id = auxdata->name;
> > platform_data = auxdata->platform_data;
> > + platform_data_length = auxdata->platform_data_length;
> > + if (platform_data && !platform_data_length)
> > + pr_warn("Make sure platform_data is allocated by kmalloc\n");
>
> Isn't this going to warn on the majority of users as static data is the norm.
This warning only triggers at the cases which driver defines auxdata and
platform_data pointer is in it. Besides, directly assign the address
of static data to device platfrom_data pointer is wrong thing, this region
will be freed using kfree at platform_device_release. Using platform_device_add_data
API is the correct thing to do that.
--
Thanks,
Peter Chen
next prev parent reply other threads:[~2020-12-11 2:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 13:42 [PATCH 1/2] of: platform: introduce platform data length for auxdata Peter Chen
2020-12-10 13:42 ` [PATCH 2/2] usb: cdns3: imx: assign platform_data_length for auxdata structure Peter Chen
2020-12-10 15:38 ` [PATCH 1/2] of: platform: introduce platform data length for auxdata Rob Herring
2020-12-11 2:02 ` Peter Chen [this message]
2020-12-22 2:23 ` Peter Chen
2021-01-04 15:00 ` Rob Herring
2021-01-05 3:37 ` Peter Chen
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=20201211020155.GA490@b29397-desktop \
--to=peter.chen@nxp.com \
--cc=a-govindraju@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=frank.li@nxp.com \
--cc=frowand.list@gmail.com \
--cc=linux-imx@nxp.com \
--cc=linux-usb@vger.kernel.org \
--cc=pawell@cadence.com \
--cc=peter.chen@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.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).