Fix problems noted by wblock

Fix lint warnings

Move each sentence to its own line

Fixing the bugs kib pointed out

I think it is possible for calls into the smbus interface to get interleaved right now. If they come from smb(4) ioctls, they could get interleaved because that driver does not hold its own sx like iic(4) does (and did even before r281828). But those calls could also be made by another driver directly calling something like smbus_bwrite(), without going through smb(4).

Addressing wblock's feedback

Closed by commit rS281828 (authored by @jah).

@imp, @loos: can you guys look over this again as soon as you get a chance and see if you find it acceptable from an iic perspective?

addressing jhb's feedback:

• looping on short writes
• always using M_WAITOK
• style(9) fixes

imp, loos: can you guys look over this again when you have time?
I also need some clarification on Warner's comment about the lock.

Change chunk size back to 128 bytes. That should still be OK to keep on the kernel stack. 32 might be too stingy for faster iic controllers.

--Shrink chunk size to 32 bytes (same as smbus blocksize), move buffer to stack
--Respect O_NONBLOCK for mallocs
--Document IICBUS_CALLBACK locking assumptions in iiconf.c and iicbus interface

Remove stale comment

Don't loop on EWOULDBLOCK.
I think we can deal with any fallout. There might be none.

In D2140#5, @loos wrote:

I agree with most of your changes (and thank you for tackling this), but maybe it is time to get rid of the busy loop on EWOULDBLOCK case.

EWOULDBLOCK could only happen when the caller request the iicbus with IIC_DONTWAIT, wouldn't be better to just return EWOULDBLOCK in this case ?

Then the caller could deal with retrying if necessary.

I think this would also make the lock dropping on iicbus_poll() unnecessary.

What do you think ?