linux-kernel - Re: [PATCH 3/3] MFD: MAX8997: IRQ definition moved to public header.

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]

Message-ID: <CAJ0PZbSrB9Cc-2h0xGot6kYUGR-uu0f7GVq43c_fSEd5oTMEog@mail.gmail.com>
Date:	Tue, 5 Jul 2011 15:49:39 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Donggeun Kim <dg77.kim@...sung.com>
Subject: Re: [PATCH 3/3] MFD: MAX8997: IRQ definition moved to public header.

On Tue, Jul 5, 2011 at 3:19 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Tue, Jul 05, 2011 at 02:57:54PM +0900, MyungJoo Ham wrote:
>> On Tue, Jul 5, 2011 at 2:16 AM, Mark Brown
>
>> > My understanding was that one of the goals of the power_supply subsystem
>> > was to support this sort of interaction? This (and your subsequent
>> > paragraphs) all sounds entirely sensible but it should be being dealt
>> > with at a higher level with the various charger drivers delivering
>> > events into a subsystem or board driver which coordinates them all.  It
>> > seems like the driver should be doing the work of dealing with the
>> > actual interrupts.
>
>> Yes, I also think that it is supposed to read and update attributes of
>> chargers. However, I don't see any ways to interconnect chargers and
>> related devices with power_supply subsystem.
>
> Nor do I, but this is just software so we should be able to make it do
> what's needed here.
>
>> If we let a user process interconnect the chargers and related
>> devices, we need to allow userland to access (both read and write)
>
> I didn't say anything about userspace, and I wouldn't expect userspace
> to do anything except policy here.
>

Ah.. then, I misunderstood "a higher level" in your previous reply was
userspace. Sorry, my bad.

I was just trying to say that
a) as long as we are connecting IRQ events of a device to another
device, the IRQ information is going to be needed as non-private, and
b) in the above case, we need to let the IRQ events of a device notify
other devices' drivers. (defined in a form of platform_data in the
case, specifying IRQ numbers for the notified devices requiring the
IRQ definitions to be included)

Anyway, I've been trying to implement some virtual device driver or
psuedo framework in kernel to interconnect charger related devices,
"charger manager". This code mentioned is to support that "charger
manager". It is sort of at a higher level of charger related devices,
taking device names of them as a platform data. The platform data
taking the IRQ numbers is the one for that "charger manager".

Thank you.

- MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
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/