Re: Use of newbus in sys/pci/pci.c

2000-01-16 Thread Doug Rabson

On Sat, 15 Jan 2000, Michael Kennett wrote:

 Hello All,
 
 I have a question on the sys/pci/pci.c code, and its use of the
 newbus architecture. An example of the code in question is:
 
 static struct resource *
 pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
  u_long start, u_long end, u_long count, u_int flags)
 {
   struct pci_devinfo *dinfo = device_get_ivars(child);
 ^   Looks wrong
   struct resource_list *rl = dinfo-resources;
 
   return resource_list_alloc(rl, dev, child, type, rid,
  start, end, count, flags);
 }
 
 I don't understand the line that extracts the ivars from the child
 device.  Isn't it the case that the ivars are a property of the bus
 device (dev)?  In any case, the child device might not be directly
 descended from the pci bus (e.g. it could be attached thru' the
 bridge isab0: VIA 82C586 PCI-ISA bridge).

The ivars are for bus-specific per-child information. The resource
locations for pci devices fall into this category and the information is
stored in a pci-private structure in the child device's ivars field.

This code is slightly dubious for the case when child isn't a direct
descendant of dev (i.e. a grandchild etc). In this case, the ivars pointer
would be read but not indirected through since the first thing
resource_list_alloc() does is check for this and pass the allocation up
the tree. It should be safe but its certainly dubious.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Use of newbus in sys/pci/pci.c

2000-01-15 Thread Michael Kennett

Hello All,

I have a question on the sys/pci/pci.c code, and its use of the
newbus architecture. An example of the code in question is:

static struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
   u_long start, u_long end, u_long count, u_int flags)
{
struct pci_devinfo *dinfo = device_get_ivars(child);
^   Looks wrong
struct resource_list *rl = dinfo-resources;

return resource_list_alloc(rl, dev, child, type, rid,
   start, end, count, flags);
}

I don't understand the line that extracts the ivars from the child
device.  Isn't it the case that the ivars are a property of the bus
device (dev)?  In any case, the child device might not be directly
descended from the pci bus (e.g. it could be attached thru' the
bridge isab0: VIA 82C586 PCI-ISA bridge).

It strikes me that the assignment is unsafe. I would have thought
that the code should be:

static struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
   u_long start, u_long end, u_long count, u_int flags)
{
struct pci_devinfo *dinfo = device_get_ivars(dev);
^^^   CHANGED
struct resource_list *rl = dinfo-resources;

return resource_list_alloc(rl, dev, child, type, rid,
   start, end, count, flags);
}

Why are the ivars extracted from the child, and not the bus device?

Kind Regards,

Mike Kennett
([EMAIL PROTECTED])



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Use of newbus in sys/pci/pci.c

2000-01-15 Thread Matthew N. Dodd

On Sat, 15 Jan 2000, Michael Kennett wrote:
 I don't understand the line that extracts the ivars from the child
 device. Isn't it the case that the ivars are a property of the bus
 device (dev)?

No since the parent may not be a PCI device.  In any case we're dealing
with a device (child) that wishes to make a resource allocation; the
parent device provides methods for this and its methods store the relevent
information on the structure assigned to the device IVARS (by the parent).

The IVARS belong to the device, not the parent.

I've probably not helped much but the code is correct.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message