driverfs support for motherboard devices

driverfs support for motherboard devices

[Pavel Machek]

Hi!

This patch adds support for motherboard devices, so that you can see
them in driverfs.

Should ide be presented to driverfs as bus with two devices on it?

What about "legacy" bus? It is not in this release, and I'm not 100%
sure who should generate it. Many architectures will need such bus so
maybe it belongs in drivers/base in order to avoid duplicate code?

								Pavel


--- clean/arch/i386/kernel/i8259.c	Thu Jan 31 23:42:10 2002
+++ linux-dm/arch/i386/kernel/i8259.c	Tue Feb  5 18:20:43 2002
@@ -11,6 +11,7 @@
 #include <linux/smp_lock.h>
 #include <linux/init.h>
 #include <linux/kernel_stat.h>
+#include <linux/device.h>
 
 #include <asm/atomic.h>
 #include <asm/system.h>
@@ -333,6 +334,18 @@
 		goto handle_real_irq;
 	}
 }
+
+static struct device device_i8259A;
+
+static void __init init_8259A_devicefs(void)
+{
+	device_register(&device_i8259A);
+	strcpy(device_i8259A.name, "i8259A");
+	strcpy(device_i8259A.bus_id, "0020");
+	device_i8259A.parent = &sys_iobus;
+}
+
+__initcall(init_8259A_devicefs);
 
 void __init init_8259A(int auto_eoi)
 {
--- clean/arch/i386/kernel/time.c	Thu Jan 31 23:42:10 2002
+++ linux-dm/arch/i386/kernel/time.c	Tue Feb  5 18:21:34 2002
@@ -41,6 +41,7 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/smp.h>
+#include <linux/device.h>
 
 #include <asm/io.h>
 #include <asm/smp.h>
@@ -633,6 +634,18 @@
 bad_ctc:
 	return 0;
 }
+
+static struct device device_i8253;
+
+static void time_init_driverfs(void)
+{
+	strcpy(device_i8253.name, "i8253");
+	strcpy(device_i8253.bus_id, "0040");
+	device_i8253.parent = &sys_iobus;
+	device_register(&device_i8253);
+}
+
+__initcall(time_init_driverfs);
 
 void __init time_init(void)
 {
--- clean/drivers/base/core.c	Thu Jan 31 23:42:12 2002
+++ linux-dm/drivers/base/core.c	Tue Feb  5 18:19:42 2002
@@ -182,6 +182,16 @@
 	return iobus_register(&device_root);
 }
 
+
+struct iobus sys_iobus;
+
+void __init device_init_sys(void)
+{
+     sprintf(sys_iobus.name,"Bus for motherboard and strange devices");
+     sprintf(sys_iobus.bus_id,"sys");
+     iobus_register(&sys_iobus);
+}
+
 int __init device_driver_init(void)
 {
 	int error = 0;
@@ -203,6 +213,7 @@
 		return error;
 	}
 
+	device_init_sys();
 	DBG("DEV: Done Initialising\n");
 	return error;
 }
--- clean/drivers/block/floppy.c	Sun Jan 20 22:36:55 2002
+++ linux-dm/drivers/block/floppy.c	Mon Feb  4 23:05:09 2002
@@ -167,6 +167,7 @@
 #include <linux/interrupt.h>
 #include <linux/init.h>
 #include <linux/devfs_fs_kernel.h>
+#include <linux/device.h>
 
 /*
  * PS/2 floppies have much slower step rates than regular floppies.
@@ -4148,11 +4149,16 @@
 
 static int have_no_fdc= -ENODEV;
 
+static struct device device_floppy;
 
 int __init floppy_init(void)
 {
 	int i,unit,drive;
 
+	strcpy(device_floppy.name, "floppy");
+	strcpy(device_floppy.bus_id, "03?0");
+	device_floppy.parent = &sys_iobus;
+	device_register(&device_floppy);
 
 	raw_cmd = NULL;
 
--- clean/drivers/ide/ide-disk.c	Thu Jan 31 23:42:14 2002
+++ linux-dm/drivers/ide/ide-disk.c	Mon Feb  4 23:05:09 2002
@@ -818,6 +818,23 @@
 
 #endif	/* CONFIG_PROC_FS */
 
