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: 17+ 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 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:35 ` Joey Lee
2011-01-07 0:01 ` Yin Kangkai
2011-01-07 7:41 ` [PATCH V2] " 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox