On Wed, Dec 18, 2013 at 11:59 AM, Lee Jones <lee.jo...@linaro.org> wrote: > On Wed, 18 Dec 2013, Laszlo Papp wrote: > >> On Wed, Dec 18, 2013 at 11:34 AM, Lee Jones <lee.jo...@linaro.org> wrote: >> >> >> What you eventually see in hwmon is only a subset of all the features >> >> >> the IC provides. You may want to read this thread: >> >> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg536509.html >> >> > >> >> > Okay, so the best thing to do is send out the entire patch-set at >> >> > once, CC'ing each of the maintainers on every patch so we can all see >> >> > how this thing fits together. >> >> >> >> Well, I am not even sure currently where to head with the MFD bits and >> >> its children subdevices currently.... >> >> >> >> I would appreciate any direction. Yesterday, I was told on IRC, I >> >> would need to switch from i2c to platform drivers for the hwmon and >> >> gpio parts, but looking at some existing mfd driver code and their >> >> children drivers, I do not see it like that. >> >> >> >> I have already sent out the gpio driver yesterday which works fine on >> >> its own: http://www.spinics.net/lists/kernel/msg1655805.html >> > >> > This is going to need a lot of work. >> > >> > Did you run the patch through `./scripts/checkpatch.pl` before >> > submitting? >> >> Of course, there has been zero errors and warnings. Eventually, I even >> ran the Lindent. Actual feedback is welcome for sure. > > I barely have enough time to review my own subsystem, let alone > others. Linus will do a great job in this regard. > >> >> Could you please guide me into the right direction what I need to >> >> change once we have standalone drivers, and they should be glued >> >> together? I thought adding an abstraction with the mfd layer would be >> >> sufficient, but apparently, that is not enough. >> >> >> >> Practically speaking, I am confused since if I needed to change the >> >> existing drivers, that means I could potentially break the interface >> >> for the existing users if the drivers stop working on their own, but >> >> then again, I am such a newbie that I would greatly appreciate some >> >> pointers. >> > >> > The MFD subsystem is quite simple to use. I'm taken aback that this is >> > your major stumbling block. Read though the mfd_add_device(s)() calls >> > to see what it expects. The rest is childs play. >> >> Yeah, I have taken, but that does not still explain the consistency I >> mentioned above. Some children do not conform the "platform" driver >> suggestion I was told. >> >> Also, what about the actual MFD code submitted? Anything to modify in >> there? Could you please comment on that, or is the direction of it >> good enough for me to submit it as a real patch at this stage? > > Submit them all as I requested before and we will do a proper review. > > Copy and pasting patches into conversation emails isn't the correct > method to use.
Well, I am at the designing phase, and I am not even sure it is so far OK. I am just trying to discuss the idea and direction, not the implementation details yet. Not that I already wasted some time by not asking before implementing stuff. See the previous hwmon patch for details. I really do not want to waste more time if possible. It costs a lot. :) ... but if you do not see design issues with it, then I will submit the implementation for review and fixes, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
