From: Yin Kangkai <kangkai.yin@linux.intel.com>
To: Corentin Chary <corentin.chary@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, "Wang,
Yong Y" <yong.y.wang@intel.com>,
"Liu, Bing Wei" <bing.wei.liu@intel.com>
Subject: Re: [PATCH] platform-driver-x86: ACPI EC Extra driver for Oaktrail
Date: Thu, 6 Jan 2011 18:11:06 +0800 [thread overview]
Message-ID: <20110106101106.GE30215@kai-debian> (raw)
In-Reply-To: <AANLkTi=B1XeBTogjVPWqOSFgJMD72gTpNZgg4znAR0t3@mail.gmail.com>
On 2011-01-06, 08:29 +0100, Corentin Chary wrote:
> Hi,
Thanks for the review and comments.
> > @@ -0,0 +1,349 @@
> > +/*-*-linux-c-*-*/
>
> I don't know what's our general policy about that, but I don't think
> each text editor should be allowed to add its own header on each
> files. Most of the time you can configure your editor to set the
> right indent style based on the path of the file or something like that.
Yes, I agree with you, will remove that.
> > + * gps - GPS subsystem enabled: contains either 0 or 1. (rw)
> > + * wifi - WiFi subsystem enabled: contains either 0 or 1. (rw)
> > + * wwan - WWAN (3G) subsystem enabled: contains either 0 or 1. (rw)
>
> Is there a reason do add these files in /sys/devices/platform while the
> functionality is already provided by rfkill ?
Provide a alternative way to enable/disable these devices, and also
for debugging. Does that make any sense?
> > + * camera - Camera subsystem enabled: contains either 0 or 1. (rw)
> > + * bluetooth - Bluetooth subsystem enabled: contains either 0 or 1. (rw)
> > + * touchscreen - Touchscreen subsystem enabled: contains either 0 or 1. (ro)
>
> This should be in Documentation/ABI/testing/
Should I prepare the document now and submit also?
> > +
> > +static struct platform_device *oaktrail_device;
> > +static struct rfkill *bt_rfkill;
> > +static struct rfkill *gps_rfkill;
> > +static struct rfkill *wifi_rfkill;
> > +static struct rfkill *wwan_rfkill;
>
> Here you could create two (four ?) helpers that contains the logic,
> and craft dummy functions which only call the helpers with the right
> parameters in your macros.
>
> These helpers could also be used by later functions.
>
I will try to define some micros..
> > +static int setup_rfkill(void)
>
> oaktrail_rfkill_init() ?
Sure.
> > + rfkill_destroy(wwan_rfkill);
> > +err_allocate_wwan:
> > + rfkill_unregister(gps_rfkill);
> > +err_register_gps:
> > + rfkill_destroy(gps_rfkill);
> > +err_allocate_gps:
> > + rfkill_unregister(bt_rfkill);
> > +err_register_bt:
> > + rfkill_destroy(bt_rfkill);
> > +err_allocate_bt:
> > + rfkill_unregister(wifi_rfkill);
> > +err_register_wifi:
> > + rfkill_destroy(wifi_rfkill);
> > +
> > + return ret;
> > +}
>
> Here I'd write an helper function to call rfkill_alloc,
> rfkill_register and handle
> rfkill_register failure. And then, if any of the helper calls fail, just call
> oaktrail_rfkill_exit (which which rfkill if the rfkill pointer is NULL or not).
>
> oaktrail_rfkill_exit could also be used in the module exit function.
Yes, will try to do that.
> > +static int __devinit oaktrail_probe(struct platform_device *pdev)
> > +{
> > + int err;
> > +
> > + err = sysfs_create_group(&pdev->dev.kobj, &oaktrail_attribute_group);
> > + return err;
> > +}
>
> return sysfs_create_group(&pdev->dev.kobj, &oaktrail_attribute_group);
>
> we don't really need err right now, do we ?
Will change this.
> > +MODULE_AUTHOR("Yin Kangkai (kangkai.yin@intel.com)");
> > +MODULE_DESCRIPTION("Intel Oaktrail Platform ACPI Extras");
> > +MODULE_VERSION(DRIVER_VERSION);
> > +MODULE_LICENSE("GPL");
>
> Maybe you could add some MODULE_ALIAS("dmi:xxxxx") lines
> to enable module autoloading ?
Will try to.
Thanks for the review.
Regards,
Kangkai
next prev parent reply other threads:[~2011-01-06 10:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 2:59 [PATCH] platform-driver-x86: ACPI EC Extra driver for Oaktrail Yin Kangkai
2011-01-06 2:59 ` Yin Kangkai
2011-01-06 7:29 ` Corentin Chary
2011-01-06 10:11 ` Yin Kangkai [this message]
2011-01-06 10:21 ` Corentin Chary
2011-01-06 10:50 ` Yin Kangkai
2011-01-06 10:54 ` Corentin Chary
2011-01-06 11:32 ` Joey Lee
2011-01-06 11:32 ` Joey Lee
2011-01-06 11:35 ` Joey Lee
2011-01-06 11:35 ` Joey Lee
2011-01-07 0:01 ` Yin Kangkai
2011-01-07 7:41 ` [PATCH V2] " Yin Kangkai
2011-01-07 7:41 ` Yin Kangkai
2011-01-07 8:56 ` Corentin Chary
2011-01-07 11:24 ` Yin Kangkai
2011-01-10 6:57 ` Yin Kangkai
2011-01-07 22:09 ` Matthew Garrett
2011-01-10 7:10 ` Yin Kangkai
2011-01-10 9:16 ` Thomas Renninger
2011-01-10 7:15 ` [PATCH V3] platform-driver-x86: " Yin Kangkai
2011-01-10 7:15 ` Yin Kangkai
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=20110106101106.GE30215@kai-debian \
--to=kangkai.yin@linux.intel.com \
--cc=bing.wei.liu@intel.com \
--cc=corentin.chary@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=yong.y.wang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.