Hello Andres,
On Wed, Feb 02, 2011 at 11:03:26PM -0800, Andres Salomon wrote:
On Wed, 2 Feb 2011 22:53:39 -0800 Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
On Wed, Feb 02, 2011 at 10:39:59PM -0800, Andres Salomon wrote:
On Wed, 2 Feb 2011 22:05:21 -0800 Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
On Wed, Feb 02, 2011 at 08:15:22PM -0800, Andres Salomon wrote:
static int __devinit twl4030_vibra_probe(struct platform_device *pdev) {
- struct twl4030_codec_vibra_data *pdata =
pdev->dev.platform_data;
- struct twl4030_codec_vibra_data *pdata =
platform_get_drvdata(pdev);
No, device's drvdata belongs to _this_ driver, and it is supposed to manage it and use as it sees fit.
Right, so it's used to pass data to the probe function; once the probe function has obtained the pdata pointer, it's free to do with it what it will.
Note platform_set_drvdata(pdev, info) later in this function along with platform_set_drvdata(pdev, NULL) in twl4030_vibra_remove(), which means that with your change you will be able to bind the device only once.
Hm, good point; if the driver is reloaded, the pdev that was created by mfd-core will have lost the pointer to pdata.
I wonder if I should be using mfd's driver_data instead. I used platform_data because a bunch of drivers had already made use of it to pass cell information..
Then they are doing it incorrectly. One possible way is to have parent device carry relevant data in its drvdata and have children get it from there.
I believe some drivers are even using the parent device already. See drivers/leds/leds-mc13783.c, for example, whose parent device drvdata is used to pass around a struct mc13783 to its children. Sounds like a possibility, will need to look into it further.
IMHO this isn't optimal done. The led driver somehow needs access to a struct mc13xxx because that one defines how to change the led-related registers.
If you ask me, the most clean solution would be that the functions like mc13xxx_lock and mc13xxx_reg_rmw wouldn't take a struct mc13xxx * as first parameter but a struct device *. Because in fact it's not the led driver's business what the mfd driver stores in his driver data.
(Note, I said clean, neither easy nor effective nor best.)
Uwe