fix various typos in comments and makefs README file.

Trailing whitespace

Merge thorpej-cfargs2.

branches: 1.24.8;
Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.23.10;
On second thought revert that. Let's open this can of worms some other day.

KB -> kB

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2; 1.20.4;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

Trailing whitespace

Merge thorpej-cfargs2.

branches: 1.24.8;
Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.23.10;
On second thought revert that. Let's open this can of worms some other day.

KB -> kB

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2; 1.20.4;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

Merge thorpej-cfargs2.

branches: 1.24.8;
Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.23.10;
On second thought revert that. Let's open this can of worms some other day.

KB -> kB

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2; 1.20.4;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.23.10;
On second thought revert that. Let's open this can of worms some other day.

KB -> kB

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2; 1.20.4;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

On second thought revert that. Let's open this can of worms some other day.

KB -> kB

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2; 1.20.4;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.20.2;
We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

We always need bp->b_resid initialized before we try to toss the transfer.

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).

Reset b_resid when tossing transfer with non-zero b_error.

need to forward the data pointer

Use C99-style initializers for struct dkdriver.

branches: 1.16.2;
use disk_init() wrapper function instead of poking data structures.

Add d_discard to all struct cdevsw instances I could find.

All have been set to "nodiscard"; some should get a real implementation.

Add d_discard to all struct bdevsw instances I could find.

I've set them all to nodiscard. Some of them (wd, dk, vnd, ld,
raidframe, maybe cgd) should be implemented for real.

branches: 1.13.2;
Fix printf formating in DPRINTF.

Remove an unused variable

branches: 1.11.2;
Fix wrong calculation of destination pointer in writes.

Existing calculation of destination pointer was always causing unnecessary erases of SPI Flash memory and was always writing each consecutive 2048 byte blocks of data into the same address of the SPI Flash memory. This commit fixes issue with writes of multiple blocks using 'dd' tool.

Patch from Semihalf.
Author: Michal Dubiel <md@semihalf.com>

branches: 1.10.14; 1.10.24;
g/c BUFQ_FOO() macros and use bufq_foo() directly.

branches: 1.9.4;
use device_lookup_private to get softc

branches: 1.8.2; 1.8.4;
device_t/softc split.

branches: 1.7.2; 1.7.4;
use aprint_*_dev and device_xname

branches: 1.6.26; 1.6.28;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Fix the kthread_create(9) call so this compiles again.

branches: 1.4.2;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.3.2; 1.3.4;
Kill caddr_t; there will be some MI fallout, but it will be fixed shortly.

branches: 1.2.2; 1.2.4; 1.2.8; 1.2.10;
This commit provides substantial fixes and functionality for SPI flash.

Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.

To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.

The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.

Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.

These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)

The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.

This work was funded by the Champaign-Urbana Community Wireless Network
Project.

Add spiflash driver, and M25P instance, used for STMicro flash devices
found on Meraki Mini (for example).