On Fri, Nov 14, 2014 at 05:38:58PM +0900, Alexandre Courbot wrote:
> On 11/14/2014 10:43 AM, Kuninori Morimoto wrote:
[...]
> >diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
> >index a1d4bf9..7f5cf80 100644
> >--- a/arch/arm/boot/dts/tegra20-seaboard.dts
> >+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
> >@@ -405,7 +405,7 @@
> > clock-frequency = <400000>;
> >
> > magnetometer@c {
> >- compatible = "ak,ak8975";
> >+ compatible = "asahi-kasei,ak8975";
>
> Mmm. So does this mean this device was never probed because the driver did
> not recognize its compatible property?
I2C (like SPI) has a fallback in case the OF table yields no match. The
of_modalias_node() that it uses extracts the module name from the device
tree node's compatible string by skipping the vendor prefix. The
resulting string is then set as the I2C client's name and causes the I2C
standard ID matching to succeed (see of_i2c_register_devices() for how
this is done in detail).
> I cannot find "ak,ak8975" anywhere else in the kernel.
>
> If so,
>
> Acked-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
Technically this is breaking backwards-compatibility from a DT
perspective, but I think it's safe to do because the Linux kernel has a
way of dealing with this and other operating systems should be able to
deal with this in a similar way (or even easier by letting the driver
match on the ak prefix as well for this particular chip).
So:
Acked-by: Thierry Reding <treding@xxxxxxxxxx>
Attachment:
pgpCqM0RwFqO2.pgp
Description: PGP signature
