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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20ADAB092842284E95860F279283C564E4D554@BGSMSX101.gar.corp.intel.com>
Date:	Sat, 15 Dec 2012 00:16:25 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	anish kumar <anish198519851985@...il.com>
CC:	Chanwoo Choi <cw00.choi@...sung.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

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

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