From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: linux-kernel@vger.kernel.org, NeilBrown <neilb@suse.de>,
"Randy Dunlap" <rdunlap@xenotime.net>,
"Mike Lockwood" <lockwood@android.com>,
"Arve Hjønnevag" <arve@android.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Donggeun Kim" <dg77.kim@samsung.com>, "Greg KH" <gregkh@suse.de>,
"Arnd Bergmann" <arnd@arndb.de>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Morten CHRISTIANSEN" <morten.christiansen@stericsson.com>,
"John Stultz" <john.stultz@linaro.org>,
"Joerg Roedel" <joerg.roedel@amd.com>,
myungjoo.ham@gmail.com
Subject: Re: [PATCH v5 1/5] Extcon (external connector): import Android's switch class and modify.
Date: Sun, 19 Feb 2012 17:54:02 -0800 [thread overview]
Message-ID: <20120220015400.GD3194@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1328856038-21912-2-git-send-email-myungjoo.ham@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]
On Fri, Feb 10, 2012 at 03:40:34PM +0900, MyungJoo Ham wrote:
> External connector class (extcon) is based on and an extension of Android
> kernel's switch class located at linux/drivers/switch/.
This looks good though I've skipped some bits as it's taken me far too
long to get round to reviewing, it'd be really good if we could get it
into 3.4 at least in staging if not in fully. I don't know if arm-soc
might be a good route if there's some concerns? A few things below but
they're relatively minor.
One thing I'd suggest is splitting the GPIO implementation into a
separate patch, mostly just to reduce the size of the initial patch for
ease of review.
> + if (edev->state != state) {
> + edev->state = state;
> +
> + prop_buf = (char *)get_zeroed_page(GFP_KERNEL);
> + if (prop_buf) {
Is the cast really needed here?
> +static int create_extcon_class(void)
> +{
> + if (!extcon_class) {
> + extcon_class = class_create(THIS_MODULE, "extcon");
> + if (IS_ERR(extcon_class))
> + return PTR_ERR(extcon_class);
> + extcon_class->dev_attrs = extcon_attrs;
I thought we were trying to remove classes, though I'm not sure if we're
actually at the point where that's happening yet? Greg?
> +static int create_extcon_class_for_android(void)
> +{
> + if (!extcon_class_for_android) {
> + extcon_class_for_android = class_create(THIS_MODULE, "switch");
> + if (IS_ERR(extcon_class_for_android))
> + return PTR_ERR(extcon_class_for_android);
> + extcon_class_for_android->dev_attrs = extcon_attrs;
> + }
> + return 0;
> +}
Might be better to put this as a separate Kconfig option or just leave
it as an out of tree patch (given how trivial it is). We're going to
end up renaming a bunch of the classes anyway I expect...
> +static int __init extcon_class_init(void)
> +{
> + return create_extcon_class();
> +}
> +
> +static void __exit extcon_class_exit(void)
> +{
> + class_destroy(extcon_class);
> +
> + if (extcon_class_for_android)
> + class_destroy(extcon_class_for_android);
> +}
> +
> +module_init(extcon_class_init);
> +module_exit(extcon_class_exit);
Ideally these should go next to the functions.
> +static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
> +{
> + struct gpio_extcon_data *extcon_data =
> + (struct gpio_extcon_data *)dev_id;
> +
> + schedule_work(&extcon_data->work);
> + return IRQ_HANDLED;
> +}
Given that all this does is schedule some work it'd seem useful to make
this a threaded IRQ and just do the work directly in the interrupt
handler. Though on the other hand we don't have any debounce here so
perhaps it's even better to allow the user to specify a debunce time in
the platform data and change this to schedule_delayed_work() to
implement it?
> +static ssize_t extcon_gpio_print_state(struct extcon_dev *edev, char *buf)
> +{
> + struct gpio_extcon_data *extcon_data =
> + container_of(edev, struct gpio_extcon_data, edev);
> + const char *state;
> + if (extcon_get_state(edev))
> + state = extcon_data->state_on;
> + else
> + state = extcon_data->state_off;
> +
> + if (state)
> + return sprintf(buf, "%s\n", state);
> + return -1;
-EINVAL or something?
> + extcon_data = kzalloc(sizeof(struct gpio_extcon_data), GFP_KERNEL);
> + if (!extcon_data)
> + return -ENOMEM;
devm_kzalloc().
> + ret = request_irq(extcon_data->irq, gpio_irq_handler,
> + IRQF_TRIGGER_LOW, pdev->name, extcon_data);
> + if (ret < 0)
> + goto err_request_irq;
request_any_context_irq() would allow use with any GPIO - sometimes the
GPIOs for accessory detection are on GPIO expanders which need threaded
context and there's nothing in the code that minds. It would also be a
good idea if the user could specify the triggers, lots of circuits need
edge triggers for example.
> +static int __init gpio_extcon_init(void)
> +{
> + return platform_driver_register(&gpio_extcon_driver);
> +}
> +
> +static void __exit gpio_extcon_exit(void)
> +{
> + platform_driver_unregister(&gpio_extcon_driver);
> +}
> +
> +module_init(gpio_extcon_init);
> +module_exit(gpio_extcon_exit);
module_platform_driver().
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-02-20 1:54 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 9:46 [PATCH v3 0/4] introduce External Connector Class (extcon) MyungJoo Ham
2012-01-11 9:46 ` [PATCH v3 1/4] Extcon (external connector): import Android's switch class and modify MyungJoo Ham
2012-01-11 9:46 ` [PATCH v3 2/4] Extcon: support notification based on the state changes MyungJoo Ham
2012-01-11 9:46 ` [PATCH v3 3/4] Extcon: support multiple states at a device MyungJoo Ham
2012-01-11 9:46 ` [PATCH v3 4/4] Extcon: support mutually exclusive relation between cables MyungJoo Ham
2012-01-20 1:01 ` [PATCH v4 0/4] introduce External Connector Class (extcon) MyungJoo Ham
2012-01-20 1:01 ` [PATCH v4 1/4] Extcon (external connector): import Android's switch class and modify MyungJoo Ham
2012-01-20 1:01 ` [PATCH v4 2/4] Extcon: support notification based on the state changes MyungJoo Ham
2012-01-20 1:01 ` [PATCH v4 3/4] Extcon: support multiple states at a device MyungJoo Ham
2012-01-20 1:01 ` [PATCH v4 4/4] Extcon: support mutually exclusive relation between cables MyungJoo Ham
2012-02-10 6:40 ` [PATCH v5 0/5] Introduce External Connector Class (extcon) MyungJoo Ham
2012-02-10 6:40 ` [PATCH v5 1/5] Extcon (external connector): import Android's switch class and modify MyungJoo Ham
2012-02-20 1:54 ` Mark Brown [this message]
2012-02-20 6:17 ` MyungJoo Ham
2012-02-20 15:45 ` Mark Brown
2012-02-10 6:40 ` [PATCH v5 2/5] Extcon: support notification based on the state changes MyungJoo Ham
2012-02-20 2:20 ` Mark Brown
2012-02-10 6:40 ` [PATCH v5 3/5] Extcon: support multiple states at a device MyungJoo Ham
2012-02-20 2:24 ` Mark Brown
2012-02-20 7:02 ` MyungJoo Ham
2012-02-22 10:07 ` Arnd Bergmann
2012-02-10 6:40 ` [PATCH v5 4/5] Extcon: support mutually exclusive relation between cables MyungJoo Ham
2012-02-20 2:27 ` Mark Brown
2012-02-22 8:23 ` MyungJoo Ham
2012-02-22 10:00 ` Arnd Bergmann
2012-02-24 4:56 ` MyungJoo Ham
2012-02-24 12:53 ` Arnd Bergmann
2012-02-27 6:47 ` MyungJoo Ham
2012-02-10 6:40 ` [PATCH v5 5/5] Extcon: adc-jack driver to support 3.5 pi or simliar devices MyungJoo Ham
2012-02-10 16:25 ` Mark Brown
2012-02-14 2:22 ` MyungJoo Ham
2012-02-14 5:58 ` Mark Brown
2012-02-27 12:15 ` [PATCH v6 0/5] Introduce External Connector Class (extcon) MyungJoo Ham
2012-02-27 12:15 ` [PATCH v6 1/5] Extcon (external connector): import Android's switch class and modify MyungJoo Ham
2012-03-09 12:41 ` Mark Brown
2012-03-12 8:06 ` MyungJoo Ham
2012-03-29 22:27 ` Erik Gilling
2012-03-30 8:56 ` MyungJoo Ham
2012-03-30 10:14 ` Mark Brown
2012-03-30 10:07 ` Mark Brown
2012-03-30 17:29 ` Erik Gilling
2012-03-30 17:38 ` Dima Zavin
2012-04-02 5:09 ` MyungJoo Ham
2012-03-31 10:19 ` Mark Brown
2012-02-27 12:15 ` [PATCH v6 2/5] Extcon: support generic GPIO extcon driver MyungJoo Ham
2012-03-29 22:37 ` Stephen Boyd
2012-03-30 8:33 ` MyungJoo Ham
2012-02-27 12:15 ` [PATCH v6 3/5] Extcon: support notification based on the state changes MyungJoo Ham
2012-02-27 12:15 ` [PATCH v6 4/5] Extcon: support multiple states at a device MyungJoo Ham
2012-02-27 12:15 ` [PATCH v6 5/5] Extcon: support mutually exclusive relation between cables MyungJoo Ham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120220015400.GD3194@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=arnd@arndb.de \
--cc=arve@android.com \
--cc=dg77.kim@samsung.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@suse.de \
--cc=joerg.roedel@amd.com \
--cc=john.stultz@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lockwood@android.com \
--cc=morten.christiansen@stericsson.com \
--cc=myungjoo.ham@gmail.com \
--cc=myungjoo.ham@samsung.com \
--cc=neilb@suse.de \
--cc=rdunlap@xenotime.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).