Message ID | 1330344939-18394-2-git-send-email-myungjoo.ham@samsung.com |
---|---|
State | New |
Headers | show |
On Mon, Feb 27, 2012 at 09:15:35PM +0900, MyungJoo Ham wrote: > +#ifdef CONFIG_ANDROID > + extcon_class = class_create(THIS_MODULE, "switch"); > +#else /* !CONFIG_ANDROID */ > + extcon_class = class_create(THIS_MODULE, "extcon"); > +#endif /* CONFIG_ANDROID */ This seems somewhat sad - if ANDROID is turned on the standard ABI vanishes. It'd be much nicer to do this with a symlink (or with symlinks within the android directory if the driver core doesn't support that). That way userspace code can be written to the new ABI and will work on Android systems without ifdefery.
On Fri, Mar 9, 2012 at 9:41 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Mon, Feb 27, 2012 at 09:15:35PM +0900, MyungJoo Ham wrote: > >> +#ifdef CONFIG_ANDROID >> + extcon_class = class_create(THIS_MODULE, "switch"); >> +#else /* !CONFIG_ANDROID */ >> + extcon_class = class_create(THIS_MODULE, "extcon"); >> +#endif /* CONFIG_ANDROID */ > > This seems somewhat sad - if ANDROID is turned on the standard ABI > vanishes. It'd be much nicer to do this with a symlink (or with > symlinks within the android directory if the driver core doesn't support > that). That way userspace code can be written to the new ABI and will > work on Android systems without ifdefery. Yes, this was the itching part. I'll first look into creating symlinks (either /sys/class/switch --> /sys/class/extcon or /sys/class/switch/* --> /sys/class/extcon/*). However, I think this symbolic links are better created selectively w/ CONFIG_ANDROID. Thanks. Cheers! MyungJoo.
On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Mon, Feb 27, 2012 at 09:15:35PM +0900, MyungJoo Ham wrote: > >> +#ifdef CONFIG_ANDROID >> + extcon_class = class_create(THIS_MODULE, "switch"); >> +#else /* !CONFIG_ANDROID */ >> + extcon_class = class_create(THIS_MODULE, "extcon"); >> +#endif /* CONFIG_ANDROID */ > > This seems somewhat sad - if ANDROID is turned on the standard ABI > vanishes. It'd be much nicer to do this with a symlink (or with > symlinks within the android directory if the driver core doesn't support > that). That way userspace code can be written to the new ABI and will > work on Android systems without ifdefery. This won't work if userspace code is receiving uevents through netlink and comparing based on the device name which it does in android. Why change the name at all? Extcon is much more specific than "switch." A switch can can be used for more than just external connections such as availability of HMDI audio (which is only available once a HDMI mode is chosen and the interface is enabled.) -Erik
On Fri, Mar 30, 2012 at 7:27 AM, Erik Gilling <konkers@google.com> wrote: > On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown > <broonie@opensource.wolfsonmicro.com> wrote: >> On Mon, Feb 27, 2012 at 09:15:35PM +0900, MyungJoo Ham wrote: >> >>> +#ifdef CONFIG_ANDROID >>> + extcon_class = class_create(THIS_MODULE, "switch"); >>> +#else /* !CONFIG_ANDROID */ >>> + extcon_class = class_create(THIS_MODULE, "extcon"); >>> +#endif /* CONFIG_ANDROID */ >> >> This seems somewhat sad - if ANDROID is turned on the standard ABI >> vanishes. It'd be much nicer to do this with a symlink (or with >> symlinks within the android directory if the driver core doesn't support >> that). That way userspace code can be written to the new ABI and will >> work on Android systems without ifdefery. > > This won't work if userspace code is receiving uevents through netlink > and comparing based on the device name which it does in android. Why > change the name at all? Extcon is much more specific than "switch." > A switch can can be used for more than just external connections such > as availability of HMDI audio (which is only available once a HDMI > mode is chosen and the interface is enabled.) > > -Erik With class_compat as in patchset v7, (this thread is w/ v6) does the issue (missing link from device name directory) still exist? (I don't think so) In the earlier iteration of dicussion, the name "switch" was dropped as "switch" may mislead the concept. https://lkml.org/lkml/2011/11/29/299 For HDMI and HDMI-audio, although HDMI-audio is not physically seperated from HDMI-cable and it is available after HDMI-cable is "attached", HDMI-audio is still an external connection to the kernel and its device drivers, isn' it? Cheers! MyungJoo.
On Thu, Mar 29, 2012 at 03:27:01PM -0700, Erik Gilling wrote: > On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown > <broonie@opensource.wolfsonmicro.com> wrote: > > On Mon, Feb 27, 2012 at 09:15:35PM +0900, MyungJoo Ham wrote: > >> +#ifdef CONFIG_ANDROID > >> + extcon_class = class_create(THIS_MODULE, "switch"); > >> +#else /* !CONFIG_ANDROID */ > >> + extcon_class = class_create(THIS_MODULE, "extcon"); > >> +#endif /* CONFIG_ANDROID */ > > This seems somewhat sad - if ANDROID is turned on the standard ABI > > vanishes. It'd be much nicer to do this with a symlink (or with > > symlinks within the android directory if the driver core doesn't support > > that). That way userspace code can be written to the new ABI and will > > work on Android systems without ifdefery. > This won't work if userspace code is receiving uevents through netlink > and comparing based on the device name which it does in android. Why That's not really the point here - the point is that the new ABI vanishes as soon as you turn on the legacy Android ABI. You're right that the particular fix I suggested has issues but the overall problem exists and should be dealt with more sensibly. > change the name at all? Extcon is much more specific than "switch." > A switch can can be used for more than just external connections such > as availability of HMDI audio (which is only available once a HDMI > mode is chosen and the interface is enabled.) I don't know myself, it was called extcon when first proposed for mainline. Renaming does have the advantage of indicating to userspace that this is the mainline, reviewed version and that things might be a bit different as a result of that review. Things like the HDMI audio example you cite do seem close enough to the term to still be useful, they're related to an external connection and it's state. If you were really worrying about it you might expect HDMI audio to be reported via something like the ALSA APIs rather than a totally unrelated ABI like this.
On Fri, Mar 30, 2012 at 05:56:01PM +0900, MyungJoo Ham wrote: > With class_compat as in patchset v7, (this thread is w/ v6) does the > issue (missing link from device name directory) still exist? (I don't > think so) Not unless the uevents are issued with both names.
On Fri, Mar 30, 2012 at 3:07 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Thu, Mar 29, 2012 at 03:27:01PM -0700, Erik Gilling wrote: >> On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown > >> > This seems somewhat sad - if ANDROID is turned on the standard ABI >> > vanishes. It'd be much nicer to do this with a symlink (or with >> > symlinks within the android directory if the driver core doesn't support >> > that). That way userspace code can be written to the new ABI and will >> > work on Android systems without ifdefery. > >> This won't work if userspace code is receiving uevents through netlink >> and comparing based on the device name which it does in android. Why > > That's not really the point here - the point is that the new ABI > vanishes as soon as you turn on the legacy Android ABI. You're right > that the particular fix I suggested has issues but the overall problem > exists and should be dealt with more sensibly. I'm also not in favor of having functionality conditionally compiled based on CONFIG_ANDROID. If fact, going through the patch stack there's much more that changes the ABI from the switch driver than just the name. Android asumes that there is a single "switch" for each logical entity (called cable types in extcon) each with a binary state (0,1). Here things have changed to have a single extcon instance that can have a bitmask of states which are sent as strings in the uevent. As it stands, this patch does not solve the cases where we use switch today and we'll probably continue to carry the switch driver in the common android tree. If, instead, we got rid of the idea of multiple states and mutual exclusivity and relied on the driver that uses extcon to have multiple instances for each logical entity and deal with mutual exclusion itself, we'd have a driver that would be pretty easy to support in android. -Erik
On Fri, Mar 30, 2012 at 10:29 AM, Erik Gilling <konkers@google.com> wrote: > On Fri, Mar 30, 2012 at 3:07 AM, Mark Brown > <broonie@opensource.wolfsonmicro.com> wrote: >> On Thu, Mar 29, 2012 at 03:27:01PM -0700, Erik Gilling wrote: >>> On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown >> >>> > This seems somewhat sad - if ANDROID is turned on the standard ABI >>> > vanishes. It'd be much nicer to do this with a symlink (or with >>> > symlinks within the android directory if the driver core doesn't support >>> > that). That way userspace code can be written to the new ABI and will >>> > work on Android systems without ifdefery. >> >>> This won't work if userspace code is receiving uevents through netlink >>> and comparing based on the device name which it does in android. Why >> >> That's not really the point here - the point is that the new ABI >> vanishes as soon as you turn on the legacy Android ABI. You're right >> that the particular fix I suggested has issues but the overall problem >> exists and should be dealt with more sensibly. > > I'm also not in favor of having functionality conditionally compiled > based on CONFIG_ANDROID. If fact, going through the patch stack > there's much more that changes the ABI from the switch driver than > just the name. Android asumes that there is a single "switch" for > each logical entity (called cable types in extcon) each with a binary > state (0,1). Here things have changed to have a single extcon > instance that can have a bitmask of states which are sent as strings > in the uevent. In addition to all this added complexity, the fact that you now have to white-list the possible "cable types" is also undesirable. If I wanted to expose a new cable type, I now have to modify the extcon.h file and the extcon.c file and I don't see what that white-list buys me. The class device itself should not care for which cable types can be registered, nor how they relate to each other. Let the client drivers decide, just enforce uniqueness. --Dima > > As it stands, this patch does not solve the cases where we use switch > today and we'll probably continue to carry the switch driver in the > common android tree. If, instead, we got rid of the idea of multiple > states and mutual exclusivity and relied on the driver that uses > extcon to have multiple instances for each logical entity and deal > with mutual exclusion itself, we'd have a driver that would be pretty > easy to support in android. > > -Erik
On Fri, Mar 30, 2012 at 10:29:27AM -0700, Erik Gilling wrote: > I'm also not in favor of having functionality conditionally compiled > based on CONFIG_ANDROID. If fact, going through the patch stack > there's much more that changes the ABI from the switch driver than > just the name. Android asumes that there is a single "switch" for > each logical entity (called cable types in extcon) each with a binary > state (0,1). Here things have changed to have a single extcon > instance that can have a bitmask of states which are sent as strings > in the uevent. The binary status thing isn't true for the original Android switch API, at least not in all cases - for headsets it's a tristate indicating if there's nothing, a headphone or headset plugged in. This does wind up being a bitmask because the numbers are 0, 1 and 2 but it isn't really clear to me if this is intentional or just an effect of counting. > As it stands, this patch does not solve the cases where we use switch > today and we'll probably continue to carry the switch driver in the > common android tree. If, instead, we got rid of the idea of multiple > states and mutual exclusivity and relied on the driver that uses > extcon to have multiple instances for each logical entity and deal > with mutual exclusion itself, we'd have a driver that would be pretty > easy to support in android. What's the advantage in not having information about mutual exclusion in the core, and why would a userspace that isn't interested in this care? It seems like this could be used by userspace to do interesting things, and I rather suspect you'll find some vendors have added features along those lines in their Android devices. For example, having different configurations for desk docks and car docks even if both end up connecting the same things up. Even if the userspace ABI doesn't expose the information it seems sensible to factor out the code for handling this into the core so there's less work to do in individual drivers.
On Sat, Mar 31, 2012 at 2:38 AM, Dima Zavin <dima@android.com> wrote: > On Fri, Mar 30, 2012 at 10:29 AM, Erik Gilling <konkers@google.com> wrote: >> On Fri, Mar 30, 2012 at 3:07 AM, Mark Brown >> <broonie@opensource.wolfsonmicro.com> wrote: >>> On Thu, Mar 29, 2012 at 03:27:01PM -0700, Erik Gilling wrote: >>>> On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown >>> >>>> > This seems somewhat sad - if ANDROID is turned on the standard ABI >>>> > vanishes. It'd be much nicer to do this with a symlink (or with >>>> > symlinks within the android directory if the driver core doesn't support >>>> > that). That way userspace code can be written to the new ABI and will >>>> > work on Android systems without ifdefery. >>> >>>> This won't work if userspace code is receiving uevents through netlink >>>> and comparing based on the device name which it does in android. Why >>> >>> That's not really the point here - the point is that the new ABI >>> vanishes as soon as you turn on the legacy Android ABI. You're right >>> that the particular fix I suggested has issues but the overall problem >>> exists and should be dealt with more sensibly. >> >> I'm also not in favor of having functionality conditionally compiled >> based on CONFIG_ANDROID. If fact, going through the patch stack >> there's much more that changes the ABI from the switch driver than >> just the name. Android asumes that there is a single "switch" for >> each logical entity (called cable types in extcon) each with a binary >> state (0,1). Here things have changed to have a single extcon >> instance that can have a bitmask of states which are sent as strings >> in the uevent. > > In addition to all this added complexity, the fact that you now have > to white-list the possible "cable types" is also undesirable. If I > wanted to expose a new cable type, I now have to modify the extcon.h > file and the extcon.c file and I don't see what that white-list buys > me. The class device itself should not care for which cable types can > be registered, nor how they relate to each other. Let the client > drivers decide, just enforce uniqueness. > > --Dima They are not a white-list that shows the possible cable types. It is a suggestion so that different device drivers may use the same cable names for common cable types. Any device drivers can still use their own "new" names without any modifications to extcon_class.c./extcon.h. Especially as long as they are "new", "rare", or "uncommon" cable types, the device drivers should be able to use their own created names. Cheers! MyungJoo. > >> >> As it stands, this patch does not solve the cases where we use switch >> today and we'll probably continue to carry the switch driver in the >> common android tree. If, instead, we got rid of the idea of multiple >> states and mutual exclusivity and relied on the driver that uses >> extcon to have multiple instances for each logical entity and deal >> with mutual exclusion itself, we'd have a driver that would be pretty >> easy to support in android. >> >> -Erik
diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon new file mode 100644 index 0000000..59a4b1c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-extcon @@ -0,0 +1,26 @@ +What: /sys/class/extcon/.../ +Date: December 2011 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + Provide a place in sysfs for the extcon objects. + This allows accessing extcon specific variables. + The name of extcon object denoted as ... is the name given + with extcon_dev_register. + +What: /sys/class/extcon/.../name +Date: December 2011 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../name shows the name of the extcon + object. If the extcon object has an optional callback + "show_name" defined, the callback will provide the name with + this sysfs node. + +What: /sys/class/extcon/.../state +Date: December 2011 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../state shows the cable attach/detach + information of the corresponding extcon object. If the extcon + objecct has an optional callback "show_state" defined, the + callback will provide the name with this sysfs node. diff --git a/drivers/Kconfig b/drivers/Kconfig index 5afe5d1..537d126 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -136,4 +136,6 @@ source "drivers/virt/Kconfig" source "drivers/devfreq/Kconfig" +source "drivers/extcon/Kconfig" + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index c07be02..6faceab 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -132,3 +132,4 @@ obj-$(CONFIG_VIRT_DRIVERS) += virt/ obj-$(CONFIG_HYPERV) += hv/ obj-$(CONFIG_PM_DEVFREQ) += devfreq/ +obj-$(CONFIG_EXTCON) += extcon/ diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig new file mode 100644 index 0000000..11db865 --- /dev/null +++ b/drivers/extcon/Kconfig @@ -0,0 +1,28 @@ +menuconfig EXTCON + tristate "External Connector Class (extcon) support" + help + Say Y here to enable external connector class (extcon) support. + This allows monitoring external connectors by userspace + via sysfs and uevent and supports external connectors with + multiple states; i.e., an extcon that may have multiple + cables attached. For example, an external connector of a device + may be used to connect an HDMI cable and a AC adaptor, and to + host USB ports. Many of 30-pin connectors including PDMI are + also good examples. + +if EXTCON + +comment "Extcon Class Configuration" + +config EXTCON_ANDROID_COMPATIBLE + bool "Class name uses 'switch' to be compatible with Android kernel" + depends on ANDROID + help + The class name of extcon device drivers are set 'switch' in order + to be compatible with Android kernel switch framework. With this + option enabled, Android userspace platform may use extcon device + drivers as if they are switch device drivers. + +comment "Extcon Device Drivers" + +endif # MULTISTATE_SWITCH diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile new file mode 100644 index 0000000..6bc6921 --- /dev/null +++ b/drivers/extcon/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for external connector class (extcon) devices +# + +obj-$(CONFIG_EXTCON) += extcon_class.o diff --git a/drivers/extcon/extcon_class.c b/drivers/extcon/extcon_class.c new file mode 100644 index 0000000..9bc062b --- /dev/null +++ b/drivers/extcon/extcon_class.c @@ -0,0 +1,226 @@ +/* + * drivers/extcon/extcon_class.c + * + * External connector (extcon) class driver + * + * Copyright (C) 2012 Samsung Electronics + * Author: Donggeun Kim <dg77.kim@samsung.com> + * Author: MyungJoo Ham <myungjoo.ham@samsung.com> + * + * based on android/drivers/switch/switch_class.c + * Copyright (C) 2008 Google, Inc. + * Author: Mike Lockwood <lockwood@android.com> + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * +*/ + +#include <linux/module.h> +#include <linux/types.h> +#include <linux/init.h> +#include <linux/device.h> +#include <linux/fs.h> +#include <linux/err.h> +#include <linux/extcon.h> +#include <linux/slab.h> + +struct class *extcon_class; + +static ssize_t state_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev); + + if (edev->print_state) { + int ret = edev->print_state(edev, buf); + + if (ret >= 0) + return ret; + /* Use default if failed */ + } + return sprintf(buf, "%u\n", edev->state); +} + +static ssize_t name_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev); + + /* Optional callback given by the user */ + if (edev->print_name) { + int ret = edev->print_name(edev, buf); + if (ret >= 0) + return ret; + } + + return sprintf(buf, "%s\n", dev_name(edev->dev)); +} + +/** + * extcon_set_state() - Set the cable attach states of the extcon device. + * @edev: the extcon device + * @state: new cable attach status for @edev + * + * Changing the state sends uevent with environment variable containing + * the name of extcon device (envp[0]) and the state output (envp[1]). + * Tizen uses this format for extcon device to get events from ports. + * Android uses this format as well. + */ +void extcon_set_state(struct extcon_dev *edev, u32 state) +{ + char name_buf[120]; + char state_buf[120]; + char *prop_buf; + char *envp[3]; + int env_offset = 0; + int length; + + if (edev->state != state) { + edev->state = state; + + prop_buf = (char *)get_zeroed_page(GFP_KERNEL); + if (prop_buf) { + length = name_show(edev->dev, NULL, prop_buf); + if (length > 0) { + if (prop_buf[length - 1] == '\n') + prop_buf[length - 1] = 0; + snprintf(name_buf, sizeof(name_buf), + "SWITCH_NAME=%s", prop_buf); + envp[env_offset++] = name_buf; + } + length = state_show(edev->dev, NULL, prop_buf); + if (length > 0) { + if (prop_buf[length - 1] == '\n') + prop_buf[length - 1] = 0; + snprintf(state_buf, sizeof(state_buf), + "SWITCH_STATE=%s", prop_buf); + envp[env_offset++] = state_buf; + } + envp[env_offset] = NULL; + kobject_uevent_env(&edev->dev->kobj, KOBJ_CHANGE, envp); + free_page((unsigned long)prop_buf); + } else { + dev_err(edev->dev, "out of memory in extcon_set_state\n"); + kobject_uevent(&edev->dev->kobj, KOBJ_CHANGE); + } + } +} +EXPORT_SYMBOL_GPL(extcon_set_state); + +static struct device_attribute extcon_attrs[] = { + __ATTR_RO(state), + __ATTR_RO(name), +}; + +static int create_extcon_class(void) +{ + if (!extcon_class) { +#ifdef CONFIG_ANDROID + extcon_class = class_create(THIS_MODULE, "switch"); +#else /* !CONFIG_ANDROID */ + extcon_class = class_create(THIS_MODULE, "extcon"); +#endif /* CONFIG_ANDROID */ + if (IS_ERR(extcon_class)) + return PTR_ERR(extcon_class); + extcon_class->dev_attrs = extcon_attrs; + } + + return 0; +} + +static void extcon_cleanup(struct extcon_dev *edev, bool skip) +{ + if (!skip && get_device(edev->dev)) { + device_unregister(edev->dev); + put_device(edev->dev); + } + + kfree(edev->dev); +} + +static void extcon_dev_release(struct device *dev) +{ + struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev); + + extcon_cleanup(edev, true); +} + +/** + * extcon_dev_register() - Register a new extcon device + * @edev : the new extcon device (should be allocated before calling) + * @dev : the parent device for this extcon device. + * + * Among the members of edev struct, please set the "user initializing data" + * in any case and set the "optional callbacks" if required. However, please + * do not set the values of "internal data", which are initialized by + * this function. + */ +int extcon_dev_register(struct extcon_dev *edev, struct device *dev) +{ + int ret; + + if (!extcon_class) { + ret = create_extcon_class(); + if (ret < 0) + return ret; + } + + edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL); + edev->dev->parent = dev; + edev->dev->class = extcon_class; + edev->dev->release = extcon_dev_release; + + dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev)); + ret = device_register(edev->dev); + if (ret) { + put_device(edev->dev); + goto err_dev; + } + + dev_set_drvdata(edev->dev, edev); + edev->state = 0; + return 0; + +err_dev: + kfree(edev->dev); + return ret; +} +EXPORT_SYMBOL_GPL(extcon_dev_register); + +/** + * extcon_dev_unregister() - Unregister the extcon device. + * @edev: the extcon device instance to be unregitered. + * + * Note that this does not call kfree(edev) because edev was not allocated + * by this class. + */ +void extcon_dev_unregister(struct extcon_dev *edev) +{ + extcon_cleanup(edev, false); +} +EXPORT_SYMBOL_GPL(extcon_dev_unregister); + +static int __init extcon_class_init(void) +{ + return create_extcon_class(); +} +module_init(extcon_class_init); + +static void __exit extcon_class_exit(void) +{ + class_destroy(extcon_class); +} +module_exit(extcon_class_exit); + +MODULE_AUTHOR("Mike Lockwood <lockwood@android.com>"); +MODULE_AUTHOR("Donggeun Kim <dg77.kim@samsung.com>"); +MODULE_AUTHOR("MyungJoo Ham <myungjoo.ham@samsung.com>"); +MODULE_DESCRIPTION("External connector (extcon) class driver"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/extcon.h b/include/linux/extcon.h new file mode 100644 index 0000000..cd732ab --- /dev/null +++ b/include/linux/extcon.h @@ -0,0 +1,82 @@ +/* + * External connector (extcon) class driver + * + * Copyright (C) 2012 Samsung Electronics + * Author: Donggeun Kim <dg77.kim@samsung.com> + * Author: MyungJoo Ham <myungjoo.ham@samsung.com> + * + * based on switch class driver + * Copyright (C) 2008 Google, Inc. + * Author: Mike Lockwood <lockwood@android.com> + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * +*/ + +#ifndef __LINUX_EXTCON_H__ +#define __LINUX_EXTCON_H__ + +/** + * struct extcon_dev - An extcon device represents one external connector. + * @name The name of this extcon device. Parent device name is used + * if NULL. + * @print_name An optional callback to override the method to print the + * name of the extcon device. + * @print_state An optional callback to override the method to print the + * status of the extcon device. + * @dev Device of this extcon. Do not provide at register-time. + * @state Attach/detach state of this extcon. Do not provide at + * register-time + * + * In most cases, users only need to provide "User initializing data" of + * this struct when registering an extcon. In some exceptional cases, + * optional callbacks may be needed. However, the values in "internal data" + * are overwritten by register function. + */ +struct extcon_dev { + /* --- Optional user initializing data --- */ + const char *name; + + /* --- Optional callbacks to override class functions --- */ + ssize_t (*print_name)(struct extcon_dev *edev, char *buf); + ssize_t (*print_state)(struct extcon_dev *edev, char *buf); + + /* --- Internal data. Please do not set. --- */ + struct device *dev; + u32 state; +}; + +#ifdef CONFIG_EXTCON +extern int extcon_dev_register(struct extcon_dev *edev, struct device *dev); +extern void extcon_dev_unregister(struct extcon_dev *edev); + +static inline u32 extcon_get_state(struct extcon_dev *edev) +{ + return edev->state; +} + +extern void extcon_set_state(struct extcon_dev *edev, u32 state); +#else /* CONFIG_EXTCON */ +static inline int extcon_dev_register(struct extcon_dev *edev, + struct device *dev) +{ + return 0; +} + +static inline void extcon_dev_unregister(struct extcon_dev *edev) { } + +static inline u32 extcon_get_state(struct extcon_dev *edev) +{ + return 0; +} + +static inline void extcon_set_state(struct extcon_dev *edev, u32 state) { } +#endif /* CONFIG_EXTCON */ +#endif /* __LINUX_EXTCON_H__ */