The chip installed in my device is mx25l25635e. But it shouldn't matter.
пт, 9 июл. 2021 г. в 13:33, Dmitry Tunin :
>
> The mx25l25635e supports clock speed up to 50Mhz.
>
> Also remove obsolete "mx25l25635f" hack.
>
> Signed-off-by: Dmitry Tunin
> ---
> .
The mx25l25635e supports clock speed up to 50Mhz.
Also remove obsolete "mx25l25635f" hack.
Signed-off-by: Dmitry Tunin
---
.../files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts| 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/target/linux/ipq40xx/file
Also remove obsolete "mx25l25635f" hack.
Signed-off-by: Dmitry Tunin
---
.../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
b/ta
This means a sysupgrade with resetting all configs, nothing else.
sysupgrade -n
пт, 10 янв. 2020 г. в 12:50, Pumr, Ondrej (EEK) :
>
> Hello,
>
>
>
> I have TP-LINK TL-WR842N-V3 running OpenWrt 18.06 with ar71xx and I want to
> migrate to OpenWrt 19.07 with ath79.
>
>
>
> In the list of known is
вт, 7 янв. 2020 г. в 02:16, :
>
> make clean? (would be no. 6 now :-) )
My apologies. We are in the middle of Christmas holidays here :-))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-
Nice release tag )) Ever tried a build test before the tag?
Tried to build
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for base-files:
* libubox20170601
* opkg_install_cmd: Cannot install package base-files.
* satisfy_dependencies_for: Cannot satisf
I am strongly against this change for a simple reason. Advantage of
this change is questionable, but we can get all sorts of trouble.
сб, 16 нояб. 2019 г. в 18:31, Piotr Dymacz :
>
> Hi Adrian,
>
> On 08.11.2019 12:48, Adrian Schmutzler wrote:
> > This patchset will introduce the label MAC address
Is one wireless adapter connected using PCIE? If it is true, you'll
have to set it's node in DTS.
Generally it's not required, but if you need a gpio controller, then
you have to.
ср, 30 окт. 2019 г. в 17:51, Dmitry Tunin :
>
> ср, 30 окт. 2019 г. в 17:31, Adrian Sc
ср, 30 окт. 2019 г. в 17:31, Adrian Schmutzler :
>
> Hi,
>
> we are still working on broken WiFi on CPE210v2/v3 (ath79, QCA9533 rev. 2)
> and have found that on ath79 a GPIO is missing compared to ar71xx (where WIFI
> is working):
>
> GPIO Config on the ar71xx:
>
> gpiochip0: GPIOs 0-31, parent:
It seems that it is not quite proper fix.
Yesterday I flashed a Linksys EA6450v3 with 19.07 build. I couldn't
connect to the device using a 100 Mbit laptop.
I had to use another laptop with a 1000 Mbit port to reach the device.
It seems that after the patch we avoided a lock on 1000 Mbit but got
Hi David,
> On the other hand there's ipqess and qca8k on the horizon to end the ar40xx
> mess.
> But i don't think this is a showstopper for this.
That stopped me from doing this fast. ipqess will solve it anyway.
Maybe it is not worth the effort now. I don't see a straightforward
simple solutio
> Are you just talking about asus/zyxel case or should I remove the entire
> patch (-> mark as deferred)?
I mean all ipq40xx devices with two MACs. I mentioned the two I have.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.
пн, 23 сент. 2019 г. в 16:34, Adrian Schmutzler :
>
> If already included in ucidef_add_switch, you do not have to
> additionally set the interface mode in ucidef_set_interfaces_*
> functions.
>
> This patch removes/adjusts such redundant cases.
>
> Signed-off-by: Adrian Schmutzler
>
> ---
>
> Thi
Thx. It is fixed now
сб, 14 сент. 2019 г. в 18:36, Koen Vandeputte :
>
>
> On 14-09-19 12:47, Magnus Kroken wrote:
> > Hi Andre
> >
> > On 14.09.2019 10:49, Andre Valentin wrote:
> >> It seems the kernel bump broke ath79 compilation. The problem lies in
> >> target/linux/ath79/patches-4.19/0028-MI
Magnus,
You are 100% correct. Fix potentially missed IRQ handling during
dispatch has an error. It should be applied only to ar71xx platform.
It should be fixed on both master and 19.07 branches.
сб, 14 сент. 2019 г. в 14:15, Dmitry Tunin :
>
> сб, 14 сент. 2019 г. в 14:12, Dmitry
сб, 14 сент. 2019 г. в 14:12, Dmitry Tunin :
>
> > 2. It modifies arch/mips/ath79/irq.c. The patch that fails on ath79,
> > 0027-MIPS-ath79-drop-legacy-IRQ-code, deletes this file completely
> > (which now fails, as the file content is changed by
> > 343-MIPS-ath79
> 2. It modifies arch/mips/ath79/irq.c. The patch that fails on ath79,
> 0027-MIPS-ath79-drop-legacy-IRQ-code, deletes this file completely
> (which now fails, as the file content is changed by
> 343-MIPS-ath79-Fix-potentially-missed-IRQ-handling-durin.patch).
I refreshed 0027-MIPS-ath79-drop-lega
Patch target/linux/ath79/patches-4.14/0027-MIPS-ath79-drop-legacy-IRQ-code.patch
doesn't apply
Applying
/home/pilot6/LEDE/openwrt/target/linux/ath79/patches-4.14/0027-MIPS-ath79-drop-legacy-IRQ-code.patch
using plaintext:
patching file arch/mips/ath79/Makefile
patching file arch/mips/ath79/irq.c
Signed-off-by: Dmitry Tunin
---
target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
b/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
index da19921..8e60bb4 100644
--- a
Rich,
OpenWrt is a Linux distro. It has all security as any other one. All
CVE are timely addressed.
There is no need for special tests.
вт, 20 авг. 2019 г. в 18:34, Rich Brown :
>
> Hi Vincent,
>
> I don't know whether the article, or its underlying report from Cyber
> Independent Testing Lab -
> /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
> 4k of calibration data from ART to bin file in /lib/firmware. I
> compared bin file to mtd area and they are identical. Why ath9k cannot
> use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
> option for?
Tested-by: Dmitry Tunin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I know that this is a bit off-topic but can anyone maintaining openwrt
git repo solve the problem with baninng of Digital Ocean servers in
Russia?
git.openwrt.org is not accessible. This is a side effect of the fight
against Telegram, that was los by the government.
It is not a really _big_ problem
As I mentioned before with 'gpio-keys' debounce-interval is not
needed. Default is OK and looks better on ar7161.
Maybe testing on other targets is needed.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/l
> So should it remove the change for ath9k keys and only do the other ones at
> the moment?
That's a good question. I suggest to leave devices that HAVE some keys
attached to ath9k keys using 'gpio-keys-polled'.
It makes no sense to use both drivers.
_
If you will be pushing it some way, remove debounce-interval too.
Without it gpio-keys work better.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> Can I add your Tested-by?
I tested only one target, it makes no sense to add this. And I what
about ath9k keys. They are a problem.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I tested gpio-keys on dir825b1 and didn't see a noticable change
against gpio-keys-polled. Both miss events and work poorly.
So no objections for a switch.
пн, 5 авг. 2019 г. в 19:27, Dmitry Tunin :
>
> > This recent Pull Request used gpio-keys on ar7100:
> > https://github
Add support for the ar71xx supported Netgear WNDR3800CH to ath79.
The device is identical to WNDR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux
Oops again. I didn't pull master for a while, because was playing with 19.07.
ср, 7 авг. 2019 г. в 22:58, Dmitry Tunin :
>
> > Are you using recent master?
> >
> > DEVICE_MODEL is the way to go now.
> Yes, I do.
___
openw
> Are you using recent master?
>
> DEVICE_MODEL is the way to go now.
Yes, I do.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Add support for the ar71xx supported Netgear WNDR3800CH to ath79.
The device is identical to WNDR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux
Add support for the ar71xx supported Netgear WNDR3800CH to ath79.
The device is identical to WNDR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux
With VENDOR/MODEL it doesn't appear in menuconfig.
So v1 with WNDR fix should work.
ср, 7 авг. 2019 г. в 22:11, Dmitry Tunin :
>
> > You still have one WNR in the commit description and you can remove the
> > DEVICE_VENDOR, as it is still inherited.
> It looks like all the
Add support for the ar71xx supported Netgear WNDR3800CH to ath79.
The device is identical to WNDR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux
> You still have one WNR in the commit description and you can remove the
> DEVICE_VENDOR, as it is still inherited.
It looks like all the file should be changed to VENDOR/MODEL, but you
are correct.
___
openwrt-devel mailing list
openwrt-devel@lists.op
> If the CH stands for China, as I've also read when googleing, I would prefer
> having CN here. This will then very much depend upon whether the CH is used
> officially somewhere or whether it's just an invention of previous OpenWrt
> versions ... (Where in the latter case I'd actually change t
Sent v2.
ср, 7 авг. 2019 г. в 21:48, Adrian Schmutzler :
>
> > > Note that you also have to update to DEVICE_VENDOR/DEVICE_MODEL syntax ...
> > I don't quite get it. Where is this syntax?
>
> Here:
>
> > +define Device/netgear_wndr3800ch
> > + $(Device/netgear_wndr3800)
> > + DEVICE_TITLE := NET
Add support for the ar71xx supported Netgear WNR3800CH to ath79.
The device is identical to WNDR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux/ath79
Maybe DEVICE_VARIANT := CH is a better choice, since it is the same device.
ср, 7 авг. 2019 г. в 21:40, Dmitry Tunin :
>
> > in commit title/description, you are using "WNR" instead of "WNDR" ...
> Oops.
>
> > Despite, from a quick research, it looks l
> in commit title/description, you are using "WNR" instead of "WNDR" ...
Oops.
> Despite, from a quick research, it looks like the device is called
> "WNDR3800CH" most frequently.
> I would update the name accordingly.
I copied the ar71xx name, but I agree.
> Note that you also have to update to
Add support for the ar71xx supported Netgear WNR3800 (Ch) to ath79.
The device is identical to WNR3800 except NETGEAR_BOARD_ID.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom | 6 ++--
.../linux
> This recent Pull Request used gpio-keys on ar7100:
> https://github.com/openwrt/openwrt/pull/1359
>
> However, I cannot extract how well this was tested.
I will have a device for testing around the next weekend. I'll report back.
___
openwrt-devel ma
пн, 5 авг. 2019 г. в 16:53, Adrian Schmutzler :
>
> > -Original Message-
> > From: Dmitry Tunin [mailto:hanipouspi...@gmail.com]
> > Sent: Freitag, 2. August 2019 18:51
> > To: Adrian Schmutzler
> > Cc: OpenWrt Development List
> > Subject: Re:
пт, 2 авг. 2019 г. в 17:46, Adrian Schmutzler :
>
> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled.
> The poll-interval is removed.
>
When I ported DIR-825-b1 to ath79 last year, "gpio-keys" where very
unreliable and I had to switch t
> Can you explain why not? I'm not aware about any critical issues on ath79. How
> are we going to prepare ath79 in possibly best shape for the next release, if
> we now provide ath79 images in 19.07? Users would simply stick to stable
> images and snapshots would get less testing.
There are some i
> e) if you want to use ath79, you should use snapshot images (and expect
> support) or
>build 19.07 for ath79 yourself (but don't expect much support)
Are you taking in account that many devices added during the last year
as ath79 won't be supported by a stable release.
Master is no good now
There is also a few devices that have been recently added as ath79
only. So they won't be supported.
пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin :
>
> 2b074654b0f259518aa56e0975ca8e26c0c12bc9
>
> I see no reason why not to build both ar71xx and ath79 for devices
> that have
2b074654b0f259518aa56e0975ca8e26c0c12bc9
I see no reason why not to build both ar71xx and ath79 for devices
that have been ported to ath79 already. Many people already use 19.07
branch and wait for the release.
That will require lots of custom builds. What is the point of excluding ath79?
__
This 19.07 commit didn't update the hash in Makefile. Please fix it.
пн, 8 июл. 2019 г. в 14:38, Eneas Queiroz :
>
> Can someone please cherry-pick this to 19.07:
> 2792daab5a wolfssl: update to 3.15.7, fix Makefile
>
> This includes a fix for a medium-level potential cache attack with a
> variant
You can build with the 4.9 kernel. I think that something like
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3b53d6fdbc241173b4264aa49142ba94d406a806
is needed for your SoC.
сб, 9 мар. 2019 г. в 21:36, Dmitry Tunin :
>
> сб, 9 мар. 2019 г. в 21:17, W. Michael Petullo :
> &
сб, 9 мар. 2019 г. в 21:17, W. Michael Petullo :
>
> >> I have been trying to narrow this down as I find time.
> >>
> >> A stock install of "OpenWrt 18.06.2, r7676-cddd7b4c77" works.
>
> > This doesn't narrow anything down. You need to find a master commit
> > that broke things down.
> > And also r
> I have been trying to narrow this down as I find time.
>
> A stock install of "OpenWrt 18.06.2, r7676-cddd7b4c77" works.
This doesn't narrow anything down. You need to find a master commit
that broke things down.
And also rebuild /etc/config/wireless
вт, 26 февр. 2019 г. в 16:03, Adrian Schmutzler :
>
> > -Original Message-
> > From: Dmitry Tunin [mailto:hanipouspi...@gmail.com]
> > Sent: Dienstag, 26. Februar 2019 10:45
> > To: Adrian Schmutzler
> > Subject: Re: [OpenWrt-Devel] [PATCH] ath79: spe
пн, 25 февр. 2019 г. в 21:20, Christian Lamparter :
> > The only problem here is that not all platforms need it.
> The problem I always have is more along the way that a patch should receive
> some "on-device" testing. So I do look forward for patches that received a
> "Tested-by:" tag or has posi
test it really well on multiple platforms, so I've sent the one
I could.
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> > Behalf Of Dmitry Tunin
> > Sent: Montag, 25. Februar 2019 19:01
> > To: C
es vs
unification.
>
> Best
>
> Adrian
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> > Behalf Of Christian Lamparter
> > Sent: Montag, 25. Februar 2019 18:28
> > To: openwrt-devel@lists.open
пн, 25 февр. 2019 г. в 21:01, Dmitry Tunin :
>
> I suggest Adrian's. I was too lazy to patch them all. Only merging
> this what matters.
>
> пн, 25 февр. 2019 г. в 20:27, Christian Lamparter :
> >
> > Hello,
> >
> > On Friday, February 22, 2019 7:52:37
I suggest Adrian's. I was too lazy to patch them all. Only merging
this what matters.
пн, 25 февр. 2019 г. в 20:27, Christian Lamparter :
>
> Hello,
>
> On Friday, February 22, 2019 7:52:37 PM CET Dmitry Tunin wrote:
> > пт, 22 февр. 2019 г. в 21:48, Adrian Schmutzler
>
пт, 22 февр. 2019 г. в 21:48, Adrian Schmutzler :
>
> Based on the ipq40xx commit from chunkeey, I tried to do the same for
> ar71xx/ath79.
>
I want to add that without this patch firmware extraction is not fast
enough to get it in time after a flash. That's why wireless needs a
restart.
I don't th
пт, 22 февр. 2019 г. в 16:57, Petr Štetiar :
>
> Dmitry Tunin [2019-02-22 16:13:52]:
>
> > What do you mean by "generalize"? Fix it on all platforms, or having
> > common 10-ath9k-eeprom, 11-ath10k-caldata, etc files., or common code
> > that will be use
пт, 22 февр. 2019 г. в 15:53, Petr Štetiar :
>
> Dmitry Tunin [2019-02-22 15:30:39]:
>
> Hi,
>
> > Signed-off-by: Dmitry Tunin
> > ---
> > target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
> > 1 file changed, 1 insertion(+),
sys 0m 0.03s
With this change eeprom extraction is fast enough to get working Wi-Fi after
initial install.
Signed-off-by: Dmitry Tunin
---
target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/target/linux
This is useful for ath9k extraction as well.
пт, 22 февр. 2019 г. в 13:09, Christian Lamparter :
>
> Hello,
>
> On Wednesday, February 20, 2019 7:26:55 PM CET Adrian Schmutzler wrote:
> > just saw the commit “ipq40xx: speed up ath10k-caldata extraction”:
> >
> > https://github.com/openwrt/openwrt/
packages.gz in the repos doesn't contain this package. It can't be
installed by opkg.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> I'm not really sure how to proceed here.
I would suggest to set it as everywhere else as e.g. I did for Tp-Link MR2040.
A user can always change it to netdev if they want it that way.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https
t
tiny un terms of RAM
and that is not very important and can be tuned if we implement "nr-interrupts"
property".
2. It reuses the same irg chip name "MISC" for both controllers.
Run tested on DIR-825 B1.
Signed-off-by: Dmitry Tunin
---
target/linux/ath79/dts/ar7100.dts
I fixed the compatible and tried to improve commit msg.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> A bit off-topic, but what does OF stand for ?
> (that legacy code does not use DT is known).
>
OF stands for Open Firmware.
It doesn't use the DT, but the code is still there in many cases. It
is not cut out by prerocessor in many cases.
___
openwrt-d
> There are other shortcomings along with upgraded kernel e.g. the
> kernel is getting so big that we may not be able to use 4M flash with
> even just basic functions of a router in a near future.
> (I remember that someone successfully fit USB support and Samba into
> 4M flash using OpenWrt Backfi
It may have sense of doing the ack this in some cases. I need to do
some hardware testing to look at it more closely.
I think we can leave it is is. It's not important as I said before for
slow devices.
But the miscintc is redefined in ar7100.dtsi. So I am happy with that.
We need to have change i
> This is true for ar7100. On other chips the entire
> RST_MISC_INTERRUPT_STATUS block is marked as Read/Write-to-Clear.
Do you have the ar7240 datasheet with those specs?
> > It makes no sense to have a separate ack done this way. It slow things down.
> You can use an implementation without ack f
чт, 23 авг. 2018 г. в 6:36, Chuanhong Guo :
>
> Dmitry Tunin 于2018年8月23日周四 上午1:24写道：
> >
> > I looked into the specs and now I see that the
> > AR71XX_RESET_REG_MISC_INT_STATUS is read-only on ar7100, so we need to
> > change the compatible
> > to "qca,ar7
at if it is not set some default
maximum possible value is applied, like 32 in this case.
But we'll be able to set some number for each controller if we want it.
ср, 22 авг. 2018 г. в 15:35, Dmitry Tunin :
>
> It allocates some RAM I guess.
> ср, 22 авг. 2018 г. в 15:34, Chuanhong
> > I see no reason of having two different ways of mask-ack for similar
> > hardware. We need to chose one that looks better and drop the other.
> I suggest discussing any irq-ath79-misc changes with the upstream developers
> Alban Bedel did *a lot* of work to make the ath79 code devicetree
> comp
ay, since we are
> reusing this driver for PCI, I suggest to declare also
> "qca,ath79-pci-intc" that will
> have a different chip name = "PCI", so that "MISC and "PCI" will be
> seen separately in /proc/interrupts.
>
> 3. I suggest removing legacy __
t "MISC and "PCI" will be
seen separately in /proc/interrupts.
3. I suggest removing legacy __init ath79_misc_irq_init() and leaving
only the OF stuff.
Any comments?
ср, 22 авг. 2018 г. в 14:47, Chuanhong Guo :
>
> Dmitry Tunin 于2018年8月22日周三 下午5:07写道：
> >
> > Currently a
It allocates some RAM I guess.
ср, 22 авг. 2018 г. в 15:34, Chuanhong Guo :
>
> Hi!
> Dmitry Tunin 于2018年8月22日周三 下午8:31写道：
> >
> > We probably need to add a SoC check there. Otherwise we'll have two 32
> > IRQ domains when using it with PCI.
> But this doesn&#
We probably need to add a SoC check there. Otherwise we'll have two 32
IRQ domains when using it with PCI.
I guess older ones have 8 IRQs and newer ones - 16. We cal leave
default of 32 for unknown SoCs if there are any.
ср, 22 авг. 2018 г. в 13:59, Dmitry Tunin :
>
> Oops. I looked
Oops. I looked into newer specs. Some chips now have 16.
ср, 22 авг. 2018 г. в 13:50, Dmitry Tunin :
>
> According to specs this interrupt controller has 8 IRQs (0-7).
> If we reuse it for PCI, we need even less (0-4).
> We don't need that hude domain there.
>
> Sign
According to specs this interrupt controller has 8 IRQs (0-7).
If we reuse it for PCI, we need even less (0-4).
We don't need that hude domain there.
Signed-off-by: Dmitry Tunin
---
.../0037-MIPS-ath79-irq-misc-reduce-irq-count.patch | 13 +
1 file changed, 13 inser
ср, 22 авг. 2018 г. в 12:05, John Crispin :
>
>
>
> On 21/08/18 13:39, Chuanhong Guo wrote:
> > We currently don't have any code configuring interface mode in ath79,
> > meaning that we relies on bootloader to set the correct interface mode.
> >
> > This patch added code to set interface correctly
I looked now and I think ro ar724x we need only
https://github.com/openwrt/openwrt/pull/1299/commits/0d2c51cc04b6f3872806970b1de6967ccd30289c
It looks OK in that case that IRQ is handled inside PCIE.
ср, 22 авг. 2018 г. в 12:27, Dmitry Tunin :
>
> > we need a comparable patch for ar72
> we need a comparable patch for ar724x, right ? and then these 2 patches
> obsolete the PR on github ?
>
> John
Frankly speaking I didn't look into ar724x code. It has a PCIE, not a
PCI controller, so it wasn't affected that badly.
Chuanhong Guo knows that better.
__
IRQ handling code from the PCI driver.
2. Defines pci-intc interrupt controller@18060018 in dtsi.
3. Removes interrupt-controller property from PCI node.
4. Sets a correct interrupt mask for PCI devices.
Run tested on DIR-825 B1.
Signed-off-by: Dmitry Tunin
---
target/linux/ath79/dts/ar7100.dtsi
_MISC_IRQ_COUNT.
We don't need that huge domain. According to spec the misc controller
has 8 IRQs and the PCI has actually 4, but we need 5 to be linear.
So 8 will be enough for both. But it must be another patch.
ср, 22 авг. 2018 г. в 10:11, Chuanhong Guo :
>
> Dmitry Tunin 于2018年8月22日周三
> > They are similar. I used that code as an example, but the
> > irq-ath79-pci has your mask/unmask for pci with reading the registers.
> > It is possible to make one driver for both, but is it really needed?
> It helps reducing code duplication.
If we completely drop that PCI_CORE IRQ that we ar
> > This should fix a bug with one IRQ for all PCI devices and also handle the
> > PCI_CORE interrupt.
> No it doesn't. Assigning it in dts doesn't mean that we "handled" it.
> But I still like this patch because it's doing a cleanup of the messy code.
I am still not very competent in the IRQ han
Performance tests look good too.
вт, 21 авг. 2018 г. в 17:59, Dmitry Tunin :
>
> It is based on Chuanhong Guo work.
>
> PCI interrupt controller is not part of PCI. It is a part of reset controller
> with 0x18060018, 0x1806001c control registers.
>
> This should fix a bug wit
It is based on Chuanhong Guo work.
PCI interrupt controller is not part of PCI. It is a part of reset controller
with 0x18060018, 0x1806001c control registers.
This should fix a bug with one IRQ for all PCI devices and also handle the
PCI_CORE interrupt.
I am not sure that this kind of cascadin
вс, 19 авг. 2018 г. в 17:46, Mathias Kresin :
>
> 2018-08-19 15:47 GMT+02:00 Chuanhong Guo :
> > These lines are coming from ar71xx to allow using sysupgrade to
> > switch from ar71xx to ath79. But a sysupgrade with config preserved
> > won't work since some of the config files are incompatible.
>
вс, 19 авг. 2018 г. в 14:29, Dmitry Tunin :
>
> вс, 19 авг. 2018 г. в 12:28, Mathias Kresin :
> >
> > 18.08.2018 14:01, David Bauer:
> > > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > > supported_devices. ar71xx is expecting "
вс, 19 авг. 2018 г. в 12:28, Mathias Kresin :
>
> 18.08.2018 14:01, David Bauer:
> > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > the ath79 image. Upgrading from ath79 is unaffected, as the im
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2
13.08.2018 19:34, Mathias Kresin пишет:
2018-08-13 18:28 GMT+02:00 Dmitry Tunin :
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2
Add support for the ar71xx supported Tp_link MR-3040 v2 to ath79.
Signed-off-by: Dmitry Tunin
---
.../linux/ath79/base-files/etc/board.d/02_network | 1 +
.../linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts | 161 +
target/linux/ath79/image/tiny-tp-link.mk | 10
96 matches
Mail list logo
