linux-kernel - Re: [PATCH] EXTCON: Get and set cable properties

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <50CE698A.4080002@samsung.com>
Date:	Mon, 17 Dec 2012 09:38:34 +0900
From:	Chanwoo Choi <cw00.choi@...sung.com>
To:	"Tc, Jenny" <jenny.tc@...el.com>
Cc:	anish kumar <anish198519851985@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Anton Vorontsov <cbouatmailru@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>
Subject: Re: [PATCH] EXTCON: Get and set cable properties

On 12/15/2012 09:16 AM, Tc, Jenny wrote:
> 
>>> I replied on the thread and pointed out issues that I see with this
>>> solution. IMHO It's not fair to register a cable with
>>> power_supply/regulator/charger manager just to expose the cable
>> properties.
>> Don't we do that with already in allmost all drivers?Like if I have a keyboard
>> driver and then I register with input framework and if the keyboard driver
>> needs clk services then I register with clk framework as well and same with
>> other services needed by keyboard driver.I think it makes sense for a cable
>> to register with different framework if it supports that functionality as those
>> services also would know that we have a cable with so and so property.
> 
> IMHO it's not a good choice to register a cable itself with any of the three subsystem
> (power_supply/regulator/charger manager)
> 
>  For example it cannot register with power_supply subsystem since it's not a 
>  power_supply. It's just source for a power_supply.We register either charger/battery with
>  power supply. I couldn't find a way to register the cable with power supply subsystem. 
> 
> In previous discussion Anton also agreed to this.
> 
> Anton,
> Could you please confirm?
> 
> I think the same case with regulator framework also. A cable doesn’t belong to a regulator framework.
> A cable doesn’t expose any control attribute (current control/voltage control). It just have  properties (eg current)
>  controlled by external agents (Host machine/wall charger)
> 
> And charger manager is a consumer and not a provider. It cannot decide the charger cable capabilities.
No, charger-manager include information for battery/charger/charger cable dependency on target H/W.
Each target has different h/w constraint for charging, so charger-manager can determine whether
specific charger cable is used on target or not.

> 
> 
>>>> As I said, extcon provider driver didn't provide directly charging
>>>> current(int
>>>> mA) and some state(unsigned long state) because the extcon provider
>>>> driver(Micro USB interface controller device or other device related
>>>> to external connector) haven't mechanism which detect dynamically
>>>> charging current immediately. If you wish to provide charging
>>>> current data to extcon consumer driver or framework, you should use
>>>> regulator/power_supply framework or other method in extcon provider
>> driver.
> 
> This information need not to come from the extcon provider. It can come from any driver
> Who knows the state of a cable. It may be a platform driver or may be a driver belongs to any
> of the three subsystem we discussed above (power_supply/regulator/charger_manager).
> Just by having an API like this (extcon_cable_set_data), it's not mandatory to register the cable
> with any of the subsystem.
> 
>>>> Also if you want to define 'struct extcon_chrgr_cable_props', you
>>>> should certainly show how detect dynamically charging current or state.
> 
> For USB cables, it's determined by USB enumeration. For USB 3.0 it would be 900mA and
> USB 2.0 it's 500mA. Also in un configured  state this would be 150 and 100mA respectively
I think only USB enumeration determine standard charging current according to version of USB.
But, Extcon subsystem always need detection mechanism. (e.g, Jack/Microphone detection device
of Wolfson sound codec and MUIC(Micro USB Interface Controller) device of MAXIM)

You didn't show any detection mechanism which detect changed state of host system.

What can some device for detecting of following host state except of CONNECT/DISCONNECT state?
I don't know. Please let me know it.

- SUSPEND(Host suspend for SDP cable),
- RESUME(Host wakeup)
- UPDATE (to increase the charge current after USB enumaeration).
- CONNECT
- DISCOONECT


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