Date:	Wed, 18 Dec 2013 12:01:57 +0000
From:	Laszlo Papp <lpapp@....org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	sameo@...ux.intel.com, LKML <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: Simple MFD driver example

On Wed, Dec 18, 2013 at 11:59 AM, Lee Jones <lee.jones@...aro.org> wrote:
> On Wed, 18 Dec 2013, Laszlo Papp wrote:
>
>> On Wed, Dec 18, 2013 at 11:34 AM, Lee Jones <lee.jones@...aro.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists