linux-kernel - Re: [PATCH] mfd: add bq2415x charger driver

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:	Tue, 6 Dec 2011 11:46:03 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Felipe Contreras <felipe.contreras@...ia.com>,
	linux-main <linux-kernel@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Pali Roh??r <pali.rohar@...il.com>,
	Aliaksei Katovich <aliaksei.katovich@...ia.com>,
	Vladimir Zapolskiy <vz@...ia.com>
Subject: Re: [PATCH] mfd: add bq2415x charger driver

On Tue, Dec 06, 2011 at 01:43:06PM +0200, Felipe Contreras wrote:

> Yes, for this particular case the regulator API might be useful, but I
> don't see how external code will use this. Will they have to search
> for the name of this regulator, and then try to change the
> current_limit?

No, they'd get hooked in via the regulator interface as consumers.  Like
I say it depends on how autonomous the chip is, if it needs a lot of TLC
then it's probably not a regulator thing.  If all you do the chip is
turn in on and off and set limits then the upper layer should really be
able to be independant of the chip.

> > its thing and run autonomously starting, stopping and fast charging by
> > itself then a power supply driver seems like a good fit - just provide
> > the upper limits as platform data or something and watch it go.

> It would have to change its behavior depending on external events,
> like charger plugged/unplugged, different types of chargers, and so
> on. I'm thinking the rx51 board code could join some hooks from
> isp1704 (which detects the events) into this driver.

That stuff definitely sounds like power supply material - there's been
several other people discussing extending the framework to make it
easier for different power supply chain elements to coordinate with each
other.  
--
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/