[OpenWrt-Devel] Did you do any testing on 3.18?
hkallweit1 at gmail.com
Tue Dec 9 16:02:02 EST 2014
With change set 43563 the kernel was updated to 3.14.26 so I guess that
all mpc85xx builds since then will face this problem caused by
After having a brief look at this commit I think that instead of reverting
this commit the better fix would be to fix the dts for TL-WDR4900 to
have proper "ranges" definitions.
However I'm not a device tree expert at all ..
Am 09.12.2014 um 20:05 schrieb Trond Haugland:
> You might have noticed that the same problem has popped up on 3.14.26.
> In any case, I've narrowed it down to a change in
> drivers/of/address.c. Here is the reverted patch, works great on
> 3.18.0 for me :)
> On Tue, Dec 2, 2014 at 4:33 PM, Trond Haugland <trondah at gmail.com> wrote:
>> Unfortunately way over my head :) I noticed that the platform
>> 210-spi-fsl-espi-preallocate-local-buffer.patch seems to fix a similar
>> issue. A -12 error is described in the header of that patch.
>> On Tue, Dec 2, 2014 at 2:16 PM, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>>> No, so far I'm using 3.14.25.
>>> -12 is the errno value for ENOMEM. You could check (e.g. by adding pr_info
>>> output) where this error is coming from in gfar_probe.
>>> Rgds, Heiner
>>> On Tue, Dec 2, 2014 at 11:52 AM, Trond Haugland <trondah at gmail.com> wrote:
>>>> Hello again Heiner :)
>>>> Just wondering if you have started using 3.18 on your WDR4900.
>>>> Something changed in rc6 that breaks gianfar probe routine:
>>>> It's not related to your auto negotiation patches, I've already tried
>>>> reverting the ar8216 patches. Everything works great with rc5. I've
>>>> looked at the changelog for rc6 but can't see anything that looks
>>>> related. Guess something changed that breaks the platform patch in
>>>> some way.
>>>> Trond Haugland
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel