On Wed, Oct 02, 2013 at 08:50:29PM +0100, Mark Brown wrote: > Bulk versions of the API would also make sense - it's likely that more > than one supply will need to be mapped - and please also add managed > versions so people don't have to write cleanup code.
For the bulk API would you prefer taking a single src and alias device and a list of supplies, or lists for all three? I would go for a list just for the supplies, as lists of devices would probably need to be filled in by a loop on the user end anyway negating the point of the bulk API some what and a lot of the use-cases will like have the same device on both sides for all the supplies. > > I have a couple of patches that update the Arizona driver to > > use this that I will send in if you think this looks along > > the lines of what you were suggesting. > > This seems like someting that should be in the MFD core, or at least > that there should be helpers in the core. Something like a set of > mappings in the mfd_cell so it's all data to the drivers. Looks like a simple enough addition to the MFD core, I will submit a patch doing it this way and see where we get to. > Please use a more meaningful name for dev. It might also be worth > allowing rewriting of the supply name since we'll probably find other > applications for things like modular board designs where name rewriting > is useful; since it's a function call with a parameter list it's harder > to add later than it would be with a struct. Seems that it could be useful to change the supply name, I will add this in as well. Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
