[PATCH 0/22] acpi4asus sync with 0.31

[PATCH 0/22] acpi4asus sync with 0.31

[Corentin CHARY]

Hi,
This set of patch is against 2.6.19. It add support for many 
models, /sys/class/backlight/, Light Sens, etc ... There is also a lot of 
cleanups. And the most important, a new system to handle unsupported models.

Patch from 0 to 10 are change and cleanups in the driver.
Patch from 11t to 21 add support for new models.

All the following patchs are available here : 
<http://xf.iksaif.net/acpi4asus/2.6.19/>

Thanks
-- 
CHARY 'Iksaif' Corentin
http://xf.iksaif.net

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Len Brown]

On Tuesday 19 December 2006 16:17, Corentin CHARY wrote:
> Hi,
> This set of patch is against 2.6.19. It add support for many 
> models, /sys/class/backlight/, Light Sens, etc ... There is also a lot of 
> cleanups. And the most important, a new system to handle unsupported models.
> 
> Patch from 0 to 10 are change and cleanups in the driver.
> Patch from 11t to 21 add support for new models.
> 
> All the following patchs are available here : 
> <http://xf.iksaif.net/acpi4asus/2.6.19/>

Great!

When this series is formatted to apply, what tree is it supposed to apply to?

How does it relate to the two asus_acpi patches in the mm tree right now --
13/19 and 19/19 that akpm forwarded to the list yesterday.

How does it relate to the acpi-test tree, which already includes
the backlight patch to asus_acpi from Holger Macht?

thanks
-Len

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Corentin CHARY]

Le mercredi 20 décembre 2006 08:42, Len Brown a écrit :
> On Tuesday 19 December 2006 16:17, Corentin CHARY wrote:
> > Hi,
> > This set of patch is against 2.6.19. It add support for many
> > models, /sys/class/backlight/, Light Sens, etc ... There is also a lot of
> > cleanups. And the most important, a new system to handle unsupported
> > models.
> >
> > Patch from 0 to 10 are change and cleanups in the driver.
> > Patch from 11t to 21 add support for new models.
> >
> > All the following patchs are available here :
> > <http://xf.iksaif.net/acpi4asus/2.6.19/>
>
> Great!
>
> When this series is formatted to apply, what tree is it supposed to apply
> to?
These patchs are done with asus_acpi.c from 2.6.19 . So it can be applied to 
2.6.19 and 2.6.20-rc1 (as there is no change for asus_acpi in 2.6.20-rc1).


>
> How does it relate to the two asus_acpi patches in the mm tree right now --
> 13/19 and 19/19 that akpm forwarded to the list yesterday.
>
The change in the mm tree are :   
	- Backlight support
	=> It's nearly the same code (patch 10/22)
	- no more useless cast
	=> It's ok (patch 7/22)
	- Add support for A6VA, M6V, W5F, V6V, A4S
	=> It's ok, but more features are supported in my patchs.
	And the implemention is cleaner, as I use my parse_method()
	function instead of adding special case in get_lcd_status()
	(see patch 5/22 and 6/22)
	- Swap W5A and W3V
	=> It's ok,  (patch 19/22)
	- Invert wled status
	=> I don't do it, as it's a mistake. I tested on A6T, A6J, F3JM, and the
	wled value don't need to be inverted.

> How does it relate to the acpi-test tree, which already includes
> the backlight patch to asus_acpi from Holger Macht?
The change in the acpi-test tree are :
	- Backlight support
	=> done
	- no more useless cast
	=> done
>
> thanks
> -Len

-- 
CHARY 'Iksaif' Corentin
http://xf.iksaif.net
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Len Brown]

Karol and Julien are listed as the MAINTAINERS for asus_acpi.
Why do I not see their Signed-off-by or Acked-by lines on this patch series?

On Wednesday 20 December 2006 05:02, Corentin CHARY wrote:
> Le mercredi 20 décembre 2006 08:42, Len Brown a écrit :
> > On Tuesday 19 December 2006 16:17, Corentin CHARY wrote:
> > > Hi,
> > > This set of patch is against 2.6.19. It add support for many
> > > models, /sys/class/backlight/, Light Sens, etc ... There is also a lot of
> > > cleanups. And the most important, a new system to handle unsupported
> > > models.
> > >
> > > Patch from 0 to 10 are change and cleanups in the driver.
> > > Patch from 11t to 21 add support for new models.
> > >
> > > All the following patchs are available here :
> > > <http://xf.iksaif.net/acpi4asus/2.6.19/>
> >

