FreeBSD_HEAD_amd64_gcc4.9 - Build #633 - Fixed:

Build information:
Full change log:
Full build log:

Change summaries:

289105 by ian:
Translate iic hardware layer status values to errno return values.

289104 by ian:
Add a short name, IIC_INTRWAIT, for the common case (IIC_INTR | IIC_WAIT).

289103 by np:
iw_cxgbe: fix for page fault in cm_close_handler().

This is roughly the iw_cxgbe equivalent of
RDMA/cxgb4: Connect_request_upcall fixes

When processing an MPA Start Request, if the listening endpoint is
DEAD, then abort the connection.

If the IWCM returns an error, then we must abort the connection and
release resources.  Also abort_connection() should not post a CLOSE
event, so clean that up too.

Signed-off-by: Steve Wise <>
Signed-off-by: Roland Dreier <>

Submitted by:   Krishnamraju Eraparaju at chelsio dot com.

289102 by ngie:
Remove all of the syncs

They're unnecessary as shown by further testing on my VM

Requested by: jhb

289099 by adrian:
Flip on fast frames support for AR5416 and AR9300 series NICs.

This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.

Now that net80211 doesn't panic, let's flip this back on.

It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next.  It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)


* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)

289098 by ian:
Fix more cases of iicbus-layer functions that must return IIC_Exxxx values.

289097 by ian:
Return only IIC_Exxxx status values from iicbus-layer functions.  Most of
these functions are thin wrappers around calling the hardware-layer driver,
but some of them do sanity checks and return an error.  Since the hardware
layer can only return IIC_Exxxxx status values, the iicbus helper functions
must also adhere to that, so that drivers at higher layers can assume that
any non-zero status value is an IIC_Exxxx value that provides details about
what happened at the hardware layer (sometimes those details are important
for certain slave drivers).

289096 by bapt:
Move ppp.conf into the ppp sources

289095 by ian:
Add iic2errno(), a helper function to translate IIC_Exxxxx status values to
errno values that are at least vaguely equivelent.  Also add a new status
value, IIC_ERESOURCE, to indicate a failure to acquire memory or other
required resources to complete a transaction.

The IIC_Exxxxxx values are supposed to communicate low-level details of the
i2c transaction status between the lowest-layer hardware driver and
higher-layer bus protocol and device drivers for slave devices on the bus.
Most of those slave drivers just return all status values from the lower
layers directly to their callers, resulting in crazy error reporting from a
user's point of view (things like timeouts being reported as "no such
process").  Now there's a helper function to make it easier to start
cleaning up all those drivers.

289094 by bapt:
Rename the dma directory into dmagent to avoid collision on unclean oject
directory where an old dma binary can remain

289093 by ian:
Use IIC_EBUSBSY and IIC_BUSERR status values consistantly across all drivers.
Make it clearer what each one means in the comments that define them.

IIC_BUSBSY was used in many places to mean two different things, either
"someone else has reserved the bus so you have to wait until they're done"
or "the signal level on the bus was not in the state I expected before/after
issuing some command".

Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors,
and IIC_BUSBSY refers to ownership/reservation of the bus.

289091 by ian:
Mostly rewrite the imx i2c driver.  This started out as an attempt to fix
one specific problem: the driver didn't check for ACK/NAK after writing a
slave address byte to the bus, and some slaves signal that they are busy
(such as when completing an internal write to flash memory) by sending a
NAK in response to being addressed.

While working on that problem I discovered that the driver's handling of
error conditions in general didn't match the state transition diagram in
the reference manual, and making that right resulted in a lot of code

Along the way various other changes also happened...

 - Remove a mutex that wasn't protecting anything.
 - Remove some mystery DELAY()s, document the few that remain.
 - Use pause_sbt(9) to yield the processor for the bulk of the time it
   takes to transfer each byte rather than busy-polling the whole time.
 - Disable the controller when no transfers are in progress; since we
   don't operate in slave mode, there's no reason to run the hardware.
 - Remove a bunch of unecessary code from probe().

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to