What were your plans for passing the bus_operations struct to card drivers? Since the drivers will require the struct as soon as possible, I would assume the call to RegisterClient in the driver attach() routine would be the place, but if so I am unsure as to if you had ideas on plumbing already.
Yes it gets filled in by RegisterClient.
Note that all of this was ripped out in recent 2.5.* kernels because it hasn't actually been used. So expect the capability to go away, unless you want to make a case for it to be restored.
So if I understand correctly, calling RegisterClient in the pccard driver does not assign the bus_operations struct value back to the passed-in client_reg_t (my first guess). You are expecting the pccard driver to initialize the bus_operations struct within the CS_CARD_EVENT_INSERTION case of the event callback routine. Correct?
Err, now that I look at the actual code, no, the bus_operations field never gets filled in. I guess I never bothered to do that since there were never any platforms that implemented the bus_operations stuff.
Actually, the in-kernel cs.c does assign the bus_operations struct in the event_callback_args. It does not, however, assign it "back" to the passed-in client_reg_t, so a driver must initialize the bus_operations in the event callback during CS_EVENT_CARD_INSERTION.
I've tested this with the 3c589_cs driver and all seems well. If you are remotely interested, I'll send you the diff of the driver once it has been completely moved-over to bus_ops.
BTW, is the use of insl/outsl() in 3c589_cs an optimization of sorts for PCMCIA controllers that do byte-combining? It seems invalid on the face of it, and I've needed to convert that to insb/outsb so I don't byteswap the data.
Log in to post a comment.