diff: nuke a redundant check for cpu_unidle() (i386)

2010-09-28 Thread Vladimir Kirillov 
Hello, t...@!

Subj, cpu_unidle() does that check itself.

Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.481
diff -u -p -r1.481 machdep.c
--- i386/machdep.c  5 Aug 2010 21:10:09 -   1.481
+++ i386/machdep.c  28 Sep 2010 11:39:14 -
@@ -3303,8 +3303,7 @@ need_resched(struct cpu_info *ci)
/* There's a risk we'll be called before the idle threads start */
if (ci-ci_curproc) {
aston(ci-ci_curproc);
-   if (ci != curcpu())
-   cpu_unidle(ci);
+   cpu_unidle(ci);
}
 }

Handling sysctl hw.serialno

2010-09-28 Thread Destan YILANCI (Parta) 
Hello Everyone,

I want to get serial number of hardware with handling sysctl. I've got a
little code below:

#include stdio.h
#include string.h
#include errno.h
#include sys/param.h
#include sys/sysctl.h

int main(int argc, char **argv)
{
char cpubuf[1024];
size_t len;
int mib[5];

mib[0] = CTL_HW;
mib[1] = HW_SERIALNO;
len = sizeof(cpubuf);
if (sysctl(mib, 2, cpubuf, len, NULL, 0) == -1) {
printf(HW_SERIALNO %s\n, strerror(errno));
return(1);
}

printf(cpu: %s\n, cpubuf);

return 0;
}

But i realized that some of my machines cant get sysctl hw.serialno so
it's normal that C code fails with this error message : HW_SERIALNO
Operation not supported

So if we return to the source, why sysctl cant handle some of hardware
serial numbers? 

Thank you.

P.S.
I want to provide a working sysctl.hw ouput here:
hw.machine=i386
hw.model=Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (GenuineIntel 686-class)
hw.ncpu=8
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0,sd1,sd2,sd3,sd4,cd0
hw.diskcount=6
hw.sensors.cpu0.temp0=44.00 degC
hw.sensors.mpi0.drive0=online (sd0), OK
hw.cpuspeed=2827
hw.setperf=99
hw.vendor=Sun Microsystems
hw.product=Sun Fire X4150
hw.serialno=2029QTF0814MR0GYD
hw.uuid=6236f661-097a-0010-915a-001e682f5f0c
hw.physmem=3757338624
hw.usermem=3756867584
hw.ncpufound=8

And here is a not working hw.serialno :
# sysctl hw
hw.machine=i386
hw.model=AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (AuthenticAMD
686-class, 512KB L2 cache)
hw.ncpu=2
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=cd0,wd0
hw.diskcount=2
hw.sensors.acpitz0.temp0=40.00 degC (zone temperature)
hw.sensors.aibs0.temp0=34.00 degC (CPU Temperature), OK
hw.sensors.aibs0.temp1=43.00 degC (MB Temperature), OK
hw.sensors.aibs0.fan0=1288 RPM (CPU FAN Speed), WARNING
hw.sensors.aibs0.fan1=1138 RPM (CHASSIS FAN Speed), WARNING
hw.sensors.aibs0.volt0=1.27 VDC (Vcore Voltage), WARNING
hw.sensors.aibs0.volt1=3.18 VDC ( +3.3 Voltage), OK
hw.sensors.aibs0.volt2=4.98 VDC ( +5.0 Voltage), OK
hw.sensors.aibs0.volt3=11.98 VDC (+12.0 Voltage), OK
hw.sensors.kate0.temp0=36.00 degC
hw.sensors.kate0.temp2=35.00 degC
hw.sensors.it0.temp0=34.00 degC
hw.sensors.it0.temp1=43.00 degC
hw.sensors.it0.temp2=25.00 degC
hw.sensors.it0.fan0=1288 RPM
hw.sensors.it0.fan1=1138 RPM
hw.sensors.it0.fan2=0 RPM
hw.sensors.it0.volt0=1.12 VDC (VCORE_A)
hw.sensors.it0.volt1=3.18 VDC (VCORE_B)
hw.sensors.it0.volt2=0.00 VDC (+3.3V)
hw.sensors.it0.volt3=4.78 VDC (+5V)
hw.sensors.it0.volt4=11.58 VDC (+12V)
hw.sensors.it0.volt5=-17.00 VDC (-12V)
hw.sensors.it0.volt6=-8.60 VDC (-5V)
hw.sensors.it0.volt7=4.57 VDC (+5VSB)
hw.sensors.it0.volt8=2.88 VDC (VBAT)
hw.cpuspeed=2010
hw.setperf=100
hw.vendor=ASUSTek Computer INC.
hw.product=M2NPV-VM
hw.uuid=----
hw.physmem=1038643200
hw.usermem=1038565376
hw.ncpufound=2

