Needs serial comma:
s/issues/issues,/

"counting from CRC errors" is still unclear. I originally thought this meant "the number of non-CRC errors." Not so sure now.

"may" is generally used for permission. "might" or "can" is better for probability:

It can also indicate a wiring error.

Low and high temperature... what? Limits? Ranges? Alarms? "either" is probably not needed.

Remove "the":
module implements Dallas Semiconductor 1-wire signaling.

Phabricator might be helping, but this shows "The only a controller" now. Should be "The only controller"?

Suggestion: use "with" rather than "via" ("via" implies travel: "I got there via Highway 8" or a transfer medium: "Electricity travels via a conductor.")

pins on a GPIO bus with

Should be either "GPIO" or .Xr gpio 4

Missing a "the":
s/in ow/in the ow/

Maybe use own(4) to make this not seem to be the word "own".

"to implement" is not needed.
responsibility of the client device drivers.

As above, own(4) rather than just "own". (It is easy to read this as a type saying "their own".

Typo:
s/interferring/interfering/

For this version of the sentence, "has" is correct. (Sorry if this is a duplicate, or changing it back. Phabricator is "helping" the crap out of this, and it's hard to tell what has changed since the original and new version are not shown together.)

1. SoCs list a 1-wire controller in their spec sheets which presumably has

"The" needed:
s/owll/the owll/

Typo:
s/an/a/

Typo:
s/Big/Bit/

s/the own/own/

But other than that, nice!

Even better!

s/The following/These

Avoid redundancy by avoiding redundancy (see also: redundancy). Probably not necessary to capitalize "family codes":

The family codes for these devices are reused by many variants
marketed under different names.

Avoid the aside:

might have different operating characteristics like accuracy or
temperature range.

Rearrange to avoid the repetitive "This driver". Also add a serial comma:

Family codes 0x10, 0x22, 0x28, and 0x3b are supported.

"Supports" is not really the right word here. The driver *provides* those entries. Probably better to use .Nm than "this driver", too:

.Nm
provides several entries in the device's node in the
.Xr sysctl 8
tree:

Probably should say "device" or "driver" here in this opening sentence.

device interfaces to the link layer of the Dallas Semiconductor 1-Wire.

It is less repetitive and easier to read (IMO) if "The blahblah function is" is replaced with just "blahblah is". There was some contention about this, as you might recall. I've been assured that I am worse than that one bad guy for thinking this.

So:

.Fn OWLL_WRITE_ONE
​and
​.Fn OWLL_WRITE_ZERO
write a...

and just

.Fn OWLL_READ_DATA
​reads one...

This can be repeated all through this page for a shorter and clearer result.

Try to avoid the informal "you":

Rather than calling the
.Nm
interface directly, consider augmenting the
.Xr own 9
interface to expose the needed functionality instead.

Missing "s", extra word:

These functions are split into three groups:

A little vague here. "Should" used as a recommendation is fine. "Generally" gets a little questionable. As opposed to what other options? Why?

Something about the wrappers providing safer or more general-purpose usage?

Probably can replace "to the devices on the bus" with just "to devices.":

The 1-Wire bus defines different layers of access to devices.

"of the bus" is not needed:

functions provide access to the network and transport layers.

Trailing preposition. Some people say these are fine, but they often indicate that the sentence can be rearranged to make more sense. Not sure on this. Does the network layer "specify" (as in choose) the clock speed of transport layer commands, or do transport layer commands just work at whatever rate the network layer is set to use? In other words, can transport layer commands run at a different clock rate than the network layer? I'd guess not, and guess that it really means this:

Transport layer commands run at a clock rate (speed?) determined by the network layer.

Rearrange to avoid nonspecific "it" when possible. Also, serial comma:

Network access, speed, and timing information are encapsulated in this structure,
as are commands to send and whether or not data is read.

s/files/fields/ (although this came up the other day somewhere else, C actually calls these "members" of a struct)

"Various" is not needed.

Flags to control the interpretation of the structure.

These flags are defined in

ROM is capitalized later on, should be here also.

This is... confusing. It is hard to tell the groupings. "Send Transport" seems like a description, not a verb, but hard to tell. Is "stuff" a noun or a verb? If this is just a single flag, it might help to start with "Enable" or "Set". Some quotes on the pairings of words could help, too:

Enable
.Dq Send Transport
(XPT) overdrive speed.

(Later flags are described with sentences ending in a period, so I added that here too.)

Probably:
s/send/sent/

Needs a comma for the pause:

.Va flags ,

"then" is not needed.

it is the number of bits to read.

Avoid the "The blah function" and use just a comma rather than the aside. Also, use active voice:

.Fn own_command_wait
acquires the 1-Wire bus, waiting if necessary,
sends the command,
then releases the bus.

Again, recommend losing the redundant "The function" wording and pause:

.Fn own_send_command
sends the command without bus reservation.

"The" not needed.

Trailing preposition... but let's see if the alternative is any better:

.Fa pdev
is the client, presentation layer device, on whose behalf the command is sent.

Hmm, not bad.

"The" and "argument" are not needed.

.Fa cmd
describes the transaction to send to the 1-Wire bus.

"The" not needed.

"the ... argument" is not needed. But some rewriting to avoid this long sentence should be done:

.Fn own_self_command
fills in
.Fa cmd
with a MATCH_ROM command.
This includes the ROM address of
.Fa pdev
and
.Fa xpt_cmd
as a convenient way to create directed commands.

The final "to the bus" is not needed:

presentation layer devices can use to coordinate access.

s/The locking/Locking/
s/at this time/at present/

Locking is purely advisory at present.

Eliminating the "The ... function" and going passive->active:

.Fn own_acquire_bus
reserves the bus.

We're talking about the function already, so I'm inclined to use "It" here. And passive->active:

It waits indefinitely if
.Fa how
is
.Dv OWN_WAIT
and returns with the error
.Dv EWOULDBLOCK
if passed
.Dv OWNDONTWAIT
when the bus is owned by another client.

Simplify this sentence, removing the "The ... function":

.Fn own_release_bus
releases the bus.

Nice! Easier to read without saying "the buffer argument" and "the len argument".

Probably can remove a "the":

the timing of signaling of different modes, and the polling

Could be clearer if the multiple "of"s could be simplified ("timing of signalling of different modes"). Maybe break into separate sentences.

"is" is not quite right here. Maybe:

presentation layer is composed of the device-specific commands and actions used to

"the" not needed here, nor is "on bus":

control specific 1-Wire devices.

Guidelines say we should always call them "manual pages", but here we can probably do better:

device) should only call the functions described here.

Double free.

The kids variable is already freed on line 132 (this line can be removed).

Experience has shown that this loop is pathological when talking to a naked bus.

We get a count of all the possible address IDs, most of which have CRC errors.

At effectively SPLHIGH().

This must be mitigated somehow.

Some suggestions:

1. add some kind of 'ensure the bus is idle' callback to the owll layer.
2. make sure the owll layer signals read errors by making sure the line eventually goes high and erroring out somehow here.
3. Profit!

"implements the", or "implements a"

What are the return code(s)?
Add one for 'bus held low' i.e. delay for G and read, if it's low bail out.

That's a good question. And a good suggestion for dealing with the 'stuck low' issue. I'll document some convention here.