RE: [PATCH] extcon : callback function to read cable property

[Tc, Jenny]

> > > For example,
> > > Firstly, the power_supply charging framework check state of charger
> > > cable whether attached or detached cable. Second, when power_supply
> > > charging framework receive the changed state of host system from
> > > 'Host system notifier', change charging current of charger cable.
> >
> > Not just SUSPEND, but we need to handle RESUME , UPDATE etc.  Also
> > this doesnât help us to define a standard interface for the charger
> > cable state/properties. IMHO it's not right to provide different
> > interfaces for different cables. This doesn't help us to standardize the
> charger cable interface.
> >
> > This thread has been running for a quite long time. Unfortunately we
> > couldn't make an agreement on the final solution. I would like to
> > recap the overall requirement and would like to propose alternate
> > solutions. The requirements is  to "Provide a generic interface for charger
> cable states and charger cable properties"
> >
> > Even though extcon subsystem handles charger cable states, it's not
> > enough to handle all kind of charger cable states. It can handle just 2 states
> CONNECT/DISCONNECT.
> > But there are scenarios where we need to handle more than 2 states
> > (eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any
> > mechanism to read cable properties in a generic way.  Extcon
> > charger-cable consumer driver implementations (eg charger-manager),
> > defines charger cable properties statically (current in mA) inside the
> > consumer driver. This is not enough, since the charger cable
> > properties may change dynamically
> >
> > In existing form extcon cannot support different charger cable states
> > and their properties in a generic way. Also we couldn't find a final
> > solution on how to modify the extcon to support these requirements.
> > From the whole discussion what I conclude is
> >  * extcon is not designed to support cable properties
> 
> The idea of using union seemed good to me, what happened to it?
> 
> I mean, MyungJoo Ham wrote:
> 
> | We may have:
> |        enum extcon_cable_type {
> |                EXTCON_CT_REGULATOR,
> |                EXTCON_CT_PSY,
> |                EXTCON_CT_CHARGER_CB,
> |                ...
> |        };
> | and have the following included at struct extcon_cable:
> |        union {
> |                struct regulator *reg;
> |                struct power_supply *psy;
> |                struct charger_cable *charger_cb;
> |                ...
> |        } cable data;
> |        enum extcon_cable_type cable_type;
> 
> This sounds good to me...

If I am right, this logic will help the consumer to know who will provide the properties and states.
But currently none of these subsystems are capable of giving the charger cable properties
because the information will be available only to the "provider driver". The provider driver
need not to be in any of these subsystem. For example if the OTG driver need to notify the
cable state (CONNECT/DISCONNECT/SUSPEND/RESUME..) and the properties (current in mA),
it doesn't make sense to register the OTG driver with any of these subsystems. 
But still it make sense to register with extcon since it can give the cable state information. 
I think this is applicable for all cable provider drivers.

If we are fine with union, then can we have the cable properties defined as unions?

struct charger_cable_props {
	unsigned long state;
	int mA;
}
struct extcon_cable {
	.....
	union {
		struct charger_cable_props chrgr_props;
		.....
	} data;
	enum extcon_cable_name cable_name;
};

This way we are not restricting the cable properties just to the charger cable.
We can add other charger cable properties as we identify the properties for them.
We can use the cable_name variable to identify  which cable property to use.

> 
> >  * extcon is not designed to support any cable state other than
> > CONNECT/DISCONNEC
> 
> Dunno for this one. Can we get these additional states via "properties" as
> described above?
> 
> Thanks,
> Anton.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
> body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
èº{.nÇ+‰·Ÿ®‰­†+%ŠËlzwm…ébëæìr¸›zX§»®w¥Š{ayºÊÚë,j­¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝj"ú!¶iO•æ¬z·švØ^¶m§ÿðÃnÆàþY&—