[PATCH] ARM: cache-armv7: remove superfluous instruction

2019-10-08 Thread Ahmad Fatoum
There are two tst r11, #0xf with nothing in between them that changes
r11. This a left over from the kernel code that checks for VMSA twice,
once to check if the page table should be setup and once to more to
flush the TLB. We do the setup in the caller already, so the tst serves
no useful purpose. Delete one.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/cpu/cache-armv7.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/cpu/cache-armv7.S b/arch/arm/cpu/cache-armv7.S
index 6a8aff8bb12c..43ec9021330e 100644
--- a/arch/arm/cpu/cache-armv7.S
+++ b/arch/arm/cpu/cache-armv7.S
@@ -7,7 +7,6 @@ ENTRY(v7_mmu_cache_on)
mov r12, lr
 #ifdef CONFIG_MMU
mrc p15, 0, r11, c0, c1, 4  @ read ID_MMFR0
-   tst r11, #0xf   @ VMSA
mov r0, #0
dsb @ drain write buffer
tst r11, #0xf   @ VMSA
-- 
2.23.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH] ARM: mmu: remove no longer accurate comment

2019-10-08 Thread Ahmad Fatoum
This comment refers to the state of things prior to e3e54c644
("ARM: mmu: Implement on-demand PTE allocation"). Since then, we no
longer generate 2nd level page tables directly below. Remove it
to avoid confusion.

Cc: Lucas Stach 
Signed-off-by: Ahmad Fatoum 
---
 arch/arm/cpu/mmu.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c
index 2c5c4b574928..158b130b5765 100644
--- a/arch/arm/cpu/mmu.c
+++ b/arch/arm/cpu/mmu.c
@@ -461,11 +461,6 @@ void __mmu_init(bool mmu_on)
 
vectors_init();
 
-   /*
-* First remap sdram cached using sections.
-* This is to speed up the generation of 2nd level page tables
-* below
-*/
for_each_memory_bank(bank) {
create_sections(ttb, bank->start, bank->start + bank->size - 1,
PMD_SECT_DEF_CACHED);
-- 
2.23.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH 2/2] ARM: dts: imx6qdl: pfla02: Remove fec phy-supply

2019-10-08 Thread Stefan Riedmueller
There is no driver for the phyFLEX-i.MX 6 phy-supply regulator in
the barebox. Use a dummy regulator instead by simply deleting the
phy-supply property.

Signed-off-by: Stefan Riedmueller 
---
 arch/arm/dts/imx6qdl-phytec-pfla02.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi 
b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
index f0bba2e09881..846ebbe6b18b 100644
--- a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
@@ -86,6 +86,10 @@
};
 };
 
+&fec {
+   /delete-property/ phy-supply;
+};
+
 &gpmi {
partitions {
compatible = "fixed-partitions";
-- 
2.7.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH 1/2] net: fec_imx: Fix resource rollback with regulator errors

2019-10-08 Thread Stefan Riedmueller
When the driver is not able to get or control the phy regulator memory
resources are already acquired and need to be released during rollback.

Signed-off-by: Stefan Riedmueller 
---
 drivers/net/fec_imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fec_imx.c b/drivers/net/fec_imx.c
index 31c91021893a..5ef1d4359e91 100644
--- a/drivers/net/fec_imx.c
+++ b/drivers/net/fec_imx.c
@@ -781,7 +781,8 @@ static int fec_probe(struct device_d *dev)
if (IS_ERR(fec->reg_phy)) {
if (PTR_ERR(fec->reg_phy) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
-   goto disable_clk;
+   fec->reg_phy = NULL;
+   goto release_res;
}
fec->reg_phy = NULL;
}
@@ -789,7 +790,7 @@ static int fec_probe(struct device_d *dev)
ret = regulator_enable(fec->reg_phy);
if (ret) {
dev_err(dev, "Failed to enable phy regulator: %d\n", ret);
-   goto disable_clk;
+   goto release_res;
}
 
phy_reset = of_get_named_gpio(dev->device_node, "phy-reset-gpios", 0);
-- 
2.7.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


Re: [PATCH] version_string: Add toolchain and build host info

2019-10-08 Thread Antony Pavlov
On Mon, 7 Oct 2019 22:14:41 -0700
Andrey Smirnov  wrote:

> On Mon, Sep 30, 2019 at 11:03 PM Antony Pavlov  
> wrote:
> >
> > On Mon, 30 Sep 2019 17:57:18 -0700
> > Andrey Smirnov  wrote:
> >
> > Hi!
> >
> > > Linux kernel reports the version of toolchain it was built with as a
> > > part of its version string, which can be extremely useful when
> > > debugging toolchain related issues. Make Barebox version string, mimic
> > > that of Linux to get the same level of information in Barebox.
> > >
> > > Signed-off-by: Andrey Smirnov 
> > > ---
> > >  common/version.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/common/version.c b/common/version.c
> > > index 8b1fd4dbe7..5f57022dac 100644
> > > --- a/common/version.c
> > > +++ b/common/version.c
> > > @@ -3,7 +3,8 @@
> > >  #include 
> > >
> > >  const char version_string[] =
> > > - "barebox " UTS_RELEASE " " UTS_VERSION "\n";
> > > + "barebox " UTS_RELEASE " (" BAREBOX_COMPILE_BY "@"
> > > + BAREBOX_COMPILE_HOST ") (" BAREBOX_COMPILER ") " UTS_VERSION "\n";
> > >  EXPORT_SYMBOL(version_string);
> >
> >
> > Can we keep COMPILE_BY and COMPILE_HOST in one line (as linux does)?
> 
> I don't understand. This line already follows formatting found in
> Linux, e. g. 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/init/version.c?h=v5.4-rc2#n46
> 
> I have no preference how this is going to be formatted, really. Can
> you just take this patch reformat it the way you want to see it and
> submit it?

Sorry!
I have made local patch several months ago. I have used it for debug purposes
only because the resulting version string is very long and looks ugly
on start.

It looks like I have used linux **proc_banner** as a reference for my patch.
Please ignore my previous message.

@Sascha
I think that long version string with all these *_COMPILE_BY and *_COMPILER
can be very handy. On the other hand this information is not very interesting 
for
most users.
Can we put all these *_COMPILE_BY and *_COMPILER into some "global" variables?

-- 
Best regards,
  Antony Pavlov

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox