Re: fix for lantiq (danube) usb
El 5/7/20 a les 22:37, Martin Blumenstingl ha escrit: Hi Luca, On Sun, Jul 5, 2020 at 3:07 PM Luca Olivetti wrote: El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit: I'm recompiling again in case I misplaced the section in my previous test. In ~30-40 minutes it should be ready and I'll report back. Success! I probably did something wrong before. I'm attaching the patch against 19.07.3 and my device, but I think the same should be done for trunk and other devices with a similar dts. please let me know if I should be sending the patch for master (previously known as "trunk"). I have no way of testing it, but with your test results I'm confident that it'll work Well, yes, I think so. Even if the usb still has issues, at least it initializes and somewhat works. If you look at the "related tasks" in bug https://bugs.openwrt.org/index.php?do=details&task_id=1634 you'll see that it also affects the arv752dpw and ar9 (and most probably all other boards where the regulator is misplaced), I'm confident the fix is the same, though I have no way of testing it. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi Daniel On 7/6/20 1:03 AM, Daniel Golle wrote: > Hi David, > > On Mon, Jul 06, 2020 at 12:37:06AM +0200, David Bauer wrote: >> Hi Daniel, >> >> On 7/5/20 10:50 PM, Daniel Golle wrote: >>> I suggest to completely remove KERNEL_TESTING_PATCHVER instead of >>> setting it to the same version as KERNEL_PATCHVER. >> >> As most targets have it included, I've decided to specifically keep it. > > Setting KERNEL_TESTING_PATCHVER enables the option in menuconfig to > build with testing kernel. If set to the same version as > KERNEL_PATCHVER, this is misleading as despite suggesting the use of a > newer/testing version, obviously the exact same kernel version will be > built. Good to know. I was under the impression I've tested this and the menu option was still visible when KERNEL_TESTING_PATCHVER was not present. Most likely i fucked up while testing this. > You are right in that keeping it became the pattern once > KERNEL_PATCHVER was bumped to the same level as > KERNEL_TESTING_PATCHVER. I assume this was not deliberate (please > scream now if it was!) we should also remove it from all other targets > with KERNEL_PATCHVER == KERNEL_TESTING_PATCHVER. I agree here. Best wishes David > > Anyone? > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi David, On Mon, Jul 06, 2020 at 12:37:06AM +0200, David Bauer wrote: > Hi Daniel, > > On 7/5/20 10:50 PM, Daniel Golle wrote: > > I suggest to completely remove KERNEL_TESTING_PATCHVER instead of > > setting it to the same version as KERNEL_PATCHVER. > > As most targets have it included, I've decided to specifically keep it. Setting KERNEL_TESTING_PATCHVER enables the option in menuconfig to build with testing kernel. If set to the same version as KERNEL_PATCHVER, this is misleading as despite suggesting the use of a newer/testing version, obviously the exact same kernel version will be built. You are right in that keeping it became the pattern once KERNEL_PATCHVER was bumped to the same level as KERNEL_TESTING_PATCHVER. I assume this was not deliberate (please scream now if it was!) we should also remove it from all other targets with KERNEL_PATCHVER == KERNEL_TESTING_PATCHVER. Anyone? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi Daniel, On 7/5/20 10:50 PM, Daniel Golle wrote: > I suggest to completely remove KERNEL_TESTING_PATCHVER instead of > setting it to the same version as KERNEL_PATCHVER. As most targets have it included, I've decided to specifically keep it. Best wishes David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi On 2020-07-05, David Bauer wrote: > Hi all, > > On 4/2/20 9:53 PM, David Bauer wrote: > > As the reported major bugs are ironed out, switch to the new kernel to > > begin testing with a broader audience. > > As the DSP exception is now sorted out we should be good to go here. > > Any objections on applying this patch left? It's now working fine on my devices (not tested the tl-wr941nd v2 though, which has/ had(?) problems with NET_DSA_MV88E6060 in v4.19, FS#2524): Runtime tested with kernel v5.4.50 on: - TP-Link TL-WR1043NDv1/ AR9103 - Buffalo WZR-HP-AG300H/ AR7161 - TP-Link TL-WDR3600/ AR9344 - TP-Link TL-WDR4300/ AR9344 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] 54d354: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 54d3549f06ce656fd78cd5c229f8bf17956a815e https://github.com/sdwalker/sdwalker.github.io/commit/54d3549f06ce656fd78cd5c229f8bf17956a815e Author: Stephen Walker Date: 2020-07-05 (Sun, 05 Jul 2020) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
On 05.07.20 14:24, David Bauer wrote: Hi all, On 4/2/20 9:53 PM, David Bauer wrote: As the reported major bugs are ironed out, switch to the new kernel to begin testing with a broader audience. As the DSP exception is now sorted out we should be good to go here. Any objections on applying this patch left? Best wishes David works for me on the 5 units I tested today. John Signed-off-by: David Bauer --- target/linux/ath79/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile index 9b203cf48e..a955602ba9 100644 --- a/target/linux/ath79/Makefile +++ b/target/linux/ath79/Makefile @@ -8,7 +8,7 @@ SUBTARGETS:=generic mikrotik nand tiny FEATURES:=ramdisk -KERNEL_PATCHVER:=4.19 +KERNEL_PATCHVER:=5.4 KERNEL_TESTING_PATCHVER:=5.4 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
On Sun, Jul 05, 2020 at 02:24:18PM +0200, David Bauer wrote: > Hi all, > > On 4/2/20 9:53 PM, David Bauer wrote: > > As the reported major bugs are ironed out, switch to the new kernel to > > begin testing with a broader audience. > > As the DSP exception is now sorted out we should be good to go here. > > Any objections on applying this patch left? > > Best wishes > David > > > > > Signed-off-by: David Bauer > > --- > > target/linux/ath79/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile > > index 9b203cf48e..a955602ba9 100644 > > --- a/target/linux/ath79/Makefile > > +++ b/target/linux/ath79/Makefile > > @@ -8,7 +8,7 @@ SUBTARGETS:=generic mikrotik nand tiny > > FEATURES:=ramdisk > > -KERNEL_PATCHVER:=4.19 > > +KERNEL_PATCHVER:=5.4 > > KERNEL_TESTING_PATCHVER:=5.4 I suggest to completely remove KERNEL_TESTING_PATCHVER instead of setting it to the same version as KERNEL_PATCHVER. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Luca, On Sun, Jul 5, 2020 at 3:07 PM Luca Olivetti wrote: > > El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit: > > > I'm recompiling again in case I misplaced the section in my previous > > test. In ~30-40 minutes it should be ready and I'll report back. > > Success! > I probably did something wrong before. > I'm attaching the patch against 19.07.3 and my device, but I think the > same should be done for trunk and other devices with a similar dts. please let me know if I should be sending the patch for master (previously known as "trunk"). I have no way of testing it, but with your test results I'm confident that it'll work Best regards, Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 15:14, Luca Olivetti ha escrit: but I'm happy enough that this is fixed now. Any chance of having a working rtl8812au driver? ;-) Well, not even the rt73 one works fine: I configured it as an AP, I can connect just fine but then, when I try to push some data (connecting to fast.com[*]) it hangs the router and it reboots after a few seconds. I don't think the cause is the rt73 driver (it's been quite stable on linux forever) but the dwc2 driver on this board. Just a guess though. [*] I'm currently using the router as a repeater with the single radio configured both as a wds client and as an AP, I wanted to see if using another radio would improve the performance. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
On 7/5/20 2:24 PM, David Bauer wrote: > Hi all, > > On 4/2/20 9:53 PM, David Bauer wrote: >> As the reported major bugs are ironed out, switch to the new kernel to >> begin testing with a broader audience. > > As the DSP exception is now sorted out we should be good to go here. > > Any objections on applying this patch left? > > Best wishes > David > >> >> Signed-off-by: David Bauer Acked-by: Hauke Mehrtens >> --- >> target/linux/ath79/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile >> index 9b203cf48e..a955602ba9 100644 >> --- a/target/linux/ath79/Makefile >> +++ b/target/linux/ath79/Makefile >> @@ -8,7 +8,7 @@ SUBTARGETS:=generic mikrotik nand tiny >> FEATURES:=ramdisk >> -KERNEL_PATCHVER:=4.19 >> +KERNEL_PATCHVER:=5.4 >> KERNEL_TESTING_PATCHVER:=5.4 >> include $(INCLUDE_DIR)/target.mk >> > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 15:07, Luca Olivetti ha escrit:
El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit:
I'm recompiling again in case I misplaced the section in my previous
test. In ~30-40 minutes it should be ready and I'll report back.
Success!
I probably did something wrong before.
I'm attaching the patch against 19.07.3 and my device, but I think the
same should be done for trunk and other devices with a similar dts.
Now it would be nice to also remove these harmless warnings ("supply
vusb_[da] not found" and "Mode Mismatch Interrupt"):
# dmesg | grep dwc2
[5.769881] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found,
using dummy regulator
[5.776840] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found,
using dummy regulator
[5.784970] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset
GRSTCTL=8001
[5.930874] dwc2 1e101000.usb: DWC OTG Controller
[5.934191] dwc2 1e101000.usb: new USB bus registered, assigned bus
number 1
[5.941041] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[ 239.438602] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.444386] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.638464] usb 1-1: new high-speed USB device number 2 using dwc2
[ 239.643522] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.650233] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
but I'm happy enough that this is fixed now.
Any chance of having a working rtl8812au driver? ;-)
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit:
I'm recompiling again in case I misplaced the section in my previous
test. In ~30-40 minutes it should be ready and I'll report back.
Success!
I probably did something wrong before.
I'm attaching the patch against 19.07.3 and my device, but I think the
same should be done for trunk and other devices with a similar dts.
Signed-off-by: Luca Olivetti
Bye
--
Luca
diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
index 72f3a686b5..62b67d40eb 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
@@ -106,6 +106,18 @@
gpios = <&gpiomm 6 GPIO_ACTIVE_LOW>;
};
};
+
+ usb_vbus: regulator-usb-vbus {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB_VBUS";
+
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+
+ gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&gpio {
@@ -146,18 +158,6 @@
lantiq,open-drain = <1>;
};
};
-
- usb_vbus: regulator-usb-vbus {
- compatible = "regulator-fixed";
-
- regulator-name = "USB_VBUS";
-
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
};
&gpiomm {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi all, On 4/2/20 9:53 PM, David Bauer wrote: As the reported major bugs are ironed out, switch to the new kernel to begin testing with a broader audience. As the DSP exception is now sorted out we should be good to go here. Any objections on applying this patch left? Best wishes David Signed-off-by: David Bauer --- target/linux/ath79/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile index 9b203cf48e..a955602ba9 100644 --- a/target/linux/ath79/Makefile +++ b/target/linux/ath79/Makefile @@ -8,7 +8,7 @@ SUBTARGETS:=generic mikrotik nand tiny FEATURES:=ramdisk -KERNEL_PATCHVER:=4.19 +KERNEL_PATCHVER:=5.4 KERNEL_TESTING_PATCHVER:=5.4 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:53, Martin Blumenstingl ha escrit: have you tried moving it out of the &gpio node (and placing it similar to what for example target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts in master uses)? Yes, no change no change means the regulator-fixed driver is still not probed? Yes, it's not probed/available it's working fine for me on my BT Home Hub 5A, so I'm surprised to find that it's not working for you. Here's what I'm seeing: # find /proc/device-tree/ -name "regulator-usb-vbus" /proc/device-tree/regulator-usb-vbus # grep "regulator-usb-vbus" /sys/kernel/debug/gpio gpio-495 (|regulator-usb-vbus ) out hi I'm recompiling again in case I misplaced the section in my previous test. In ~30-40 minutes it should be ready and I'll report back. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Luca,
On Sun, Jul 5, 2020 at 1:42 PM Luca Olivetti wrote:
>
> El 5/7/20 a les 13:29, Martin Blumenstingl ha escrit:
> > Hi Luca,
> >
> > On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti wrote:
> > [...]
> >> I put a printk in every step of reg_fixed_regulator_probe
> >> (drivers/regulator/fixed.c) and it seems it isn't called at all (my
> >> strings are indeed compiled in fixed.o).
> >>
> >> Why is that? Perhaps an error in the dts?
> > unfortunately you have only given an extract of your changes instead
> > of the full patch, which means I don't have much context and have to
> > guess
>
> No, now I was talking about the original dts.
ah, now I understand
> >
> >> I checked and it seems the same as other devices in 19.07.3, the only
> >> difference is the section (most devices have it in the first section
> >> while here it is in the &gpio section) and the name after the colon
> >> (most use no name at all after the colon or the same as before, i.e.
> >> here it would be usb_vbus: usb_vbus ).
> >>
> >> This is the definition in the dts
> >>
> >>
> >> usb_vbus: regulator-usb-vbus {
> >> compatible = "regulator-fixed";
> >>
> >> regulator-name = "USB_VBUS";
> >>
> >> regulator-min-microvolt = <500>;
> >> regulator-max-microvolt = <500>;
> >>
> >> gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
> >> enable-active-high;
> >> };
> > assuming that board uses GPIO 14 with polarity "active high" this part
> > seems correct to me
> >
> > have you tried moving it out of the &gpio node (and placing it similar
> > to what for example
> > target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
> > in master uses)?
>
> Yes, no change
no change means the regulator-fixed driver is still not probed?
it's working fine for me on my BT Home Hub 5A, so I'm surprised to
find that it's not working for you.
Here's what I'm seeing:
# find /proc/device-tree/ -name "regulator-usb-vbus"
/proc/device-tree/regulator-usb-vbus
# grep "regulator-usb-vbus" /sys/kernel/debug/gpio
gpio-495 (|regulator-usb-vbus ) out hi
Best regards,
Martin
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:29, Martin Blumenstingl ha escrit:
Hi Luca,
On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti wrote:
[...]
I put a printk in every step of reg_fixed_regulator_probe
(drivers/regulator/fixed.c) and it seems it isn't called at all (my
strings are indeed compiled in fixed.o).
Why is that? Perhaps an error in the dts?
unfortunately you have only given an extract of your changes instead
of the full patch, which means I don't have much context and have to
guess
No, now I was talking about the original dts.
I checked and it seems the same as other devices in 19.07.3, the only
difference is the section (most devices have it in the first section
while here it is in the &gpio section) and the name after the colon
(most use no name at all after the colon or the same as before, i.e.
here it would be usb_vbus: usb_vbus ).
This is the definition in the dts
usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "USB_VBUS";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
assuming that board uses GPIO 14 with polarity "active high" this part
seems correct to me
have you tried moving it out of the &gpio node (and placing it similar
to what for example
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
in master uses)?
Yes, no change
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Luca,
On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti wrote:
[...]
> I put a printk in every step of reg_fixed_regulator_probe
> (drivers/regulator/fixed.c) and it seems it isn't called at all (my
> strings are indeed compiled in fixed.o).
>
> Why is that? Perhaps an error in the dts?
unfortunately you have only given an extract of your changes instead
of the full patch, which means I don't have much context and have to
guess
> I checked and it seems the same as other devices in 19.07.3, the only
> difference is the section (most devices have it in the first section
> while here it is in the &gpio section) and the name after the colon
> (most use no name at all after the colon or the same as before, i.e.
> here it would be usb_vbus: usb_vbus ).
>
> This is the definition in the dts
>
>
> usb_vbus: regulator-usb-vbus {
> compatible = "regulator-fixed";
>
> regulator-name = "USB_VBUS";
>
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
>
> gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
assuming that board uses GPIO 14 with polarity "active high" this part
seems correct to me
have you tried moving it out of the &gpio node (and placing it similar
to what for example
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
in master uses)?
background info: device-tree nodes can not be placed in random
locations within the .dts. all nodes below top-level (where the model
property is defined for example) are supported. for all other nodes it
depends on the (driver) implementation: all nodes with compatible =
"simple-bus" are also scanned for child-nodes. However, any node
placed for example below the &usb_phy node (I didn't check the &gpio
implementation to see if it's the same) will NOT be scanned (because
the driver doesn't support that).
in case moving the &usb_vbus node fixes it we probably have to fix
three more boards as the following four all place &usb_vbus inside
&gpio (on master, only looking at Linux 5.4):
- target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/ar9_zyxel_p-2601hn.dts
-
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv752dpw.dts
-
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv7510pw22.dts
-
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/danube_arcadyan_arv7518pw.dts
> Oh, and is there a quick way to test modifications to the dts? Every
> time I invoke make, even for a trivial change, it takes 40 minutes.
I don't know about this part of the OpenWrt build-system so I'm
passing this questions to somebody else
Best regards,
Martin
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 23:18, Luca Olivetti ha escrit:
El 3/7/20 a les 19:49, John Crispin ha escrit:
On 03.07.20 19:47, Luca Olivetti wrote:
El 3/7/20 a les 19:37, John Crispin ha escrit:
Why not use the gpio regulator ?
Because I don't know how :-(
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
Oh, I see, but that's the one I had to *remove* because it didn't work.
Bye
CONFIG_REGULATOR_GPIO is not enabled in the kernel config
I think the correct one is CONFIG_REGULATOR_FIXED_VOLTAGE, which was
already in the configuration, hence adding CONFIG_REGULATOR_GPIO has no
effect.
I put a printk in every step of reg_fixed_regulator_probe
(drivers/regulator/fixed.c) and it seems it isn't called at all (my
strings are indeed compiled in fixed.o).
Why is that? Perhaps an error in the dts?
I checked and it seems the same as other devices in 19.07.3, the only
difference is the section (most devices have it in the first section
while here it is in the &gpio section) and the name after the colon
(most use no name at all after the colon or the same as before, i.e.
here it would be usb_vbus: usb_vbus ).
This is the definition in the dts
usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "USB_VBUS";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = <&gpio 14 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
Oh, and is there a quick way to test modifications to the dts? Every
time I invoke make, even for a trivial change, it takes 40 minutes.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
build problems in layerscape target kernel
Hi Yangbo Lu, I see some build problem with the layerscape target in the OpenWrt build bots recently. Since the update to kernel 5.4.50 the scripts/headers_install.sh script complains that include/linux/fmd/Peripherals/fm_port_ioctls.h includes CONFIG_COMPAT. This is a problem when some user space application includes this file, because user space applications do not know of the kernel configuration and normally none of these CONFIG_ symbols is set. This happens when changing the Linux kernel from version 45.4.48 to 5.4.49, but I do not know why this change is triggering this error and why it did not happen before. This is the error message: HDRINST usr/include/linux/fmd/integrations/integration_ioctls.h HDRINST usr/include/linux/fmd/Peripherals/fm_port_ioctls.h error: include/uapi/linux/fmd/Peripherals/fm_port_ioctls.h: leak CONFIG_COMPAT to user-space scripts/Makefile.headersinst:63: recipe for target 'usr/include/linux/fmd/Peripherals/fm_port_ioctls.h' failed make[5]: *** [usr/include/linux/fmd/Peripherals/fm_port_ioctls.h] Error 1 Makefile:1198: recipe for target 'headers' failed make[4]: *** [headers] Error 2 https://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/349 It is happening since: https://git.openwrt.org/68d9cb82143b864d70e4fb3d7cbb7068f82216a1 -- Before we saw this problem the layerscape target in the linking of the kernel image. It shows this error message. LD vmlinux SORTEX vmlinux SYSMAP System.map Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround Makefile:1081: recipe for target 'vmlinux' failed make[4]: *** [vmlinux] Error 1 This is happening since this build bot run, the changes since the previous build are listed in the log: https://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/422 I haven't looked closer into this problem. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
