linux-kernel - Re: Simple MFD driver example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Dec 2013 11:49:20 +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: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.

>> 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?
--
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/