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: <496F1C7A.5080202@gmail.com>
Date:	Thu, 15 Jan 2009 11:22:34 +0000
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	Eric Miao <eric.y.miao@...il.com>
CC:	Mike Rapoport <mike@...pulab.co.il>,
	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.

Eric Miao wrote:
> 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.
>   
Agreed, that lack of a means to obtain i2c devices in board configs is
beginning to get in the way
of quite a few things.  Perhaps we need to start a proper discussion on
how to sort that out.
(some sort of registered call backs perhaps to allow the right dev
pointers to be set on the i2c
device finally being allocated?)  I'm guessing the i2c guys are going to
have strong views
on any changes to their allocation approach!
> 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
>   
Agreed.  This definitely isn't the way to go in the long run (assuming
otg etc get cleaned up)
but would it be an acceptable stop gap?  I'm just keen to get the
functionality available
so as to get a board config (intel stargate 2) sorted.  (some of which
you were kind enough to
review a while back - thanks).

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