Re: [PATCH v3 3/3] fs: add support for SquashFS 4.0
On Fri, 19 Feb 2016 15:49:15 +0100 yegorsli...@googlemail.com wrote: > From: Yegor Yefremov > > The driver was imported from Linux 4.4. > > Current implementation supports only XZ decompressor. > > Cc: Antony Pavlov > Signed-off-by: Yegor Yefremov I have just tested this series on AR9331-based board, so Tested-by: Antony Pavlov However there are some issues, see below > --- /dev/null > +++ b/Documentation/filesystems/squashfs.rst > @@ -0,0 +1,15 @@ > +.. index:: squashfs (filesystem) > + > +SquashFS filesystem > +=== > + > +SquashFS is a highly compressed read-only filesystem for Linux. > +It uses zlib, lzo or xz compression to compress both files, inodes > +and directories. A SquashFS filesystem can be mounted using the > +:ref:`command_mount` command:: > + > + mkdir /mnt > + mount -t squashfs /dev/spiflash.FileSystem /mnt > + ls /mnt > + zImage barebox.bin > + umount /mnt Please add barebox prompt to this example, e.g.: barebox:/ mkdir /mnt barebox:/ mount -t squashfs /dev/spiflash.FileSystem /mnt barebox:/ ls /mnt zImage barebox.bin barebox:/ umount /mnt I suppose that the 'squashfs squashfs0: squashfs_mount' message is redundant, e.g: barebox:/ mount -t squashfs /dev/spiflash.linux /mnt/ squashfs squashfs0: squashfs_mount barebox:/ ls /mnt/ binboot devetchome init liblib32 linuxrcmedia mntopt proc root runsbin systmp usrvar Also I see a memory leak on mount (By mistake I have tried to mount non-cdev squashfs image): barebox:/ meminfo used: 2693564 free: 14074728 barebox:/ mount -t squashfs rootfs.20160223.xz-squashfs /mnt/ squashfs squashfs0: probe failed: Invalid argument mount: Invalid argument barebox:/ meminfo used: 2693636 free: 14074644 barebox:/ mount -t squashfs rootfs.20160223.xz-squashfs /mnt/ squashfs squashfs0: probe failed: Invalid argument mount: Invalid argument barebox:/ meminfo used: 2693748 free: 14074524 barebox:/ mount -t squashfs rootfs.20160223.xz-squashfs /mnt/ squashfs squashfs0: probe failed: Invalid argument mount: Invalid argument barebox:/ meminfo used: 2693832 free: 14074428 -- Best regards, Antony Pavlov ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] commands: magicvar: make locally used magicvar_find() static
The patch fixes this compiler's warning:
commands/magicvar.c:27:22: warning: no previous prototype for
'magicvar_find' [-Wmissing-prototypes]
struct magicvar_dyn *magicvar_find(const char *name)
^
Signed-off-by: Antony Pavlov
---
commands/magicvar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/commands/magicvar.c b/commands/magicvar.c
index 6737eb5..8740784 100644
--- a/commands/magicvar.c
+++ b/commands/magicvar.c
@@ -24,7 +24,7 @@ static void magicvar_print_one(struct magicvar_dyn *md, int
verbose)
}
}
-struct magicvar_dyn *magicvar_find(const char *name)
+static struct magicvar_dyn *magicvar_find(const char *name)
{
struct magicvar_dyn *md;
--
2.7.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: phytec-som-imx6: DCD setup: PLL reduction and video core settings
Hi Andreas, thanks a lot for your detailed write-up. Indeed these register settings are confusing. > What concerns me more is the CPU core clock reduction: > // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on, > // bypass off, 396MHz > // reset default: 0x00013042 => PLL not locked, PLL off, bypass on, > // bypass 24MHz osc as src, pll divider > // for 792MHz > // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for > // 396MHz ; Attn.: PLL locked is w/o ; divider for > // 396MHz is below valid range > wm 32 0x020c8000 0x80002021 > Comments again added by me. > > Two things here look questionable to me: > 1.) Datasheet says valid divider values are 54-108, so the > default 0x42=66 is in range, whereas the 0x21=33 is not. > 2.) Even if the divider value is legit, the change flow might be not. > A PLL normally takes some time to lock. We have tracked down the origin of this DCD entry internally. It originated from a PMIC workaround for the phyFLEX-i.MX6 in an older barebox version which isn't mainline. It had a comment attached to it, but that was dropped while bringing the phyFLEX-i.MX6 mainline. We will take a closer look to that issue next week, whether the fix is still needed or can be resolved differently. Mit freundlichen Grüßen / Kind regards, Stefan Christ On Fri, Feb 19, 2016 at 08:28:25PM +0100, Andreas Pretzsch wrote: > While looking into a maybe boarderline RAM setup on one specific piece > of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec > i.MX6 modules in barebox. > And came across two things that look ... somewhat questionable, maybe > worth a look. > > In the very first setup (the DCD) in > arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h > there is a block > wm 32 0x020e0010 0xf0ff > wm 32 0x020e0018 0x007F007F > wm 32 0x020e001c 0x007F007F > wm 32 0x020c8000 0x80002021 > at the end. > > > The first three (comments about complete register meanings added by me) > // IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge > wm 32 0x020e0010 0xf0ff > // IOMUX_GPR6 : IPU1 QoS setup > wm 32 0x020e0018 0x007F007F > // IOMUX_GPR7 : IPU2 QoS setup > wm 32 0x020e001c 0x007F007F > do setup some cache attributes of VDOA, IPU, VPU (some of the video > cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they > maybe do not harm, and can be found also in various other board files. > Might be some case of copy-from-copy, no idea. > Not sure if these really should be part of lowest-level memory setup... > Maybe - if at all - in some board-specific setup, given barebox drives a > display. > Also, a quick google search shows the possible origin, and that it has > been removed in some U-Boot branch, leaving it to the Linux kernel: > https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch > So maybe more of a cleanup issue. > Not only in the Phytec DCDs, but maybe also the other ones. > > > What concerns me more is the CPU core clock reduction: > // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on, > // bypass off, 396MHz > // reset default: 0x00013042 => PLL not locked, PLL off, bypass on, > // bypass 24MHz osc as src, pll divider > // for 792MHz > // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for > // 396MHz ; Attn.: PLL locked is w/o ; divider for > // 396MHz is below valid range > wm 32 0x020c8000 0x80002021 > Comments again added by me. > > Two things here look questionable to me: > 1.) Datasheet says valid divider values are 54-108, so the > default 0x42=66 is in range, whereas the 0x21=33 is not. > 2.) Even if the divider value is legit, the change flow might be not. > A PLL normally takes some time to lock. > > Now, I have not looked yet at the PLL setup and/or scaling code of the > kernel, both wrt PLL change flow as well as dividers. So this might be > ok, and even if only implicitly (like due to some implicit delay after > DCD got parsed). > And obviously it works. "Only" misses a comment whats it does. And only > present in some of the Phytec DCDs, as far as I can see. > > But what I like to understand is why ? > I mean, scaling down the i.MX6 to its minimum frequency (half of > default) in the bootloader, to get a maximum stable state, ok. Even if > it extends the bootup time. > > But why after all the IOMUX, MMDC and DDR setup is through ? > Probably too late if it is about some PMIC-reset-voltage-scaling issue. > Or some thermal precaution ? > > By the way, the above setups goes back through long history, as in > a540c30 boards: A
Re: bootm crash - bad uimage?
This commit doesn't seem to fix the problem (in fact it was already applied when I saw the crash). Note: I am using mkimage to create bootable image of a real-time OS (PikeOS). There is no initrd or dtc at this step for now: I guess it is like loading an old Linux kernel without userspace. I do not want to bother you with a specific use case if this is the root of the problem. Best regards, Philippe LEDUC ledphili...@gmail.com 2016-02-23 9:05 GMT+01:00 Sascha Hauer : > Hi Philippe, > > On Mon, Feb 22, 2016 at 04:31:18PM +0100, Philippe Leduc wrote: >> Hello, >> >> Since the commit 0a37e22d638acf1b2c7c6e6ab83b6a3272b0a11c, I can't >> boot my image anymore. >> It seems that os_part is a null pointer and simple_strtoul crash on it >> (in bootm_load_os). I workaround the problem by forcing the value to 0 >> if os_part if null, but I guess that it is a bad solution. >> Is this a due to a bad usage of the mkimage utility? > > Probably not. Is this fixed by this commit? > > commit 1a180cd3b6e5c067c68f3e09f7e15e5b18af9761 > Author: Lucas Stach > Date: Fri Feb 12 17:58:23 2016 +0100 > > bootm: parse initrd and oftree into correct struct members > > The code parsing the oftree and initrd file names is clearly wrong, > leading to bootm not loading oftree or initrd files any more. > > Signed-off-by: Lucas Stach > Signed-off-by: Sascha Hauer > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Help configuring i.MX6 IPUv3 with a parrallel display
> Parallel display support for IPUv3 is not yet implemented.
I could have searched a long time ^^' (Fortunately there is the mailing list!)
I tried to add the simple panel but I do not get any framebuffer?
Here is the output of devinfo panel.13:
Driver: simple-panel
Bus: platform
Device node: /panel
panel {
compatible = "simple-panel";
status = "okay";
display-timings {
clock-frequency = <0x895440 0xe4e1c0>;
hactive = <0x1e0>;
vactive = <0x110>;
hfront-porch = <0x2 0x2 0x52>;
hback-porch = <0x2 0x2 0x29>;
hsync-len = <0x2 0x29 0x29>;
vback-porch = <0x1 0x2 0xb>;
vfront-porch = <0x1 0x2 0xe3>;
vsync-len = <0x1 0xa 0xb>;
pixelclk-active = <0x1>;
hsync-active = <0x0>;
vsync-active = <0x0>;
de-active = <0x1>;
};
port {
enpoint {
remote-endpoint = <0x3d>;
linux,phandle = <0x2b>;
phandle = <0x2b>;
};
};
};
So it seems that the driver is loaded, but there is no entry point for
the 'userspace'.
> Note that this binding is not compatible with the kernel
since the maintainer refuses to let display timings into the device tree
for simple panels.
OK, good to know.
Philippe LEDUC
ledphili...@gmail.com
2016-02-23 9:32 GMT+01:00 Sascha Hauer :
> On Mon, Feb 22, 2016 at 05:41:01PM +0100, Philippe Leduc wrote:
>> Hello,
>>
>> I would like to use the barebox framebuffer on a iMX6S chip. My goal
>> is to display a splashscreen. However, I can't manage to use the
>> framebuffer for now...
>>
>> Here is the output of "devinfo fb0":
>> Resources:
>> num: 0
>> start: 0x
>> size: 0x
>> Available modes:
>> Parameters:
>> enable: 0
>> mode_name: invalid:0
>> shadowfb: 1
>>
>> Is this a correct behavior that there is NO availables modes? I do not
>> manage to add one through the DTS.
>>
>> If I try to enable the framebuffer (fb0.enable=1), barebox hangs:
>> fb0.enable=1
>> unable to handle NULL pointer dereference at address 0x001d
>> pc : [<2ff1ab1c>]lr : [<2ff17f41>]
>> sp : 2a3c ip : 2ff1a3fa fp : 2a78
>> r10: 20212d0c r9 : r8 :
>> r7 : 20024210 r6 : f57f r5 : 0c00 r4 : 001d
>> r3 : 2ff1a1e5 r2 : 0c00 r1 : 005c r0 : 0022
>> Flags: nzcv IRQs off FIQs off Mode SVC_32
>> [<2ff1ab1c>] (clk_is_enabled+0x34/0x38) from [<7f8d1fc0>] (0x7f8d1fc0)
>>
>> [<2ff389d9>] (unwind_backtrace+0x1/0x58) from [<2ff00d19>] (panic+0x1d/0x34)
>> [<2ff00d19>] (panic+0x1d/0x34) from [<2ff38e7d>] (do_exception+0xd/0x10)
>> [<2ff38e7d>] (do_exception+0xd/0x10) from [<2ff38edd>]
>> (do_data_abort+0x21/0x2c)
>> [<2ff38edd>] (do_data_abort+0x21/0x2c) from [<2ff38bd4>]
>> (do_abort_6+0x48/0x54)
>> Switch to console [serial0]
>>
>> Here is what I put in the DTS to enable the display:
>>
>> display0: display@di0 {
>> compatible = "fsl,imx-parallel-display";
>> // crtcs = <&ipu1 0>;
>> interface-pix-fmt = "rgb24";
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_ipu_disp>;
>> status = "okay";
>>
>> display-timings {
>> rk043fn07h {
>> native-mode;
>> clock-frequency = <900 1500>;
>> hactive = <480>;
>> vactive = <272>;
>> hfront-porch = <2 2 82>;
>> hback-porch = <2 2 41>;
>> hsync-len = <2 41 41>;
>> vback-porch = <1 2 11>;
>> vfront-porch = <1 2 227>;
>> vsync-len = <1 10 11>;
>> pixelclk-active = <1>;
>> hsync-active = <0>;
>> vsync-active = <0>;
>> de-active = <1>;
>> };
>> };
>>
>> port {
>> display0_in: endpoint {
>> remote-endpoint = <&ipu1_di0_disp0>;
>> };
>> };
>>
>>
>> &ipu1_di0_disp0 {
>> remote-endpoint = <&display0_in>;
>> };
>
> Parallel display support for IPUv3 is not yet implemented. What's
> missing is a driver that matches to "fsl,imx-parallel-display", calls
> vpl_register on its own node and returns the display timings parsed from
> device tree in the VPL_GET_VIDEOMODES callback.
>
> You could try the following binding instead. It doesn't use the
> "fsl,imx-parallel-display" compatible but the "simple-panel" binding
> instead. Since IPU parallel display support is a no-op anyway this
> should work. Note that this binding is not compatible with the kernel
> since the maintainer refuses to let display timings into the device tree
> for simple panels.
>
> panel {
> compatible = "simple-panel";
>
> display-timings {
> /* your timings here */
> };
>
> port {
> display0_in: enpoint {
> remote-endpoint = <&ipu1_di0_disp0>;
> };
>
Re: bootm: booting of uncompressed uimages broken
Hi Hubert, On Tue, Feb 23, 2016 at 10:52:21AM +0100, Hubert Feurstein wrote: > Hi, > > booting of uncompressed uimages is broken since patch "ARM: bootm: fix > default uImage placement" (0839e3f402ffc74202a1ca4fbeaffcadb4336ce1): > > This is the change causing the issue: > @@ -138,13 +144,10 @@ static int do_bootm_linux(struct image_data *data) > return ret; > > /* > - * Put devicetree/initrd at maximum to 128MiB into RAM to not > - * risk to put it outside of lowmem. > + * put oftree/initrd close behind compressed kernel image to avoid > + * placing it outside of the kernels lowmem. > */ > - if (mem_size > SZ_256M) > - mem_free = mem_start + SZ_128M; > - else > - mem_free = PAGE_ALIGN(data->os_res->end + SZ_1M); > + mem_free = PAGE_ALIGN(data->os_res->end + SZ_1M); > > return __do_bootm_linux(data, mem_free, 0); > } > > System Info: iMX6S; 512MB RAM; LoadAddress 0x10008000; Barebox v2015.06.0 I assume what happens here is that due to 0839e3f40 barebox places the device tree close behind the kernel image, the kernel then copies itself out of the way so it won't overwrite itself while uncompressing, then it uncompresses itself back to 0x10008000 and overwrites the device tree. This behaviour is broken and should be fixed. However, 0x10008000 is a poor choice for the load address. It's exactly the place where the decompressor has to put the image to after decompressing, so this address forces the decompressor to move the compressed kernel somewhere else before decompressing it. You could specify the load address to 0x. This allows barebox to pick a good place for the kernel image. A bonus is a slightly faster kernel startup because barebox will pick a place that does not force the decompressor to move the kernel image. We should probably finally fix the kernel decompressor so that it won't overwrite the device tree. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
bootm: booting of uncompressed uimages broken
Hi, booting of uncompressed uimages is broken since patch "ARM: bootm: fix default uImage placement" (0839e3f402ffc74202a1ca4fbeaffcadb4336ce1): This is the change causing the issue: @@ -138,13 +144,10 @@ static int do_bootm_linux(struct image_data *data) return ret; /* - * Put devicetree/initrd at maximum to 128MiB into RAM to not - * risk to put it outside of lowmem. + * put oftree/initrd close behind compressed kernel image to avoid + * placing it outside of the kernels lowmem. */ - if (mem_size > SZ_256M) - mem_free = mem_start + SZ_128M; - else - mem_free = PAGE_ALIGN(data->os_res->end + SZ_1M); + mem_free = PAGE_ALIGN(data->os_res->end + SZ_1M); return __do_bootm_linux(data, mem_free, 0); } System Info: iMX6S; 512MB RAM; LoadAddress 0x10008000; Barebox v2015.06.0 Best Regards Hubert ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Help configuring i.MX6 IPUv3 with a parrallel display
On Mon, Feb 22, 2016 at 05:41:01PM +0100, Philippe Leduc wrote:
> Hello,
>
> I would like to use the barebox framebuffer on a iMX6S chip. My goal
> is to display a splashscreen. However, I can't manage to use the
> framebuffer for now...
>
> Here is the output of "devinfo fb0":
> Resources:
> num: 0
> start: 0x
> size: 0x
> Available modes:
> Parameters:
> enable: 0
> mode_name: invalid:0
> shadowfb: 1
>
> Is this a correct behavior that there is NO availables modes? I do not
> manage to add one through the DTS.
>
> If I try to enable the framebuffer (fb0.enable=1), barebox hangs:
> fb0.enable=1
> unable to handle NULL pointer dereference at address 0x001d
> pc : [<2ff1ab1c>]lr : [<2ff17f41>]
> sp : 2a3c ip : 2ff1a3fa fp : 2a78
> r10: 20212d0c r9 : r8 :
> r7 : 20024210 r6 : f57f r5 : 0c00 r4 : 001d
> r3 : 2ff1a1e5 r2 : 0c00 r1 : 005c r0 : 0022
> Flags: nzcv IRQs off FIQs off Mode SVC_32
> [<2ff1ab1c>] (clk_is_enabled+0x34/0x38) from [<7f8d1fc0>] (0x7f8d1fc0)
>
> [<2ff389d9>] (unwind_backtrace+0x1/0x58) from [<2ff00d19>] (panic+0x1d/0x34)
> [<2ff00d19>] (panic+0x1d/0x34) from [<2ff38e7d>] (do_exception+0xd/0x10)
> [<2ff38e7d>] (do_exception+0xd/0x10) from [<2ff38edd>]
> (do_data_abort+0x21/0x2c)
> [<2ff38edd>] (do_data_abort+0x21/0x2c) from [<2ff38bd4>]
> (do_abort_6+0x48/0x54)
> Switch to console [serial0]
>
> Here is what I put in the DTS to enable the display:
>
> display0: display@di0 {
> compatible = "fsl,imx-parallel-display";
> // crtcs = <&ipu1 0>;
> interface-pix-fmt = "rgb24";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_ipu_disp>;
> status = "okay";
>
> display-timings {
> rk043fn07h {
> native-mode;
> clock-frequency = <900 1500>;
> hactive = <480>;
> vactive = <272>;
> hfront-porch = <2 2 82>;
> hback-porch = <2 2 41>;
> hsync-len = <2 41 41>;
> vback-porch = <1 2 11>;
> vfront-porch = <1 2 227>;
> vsync-len = <1 10 11>;
> pixelclk-active = <1>;
> hsync-active = <0>;
> vsync-active = <0>;
> de-active = <1>;
> };
> };
>
> port {
> display0_in: endpoint {
> remote-endpoint = <&ipu1_di0_disp0>;
> };
> };
>
>
> &ipu1_di0_disp0 {
> remote-endpoint = <&display0_in>;
> };
Parallel display support for IPUv3 is not yet implemented. What's
missing is a driver that matches to "fsl,imx-parallel-display", calls
vpl_register on its own node and returns the display timings parsed from
device tree in the VPL_GET_VIDEOMODES callback.
You could try the following binding instead. It doesn't use the
"fsl,imx-parallel-display" compatible but the "simple-panel" binding
instead. Since IPU parallel display support is a no-op anyway this
should work. Note that this binding is not compatible with the kernel
since the maintainer refuses to let display timings into the device tree
for simple panels.
panel {
compatible = "simple-panel";
display-timings {
/* your timings here */
};
port {
display0_in: enpoint {
remote-endpoint = <&ipu1_di0_disp0>;
};
};
};
&ipu1_di0_disp0 {
interface-pix-fmt = "rgb24";
remote-endpoint = <&display0_in>;
};
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: bootm crash - bad uimage?
Hi Philippe, On Mon, Feb 22, 2016 at 04:31:18PM +0100, Philippe Leduc wrote: > Hello, > > Since the commit 0a37e22d638acf1b2c7c6e6ab83b6a3272b0a11c, I can't > boot my image anymore. > It seems that os_part is a null pointer and simple_strtoul crash on it > (in bootm_load_os). I workaround the problem by forcing the value to 0 > if os_part if null, but I guess that it is a bad solution. > Is this a due to a bad usage of the mkimage utility? Probably not. Is this fixed by this commit? commit 1a180cd3b6e5c067c68f3e09f7e15e5b18af9761 Author: Lucas Stach Date: Fri Feb 12 17:58:23 2016 +0100 bootm: parse initrd and oftree into correct struct members The code parsing the oftree and initrd file names is clearly wrong, leading to bootm not loading oftree or initrd files any more. Signed-off-by: Lucas Stach Signed-off-by: Sascha Hauer -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/3] EP93xx eth: allow passing of phy config via platform data
On Sun, Feb 21, 2016 at 07:06:28PM +0100, Alexander Kurz wrote: > Passing phy configuration to the ep93xx_eth driver was not supported yet > and will be added with this patch. When no pdata is passed, the probably > broken default of phy_addr = 0 will be used to maintain compatibility > with the previous implementation. > > Signed-off-by: Alexander Kurz > --- > drivers/net/ep93xx.c | 14 -- > drivers/net/ep93xx.h | 2 ++ > 2 files changed, 14 insertions(+), 2 deletions(-) Applied all, thanks. I wouldn't have thought EP93xx is still actively used :) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
