patch & a question about the serial driver

patch & a question about the serial driver

[Dino Klein]

I am interested to know whether the patch below looks like a good idea as a 
way to allow the user to specify additional HIDs that the driver should 
handle; I had to add an HID to the list when I tried to get the Wacom device 
in my tablet to work, since it was using a different HID than the standard 
one for serial ports. This patch would allow the user to specify an 
alternative string of HIDs without having to recompile the kernel.
The extra question I have is about the HIDs listed in the 8250_pnp.c file; 
shouldn't those values (some, or all) be shared with between the two 
drivers? or are they unlikely to show up through ACPI?


--- linux-2.6.7-orig/drivers/serial/8250_acpi.c	2004-06-19 
22:07:23.668416224 -0400
+++ linux-2.6.7/drivers/serial/8250_acpi.c	2004-06-19 21:45:20.000000000 
-0400
@@ -21,6 +21,13 @@
#include <asm/io.h>
#include <asm/serial.h>

+
+static char *hids = "PNP0501";
+
+MODULE_PARM(hids, "s");
+
+
+
struct serial_private {
	int	line;
	void	*iomem_base;
@@ -173,7 +180,6 @@
static struct acpi_driver acpi_serial_driver = {
	.name =		"serial",
	.class =	"",
-	.ids =		"PNP0501",
	.ops =	{
		.add =		acpi_serial_add,
		.remove =	acpi_serial_remove,
@@ -182,6 +188,7 @@

static int __init acpi_serial_init(void)
{
+	acpi_serial_driver.ids = hids;
	return acpi_bus_register_driver(&acpi_serial_driver);
}

_________________________________________________________________
MSN Messenger: instale grátis e converse com seus amigos. 
http://messenger.msn.com.br



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: patch & a question about the serial driver

[Matthew Wilcox]

On Sat, Jun 19, 2004 at 11:55:09PM -0300, Dino Klein wrote:
> I am interested to know whether the patch below looks like a good idea as a 
> way to allow the user to specify additional HIDs that the driver should 
> handle;

No.  The device in question should specify PNP0501 in its _CID if it's
compatible with PNP0501.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

PBLK length again

[Herman Sheremetyev]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Hi All,

I have an Asus M6N and the Bios DSDT provides a PBLK length of 7 which
causes ACPI to always use the C1 processor state.  This laptop
definitely supports C2 and most people have just used custom DSDT's and
changed the value to 6.  I don't like using a custom DSDT so I made a
quick kernel patch (attached) to accept 7 as a good value.

I've searched the archives and found that other people have had issues
with PBLK being set to something other than 0 or 6 and at one point the
ACPI code was relaxed to allow for other values but then changed back to
the original strict mode due to issues with C2 being used when it
shouldn't be.  There was also talk of making the relaxed code optional
but it seems that never got off the ground.  

My question is, if I make a nicer patch that allows for either strict
interpretation versus a relaxed one, is there a chance that it will get
included?  It seems there is enough interest out there to make it worth
the effort.

Thanks,

-Herman

 

[-- Attachment #2: pblk_length-7-hack.patch --]
[-- Type: text/x-patch, Size: 864 bytes --]

--- linux-2.6.7/drivers/acpi/processor.c	2004-06-20 14:49:10.066168648 -0400
+++ linux-2.6.7.hack/drivers/acpi/processor.c	2004-06-19 21:26:33.000000000 -0400
@@ -2214,7 +2230,8 @@
 
 	if (!object.processor.pblk_address)
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
-	else if (object.processor.pblk_length != 6)
+	else if ((object.processor.pblk_length != 6 ) && 
+		(object.processor.pblk_length != 7 ))
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid PBLK length [%d]\n",
 			object.processor.pblk_length));
 	else {
@@ -2233,7 +2250,7 @@
 		 *
 		 * (In particular, allocating the IO range for Cardbus)
 		 */
-		request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+		request_region(pr->throttling.address, object.processor.pblk_length, "ACPI CPU throttle");
 		request_region(acpi_fadt.xpm_tmr_blk.address, 4, "ACPI timer");
 	}
 

Re: PBLK length again

[Luca Capello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

on 06/21/04 00:20, Herman Sheremetyev wrote:
> I have an Asus M6N and the Bios DSDT provides a PBLK length of 7 which
> causes ACPI to always use the C1 processor state.  This laptop
> definitely supports C2 and most people have just used custom DSDT's
> and changed the value to 6.  I don't like using a custom DSDT so I
> made a quick kernel patch (attached) to accept 7 as a good value.
AFAIK 7 isn't an allowed value from the ACPI-CA specs (but I'm not an
expert).

BTW, I've an ASUS M6N, too, please refers to this kernel bug:
	http://bugme.osdl.org/show_bug.cgi?id=1958
I made some tests in the past with the provided Bruno Ducrot's patch (as
you can read), but it seems that now the patch is broken.

ASAP I'll try your patch, just to confirm that it works on different
machines.

> My question is, if I make a nicer patch that allows for either strict
> interpretation versus a relaxed one, is there a chance that it will
> get included?  It seems there is enough interest out there to make it
> worth the effort.
You should wait for someone other's advice, but if PBLK = 7 isn't
correct for the ACPI-CA specs, IMHO the solution shouldn't be a
workaround like your.

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA1z+eVAp7Xm10JmkRAobWAJ0Us331jNC+JL9PYfMM4x3Ax41JDwCaA0XV
9jqGRccGmDCjTPArZMFBxEQ=
=t0/x
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: PBLK length again

[Herman Sheremetyev]

Hi Luca,

Thanks for the response,

> on 06/21/04 00:20, Herman Sheremetyev wrote:
> > I have an Asus M6N and the Bios DSDT provides a PBLK length of 7 which
> > causes ACPI to always use the C1 processor state.  This laptop
> > definitely supports C2 and most people have just used custom DSDT's
> > and changed the value to 6.  I don't like using a custom DSDT so I
> > made a quick kernel patch (attached) to accept 7 as a good value.
> AFAIK 7 isn't an allowed value from the ACPI-CA specs (but I'm not an
> expert).

