lkml.org 
[lkml]   [2015]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: spi: OF module autoloading is still broken
From
Date
Hello Mark,

On 11/17/2015 10:19 AM, Mark Brown wrote:
> On Tue, Nov 17, 2015 at 10:14:27AM -0300, Javier Martinez Canillas wrote:
>> On 11/16/2015 06:51 PM, Brian Norris wrote:
>
>>> Lest someone else wonder whether this is theoretical or not, I'll save
>>> them the work in pointing at an example: "st,st33zp24". See:
>
>>> Documentation/devicetree/bindings/security/tpm/st33zp24-*.txt
>
>>> and the code is in drivers/char/tpm/st33zp24/, sharing the same core
>>> library, suggesting that the devices really are the same except simply
>>> the bus.
>
>> Thanks for pointing out that example although for that specific case,
>> the drivers' compatible are "st,st33zp24-i2c" and "st,st33zp24-spi" to
>> avoid the issue explained before.
>
> Eew, that's gross.
>

Well, I'm not the author of the driver but I've seen many drivers doing
the same so I believe the reason is to avoid the issue explained before.

>> I still didn't find an example where the same compatible string is
>> used for different drivers (i.e: "st,st33zp24" or "google,cros-ec")
>> but the fact that is possible for legacy and not for OF is worrisome.
>
> There's a bunch of audio CODEC and PMIC drivers, arizona is the first
> example that springs to mind but it's very common to have mixed signal
> devices devices which can run in both I2C and SPI modes.
>

Thanks a lot for the examples, I just looked at the arizona MFD drivers
and indeed the same OF device ID table is used for both the SPI and I2C
drivers.

Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America


\
 
 \ /
  Last update: 2015-11-17 15:01    [W:0.045 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site