+static int idedisk_suspend (ide_drive_t *drive, u32 state, u32 stage)
+{
+	/* During S4, interrupt might be pending over resume. If it hits us and we 
+	   think it is completion interrupt from something started between suspend,
+	   we'll destroy data. Don't do that. */
+	if (state == 4)
+		return -EINVAL;
+	return 0;
+}
+
+static int idedisk_resume (ide_drive_t *drive, u32 stage)
+{
+	return 0;
+}
+
+
+
 /*
  * This is tightly woven into the driver->do_special can not touch.
  * DON'T do it again until a total personality rewrite is committed.
@@ -1082,6 +1099,8 @@
 	special:		idedisk_special,
 	proc:			idedisk_proc,
 	driver_reinit:		idedisk_reinit,
+	suspend:		idedisk_suspend,
+	resume:			idedisk_resume,
 };
 
 int idedisk_init (void);
--- clean/drivers/ide/ide-probe.c	Thu Jan 31 23:42:14 2002
+++ linux-dm/drivers/ide/ide-probe.c	Tue Feb  5 18:26:42 2002
@@ -467,8 +467,39 @@
 	return(region_errors);
 }
 
+int ide_hwif_suspend(struct device * dev, u32 state, u32 stage)
+{
+	int i, res = 0;
+	ide_hwif_t *hwif = dev->driver_data;
+
+	for (i=0; i<MAX_DRIVES; i++) {
+		if (hwif->drives[i].driver->suspend)
+			res = hwif->drives[i].driver->suspend(hwif->drives+i, state, stage);
+		if (res)
+			return res;
+	}
+	return 0;
+}
+
+int ide_hwif_resume(struct device * dev, u32 stage)
+{
+	ide_hwif_t *hwif = dev->driver_data;
+	return 0;
+}
+
+struct device_driver ide_device_driver = {
+	suspend:	ide_hwif_suspend,
+	resume:		ide_hwif_resume,	
+};
+
 static void hwif_register (ide_hwif_t *hwif)
 {
+	sprintf(hwif->device.bus_id, "%04x", hwif->io_ports[IDE_DATA_OFFSET]);
+	sprintf(hwif->device.name, "ide");
+	hwif->device.driver = &ide_device_driver;
+	hwif->device.driver_data = hwif;
+	hwif->device.parent = &sys_iobus;
+	device_register(&hwif->device);
 	if (((unsigned long)hwif->io_ports[IDE_DATA_OFFSET] | 7) ==
 	    ((unsigned long)hwif->io_ports[IDE_STATUS_OFFSET])) {
 		ide_request_region(hwif->io_ports[IDE_DATA_OFFSET], 8, hwif->name);
--- clean/drivers/ide/ide-proc.c	Thu Jan 31 23:42:14 2002
+++ linux-dm/drivers/ide/ide-proc.c	Mon Feb  4 23:05:09 2002
@@ -591,13 +591,13 @@
 	(char *page, char **start, off_t off, int count, int *eof, void *data)
 {
 	ide_drive_t	*drive = (ide_drive_t *) data;
-	ide_driver_t    *driver = (ide_driver_t *) drive->driver;
+	ide_driver_t    *driver = drive->driver;
 	int		len;
 
 	if (!driver)
 		len = sprintf(page, "(none)\n");
         else
-		len = sprintf(page,"%llu\n", (__u64) ((ide_driver_t *)drive->driver)->capacity(drive));
+		len = sprintf(page,"%llu\n", (__u64) drive->driver->capacity(drive));
 	PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
 }
 
@@ -629,7 +629,7 @@
 	(char *page, char **start, off_t off, int count, int *eof, void *data)
 {
 	ide_drive_t	*drive = (ide_drive_t *) data;
-	ide_driver_t	*driver = (ide_driver_t *) drive->driver;
+	ide_driver_t	*driver = drive->driver;
 	int		len;
 
 	if (!driver)

diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinux -x vmlinuz -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/include/linux/device.h linux-dm/include/linux/device.h
--- clean/include/linux/device.h	Thu Jan 31 23:42:28 2002
+++ linux-dm/include/linux/device.h	Mon Feb  4 23:05:09 2002
@@ -209,5 +209,6 @@
 }
 
 extern void put_iobus(struct iobus * iobus);
+extern struct iobus sys_iobus;
 
 #endif /* _DEVICE_H_ */
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinux -x vmlinuz -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/include/linux/ide.h linux-dm/include/linux/ide.h
--- clean/include/linux/ide.h	Thu Jan 31 23:42:29 2002
+++ linux-dm/include/linux/ide.h	Mon Feb  4 23:05:09 2002
@@ -14,6 +14,7 @@
 #include <linux/blkdev.h>
 #include <linux/proc_fs.h>
 #include <linux/devfs_fs_kernel.h>
+#include <linux/device.h>
 #include <asm/hdreg.h>
 
 /*
@@ -424,12 +425,12 @@
 	unsigned long	capacity;	/* total number of sectors */
 	unsigned long long capacity48;	/* total number of sectors */
 	unsigned int	drive_data;	/* for use by tuneproc/selectproc as needed */
-	void		  *hwif;	/* actually (ide_hwif_t *) */
+	struct ide_hwif_s *hwif;	/* actually (ide_hwif_t *) */
 	wait_queue_head_t wqueue;	/* used to wait for drive in open() */
 	struct hd_driveid *id;		/* drive model identification info */
 	struct hd_struct  *part;	/* drive partition table */
 	char		name[4];	/* drive name, such as "hda" */
-	void 		*driver;	/* (ide_driver_t *) */
+	struct ide_driver_s *driver;	/* (ide_driver_t *) */
 	void		*driver_data;	/* extra driver data */
 	devfs_handle_t	de;		/* directory for device */
 	struct proc_dir_entry *proc;	/* /proc/ide/ directory entry */