>From the research I've done I am fairly certain that 7 is not a legal
value but Asus insists on breaking the spec by sticking 5's and 7's in
PBLK length even though they mean 6, and Windows doesn't seem to mind. 
There should be a way for Linux to deal with this too I think.

> BTW, I've an ASUS M6N, too, please refers to this kernel bug:
> 	http://bugme.osdl.org/show_bug.cgi?id=1958
> I made some tests in the past with the provided Bruno Ducrot's patch (as
> you can read), but it seems that now the patch is broken.
> 
> ASAP I'll try your patch, just to confirm that it works on different
> machines.


Cool, I run a "Linux on the M6N" forum so you can post your results
there as it probably doesn't need to be on this list:

http://mrhammy2.ath.cx:81/forum/viewtopic.php?t=85

> > My question is, if I make a nicer patch that allows for either strict
> > interpretation versus a relaxed one, is there a chance that it will
> > get included?  It seems there is enough interest out there to make it
> > worth the effort.
> You should wait for someone other's advice, but if PBLK = 7 isn't
> correct for the ACPI-CA specs, IMHO the solution shouldn't be a
> workaround like your.

What this patch does is really no different from using a custom DSDT, in
the end you're still overriding the value the BIOS provides with one
that make sense to the OSPM system.  I'm definitely no expert on this
stuff but I would think a kernel based solution (granted it should be
nicer than my initial patch) is better than a DSDT based one.  Having
either a compile-time or boot-time option to accept other values or
maybe override the PBLK length would probably benefit a lot of people
with broken BIOS's.

-Herman



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: PBLK length again

[Stefan Seyfried]

On Mon, Jun 21, 2004 at 04:40:04PM -0400, Herman Sheremetyev wrote:

> From the research I've done I am fairly certain that 7 is not a legal
> value but Asus insists on breaking the spec by sticking 5's and 7's in
> PBLK length even though they mean 6, and Windows doesn't seem to mind. 
> There should be a way for Linux to deal with this too I think.

IIRC there was a discussion on this list some time ago and the outcome was,
that intel once shipped a "BIOS programmers guide" which told that 7 was
allowed. Later they changed their mind and decided only 6 was correct.
So there was some consent that 7 should also be allowed in the linux
implementation. Unfortunately nobody ever implemeted it.
This is all IIRC, YMMV.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: PBLK length again

[Karol Kozimor]

Thus wrote Stefan Seyfried:
> IIRC there was a discussion on this list some time ago and the outcome was,
> that intel once shipped a "BIOS programmers guide" which told that 7 was
> allowed. Later they changed their mind and decided only 6 was correct.

Well, since Intel shipped / still ships chipsets that actually do have a 
PBLK of length 7, that's somehow odd.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: PBLK length again

