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
| ||
|
Date: Sat, 3 Nov 2012 02:57:35 +0000 From: "Tc, Jenny" <jenny.tc@...el.com> To: "'myungjoo.ham@...sung.com'" <myungjoo.ham@...sung.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 Myunjoo, Ping. Could you please have a look at my response below? -jtc > -----Original Message----- > From: Tc, Jenny > Sent: Thursday, October 25, 2012 2:55 PM > To: myungjoo.ham@...sung.com; ??? > Cc: linux-kernel@...r.kernel.org; anish kumar > Subject: RE: RE: [PATCH] extcon : callback function to read cable property > > > Subject: Re: RE: [PATCH] extcon : callback function to read cable > > property > > > 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?) > > The flow we have is "notifier (OTG driver/cable notifier driver) -> extcon-> > charging framework->charger driver" > > When the framework gets notification from the extcon, it just know cable is > connected/disconnected > > For a USB charging the state machine can be > > For USB2.0 > 1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA) > 2)CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)- > >DISCONNECT(0mA) > 3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)- > >HOST RESUME(500mA)->DISCONNECT(0mA) > > For USB 3.0 > 4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA) > 5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)- > >DISCONNECT(0mA) > 6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)- > >HOST RESUME(900mA)->DISCONNECT(0mA) > > > > > 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 > > I got your point. It's not just 2 cables we may need 4 cables to support USB2.0 > and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 > for USB 3.0. But what about the states? > > . > > > > > > > > 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. > > But just by getting the device instance how do we extract the cable > properties like cable state and the charge current in a generic way? > -- 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/
Powered by blists - more mailing lists