Ticket #149 (closed defect: wontfix)
lm4857 not i2c address compliant
| Reported by: | graeme@… | Owned by: | michael@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | kernel | Version: | current svn head |
| Severity: | major | Keywords: | |
| Cc: | buglog@…, cw@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
While doing the driver for the wm8753 I needed to turn on the lm5857 amp chip
which required talking to it through I2C bus.
I have found the two addresses the chip can use (0x7C, 0x7D) are not i2c
compliant as they are in the reserved range according to the i2c spec. This
means the i2c driver in the kernel rejects this address when trying to create an
i2c connection to this chip.
The code at 652-657 in i2c-core.c is responsible for this checking.
/* Make sure the address is valid */
if (addr < 0x03 addr > 0x77) { dev_warn(&adapter->dev, "Invalid probe address 0x%02x\n",
addr);
return -EINVAL;
}
I have had to comment out this check in order to make use of this chip.
I think this causes problems for neo1973 audio support to enter mainline ASoC as
I guess kernel core will never accept this change.
Change History
comment:3 Changed 6 years ago by willie_chen@…
- Status changed from assigned to closed
- Resolution set to fixed
lm4857 can work now
comment:4 Changed 6 years ago by willie_chen@…
- Status changed from closed to reopened
- Resolution fixed deleted
Masking check i2c address code isn't good solution.
We need to find out good solution for lm4857.

Now how stupid is that, using a reserved range. Somebody should LART natsemi
about such crap.
With regard to mainline support for the Neo1793 ASoC platform/machine driver, I
think we can probably compromise somehow. Permanently disabling the check is
not an option, but adding something like a device specific quirk that a device
driver can tell the i2c-core which would then become a bus-specific property.
We have bugs and fixes around hardware issues all over the kernel device
drivers. I don't think it's a fundamental problem.