Any other not working output is also here:
# sysctl hw
hw.machine=i386
hw.model=VIA Eden Processor 1000MHz (CentaurHauls 686-class)
hw.ncpu=1
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=wd0
hw.diskcount=1
hw.sensors.fins0.temp0=29.00 degC
hw.sensors.fins0.temp1=26.00 degC
hw.sensors.fins0.temp2=109.00 degC
hw.sensors.fins0.fan0=6849 RPM
hw.sensors.fins0.volt0=3.39 VDC (+3.3V)
hw.sensors.fins0.volt1=0.85 VDC (Vtt)
hw.sensors.fins0.volt2=1.44 VDC (Vram)
hw.sensors.fins0.volt3=1.66 VDC (Vchips)
hw.sensors.fins0.volt4=5.13 VDC (+5V)
hw.sensors.fins0.volt5=11.97 VDC (+12V)
hw.sensors.fins0.volt6=1.11 VDC (+1.5V)
hw.sensors.fins0.volt7=1.08 VDC (Vcore)
hw.sensors.fins0.volt8=5.05 VDC (Vsb)
hw.cpuspeed=1001
hw.setperf=58
hw.product=CN700-8237
hw.uuid=Not Set
hw.physmem=1005023232
hw.usermem=1005010944
hw.ncpufound=1

--
Destan YILANCI
www.parta.com.tr

[PATCH] Add product name for Radeon Mobility 4200 series cards.

2010-09-28 Thread Brynet 
Morning,

I recently picked up a new (..well, to me) Acer Aspire 5551 notebook
which includes an ATI Mobility Radeon 4250, it seems all 42xx mobility
series cards use the same product ID so the following patch just calls
them all 4200.

In the latest amd64 snapshot the xf86-video-ati driver is a little out
of date, doesn't entirely recognize this family yet.

So, drm(4) is never opened.. but modsetting works and I get a nice
widescreen desktop (1366x768) on a 15.6 16:9 screen.

If I go beyond the unsupported and build 6.13.1 (..with non-kms fix from
git) it opens drm(4) and 2D/Xv start working.. but there doesn't appear
to be a r600 DRI module included yet.

http://brynet.biz.tm/~brynet/dmesg_acer.txt
http://brynet.biz.tm/~brynet/new_acer_dmesg.txt

Apologies, It's my first computer from this decade. :-)

Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1572
diff -u -r1.1572 pcidevs
--- dev/pci/pcidevs 21 Sep 2010 11:41:34 -  1.1572
+++ dev/pci/pcidevs 27 Sep 2010 07:53:02 -
@@ -1355,6 +1355,7 @@
 product ATI RADEON_HD3300  0x9614  Radeon HD 3300
 product ATI RADEON_HD4200_HDA  0x970f  Radeon HD 4200 HD Audio
 product ATI RADEON_HD4200  0x9710  Radeon HD 4200
+product ATI RADEON_HD4200_M0x9712  Mobility Radeon HD 4200
 product ATI RADEON_HD2600_HDA  0xaa08  Radeon HD 2600 HD Audio
 product ATI RS690M_HDA 0xaa10  RS690M HD Audio
 product ATI RADEON_HD3870_HDA  0x0018  Radeon HD 3870 HD Audio
Index: dev/pci/drm/radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.50
diff -u -r1.50 radeon_drv.c
--- dev/pci/drm/radeon_drv.c8 Sep 2010 17:19:15 -   1.50
+++ dev/pci/drm/radeon_drv.c27 Sep 2010 07:53:03 -
@@ -524,6 +524,8 @@
CHIP_RV770|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4200,
CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
+   {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4200_M,
+   CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
 {0, 0, 0}
 };

fix various TCP issues

