handled before the cv_timedwait_sig() call, or while polling.
Seems to fix "sunxitwi0: send STOP failed" messages frequently seen related
to axp20x0 sensors.
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!)
It was a hack meant only for EEPROMs, which have another way to specify
size in the config directive ("flag" paramter), as well as a better way
to detect size based on "compatible" string.
super-general, it turns out I also made it a little to cumbersome
to use (if my tired fingers are any indication). So, this is a
course-correction -- one string per entry (like of_compat_data,
which it will soon replace), and remove the over-verbose macros.
to use the new device_compatible_match() routine. A pointer to
the matching device_compatible_entry is returned if a match is
found.
- Adjust iic_use_direct_match() accordingly.
- i2c drivers now provide device_compatible_entry tables when performing
direct-config matching.
- In the dsrtc driver, take advantage of this new capability to greatly
simplify model selection.
(I'm coming for you next, of_compat_data...)
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
In addition to the above:
- Add support for direct-config matching this driver based on
"compatible" properties.
- Address-only matching is now done based on the specific addresses
the requested model supports.
- "compatible" property can specify to the driver which model is to
be used, so that using config "flags" directives aren't required
in the direct-config case.
XXX More changes coming that require re-factoring some other code.
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
XXX This driver is an odd-ball with respect to the hardware device.
See comments in the match routine. Unclear how best to handle it.
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
— iic_search() chooses a “probe strategy” based on the
"i2c-indirect-probe-strategy” property on the “iic” instance.
Valid values are "smbus-quick-write”, "smbus-receive-byte”, and
“none”. If no value is specified, the default is "smbus-quick-write”.
— If the "i2c-indirect-device-whitelist” exists on the “iic” instance,
iic_search() will first check the driver name in the cfdata_t against
this list, and only allow the match/probe to move forward if the
cfdata_t driver name is in the list. This is primarily to accommodate
the Intel integrated memory controller neutered-i2c-thing.
— If the cfdata_t specifies a wildcard address, each address of the i2c
bus will be consulted. If the cfdata_t contains a nailed-down address,
then we limit the bus scan to that specific address.
— We explicitly skip reserved / special i2c addresses, such as the
General-Call address, etc.
— We introduce the notion of a “match quality” for i2c drivers. From
lowest-quality to highest-quality: matched by plausible address only,
matched by plausible address and poking at the bus to see if the
device looks reasonable, matched by direct-config “compatible” string,
matched by direct-config “driver name” string.
— If the “match quality” is merely “plausible address only”, then
iic_search() will use the probe strategy selected above to see if
a device responds to that address.
busses would end up with "ghost" device instances on the second bus. This
issue was previously masked on ARM systems by the empty-child-devices
array issue fixed recently (that effectively blocked all indirect config
of i2c busses on those systems).
To fix this problem, we require that indirectly-configured devices have
to fully specify their parent spec and address, e.g.:
foo* at iic0 addr 0x55
NOT
foo* at iic? addr ?
or even:
foo* at iic? addr 0x55
This is needed because of how indirect configuration works... attach
directives in the kernel config file are enumerated, calling the bus's
search routine, which in the case of i2c, enumerates all i2c addresses
and calls the match routine for each address. Because we can't always
reliably probe for i2c devices, we ended up with erroneous matches.
Direct configuration of i2c is still allowed to use wildcarded parent specs
and locators.
POKSIRQ is triggered if POK remains low for less than IRQLEVEL. This makes
it way too easy to accidentally trigger shutdown. POKLIRQ is triggered if
POK hold time is greater than IRQLEVEL, which is much more reasonable for
this use case.
