Hello Arnd,
Presuming that the requests and comments upto v5 patchsets were
addressed in the last patchset (v6), here goes a pull request of
Extcon.
The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:
Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsung extcon-for-next
Donggeun Kim (1):
Extcon: support notification based on the state changes.
MyungJoo Ham (4):
Extcon (external connector): import Android's switch class and modify.
Extcon: support generic GPIO extcon driver
Extcon: support multiple states at a device.
Extcon: support mutually exclusive relation between cables.
Documentation/ABI/testing/sysfs-class-extcon | 97 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/extcon/Kconfig | 35 ++
drivers/extcon/Makefile | 6 +
drivers/extcon/extcon_class.c | 812 ++++++++++++++++++++++++++
drivers/extcon/extcon_gpio.c | 175 ++++++
include/linux/extcon.h | 322 ++++++++++
include/linux/extcon/extcon_gpio.h | 52 ++
9 files changed, 1502 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-extcon
create mode 100644 drivers/extcon/Kconfig
create mode 100644 drivers/extcon/Makefile
create mode 100644 drivers/extcon/extcon_class.c
create mode 100644 drivers/extcon/extcon_gpio.c
create mode 100644 include/linux/extcon.h
create mode 100644 include/linux/extcon/extcon_gpio.h
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
On Tue, Feb 28, 2012 at 05:58:02PM +0900, MyungJoo Ham wrote:
> Hello Arnd,
>
>
> Presuming that the requests and comments upto v5 patchsets were
> addressed in the last patchset (v6), here goes a pull request of
> Extcon.
Wait, please, before this code can be accepted, I would like to get
verification that you have also made the needed changes to the Android
userspace side of this interface, and that the code works there, and it
is on its way to be included in the main Android repo.
Is this true? If not, what is the plans for this to happen? Without
that happening, I don't think this code can be accepted, do you?
thanks,
greg k-h
On Tue, Feb 28, 2012 at 08:44:13AM -0800, Greg KH wrote:
> Wait, please, before this code can be accepted, I would like to get
> verification that you have also made the needed changes to the Android
> userspace side of this interface, and that the code works there, and it
> is on its way to be included in the main Android repo.
> Is this true? If not, what is the plans for this to happen? Without
> that happening, I don't think this code can be accepted, do you?
There's a few more kernel changes needed there before full acceptance
would be possible - for example, should have an integration into the
audio stack as one of the uses of the switch API on Android is for
headset detection.
On Tue, Feb 28, 2012 at 04:57:28PM +0000, Mark Brown wrote:
> On Tue, Feb 28, 2012 at 08:44:13AM -0800, Greg KH wrote:
>
> > Wait, please, before this code can be accepted, I would like to get
> > verification that you have also made the needed changes to the Android
> > userspace side of this interface, and that the code works there, and it
> > is on its way to be included in the main Android repo.
>
> > Is this true? If not, what is the plans for this to happen? Without
> > that happening, I don't think this code can be accepted, do you?
>
> There's a few more kernel changes needed there before full acceptance
> would be possible - for example, should have an integration into the
> audio stack as one of the uses of the switch API on Android is for
> headset detection.
Is this integration planned?
On Tue, Feb 28, 2012 at 09:02:46AM -0800, Greg KH wrote:
> On Tue, Feb 28, 2012 at 04:57:28PM +0000, Mark Brown wrote:
> > There's a few more kernel changes needed there before full acceptance
> > would be possible - for example, should have an integration into the
> > audio stack as one of the uses of the switch API on Android is for
> > headset detection.
> Is this integration planned?
Don't know if anyone has a specific plan at the moment, though there's
enough people care that I'd imagine it'll happen if Android decides to
use this stuff.
That said I don't see this as a blocker myself - it's more like an
afternoon or whatever of work than a serious development effort to do
the updates, but a similar thing applies to most of the Android
userspace updates.
On Wed, Feb 29, 2012 at 1:44 AM, Greg KH <[email protected]> wrote:
> On Tue, Feb 28, 2012 at 05:58:02PM +0900, MyungJoo Ham wrote:
>> Hello Arnd,
>>
>>
>> Presuming that the requests and comments upto v5 patchsets were
>> addressed in the last patchset (v6), here goes a pull request of
>> Extcon.
>
> Wait, please, before this code can be accepted, I would like to get
> verification that you have also made the needed changes to the Android
> userspace side of this interface, and that the code works there, and it
> is on its way to be included in the main Android repo.
>
> Is this true? ?If not, what is the plans for this to happen? ?Without
> that happening, I don't think this code can be accepted, do you?
>
> thanks,
>
> greg k-h
When an extcon device driver is not using the extended features
(multistate & mutually-exclusiveness) and CONFIG_ANDROID is on, the
userspace interface is same as the Android kernel's switch class (name
and state ABI, which were read-only in Android kernel).
If an extcon device drivers uses the extended features (multistate &
mutually-exclusiveness) by adding "cable names", the state ABI will
provided information in different format. Besides, Android kernel's
switch device driver cannot provide the extended feature anyway.
Thanks.
Cheers!
MyungJoo.
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
On Wed, Feb 29, 2012 at 10:57 AM, MyungJoo Ham <[email protected]> wrote:
> On Wed, Feb 29, 2012 at 1:44 AM, Greg KH <[email protected]> wrote:
>> On Tue, Feb 28, 2012 at 05:58:02PM +0900, MyungJoo Ham wrote:
>>> Hello Arnd,
>>>
>>>
>>> Presuming that the requests and comments upto v5 patchsets were
>>> addressed in the last patchset (v6), here goes a pull request of
>>> Extcon.
>>
>> Wait, please, before this code can be accepted, I would like to get
>> verification that you have also made the needed changes to the Android
>> userspace side of this interface, and that the code works there, and it
>> is on its way to be included in the main Android repo.
>>
>> Is this true? ?If not, what is the plans for this to happen? ?Without
>> that happening, I don't think this code can be accepted, do you?
>>
>> thanks,
>>
>> greg k-h
>
> When an extcon device driver is not using the extended features
> (multistate & mutually-exclusiveness) and CONFIG_ANDROID is on, the
> userspace interface is same as the Android kernel's switch class (name
> and state ABI, which were read-only in Android kernel).
>
> If an extcon device drivers uses the extended features (multistate &
> mutually-exclusiveness) by adding "cable names", the state ABI will
> provided information in different format. Besides, Android kernel's
> switch device driver cannot provide the extended feature anyway.
ps. If CONFIG_ANDROID is on and the extended features (that were not
in Android kernel) are used by an extcon device driver, then, the
format of state ABI will be different. However, the path should be the
same although there will be additional sysfs entries.
>
>
> Thanks.
>
>
> Cheers!
> MyungJoo.
> --
> MyungJoo Ham, Ph.D.
> System S/W Lab, S/W Center, Samsung Electronics
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
On Wed, Feb 29, 2012 at 2:45 AM, Mark Brown
<[email protected]> wrote:
> On Tue, Feb 28, 2012 at 09:02:46AM -0800, Greg KH wrote:
>> On Tue, Feb 28, 2012 at 04:57:28PM +0000, Mark Brown wrote:
>
>> > There's a few more kernel changes needed there before full acceptance
>> > would be possible - for example, should have an integration into the
>> > audio stack as one of the uses of the switch API on Android is for
>> > headset detection.
>
>> Is this integration planned?
>
> Don't know if anyone has a specific plan at the moment, though there's
> enough people care that I'd imagine it'll happen if Android decides to
> use this stuff.
>
> That said I don't see this as a blocker myself - it's more like an
> afternoon or whatever of work than a serious development effort to do
> the updates, but a similar thing applies to most of the Android
> userspace updates.
I'm not sure which Android kernel devide drivers are going to be upstreamed.
However, if the swtich device driver writers decide to keep the
functionality limited to the original Android switch class by not
providing cable names additionally, the changes will probably be
limited to ":s/switch/extcon/g" for API calls and struct name.
Cheers!
MyungJoo.
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
On Wed, Feb 29, 2012 at 11:05:39AM +0900, MyungJoo Ham wrote:
> On Wed, Feb 29, 2012 at 2:45 AM, Mark Brown
> > Don't know if anyone has a specific plan at the moment, though there's
> > enough people care that I'd imagine it'll happen if Android decides to
> > use this stuff.
> > That said I don't see this as a blocker myself - it's more like an
> > afternoon or whatever of work than a serious development effort to do
> > the updates, but a similar thing applies to most of the Android
> > userspace updates.
> I'm not sure which Android kernel devide drivers are going to be upstreamed.
There's a lot of things that are just generic functionality and aren't
at all Android specific, a lot of which is already upstream but just not
exporting the switch API but instead using other existing kernel APIs.
> However, if the swtich device driver writers decide to keep the
> functionality limited to the original Android switch class by not
> providing cable names additionally, the changes will probably be
> limited to ":s/switch/extcon/g" for API calls and struct name.
For things like headphone detection the actual switch they're providing
has issues too even just within the switch API - it's called "h2w" with
magic values.