summaryrefslogtreecommitdiffstats
path: root/sys/dev/ic/wd33c93.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Since dlg@'s 2009 scsi midlayer refactoring the 'struct scsi_generic *cmd'krw2020-09-221-5/+5
| | | | | | | | | | | | member of 'struct scsi_xfer' has always been pointed at the 'struct scsi_generic cmdstore' member of the same instance. So nuke 'cmdstore' and remove the '*' from cmd. Take the address of cmd as required by the various casts. No intentional functional change. luna88k test by aoyama@, sparc64 test by jmatthew@ Identification of 2009's last *cmd use and ok jmatthew@
* Move remaining scsi bus initialization info from "prototype scsi link"krw2020-07-201-5/+5
| | | | | | | fields to struct scsibus_attach_args. Nuke the struct scsi_link * (saa_sc_link) in scaibus_attach_args. Explicitly initialize each field in scsibus_attach_args variables.
* Move the adapter related items (luns, adapter, adapter_target,krw2020-07-191-6/+6
| | | | | | | adapter_buswidth, adapter_softc) from struct scsi_link to struct scsibus_attach_args. Additional compile tests by jmatthew@ (sparc64) and aoyam@ (luna88k).
* Access adapter softc via link->bus->sb_adapter_softc.krw2020-07-161-3/+3
| | | | | | | | In sparc64 autoconf access 'luns' via sb_luns and 'adapter_buswidth' via sb_adapter_buswidth. Removes last post-config uses of the copies of bus related information in scsi_link.
* If the adapter card needs to keep track of its own id on the bus, orkrw2020-07-011-2/+2
| | | | | | | | | | | the width of the bus it is providing, it should rely on info in its softc. i.e. not on info in the prototype scsi_link that is passed out for other bits of the kernel to fiddle with. Most drivers already do this. Make it so for the laggards iha(4) and siop(4). Actually use the existing softc value in wd33c93.c. No intentional functional change.
* No need to bzero()/memset() 'struct scsibus_attach_args' variableskrw2020-06-271-2/+1
| | | | immediately before initializing the only field in the struct.
* kernel: use gettime(9)/getuptime(9) in lieu of time_second(9)/time_uptime(9)cheloha2020-06-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | time_second(9) and time_uptime(9) are widely used in the kernel to quickly get the system UTC or system uptime as a time_t. However, time_t is 64-bit everywhere, so it is not generally safe to use them on 32-bit platforms: you have a split-read problem if your hardware cannot perform atomic 64-bit reads. This patch replaces time_second(9) with gettime(9), a safer successor interface, throughout the kernel. Similarly, time_uptime(9) is replaced with getuptime(9). There is a performance cost on 32-bit platforms in exchange for eliminating the split-read problem: instead of two register reads you now have a lockless read loop to pull the values from the timehands. This is really not *too* bad in the grand scheme of things, but compared to what we were doing before it is several times slower. There is no performance cost on 64-bit (__LP64__) platforms. With input from visa@, dlg@, and tedu@. Several bugs squashed by visa@. ok kettenis@
* Whitespace.krw2020-06-191-2/+2
|
* wdsc(4), ncr53c9x: timestamp LUNs with time_uptime(9), not time_second(9)cheloha2020-04-151-3/+3
| | | | | | | Use a monotonic clock for timestamping LUNs to avoid problems when the UTC clock jumps. ok krw@
* Rename Debugger() into db_enter().mpi2017-04-301-3/+3
| | | | | | | Using a name with the 'db_' prefix makes it invisible from the dynamic profiler. ok deraadt@, kettenis@, visa@
* Fix typo, happend -> happenedjca2016-12-261-2/+2
|
* all pools have their ipl set via pool_setipl, so fold it into pool_init.dlg2016-09-151-4/+3
| | | | | | | | | | | | | | | | | | | | | | the ioff argument to pool_init() is unused and has been for many years, so this replaces it with an ipl argument. because the ipl will be set on init we no longer need pool_setipl. most of these changes have been done with coccinelle using the spatch below. cocci sucks at formatting code though, so i fixed that by hand. the manpage and subr_pool.c bits i did myself. ok tedu@ jmatthew@ @ipl@ expression pp; expression ipl; expression s, a, o, f, m, p; @@ -pool_init(pp, s, a, o, f, m, p); -pool_setipl(pp, ipl); +pool_init(pp, s, a, ipl, f, m, p);
* add a size argument to free. will be used soon, but for now default to 0.tedu2014-07-121-3/+3
| | | | after discussions with beck deraadt kettenis.
* Standardize xfer byte counts to ssize_t rather than a mix of size_t and intmiod2014-06-271-51/+71
| | | | | | | | | (we need to make them signed to spot controller overruns), and fix format strings accordingly. While there, make sure every runtime printf is prefixed by either the complete target information, if available, or at least the driver name with the proper instance number - supported systems with > 1 wdsc are quite common.
* move away from XS_NO_CCB to iopools. all instances of this driver share adlg2014-01-181-26/+22
| | | | | | | single pool, which we now layer iopools on top of and share in the same way. tweaks and testing by miod@
* Backout premature optimization and actually commit the diff which had beenmiod2012-07-021-3/+8
| | | | tested to boot multiuser.
* Report immediate deselection from a target upon selection as a `selectionmiod2012-07-021-5/+6
| | | | | | | | | timeout', instead of being stuck with a non-progressing request. This lets the nonexistent LUNs of the Insite Floptical probe (as non-existing) correctly. Step two of Floptical support, now if only the loading mechanism would unjam I could try some real I/O with it...
* If running on the original 33C93, reject commands not in groups 0, 1 or 5miod2012-04-091-58/+87
| | | | | | | | | | | | if their size is not exactly six bytes, as the chip can't cope with this situation. Another situation all 33C93 do not cope with very well, is sending stop commands to targets (such as all sd(4) devices when halting with poweroff) - it takes a very long time to recover once all targets on the bus have been powered down, so we need to raise timeouts to unholy values (one test case has required more than 20 seconds to recover). Not surprising, as this command is not documented as supported in the chip documentation.
* Work in progress support for the SGI Indigo, Indigo 2 and Indy systemsmiod2012-03-281-0/+2337
(IP20, IP22, IP24) in 64-bit mode, adapated from NetBSD. Currently limited to headless operation, input and video drivers will get ported soon. Should work on all R4000, R4440 and R5000 based systems. L2 cache on R5000SC Indy not supported yet (coming soon), R4600 not supported yet either (coming soon as well). Tested to boot multiuser on: Indigo2 R4000SC, Indy R4000PC, Indy R4000SC, Indy R5000SC, Indigo2 R4400SC. There are still glitches in the Ethernet driver which are being looked at. Expansion support is limited to the GIO E++ board; GIO boards with PCI-GIO bridges not ported yet due to the lack of hardware, and this kind of driver does not port blindly. Most of this work comes from NetBSD, polishing and integration work, as well as putting as many ``R4x00 in 64-bit mode'' erratas as necessary, by yours truly. More work is coming, as well as trying to get some easy way to boot install kernels (as older PROM can only boot ECOFF binaries, which won't do for the kernel).