Message-ID: <20121122200355.GA12397@lizard>
Date:	Thu, 22 Nov 2012 12:03:55 -0800
From:	Anton Vorontsov <cbouatmailru@...il.com>
To:	"Tc, Jenny" <jenny.tc@...el.com>
Cc:	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	??? <cw00.choi@...sung.com>,
	anish singh <anish198519851985@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"myunjoo.ham@...il.com" <myunjoo.ham@...il.com>,
	"lockwood@...roid.com" <lockwood@...roid.com>,
	"peterhuewe@....de" <peterhuewe@....de>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"lars@...afoo.de" <lars@...afoo.de>,
	"jic23@...nel.org" <jic23@...nel.org>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>
Subject: Re: Re: [PATCH] extcon : callback function to read cable property

On Thu, Nov 22, 2012 at 01:00:52PM +0000, Tc, Jenny wrote:
[...]
> For this solution to work, the cable provider itself
> need to register with any of these subsystems - power_supply/regulator/charger manager
> IMHO a cable provider shouldn't register itself with any of the subsystem.
> 
>  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.

Yes, I guess that doesn't make much sense.

> Anton,
> Do you have any suggestion here?
> 
> 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.
> 
> I  have a modified version of the above patch which uses properties directly. 
> https://gitorious.org/linux-charging-framework/linux-charging-framework/commit/ff358373dcb32027ebe1a267fc8b8999a3bd37e4

(Please, always inline the patches.)

I spent some time trying to understand what exactly you're trying to
accomplish and I failed, and that's why:

1. I see only some small snippets of the code, sometimes by means of URLs
   and references to another patches, which is hard to follow when you
   have like tens of emails in the thread;
2. I believe I still didn't see a user of this callback.

So, basically you're trying to force me to read your mind and guess your
ideas, but as it appears, I'm not good at it. :)

So, please do the following:

- Prepare a complete, but minimal workable solution, a patchset that shows
  how exactly you use the new features that you introduce;

- The series must be an all-in-1 patchset, so people won't need to go back
  and forth trying to understand how things depend on each other;

- Briefly describe how things work, a typical use-case and how drivers
  interact with each other. E.g. which driver registers extcon_device,
  which driver reads mA field, which driver sets mA field (and based on
  what information), which driver listens for the extcon events, which
  driver produces the extcon events, etc. No need for lengthy explanations
  about why you made the decisions, just a brief explanation of how things
  currently work and interact.

Thanks,
Anton.
--
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