@@ -580,6 +581,7 @@
 	void		*hwif_data;	/* extra hwif data */
 	ide_busproc_t	*busproc;	/* driver soft-power interface */
 	byte		bus_state;	/* power state of the IDE bus */
+	struct device	device;
 } ide_hwif_t;
 
 /*
@@ -718,6 +720,8 @@
 typedef ide_startstop_t	(ide_special_proc)(ide_drive_t *);
 typedef void		(ide_setting_proc)(ide_drive_t *);
 typedef int		(ide_driver_reinit_proc)(ide_drive_t *);
+typedef int		(ide_suspend_proc)(ide_drive_t *, u32 state, u32 stage);
+typedef int		(ide_resume_proc)(ide_drive_t *, u32 stage);
 
 typedef struct ide_driver_s {
 	const char			*name;
@@ -741,6 +745,8 @@
 	ide_special_proc		*special;
 	ide_proc_entry_t		*proc;
 	ide_driver_reinit_proc		*driver_reinit;
+	ide_suspend_proc		*suspend;
+	ide_resume_proc			*resume;
 } ide_driver_t;
 
 #define DRIVER(drive)		((ide_driver_t *)((drive)->driver))

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: driverfs support for motherboard devices

[Xavier Bestel]

le mar 05-02-2002 à 18:39, Pavel Machek a écrit :

> +void __init device_init_sys(void)
> +{
> +     sprintf(sys_iobus.name,"Bus for motherboard and strange devices");

Don't you fear that, with such a vague name, it'll end up being used as
a generic thing where all not-well-defined hacks will end ? (à la
procfs)

	Xav

Re: driverfs support for motherboard devices

[Zwane Mwaikambo]

On 5 Feb 2002, Xavier Bestel wrote:

> le mar 05-02-2002 à 18:39, Pavel Machek a écrit :
> 
> > +void __init device_init_sys(void)
> > +{
> > +     sprintf(sys_iobus.name,"Bus for motherboard and strange devices");
> 
> Don't you fear that, with such a vague name, it'll end up being used as
> a generic thing where all not-well-defined hacks will end ? (à la
> procfs)

How about s/strange/system/

Regards,
	Zwane Mwaikambo

Re: driverfs support for motherboard devices

[Jeff Garzik]

Pavel Machek wrote:
> 
> Hi!
> 
> This patch adds support for motherboard devices, so that you can see
> them in driverfs.
> 
> Should ide be presented to driverfs as bus with two devices on it?

This is a tough one...  Since there is a typically a single PCI device
for IDE, a PCI or HOST bridge should register an IDE device.  The IDE
device would in turn register two IDE controllers, which would in turn
register up to two disks.

> What about "legacy" bus? It is not in this release, and I'm not 100%
> sure who should generate it. Many architectures will need such bus so
> maybe it belongs in drivers/base in order to avoid duplicate code?

I think one should have a conceptual "system bus" as a virtual parent,
when none is present.  For example my old 486 has PCI, but the only PCI
device is IDE.  There are the standard legacy devices like parallel and
serial, but they do not show up under an ISA bridge device.  This 486
system would be a candidate for this system bus.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: driverfs support for motherboard devices

[Patrick Mochel]

Hi Pavel,

On Tue, 5 Feb 2002, Pavel Machek wrote:

> Hi!
> 
> This patch adds support for motherboard devices, so that you can see
> them in driverfs.
> 
> Should ide be presented to driverfs as bus with two devices on it?

I think that ide should get its own bus, as a child of the ide controller. 
I haven't looked at ide yet at all. But, on most modern systems, the ide 
controller is a function of the southbridge, so ide devices should go 
under that. Like what the usb stuff does now...

> 
> What about "legacy" bus? It is not in this release, and I'm not 100%
> sure who should generate it. Many architectures will need such bus so
> maybe it belongs in drivers/base in order to avoid duplicate code?

I've had this actually in my queue for some time, though I've been 
waititng for some of the other changes to go in (most of which went in to 
2.5.3).

Adding simple legacy and system device support is trivial - patches are 
attached. Basically, you would do something like:

static struct device old_legacy_device = {
	bus_id:		"artifact",
	name:		"Some old device that someone is still using",
};

old_dev_init() 
{
	...
	register_legacy_device(&old_legacy_device);
}


And it shows up as $MNTPT/root/legacy/artifact/

Similarly for system devices with register_sys_device().

Unfortunately, the diff is relative to what I've already sent Linus. He 
says he applied them, so you'll have to wait until 2.4.1-pre1 comes. 

For clarification: 

Legacy devices are typical legacy PC devices, like floppy drives, parallel 
ports, serial ports, etc. They are devices that you can typically access 
through the standard, hardcoded I/O addresses; and without having to 
enable the upstream parents to do so. 

'legacy' is what I've always heard them referred to as, as a whole. The 
name may imply old and/or deprecated, and in a lot of cases they are. But, 
it's a easy, common way to group them.

System devices are devices are attached to the motherboard, but aren't 
typical devices that you would read or write to. Yet, you still want to 
export an interface to them. This includes CPUs, PICs, RTC, etc. 

	-pat

Also included are samples for the keyboard and RTC drivers (keyboard is a 
legacy device, RTC is a system device)

diff -Nur linux-2.5.3.orig/drivers/base/legacy.c linux-2.5.3/drivers/base/legacy.c
--- linux-2.5.3.orig/drivers/base/legacy.c	Wed Dec 31 16:00:00 1969
+++ linux-2.5.3/drivers/base/legacy.c	Tue Feb  5 07:30:48 2002
@@ -0,0 +1,44 @@
+/*
+ * legacy.c - Create bus for legacy devices to attach to
+ * 
+ * Copyright (c) 2002 Patrick Mochel
+ *		 2002 Open Source Development Lab
+ * 
+ * 
+ */
+
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/init.h>
+
+static struct device legacy_bus = { 
+	name:		"Legacy Bus",
+	bus_id:		"legacy",
+};
+
+int register_legacy_device(struct device * dev)
+{
+	int error = -EINVAL;
+	if (dev) {
+		if (!dev->parent)
+			dev->parent = &legacy_bus;
+		error = device_register(dev);
+	}
+	return error;
+}
+
+void unregister_legacy_device(struct device * dev)
+{
+	if (dev)
+		put_device(dev);
+}
+
+static int legacy_bus_init(void)
+{
+	return device_register(&legacy_bus);
+}
+
+subsys_initcall(legacy_bus_init);
+EXPORT_SYMBOL(register_legacy_device);
+EXPORT_SYMBOL(unregister_legacy_device);
diff -Nur linux-2.5.3.orig/drivers/base/Makefile linux-2.5.3/drivers/base/Makefile
--- linux-2.5.3.orig/drivers/base/Makefile	Mon Jan 28 14:50:41 2002
+++ linux-2.5.3/drivers/base/Makefile	Tue Feb  5 10:03:55 2002
@@ -1,7 +1,9 @@
 O_TARGET	:= base.o
 
