/include/asm/bug.h:24:2: error: implicit declaration of function
'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
Reported-by: kernel test robot
Cc: Randy Dunlap
Cc: Evan Quan
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Alex D
no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
>
> Had it been split up, the drm parts would've been merged already.
FWIW, the amdgpu and scheduler changes have already been fixed for -next.
Alex
>
> BR,
> Jani.
>
> -
is "for-curr" and "for-next" (or equivalent) trees?
next:
https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
fixes:
https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
Alex
>
>> Also, your pull is missing the [PULL] tag in the
>> subject.
>
&
h 'regression' and 'bug' categories.
Not sure what changed under the hood from 4.9 to 4.13-rc3 to cause such
a drastically different behavior. I can't really do much else as
workarounds, since the GMAC registers are not writable while the GMAC is
in reset.
Alex
[
plan to later
remove the fpga dts once the actual silicon works.
[snip]
+#include "skeleton.dtsi"
Perhaps put a one liner that this is based on SNPS ARC700 cpu !
Staged for [PATCH v2].
Alex
+
+/ {
+compatible = "adaptrum,anarion";
+#address-ce
be sure to CC netdev@ on
[PATCH v2].
Alex
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
et, but that requires a custom platform early_init(), and a glue
driver for snps,dwmac.
Let me know if it helps.
Yes. I implemented the proof-of-concept today. It's a very "interesting"
balancing act on when exactly to release the reset on the GMAC. I&#