> >
> > When this series is formatted to apply, what tree is it supposed to apply
> > to?
> These patchs are done with asus_acpi.c from 2.6.19 . So it can be applied to 
> 2.6.19 and 2.6.20-rc1 (as there is no change for asus_acpi in 2.6.20-rc1).
> 
> 
> >
> > How does it relate to the two asus_acpi patches in the mm tree right now --
> > 13/19 and 19/19 that akpm forwarded to the list yesterday.
> >
> The change in the mm tree are :   
> 	- Backlight support
> 	=> It's nearly the same code (patch 10/22)
> 	- no more useless cast
> 	=> It's ok (patch 7/22)
> 	- Add support for A6VA, M6V, W5F, V6V, A4S
> 	=> It's ok, but more features are supported in my patchs.
> 	And the implemention is cleaner, as I use my parse_method()
> 	function instead of adding special case in get_lcd_status()
> 	(see patch 5/22 and 6/22)
> 	- Swap W5A and W3V
> 	=> It's ok,  (patch 19/22)
> 	- Invert wled status
> 	=> I don't do it, as it's a mistake. I tested on A6T, A6J, F3JM, and the
> 	wled value don't need to be inverted.

So should we NAK the two patches that are proposed in -mm
and ask Andrew to not accept asus_acpi patches and instead direct
them to acpi4asus-user@lists.sourceforge.net?

> > How does it relate to the acpi-test tree, which already includes
> > the backlight patch to asus_acpi from Holger Macht?
> The change in the acpi-test tree are :
> 	- Backlight support
> 	=> done
> 	- no more useless cast
> 	=> done

Holger's patch is already queued for upstream -- having lived in -mm for some time now.
When you resend the acpi4asus series such that it is properly formatted,
please be sure it applies cleanly to what is in acpi release tree.
(ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.20/acpi-release-20060707-2.6.20-rc1.diff.gz)

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Corentin CHARY]

Le mercredi 20 décembre 2006 23:49, vous avez écrit :
> Karol and Julien are listed as the MAINTAINERS for asus_acpi.
> Why do I not see their Signed-off-by or Acked-by lines on this patch
> series?
>
Julien and Karol are not active any more.

-- 
CHARY 'Iksaif' Corentin
http://xf.iksaif.net
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Julien Lerouge]

Sorry Len, I should have told you earlier,

I have not been active for a long time, and don't plan to be, at least
not on this driver. Corentin is willing to maintain it. I don't know for
Karol, but you can remove me from the MAINTAINERS.

Also, Corentin should be added to the list of the MAINTAINERS for this
driver.

Thanks,
Julien

On Wed, Dec 20, 2006 at 05:49:32PM -0500, Len Brown wrote:
> Karol and Julien are listed as the MAINTAINERS for asus_acpi.
> Why do I not see their Signed-off-by or Acked-by lines on this patch series?

> On Wednesday 20 December 2006 05:02, Corentin CHARY wrote:
> > Le mercredi 20 décembre 2006 08:42, Len Brown a écrit :
> > > On Tuesday 19 December 2006 16:17, Corentin CHARY wrote:
> > > > Hi,
> > > > This set of patch is against 2.6.19. It add support for many
> > > > models, /sys/class/backlight/, Light Sens, etc ... There is also a lot of
> > > > cleanups. And the most important, a new system to handle unsupported
> > > > models.
> > > >
> > > > Patch from 0 to 10 are change and cleanups in the driver.
> > > > Patch from 11t to 21 add support for new models.
> > > >
> > > > All the following patchs are available here :
> > > > <http://xf.iksaif.net/acpi4asus/2.6.19/>
> > >

> > >
> > > When this series is formatted to apply, what tree is it supposed to apply
> > > to?
> > These patchs are done with asus_acpi.c from 2.6.19 . So it can be applied to 
> > 2.6.19 and 2.6.20-rc1 (as there is no change for asus_acpi in 2.6.20-rc1).
> > 
> > 
> > >
> > > How does it relate to the two asus_acpi patches in the mm tree right now --
> > > 13/19 and 19/19 that akpm forwarded to the list yesterday.
> > >
> > The change in the mm tree are :   
> > 	- Backlight support
> > 	=> It's nearly the same code (patch 10/22)
> > 	- no more useless cast
> > 	=> It's ok (patch 7/22)
> > 	- Add support for A6VA, M6V, W5F, V6V, A4S
> > 	=> It's ok, but more features are supported in my patchs.
> > 	And the implemention is cleaner, as I use my parse_method()
> > 	function instead of adding special case in get_lcd_status()
> > 	(see patch 5/22 and 6/22)
> > 	- Swap W5A and W3V
> > 	=> It's ok,  (patch 19/22)
> > 	- Invert wled status
> > 	=> I don't do it, as it's a mistake. I tested on A6T, A6J, F3JM, and the
> > 	wled value don't need to be inverted.

