On 21-01-04 08:00:07, Rob Herring wrote:

On Thu, Dec 10, 2020 at 7:02 PM Peter Chen [off-list ref] wrote:

quoted

On 20-12-10 09:38:49, Rob Herring wrote:

quoted

On Thu, Dec 10, 2020 at 7:42 AM Peter Chen [off-list ref] wrote:

quoted

From: Peter Chen <redacted>

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)

The split of these between a platform specific driver and the core IP
driver was just wrong to begin with. There should only be 1 driver
with common 'library' functions like we do for every other case of
common, licensed IP. Perhaps the core driver should stop pretending it
is generic and figure out the quirks for itself by looking at the
parent node.

Not only hardware quirks, but software quirks and callbacks which are implemented
at platform specific driver and are called at core driver.

-- 

Thanks,
Peter Chen