| Message ID | 20110406152322.GA2757@sortiz-mobl (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -33,6 +33,7 @@ struct class; > struct subsys_private; > struct bus_type; > struct device_node; > +struct mfd_cell; > > struct bus_attribute { > struct attribute attr; > @@ -444,6 +445,8 @@ struct device { > struct device_node *of_node; /* associated device tree node */ > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > + What is a "MFD cell pointer" and why is it needed in struct device? thanks, greg k-h ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Hi Greg, On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > --- a/include/linux/device.h > > +++ b/include/linux/device.h > > @@ -33,6 +33,7 @@ struct class; > > struct subsys_private; > > struct bus_type; > > struct device_node; > > +struct mfd_cell; > > > > struct bus_attribute { > > struct attribute attr; > > @@ -444,6 +445,8 @@ struct device { > > struct device_node *of_node; /* associated device tree node */ > > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > > + > > What is a "MFD cell pointer" and why is it needed in struct device? An MFD cell is an MFD instantiated device. MFD (Multi Function Device) drivers instantiate platform devices. Those devices drivers sometimes need a platform data pointer, sometimes an MFD specific pointer, and sometimes both. Also, some of those drivers have been implemented as MFD sub drivers, while others know nothing about MFD and just expect a plain platform_data pointer. We've been faced with the problem of being able to pass both MFD related data and a platform_data pointer to some of those drivers. Squeezing the MFD bits in the sub driver platform_data pointer doesn't work for drivers that know nothing about MFDs. It also adds an additional dependency on the MFD API to all MFD sub drivers. That prevents any of those drivers to eventually be used as plain platform device drivers. So, adding an MFD cell pointer to the device structure allows us to cleanly pass both pieces of information, while keeping all the MFD sub drivers independant from the MFD core if they want/can. Cheers, Samuel.
On Wed, 2011-04-06 at 19:05 +0200, Samuel Ortiz wrote: > Hi Greg, > > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > > --- a/include/linux/device.h > > > +++ b/include/linux/device.h > > > @@ -33,6 +33,7 @@ struct class; > > > struct subsys_private; > > > struct bus_type; > > > struct device_node; > > > +struct mfd_cell; > > > > > > struct bus_attribute { > > > struct attribute attr; > > > @@ -444,6 +445,8 @@ struct device { > > > struct device_node *of_node; /* associated device tree node */ > > > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > > > + > > > > What is a "MFD cell pointer" and why is it needed in struct device? > An MFD cell is an MFD instantiated device. > MFD (Multi Function Device) drivers instantiate platform devices. Those > devices drivers sometimes need a platform data pointer, sometimes an MFD > specific pointer, and sometimes both. Also, some of those drivers have been > implemented as MFD sub drivers, while others know nothing about MFD and just > expect a plain platform_data pointer. > > We've been faced with the problem of being able to pass both MFD related data > and a platform_data pointer to some of those drivers. Squeezing the MFD bits > in the sub driver platform_data pointer doesn't work for drivers that know > nothing about MFDs. It also adds an additional dependency on the MFD API to > all MFD sub drivers. That prevents any of those drivers to eventually be used > as plain platform device drivers. > So, adding an MFD cell pointer to the device structure allows us to cleanly > pass both pieces of information, while keeping all the MFD sub drivers > independant from the MFD core if they want/can. Why isn't an MFD the parent of its component devices? Ben.
Hi Ben, On Wed, Apr 06, 2011 at 06:16:49PM +0100, Ben Hutchings wrote: > > So, adding an MFD cell pointer to the device structure allows us to cleanly > > pass both pieces of information, while keeping all the MFD sub drivers > > independant from the MFD core if they want/can. > > Why isn't an MFD the parent of its component devices? It actually is. How would that help here ? Cheers, Samuel.
On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote: > Hi Greg, > > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > > --- a/include/linux/device.h > > > +++ b/include/linux/device.h > > > @@ -33,6 +33,7 @@ struct class; > > > struct subsys_private; > > > struct bus_type; > > > struct device_node; > > > +struct mfd_cell; > > > > > > struct bus_attribute { > > > struct attribute attr; > > > @@ -444,6 +445,8 @@ struct device { > > > struct device_node *of_node; /* associated device tree node */ > > > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > > > + > > > > What is a "MFD cell pointer" and why is it needed in struct device? > An MFD cell is an MFD instantiated device. > MFD (Multi Function Device) drivers instantiate platform devices. Those > devices drivers sometimes need a platform data pointer, sometimes an MFD > specific pointer, and sometimes both. Also, some of those drivers have been > implemented as MFD sub drivers, while others know nothing about MFD and just > expect a plain platform_data pointer. That sounds like a bug in those drivers, why not fix them to properly pass in the correct pointer? > We've been faced with the problem of being able to pass both MFD related data > and a platform_data pointer to some of those drivers. Squeezing the MFD bits > in the sub driver platform_data pointer doesn't work for drivers that know > nothing about MFDs. It also adds an additional dependency on the MFD API to > all MFD sub drivers. That prevents any of those drivers to eventually be used > as plain platform device drivers. Then they shouldn't be "plain" platform drivers, that should only be reserved for drivers that are the "lowest" type. Just make them MFD devices and go from there. > So, adding an MFD cell pointer to the device structure allows us to cleanly > pass both pieces of information, while keeping all the MFD sub drivers > independant from the MFD core if they want/can. They shouldn't be "independant", make them "dependant" and go from there. thanks, greg k-h ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On Wed, 2011-04-06 at 19:51 +0200, Samuel Ortiz wrote: > Hi Ben, > > On Wed, Apr 06, 2011 at 06:16:49PM +0100, Ben Hutchings wrote: > > > So, adding an MFD cell pointer to the device structure allows us to cleanly > > > pass both pieces of information, while keeping all the MFD sub drivers > > > independant from the MFD core if they want/can. > > > > Why isn't an MFD the parent of its component devices? > It actually is. How would that help here ? I was thinking you could encode the component address in the platform_device name (just as the bus address is the name of a normal bus device). That plus the parent device pointer would be sufficient information to look up the mfd_cell. Ben.
On Wed, 6 Apr 2011 10:56:47 -0700 Greg KH <gregkh@suse.de> wrote: > On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote: > > Hi Greg, > > > > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > > > --- a/include/linux/device.h > > > > +++ b/include/linux/device.h > > > > @@ -33,6 +33,7 @@ struct class; > > > > struct subsys_private; > > > > struct bus_type; > > > > struct device_node; > > > > +struct mfd_cell; > > > > > > > > struct bus_attribute { > > > > struct attribute attr; > > > > @@ -444,6 +445,8 @@ struct device { > > > > struct device_node *of_node; /* associated > > > > device tree node */ const struct of_device_id *of_match; /* > > > > matching of_device_id from driver */ > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer > > > > */ + > > > > > > What is a "MFD cell pointer" and why is it needed in struct > > > device? > > An MFD cell is an MFD instantiated device. > > MFD (Multi Function Device) drivers instantiate platform devices. > > Those devices drivers sometimes need a platform data pointer, > > sometimes an MFD specific pointer, and sometimes both. Also, some > > of those drivers have been implemented as MFD sub drivers, while > > others know nothing about MFD and just expect a plain platform_data > > pointer. > > That sounds like a bug in those drivers, why not fix them to properly > pass in the correct pointer? I'm still trying to understand if this is a theoretical problem, or if Grant has actually experienced a regression. His mention of bisecting made it sound like the latter was the case, but I've yet to hear of specifically what drivers this was breaking. Samuel described some potential driver breakage, but nothing concrete. I do agree that this needs a better solution, given the theoretical breakage. > > > We've been faced with the problem of being able to pass both MFD > > related data and a platform_data pointer to some of those drivers. > > Squeezing the MFD bits in the sub driver platform_data pointer > > doesn't work for drivers that know nothing about MFDs. It also adds > > an additional dependency on the MFD API to all MFD sub drivers. > > That prevents any of those drivers to eventually be used as plain > > platform device drivers. > > Then they shouldn't be "plain" platform drivers, that should only be > reserved for drivers that are the "lowest" type. Just make them MFD > devices and go from there. The problem is of mixing "plain" platform devices and MFD devices. It's reasonable to assume that different hardware may be using one method or the other to create devices; in order to maintain compatibility with the driver, one either needs to use a plain platform device. Alternatively, if an MFD-specific device class is created, then MFD devices would start showing up in weird places. > > > So, adding an MFD cell pointer to the device structure allows us to > > cleanly pass both pieces of information, while keeping all the MFD > > sub drivers independant from the MFD core if they want/can. > > They shouldn't be "independant", make them "dependant" and go from > there. > > thanks, > > greg k-h ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote: > > > We've been faced with the problem of being able to pass both MFD > > > related data and a platform_data pointer to some of those drivers. > > > Squeezing the MFD bits in the sub driver platform_data pointer > > > doesn't work for drivers that know nothing about MFDs. It also adds > > > an additional dependency on the MFD API to all MFD sub drivers. > > > That prevents any of those drivers to eventually be used as plain > > > platform device drivers. > > > > Then they shouldn't be "plain" platform drivers, that should only be > > reserved for drivers that are the "lowest" type. Just make them MFD > > devices and go from there. > > > The problem is of mixing "plain" platform devices and MFD devices. Then don't do that. > It's reasonable to assume that different hardware may be using > one method or the other to create devices; in order to maintain > compatibility with the driver, one either needs to use a plain platform > device. Alternatively, if an MFD-specific device class is created, > then MFD devices would start showing up in weird places. Then fix it. Lots of other drivers handle different "bus types" just fine (look at the EHCI USB driver for an example.) Don't polute the driver core just because you don't want to fix up the individual driver issues that are quite obvious. thanks, greg k-h ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On Wed, Apr 06, 2011 at 10:56:47AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote: > > Hi Greg, > > > > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > > > --- a/include/linux/device.h > > > > +++ b/include/linux/device.h > > > > @@ -33,6 +33,7 @@ struct class; > > > > struct subsys_private; > > > > struct bus_type; > > > > struct device_node; > > > > +struct mfd_cell; > > > > > > > > struct bus_attribute { > > > > struct attribute attr; > > > > @@ -444,6 +445,8 @@ struct device { > > > > struct device_node *of_node; /* associated device tree node */ > > > > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > > > > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > > > > + > > > > > > What is a "MFD cell pointer" and why is it needed in struct device? > > An MFD cell is an MFD instantiated device. > > MFD (Multi Function Device) drivers instantiate platform devices. Those > > devices drivers sometimes need a platform data pointer, sometimes an MFD > > specific pointer, and sometimes both. Also, some of those drivers have been > > implemented as MFD sub drivers, while others know nothing about MFD and just > > expect a plain platform_data pointer. > > That sounds like a bug in those drivers, why not fix them to properly > pass in the correct pointer? Because they're drivers for generic IPs, not MFD ones. By forcing them to use MFD specific structure and APIs, we make it more difficult for platform code to instantiate them. The timberdale MFD for example is built with a Xilinx SPI controller, and a Micrel ks8842 ethernet switch IP. Forcing those devices into being MFD devices would mean any platform willing to instantiate them would have to use the MFD APIs. That sounds a bit artificial to me. Although there is currently no drivers instantiated by both an MFD driver and some platform code, Grant complaint about the Xilinx SPI driver moving from a platform driver to an MFD one makes sense to me. > > So, adding an MFD cell pointer to the device structure allows us to cleanly > > pass both pieces of information, while keeping all the MFD sub drivers > > independant from the MFD core if they want/can. > > They shouldn't be "independant", Excuse my poor spelling. > make them "dependant" and go from there. That's what the code currently does. Cheers, Samuel.
Hi, On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote: > > > > What is a "MFD cell pointer" and why is it needed in struct device? > > > An MFD cell is an MFD instantiated device. > > > MFD (Multi Function Device) drivers instantiate platform devices. Those > > > devices drivers sometimes need a platform data pointer, sometimes an MFD > > > specific pointer, and sometimes both. Also, some of those drivers have been > > > implemented as MFD sub drivers, while others know nothing about MFD and just > > > expect a plain platform_data pointer. > > > > That sounds like a bug in those drivers, why not fix them to properly > > pass in the correct pointer? > Because they're drivers for generic IPs, not MFD ones. By forcing them to use > MFD specific structure and APIs, we make it more difficult for platform code > to instantiate them. I agree. What I do on those cases is to have a simple platform_device for the core IP driver and use platform_device_id tables to do runtime checks of the small differences. If one platform X doesn't use a platform_bus, it uses e.g. PCI, then you make a PCI "bridge" which allocates a platform_device with the correct name and adds that to the driver model. See [1] (for the core driver) and [2] (for a PCI bridge driver) for an example of what I'm talking about. > The timberdale MFD for example is built with a Xilinx SPI controller, and a > Micrel ks8842 ethernet switch IP. Forcing those devices into being MFD devices > would mean any platform willing to instantiate them would have to use the MFD > APIs. That sounds a bit artificial to me. do they share any address space ? If they do, then you'd need something to synchronize, right ? If they don't, then you just add two separate devices, they don't have to be MFD. > Although there is currently no drivers instantiated by both an MFD driver > and some platform code, Grant complaint about the Xilinx SPI driver moving > from a platform driver to an MFD one makes sense to me. I don't think so. That's not really an MFD device is it ? It's just two different IPs instantianted on the same ASIC/FPGA, right ? Unless they share the register space, IMHO, there's no need to make them MFD. [1] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/core.c [2] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/dwc3-haps.c
On Wed, Apr 06, 2011 at 09:59:02PM +0300, Felipe Balbi wrote: > Hi, > > On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote: > > > > > What is a "MFD cell pointer" and why is it needed in struct device? > > > > An MFD cell is an MFD instantiated device. > > > > MFD (Multi Function Device) drivers instantiate platform devices. Those > > > > devices drivers sometimes need a platform data pointer, sometimes an MFD > > > > specific pointer, and sometimes both. Also, some of those drivers have been > > > > implemented as MFD sub drivers, while others know nothing about MFD and just > > > > expect a plain platform_data pointer. > > > > > > That sounds like a bug in those drivers, why not fix them to properly > > > pass in the correct pointer? > > Because they're drivers for generic IPs, not MFD ones. By forcing them to use > > MFD specific structure and APIs, we make it more difficult for platform code > > to instantiate them. > > I agree. What I do on those cases is to have a simple platform_device > for the core IP driver and use platform_device_id tables to do runtime > checks of the small differences. If one platform X doesn't use a > platform_bus, it uses e.g. PCI, then you make a PCI "bridge" which > allocates a platform_device with the correct name and adds that to the > driver model. > > See [1] (for the core driver) and [2] (for a PCI bridge driver) for an > example of what I'm talking about. Yes, thanks for providing a real example, this is the best way to handle this. thanks, greg k-h ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On Wed, Apr 06, 2011 at 11:38:54AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote: > > > > We've been faced with the problem of being able to pass both MFD > > > > related data and a platform_data pointer to some of those drivers. > > > > Squeezing the MFD bits in the sub driver platform_data pointer > > > > doesn't work for drivers that know nothing about MFDs. It also adds > > > > an additional dependency on the MFD API to all MFD sub drivers. > > > > That prevents any of those drivers to eventually be used as plain > > > > platform device drivers. > > > > > > Then they shouldn't be "plain" platform drivers, that should only be > > > reserved for drivers that are the "lowest" type. Just make them MFD > > > devices and go from there. > > > > > > The problem is of mixing "plain" platform devices and MFD devices. > > Then don't do that. >From my perspective, MFD devices are little more than a bag of platform_devices, with the MFD layer provides infrastructure for managing it. It isn't that there are 'plain' platform device and 'mfd' devices. There are only platform_devices, but some of the drivers use additional data stored in a struct mfd. Personally, I'm not thrilled with the approach of using struct mfd, or more specifically making it available to drivers, but on the ugly scale it isn't very high. However, the changes on how struct mfd is passed that were merged in 2.6.39 were actively dangerous and are going to be reverted. Yet a method is still needed to pass the struct mfd in a safe way. I don't have a problem with adding the mfd pointer to struct platform_device, even if it should just be a stop gap to something better. Independently, I have been experimenting with typesafe methods for attaching data to devices which may very well be the long term approach, but for the short term I see no problem with adding the mfd pointer, particularly because it is by far safer than any of the other immediately available options. g. ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Hi, On Wed, Apr 06, 2011 at 03:09:00PM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 09:59:02PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote: > > > > > > What is a "MFD cell pointer" and why is it needed in struct device? > > > > > An MFD cell is an MFD instantiated device. > > > > > MFD (Multi Function Device) drivers instantiate platform devices. Those > > > > > devices drivers sometimes need a platform data pointer, sometimes an MFD > > > > > specific pointer, and sometimes both. Also, some of those drivers have been > > > > > implemented as MFD sub drivers, while others know nothing about MFD and just > > > > > expect a plain platform_data pointer. > > > > > > > > That sounds like a bug in those drivers, why not fix them to properly > > > > pass in the correct pointer? > > > Because they're drivers for generic IPs, not MFD ones. By forcing them to use > > > MFD specific structure and APIs, we make it more difficult for platform code > > > to instantiate them. > > > > I agree. What I do on those cases is to have a simple platform_device > > for the core IP driver and use platform_device_id tables to do runtime > > checks of the small differences. If one platform X doesn't use a > > platform_bus, it uses e.g. PCI, then you make a PCI "bridge" which > > allocates a platform_device with the correct name and adds that to the > > driver model. > > > > See [1] (for the core driver) and [2] (for a PCI bridge driver) for an > > example of what I'm talking about. > > Yes, thanks for providing a real example, this is the best way to handle > this. no problem. ps: that's the driver for the USB3 controller which will come on OMAP5. Driver being validate on a pre-silicon platform right now :-D In a few weeks I'll send the driver for integration.
diff --git a/drivers/base/platform.c b/drivers/base/platform.c index f051cff..bde6b97 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -149,6 +149,7 @@ static void platform_device_release(struct device *dev) of_device_node_put(&pa->pdev.dev); kfree(pa->pdev.dev.platform_data); + kfree(pa->pdev.dev.mfd_cell); kfree(pa->pdev.resource); kfree(pa); } diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c index d01574d..99b0d6d 100644 --- a/drivers/mfd/mfd-core.c +++ b/drivers/mfd/mfd-core.c @@ -18,6 +18,18 @@ #include <linux/pm_runtime.h> #include <linux/slab.h> +static int mfd_platform_add_cell(struct platform_device *pdev, const struct mfd_cell *cell) +{ + if (!cell) + return 0; + + pdev->dev.mfd_cell = kmemdup(cell, sizeof(*cell), GFP_KERNEL); + if (!pdev->dev.mfd_cell) + return -ENOMEM; + + return 0; +} + int mfd_cell_enable(struct platform_device *pdev) { const struct mfd_cell *cell = mfd_get_cell(pdev); @@ -75,7 +87,7 @@ static int mfd_add_device(struct device *parent, int id, pdev->dev.parent = parent; - ret = platform_device_add_data(pdev, cell, sizeof(*cell)); + ret = mfd_platform_add_cell(pdev, cell); if (ret) goto fail_res; @@ -123,7 +135,6 @@ static int mfd_add_device(struct device *parent, int id, return 0; -/* platform_device_del(pdev); */ fail_res: kfree(res); fail_device: diff --git a/include/linux/device.h b/include/linux/device.h index ab8dfc0..cf353cf 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -33,6 +33,7 @@ struct class; struct subsys_private; struct bus_type; struct device_node; +struct mfd_cell; struct bus_attribute { struct attribute attr; @@ -444,6 +445,8 @@ struct device { struct device_node *of_node; /* associated device tree node */ const struct of_device_id *of_match; /* matching of_device_id from driver */ + struct mfd_cell *mfd_cell; /* MFD cell pointer */ + dev_t devt; /* dev_t, creates the sysfs "dev" */ spinlock_t devres_lock; diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h index ad1b19a..28f81cf 100644 --- a/include/linux/mfd/core.h +++ b/include/linux/mfd/core.h @@ -86,7 +86,7 @@ extern int mfd_clone_cell(const char *cell, const char **clones, */ static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev) { - return pdev->dev.platform_data; + return pdev->dev.mfd_cell; } /* @@ -95,7 +95,10 @@ static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev) */ static inline void *mfd_get_data(struct platform_device *pdev) { - return mfd_get_cell(pdev)->mfd_data; + if (pdev->dev.mfd_cell) + return mfd_get_cell(pdev)->mfd_data; + else + return pdev->dev.platform_data; } extern int mfd_add_devices(struct device *parent, int id,