linux-kernel - Re: [PATCH v5 2/3] extcon: Palmas Extcon 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:	Mon, 27 May 2013 12:26:14 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Kishon Vijay Abraham I <kishon@...com>
CC:	Chanwoo Choi <cw00.choi@...sung.com>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	"balbi@...com" <balbi@...com>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"george.cherian@...com" <george.cherian@...com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>
Subject: Re: [PATCH v5 2/3] extcon: Palmas Extcon Driver

On Monday 27 May 2013 12:11 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 27 May 2013 12:06 PM, Laxman Dewangan wrote:
>> On Monday 27 May 2013 12:01 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Monday 27 May 2013 11:52 AM, Laxman Dewangan wrote:
>>>> On Monday 27 May 2013 11:38 AM, Chanwoo Choi wrote:
>>>>> On 05/27/2013 02:54 PM, Kishon Vijay Abraham I wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote:
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>> I have some comment about this patch
>>>>>>> and upload modified patch to following repository
>>>>>>> (extcon-for-palmas).
>>>>>>> -
>>>>>>> http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmas&id=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This patchset include patch related to other module
>>>>>>> ,so I need your opinion to apply this patchset to git repository.
>>>>>> yeah.. Still there is some confusion with palmas_set_switch_smps10().
>>>>>> I think we can remove it for now and add it separately later. By this
>>>>>> at least we can have device mode fully functional in OMAP5. What do
>>>>>> you think?
>>>>>>
>>>>>     I agree your opinion.
>>>>>
>>>>> But, I propose some fixes about palmas_set_switch_smps10().
>>>>> I dont' prefer to call global function in exton-palmas.c from
>>>>> palmas-regulator.c.
>>>>> So, Why don't you use regulator consumer instead of global function?
>>>>> You can register specific regulator for enabling or disabling
>>>>> SMPS10_SWITCH_EN
>>>>> and then control SMPS10_SWITCH_EN bit through regulator framework in
>>>>> extcon-palmas.c
>>>>> without calling global function.
>>>> Along with this, I also like to make the VBUS regulator control to be
>>>> optional here. Currently it is mandatory.
>>> But dint you just tell on my v4 of this patch that you don’t require
>>> this.
>>> http://www.spinics.net/lists/linux-doc/msg10638.html
>> In V4, I said remove this VBUS control and my mean was to remove all
>> regulator calls for VBUS enabled/disable.
>> I saw you just remove the platform data option to have this control and
>> made VBUS mandatory.
>>
>> Probably some gap here.
> Indeed..
> I think then we should stick back to how it was with my v4 or else it
> would break OMAP. The regulator calls can't be moved anywhere else as it
> is specific to PALMAS.
>

I was thinking that extcon driver just detect the cable type and notify 
to the client. After cable detection, the next level of configuration 
should be done in the respective client.

On Tegra platform,  for ID pin detection, Tegra SOC is capable of detect 
the ID pin presence or Palma is capable. Depending on the board design, 
how the ID pin routed from USB connector to PMIC or to Tegra, we enable 
corresponding detection logic.
Once the USB driver got notification for ID pin presence (by any means), 
the enabling of VBUS (as the Tegra will work as Host now and need to 
supply VBUS), is done in USB driver.
Not sure about the OMAP here.


So in above context, I really do not want to have the VBUS control on 
extcon driver from Tegra context. If it is require in OMAP context then 
please make it as optional so that we can satisfy for Tegra and Omap 
platform.

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