> -----Original Message----- > From: linux-input-owner@xxxxxxxxxxxxxxx > [mailto:linux-input-owner@xxxxxxxxxxxxxxx] On Behalf Of Mark Brown > Sent: Tuesday, September 07, 2010 5:27 PM > To: Premi, Sanjeev > Cc: linux-omap@xxxxxxxxxxxxxxx; linux-input@xxxxxxxxxxxxxxx > Subject: Re: omap3: regulator_get() failure in ads7846 > > On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote: > > > ts->reg = regulator_get(&spi->dev, "vcc"); > > > This regulator isn't defined for omap3evm. And I suspect - once > > defined - the name will be different than "vcc". > > What makes you say this? The names for regulator supplies are defined > in terms of the chip being supplied, not in terms of the board. [sp] The name "vcc" is too generic name for the regulator supply. If there were more than one supplies as in case of the omap3evm, it would be difficult to name the supply as "vcc". Assuming there is another (different) driver which uses "vcc" (as ads7846 uses currently) but uses different supply, what is expected behavior? If, however, the name here was something like "vcc_ts", then the supplies could be defined for any board as: static struct regulator_consumer_supply my_board_ts_supply = { .supply = "vcc_ts", }; This would be more portable for other boards as well. OR Does regulator_get() searches by "device_name-supply_id" pair? Then, my comments above don't hold... And I would try the mapping you mentioned below. > > > Looking at pointers on how this should be handled. > > The best thing to do is to define the mapping for the regulator. You > can work around it by enabling REGULATOR_DUMMY. [sp] Yes, this would be a workaround; but it comes with another warning on console. Best regards, Sanjeev > -- > To unsubscribe from this list: send the line "unsubscribe > linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
