Reading CIS from kernel?
Hi all, The Xircom ethernet driver needs to read/write PCCARD attribute memory from its probe routine, in order to identify the type of card and to beat brain-damaged CEM56 cards into shape :-) Currently this is done by way of 'fake' calls to read() and write() on the appropriate /dev/cardXX device. However, if we look at the version of the driver that David O'Brien has kindly committed to the repository (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pccard/if_xe.c) we see: === RCS file: /home/ncvs/src/sys/dev/pccard/if_xe.c,v retrieving revision 1.2 retrieving revision 1.3 diff -p -u -r1.2 -r1.3 --- src/sys/dev/pccard/if_xe.c 1999/05/14 04:18:24 1.2 +++ /home/ncvs/src/sys/dev/pccard/if_xe.c 1999/05/31 11:24:51 1.3 @@ -352,7 +352,11 @@ xe_memwrite(struct pccard_devinfo *devi, uios.uio_rw = UIO_WRITE; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_write(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } @@ -373,7 +377,11 @@ xe_memread(struct pccard_devinfo *devi, uios.uio_rw = UIO_READ; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_read(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } Now I'll grant you that it probably *is* bogus, but when I first started writing the driver it was the least ugly solution proposed. So, since I can't do it that way anymore, are there any suggestions for an 'approved' way of reading/writing PCCARD attribute memory from inside the kernel? If it's just the use of cdevsw[] that's problematic, then making crdread() and crdwrite() (in /sys/pccard/pccard.c) non-static and calling them directly from the driver code would be an easy workaround. Alternatively, I could export pccard_mem and pccard_kmem from the same file and do the reads and writes myself, but that seems a bit dangerous. Any other approach would seem to involve duplicating more of the PCCARD code than I care to, expecially considering that it's all being redone in the newbus-ification of -CURRENT. I'd appreciate some advice from the powers-that-be as to what will and won't get stomped on here, as both David and I would like to see a *working* version of this code in the tree... Cheers, Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Reading CIS from kernel?
Hi all, The Xircom ethernet driver needs to read/write PCCARD attribute memory from its probe routine, in order to identify the type of card and to beat brain-damaged CEM56 cards into shape :-) Currently this is done by way of 'fake' calls to read() and write() on the appropriate /dev/cardXX device. However, if we look at the version of the driver that David O'Brien has kindly committed to the repository (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pccard/if_xe.c) we see: === RCS file: /home/ncvs/src/sys/dev/pccard/if_xe.c,v retrieving revision 1.2 retrieving revision 1.3 diff -p -u -r1.2 -r1.3 --- src/sys/dev/pccard/if_xe.c 1999/05/14 04:18:24 1.2 +++ /home/ncvs/src/sys/dev/pccard/if_xe.c 1999/05/31 11:24:51 1.3 @@ -352,7 +352,11 @@ xe_memwrite(struct pccard_devinfo *devi, uios.uio_rw = UIO_WRITE; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_write(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } @@ -373,7 +377,11 @@ xe_memread(struct pccard_devinfo *devi, uios.uio_rw = UIO_READ; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_read(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } Now I'll grant you that it probably *is* bogus, but when I first started writing the driver it was the least ugly solution proposed. So, since I can't do it that way anymore, are there any suggestions for an 'approved' way of reading/writing PCCARD attribute memory from inside the kernel? If it's just the use of cdevsw[] that's problematic, then making crdread() and crdwrite() (in /sys/pccard/pccard.c) non-static and calling them directly from the driver code would be an easy workaround. Alternatively, I could export pccard_mem and pccard_kmem from the same file and do the reads and writes myself, but that seems a bit dangerous. Any other approach would seem to involve duplicating more of the PCCARD code than I care to, expecially considering that it's all being redone in the newbus-ification of -CURRENT. I'd appreciate some advice from the powers-that-be as to what will and won't get stomped on here, as both David and I would like to see a *working* version of this code in the tree... Cheers, Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from > its probe routine, in order to identify the type of card and to beat ... > then making crdread() and crdwrite() (in /sys/pccard/pccard.c) > non-static and calling them directly from the driver code would be an > easy workaround. Since no one has repsonded to this querry, I will be un-staticizing these so they will be available to drivers. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote: > [about cdread()/cdwrite() in /sys/pccard/pcccard.c] > > Since no one has repsonded to this querry, I will be un-staticizing these > so they will be available to drivers. This is going to be for both -current and MFC'd back into -stable, yes? -aDe -- Ade Lovett, Austin, TX. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <19990713182203.a68...@nuxi.com> "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <19990713210337.h85...@remarq.com> Ade Lovett writes: : This is going to be for both -current and MFC'd back into -stable, yes? The interface for doing this I'll be merging back into -stable. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote: > In message <19990713182203.a68...@nuxi.com> "David O'Brien" writes: > : Since no one has repsonded to this querry, I will be un-staticizing these > : so they will be available to drivers. > > No. Please don't. This is the first I've seen this. There will be > another cis reading interface as part of the newbusification of pccard > stuff and I'd rather not have to fix any more drivers than I have to. > I wish I had seen it sooner. The Xircom driver is one of the ones > that my first attempt at newbusification would have broken... > > Warner > Ugh. In that case, can someone back out Poul-Henning's changes to the if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it from working. At least that way only my code will be bogus :-) Believe me, I know it's ugly, but there's no getting around the fact that the driver needs to read the CIS, and right now there's no clean way to do that in -STABLE (is there?). Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <19990714185101.09...@goatsucker.org>, Scott Mitchell writes: >Ugh. In that case, can someone back out Poul-Henning's changes to the >if_xe.c in the -STABLE tree? Uhm my change has not been applied to STABLE, but the 3.2-PAO import references current rather than stable. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <19990714185101.09...@goatsucker.org> Scott Mitchell writes: : Ugh. In that case, can someone back out Poul-Henning's changes to the : if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it : from working. At least that way only my code will be bogus :-) Believe : me, I know it's ugly, but there's no getting around the fact that the : driver needs to read the CIS, and right now there's no clean way to do that : in -STABLE (is there?). Can I get your comments on the following interface? int pccard_map_cis(int slot) Maps the slot's cis into memory. You must call the before any of the following. It returns 0 on success, or an error from /usr/include/sys/errno.h (most likely EBUSY if there are no memory windows available). int pccard_unmap_cis(int slot) Unmaps the CIS. This frees any resource used by the slot to map its CIS. It returns 0 on success, and an errno value if not. vaddr_t pccard_cis_addr(int slot) Return the virtual address of the CIS. The CIS must be mapped before call this function. Drivers may read/write this memory. Reading this memory will get the CIS entries. Drivers are responsible for interpreting the CIS. Writing to CIS locations generally is used to configure the card and does not change the CIS stored on the card. If the card is not mapped, then 0 will be returned. It is not valid to access memory returned by this call after a call to pccard_unmap_cis. Future interfaces may ease the burdon on driver writers, but this interface will be supported for a while. Does this fill your needs? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from > its probe routine, in order to identify the type of card and to beat ... > then making crdread() and crdwrite() (in /sys/pccard/pccard.c) > non-static and calling them directly from the driver code would be an > easy workaround. Since no one has repsonded to this querry, I will be un-staticizing these so they will be available to drivers. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote: > [about cdread()/cdwrite() in /sys/pccard/pcccard.c] > > Since no one has repsonded to this querry, I will be un-staticizing these > so they will be available to drivers. This is going to be for both -current and MFC'd back into -stable, yes? -aDe -- Ade Lovett, Austin, TX. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <[EMAIL PROTECTED]> Ade Lovett writes: : This is going to be for both -current and MFC'd back into -stable, yes? The interface for doing this I'll be merging back into -stable. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "David O'Brien" writes: > : Since no one has repsonded to this querry, I will be un-staticizing these > : so they will be available to drivers. > > No. Please don't. This is the first I've seen this. There will be > another cis reading interface as part of the newbusification of pccard > stuff and I'd rather not have to fix any more drivers than I have to. > I wish I had seen it sooner. The Xircom driver is one of the ones > that my first attempt at newbusification would have broken... > > Warner > Ugh. In that case, can someone back out Poul-Henning's changes to the if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it from working. At least that way only my code will be bogus :-) Believe me, I know it's ugly, but there's no getting around the fact that the driver needs to read the CIS, and right now there's no clean way to do that in -STABLE (is there?). Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <[EMAIL PROTECTED]>, Scott Mitchell writes: >Ugh. In that case, can someone back out Poul-Henning's changes to the >if_xe.c in the -STABLE tree? Uhm my change has not been applied to STABLE, but the 3.2-PAO import references current rather than stable. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message <[EMAIL PROTECTED]> Scott Mitchell writes: : Ugh. In that case, can someone back out Poul-Henning's changes to the : if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it : from working. At least that way only my code will be bogus :-) Believe : me, I know it's ugly, but there's no getting around the fact that the : driver needs to read the CIS, and right now there's no clean way to do that : in -STABLE (is there?). Can I get your comments on the following interface? int pccard_map_cis(int slot) Maps the slot's cis into memory. You must call the before any of the following. It returns 0 on success, or an error from /usr/include/sys/errno.h (most likely EBUSY if there are no memory windows available). int pccard_unmap_cis(int slot) Unmaps the CIS. This frees any resource used by the slot to map its CIS. It returns 0 on success, and an errno value if not. vaddr_t pccard_cis_addr(int slot) Return the virtual address of the CIS. The CIS must be mapped before call this function. Drivers may read/write this memory. Reading this memory will get the CIS entries. Drivers are responsible for interpreting the CIS. Writing to CIS locations generally is used to configure the card and does not change the CIS stored on the card. If the card is not mapped, then 0 will be returned. It is not valid to access memory returned by this call after a call to pccard_unmap_cis. Future interfaces may ease the burdon on driver writers, but this interface will be supported for a while. Does this fill your needs? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