2010-09-28 Thread Claudio Jeker 
The new tcp send/recv socket buffer scaling uncovered a few bugs in our
stack that seem to be around for some time but were well hidden.

First hunk removes a totaly incorrect call of tcp_rscale(). It is not
allowed to recalculate the receive scaling value after the initial SYN
packet. We need to stick to the value the syncache calculated.
Because of this our window updates are totaly wrong which results in a lot
of data after window packets.

The second part has todo with the syncache not properly initializing the
initial TCP timestamp and by that causing havok in 50% of all connections
(because of the timestamp modulation). This results in non working receive
side buffer scaling and probably other nasty effects.
Just to be sure I also make sure that we do not use stack garbage in the
dummy tcpcb we pass to tcp_dooptions() in syn_cache_add().

This problems can be triggered by using tcpbench over the loopback.
-- 
:wq Claudio

Index: tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.236
diff -u -p -r1.236 tcp_input.c
--- tcp_input.c 24 Sep 2010 02:59:45 -  1.236
+++ tcp_input.c 28 Sep 2010 16:27:14 -
@@ -765,11 +768,6 @@ findpcb:
if (tp == NULL)
goto badsyn;/*XXX*/
 
-   /*
-* Compute proper scaling
-* value from buffer space
-*/
-   tcp_rscale(tp, 
so-so_rcv.sb_hiwat);
goto after_listen;
}
} else {
@@ -3813,6 +3812,7 @@ syn_cache_get(struct sockaddr *src, stru
 #endif
 
tp-ts_modulate = sc-sc_modulate;
+   tp-ts_recent = sc-sc_timestamp;
tp-iss = sc-sc_iss;
tp-irs = sc-sc_irs;
tcp_sendseqinit(tp);
@@ -3993,6 +3993,7 @@ syn_cache_add(struct sockaddr *src, stru
 #else
if (optp) {
 #endif
+   bzero(tb, sizeof(tb));
tb.pf = tp-pf;
 #ifdef TCP_SACK
tb.sack_enable = tp-sack_enable;

Re: Handling sysctl hw.serialno

2010-09-28 Thread Ted Unangst 
You're asking why something that doesn't exist can't be found?  It
can't be found because it doesn't exist.

What would you like the sysctl to return if there's no serialno?

On Tue, Sep 28, 2010 at 10:36 AM, Destan YILANCI (Parta)
dyila...@parta.com.tr wrote:
 Hello Everyone,

 I want to get serial number of hardware with handling sysctl. I've got a
 little code below:

 #include stdio.h
 #include string.h
 #include errno.h
 #include sys/param.h
 #include sys/sysctl.h

 int main(int argc, char **argv)
 {
char cpubuf[1024];
size_t len;
int mib[5];

mib[0] = CTL_HW;
mib[1] = HW_SERIALNO;
len = sizeof(cpubuf);
if (sysctl(mib, 2, cpubuf, len, NULL, 0) == -1) {
printf(HW_SERIALNO %s\n, strerror(errno));
return(1);
}

printf(cpu: %s\n, cpubuf);

return 0;
 }

 But i realized that some of my machines cant get sysctl hw.serialno so
 it's normal that C code fails with this error message : HW_SERIALNO
 Operation not supported

 So if we return to the source, why sysctl cant handle some of hardware
 serial numbers?

 Thank you.

 P.S.
 I want to provide a working sysctl.hw ouput here:
 hw.machine=i386
 hw.model=Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (GenuineIntel 686-class)
 hw.ncpu=8
 hw.byteorder=1234
 hw.pagesize=4096
 hw.disknames=sd0,sd1,sd2,sd3,sd4,cd0
 hw.diskcount=6
 hw.sensors.cpu0.temp0=44.00 degC
 hw.sensors.mpi0.drive0=online (sd0), OK
 hw.cpuspeed=2827
 hw.setperf=99
 hw.vendor=Sun Microsystems
 hw.product=Sun Fire X4150
 hw.serialno=2029QTF0814MR0GYD
 hw.uuid=6236f661-097a-0010-915a-001e682f5f0c
 hw.physmem=3757338624
 hw.usermem=3756867584
 hw.ncpufound=8

 And here is a not working hw.serialno :
 # sysctl hw
 hw.machine=i386
 hw.model=AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (AuthenticAMD
 686-class, 512KB L2 cache)
 hw.ncpu=2
 hw.byteorder=1234
 hw.pagesize=4096
 hw.disknames=cd0,wd0
 hw.diskcount=2
 hw.sensors.acpitz0.temp0=40.00 degC (zone temperature)
 hw.sensors.aibs0.temp0=34.00 degC (CPU Temperature), OK
 hw.sensors.aibs0.temp1=43.00 degC (MB Temperature), OK
 hw.sensors.aibs0.fan0=1288 RPM (CPU FAN Speed), WARNING
 hw.sensors.aibs0.fan1=1138 RPM (CHASSIS FAN Speed), WARNING
 hw.sensors.aibs0.volt0=1.27 VDC (Vcore Voltage), WARNING
 hw.sensors.aibs0.volt1=3.18 VDC ( +3.3 Voltage), OK
 hw.sensors.aibs0.volt2=4.98 VDC ( +5.0 Voltage), OK
 hw.sensors.aibs0.volt3=11.98 VDC (+12.0 Voltage), OK
 hw.sensors.kate0.temp0=36.00 degC
 hw.sensors.kate0.temp2=35.00 degC
 hw.sensors.it0.temp0=34.00 degC
 hw.sensors.it0.temp1=43.00 degC
 hw.sensors.it0.temp2=25.00 degC
 hw.sensors.it0.fan0=1288 RPM
 hw.sensors.it0.fan1=1138 RPM
 hw.sensors.it0.fan2=0 RPM
 hw.sensors.it0.volt0=1.12 VDC (VCORE_A)
 hw.sensors.it0.volt1=3.18 VDC (VCORE_B)
 hw.sensors.it0.volt2=0.00 VDC (+3.3V)
 hw.sensors.it0.volt3=4.78 VDC (+5V)
 hw.sensors.it0.volt4=11.58 VDC (+12V)
 hw.sensors.it0.volt5=-17.00 VDC (-12V)
 hw.sensors.it0.volt6=-8.60 VDC (-5V)
 hw.sensors.it0.volt7=4.57 VDC (+5VSB)
 hw.sensors.it0.volt8=2.88 VDC (VBAT)
 hw.cpuspeed=2010
 hw.setperf=100
 hw.vendor=ASUSTek Computer INC.
 hw.product=M2NPV-VM
 hw.uuid=----
 hw.physmem=1038643200
 hw.usermem=1038565376
 hw.ncpufound=2

 Any other not working output is also here:
 # sysctl hw
 hw.machine=i386
 hw.model=VIA Eden Processor 1000MHz (CentaurHauls 686-class)
 hw.ncpu=1
 hw.byteorder=1234
 hw.pagesize=4096
 hw.disknames=wd0
 hw.diskcount=1
 hw.sensors.fins0.temp0=29.00 degC
 hw.sensors.fins0.temp1=26.00 degC
 hw.sensors.fins0.temp2=109.00 degC
 hw.sensors.fins0.fan0=6849 RPM
 hw.sensors.fins0.volt0=3.39 VDC (+3.3V)
 hw.sensors.fins0.volt1=0.85 VDC (Vtt)
 hw.sensors.fins0.volt2=1.44 VDC (Vram)
 hw.sensors.fins0.volt3=1.66 VDC (Vchips)
 hw.sensors.fins0.volt4=5.13 VDC (+5V)
 hw.sensors.fins0.volt5=11.97 VDC (+12V)
 hw.sensors.fins0.volt6=1.11 VDC (+1.5V)
 hw.sensors.fins0.volt7=1.08 VDC (Vcore)
 hw.sensors.fins0.volt8=5.05 VDC (Vsb)
 hw.cpuspeed=1001
 hw.setperf=58
 hw.product=CN700-8237
 hw.uuid=Not Set
 hw.physmem=1005023232
 hw.usermem=1005010944
 hw.ncpufound=1

 --
 Destan YILANCI
 www.parta.com.tr

CONFIRMATION D'ABONNNEMENT A LA GOUVLETTER

2010-09-28 Thread CICG (Centre d'Information et de Communication Gouvernementale) 
Visitez le portail officiel du ( http://www.gouv.ci/index.php; ) Gouvernement
de Ctte d'Ivoire, Cliquez ici ( http://www.gouv.ci; )  
( http://www.gouv.ci; )

FORMULAIRE D'ABONNEMENT


 


Dans le cadre de la diffusion de l'information gouvernementale, le C.I.C.G
(Centre d'Information et de Communication Gouvernementale) a mis sur pied une
panoplie d'outils au nombre desquels la +Gouvletter; (Newsletter du
Gouvernement de la Ripublique de Ctte d'Ivoire).
En vue de filtrer notre liste de contact et iviter que vous  receviez des
courriers non sollicitis, nous vous serons gri de bien vouloir remplir ce
formulaire.



 Disirez-vous continuer ` recevoir la Gouvletter (Newsletter du gouvernement
de la Ripublique de Ctte d'Ivoire) ?



Cliquez ici pour vous disabonner

  

 Cliquez ici pour vous (re)abonner ( http://www.gouv.ci/index.php; )

( http://www.gouv.ci/index.php; )




 




LA COMMUNICATION AU COEUR DE L'ACTION GOUVERNEMENTALE
( http://www.gouv.ci; )   Continuez de nous faire part de vos suggestions (
http://www.gouv.ci/webmaster.php; ). 
Merci ` toutes celles et tous ceux qui nous ont dij` icrit !



 

Si vous ne souhaitez plus recevoir notre lettre d'informations, cliquez ici
pour vous disabonner
 

[demime 1.01d removed an attachment of type image/png which had a name of 
=?iso-8859-1?Q?accept.png?=]

[demime 1.01d removed an attachment of type image/png which had a name of 
=?iso-8859-1?Q?delete.png?=]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
=?iso-8859-1?Q?gouvletter.jpg?=]

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
=?iso-8859-1?Q?logo.jpg?=]

glxpcib unification

2010-09-28 Thread Paul Irofti 
This is the first step into moving the glxpcib driver into MI land. 

The following diff brings the loongson and i386 drivers as close
together as possible. The only difference after applying the diff are
some defines which are already handled properly (from an MI point of
view) in loongson/dev/glxreg.h.

So once this gets in we can move that header into MI land as well and
have the same driver for both architectures -- this is step two of
course.

Please test and comment.

Index: i386/pci/glxpcib.c
===
RCS file: /cvs/src/sys/arch/i386/pci/glxpcib.c,v
retrieving revision 1.13
diff -u -p -r1.13 glxpcib.c
--- i386/pci/glxpcib.c  24 Sep 2010 10:30:29 -  1.13
+++ i386/pci/glxpcib.c  28 Sep 2010 18:35:55 -
@@ -24,12 +24,15 @@
 
 #include sys/param.h
 #include sys/systm.h
+#include sys/proc.h
 #include sys/device.h
 #include sys/gpio.h
 #include sys/timetc.h
 
 #include machine/bus.h
+#ifdef __i386__
 #include machine/cpufunc.h
+#endif
 
 #include dev/gpio/gpiovar.h
 #include dev/pci/pcireg.h
@@ -125,6 +128,15 @@
 #define AMD5536_GPIO_IN_INVRT_EN 0x24  /* invert input */
 #defineAMD5536_GPIO_READ_BACK  0x30/* read back value */
 
+/*
+ * MSR registers we want to preserve accross suspend/resume
+ */
+const uint32_t glxpcib_msrlist[] = {
+   GLIU_PAE,
+   GLCP_GLD_MSR_PM,
+   DIVIL_BALL_OPTS
+};
+
 struct glxpcib_softc {
struct device   sc_dev;
 
@@ -132,7 +144,9 @@ struct glxpcib_softc {
bus_space_tag_t sc_iot;
bus_space_handle_t  sc_ioh;
 
-#ifndef SMALL_KERNEL
+   uint64_tsc_msrsave[nitems(glxpcib_msrlist)];
+
+#if !defined(SMALL_KERNEL)  NGPIO  0
/* GPIO interface */
bus_space_tag_t sc_gpio_iot;
bus_space_handle_t  sc_gpio_ioh;
@@ -160,12 +174,12 @@ struct cfattach glxpcib_ca = {
 void   pcibattach(struct device *parent, struct device *self, void *aux);
 
 u_int  glxpcib_get_timecount(struct timecounter *tc);
-#ifndef SMALL_KERNEL
-int glxpcib_wdogctl_cb(void *, int);
 
+#if !defined(SMALL_KERNEL)  NGPIO  0
+void   glxpcib_gpio_pin_ctl(void *, int, int);
 intglxpcib_gpio_pin_read(void *, int);
 void   glxpcib_gpio_pin_write(void *, int, int);
-void   glxpcib_gpio_pin_ctl(void *, int, int);
+int glxpcib_wdogctl_cb(void *, int);
 #endif
 
 const struct pci_matchid glxpcib_devices[] = {
@@ -176,8 +190,10 @@ int
 glxpcib_match(struct device *parent, void *match, void *aux)
 { 
if (pci_matchbyid((struct pci_attach_args *)aux, glxpcib_devices,
-   sizeof(glxpcib_devices) / sizeof(glxpcib_devices[0])))
+   nitems(glxpcib_devices))) {
+   /* needs to win over pcib */
return 2;
+   }
 
return 0;
 }
@@ -187,18 +203,21 @@ glxpcib_attach(struct device *parent, st
 {
struct glxpcib_softc *sc = (struct glxpcib_softc *)self;
struct timecounter *tc = sc-sc_timecounter;
-#ifndef SMALL_KERNEL
-   struct pci_attach_args *pa = aux;
+#ifndef !defined(SMALL_KERNEL)  NGPIO  0
+   struct pci_attach_args *pa = (struct pci_attach_args *)aux;
u_int64_t wa, ga;
struct gpiobus_attach_args gba;
int i, gpio = 0;
 #endif
-
tc-tc_get_timecount = glxpcib_get_timecount;
tc-tc_counter_mask = 0x;
tc-tc_frequency = 3579545;
tc-tc_name = CS5536;
+#ifdef __loongson__
+   tc-tc_quality = 0;
+#else
tc-tc_quality = 1000;
+#endif
tc-tc_priv = sc;
tc_init(tc);
 
@@ -206,14 +225,13 @@ glxpcib_attach(struct device *parent, st
(int)rdmsr(AMD5536_REV)  AMD5536_REV_MASK,
tc-tc_frequency);
 
-#ifndef SMALL_KERNEL
+#if !defined(SMALL_KERNEL)  NGPIO  0
/* Attach the watchdog timer */
sc-sc_iot = pa-pa_iot;
wa = rdmsr(MSR_LBAR_MFGPT);
if (wa  MSR_LBAR_ENABLE 
!bus_space_map(sc-sc_iot, wa  MSR_MFGPT_ADDR_MASK,
MSR_MFGPT_SIZE, 0, sc-sc_ioh)) {
-
/* count in seconds (as upper level desires) */
bus_space_write_2(sc-sc_iot, sc-sc_ioh, AMD5536_MFGPT0_SETUP,
AMD5536_MFGPT_CNT_EN | AMD5536_MFGPT_CMP2EV |
@@ -259,7 +277,8 @@ glxpcib_attach(struct device *parent, st
}
 #endif
pcibattach(parent, self, aux);
-#ifndef SMALL_KERNEL
+
+#if !defined(SMALL_KERNEL)  NGPIO  0
if (gpio)
config_found(sc-sc_dev, gba, gpiobus_print);
 #endif
@@ -272,6 +291,7 @@ glxpcib_activate(struct device *self, in
struct glxpcib_softc *sc = (struct glxpcib_softc *)self;
 #endif
int rv = 0;
+   uint i;
 
switch (act) {
case DVACT_QUIESCE:
@@ -286,12 +306,17 @@ glxpcib_activate(struct device *self, in
}
 #endif
rv = config_activate_children(self, act);
+   for (i = 0; i  nitems(glxpcib_msrlist); i++)
+   sc-sc_msrsave[i] =

Re: glxpcib unification

2010-09-28 Thread Miod Vallat 
 This is the first step into moving the glxpcib driver into MI land. 
 
 The following diff brings the loongson and i386 drivers as close
 together as possible. The only difference after applying the diff are
 some defines which are already handled properly (from an MI point of
 view) in loongson/dev/glxreg.h.
 
 So once this gets in we can move that header into MI land as well and
 have the same driver for both architectures -- this is step two of
 course.

I suggested a similar diff some time ago, and I have changed my mind
about this. I am strongly opposing unification beyond register defines
in a separate header.

In the long term, we will not be using the geode chip in the same way
between loongson and i386 (if only because of clock programming), so
either we share a common glxpcib which acts as a pcib device and nothing
else, and attach other drivers to provide e.g. watchdog functionality,
or we do not share the code.

Miod

Re: glxpcib unification

2010-09-28 Thread Paul Irofti 
On Tue, Sep 28, 2010 at 06:51:07PM +, Miod Vallat wrote:
  This is the first step into moving the glxpcib driver into MI land. 
  
  The following diff brings the loongson and i386 drivers as close
  together as possible. The only difference after applying the diff are
  some defines which are already handled properly (from an MI point of
  view) in loongson/dev/glxreg.h.
  
  So once this gets in we can move that header into MI land as well and
  have the same driver for both architectures -- this is step two of
  course.
 
 I suggested a similar diff some time ago, and I have changed my mind
 about this. I am strongly opposing unification beyond register defines
 in a separate header.
 
 In the long term, we will not be using the geode chip in the same way
 between loongson and i386 (if only because of clock programming), so
 either we share a common glxpcib which acts as a pcib device and nothing
 else, and attach other drivers to provide e.g. watchdog functionality,
 or we do not share the code.

I prefer the attach other drivers approach. But I don't have strong
feelings about it. Seems cleaner to me and easier to maintain.

Re: merge pms and pmsi + added support for some of mouse

2010-09-28 Thread Alexandr Shadchin 
On Mon, Sep 27, 2010 at 01:10:58PM -0700, Matthew Dempsky wrote:
 On Mon, Sep 27, 2010 at 10:42 AM, Alexandr Shadchin
 alexandr.shadc...@gmail.com wrote:
 if (pa-pa_slot != PCKBC_AUX_SLOT)
  -return (0);
  +return 0;
 
 return (x) is proper KNF.  Please don't undo it.

I have recently seen more often return without the brackets, so I decided 
that this is correct. For me, with or without the brackets do not matter.
So back braces or not?

-- 
Alexandr Shadchin

Re: merge pms and pmsi + added support for some of mouse

2010-09-28 Thread Theo de Raadt 
 On Mon, Sep 27, 2010 at 01:10:58PM -0700, Matthew Dempsky wrote:
  On Mon, Sep 27, 2010 at 10:42 AM, Alexandr Shadchin
  alexandr.shadc...@gmail.com wrote:
  if (pa-pa_slot != PCKBC_AUX_SLOT)
   -return (0);
   +return 0;
  
  return (x) is proper KNF.  Please don't undo it.
 
 I have recently seen more often return without the brackets, so I decided 
 that this is correct. For me, with or without the brackets do not matter.
 So back braces or not?

Do whatever you want and ignore the people on the mailing list who are
NOT DEVELOPERS.

Re: merge pms and pmsi + added support for some of mouse

2010-09-28 Thread Mark Kettenis 
 Date: Wed, 29 Sep 2010 03:21:21 +0600
 From: Alexandr Shadchin alexandr.shadc...@gmail.com
 
 On Mon, Sep 27, 2010 at 01:10:58PM -0700, Matthew Dempsky wrote:
  On Mon, Sep 27, 2010 at 10:42 AM, Alexandr Shadchin
  alexandr.shadc...@gmail.com wrote:
  if (pa-pa_slot != PCKBC_AUX_SLOT)
   -return (0);
   +return 0;
  
  return (x) is proper KNF.  Please don't undo it.
 
 I have recently seen more often return without the brackets, so I decided 
 that this is correct. For me, with or without the brackets do not matter.
 So back braces or not?

I'd say, don't arbitrarily change them, and try to keep things
consistent with the code around it.

Helping You Improve Eye Sight - Naturally!

2010-09-28 Thread Dr. William H. Bates 
Helping You Improve Eye Sight - Naturally!

Don't Let Your Vision Problems Stop You From Living A Care-Free Life
If Glasses and Contacts Harms Vision and Surgery Is Too Risky, Then How Can I 
Improve My Eyesight?

Click here : http://money-wall.com/index.php/improve-eye-sight