[Herman Sheremetyev]

Hi Karol,

> Well, since Intel shipped / still ships chipsets that actually do have a 
> PBLK of length 7, that's somehow odd.
> Best regards,

If what you're saying is right then this patch should probably be included 
in the main source since right now value of 6 is the only one hardcoded in
to be accepted.  Is there some other place than this list I should submit it?

Thanks,

-Herman

--- linux-2.6.7/drivers/acpi/processor.c        2004-06-20 14:49:10.066168648 -0400
+++ linux-2.6.7.hack/drivers/acpi/processor.c   2004-06-19 21:26:33.000000000 -0400
@@ -2214,7 +2230,8 @@

        if (!object.processor.pblk_address)
                ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
-       else if (object.processor.pblk_length != 6)
+       else if ((object.processor.pblk_length != 6 ) &&
+               (object.processor.pblk_length != 7 ))
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid PBLK length [%d]\n",
                        object.processor.pblk_length));
        else {
@@ -2233,7 +2250,7 @@
                 *
                 * (In particular, allocating the IO range for Cardbus)
                 */
-               request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+               request_region(pr->throttling.address, object.processor.pblk_length, "ACPI CPU throttle");
                request_region(acpi_fadt.xpm_tmr_blk.address, 4, "ACPI timer");
        }




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: PBLK length again

[Stefan Seyfried]

On Thu, Jun 24, 2004 at 06:21:17PM +0200, Karol Kozimor wrote:
> Thus wrote Stefan Seyfried:
> > IIRC there was a discussion on this list some time ago and the outcome was,
> > that intel once shipped a "BIOS programmers guide" which told that 7 was
> > allowed. Later they changed their mind and decided only 6 was correct.
> 
> Well, since Intel shipped / still ships chipsets that actually do have a 
> PBLK of length 7, that's somehow odd.

Maybe the ACPI developers decided that only 6 is correct, but the BIOS
programmers still have the old "programmers guide" ;^)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: PBLK length again

[Luca Capello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

on 06/21/04 22:40, Herman Sheremetyev wrote:

> From the research I've done I am fairly certain that 7 is not a legal
> value but Asus insists on breaking the spec by sticking 5's and 7's in
> PBLK length even though they mean 6, and Windows doesn't seem to mind.
> There should be a way for Linux to deal with this too I think.
I agree. And it seems that after having informed ASUS of this problem,
they don't care about it  :-(

>> ASAP I'll try your patch, just to confirm that it works on different
>> machines.
> Cool, I run a "Linux on the M6N" forum so you can post your results
> there as it probably doesn't need to be on this list:
>
> http://mrhammy2.ath.cx:81/forum/viewtopic.php?t=85
I know your site: it's there that I found that the ASUS M6N has an
S3_bios. Anyway, I'm posting here the results:
=====
luca-HSB4nKSusd8@public.gmane.org:~$ cat /proc/acpi/processor/CPU1/*
processor id:            0
acpi id:                 1
bus mastering control:   yes
power management:        yes
throttling control:      yes
limit interface:         yes
active limit:            P0:T0
user limit:              P0:T0
thermal limit:           P0:T0
active state:            C2
default state:           C1
bus master activity:     00000000
states:
  C1:          promotion[C2] demotion[--] latency[000] usage[00088150]
 *C2:          promotion[--] demotion[C1] latency[099] usage[00399406]
  C3:          <not supported>
state count:             8
active state:            T0
states:
   *T0:                  00%
    T1:                  12%
    T2:                  25%
    T3:                  37%
    T4:                  50%
    T5:                  62%
    T6:                  75%
    T7:                  87%
luca-HSB4nKSusd8@public.gmane.org:~$
=====

> What this patch does is really no different from using a custom DSDT,
> in the end you're still overriding the value the BIOS provides with
> one that make sense to the OSPM system.  I'm definitely no expert on
> this stuff but I would think a kernel based solution (granted it
> should be nicer than my initial patch) is better than a DSDT based
> one.  Having either a compile-time or boot-time option to accept other
> values or maybe override the PBLK length would probably benefit a lot
> of people with broken BIOS's.
I agree, I prefer to not have a custom DSDT, but it's now always
possible  :-(

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA3BGoVAp7Xm10JmkRAh0WAJ91cJ/hIGiFJnNOpzuRk1gjjAH39gCfRyiS
mEIR/2T80FKJsvHVPx2yLFs=
=Bfr7
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com