linux-kernel - Re: RE: [PATCH] extcon : callback function to read cable property

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-next>] [day] [month] [year] [list]

Date:	Thu, 25 Oct 2012 08:37:06 +0000 (GMT)
From:	MyungJoo Ham <myungjoo.ham@...sung.com>
To:	"Tc, Jenny" <jenny.tc@...el.com>,
	최찬우 <cw00.choi@...sung.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	anish kumar <anish198519851985@...il.com>
Subject: Re: RE: [PATCH] extcon : callback function to read cable property

> 
> > Subject: Re: [PATCH] extcon : callback function to read cable property
> > 
> > On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> > The rold of extcon inform only attached/detached state of extcon consumer
> > driver from extcon provider driver. After extcon consumer driver detect the
> > state of cable through extcon, extcon consumer driver or framework should
> > get the additional information of cable from other device driver except of
> > extcon.
> > 
> > Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG-
> > USB-OFF, Dock) What are common properties among many cables expect
> > attached or detached state?
> > 
> 
> For charger cable the current each cable can provide will be common.
> But may not be relevant for other cables. 
> 
> I understand your point on extcon role. But my concern is, when the consumer
> driver gets a notification on cable state change, how does the consumer query the
> cable properties in a generic way. Do you have any suggestions for this?
> 
> A use case can be as below
> 
> When a USB host cable (SDP) connected to the platform, without USB enumeration
> it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec).
> Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver
> need to configure the charger chip, it need to know the charger cable capabilities.
> For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1.
> But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How 
> CHGR1 driver can detect  the cable properties without having any platform layer
> hooks? The platform layer hooks (using platform data)will work only if the consumer is
> a platform driver. What if it's a framework which will have the same flow in all platforms?

In general,
an extcon user (extcon notifee) knows who's the extcon notifier; the user
is supposed to know the name of the notifier.

Thus, the extcon user should be able to get the appropriate object; i.e.,
a regulator struct in this case. Then, according to the USB state,
the current limit of the USB can be changed by the notifier; which
may notify (regulator subsystem has one) the extcon user to react
(change current limit of charger?)

Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator
controlling the charger current and if the OTG2 regulator affects
the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg)
the consumer-supplier chain should be setup (if the BSP is ideal).

OR

If it is impossible to have any objects of OTG2 (looks strange, but..),
you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB),
where Fast-charger.04 is enabled when USB2 enumeration is done with 5.

However, the following callback might be considered if there are cases where
an extcon user has information of extcon_name and cable_name while the user
CANNOT get any information on which device or object is related with the
specific cable; in struct extcon, with optional user initializing data section:

+	struct device **cable_device;
OR
+	char **cable_device_name;

With any relevant changes in the status with cable_device,
we may notify any notifier-block that are interested in the specific
cable. Then, the notifier-block (for register_interest) is going to
handle extcon-state changes and cable_device notifications.
Currently, the user's nb is for cable attach/detach events with
true/false value in the place of 32bit value (val). However,
if we add the third possible value for that parameter
(0: cable detached, 1: cable attached, 2: cable status changed;
go find out what's going on), it is still compatible.

I considered using a void pointer instead of cable_device, too.
However, that would spoil the subsystem too much; we'll be creating
a total chaos: "USB-A driver uses struct regulator", "USB-B driver
uses struct device", "USB-C driver uses true/false", and so on.

Cheers,
MyungJoo