As far as I can tell, this driver must have produced this error
for as long as it has been merged into the mainline kernel, but
it was never part of the normal build tests:
drivers/i2c/busses/i2c-nuc900.c: In function 'nuc900_i2c_probe':
drivers/i2c/busses/i2c-nuc900.c:601:17: error: request for m
On Wed, May 14, 2014 at 09:17:49PM +0200, Wolfram Sang wrote:
>
> > For the moment, I'd leave this up to Wan ZongShun. He has in the past
> > at least replied to emails about the platform, even though there hasn't
> > been any new development.
>
> Agreed. Let's wait for his response. If there is
On Thu, May 08, 2014 at 04:56:22PM +0200, Arnd Bergmann wrote:
> As far as I can tell, this driver must have produced this error
> for as long as it has been merged into the mainline kernel, but
> it was never part of the normal build tests:
>
> drivers/i2c/busses/i2c-nuc900.c: In function 'nuc900
On Wednesday 14 May 2014 18:27:25 Wolfram Sang wrote:
> On Thu, May 08, 2014 at 04:56:22PM +0200, Arnd Bergmann wrote:
> > As far as I can tell, this driver must have produced this error
> > for as long as it has been merged into the mainline kernel, but
> > it was never part of the normal build te
> For the moment, I'd leave this up to Wan ZongShun. He has in the past
> at least replied to emails about the platform, even though there hasn't
> been any new development.
Agreed. Let's wait for his response. If there is none, I'll think about
removing the driver.
signature.asc
Description:
"[PATCH] NUC900: patch for implement clk_get_rate"
https://lkml.org/lkml/2010/6/15/147
This patch would have fixed the apbfreq not being a real struct member
and would also explain why clk_get_rate is called without using it's
return value in the line above what you have.
>From 2010, so it got dr
6 matches
Mail list logo