-obj-y		:= core.o interface.o fs.o
+obj-y		:= core.o interface.o fs.o \
+			sys.o legacy.o
 
-export-objs	:= core.o interface.o fs.o 
+export-objs	:= core.o interface.o fs.o \
+			sys.o legacy.o
 
 include $(TOPDIR)/Rules.make
diff -Nur linux-2.5.3.orig/drivers/base/sys.c linux-2.5.3/drivers/base/sys.c
--- linux-2.5.3.orig/drivers/base/sys.c	Wed Dec 31 16:00:00 1969
+++ linux-2.5.3/drivers/base/sys.c	Tue Feb  5 07:31:01 2002
@@ -0,0 +1,48 @@
+/*
+ * sys.c - pseudo-bus for system 'devices' (cpus, PICs, timers, etc)
+ *
+ * Copyright (c) 2002 Patrick Mochel
+ *		 2002 Open Source Development Lab
+ * 
+ * This exports a 'system' bus type. 
+ * By default, a 'sys' bus gets added to the root of the system. There will
+ * always be core system devices. Devices can use register_sys_device() to
+ * add themselves as children of the system bus.
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+
+static struct device system_bus = {
+	name:		"System Bus",
+	bus_id:		"sys",
+};
+
+int register_sys_device(struct device * dev)
+{
+	int error = -EINVAL;
+
+	if (dev) {
+		if (!dev->parent)
+			dev->parent = &system_bus;
+		error = device_register(dev);
+	}
+	return error;
+}
+
+void unregister_sys_device(struct device * dev)
+{
+	if (dev)
+		put_device(dev);
+}
+
+static int sys_bus_init(void)
+{
+	return device_register(&system_bus);
+}
+
+subsys_initcall(sys_bus_init);
+EXPORT_SYMBOL(register_sys_device);
+EXPORT_SYMBOL(unregister_sys_device);
diff -Nur linux-2.5.3.orig/drivers/char/keyboard.c linux-2.5.3/drivers/char/keyboard.c
--- linux-2.5.3.orig/drivers/char/keyboard.c	Thu Jan 24 13:02:23 2002
+++ linux-2.5.3/drivers/char/keyboard.c	Tue Feb  5 07:41:41 2002
@@ -42,6 +42,7 @@
 #include <linux/kbd_ll.h>
 #include <linux/sysrq.h>
 #include <linux/pm.h>
+#include <linux/device.h>
 
 #define SIZE(x) (sizeof(x)/sizeof((x)[0]))
 
@@ -906,6 +907,11 @@
 
 pm_callback pm_kbd_request_override = NULL;
 
+static struct device kbd_device = {
+	bus_id:	"keyboard",
+	name:	"Keyboard",
+};
+
 int __init kbd_init(void)
 {
 	int i;
@@ -930,6 +936,8 @@
 	tasklet_schedule(&keyboard_tasklet);
 	
 	pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, pm_kbd_request_override);
+
+	register_legacy_device(&kbd_device);
 
 	return 0;
 }
diff -Nur linux-2.5.3.orig/drivers/char/rtc.c linux-2.5.3/drivers/char/rtc.c
--- linux-2.5.3.orig/drivers/char/rtc.c	Thu Jan 24 13:02:23 2002
+++ linux-2.5.3/drivers/char/rtc.c	Tue Feb  5 07:50:35 2002
@@ -67,6 +67,7 @@
 #include <linux/poll.h>
 #include <linux/proc_fs.h>
 #include <linux/spinlock.h>
+#include <linux/device.h>
 
 #include <asm/io.h>
 #include <asm/uaccess.h>
@@ -659,6 +660,11 @@
 	&rtc_fops
 };
 
+static struct device rtc_device = {
+	bus_id:	"rtc",
+	name:	"Real Time Clock",
+};
+
 static int __init rtc_init(void)
 {
 #if defined(__alpha__) || defined(__mips__)
@@ -797,7 +803,7 @@
 	rtc_freq = 1024;
 no_irq2:
 #endif
-
+	register_sys_device(&rtc_device);
 	printk(KERN_INFO "Real Time Clock Driver v" RTC_VERSION "\n");
 
 	return 0;

Re: driverfs support for motherboard devices

[Russell King]

On Tue, Feb 05, 2002 at 10:43:14AM -0800, Patrick Mochel wrote:
> I think that ide should get its own bus, as a child of the ide controller. 
> I haven't looked at ide yet at all. But, on most modern systems, the ide 
> controller is a function of the southbridge, so ide devices should go 
> under that. Like what the usb stuff does now...

What about, say, a Promise PCI IDE card?  You really need to reference
the parent PCI device when the is one.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: driverfs support for motherboard devices

[Andre Hedrick]

On Tue, 5 Feb 2002, Russell King wrote:

> On Tue, Feb 05, 2002 at 10:43:14AM -0800, Patrick Mochel wrote:
> > I think that ide should get its own bus, as a child of the ide controller. 
> > I haven't looked at ide yet at all. But, on most modern systems, the ide 
> > controller is a function of the southbridge, so ide devices should go 
> > under that. Like what the usb stuff does now...
> 
> What about, say, a Promise PCI IDE card?  You really need to reference
> the parent PCI device when the is one.

LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
local BUSS?

Cheers,


Andre Hedrick
Linux Disk Certification Project                Linux ATA Development

Re: driverfs support for motherboard devices

[Joel Jaeggli]

On Tue, 5 Feb 2002, Andre Hedrick wrote:

> On Tue, 5 Feb 2002, Russell King wrote:
> 
> > On Tue, Feb 05, 2002 at 10:43:14AM -0800, Patrick Mochel wrote:
> > > I think that ide should get its own bus, as a child of the ide controller. 
> > > I haven't looked at ide yet at all. But, on most modern systems, the ide 
> > > controller is a function of the southbridge, so ide devices should go 
> > > under that. Like what the usb stuff does now...
> > 
> > What about, say, a Promise PCI IDE card?  You really need to reference
> > the parent PCI device when the is one.
> 
> LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
> local BUSS?
> 
> Cheers,

or an i960rp and 3 promise 20276's, I've got two of those...

joelja
 
> 
> Andre Hedrick
> Linux Disk Certification Project                Linux ATA Development
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   joelja@darkwing.uoregon.edu    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
The accumulation of all powers, legislative, executive, and judiciary, in 
the same hands, whether of one, a few, or many, and whether hereditary, 
selfappointed, or elective, may justly be pronounced the very definition of
tyranny. - James Madison, Federalist Papers 47 -  Feb 1, 1788

Re: driverfs support for motherboard devices

[Alan Cox]

> > > What about, say, a Promise PCI IDE card?  You really need to reference
> > > the parent PCI device when the is one.
> > LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
> > local BUSS?
> 
> or an i960rp and 3 promise 20276's, I've got two of those...

Yep. And then you hit the CRIS where the ide appears to be on the CPU 8)

I don't think anyone should be trying to define where the IDE goes in the
heirarchy like this - its dependant on the situation and the platform.

Alan

Re: driverfs support for motherboard devices

[Patrick Mochel]

On Tue, 5 Feb 2002, Alan Cox wrote:

> > > > What about, say, a Promise PCI IDE card?  You really need to reference
> > > > the parent PCI device when the is one.
> > > LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
> > > local BUSS?
> > 
> > or an i960rp and 3 promise 20276's, I've got two of those...
> 
> Yep. And then you hit the CRIS where the ide appears to be on the CPU 8)
> 
> I don't think anyone should be trying to define where the IDE goes in the
> heirarchy like this - its dependant on the situation and the platform.

Exactly. My point was that based on the situation, you know the hierarchy 
and you can use it. 

	-pat

Re: driverfs support for motherboard devices

[Patrick Mochel]

On Tue, 5 Feb 2002, Andre Hedrick wrote:

> On Tue, 5 Feb 2002, Russell King wrote:
> 
> > On Tue, Feb 05, 2002 at 10:43:14AM -0800, Patrick Mochel wrote:
> > > I think that ide should get its own bus, as a child of the ide controller. 
> > > I haven't looked at ide yet at all. But, on most modern systems, the ide 
> > > controller is a function of the southbridge, so ide devices should go 
> > > under that. Like what the usb stuff does now...
> > 
> > What about, say, a Promise PCI IDE card?  You really need to reference
> > the parent PCI device when the is one.
> 
> LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
> local BUSS?

LOL? I don't understand...

I don't see how any of those cases are necessarily hard to visualize. 

Case 1: Typical PC with IDE as function of southbridge.

pci0
 |
  -- 07.2 (IDE controller)
     |
      --- disk0
     |
      --- disk1

Case 2: Promise IDE Controller with 2 channels


pci0
 |
  --- 03.0 (Promise IDE Controller)
      |
       --- channel0
           |
            ---- disk0
           |
            ---- disk1


Case 3: Quad channel DEC Bridge

Ok, maybe I don't understand completely what you're talking about, Andre. 
That's just a 4 channel IDE controller, that happens to be on the board? 
So, it's looks the same as the last example.

Unless, I'm missing something, which is always likely.

	-pat

Re: driverfs support for motherboard devices

[Joel Jaeggli]

On Tue, 5 Feb 2002, Patrick Mochel wrote:

<really big snip>

> 
> Case 3: Quad channel DEC Bridge
> 
> Ok, maybe I don't understand completely what you're talking about, Andre. 
> That's just a 4 channel IDE controller, that happens to be on the board? 
> So, it's looks the same as the last example.
> 
> Unless, I'm missing something, which is always likely.

actually it's two two channel controllers on one board...

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
PDC20268: IDE controller on PCI bus 01 dev 10
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: ROM enabled at 0x000dc000
PDC20268: pci-config space interrupt mirror fixed.
PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
    ide2: BM-DMA at 0xcc00-0xcc07, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdg:pio, hdh:pio
PDC20268: IDE controller on PCI bus 01 dev 08
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: ROM enabled at 0xeded0000
PDC20268: pci-config space interrupt mirror fixed.
PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
    ide4: BM-DMA at 0xb800-0xb807, BIOS settings: hdi:pio, hdj:pio
    ide5: BM-DMA at 0xb808-0xb80f, BIOS settings: hdk:pio, hdl:pio

 
> 	-pat
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   joelja@darkwing.uoregon.edu    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
The accumulation of all powers, legislative, executive, and judiciary, in 
the same hands, whether of one, a few, or many, and whether hereditary, 
selfappointed, or elective, may justly be pronounced the very definition of
tyranny. - James Madison, Federalist Papers 47 -  Feb 1, 1788

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

> > > On Tue, Feb 05, 2002 at 10:43:14AM -0800, Patrick Mochel wrote:
> > > > I think that ide should get its own bus, as a child of the ide controller. 
> > > > I haven't looked at ide yet at all. But, on most modern systems, the ide 
> > > > controller is a function of the southbridge, so ide devices should go 
> > > > under that. Like what the usb stuff does now...
> > > 
> > > What about, say, a Promise PCI IDE card?  You really need to reference
> > > the parent PCI device when the is one.
> > 
> > LOL, how about ones that are quad-channel with a DEC-Bridge to slip the
> > local BUSS?
> 
> LOL? I don't understand...
> 
> I don't see how any of those cases are necessarily hard to visualize. 
> 
> Case 1: Typical PC with IDE as function of southbridge.
> 
> pci0
>  |
>   -- 07.2 (IDE controller)
>      |
>       --- disk0
>      |
>       --- disk1
> 
> Case 2: Promise IDE Controller with 2 channels
> 
> 
> pci0
>  |
>   --- 03.0 (Promise IDE Controller)
>       |
>        --- channel0
>            |
>             ---- disk0
>            |
>             ---- disk1
> 

These are easy ones, but what about

Case 4: 386 with no PCI

and what's worse

Case 5: 486 with both PCI and VLB, where ide is on the VLB?

cases 4 and 5 are IMO hard, because it is difficult to know where it
really is... and I'm not sure current kernel knows it.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: driverfs support for motherboard devices

[Patrick Mochel]

> These are easy ones, but what about
> 
> Case 4: 386 with no PCI
> 
> and what's worse
> 
> Case 5: 486 with both PCI and VLB, where ide is on the VLB?
> 
> cases 4 and 5 are IMO hard, because it is difficult to know where it
> really is... and I'm not sure current kernel knows it.

Does the IDE subsystem always know where it sits? I.e. does it know that a 
particular IDE controller is a function of the south bridge, an add-on PCI 
card, or directly on the motherboard?

If it does, there is no problem. It can properly add itself in the correct 
hierarchial position. 

If it doesn't, it's still not much of a problem (at least not at first 
glance).

If the IDE controller doesn't know it's parent, create an 'ide' bus as a 
child of the root and put ide devices under it. If there are multiple 
controllers or channels, represent them accordingly. 

	-pat

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

> If the IDE controller doesn't know it's parent, create an 'ide' bus as a 
> child of the root and put ide devices under it. If there are multiple 
> controllers or channels, represent them accordingly. 

Uh?

I'd expect legacy bus (it fits description of legacy device, right?)
and then ide bus hanging from the IDE controller on legacy bus, then
disks on the ide bus...
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: driverfs support for motherboard devices

[Alan Cox]

> Case 5: 486 with both PCI and VLB, where ide is on the VLB?
> 
> cases 4 and 5 are IMO hard, because it is difficult to know where it
> really is... and I'm not sure current kernel knows it.

I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac 
perfectly ready for a 2.5 merger

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

> > Case 5: 486 with both PCI and VLB, where ide is on the VLB?
> > 
> > cases 4 and 5 are IMO hard, because it is difficult to know where it
> > really is... and I'm not sure current kernel knows it.
> 
> I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac 
> perfectly ready for a 2.5 merger

PnPBIOS is nasty, and I suspect it is not present/working on all
models, right?
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: driverfs support for motherboard devices

[Dave Jones]

On Thu, Feb 07, 2002 at 01:31:25PM +0100, Pavel Machek wrote:
 > > I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac 
 > > perfectly ready for a 2.5 merger
 > PnPBIOS is nasty, and I suspect it is not present/working on all
 > models, right?

 For the most part it's fine, it just needs the floppy driver / ps2
 driver (and maybe some others) fixed up to not allocate regions
 that pnpbios already reserved. Other than these issues, it seems
 to be working well. It's certainly handled itself ok on all my
 test boxes (Even the weird compaq with the fscked up pnpbios --
 it claims to have pnpbios, yet when you call it, you get feature
 not supported return codes. cute.)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: driverfs support for motherboard devices

[Patrick Mochel]

On Thu, 7 Feb 2002, Dave Jones wrote:

> On Thu, Feb 07, 2002 at 01:31:25PM +0100, Pavel Machek wrote:
>  > > I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac 
>  > > perfectly ready for a 2.5 merger
>  > PnPBIOS is nasty, and I suspect it is not present/working on all
>  > models, right?
> 
>  For the most part it's fine, it just needs the floppy driver / ps2
>  driver (and maybe some others) fixed up to not allocate regions
>  that pnpbios already reserved. Other than these issues, it seems
>  to be working well. It's certainly handled itself ok on all my
>  test boxes (Even the weird compaq with the fscked up pnpbios --
>  it claims to have pnpbios, yet when you call it, you get feature
>  not supported return codes. cute.)

Hey, speaking of PnPBios, is there a spec somewhere?

Speaking of specs, does anyone know of some sort of list of specs of 
things kernel related - platforms, hardware and firmware? sandpile.org is 
good for most x86 things, though they are merely document names. 

	-pat

Re: driverfs support for motherboard devices

[Dave Jones]

On Thu, Feb 07, 2002 at 09:26:01AM -0800, Patrick Mochel wrote:

 > Hey, speaking of PnPBios, is there a spec somewhere?

 I was hunting for it yesterday for someone else who asked me,
 but I didn't turn up a pdf. The only copy I seem to have is
 in dead-tree format (Mindshare PCI book).

 > Speaking of specs, does anyone know of some sort of list of specs of 
 > things kernel related - platforms, hardware and firmware? sandpile.org is 
 > good for most x86 things, though they are merely document names. 

 Jeff Garzik has gathered some stuff together at 
 http://gkernel.sourceforge.net/specs/

 Other stuff is kind of... 'well dispersed'

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: driverfs support for motherboard devices

[Gunther Mayer]

Patrick Mochel wrote:

> On Thu, 7 Feb 2002, Dave Jones wrote:
>
> > On Thu, Feb 07, 2002 at 01:31:25PM +0100, Pavel Machek wrote:
> >  > > I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac
> >  > > perfectly ready for a 2.5 merger
> >  > PnPBIOS is nasty, and I suspect it is not present/working on all
> >  > models, right?
> >
> >  For the most part it's fine, it just needs the floppy driver / ps2
> >  driver (and maybe some others) fixed up to not allocate regions
> >  that pnpbios already reserved. Other than these issues, it seems
> >  to be working well. It's certainly handled itself ok on all my
> >  test boxes (Even the weird compaq with the fscked up pnpbios --
> >  it claims to have pnpbios, yet when you call it, you get feature
> >  not supported return codes. cute.)
>
> Hey, speaking of PnPBios, is there a spec somewhere?

http://www.microsoft.com/hwdev/tech/PnP/default.asp

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

>  > > I suspect PnPBIOS knows for the 486. There is PnPbios code in 2.4-ac 
>  > > perfectly ready for a 2.5 merger
>  > PnPBIOS is nasty, and I suspect it is not present/working on all
>  > models, right?
> 
>  For the most part it's fine, it just needs the floppy driver / ps2
>  driver (and maybe some others) fixed up to not allocate regions
>  that pnpbios already reserved. Other than these issues, it seems
>  to be working well. It's certainly handled itself ok on all my
>  test boxes (Even the weird compaq with the fscked up pnpbios --
>  it claims to have pnpbios, yet when you call it, you get feature
>  not supported return codes. cute.)

It is *BIOS*, and that makes me nervous.

Anyway, I guess that for old boxen, it is okay to just put ide onto
/driver/legacy/XXX (and for new boxen probably too, we do not want
special code calling PnPbios/PCI just to put drivers to the right
place in the tree, right?)
									Pavel
PS: I suspect that those southbridge-integrated IDE controllers are
not *really* on PCI... They certainly do not use PCI IRQ A..D.
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: driverfs support for motherboard devices

[Zwane Mwaikambo]

On Tue, 5 Feb 2002, Patrick Mochel wrote:

> I think that ide should get its own bus, as a child of the ide controller. 
> I haven't looked at ide yet at all. But, on most modern systems, the ide 
> controller is a function of the southbridge, so ide devices should go 
> under that. Like what the usb stuff does now...

How about add-on ATA controllers? 

Cheers,
	Zwane Mwaikambo

Re: driverfs support for motherboard devices

[Zwane Mwaikambo]

On Tue, 5 Feb 2002, Pavel Machek wrote:

> +static void __init init_8259A_devicefs(void)
> +{
> +	device_register(&device_i8259A);
> +	strcpy(device_i8259A.name, "i8259A");
> +	strcpy(device_i8259A.bus_id, "0020");
> +	device_i8259A.parent = &sys_iobus;

I'm not entirely familiar with the driverfs API but wouldn't an API 
function to do all that strcpy and other init assignments be a bit 
cleaner? I see lots of retyping going on otherwise, someone feel free to 
hit me with a clue bat if i'm missing something...

Cheers,
	Zwane Mwaikambo

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

> > +static void __init init_8259A_devicefs(void)
> > +{
> > +	device_register(&device_i8259A);
> > +	strcpy(device_i8259A.name, "i8259A");
> > +	strcpy(device_i8259A.bus_id, "0020");
> > +	device_i8259A.parent = &sys_iobus;
> 
> I'm not entirely familiar with the driverfs API but wouldn't an API 
> function to do all that strcpy and other init assignments be a bit 
> cleaner? I see lots of retyping going on otherwise, someone feel free to 
> hit me with a clue bat if i'm missing something...

I guess that's okay. We do not helper with 1000 arguments to fill
structure up. It will be strcpy sometimes, sprintf
sometimes.... Better leave that alone.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: driverfs support for motherboard devices

[Patrick Mochel]

On Wed, 6 Feb 2002, Zwane Mwaikambo wrote:

> On Tue, 5 Feb 2002, Pavel Machek wrote:
> 
> > +static void __init init_8259A_devicefs(void)
> > +{
> > +	device_register(&device_i8259A);
> > +	strcpy(device_i8259A.name, "i8259A");
> > +	strcpy(device_i8259A.bus_id, "0020");
> > +	device_i8259A.parent = &sys_iobus;
> 
> I'm not entirely familiar with the driverfs API but wouldn't an API 
> function to do all that strcpy and other init assignments be a bit 
> cleaner? I see lots of retyping going on otherwise, someone feel free to 
> hit me with a clue bat if i'm missing something...

Actually, that's something I didn't notice with the patch: you need a 
non-NULL bus_id inorder to register the device.

Something like this for singular devices would work better:

static struct device device_i8259A = {
	name:		"i8259A",
	bus_id:		"0020",
};

Though, where does that bus_id come from?

	-pat

Re: driverfs support for motherboard devices

[Pavel Machek]

Hi!

> > > +static void __init init_8259A_devicefs(void)
> > > +{
> > > +	device_register(&device_i8259A);
> > > +	strcpy(device_i8259A.name, "i8259A");
> > > +	strcpy(device_i8259A.bus_id, "0020");
> > > +	device_i8259A.parent = &sys_iobus;
> > 
> > I'm not entirely familiar with the driverfs API but wouldn't an API 
> > function to do all that strcpy and other init assignments be a bit 
> > cleaner? I see lots of retyping going on otherwise, someone feel free to 
> > hit me with a clue bat if i'm missing something...
> 
> Actually, that's something I didn't notice with the patch: you need a 
> non-NULL bus_id inorder to register the device.
> 
> Something like this for singular devices would work better:
> 
> static struct device device_i8259A = {
> 	name:		"i8259A",
> 	bus_id:		"0020",
> };
> 
> Though, where does that bus_id come from?

It is address on (what used to be) ISA bus. I'm selecting lowest when
I have a choice.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: driverfs support for motherboard devices

[Thomas Hood]

I have put the two documents
   pnpbios.rtf
   biosclar.rtf
up on my web page
   http://panopticon.csustan.edu/thood/pnpbios.html

Re: driverfs support for motherboard devices

[Patrick Mochel]

On Thu, 7 Feb 2002, Thomas Hood wrote:

> I have put the two documents
>    pnpbios.rtf
>    biosclar.rtf
> up on my web page
>    http://panopticon.csustan.edu/thood/pnpbios.html

Cool, thanks. 

Do you know what the original source of these is? Or, perhaps in the 
documents?

	-pat