On Tue, 26 Aug 2014, Dmitry Torokhov wrote: > On Tue, Aug 26, 2014 at 10:22:05AM +0100, Lee Jones wrote: > > On Mon, 25 Aug 2014, Chris Zhong wrote: > > > On 08/20/2014 05:21 PM, Lee Jones wrote: > > > >On Wed, 20 Aug 2014, Chris Zhong wrote: > > > > > > > >>The RK808 chip is a power management IC for multimedia and handheld > > > >>devices. It contains the following components: > > > >> > > > >>- Regulators > > > >>- RTC > > > >> > > > >>The rk808 core driver is registered as a platform driver and provides > > > >>communication through I2C with the host device for the different > > > >>components. > > > >> > > > >>Signed-off-by: Chris Zhong <zyw@xxxxxxxxxxxxxx> > > > >>--- > > > > [...] > > > > > >>+ rk808->pdata = pdata; > > > >Remove pdata from 'struct rk808'. You can obtain it from dev. > > > > > > Can I keep this pdata in rk808, because it is used in the regulator driver. > > > The one obtain from dev maybe empty. > > > > If the one in dev is empty, you should populate that instead. > > No, drivers should not populate platform data in devices - they do not > own it (unlike drvdata). Platform data should be read-only so that if > one would unbind and then try to re-bind the driver we'd end up in > exactly same state as before. Right. I guess this point is moot now, as my other point about pdata not actually being required has been accecpted. But, when I say "you can obtain it from dev" I meant via dev_get_platdata(dev), rather than dev_get_platdata(dev->parent). So if this 'pdata' has to go somewhere, rather than sticking it in the MFD's (parent) platform_data, the .platform_data attribute in 'struct mfd_cell' should be used. > For DT systems we should be allocating platform data separately and make > sure we clean up after ourselves. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
