BMAC Ethernet Driver

[Peter Grehan]

Hi Nathan,

>  >  This would get my vote. I would think the gpio device would register 
> itself, perhaps with it's macio parent, and clients would access it 
> through kobj methods. These would include interrupt forwarding, and GPIO 
> toggling.
> 
> The trouble here is that SMU isn't a macio child, so it wouldn't pick up 
> the GPIO kobj methods.

  In this case, the kobj methods wouldn't be part of the device 
hierarchy, but accessible directly through a device_t.

  Have a look at kern/subr_rtc.c for a similar case where a real-time 
clock device exports kobj methods via a registration and wrapper routines.

>  >  How does the SMU use the GPIO's ? Just toggling ?
> 
> Yeah. It also reads them from time to time, which the onboard audio 
> stuff does too (to sense headphone connections and the like).

  OK, that could be handled through exported toggle methods.

>  >  Hopefully it is a one-way path with the gpio device knowing nothing 
> about the users that call it.
> 
> Yes, I think that would be ideal. I'm not quite sure how to do it 
> though. Having a second gpio driver for each device that attaches to 
> macgpio and can find its partner by internal logic could work.

  For macio devices, the methods could be exported by the parent. For 
non-macio devices, something like the subr_rtc.c style could be used.

> Or global calls into macgpio.

  That should be a last resort :)

> Also, is there a way to find a FreeBSD device given an OF phandle? For 
> SMU, the GPIO lines it needs to care about are listed as device handles 
> under /smu. So an SMU attachment would need to figure out the macgpio 
> device and GPIO line to watch from the OF handle. I don't know how this 
> works for PMU.

  This could be ugly :( Do you have any examples of the devices that the 
SMU handles end up pointing to ?

later,

Peter.