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] [day] [month] [year] [list]
Date:	Sat, 5 Jan 2013 18:19:01 -0800
From:	Anton Vorontsov <anton@...msg.org>
To:	"Tc, Jenny" <jenny.tc@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	anish kumar <anish198519851985@...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

On Mon, Dec 03, 2012 at 02:09:02AM +0000, Tc, Jenny wrote:
> > > Could you please review this. This is a follow up patch for "PATCH]
> > > extcon : callback function to read cable property"
> > 
> > While I see nothing wrong with the patch itself, I beg you to send some users
> > for the new calls. Don't be obsessed with the extcon internals too much,
> > think more about how things will interact (i.e. I really really want to see how
> > you use these calls from the power supply drivers).
> 
> The usage of extcon cable property is captured in patch https://lkml.org/lkml/2012/10/18/219
> This patch uses a extcon_dev  callback function get_cable_properties() to get the
> cable properties. As discussed in the previous mail thread, it may not be good to have a extcon call
> back function since the extcon provider may not be aware of the cable properties. This patch replaces
> the callback function with an API, so that whoever knows the cable property, can set the property
> using the extcon API extcon_cable_set_data().
> 
> The usage flow would be
> 1)Consumer gets a notification from the extcon
> 2)consumer reads the property using the API extcon_cable_get_data
> 
> This way it doesn't mandatory for the extcon provider to give the cable property.
> Anyone who is aware of the cable property can set the cable property using the API.
> It makes the consumer and provider implementations very simple.
> 
> With this new API, the callback function in patch https://lkml.org/lkml/2012/10/18/219 can be
> replaced by the API extcon_cable_set_data().

Looking at this, the whole idea of hiding power source behind the "extcon"
seems dubious. Why don't you use USB device to get the current?

"extcon" subsystem, as I see it, should only be used to get notified about
external connectors events. And that's all. And chargers probably should
not even care about extcon (well, with the exception of the direct AC/gpio
power source).

For USB, it would make more sense if for you'd get plug/unplug
notifications *and* properties from the USB device (or OTG transceiver)
directly, not from the extcon. And I guess we have this mechanism already,
see drivers/power/pda_power.c.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