> So should we NAK the two patches that are proposed in -mm
> and ask Andrew to not accept asus_acpi patches and instead direct
> them to acpi4asus-user@lists.sourceforge.net?

> > > How does it relate to the acpi-test tree, which already includes
> > > the backlight patch to asus_acpi from Holger Macht?
> > The change in the acpi-test tree are :
> > 	- Backlight support
> > 	=> done
> > 	- no more useless cast
> > 	=> done

> Holger's patch is already queued for upstream -- having lived in -mm for some time now.
> When you resend the acpi4asus series such that it is properly formatted,
> please be sure it applies cleanly to what is in acpi release tree.
> (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.20/acpi-release-20060707-2.6.20-rc1.diff.gz)

> thanks,
> -Len
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Len Brown]

On Wednesday 20 December 2006 20:17, Julien Lerouge wrote:
> ...Corentin is willing to maintain it. I don't know for
> Karol, but you can remove me from the MAINTAINERS.
> 
> Also, Corentin should be added to the list of the MAINTAINERS for this
> driver.

Thanks Julien, I'll update MAINTAINERS patch below.

Corentin, please ACK or NAK (note, I put your URL in there too)

I'll leave Karol's entry alone till I hear from him.

Corentin,
Do you agree that patches for asus_acpi should always appear on the
acpi4asus mailing list and get an ACK from you before being applied upstream?
(The only answer is yes:-)  I'll NAK them now:-)

But to apply your series, we need to first iron out a couple of logistics.

Per Documentation/SubmittingPatches

From: Original Author <author@example.com>
must appear on each patch to credit the original author.
Clarity on the Subject: line about what changed is important.
Important to keep cosmetic vs functional changes in different patches
and document such -- looks like you've done a good job of that --
though ideally the cosmetic patches come _after_ the functional ones
in case somebody wants to apply functional w/o cosmetic -- but not a hard rule.
Check-in comments go into the permanent record, so they don't
need to say thing like "this patch" etc, since that is implicit etc.

The series you sent is from you and signed-off-by you, which credits nobody else.
That is fine if you are the original author and only contributor, but needs to be updated if not.

Also, the e-mail patches must apply and not get garbled by your mailer due to line-wrap
per my previous message.

The patch series will ideally apply on top of any asus_acpi patches already in my tree.
But if not, then at a minimum they must apply to Linus' tree -- which is where you are now
and I can attempt to merge any conflicts.  If you'd rather merge the conflicts, then make
sure the series you send applied to my tree.

Re: development strategy
Asside from supporting your users, there are a couple of "big picture" things to be aware of.
It is clear that we need platform-specific drivers like asus_acpi, and always will.
However, to the extent that we create special API's to user-space in the form
of /proc or /sysfs files that appear only when that driver is loaded, we've failed.

We need to move towards common interfaces that make it simple for users and programmers
to talk to the kernel drivers, the backlight and led classes are good examples,
and input layer for keyboard events is another.  In these cases the user or
utility doesn't know or care about the model of laptop they have or the way
that the feature is implemented.  So while /proc/acpi/asus_acpi files were
practical for a prototype, they are what we want to move _away_ from,
and we should be working on deleting them and not changing what is there
and not adding any more /proc files.

Indeed, in the long term, all of /proc/acpi will be removed in favor of generic /sys
interfaces -- as ACPI itself is an implementation dependent way of making features
available to the user -- ie. not all systems have ACPI...

Some platform specific drivers use ACPI, some do not, but by definition,
they are platform specific and are not _part_ of ACPI (ie. not described in the spec).
Thus it doesn't make sense for them to live under /drivers/acpi in the source tree.
New platform specific drivers are being added to the tree under /drivers/misc/
for example, msi-laptop.c.  At some point, asus_acpi.c should move to /drivers/misc
if that is where they all end up.  However, I do not highly recommend re-naming the
actual driver, because users already know the module name asus_acpi.

In general, I'd like to see the platform specific drivers not implement features that
should be generic -- as the effort is better spent helping all users, not just those
with a specific model.  A good example of this is docking support emerging on ibm_acpi
and the dock driver at the same time -- I'd much rather see the effort go into the generic
driver when at all possible.  A good counter-example was they hotkey driver --
which failed to make it out of EXPERIMENTAL stage and will be removed
because there are more differences in the non-standard hotkey implementations
than there is common code that can be shared.

thanks,
-Len

diff --git a/MAINTAINERS b/MAINTAINERS
index d708702..68f72c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -404,13 +404,13 @@ L:	netdev@vger.kernel.org
 S:	Maintained
 
 ASUS ACPI EXTRAS DRIVER
