To wrap this up (as there has been some confusion):

@eadler no need to apologize, thanks for your effort.

Updated to versions a of 20150626, therefore this review is obsolete now => Abandon Revision.

@koobs thanks, I'm building new versions of those packages right now, I'll test them and commit shortly.

I'm more than happy to pass those ports on to you @mat or phabric-admin, please make sure you update and test devel/phabrictor though (as phabric-admin@ runs a heavily customized version of phabricator).

@mat this won't build as long as devel/libphutil/distinfo is broken (see my comment above). Accept Revision shouldn't have an "if it works" comment in it, but mean that some actual review happened (well, AFAIK).

After fixing libphutil/distinfo this installed fine. I rolled it out at work yesterday and so far it seems to work ok.

Add extra newline to comply to style(9), change PZERO to 0 in mtx_sleep

Please fix distinfo of arcanist and test building all three ports.
(I'll install and test those versions @work to see if they are ok otherwise)

Add extra newline to comply to style(9), change PZERO to 0 in
mtx_sleep as suggestedi. Tested the change it works fine.

Next iteration.

Same as before, but this time with the actual change: Add comment
to clarify locking semantics.

Add comment that aims to clarify locking semantics.

Feedback I received from @wblock by email:

In D2744#53895, @grembo wrote:

In D2744#53837, @kib wrote:

In D2744#53712, @grembo wrote:

I think that clarification of the mutex/io_lock semantic is required as the first step.

call_lock protects a series of calls to the controller (set_controller/slave/wait_status) that form an ioctl so they won't interleave, while io_lock is used to coordinate the interrupt handler with other I/O to the controller, especially wait_status.

That far I can understand myself from reading the code. What I cannot get from the code alone, without using some kind of mind-reading low-tech solution, is what is the intent for the bounds of transactions manipulating the hardware state. E.g., why is it fine to allow the interrupt handler to intervene while waiting for i/o completion:

Why do you think this wouldn't be the case?

what hw state should be re-acquired after the sleep ? Does the interrupt handler need exclusion with the top half of the driver, if needed, why ? ... etc

Which sleep are you referring to (mtx_sleep in wait_status maybe)? Why would a hardware state need to be reacquired? And where does the "top half of the driver" end?

In D2744#53837, @kib wrote:

In D2744#53712, @grembo wrote:

I think that clarification of the mutex/io_lock semantic is required as the first step.

call_lock protects a series of calls to the controller (set_controller/slave/wait_status) that form an ioctl so they won't interleave, while io_lock is used to coordinate the interrupt handler with other I/O to the controller, especially wait_status.

That far I can understand myself from reading the code. What I cannot get from the code alone, without using some kind of mind-reading low-tech solution, is what is the intent for the bounds of transactions manipulating the hardware state. E.g., why is it fine to allow the interrupt handler to intervene while waiting for i/o completion:

I think that clarification of the mutex/io_lock semantic is required as the first step.

call_lock protects a series of calls to the controller (set_controller/slave/wait_status) that form an ioctl so they won't interleave, while io_lock is used to coordinate the interrupt handler with other I/O to the controller, especially wait_status.

Remove locks in callback and simplify unsupported smb_quick call.

Are there any specific features or is this "only" about staying current/compatibility like you stated in the summary section?

@jhb & @adrian: Do you think this is acceptable now?

Make calling bus_generic_detach dependent on device_is_attached(dev)

Next iteration based on code review.

Next iteration follows soon.

Further man page improvements as suggested by @wblock

@jhb This shouldn't interfere with I2C in KMS.
@jhb In terms of licensing, are there any best practices? Like if you port one feature from another BSD to FreeBSD (like a patch to the keyboard driver, maybe a few lines of code), will this affect the the license of the original file? When porting something completely new (like in this case), at which point should the porter be mentioned in the header - you clearly don't want to blame the original author for porting and/or system specific bugs. Something like:

Man page changes as suggested by @wblock.

Will send a new revision with man page changes shortly (is there a better workflow? It always seems odd to comment on changes here and then create another arc revision).

These data is -> This data is

Set all ending man page changes to closed for new review request.

@adrian & @jhb: Could you both accept the revision (only changes since last accept were to the man page), so I can commit it. Thanks.

Changes to man page like discussed with @wblock, for the remaining changes
to the man page I'll open a new code review request once this one has been
committed.

Closed by commit rP383964 (authored by @grembo).

@wblock Added you as a reviewer for man page changes. The code should be good enough at this point.

Put output of successful probes under bootverbose (nomatch isn't
not worth the effort and could be added at a later point in time).

Same as before, but pass all changed files to arcanist.

Use bus_generic_probe instead of device_add_child like suggested
by @jhb, works, thank you.

Improvements as suggested by @jhb. This works now, thanks a lot for the
insight.

@jhb and @imp:

Changes as suggested by @imp

@imp Did a couple of more changes, please check the next iteration that I'll submit shortly.

Changes like discussed:

• Remove enum smbus_child_ivars, turn SMBUS_IVAR_ADDR into enum
• Add __BUS_ACCESSOR to address which returns int (can return -1)
• Change code structure of smbus_read_ivar and make it set set response to -1 in case no addr is set

I sent an email to arch, let's see if there is any additional feedback. I'll submit a new version with the changes from the inline comments soon.

Changes like discussed inline (various style fixes and optimization,
new man page, new calls like print_child, location_str etc.).

@jhb Thanks for your detailed review, please see replies for details.

Replace magic numbers with #defined values as requested.

Closed by commit rS279222 (authored by @grembo).

Is there anything else I could do to move this forward?

Removed 32MiB check from code like suggested (reverted comment changes).

Closed by commit rS278787 (authored by @grembo).

Changes like requested, I will add a few more inline comments.

Closed by commit rP378836 (authored by @grembo).

Added symlink from dom.cpp to dom.c for symmetry reasons

Closed by commit rS278541 (authored by @grembo).

@adrian acknowledged this revision (thanks), but he also pointed out, that he thinks this needs more testing before committing. I tried to get some attention on freebsd-current, but this isn't a very interesting topic for people to test, so even though it's been only a few days, I don't think this will result in sufficient testing.

I like the idea of structuring quirks in a more uniform way, but since we have those in many different places (drm2, USB, CAM, ACPI) I think this should be approached in a separate effort.

Add newline to match style

New approach, reverted to the original version and added changes based
on quirks.