linux-kernel - Re: [PATCH 2.6.29-rc1-git4] mfd: da9030 usb charge pump support within mfd 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]

Message-ID: <f17812d70901150013v2c70047er829b1c884a1d7772@mail.gmail.com>
Date:	Thu, 15 Jan 2009 16:13:36 +0800
From:	Eric Miao <eric.y.miao@...il.com>
To:	Mike Rapoport <mike@...pulab.co.il>
Cc:	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...ena.org.uk>,
	Samuel Ortiz <sameo@...nedhand.com>, felipe.balbi@...ia.com,
	Liam Girdwood <lrg@...nel.org>
Subject: Re: [PATCH 2.6.29-rc1-git4] mfd: da9030 usb charge pump support 
	within mfd driver.

On Thu, Jan 15, 2009 at 3:28 PM, Mike Rapoport <mike@...pulab.co.il> wrote:
>
>
> Eric Miao wrote:
>> On Thu, Jan 15, 2009 at 2:34 PM, Mike Rapoport <mike@...pulab.co.il> wrote:
>>>
>>> Eric Miao wrote:
>>>> On Thu, Jan 15, 2009 at 2:16 AM, Jonathan Cameron <jic23@....ac.uk> wrote:
>>>>> From: Jonathan Cameron <jic23@....ac.uk>
>>>>>
>>>>> Add support for changing the mode of the da9030 usb charge pump
>>>>>
>>>> Well, if it is totally USB charger related, I'd suggest to move this into
>>>> the dedicated driver. This mfd/da903x.c serves as a common code
>>>> base for all sub-peripherals.
>>> It's not exactly related to the charger, it's rather related to the USB voltage
>>> supplied to USB devices attached to PXA OHCI.
>>> Indeed the mfd/da903x.c serves as a common core for sub-peripherals, but IMHO
>>> adding a subdevice driver because of single method doesn't worth the overhead.
>>> I'm for the solution Jonathan proposes.
>>>
>>
>> Mmm... then who will be the invoker? I'm a bit upset about this
>> being exported while called out of control. If it works as the
>> name suggested, setting some mode, maybe we can have a
>> platform data field specifying this, and hide this totally within
>> the driver. I didn't look into this too much, just a concern here.
>
> The USB charge pump should be enabled if DA9030 should supply USB VBUS for USB
> devices connected to PXA OHCI port. In the most simple case, when the USB port
> is configured to be host only the platform data can be used to setup the charge
> pump once and forget about it. However, if the USB port is configured as OTG,
> the charge pump should be toggled depending on OTG ID.
> In EM-X270 I have a GPIO connected to OTG ID pin of the connector and according
> to the GPIO state I toggle the da9030 USB charge pump.
>

OK, now I understand the problem. The optimal way would be to invent
an abstraction for this external charge pump (in terms of PXA27x OTG
controller) and make DA9030 a derived class of it. But the PXA27x OTG
solution is really a hybrid one, and the existing OTG code is in a mess
(without a clear abstraction), the sub-optimal way would let platform code
do this trick. Yet the platform code is currently suffering from a missed
API to retreive this dynamically scanned I2C device. Mmm...stumped.

I would expect the final solution to be clean enough, that requires some
dependent stuffs to be modified, and the final look of this patch may be a
bit different.
--
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/