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]

Date:	Fri, 1 Jul 2011 09:43:31 +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>, myungjoo.ham@...il.com
Subject: Re: [PATCH 3/3] MFD: MAX8997: IRQ definition moved to public header.

On Fri, Jul 1, 2011 at 12:56 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Thu, Jun 30, 2011 at 05:00:13PM +0900, MyungJoo Ham wrote:
>
>> In our code:
>> http://git.infradead.org/users/kmpark/linux-2.6-samsung/blob/eba500212699c0ad8d6bde0dc01c3ec7101f8154:/arch/arm/mach-exynos4/setup-charger.c
>> around line 85, it specifies which interrupt is going to be a
>> wakeup-source ("true"), how the power-managing S/W should interpret
>> them.
>
> This looks like charger specific configuration which should be done by
> the charger driver rather than by directly working with the IRQs?
>

Well, the issue is that the charger driver just does not know what to
do with its own interrupts.

For example, each board has different regulator setting for DCIN
depending on the specification of the board (some uses 450mA
constantly, some uses 450mA and 700mA depending on the connection
information, which is not known to charger driver, some uses 900mA
unconditionally, and so on).

Sometimes setting the attributes of a charger at its own interrupts
depends on the status of another charger; when we have USB charger,
wireless charger, and solar panels, which may be enabled independently
and have their own device drivers.

Scenarios that we are going to support include limiting the aggregated
charging flow, stopping every charger for an error detected at a
single charger (only for really critical ones that imply that the
battery itself has a major issue) as usually only one of the chargers
has sophiscated sensors and controls, and disabling a charger when
others are active (e.g., when CC charging is finished and CV charging
is going on with little current).

In that charger specific configuration and its driver, we are trying
to aggregate multiple chargers (although we specified only two
independent chargers, not three, in that example).

Thanks,
- 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/