On 21-01-04 08:00:07, Rob Herring wrote: > On Thu, Dec 10, 2020 at 7:02 PM Peter Chen <peter.chen@xxxxxxx> wrote: > > > > On 20-12-10 09:38:49, Rob Herring wrote: > > > On Thu, Dec 10, 2020 at 7:42 AM Peter Chen <peter.chen@xxxxxxxxxx> wrote: > > > > > > > > From: Peter Chen <peter.chen@xxxxxxx> > > > > > > > > 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