+P:	Corentin Chary
+M:	corentincj@iksaif.net
 P:	Karol Kozimor
 M:	sziwan@users.sourceforge.net
-P:	Julien Lerouge
-M:	julien.lerouge@free.fr
 L:	acpi4asus-user@lists.sourceforge.net
 W:	http://sourceforge.net/projects/acpi4asus
-W:	http://julien.lerouge.free.fr
+W:	http://xf.iksaif.net/acpi4asus
 S:	Maintained
 
 ATA OVER ETHERNET DRIVER

Re: [PATCH 0/22] acpi4asus sync with 0.31

[Corentin CHARY]

ACK

Le samedi 23 décembre 2006 03:11, Len Brown a écrit :
> Thanks Julien, I'll update MAINTAINERS patch below.
>
> Corentin, please ACK or NAK (note, I put your URL in there too)
>
> I'll leave Karol's entry alone till I hear from him.
>
> Corentin,
> Do you agree that patches for asus_acpi should always appear on the
> acpi4asus mailing list and get an ACK from you before being applied
> upstream? (The only answer is yes:-)  I'll NAK them now:-)
Yes

> But to apply your series, we need to first iron out a couple of logistics.
>
> Per Documentation/SubmittingPatches
>
> From: Original Author <author@example.com>
> must appear on each patch to credit the original author.
> Clarity on the Subject: line about what changed is important.
> Important to keep cosmetic vs functional changes in different patches
> and document such -- looks like you've done a good job of that --
> though ideally the cosmetic patches come _after_ the functional ones
> in case somebody wants to apply functional w/o cosmetic -- but not a hard
> rule. Check-in comments go into the permanent record, so they don't
> need to say thing like "this patch" etc, since that is implicit etc.
>
> The series you sent is from you and signed-off-by you, which credits nobody
> else. That is fine if you are the original author and only contributor, but
> needs to be updated if not.
Most of the patch I get were unusable. Some of them were very usefull (but I 
had to rewrite them), I added authors in asus_acpi.c header, but forgot them 
in the mails.

> Also, the e-mail patches must apply and not get garbled by your mailer due
> to line-wrap per my previous message.
Ok, I will re-send the whole series. Maybe I should join them to avoid stupid 
mistakes like that ? (Or I can just uncheck line-wrap ^^)

> The patch series will ideally apply on top of any asus_acpi patches already
> in my tree. But if not, then at a minimum they must apply to Linus' tree --
> which is where you are now and I can attempt to merge any conflicts.  If
> you'd rather merge the conflicts, then make sure the series you send
> applied to my tree.
I can re-do the whole series to apply to your tree. If I do that, I will also 
include some change from the CVS (3 new models, some cleanups, new led). I 
can also just re-send the series as it is. As you want.
Anyway, I can't do anything before next week.

> Re: development strategy
> Asside from supporting your users, there are a couple of "big picture"
> things to be aware of. It is clear that we need platform-specific drivers
> like asus_acpi, and always will. However, to the extent that we create
> special API's to user-space in the form of /proc or /sysfs files that
> appear only when that driver is loaded, we've failed.
>
> We need to move towards common interfaces that make it simple for users and
> programmers to talk to the kernel drivers, the backlight and led classes
> are good examples, and input layer for keyboard events is another.  In
> these cases the user or utility doesn't know or care about the model of
> laptop they have or the way that the feature is implemented.  So while
> /proc/acpi/asus_acpi files were practical for a prototype, they are what we
> want to move _away_ from, and we should be working on deleting them and not
> changing what is there and not adding any more /proc files.
>
> Indeed, in the long term, all of /proc/acpi will be removed in favor of
> generic /sys interfaces -- as ACPI itself is an implementation dependent
> way of making features available to the user -- ie. not all systems have
> ACPI...
>
It's why I will try to add led support in the next release :). There is also 
the new display class.

>
> thanks,
> -Len
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d708702..68f72c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -404,13 +404,13 @@ L:	netdev@vger.kernel.org
>  S:	Maintained
>
>  ASUS ACPI EXTRAS DRIVER
> +P:	Corentin Chary
> +M:	corentincj@iksaif.net
>  P:	Karol Kozimor
>  M:	sziwan@users.sourceforge.net
> -P:	Julien Lerouge
> -M:	julien.lerouge@free.fr
>  L:	acpi4asus-user@lists.sourceforge.net
>  W:	http://sourceforge.net/projects/acpi4asus
> -W:	http://julien.lerouge.free.fr
> +W:	http://xf.iksaif.net/acpi4asus
>  S:	Maintained
>
>  ATA OVER ETHERNET DRIVER

Thanks
-- 
CHARY 'Iksaif' Corentin
http://xf.iksaif.net
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html