Re: [PATCH 1/2] of: platform: introduce platform data length for auxdata

[Peter Chen <peter.chen@nxp.com>]

On 21-01-04 08:00:07, Rob Herring wrote:
> On Thu, Dec 10, 2020 at 7:02 PM Peter Chen <peter.chen@nxp.com> wrote:
> >
> > 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)
> 
> 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