Date: Wed, 02 Jan 2008 13:40:33 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: freebsd-embedded@FreeBSD.org Subject: Re: ocpbus(4) Message-ID: <20080102.134033.-672663610.imp@bsdimp.com> In-Reply-To: <200801021453.02931.jhb@freebsd.org> References: <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> <200801021453.02931.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200801021453.02931.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote:
: >
: > On Jan 2, 2008, at 10:03 AM, John Baldwin wrote:
: >
: > > Agreed, and device.FOO would create an unknownX device (much like
: > > unprobed
: > > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the
: > > bus impl
: > > uses properties to create devices and doesn't use them purely as
: > > additional
: > > metadata). For example, I actually figured that the default
: > > device.hints type
: > > stuff for COM1 would look like this:
: > >
: > > device.COM1.at="isa"
: > > device.COM1.port="0x3f8-0x3ff"
: > > device.COM1.irq=4
: > > device.COM1.pnpid="PNP0500"
: >
: > BTW: I like the port range.
:
: I hate that abuot the current hints actually where drives hardcode things like
: IO_COMSIZE. I really would like the enumeration data that is provided not by
: the firmware to look like something that comes from firmware, on which we
: seem to agree.
We're all in agreement here then. I think the entire resource (not
just range) should be accepted here. Eg:
hint.fdc.0.port="0x3f2-0x3f3,0x3f4-0x3f5,0x3f7"
or whatever your favored syntax is for the left hand side of the =
sign. I'd prefer this over a portsz key. It is useful for many
instances of this problem, not just the odd-ball floppy drive.
Note: The above is a little more complicated than what a user would
enter, but many BIOS tables are constructed that way.
Also, I'd like to keep the 'You have this resource' command different
than the 'Bind me to the device that has this resource' command. So
: FOO {
: resources {
: irq {
: 0=4
: }
: ioport {
: 1=0xa-0xb
: }
: }
: at="blah"
: }
: We could also call 'at', 'location' perhaps.
I think this still confuses things and is a cumbersome syntax.
FOO {
resources {
irq(0)=4
}
location {
ioport=0xa-0xb
_HID="COMA"
}
driver="sio"
unit=2
}
Would be much better.
we could then have wildcard entries like so that are unnamed:
{
location {
_HID="PNP0501"
bus="acpi"
}
driver="uart"
baud=115200
}
{
location {
vendor=0x3451
device=0x0001
bus="pci"
}
driver="sio"
baud=1200
}
if one wanted to universally use uart for all serial ports. This also
mirrors the pnpinfo that the ACPI bus provides and the PCI bus
provides. It would easily allow one to look at the devinfo -v output
and know how to bind a driver to a hunk of hardware (generically).
It would also allow us to say:
{
location {
bus="pci3"
slot=31
function=1
// or at=pci3.31.1
// or at=pci0.3.31.1 including the pci domain
}
override {
vendor=0x3451
device=0x0001
}
}
if we wanted to integrate into this system the strong desire that
people have expressed for being able to say 'treat device X as if it
were a Y'.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080102.134033.-672663610.imp>