[PATCH] staging: new asus fan driver
Simple driver to enable control of the fan in ASUS laptops. So far this
has only been tested in ASUS Zenbook Prime UX31A, but according to some
online reference [1], it should work in other models as well.
The implementation is very straight-forward, the only caveat is that the
fan speed needs to be saved after it has been manually changed because
it won't be reported properly until it goes back to 'auto' mode.
[1]
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
Signed-off-by: Felipe Contreras
---
Two incarnations of this code exists [1][2], one that used ACPI methods
directly, and one through WMI. Unfortunately the WMI version needs us to pass
physicall addresses which is not exactly clean, and that's the only reason the
code is proposed for staging.
Most likely this cannot graduate until acpica gets support to receive virtual
addresses.
[1] http://article.gmane.org/gmane.linux.power-management.general/36774
[2] http://article.gmane.org/gmane.linux.kernel/1576463
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile| 1 +
drivers/staging/asus-thermal/Kconfig| 7 ++
drivers/staging/asus-thermal/asus_thermal.c | 166
4 files changed, 176 insertions(+)
create mode 100644 drivers/staging/asus-thermal/Kconfig
create mode 100644 drivers/staging/asus-thermal/asus_thermal.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 3626dbc8..b245af5 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -148,4 +148,6 @@ source "drivers/staging/dgnc/Kconfig"
source "drivers/staging/dgap/Kconfig"
+source "drivers/staging/asus-thermal/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d1b4b80..70e4456 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -66,3 +66,4 @@ obj-$(CONFIG_USB_BTMTK) += btmtk_usb/
obj-$(CONFIG_XILLYBUS) += xillybus/
obj-$(CONFIG_DGNC) += dgnc/
obj-$(CONFIG_DGAP) += dgap/
+obj-$(CONFIG_ASUS_THERMAL) += asus-thermal/
diff --git a/drivers/staging/asus-thermal/Kconfig
b/drivers/staging/asus-thermal/Kconfig
new file mode 100644
index 000..8bf7db4
--- /dev/null
+++ b/drivers/staging/asus-thermal/Kconfig
@@ -0,0 +1,7 @@
+config ASUS_THERMAL
+ tristate "ASUS thermal driver"
+ depends on THERMAL
+ depends on X86
+ help
+ Enables control of the fan in ASUS laptops.
+
diff --git a/drivers/staging/asus-thermal/asus_thermal.c
b/drivers/staging/asus-thermal/asus_thermal.c
new file mode 100644
index 000..a84856e
--- /dev/null
+++ b/drivers/staging/asus-thermal/asus_thermal.c
@@ -0,0 +1,166 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Felipe Contreras ");
+MODULE_DESCRIPTION("ASUS fan driver");
+MODULE_LICENSE("GPL");
+
+#define ASUS_WMI_MGMT_GUID "97845ED0-4E6D-11DE-8A39-0800200C9A66"
+#define ASUS_WMI_METHODID_AGFN 0x4E464741
+#define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFE
+
+static struct thermal_cooling_device *fan;
+static int fan_speed;
+
+struct bios_args {
+ u32 arg0;
+ u32 arg1;
+} __packed;
+
+struct fan_args {
+ u16 mfun;
+ u16 sfun;
+ u16 len;
+ u8 stas;
+ u8 err;
+ u8 fan;
+ u32 speed;
+} __packed;
+
+/*
+ * Copied from [1], where this code belongs.
+ * [1] drivers/platform/x86/asus-wmi.c
+ */
+static int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
+ u32 *retval)
+{
+ struct bios_args args = {
+ .arg0 = arg0,
+ .arg1 = arg1,
+ };
+ struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
+ struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ acpi_status status;
+ union acpi_object *obj;
+ u32 tmp;
+
+ status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1, method_id,
+&input, &output);
+
+ if (ACPI_FAILURE(status))
+ goto exit;
+
+ obj = (union acpi_object *)output.pointer;
+ if (obj && obj->type == ACPI_TYPE_INTEGER)
+ tmp = (u32) obj->integer.value;
+ else
+ tmp = 0;
+
+ if (retval)
+ *retval = tmp;
+
+ kfree(obj);
+
+exit:
+ if (ACPI_FAILURE(status))
+ return -EIO;
+
+ if (tmp == ASUS_WMI_UNSUPPORTED_METHOD)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int fan_speed_helper(int write, int fan, unsigned long *speed)
+{
+ struct fan_args args = {
+ .len = sizeof(args),
+ .mfun = 0x13,
+ .sfun = write ? 0x07 : 0x06,
+ .fan = fan,
+ .speed = write ? *speed : 0,
+ };
+ int r;
+ u32 value;
+
+ if (!write && fan_speed >= 0) {
+ *speed = f
[RESEND PATCH 2/2] staging/olpc_docn: reorder the lock sequence to avoid potential dead lock
The lock sequence of dcon_blank_fb(fb_info->lock ---> console_lock) is against
with the one of console_callback(console_lock ---> fb_info->lock), it'll
lead to a potential dead lock, so reorder the lock sequence of dcon_blank_fb
to avoid the potential dead lock.
Signed-off-by: Gu Zheng
---
drivers/staging/olpc_dcon/olpc_dcon.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 198595e..9db88d9 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -255,17 +255,19 @@ static bool dcon_blank_fb(struct dcon_priv *dcon, bool
blank)
{
int err;
+ console_lock();
if (!lock_fb_info(dcon->fbinfo)) {
+ console_unlock();
dev_err(&dcon->client->dev, "unable to lock framebuffer\n");
return false;
}
- console_lock();
+
dcon->ignore_fb_events = true;
err = fb_blank(dcon->fbinfo,
blank ? FB_BLANK_POWERDOWN : FB_BLANK_UNBLANK);
dcon->ignore_fb_events = false;
- console_unlock();
unlock_fb_info(dcon->fbinfo);
+ console_unlock();
if (err) {
dev_err(&dcon->client->dev, "couldn't %sblank framebuffer\n",
--
1.7.7
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
FROM MISSIONARY KAYTRINA KRIVANEC: READ AND GET BACK TO ME, SO WE CAN USE MY MONEY TO HELP THE POOR
My Very good friend Do you know that we can make a difference by helping the less privilege and the poor. Psalm 41:1, Blessed is he that considereth the poor,the lord will deliver him in time of trouble. I want you to use my money to help the poor as i am already suffering from a very serious illness Please contact me immediately via e-mail : kaytkriva...@yahoo.com Mrs Kaytrina Krivanec ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH 2/2] staging/olpc_docn: reorder the lock sequence to avoid potential dead lock
On Tue, Nov 05, 2013 at 06:01:00PM +0800, Gu Zheng wrote: > The lock sequence of dcon_blank_fb(fb_info->lock ---> console_lock) is against > with the one of console_callback(console_lock ---> fb_info->lock), it'll > lead to a potential dead lock, so reorder the lock sequence of dcon_blank_fb > to avoid the potential dead lock. > > Signed-off-by: Gu Zheng Relax, Greg isn't taking new patches for another three weeks because the merge window is open. Also what happened to [PATCH 1/2]? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: > Simple driver to enable control of the fan in ASUS laptops. So far this > has only been tested in ASUS Zenbook Prime UX31A, but according to some > online reference [1], it should work in other models as well. > > The implementation is very straight-forward, the only caveat is that the > fan speed needs to be saved after it has been manually changed because > it won't be reported properly until it goes back to 'auto' mode. > > [1] > http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html > > Signed-off-by: Felipe Contreras > --- > > Two incarnations of this code exists [1][2], one that used ACPI methods > directly, and one through WMI. Unfortunately the WMI version needs us to pass > physicall addresses which is not exactly clean, and that's the only reason the > code is proposed for staging. > > Most likely this cannot graduate until acpica gets support to receive virtual > addresses. When is that going to happen? > > [1] http://article.gmane.org/gmane.linux.power-management.general/36774 > [2] http://article.gmane.org/gmane.linux.kernel/1576463 > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile| 1 + > drivers/staging/asus-thermal/Kconfig| 7 ++ > drivers/staging/asus-thermal/asus_thermal.c | 166 > I need a TODO file for a staging driver listing who is responsible for it, and what is needed to be done to it in order to get it out of staging. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: new asus fan driver
Simple driver to enable control of the fan in ASUS laptops. So far this
has only been tested in ASUS Zenbook Prime UX31A, but according to some
online reference [1], it should work in other models as well.
The implementation is very straight-forward, the only caveat is that the
fan speed needs to be saved after it has been manually changed because
it won't be reported properly until it goes back to 'auto' mode.
[1]
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
Signed-off-by: Felipe Contreras
---
Changes since v1:
* Added a missing TODO file
* Added missing Makefile
Two incarnations of this code exists [1][2], one that used ACPI methods
directly, and one through WMI. Unfortunately the WMI version needs us to pass
physicall addresses which is not exactly clean, and that's the only reason the
code is proposed for staging.
Most likely this cannot graduate until acpica gets support to receive virtual
addresses.
[1] http://article.gmane.org/gmane.linux.power-management.general/36774
[2] http://article.gmane.org/gmane.linux.kernel/1576463
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile| 1 +
drivers/staging/asus-thermal/Kconfig| 7 ++
drivers/staging/asus-thermal/Makefile | 1 +
drivers/staging/asus-thermal/TODO | 5 +
drivers/staging/asus-thermal/asus_thermal.c | 166
6 files changed, 182 insertions(+)
create mode 100644 drivers/staging/asus-thermal/Kconfig
create mode 100644 drivers/staging/asus-thermal/Makefile
create mode 100644 drivers/staging/asus-thermal/TODO
create mode 100644 drivers/staging/asus-thermal/asus_thermal.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 3626dbc8..b245af5 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -148,4 +148,6 @@ source "drivers/staging/dgnc/Kconfig"
source "drivers/staging/dgap/Kconfig"
+source "drivers/staging/asus-thermal/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d1b4b80..70e4456 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -66,3 +66,4 @@ obj-$(CONFIG_USB_BTMTK) += btmtk_usb/
obj-$(CONFIG_XILLYBUS) += xillybus/
obj-$(CONFIG_DGNC) += dgnc/
obj-$(CONFIG_DGAP) += dgap/
+obj-$(CONFIG_ASUS_THERMAL) += asus-thermal/
diff --git a/drivers/staging/asus-thermal/Kconfig
b/drivers/staging/asus-thermal/Kconfig
new file mode 100644
index 000..8bf7db4
--- /dev/null
+++ b/drivers/staging/asus-thermal/Kconfig
@@ -0,0 +1,7 @@
+config ASUS_THERMAL
+ tristate "ASUS thermal driver"
+ depends on THERMAL
+ depends on X86
+ help
+ Enables control of the fan in ASUS laptops.
+
diff --git a/drivers/staging/asus-thermal/Makefile
b/drivers/staging/asus-thermal/Makefile
new file mode 100644
index 000..ec05519
--- /dev/null
+++ b/drivers/staging/asus-thermal/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ASUS_THERMAL) += asus_thermal.o
diff --git a/drivers/staging/asus-thermal/TODO
b/drivers/staging/asus-thermal/TODO
new file mode 100644
index 000..cecf435
--- /dev/null
+++ b/drivers/staging/asus-thermal/TODO
@@ -0,0 +1,5 @@
+TODO:
+- Get rid of virt_to_phys()
+
+Please send any patches to Greg Kroah-Hartman ,
+Felipe Contreras
diff --git a/drivers/staging/asus-thermal/asus_thermal.c
b/drivers/staging/asus-thermal/asus_thermal.c
new file mode 100644
index 000..a84856e
--- /dev/null
+++ b/drivers/staging/asus-thermal/asus_thermal.c
@@ -0,0 +1,166 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Felipe Contreras ");
+MODULE_DESCRIPTION("ASUS fan driver");
+MODULE_LICENSE("GPL");
+
+#define ASUS_WMI_MGMT_GUID "97845ED0-4E6D-11DE-8A39-0800200C9A66"
+#define ASUS_WMI_METHODID_AGFN 0x4E464741
+#define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFE
+
+static struct thermal_cooling_device *fan;
+static int fan_speed;
+
+struct bios_args {
+ u32 arg0;
+ u32 arg1;
+} __packed;
+
+struct fan_args {
+ u16 mfun;
+ u16 sfun;
+ u16 len;
+ u8 stas;
+ u8 err;
+ u8 fan;
+ u32 speed;
+} __packed;
+
+/*
+ * Copied from [1], where this code belongs.
+ * [1] drivers/platform/x86/asus-wmi.c
+ */
+static int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
+ u32 *retval)
+{
+ struct bios_args args = {
+ .arg0 = arg0,
+ .arg1 = arg1,
+ };
+ struct acpi_buffer input = { (acpi_size) sizeof(args), &args };
+ struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ acpi_status status;
+ union acpi_object *obj;
+ u32 tmp;
+
+ status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1, method_id,
+&input, &output);
+
+ if (ACPI_FAILURE(status))
+ goto e
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman wrote: > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: >> Simple driver to enable control of the fan in ASUS laptops. So far this >> has only been tested in ASUS Zenbook Prime UX31A, but according to some >> online reference [1], it should work in other models as well. >> >> The implementation is very straight-forward, the only caveat is that the >> fan speed needs to be saved after it has been manually changed because >> it won't be reported properly until it goes back to 'auto' mode. >> >> [1] >> http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html >> >> Signed-off-by: Felipe Contreras >> --- >> >> Two incarnations of this code exists [1][2], one that used ACPI methods >> directly, and one through WMI. Unfortunately the WMI version needs us to pass >> physicall addresses which is not exactly clean, and that's the only reason >> the >> code is proposed for staging. >> >> Most likely this cannot graduate until acpica gets support to receive virtual >> addresses. > > When is that going to happen? I don't know. Presumably when I get it done, which might be never, or a few days from now. Most likely it will take some time. >> [1] http://article.gmane.org/gmane.linux.power-management.general/36774 >> [2] http://article.gmane.org/gmane.linux.kernel/1576463 >> >> drivers/staging/Kconfig | 2 + >> drivers/staging/Makefile| 1 + >> drivers/staging/asus-thermal/Kconfig| 7 ++ >> drivers/staging/asus-thermal/asus_thermal.c | 166 >> > > I need a TODO file for a staging driver listing who is responsible for > it, and what is needed to be done to it in order to get it out of > staging. Done. -- Felipe Contreras ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote: > On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman > wrote: > > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: > >> Simple driver to enable control of the fan in ASUS laptops. So far this > >> has only been tested in ASUS Zenbook Prime UX31A, but according to some > >> online reference [1], it should work in other models as well. > >> > >> The implementation is very straight-forward, the only caveat is that the > >> fan speed needs to be saved after it has been manually changed because > >> it won't be reported properly until it goes back to 'auto' mode. > >> > >> [1] > >> http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html > >> > >> Signed-off-by: Felipe Contreras > >> --- > >> > >> Two incarnations of this code exists [1][2], one that used ACPI methods > >> directly, and one through WMI. Unfortunately the WMI version needs us to > >> pass > >> physicall addresses which is not exactly clean, and that's the only reason > >> the > >> code is proposed for staging. > >> > >> Most likely this cannot graduate until acpica gets support to receive > >> virtual > >> addresses. > > > > When is that going to happen? > > I don't know. Presumably when I get it done, which might be never, or > a few days from now. Most likely it will take some time. Then why not just merge this to the proper place, instead of relying on staging? I don't want to have to have a staging driver that is waiting on external things to get it merged, instead of issues with the driver itself, as you are now putting the burden of maintenance on me, for no good reason other than you being too "lazy" to get other stuff done :) So, I really don't want this driver, sorry, please merge it to the "proper" place in the kernel itself, fixing up the ACPI core to do so, or just living with the driver as-is if you don't want to do that work... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] vme_user: Ensure driver compiles after VME bridges
I'm sorry, this is not a fix. Martyn On 31/10/13 23:47, Aaron Sierra wrote: > If VME bridge and vme_user modules are compiled into the kernel, then > vme_user will attempt to register itself before any VME buses have been > probed. This results in a kernel panic. > > This patch removes the staging VME devices build from the general > staging Makefile and moves the build to the general VME Makefile after > all VME buses are built. > > Signed-off-by: Aaron Sierra > --- > drivers/staging/Makefile |1 - > drivers/vme/Makefile |1 + > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index 415772e..8082bdb 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -27,7 +27,6 @@ obj-$(CONFIG_USB_SERIAL_QUATECH2) += serqt_usb2/ > obj-$(CONFIG_OCTEON_ETHERNET)+= octeon/ > obj-$(CONFIG_VT6655) += vt6655/ > obj-$(CONFIG_VT6656) += vt6656/ > -obj-$(CONFIG_VME_BUS)+= vme/ > obj-$(CONFIG_DX_SEP)+= sep/ > obj-$(CONFIG_IIO)+= iio/ > obj-$(CONFIG_ZRAM) += zram/ > diff --git a/drivers/vme/Makefile b/drivers/vme/Makefile > index d7bfcb9..7a784ab 100644 > --- a/drivers/vme/Makefile > +++ b/drivers/vme/Makefile > @@ -5,3 +5,4 @@ obj-$(CONFIG_VME_BUS) += vme.o > > obj-y+= bridges/ > obj-y+= boards/ > +obj-$(CONFIG_STAGING)+= ../staging/vme/ > -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] vme_user: Update API to work in mixed environments
Greg - I don't have any experience dealing with a mixture of 32-bit user space
and a 64-bit kernel, is this the correct thing to do?
On 31/10/13 23:47, Aaron Sierra wrote:
> This patch updates the vme_master and vme_slave structures to use
> types with well defined size and to prevent the compiler from
> inserting padding (between enable and vme_addr for one).
>
> The original vme_master and vme_slave structs would be different
> sizes and have different layouts depending on whether they were built
> for a 32-bit or 64-bit system.
>
> On x86 it is possible to have a 32-bit userspace and a 64-bit kernel.
> In this type of environment, the userspace and kernel vme_user APIs
> would disagree and prevent ioctls from executing (based on ioctl
> signatures from _IOR and _IOW).
>
> Signed-off-by: Aaron Sierra
> ---
> drivers/staging/vme/devices/vme_user.c |1 +
> drivers/staging/vme/devices/vme_user.h | 26 +-
> 2 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c
> b/drivers/staging/vme/devices/vme_user.c
> index da7f759..e69f0cd 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -147,6 +147,7 @@ static const struct file_operations vme_user_fops = {
> .write = vme_user_write,
> .llseek = vme_user_llseek,
> .unlocked_ioctl = vme_user_unlocked_ioctl,
> + .compat_ioctl = vme_user_unlocked_ioctl,
> };
>
>
> diff --git a/drivers/staging/vme/devices/vme_user.h
> b/drivers/staging/vme/devices/vme_user.h
> index 7d24cd6..6726a42 100644
> --- a/drivers/staging/vme/devices/vme_user.h
> +++ b/drivers/staging/vme/devices/vme_user.h
> @@ -6,13 +6,13 @@
> /*
> * VMEbus Master Window Configuration Structure
> */
> -struct vme_master {
> - int enable; /* State of Window */
> - unsigned long long vme_addr;/* Starting Address on the VMEbus */
> - unsigned long long size;/* Window Size */
> - u32 aspace; /* Address Space */
> - u32 cycle; /* Cycle properties */
> - u32 dwidth; /* Maximum Data Width */
> +struct __attribute__((__packed__)) vme_master {
> + u32 enable; /* State of Window */
> + u64 vme_addr; /* Starting Address on the VMEbus */
> + u64 size; /* Window Size */
> + u32 aspace; /* Address Space */
> + u32 cycle; /* Cycle properties */
> + u32 dwidth; /* Maximum Data Width */
> #if 0
> char prefetchEnable;/* Prefetch Read Enable State */
> int prefetchSize; /* Prefetch Read Size (Cache Lines) */
> @@ -30,12 +30,12 @@ struct vme_master {
>
>
> /* VMEbus Slave Window Configuration Structure */
> -struct vme_slave {
> - int enable; /* State of Window */
> - unsigned long long vme_addr;/* Starting Address on the VMEbus */
> - unsigned long long size;/* Window Size */
> - u32 aspace; /* Address Space */
> - u32 cycle; /* Cycle properties */
> +struct __attribute__((__packed__)) vme_slave {
> + u32 enable; /* State of Window */
> + u64 vme_addr; /* Starting Address on the VMEbus */
> + u64 size; /* Window Size */
> + u32 aspace; /* Address Space */
> + u32 cycle; /* Cycle properties */
> #if 0
> char wrPostEnable; /* Write Post State */
> char rmwLock; /* Lock PCI during RMW Cycles */
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] vme_user: Ensure driver compiles after VME bridges
- Original Message - > From: "Martyn Welch" > > I'm sorry, this is not a fix. > > Martyn Martyn, Can you please elaborate on why you feel it is not a fix? For instance, will this type of solution not be accepted upstream? Is this solution not complete enough? Do you feel that it doesn't resolve any issue? -Aaron > > On 31/10/13 23:47, Aaron Sierra wrote: > > If VME bridge and vme_user modules are compiled into the kernel, then > > vme_user will attempt to register itself before any VME buses have been > > probed. This results in a kernel panic. > > > > This patch removes the staging VME devices build from the general > > staging Makefile and moves the build to the general VME Makefile after > > all VME buses are built. > > > > Signed-off-by: Aaron Sierra > > --- > > drivers/staging/Makefile |1 - > > drivers/vme/Makefile |1 + > > 2 files changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > > index 415772e..8082bdb 100644 > > --- a/drivers/staging/Makefile > > +++ b/drivers/staging/Makefile > > @@ -27,7 +27,6 @@ obj-$(CONFIG_USB_SERIAL_QUATECH2) += serqt_usb2/ > > obj-$(CONFIG_OCTEON_ETHERNET) += octeon/ > > obj-$(CONFIG_VT6655) += vt6655/ > > obj-$(CONFIG_VT6656) += vt6656/ > > -obj-$(CONFIG_VME_BUS) += vme/ > > obj-$(CONFIG_DX_SEP)+= sep/ > > obj-$(CONFIG_IIO) += iio/ > > obj-$(CONFIG_ZRAM) += zram/ > > diff --git a/drivers/vme/Makefile b/drivers/vme/Makefile > > index d7bfcb9..7a784ab 100644 > > --- a/drivers/vme/Makefile > > +++ b/drivers/vme/Makefile > > @@ -5,3 +5,4 @@ obj-$(CONFIG_VME_BUS) += vme.o > > > > obj-y += bridges/ > > obj-y += boards/ > > +obj-$(CONFIG_STAGING) += ../staging/vme/ > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] vme_user: Update API to work in mixed environments
On Tue, Nov 05, 2013 at 05:01:10PM +, Martyn Welch wrote: > Greg - I don't have any experience dealing with a mixture of 32-bit user space > and a 64-bit kernel, is this the correct thing to do? It might be, we need to do something here. I'll review it when I get through my patch queue, hopefully later this week, if not, it will be another week or so, after 3.13-rc1 is out, due to travel... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] vme_user: Ensure driver compiles after VME bridges
On 05/11/13 17:53, Aaron Sierra wrote: > Martyn, > Can you please elaborate on why you feel it is not a fix? For instance, > will this type of solution not be accepted upstream? Is this solution not > complete enough? Do you feel that it doesn't resolve any issue? > > -Aaron The vme_user driver is in the staging tree as it is not in a fit state to incorporate into the main kernel tree. As far as I can see, the below patch just causes the driver to be built at a subtly different time, from a subtly different location (outside of the staging tree). To be honest, I'm not sure how this is fixing anything. Martyn > >> >> On 31/10/13 23:47, Aaron Sierra wrote: >>> If VME bridge and vme_user modules are compiled into the kernel, then >>> vme_user will attempt to register itself before any VME buses have been >>> probed. This results in a kernel panic. >>> >>> This patch removes the staging VME devices build from the general >>> staging Makefile and moves the build to the general VME Makefile after >>> all VME buses are built. >>> >>> Signed-off-by: Aaron Sierra >>> --- >>> drivers/staging/Makefile |1 - >>> drivers/vme/Makefile |1 + >>> 2 files changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile >>> index 415772e..8082bdb 100644 >>> --- a/drivers/staging/Makefile >>> +++ b/drivers/staging/Makefile >>> @@ -27,7 +27,6 @@ obj-$(CONFIG_USB_SERIAL_QUATECH2) += serqt_usb2/ >>> obj-$(CONFIG_OCTEON_ETHERNET) += octeon/ >>> obj-$(CONFIG_VT6655) += vt6655/ >>> obj-$(CONFIG_VT6656) += vt6656/ >>> -obj-$(CONFIG_VME_BUS) += vme/ >>> obj-$(CONFIG_DX_SEP)+= sep/ >>> obj-$(CONFIG_IIO) += iio/ >>> obj-$(CONFIG_ZRAM) += zram/ >>> diff --git a/drivers/vme/Makefile b/drivers/vme/Makefile >>> index d7bfcb9..7a784ab 100644 >>> --- a/drivers/vme/Makefile >>> +++ b/drivers/vme/Makefile >>> @@ -5,3 +5,4 @@ obj-$(CONFIG_VME_BUS) += vme.o >>> >>> obj-y += bridges/ >>> obj-y += boards/ >>> +obj-$(CONFIG_STAGING) += ../staging/vme/ >>> -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 5, 2013 at 9:16 AM, Greg Kroah-Hartman wrote: > On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote: >> On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman >> wrote: >> > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: >> >> Simple driver to enable control of the fan in ASUS laptops. So far this >> >> has only been tested in ASUS Zenbook Prime UX31A, but according to some >> >> online reference [1], it should work in other models as well. >> >> >> >> The implementation is very straight-forward, the only caveat is that the >> >> fan speed needs to be saved after it has been manually changed because >> >> it won't be reported properly until it goes back to 'auto' mode. >> >> >> >> [1] >> >> http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html >> >> >> >> Signed-off-by: Felipe Contreras >> >> --- >> >> >> >> Two incarnations of this code exists [1][2], one that used ACPI methods >> >> directly, and one through WMI. Unfortunately the WMI version needs us to >> >> pass >> >> physicall addresses which is not exactly clean, and that's the only >> >> reason the >> >> code is proposed for staging. >> >> >> >> Most likely this cannot graduate until acpica gets support to receive >> >> virtual >> >> addresses. >> > >> > When is that going to happen? >> >> I don't know. Presumably when I get it done, which might be never, or >> a few days from now. Most likely it will take some time. > > Then why not just merge this to the proper place, instead of relying on > staging? I don't want to have to have a staging driver that is waiting > on external things to get it merged, instead of issues with the driver > itself, as you are now putting the burden of maintenance on me, for no > good reason other than you being too "lazy" to get other stuff done :) *I* am too lazy? I am doing all the work. Nobody else is doing anything about it. Linux is throttling the CPU speed of this machine without trying to to increase the fan speed first, that is not ideal. So I do the first step of writing the fan driver and I get told it shouldn't be a separate driver, it should be part of wmi, only to be told later by the same person that it doesn't belong in wmi when I put it there. Then I get told virt_to_physical() is not good, and it should move to staging, and then I'm told you don't want it. And at no point in time has anybody helped an iota to actually solve the throttling problem. So much for collaborative effort. > So, I really don't want this driver, sorry, please merge it to the > "proper" place in the kernel itself, fixing up the ACPI core to do so, > or just living with the driver as-is if you don't want to do that > work... Forget it, I was hoping other people could use the driver while somebody explains to me how to plug it o the thermal framework so it gets activated when the machine gets hot, but clearly that's not going to happen. I have done my fair share of collaboration. I'll just keep the driver for myself and figure out how to solve the throttling by myself, which apparently I have to do anyway. Cheers. -- Felipe Contreras ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
re: staging: media: Use dev_err() instead of pr_err()
Hello Dulshani Gunawardhana,
The patch 44ee8e801137: "staging: media: Use dev_err() instead of
pr_err()" from Oct 20, 2013, leads to the following
GCC warning:
drivers/staging/media/go7007/go7007-usb.c: In function ‘go7007_usb_probe’:
drivers/staging/media/go7007/go7007-usb.c:1100:13: warning: ‘go’ may be used
uninitialized in this function [-Wuninitialized]
drivers/staging/media/go7007/go7007-usb.c
1049 static int go7007_usb_probe(struct usb_interface *intf,
1050 const struct usb_device_id *id)
1051 {
1052 struct go7007 *go;
1053 struct go7007_usb *usb;
1054 const struct go7007_usb_board *board;
1055 struct usb_device *usbdev = interface_to_usbdev(intf);
1056 unsigned num_i2c_devs;
1057 char *name;
1058 int video_pipe, i, v_urb_len;
1059
1060 dev_dbg(go->dev, "probing new GO7007 USB board\n");
^^^
1061
1062 switch (id->driver_info) {
1063 case GO7007_BOARDID_MATRIX_II:
1064 name = "WIS Matrix II or compatible";
1065 board = &board_matrix_ii;
1066 break;
There are several other uses of "go" before it has been initialized.
Probably you will just want to change these back to pr_info(). Some of
the messages are not very useful like:
dev_info(go->dev, "Sensoray 2250 found\n");
You can delete that one.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] vme_user: Ensure driver compiles after VME bridges
- Original Message - > From: "Martyn Welch" > Subject: Re: [PATCH 1/3] vme_user: Ensure driver compiles after VME bridges > > On 05/11/13 17:53, Aaron Sierra wrote: > > Martyn, > > Can you please elaborate on why you feel it is not a fix? For instance, > > will this type of solution not be accepted upstream? Is this solution not > > complete enough? Do you feel that it doesn't resolve any issue? > > > > -Aaron > > The vme_user driver is in the staging tree as it is not in a fit state to > incorporate into the main kernel tree. As far as I can see, the below patch > just causes the driver to be built at a subtly different time, from a subtly > different location (outside of the staging tree). To be honest, I'm not sure > how this is fixing anything. > > Martyn Martyn, You are correct about the function of this patch, however, I know that it resolves a real problem despite its inconsequential appearance. Using a 3.10.6 kernel, if I compile vme, vme_tsi148, and vme_user as modules, then attempting to insert vme_user into the kernel before the vme subsystem driver has been loaded results in the module failing to load with the following (this is good): vme_user: Unknown symbol vme_master_read (err 0) vme_user: Unknown symbol vme_master_write (err 0) vme_user: Unknown symbol vme_free_consistent (err 0) vme_user: Unknown symbol vme_register_driver (err 0) vme_user: Unknown symbol vme_irq_generate (err 0) vme_user: Unknown symbol vme_alloc_consistent (err 0) vme_user: Unknown symbol vme_slave_request (err 0) vme_user: Unknown symbol vme_master_free (err 0) vme_user: Unknown symbol vme_master_request (err 0) vme_user: Unknown symbol vme_slave_free (err 0) vme_user: Unknown symbol vme_slave_set (err 0) vme_user: Unknown symbol vme_master_get (err 0) vme_user: Unknown symbol vme_slave_get (err 0) vme_user: Unknown symbol vme_master_set (err 0) vme_user: Unknown symbol vme_unregister_driver (err 0) vme_user: Unknown symbol vme_get_size (err 0) This "Unknown symbol" error forces modules to be loaded in this order at the very least; vme -> vme_user. However, when these modules are compiled into the kernel, unfortunate things start to take place. This is the order that the three VME drivers are compiled when using an unpatched kernel: CC drivers/staging/vme/devices/vme_user.o LD drivers/staging/vme/devices/built-in.o LD drivers/staging/vme/built-in.o LD drivers/staging/built-in.o CC drivers/vme/vme.o CC drivers/vme/bridges/vme_tsi148.o LD drivers/vme/bridges/built-in.o LD drivers/vme/built-in.o LD drivers/built-in.o Note that this is not only the order that the drivers are compiled, but also the order that they are initialized. Also notice that since all three drivers are compiled into the kernel, there are no "Unknown symbols" to prevent the vme_user driver from initializing as if the VME bus subsystem has already been initialized. Therefore the following load order occurs; vme_user -> vme -> vme_tsi148. This is the result of the unpatched initialization order: [snip] hidraw: raw HID events driver (C) Jiri Kosina usbcore: registered new interface driver usbhid usbhid: USB HID core driver vme_user: VME User Space Access Driver [ cut here ] kernel BUG at drivers/base/driver.c:169! invalid opcode: [#1] SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.6-xes_r3-00018-g300fcda-dirty #112 Hardware name: Extreme Engineering Solutions, Inc. (X-ES) XCalibur4331/XCalibur4331, BIOS 1-2.21.1 12/10/2012 task: 880232888000 ti: 880232884000 task.ti: 880232884000 RIP: 0010:[] [] driver_register+0x1d/0x106 RSP: :880232885e18 EFLAGS: 00010246 RAX: 8184ef20 RBX: 8184ee68 RCX: 0026 RDX: 0023 RSI: 0020 RDI: 8184ee68 RBP: 880232885e48 R08: 0001 R09: R10: R11: 81d5f420 R12: 8184ee30 R13: R14: R15: 8184eee0 FS: () GS:88023bc8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 0180c000 CR4: 07e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Stack: 0001 818a576d 8184ee30 8184eee0 880232885eb8 813a63aa 880232885eb8 814bc12b 880232885eb8 0028 Call Trace: [] ? staging_init+0x8/0x8 [] vme_register_driver+0x4c/0x23b [] ? printk+0x48/0x4a [] ? staging_init+0x8/0x8 [] vme_user_init+0x23/0x25 [] do_one_initcall+0x7b/0x10c [] kernel_init_freeable+0x101/0x190 [] ? do_early_param+0x86/0x86 [] ? rest_init+0x6f/0x6f usb 1-1: new high-speed USB device number 2 using ehci-pci [] kernel_init+0x9/0xd1 [] ret_from_fork+0x7c/0xb0 [] ?
Re: [PATCH] memstick: rtsx: fix ms card data transfer bug
On Wed, 30 Oct 2013 14:40:16 +0800 wrote: > unlike mspro card, ms card use normal read/write mode for DMA > data transfer. What are the user-visible effects of this bug? Please always include this information when fixing bugs so that others can decide whether they (or their customers) need the patch. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/4] media/solo6x10: Changes on the vb2-dma-sg API
On Fri, 19 Jul 2013 09:58:49 +0200 Ricardo Ribalda Delgado wrote: > The struct vb2_dma_sg_desc has been replaced with the generic sg_table > to describe the location of the video buffers. > > Signed-off-by: Ricardo Ribalda Delgado Acked-by: Ismael Luceno <...> signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Add mx6 hdmi transmitter support
On Tue, Nov 5, 2013 at 9:29 PM, Matt Sealey wrote: > I know about that one. BTW this isn't in the MX6SDL errata > documentation, but it is in the MX6QD errata. If this actually affects > the Solo etc. as Russell dictates, isn't the errata document missing > some info here? If you read the code you will notice that the multiple writes affects only mx6quad. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Add mx6 hdmi transmitter support
On Tue, Nov 5, 2013 at 5:35 PM, Fabio Estevam wrote: > On Tue, Nov 5, 2013 at 9:29 PM, Matt Sealey wrote: > >> I know about that one. BTW this isn't in the MX6SDL errata >> documentation, but it is in the MX6QD errata. If this actually affects >> the Solo etc. as Russell dictates, isn't the errata document missing >> some info here? > > If you read the code you will notice that the multiple writes affects > only mx6quad. I might have missed a patch.. mails are going missing. Who's tree is this in, as actual code with git commits and not a stream of mis-threaded emails? Matt ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] memstick: rtsx: fix ms card data transfer bug
MS card can not use auto read/write mode, so it will fail at initialize and long data transfer. This patch is used to add support for ms card. Shall I re-send this patch to add more info? On 11/06/2013 05:10 AM, Andrew Morton wrote: On Wed, 30 Oct 2013 14:40:16 +0800 wrote: unlike mspro card, ms card use normal read/write mode for DMA data transfer. What are the user-visible effects of this bug? Please always include this information when fixing bugs so that others can decide whether they (or their customers) need the patch. . -- Best Regards Micky. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Add mx6 hdmi transmitter support
On Mon, Nov 4, 2013 at 7:13 PM, Fabio Estevam wrote: > On Mon, Nov 4, 2013 at 9:20 PM, Matt Sealey wrote: > >> Fabio, Shawn, could you go so far as to bring this up with the i.MX >> guys responsible for documentation or find the original transmitter IP >> specs, or find the two pages missing from the manual? This is a really > > The multiple writes comes from the following erratum: > ERR005173 HDMI: Clarification on HDMI programming procedure to avoid > FIFO overflow I know about that one. BTW this isn't in the MX6SDL errata documentation, but it is in the MX6QD errata. If this actually affects the Solo etc. as Russell dictates, isn't the errata document missing some info here? Also the patch doesn't ACTUALLY do what the erratum states you should do - nobody is checking audio FIFO status here before retrying. What I am more curious about is the net effect of every bit in this 8 bit undocumented register which seems to have a major errata around it. I noticed a couple which have very abstract definitions which could mean a couple things regarding packetizing information. What does R_V_BLANK_IN_OSC mean? It's being set when the VIC selected is 39, which makes sense in that there is a magic interlace timing for this VIC if it also exists in the EDID DTDs. However, no check for this is made, it just sets it outright. In fact, it doesn't even make sense since in theory it would not be being told to set the VIC timing, it would be passed the DTD timing, which need to match a very specific set of values, and if they match you need to, instead, fix up the timing used based on the fact that VIC 39 was also listed in the CEA extension block... If you don't follow the CEA-861-E specs or HDMI 1.3a specs *at least* when configuring a mode, and packetizing your infoframes, and the content of those infoframes, then you're going to end up with magenta lines regardless of esoteric audio FIFO underflows. What I don't understand here is how a FIFO underflow in the audio packetizer is causing this magenta line. What you should get is a pop or crackle in the audio (or silence..) or just zero effect on the display if the packetizer can't put valid data in there. There aren't any reasons why a FIFO underflow would somehow change mode timings to cause a magenta line. That said, I got the same thing accidentally enabling audio on a DVI monitor, although this was an SPDIF connection to an external transmitter (not an internal IP block) - even if you didn't enable audio and it was in DVI mode, it caused enough "drag" on the logic to sample audio and be getting nothing over the audio link to put a huge pink line down the side of at least 2 monitors. There doesn't seem to be any audio setup going on in the driver, so I would suggest trying to just force DVI mode and see if the line goes away or gets worse with those different values for retrying, and then forcing HDMI mode.. same test. Matt Sealey ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH 2/2] staging/olpc_docn: reorder the lock sequence to avoid potential dead lock
Hi Dan, On 11/05/2013 07:02 PM, Dan Carpenter wrote: > On Tue, Nov 05, 2013 at 06:01:00PM +0800, Gu Zheng wrote: >> The lock sequence of dcon_blank_fb(fb_info->lock ---> console_lock) is >> against >> with the one of console_callback(console_lock ---> fb_info->lock), it'll >> lead to a potential dead lock, so reorder the lock sequence of dcon_blank_fb >> to avoid the potential dead lock. >> >> Signed-off-by: Gu Zheng > > Relax, Greg isn't taking new patches for another three weeks because the > merge window is open. Got it, I just want to gain some comments about this patch. > > Also what happened to [PATCH 1/2]? It fixes the similar issue of fb subsystem. https://patchwork.kernel.org/patch/3140121/ Regards, Gu > > regards, > dan carpenter > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 05, 2013 at 01:54:51PM -0600, Felipe Contreras wrote: > On Tue, Nov 5, 2013 at 9:16 AM, Greg Kroah-Hartman > wrote: > > On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote: > >> On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman > >> wrote: > >> > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: > >> >> Simple driver to enable control of the fan in ASUS laptops. So far this > >> >> has only been tested in ASUS Zenbook Prime UX31A, but according to some > >> >> online reference [1], it should work in other models as well. > >> >> > >> >> The implementation is very straight-forward, the only caveat is that the > >> >> fan speed needs to be saved after it has been manually changed because > >> >> it won't be reported properly until it goes back to 'auto' mode. > >> >> > >> >> [1] > >> >> http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html > >> >> > >> >> Signed-off-by: Felipe Contreras > >> >> --- > >> >> > >> >> Two incarnations of this code exists [1][2], one that used ACPI methods > >> >> directly, and one through WMI. Unfortunately the WMI version needs us > >> >> to pass > >> >> physicall addresses which is not exactly clean, and that's the only > >> >> reason the > >> >> code is proposed for staging. > >> >> > >> >> Most likely this cannot graduate until acpica gets support to receive > >> >> virtual > >> >> addresses. > >> > > >> > When is that going to happen? > >> > >> I don't know. Presumably when I get it done, which might be never, or > >> a few days from now. Most likely it will take some time. > > > > Then why not just merge this to the proper place, instead of relying on > > staging? I don't want to have to have a staging driver that is waiting > > on external things to get it merged, instead of issues with the driver > > itself, as you are now putting the burden of maintenance on me, for no > > good reason other than you being too "lazy" to get other stuff done :) > > *I* am too lazy? I am doing all the work. Nobody else is doing > anything about it. > > Linux is throttling the CPU speed of this machine without trying to to > increase the fan speed first, that is not ideal. > > So I do the first step of writing the fan driver and I get told it > shouldn't be a separate driver, it should be part of wmi, only to be > told later by the same person that it doesn't belong in wmi when I put > it there. Then I get told virt_to_physical() is not good, and it > should move to staging, and then I'm told you don't want it. Who told you to put it in staging? That is the person that needs to be corrected here, it's not your issue, sorry, I didn't realize the backstory here. And I would push back on those people, if it solves your problem, and there's no other good solution, then it should go into the "real" part of the kernel. Who has rejected this driver and for what reason? greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: new asus fan driver
On Tue, Nov 5, 2013 at 8:19 PM, Greg Kroah-Hartman wrote: > On Tue, Nov 05, 2013 at 01:54:51PM -0600, Felipe Contreras wrote: >> On Tue, Nov 5, 2013 at 9:16 AM, Greg Kroah-Hartman >> wrote: >> > On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote: >> >> On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman >> >> wrote: >> >> > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote: >> >> >> Simple driver to enable control of the fan in ASUS laptops. So far this >> >> >> has only been tested in ASUS Zenbook Prime UX31A, but according to some >> >> >> online reference [1], it should work in other models as well. >> >> >> >> >> >> The implementation is very straight-forward, the only caveat is that >> >> >> the >> >> >> fan speed needs to be saved after it has been manually changed because >> >> >> it won't be reported properly until it goes back to 'auto' mode. >> >> >> >> >> >> [1] >> >> >> http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html >> >> >> >> >> >> Signed-off-by: Felipe Contreras >> >> >> --- >> >> >> >> >> >> Two incarnations of this code exists [1][2], one that used ACPI methods >> >> >> directly, and one through WMI. Unfortunately the WMI version needs us >> >> >> to pass >> >> >> physicall addresses which is not exactly clean, and that's the only >> >> >> reason the >> >> >> code is proposed for staging. >> >> >> >> >> >> Most likely this cannot graduate until acpica gets support to receive >> >> >> virtual >> >> >> addresses. >> >> > >> >> > When is that going to happen? >> >> >> >> I don't know. Presumably when I get it done, which might be never, or >> >> a few days from now. Most likely it will take some time. >> > >> > Then why not just merge this to the proper place, instead of relying on >> > staging? I don't want to have to have a staging driver that is waiting >> > on external things to get it merged, instead of issues with the driver >> > itself, as you are now putting the burden of maintenance on me, for no >> > good reason other than you being too "lazy" to get other stuff done :) >> >> *I* am too lazy? I am doing all the work. Nobody else is doing >> anything about it. >> >> Linux is throttling the CPU speed of this machine without trying to to >> increase the fan speed first, that is not ideal. >> >> So I do the first step of writing the fan driver and I get told it >> shouldn't be a separate driver, it should be part of wmi, only to be >> told later by the same person that it doesn't belong in wmi when I put >> it there. Then I get told virt_to_physical() is not good, and it >> should move to staging, and then I'm told you don't want it. > > Who told you to put it in staging? That is the person that needs to be > corrected here, it's not your issue, sorry, I didn't realize the > backstory here. Matthew Garrett. He said I should wrap my wmi fan code [1], so that it compiles only when staging. I was doing that when I realized how ugly it would all be, and there doesn't seem to be any precedent for that, so I just wrote it as a separate driver. > And I would push back on those people, if it solves your problem, and > there's no other good solution, then it should go into the "real" part > of the kernel. Who has rejected this driver and for what reason? Matthew Garrett. Because as it's described in the TODO, this code is passing a physical address of our structs to the ACPI code, but that's what the DSDT expects, there's no way around it. Doing virt_to_phys() and passing that to the ACPI code might be a little ugly, but as far as I know there's checks already in place. Matthew said the acpica code is the one that should be doing the virt_to_phys() conversion, which is probably true, but since nobody is going to do that, the task is left for me. Before going into this daunting task, I would rather have the CPU throttling fixed by hooking the fan to a thermal zone, which was my motivation of starting it in the first place, but I have not received any help as to how to do that, I was hoping having the driver land somewhere (e.g. staging) might help to get the first part out of the way, and concentrate on how to actually make it useful. [1] http://article.gmane.org/gmane.linux.power-management.general/39522 -- Felipe Contreras ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
