Re: Question re DeviceTree addressing

[Florian Fainelli]

On 4/3/2023 7:00 AM, Caleb James DeLisle wrote:

Hello folks,

I've been working on trying to port an en7526 and in doing so I'm trying 
to learn how to at least partially write a DTS file from an old style 
header full of #defines.


I ran into a bit of a quandry, I'm comparing the mt7621.dtsi file to an 
older MT7621 memory map header:


https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621.dtsi#L100

https://github.com/keenetic/kernel-49/blob/master/arch/mips/include/asm/rt2880/rt_mmap.h#L48

```
 palmbus: palmbus@1e00 {
     compatible = "palmbus";
     reg = <0x1e00 0x10>;
     ranges = <0x0 0x1e00 0x0f>;

[...]

     i2c: i2c@900 {
     compatible = "mediatek,mt7621-i2c";
     reg = <0x900 0x100>;
```

For me, means there should be an I2C controller mapped at address 
0x1e000900.


Correct.



But looking at rt_mmap.h I see:

```
#define RALINK_I2C_BASE    0xBE000900
```

And in fact almost everything is based on 0xBE00, except UART and 
USB addresses which are "correct". And I see these 0xBE00 addresses 
being passed through KSEG1ADDR() so it seems they are physical memory 
addresses, not virtual.


KSEG1ADDR does a logical or so it would not be altering RALINK_I2C_BASE 
when OR'd with 0xa000 (KSEG1) you would still get 0xBE000900.


It seems to me like in places where it may be necessary to pass a 
physical address they used physical addresses such that ioremap() 
ends-up returning a proper kernel virtual address in KSEG1, however 
everywhere else the driver might have just directly de-referenced the 
constant which ends-up working just fine as well.


HTH
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Unloading unused kernel modules (NAT speed)

[Florian Fainelli]

On 2/3/23 08:18, Rafał Miłecki wrote:

Another step in my NAT performance debugging.

I realized that my OpenWrt 21.02 based bcm53xx builds can't reach 940
Mb/s because I have qos-scripts installed.

It happens even with QoS interface disabled:
qos.wan.enabled='0'
and with QoS disabled in general:
/etc/init.d/qos stop
(disable & reboot don't help neither)

After quite some debugging I discovered that:
1. qos-scripts selects iptables-mod-conntrack-extra
2. iptables-mod-conntrack-extra selects kmod-ipt-raw
3. kmod-ipt-raw provides iptable_raw.ko
4. iptable_raw.ko slows down NAT


I can bump NAT speed from 880 Mb/s to 940 Mb/s by doing:

# rmmod iptable_raw
unloading the module failed
# /etc/init.d/firewall stop > /dev/null 2>&1
# rmmod iptable_raw
# /etc/init.d/firewall start > /dev/null 2>&1


I'm wondering if there is any good solution to that. I can't think of
anything clean and generic. Handling modprobe & rmmod directly in
/etc/init.d/qos sounds really hacky. Any good ideas?


Have you managed to get a `perf record` or `perf top` capture to see 
whether we might be going a little too far into iptables-raw code rather 
than bailing out early if we are not utilizing it?

--
Florian


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: DSA Mini-tutorial still marked as Work In Progress

[Florian Fainelli]

On 9/7/2022 3:00 PM, Sebastian Moeller wrote:

Hi Jo,

I was under the impression* that bridge-vlan filtering is something that can be 
relegated to the switch hardware, while creating a bridge between VLAN 
interfaces happens in software. Is that wrong?


It is incorrect. DSA offloads the bridge to the switch hardware whether 
you have VLAN filtering or not.


When the bridge is not VLAN aware (vlan_filtering=0) what it means is 
that the Linux bridge, and the underlying switch MUST accept both VLAN 
and non-VLAN tagged frames.


If you do want VLAN tagged frames in that bridge, then you are supposed 
to terminate VLAN traffic by creating upper VLAN devices such as 
lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 
still happens in hardware because those VLAN devices are offloaded into 
the switch hardware.


When vlan_filtering=1 is set, the hardware is configured to only accept 
untagged PVID frames as well as whichever VLAN tagged frames you have 
configured.


For instance, if you configured your bridge this way with: lan1, lan2, 
lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port 
will be programmed to be in the bridge's default_pvid (1, unless 
changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any 
of those ports, and assuming the switch hardware is capable of it, that 
VLAN ID 2 frame creates an egress VID violation and is discarded. If not 
discarded in hardware it would be discarded in software.


Hope this helps.



Regards
Sebastian


*) Not sure where I got that impression from



On Sep 7, 2022, at 23:48, Jo-Philipp Wich  wrote:

Hi Rich,

that tutorial is good ground work imho. One thing I repeatedly noticed (not in
the document, but in forum and irc chatter) is that over the time, DSA and
bridge VLAN filtering became conflated into one concept while they're actually
different pieces; one can do bridge VLAN filtering without DSA and one can
utilize DSA without doing bridge VLAN filtering.

Bluntly speaking, DSA is the thing that gives you one Linux network device per
switch port and bridge VLAN filtering is the stuff that allows you declaring
swconfig-esque VLAN port groups on top of an arbitrary bridge interface.

I think this is something we should try to better convey in the documentation.

For example simple common use cases like:

- Making each switch port it's own independent interface with own subnet

or

- Break out one switch port to turn it into some kind of restricted IoT or
   guest network access port

or

- Bridge each ethernet port to another SSID

don't require bridge VLAN filtering or touching VLANs in general at all (in
contrast to former swconfig). The per-port net devices just have to be taken
out of the br-lan bridge and either be put into another bridge or configured
as independent network devices.

Bridge VLAN filtering on the other hand is only actually needed if you want to
deal with VLAN tagged traffic inside the bridge. And even then there's
sometimes alternative ways, for example the following two scenarios should be
functionally equivalent:

- Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
  - VLAN filtering disabled

vs.

- Bridge device "br-lan" containing "lan1 lan2 lan3"
  - VLAN filtering enabled
  - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged
- VLAN device br-lan.10 on top of br-lan


In the former case you would put your IP address settings onto the dedicated
"br-vlan10" bridge device while in the latter case you would configure the IP
addressing on the "br-lan.10" subinterface of the "br-lan" bridge.

So maybe it makes sense to focus on the "with DSA, your switch just becomes a
linux bridge over a bunch of netdevs" aspect in the mini tutorial and break
out any bridge-VLAN related information into a separate advanced VLAN tutorial.

Another conceptual issue I see is that people came to expect a dedicated
"switch" configuration ui which is something that does not really work with
DSA devices anymore since there is no dedicated switch hardware entity to
interact with anymore (DSA takes care of completely abstracting this away from
the user point of view) and that bridge-vlans just happen to be a
configuration detail of a bridge, and that there happens to be a bridge
"br-lan" by default, but a system could have multiple bridges, or none at all.

So we should also explain why there is no central "switch configuration"
anymore and that this does not translate into a loss of functionality, but
that the former semi opague swconfig switch configuration entity was dissolved
into a bunch of ethernet devices inside a bridge...



~ Jo

___
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

Re: DSA Mini-tutorial still marked as Work In Progress

[Florian Fainelli]

On 9/7/2022 3:17 PM, David Lang wrote:
with DSA, do you HAVE to go through the cpu interface and kernel to 
bridge different ports on the switch? or can you still do vlan routing 
inside the switch?


DSA offloads the bridge to the switch hardware, so if the hardware 
switch can do its job and forward frames in hardware from port A to port 
B, it will do it. DSA has little significance here, the same constraints 
apply/applied to swconfig as well.




for the Scale conference, I've done a lot of work using the switch for 
passing vlan tagged traffic on to other systems while only sending some 
of it to the CPU (the CPU would be a very significant bottleneck if I 
tried to send everything though it)


David Lang

On Wed, 7 Sep 2022, Jo-Philipp Wich wrote:


Hi Rich,

that tutorial is good ground work imho. One thing I repeatedly noticed 
(not in
the document, but in forum and irc chatter) is that over the time, DSA 
and
bridge VLAN filtering became conflated into one concept while they're 
actually
different pieces; one can do bridge VLAN filtering without DSA and one 
can

utilize DSA without doing bridge VLAN filtering.

Bluntly speaking, DSA is the thing that gives you one Linux network 
device per
switch port and bridge VLAN filtering is the stuff that allows you 
declaring

swconfig-esque VLAN port groups on top of an arbitrary bridge interface.

I think this is something we should try to better convey in the 
documentation.


For example simple common use cases like:

- Making each switch port it's own independent interface with own subnet

or

- Break out one switch port to turn it into some kind of restricted 
IoT or

  guest network access port

or

- Bridge each ethernet port to another SSID

don't require bridge VLAN filtering or touching VLANs in general at 
all (in
contrast to former swconfig). The per-port net devices just have to be 
taken
out of the br-lan bridge and either be put into another bridge or 
configured

as independent network devices.

Bridge VLAN filtering on the other hand is only actually needed if you 
want to

deal with VLAN tagged traffic inside the bridge. And even then there's
sometimes alternative ways, for example the following two scenarios 
should be

functionally equivalent:

- Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
 - VLAN filtering disabled

vs.

- Bridge device "br-lan" containing "lan1 lan2 lan3"
 - VLAN filtering enabled
 - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as 
tagged

- VLAN device br-lan.10 on top of br-lan


In the former case you would put your IP address settings onto the 
dedicated
"br-vlan10" bridge device while in the latter case you would configure 
the IP

addressing on the "br-lan.10" subinterface of the "br-lan" bridge.

So maybe it makes sense to focus on the "with DSA, your switch just 
becomes a
linux bridge over a bunch of netdevs" aspect in the mini tutorial and 
break
out any bridge-VLAN related information into a separate advanced VLAN 
tutorial.


Another conceptual issue I see is that people came to expect a dedicated
"switch" configuration ui which is something that does not really work 
with

DSA devices anymore since there is no dedicated switch hardware entity to
interact with anymore (DSA takes care of completely abstracting this 
away from

the user point of view) and that bridge-vlans just happen to be a
configuration detail of a bridge, and that there happens to be a bridge
"br-lan" by default, but a system could have multiple bridges, or none 
at all.


So we should also explain why there is no central "switch configuration"
anymore and that this does not translate into a loss of functionality, 
but
that the former semi opague swconfig switch configuration entity was 
dissolved

into a bunch of ethernet devices inside a bridge...



~ Jo




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: DSA Mini-tutorial still marked as Work In Progress

[Florian Fainelli]

On 9/4/2022 2:32 PM, Arınç ÜNAL wrote:

Hi Rich,

On 4.09.2022 17:58, Rich Brown wrote:

Folks,

The DSA Mini-tutorial on the Wiki 
(https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is 
still marked as a "Work In Progress"


I should know - I wrote this up as we were getting ready to ship 
21.02, and I thought that we should have something about DSA on the 
wiki. But I don't really know anything about DSA - I simply pieced the 
article together from a few forum posts. And I never received any 
direct feedback or saw any updates to the wiki page.


I was "makin' a lot of stuff up" as I wrote that page. It's the best I 
could do, but nothing that's written there should be taken as gospel. 
The italics near the top indicate areas of uncertainty. I also was 
guessing about the difference between device and interface definitions.


Here's my request:

It would do my heart good to have someone who's knowledgeable about 
DSA read through the page and either make direct corrections, or send 
me a note and I'll make them.  Thanks.


I don't see much content to document DSA. All DSA does is creating a 
network interface for each switch port. What I think should be properly 
documented is the Bridge VLAN filtering feature. I have made some 
efforts to do that on my playground here:


https://openwrt.org/playground/arinc9/start

I know I was supposed to deliver much more, much earlier. I still have a 
huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully 
pushed down to the bottom of my task list.


Maybe this is enough to reference since it contains basic use cases, and 
not so basic ones, too:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

On 8/12/22 13:28, Robert Marko wrote:

On Fri, 12 Aug 2022 at 21:45, Florian Fainelli  wrote:


On 8/12/22 11:09, Robert Marko wrote:

On Fri, 12 Aug 2022 at 19:54, Florian Fainelli  wrote:


On 8/10/22 13:32, Robert Marko wrote:

On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
 wrote:


Not to play the devil's advocate but... do we want old kernels hanging out that 
long?

Besides not encouraging people to update to new releases that mitigate 
discovered CVE's, we'd also not pick up David Taht's excellent improvements in 
Buffer Bloat.


I have to agree with this.
What would be the benefit for OpenWrt with having LTS kernels
supported for 6 years?


One aspect I could see is take for instance a device that is widely
popular amongst our user base as was TI's ar7 for instance a while back,
and for which we might have done a Linux 5.4, or 5.10 version at the
time but we do not wish to continue to maintain.


I dont see how this is related to LTS kernel support.


OK maybe I need to spell out my example more clearly. Let us say that we
have a release in 2019 of OpenWrt that supported TI AR7 based upon the
Linux 5.4 kernel.

Fast forward to 2022, we decide to abandon TI AR7 in master and we stop
supporting it entirely for future releases. A very bad Linux security
problem show up, and because we care about our users, we keep updating
the LTS kernel that was used in the 2019.x release up until, say the
said kernel stops being supported. If that support time frame was 6
years, then we would really be helping our users.

Maybe the wider discussion to be had, is:

- when and how do we decide to deprecate a given Linux port, I assume it
is when no more users show up or maybe more realistically when OpenWrt
developers just cannot keep up with updating those devices because they
no longer use those themselves

- how long do we want to keep supporting past OpenWrt releases with
kernel updates, 2 years, 3/4 years, 6 years to match the kernel
lifecycle they are based upon?


As an idea, I understand this, it would basically be an "LTS" OpenWrt
release that
would receive security-only updates.

However, we had a long discussion on the IRC today and the resources are spread
rather thin even currently with 2 or 3 releases being supported.

If its gonna be a volunteer kind of no guarantees release, then maybe
but I dont see
how we can manage that as well.


That is fair, if we are spread too thin, and clearly we are, then yes, I 
agree we should focus on the latest releases and people who cannot 
update for whatever reason, be it now unsupported hardware, or high 
availability or whatever should find out a solution. It's open source 
after all :)










Being able to continue to deliver stable kernel updates in a stable
OpenWrt branch could be a good way for users to pick up their next xDSL
router since there are not so many out there that can actually run
OpenWrt compared to pure Wired/Wi-Fi for instance.


I can agree with this.




Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.


That argument I am sympathetic with, and the sheer amount of out of tree
patches we have in OpenWrt is not helping, in fact it definitively makes
it harder to regularly test, but still somehow we managed to do it.

Since we will merge stable updates eventually, the point would be that
instead of testing those that are already released, we could try to test
the release candidates and report back anything we find?


This is a good idea, not sure how we can do it within OpenWrt though with
the amount of patches we have that make it a pain to bump kernels.


Maybe we should give it a spin and see how painful that actually is and
then if we can sustain doing that over time it just becomes a thing a
group of volunteers can do?

After all, we do go through that exercise fairly frequently.


This looks similar to what we discussed to today on IRC, maybe having a more
up-to-date development OpenWrt along longer lasting stable releases.

As currently, OpenWrt is way out of date for kernel development but is moving
too quickly for keeping the stable releases from regressing.


Which is an interesting paradox.
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

On 8/12/22 13:49, Philip Prindeville wrote:




On Aug 12, 2022, at 11:54 AM, Florian Fainelli  wrote:

One aspect I could see is take for instance a device that is widely popular 
amongst our user base as was TI's ar7 for instance a while back, and for which 
we might have done a Linux 5.4, or 5.10 version at the time but we do not wish 
to continue to maintain.



Per my previous email, that seems like something that the SoC manufacturer 
should be doing... Why is this our burden?



Totally agree that SoC manufacturers share a fair amount of 
responsibility, there is no substitute for upstream and it associated 
benefits, but it is a commitment, and you are not stranger to this world.


In terms of supporting a given piece of hardware though, I would 
decouple the timeline.


There is the initial effort required to support your SoC and its many 
products which largely involves writing architecture specific code 
sometimes, DTS files, clock/SPI/USB/NAND/Ethernet MAC/PHY/Switch/Wi-Fi 
drivers for the most part. You would typically target a LTS kernel 
version for that effort such that you amortize that effort over a few 
years to come until the next LTS, and if possible in the meantime try to 
get your patches upstream such that the next LTS requires fewer patches 
to be carried over.


Now, when new stable updates show up though, the amount of merge 
conflicts or SoC support code you need to adjust is minimal compared to 
the other parts of the kernel that got updated.


So back to my example, we could have invested out of tree support for TI 
AR7 up until 5.4 and then decided to put it into an EOL/deep maintenance 
mode. Updating the stable 5.4 kernel would unlikely change the amount of 
AR7 specific patches, so the maintenance cost could be fairly low.


Does that make sense?
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

On 8/12/22 11:09, Robert Marko wrote:

On Fri, 12 Aug 2022 at 19:54, Florian Fainelli  wrote:


On 8/10/22 13:32, Robert Marko wrote:

On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
 wrote:


Not to play the devil's advocate but... do we want old kernels hanging out that 
long?

Besides not encouraging people to update to new releases that mitigate 
discovered CVE's, we'd also not pick up David Taht's excellent improvements in 
Buffer Bloat.


I have to agree with this.
What would be the benefit for OpenWrt with having LTS kernels
supported for 6 years?


One aspect I could see is take for instance a device that is widely
popular amongst our user base as was TI's ar7 for instance a while back,
and for which we might have done a Linux 5.4, or 5.10 version at the
time but we do not wish to continue to maintain.


I dont see how this is related to LTS kernel support.


OK maybe I need to spell out my example more clearly. Let us say that we 
have a release in 2019 of OpenWrt that supported TI AR7 based upon the 
Linux 5.4 kernel.


Fast forward to 2022, we decide to abandon TI AR7 in master and we stop 
supporting it entirely for future releases. A very bad Linux security 
problem show up, and because we care about our users, we keep updating 
the LTS kernel that was used in the 2019.x release up until, say the 
said kernel stops being supported. If that support time frame was 6 
years, then we would really be helping our users.


Maybe the wider discussion to be had, is:

- when and how do we decide to deprecate a given Linux port, I assume it 
is when no more users show up or maybe more realistically when OpenWrt 
developers just cannot keep up with updating those devices because they 
no longer use those themselves


- how long do we want to keep supporting past OpenWrt releases with 
kernel updates, 2 years, 3/4 years, 6 years to match the kernel 
lifecycle they are based upon?







Being able to continue to deliver stable kernel updates in a stable
OpenWrt branch could be a good way for users to pick up their next xDSL
router since there are not so many out there that can actually run
OpenWrt compared to pure Wired/Wi-Fi for instance.


I can agree with this.




Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.


That argument I am sympathetic with, and the sheer amount of out of tree
patches we have in OpenWrt is not helping, in fact it definitively makes
it harder to regularly test, but still somehow we managed to do it.

Since we will merge stable updates eventually, the point would be that
instead of testing those that are already released, we could try to test
the release candidates and report back anything we find?


This is a good idea, not sure how we can do it within OpenWrt though with
the amount of patches we have that make it a pain to bump kernels.


Maybe we should give it a spin and see how painful that actually is and 
then if we can sustain doing that over time it just becomes a thing a 
group of volunteers can do?


After all, we do go through that exercise fairly frequently.
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

On 8/10/22 13:32, Robert Marko wrote:

On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
 wrote:


Not to play the devil's advocate but... do we want old kernels hanging out that 
long?

Besides not encouraging people to update to new releases that mitigate 
discovered CVE's, we'd also not pick up David Taht's excellent improvements in 
Buffer Bloat.


I have to agree with this.
What would be the benefit for OpenWrt with having LTS kernels
supported for 6 years?


One aspect I could see is take for instance a device that is widely 
popular amongst our user base as was TI's ar7 for instance a while back, 
and for which we might have done a Linux 5.4, or 5.10 version at the 
time but we do not wish to continue to maintain.


Being able to continue to deliver stable kernel updates in a stable 
OpenWrt branch could be a good way for users to pick up their next xDSL 
router since there are not so many out there that can actually run 
OpenWrt compared to pure Wired/Wi-Fi for instance.



Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.


That argument I am sympathetic with, and the sheer amount of out of tree 
patches we have in OpenWrt is not helping, in fact it definitively makes 
it harder to regularly test, but still somehow we managed to do it.


Since we will merge stable updates eventually, the point would be that 
instead of testing those that are already released, we could try to test 
the release candidates and report back anything we find?

--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

On 8/10/22 15:27, Hauke Mehrtens wrote:

On 8/9/22 01:15, Florian Fainelli wrote:

Hi,

Greg KH has communicated a few times before on his blog [1] that he is 
seeking the help of individuals and company to help him maintain the 
LTS kernels and allow them to be made 6 years instead of just the 
usual 2 years.


5.10 is a 6 year LTS, but 5.15 is not listed as such, although it 
certainly would make sense for it to be since we use 5.15 in OpenWrt.


It would be good for the project to have a designated contact who can 
communicate the kernel version plan ahead of time, or once a LTS is 
picked up, we could sign up people to do regular testing of the stable 
release candidates?


Thoughts?

[1]: 
http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/ 



Hi Florian,

I saw that you are often testing the stable rc version, this is really 
great. Someone could try to automate this in OpenWrt to automatically 
test the stable RC kernel versions, but it probably still needs some 
maintenance. Currently I do not see that we have the resources to do this.


Yes I do try to test the release candidates when they show up, although 
that is done on the limited set of devices I have at work and at home 
usually, so it won't catch all of the possible regressions, and the 
tests are limited to kselftests and some occasional one offs that are 
device specific.




I do not think OpenWrt needs 6 LTS years kernel support 3 to 4 years is 
fine for OpenWrt. If we do the 22.03 stable release in the next week we 
can declare 21.02 end of life by end of February 2023. We would have 
used kernel 5.4 only a bit over 3 years after its initial release is 
November 2019.


OK, the 3-4 years time frame is not something that we currently have 
with Linux kernels, it is either 2 years or 6 years, since 6 > 4, it 
sounds like we still have some interest in having 6 LTS kernels, but 
maybe not have every single LTS release be 6 years, right?




If you want to volunteer to help Greg KH more on this it would still be 
nice.


I will continue to help with the stable candidates testing for the 
foreseeable future as it is largely automated and does not require much 
effort on my side, and will keep an open channel with Greg to tell him 
about what OpenWrt has selected.

--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reaching out to Greg KH for 6 year LTS kernel versions

[Florian Fainelli]

Hi,

Greg KH has communicated a few times before on his blog [1] that he is 
seeking the help of individuals and company to help him maintain the LTS 
kernels and allow them to be made 6 years instead of just the usual 2 years.


5.10 is a 6 year LTS, but 5.15 is not listed as such, although it 
certainly would make sense for it to be since we use 5.15 in OpenWrt.


It would be good for the project to have a designated contact who can 
communicate the kernel version plan ahead of time, or once a LTS is 
picked up, we could sign up people to do regular testing of the stable 
release candidates?


Thoughts?

[1]: 
http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/

--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/14/22 11:07 AM, Hauke Mehrtens wrote:
> On 2/4/22 00:48, Hauke Mehrtens wrote:
>> Hi,
>>
>> We would like to switch the bcm63xx target to kernel 5.10. Paul
>> created a pull request for that:
>> https://github.com/openwrt/openwrt/pull/4616
>>
>> There is still a problem with Macronix NAND flash chips, see the
>> comments from the pull request.
>>
>> Could someone please have a look into this problem.
>>
>> Does this change in the upstream kernel help?
>> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530
>>
>>
>> Hauke
> 
> Hi,
> 
> I read that Daniel's device is now completely broken, probably
> bootloader was overwritten.
> 
> The bcm63xx target is the last one using kernel 5.4. We would like to
> remove kernel 5.4 support from OpenWrt master soon and branch off the
> next major release. How do we want to go forward with this topic?
> 
> Should we apply this hack?

I would be inclined to apply this hack and make it bcm63xx specific
unless other platforms suffer from that problem.

Meanwhile, I would reach out to the MTD maintainers to understand what
is going on, mentioning what we have found, which is that the brcmnand
controller prior to version 4.0 does not support the {GET,SET}_FEATURES
command.

Daniel, any hope of recovering your device somehow?
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 2:57 PM, Florian Fainelli wrote:



On 2/4/2022 2:50 PM, Florian Fainelli wrote:



On 2/4/2022 2:45 PM, Florian Fainelli wrote:



On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:

El vie, 4 feb 2022 a las 23:02, Florian Fainelli
() escribió:




On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
So the problem is that SET_FEATURES and GET_FEATURES isn’t 
supported by versions 2.1, 2.2 and 4.0 of the nand controller, 
which are the ones present on bcm63xx, right?


Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
being defined in the register database for the controllers v2.1 and
v2.2, v3.3. Staring with v4.0, the controllers do have the
CMD_LOW_LEVEL_OP. This is the version/feature table that I could
programmatically compile:

version: 0.1, ll: no
version: 1.0, ll: no
version: 2.0, ll: no
version: 2.1, ll: no
version: 2.2, ll: no
version: 3.0, ll: no
version: 3.2, ll: no
version: 3.3, ll: no
version: 3.4, ll: no
version: 4.0, ll: yes
version: 5.0, ll: yes
version: 6.0, ll: yes
version: 6.2, ll: yes
version: 7.0, ll: yes
version: 7.1, ll: yes
version: 7.2, ll: yes
version: 7.3, ll: yes

How about this patch, does it work better?

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..06ac593beec0 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
  break;
  case NAND_CMD_SET_FEATURES:
  case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
  brcmnand_low_level_op(host, LL_OP_CMD, command, 
false);
  brcmnand_low_level_op(host, LL_OP_ADDR, column, 
false);

  break;

--
Florian


No, it didn't help:


OK, last tentative and then I think you should report this to 
linux-mtd such that the MTD maintainers may suggest whether we are 
missing something obvious here:


scratch that, can you try this instead:


And also try this patch because I don't believe there is sufficient 
protection in macronix_nand_block_protection_support to ensure that the 
NAND chip is ONFI capable:


Could you try this patch?



diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
b/drivers/mtd/nand/raw/nand_macronix.c

index 1472f925f386..78f893add636 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -219,9 +219,13 @@ static int mxic_nand_unlock(struct nand_chip *chip, 
loff_t ofs, uint64_t len)


  static void macronix_nand_block_protection_support(struct nand_chip 
*chip)

  {
+   struct nand_parameters *p = >parameters;
     u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
     int ret;

+   if (!p->onfi || !chip->parameters.supports_set_get_features)
+   return;
+
     bitmap_set(chip->parameters.get_feature_list,
    ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);

Thanks!


--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 2:50 PM, Florian Fainelli wrote:



On 2/4/2022 2:45 PM, Florian Fainelli wrote:



On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:

El vie, 4 feb 2022 a las 23:02, Florian Fainelli
() escribió:




On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
So the problem is that SET_FEATURES and GET_FEATURES isn’t 
supported by versions 2.1, 2.2 and 4.0 of the nand controller, 
which are the ones present on bcm63xx, right?


Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
being defined in the register database for the controllers v2.1 and
v2.2, v3.3. Staring with v4.0, the controllers do have the
CMD_LOW_LEVEL_OP. This is the version/feature table that I could
programmatically compile:

version: 0.1, ll: no
version: 1.0, ll: no
version: 2.0, ll: no
version: 2.1, ll: no
version: 2.2, ll: no
version: 3.0, ll: no
version: 3.2, ll: no
version: 3.3, ll: no
version: 3.4, ll: no
version: 4.0, ll: yes
version: 5.0, ll: yes
version: 6.0, ll: yes
version: 6.2, ll: yes
version: 7.0, ll: yes
version: 7.1, ll: yes
version: 7.2, ll: yes
version: 7.3, ll: yes

How about this patch, does it work better?

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..06ac593beec0 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
  break;
  case NAND_CMD_SET_FEATURES:
  case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
  brcmnand_low_level_op(host, LL_OP_CMD, command, 
false);
  brcmnand_low_level_op(host, LL_OP_ADDR, column, 
false);

  break;

--
Florian


No, it didn't help:


OK, last tentative and then I think you should report this to 
linux-mtd such that the MTD maintainers may suggest whether we are 
missing something obvious here:


scratch that, can you try this instead:


And also try this patch because I don't believe there is sufficient 
protection in macronix_nand_block_protection_support to ensure that the 
NAND chip is ONFI capable:


diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
b/drivers/mtd/nand/raw/nand_macronix.c

index 1472f925f386..78f893add636 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -219,9 +219,13 @@ static int mxic_nand_unlock(struct nand_chip *chip, 
loff_t ofs, uint64_t len)


 static void macronix_nand_block_protection_support(struct nand_chip *chip)
 {
+   struct nand_parameters *p = >parameters;
u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
int ret;

+   if (!p->onfi || !chip->parameters.supports_set_get_features)
+   return;
+
bitmap_set(chip->parameters.get_feature_list,
   ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);

Thanks!
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 2:45 PM, Florian Fainelli wrote:



On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:

El vie, 4 feb 2022 a las 23:02, Florian Fainelli
() escribió:




On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
So the problem is that SET_FEATURES and GET_FEATURES isn’t supported 
by versions 2.1, 2.2 and 4.0 of the nand controller, which are the 
ones present on bcm63xx, right?


Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
being defined in the register database for the controllers v2.1 and
v2.2, v3.3. Staring with v4.0, the controllers do have the
CMD_LOW_LEVEL_OP. This is the version/feature table that I could
programmatically compile:

version: 0.1, ll: no
version: 1.0, ll: no
version: 2.0, ll: no
version: 2.1, ll: no
version: 2.2, ll: no
version: 3.0, ll: no
version: 3.2, ll: no
version: 3.3, ll: no
version: 3.4, ll: no
version: 4.0, ll: yes
version: 5.0, ll: yes
version: 6.0, ll: yes
version: 6.2, ll: yes
version: 7.0, ll: yes
version: 7.1, ll: yes
version: 7.2, ll: yes
version: 7.3, ll: yes

How about this patch, does it work better?

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..06ac593beec0 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
  break;
  case NAND_CMD_SET_FEATURES:
  case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
  brcmnand_low_level_op(host, LL_OP_CMD, command, 
false);
  brcmnand_low_level_op(host, LL_OP_ADDR, column, 
false);

  break;

--
Florian


No, it didn't help:


OK, last tentative and then I think you should report this to linux-mtd 
such that the MTD maintainers may suggest whether we are missing 
something obvious here:


scratch that, can you try this instead:

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c 
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c

index f75929783b94..f49ef76bc2b8 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1651,6 +1651,9 @@ static int brcmnand_low_level_op(struct 
brcmnand_host *host,

struct brcmnand_controller *ctrl = host->ctrl;
u32 tmp;

+   if (ctrl->nand_version < 0x0400)
+   return -EOPNOTSUPP;
+
tmp = data & LLOP_DATA_MASK;
switch (type) {
case LL_OP_CMD:
@@ -1829,7 +1832,9 @@ static uint8_t brcmnand_read_byte(struct nand_chip 
*chip)

} else {
bool last = host->last_byte ==
ONFI_SUBFEATURE_PARAM_LEN - 1;
-   brcmnand_low_level_op(host, LL_OP_RD, 0, last);
+   ret = brcmnand_low_level_op(host, LL_OP_RD, 0, 
last);

+   if (ret == -EOPNOTSUPP)
+   return ret;
ret = brcmnand_read_reg(ctrl, 
BRCMNAND_LL_RDATA) & 0xff;

}
}


--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:

El vie, 4 feb 2022 a las 23:02, Florian Fainelli
() escribió:




On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:

So the problem is that SET_FEATURES and GET_FEATURES isn’t supported by 
versions 2.1, 2.2 and 4.0 of the nand controller, which are the ones present on 
bcm63xx, right?


Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
being defined in the register database for the controllers v2.1 and
v2.2, v3.3. Staring with v4.0, the controllers do have the
CMD_LOW_LEVEL_OP. This is the version/feature table that I could
programmatically compile:

version: 0.1, ll: no
version: 1.0, ll: no
version: 2.0, ll: no
version: 2.1, ll: no
version: 2.2, ll: no
version: 3.0, ll: no
version: 3.2, ll: no
version: 3.3, ll: no
version: 3.4, ll: no
version: 4.0, ll: yes
version: 5.0, ll: yes
version: 6.0, ll: yes
version: 6.2, ll: yes
version: 7.0, ll: yes
version: 7.1, ll: yes
version: 7.2, ll: yes
version: 7.3, ll: yes

How about this patch, does it work better?

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..06ac593beec0 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
  break;
  case NAND_CMD_SET_FEATURES:
  case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
  brcmnand_low_level_op(host, LL_OP_CMD, command, false);
  brcmnand_low_level_op(host, LL_OP_ADDR, column, false);
  break;

--
Florian


No, it didn't help:


OK, last tentative and then I think you should report this to linux-mtd 
such that the MTD maintainers may suggest whether we are missing 
something obvious here:


diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c 
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c

index f75929783b94..0632550f0c45 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1701,10 +1701,6 @@ static void brcmnand_cmdfunc(struct nand_chip 
*chip, unsigned command,

dev_dbg(ctrl->dev, "cmd 0x%x addr 0x%llx\n", command,
(unsigned long long)addr);

-   host->last_cmd = command;
-   host->last_byte = 0;
-   host->last_addr = addr;
-
switch (command) {
case NAND_CMD_RESET:
native_cmd = CMD_FLASH_RESET;
@@ -1727,6 +1723,8 @@ static void brcmnand_cmdfunc(struct nand_chip 
*chip, unsigned command,

break;
case NAND_CMD_SET_FEATURES:
case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
brcmnand_low_level_op(host, LL_OP_CMD, command, false);
brcmnand_low_level_op(host, LL_OP_ADDR, column, false);
break;
@@ -1748,6 +1746,10 @@ static void brcmnand_cmdfunc(struct nand_chip 
*chip, unsigned command,

if (!native_cmd)
return;

+   host->last_cmd = command;
+   host->last_byte = 0;
+   host->last_addr = addr;
+
brcmnand_set_cmd_addr(mtd, addr);
brcmnand_send_cmd(host, native_cmd);
brcmnand_waitfunc(chip);


--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:

So the problem is that SET_FEATURES and GET_FEATURES isn’t supported by 
versions 2.1, 2.2 and 4.0 of the nand controller, which are the ones present on 
bcm63xx, right?


Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP 
being defined in the register database for the controllers v2.1 and 
v2.2, v3.3. Staring with v4.0, the controllers do have the 
CMD_LOW_LEVEL_OP. This is the version/feature table that I could 
programmatically compile:


version: 0.1, ll: no
version: 1.0, ll: no
version: 2.0, ll: no
version: 2.1, ll: no
version: 2.2, ll: no
version: 3.0, ll: no
version: 3.2, ll: no
version: 3.3, ll: no
version: 3.4, ll: no
version: 4.0, ll: yes
version: 5.0, ll: yes
version: 6.0, ll: yes
version: 6.2, ll: yes
version: 7.0, ll: yes
version: 7.1, ll: yes
version: 7.2, ll: yes
version: 7.3, ll: yes

How about this patch, does it work better?

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c 
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c

index f75929783b94..06ac593beec0 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip 
*chip, unsigned command,

break;
case NAND_CMD_SET_FEATURES:
case NAND_CMD_GET_FEATURES:
+   if (ctrl->nand_version < 0x0400)
+   break;
brcmnand_low_level_op(host, LL_OP_CMD, command, false);
brcmnand_low_level_op(host, LL_OP_ADDR, column, false);
break;

--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 10:47 AM, Hauke Mehrtens wrote:

On 2/4/22 19:23, Florian Fainelli wrote:



On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote:

Hi Hauke:

El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () 
escribió:


Hi,

We would like to switch the bcm63xx target to kernel 5.10. Paul created
a pull request for that:
https://github.com/openwrt/openwrt/pull/4616

There is still a problem with Macronix NAND flash chips, see the
comments from the pull request.

Could someone please have a look into this problem.

Does this change in the upstream kernel help?
https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 




The patch together with:
https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 



They both apply cleanly without changes in current Openwrt, kernel
testing 5.10, But the kernel still fails to load, caused by
macronix_nand_block_protection_support .


Is there a log available somewhere that shows the boot failure with 
5.10? Have you been able to run a bisection somehow?


None of those patches should be relevant as the DSL SoCs do not use 
EDU, they use PIO. Now about this one:


lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html


Hi Florian,

The details are in this pull request:
https://github.com/openwrt/openwrt/pull/4616

We see this error:
---
[    0.789569] printk: bootconsole [early0] disabled
[    0.789569] printk: bootconsole [early0] disabled
[    0.812291] bcm6368_nand 1200.nand: there is not valid maps for 
state default

[    0.823019] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[    0.829592] nand: Macronix MX30LF1G18AC
[    0.833525] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    0.841306] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB 
blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4

[    0.857758] Bad block table not found for chip 0
[    0.867999] Bad block table not found for chip 0
[    0.872690] Scanning device for bad blocks
[    0.909739] CPU 0 Unable to handle kernel paging request at virtual 
address 004c, epc == 80064e4c, ra == 80066e30

[    0.920631] Oops[#1]:
[    0.922965] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.87 #0
[    0.929136] $ 0   :  0001 0040 0002
[    0.934511] $ 4   : 81438080 8140be2c  81408300
[    0.939887] $ 8   : 8140a000 1ff0 0001 8114af80
[    0.945263] $12   : 0400 8143bc80 8143bc80 
[    0.950638] $16   : 80ee1f40 0003 81438080 807b460c
[    0.956014] $20   : 0002 807a9880 806e9670 806e9648
[    0.961392] $24   : 0002 806549f8
[    0.966767] $28   : 807a2000 8140bde0 8082 80066e30
[    0.972143] Hi    : 0008
[    0.975101] Lo    : cccf
[    0.978082] epc   : 80064e4c __task_rq_lock+0x38/0xc0
[    0.983266] ra    : 80066e30 try_to_wake_up+0xb4/0x5a4
[    0.988541] Status: 10008f02 KERNEL EXL
[    0.992574] Cause : 0088 (ExcCode 02)
[    0.996695] BadVA : 004c
[    0.999652] PrId  : 0002a080 (Broadcom BMIPS4350)
[    1.004488] Modules linked in:
[    1.007633] Process swapper/0 (pid: 0, threadinfo=(ptrval), 
task=(ptrval), tls=)
[    1.015957] Stack : 81438000 0003  81438000 81438080 
0003  10008f00
[    1.024567] 8143852c 80066e30 0400 002e 0329 
  0001
[    1.033178] 0001    81422180 
82368cc4 10008f00 8140bf0c
[    1.041789] 003a 807a9880 806e9670 806e9648 8082 
80080920 80ee1f40 
[    1.050400] 80ee1f40 82368cc0 82368cc0 80080d90 81421a00 
  

[    1.059010] ...
[    1.061520] Call Trace:
[    1.064038] [<80064e4c>] __task_rq_lock+0x38/0xc0
[    1.068881] [<80066e30>] try_to_wake_up+0xb4/0x5a4
[    1.073831] [<80080920>] swake_up_locked+0x28/0x58
[    1.078734] [<80080d90>] complete+0x44/0x64
[    1.083065] [<8043b450>] brcmnand_irq+0xa4/0xac
[    1.087719] [<80090a3c>] __handle_irq_event_percpu+0x70/0x1b8
[    1.093607] [<80090c4c>] handle_irq_event+0x50/0xe8
[    1.098624] [<80094fbc>] handle_level_irq+0xf0/0x1fc
[    1.103732] [<80090118>] generic_handle_irq+0x44/0x5c
[    1.108946] [<80396b10>] bcm6345_periph_irq_handle+0x110/0x1c0
[    1.114932] [<80090118>] generic_handle_irq+0x44/0x5c
[    1.120152] [<8065521c>] do_IRQ+0x1c/0x2c
[    1.124254] [<80396fc4>] plat_irq_dispatch+0x60/0xd0
[    1.129371] [<80015bf0>] handle_int+0x150/0x15c
[    1.134015] [<80015a60>] __r4k_wait+0x20/0x40
[    1.138492]
[    1.140008] Code: 24140002  26101f40  8e420004 <8c42000c> 00021080 
02621021  8c51  02118821  0c19540e

[    1.150070]
[    1.151660] ---[ end trace 625caeee62f8fa21 ]---
[    1.156366] Kernel panic - not syncing: Fatal exception in interrupt
[    1.162890] [ cut here ]
[    1.167651] WARNING: CPU: 0 PI

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote:

Hi Hauke:

El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió:


Hi,

We would like to switch the bcm63xx target to kernel 5.10. Paul created
a pull request for that:
https://github.com/openwrt/openwrt/pull/4616

There is still a problem with Macronix NAND flash chips, see the
comments from the pull request.

Could someone please have a look into this problem.

Does this change in the upstream kernel help?
https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530


The patch together with:
https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03

They both apply cleanly without changes in current Openwrt, kernel
testing 5.10, But the kernel still fails to load, caused by
macronix_nand_block_protection_support .


Is there a log available somewhere that shows the boot failure with 
5.10? Have you been able to run a bisection somehow?


None of those patches should be relevant as the DSL SoCs do not use EDU, 
they use PIO. Now about this one:


lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html
--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe

[Florian Fainelli]

On 1/13/2022 9:46 AM, Oskari Lemmelä wrote:

Hi,

On 1/4/22 23:28, Sander Vanheule wrote:

Hi,

On Sun, 2021-12-26 at 20:41 +0200, Oskari Lemmela wrote:

RFC patchset because of following open questions:

---

[...]


POE driver is implemented as a kernel module. Every port is separate
hwmon device with same label as the DSA port.

[...]



Should this be implemented in Realtek POE switches as well?

I haven't created any userspace tools for ubus integration yet
Because I'm not sure if this is the right way to go.

The hwmon part should be upstremable. Only thing is two non-standard 
sysfs

controls (force_enable, port_state). They are also possible to implement
as debugfs files if they are not accepted by the upstream.


A short general comment, as this would be at least the fourth way to 
manage PoE devices in
OpenWrt (GPIO controlled, realtek poe tool, ubiquiti poe tool). So 
this is more related to
how OpenWrt could interface with PoE hardware in a more generic way, 
rather than this
specific implementation (and I'm certainly not asking you to rewrite 
anything, Oskari).


For controlling the outputs of PoE PSE ports, I had actually been 
thinking of using the
the regulator framework in some way. This could range from simple GPIO 
controlled PoE
ports (fixed-regulator), to actual PoE-controllers with current limits 
(PoE, PoE+...) and
overload detection. That way existing interfaces could be used to 
manage (regulator) and
monitor (regulator or hwmon) the outputs. I fear that adding custom 
hwmon interfaces for

every type of PoE PSE out there just won't scale very well.



I do not think the regulatory framework is the best for PoE control. It 
is more for displaying power dependencies and controlling power for 
power saving purposes.


The best option could be to extend the netlink ethtool interface to 
support PoE standard data. This is quite similar to what SFP support has 
today. Ethtool is used to read EEPROM / FEC statistics and hwmon to 
display monitoring data.


A GPIO controlled passive POE could only implement some parts of the 
ethtool netlink interface.


IMHO, passive POE should never have been introduced, but I understand 
that the price of a product is more important than safety.


Maybe getting feedback from the upstream Linux kernel maintainers would 
be a good way to move forward, assuming you would want these PoE drivers 
to land upstream as some point.


From a quick look it seems to me that these PoE controllers should 
actually be modeled by a combination of regulator (for control) + hwmon 
(for reporting), possibly linked from a single parent device.

--
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] gemini: Bring up DSA switches

[Florian Fainelli]

On 11/27/2019 7:27 AM, Linus Walleij wrote:
> On Wed, Nov 27, 2019 at 4:05 PM Petr Štetiar  wrote:
> 
>> what's the state of this? It's not clear from the discussion, thanks.
> 
> Sadly I'm as confused as you are. I'm scratching my head about
> what to do. I suspect the problem will only get bigger as more
> DSA switches appear in the Linux kernel.

It seems to me that we are still missing something critical for users
which is converting a switch configuration syntax, such as:

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 5t'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0 5t'

into an appropriate succession of iproute2 calls (possibly with a VLAN
aware bridge).

Is anyone working on bridging that gap at this point?
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches

[Florian Fainelli]

On 7/13/2019 4:04 AM, Linus Walleij wrote:
> On Fri, Jul 12, 2019 at 8:57 AM Hauke Mehrtens  wrote:
>> On 7/12/19 8:07 AM, Linus Walleij wrote:
> 
>>> + # These are all connected to eth1 thru VSC7385
>>> + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
>>
>> This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I
>> think you do not have to put eth1 into this bridge, it should be
>> sufficient to have all the lanX in it.
> 
> It is really puzzling to me too :(

drivers/net/dsa/vitesse-vsc73xx.c returns DSA_TAG_PROTO_NONE for the
tagging protocol, which means that the DSA slave devices are only
control devices they are not used by the data-path (which requires an
appropriate tagging protocol to allow differentiating the Ethernet
frames on a per-port basis). If you supported a different tagging
protocol, then you would not be able to enslave the DSA master device
(eth1) into the bridge, because that would conflict with the bridge's
rx_handler, see 8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e ("net: bridge:
reject DSA-enabled master netdevices as bridge members")

Your second sequence is more in line with what you should do, see the
recent documentation examples from Benedikt:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst

> 
> What I notice is that if I do this everything works fine and if eth1
> is not included it doesn't.
> 
> This sequence also works fine:
> ifconfig eth1 169.254.1.2 netmask 255.255.255.0 up
> ifconfig lan1 up
> ifconfig lan2 up
> ifconfig lan3 up
> ifconfig lan4 up
> 
> I think the reason is that the IP address is not assigned to
> eth1 (the CPU port towards the switch/DSA).
> 
> Maybe other DSA switches are better with this? My dmesg
> looks like this with eth1 included in the lan-facing interfaces:
> 
> [   52.704396] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [   53.046012] br-lan: port 1(eth1) entered blocking state
> [   53.170160] br-lan: port 1(eth1) entered disabled state
> [   53.253455] device eth1 entered promiscuous mode
> [   53.299150] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
> [   53.388545] vsc73xx spi0.0: enable port 0
> [   53.446029] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [   53.526483] br-lan: port 2(lan1) entered blocking state
> [   53.594789] br-lan: port 2(lan1) entered disabled state
> [   53.665816] device lan1 entered promiscuous mode
> [   53.728728] br-lan: port 1(eth1) entered blocking state
> [   53.760176] br-lan: port 1(eth1) entered forwarding state
> [   53.874449] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
> [   54.000353] vsc73xx spi0.0: enable port 1
> [   54.056099] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode
> [   54.142223] br-lan: port 3(lan2) entered blocking state
> [   54.214679] br-lan: port 3(lan2) entered disabled state
> [   54.266496] device lan2 entered promiscuous mode
> [   54.308593] vsc73xx spi0.0: enable port 2
> [   54.335298] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode
> [   54.377279] br-lan: port 4(lan3) entered blocking state
> [   54.97] br-lan: port 4(lan3) entered disabled state
> [   54.515791] device lan3 entered promiscuous mode
> [   54.588687] vsc73xx spi0.0: enable port 3
> [   54.646048] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode
> [   54.726991] br-lan: port 5(lan4) entered blocking state
> [   54.785910] vsc73xx spi0.0 lan1: Link is Up - 1Gbps/Full - flow control 
> rx/tx
> [   54.844478] br-lan: port 5(lan4) entered disabled state
> [   54.915911] device lan4 entered promiscuous mode
> [   54.976533] br-lan: port 2(lan1) entered blocking state
> [   55.007954] br-lan: port 2(lan1) entered forwarding state
> 
> After this I can ping the host:
> # ping 169.254.1.1
> PING 169.254.1.1 (169.254.1.1): 56 data bytes
> 64 bytes from 169.254.1.1: seq=0 ttl=64 time=2.049 ms
> 64 bytes from 169.254.1.1: seq=6 ttl=64 time=0.913 ms
> 64 bytes from 169.254.1.1: seq=25 ttl=64 time=1.268 ms
> And the host can ping the device:
> $ ping 169.254.1.2
> PING 169.254.1.2 (169.254.1.2) 56(84) bytes of data.
> 64 bytes from 169.254.1.2: icmp_seq=1 ttl=64 time=1.12 ms
> 64 bytes from 169.254.1.2: icmp_seq=2 ttl=64 time=0.582 ms
> 64 bytes from 169.254.1.2: icmp_seq=3 ttl=64 time=0.576 ms
> 64 bytes from 169.254.1.2: icmp_seq=4 ttl=64 time=0.654 ms
> 
> But if I remove eth1 from the LAN facing interfaces it looks like
> this:
> 
> [   52.433253] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [   52.769503] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [   52.925178] device eth1 entered promiscuous mode
> [   52.987672] vsc73xx spi0.0: enable port 0
> [   53.014460] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [   53.054754] br-lan: port 1(lan1) entered blocking state
> [   53.086323] br-lan: port 1(lan1) entered disabled state
> [   53.119857] device lan1 

Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge

[Florian Fainelli]

On 3/19/19 11:14 AM, Christian Lamparter wrote:
> Cc: Florian. I hope you don't mind.
> 
> On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
>> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
>> on an IPQ4019-based device, I can get basic connectivity either manually,
>> or with a "standard" UCI definition of the "lan" bridge[2].
>>
>> (I'm aware that this is not "production" code and expect "challenges".)
>>
>> However, I'm puzzled as how to manage VLANs and tagging, even using
>> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>>
>> It appears that the qca8k driver doesn't support `bridge` VLAN-related
>> commands. Checking the source doesn't show implementation of the
>> `port_vlan_*` functions described in the Linux DSA doc[3].
>>
>>
>> Setting aside my suspicion that a port-based VLAN approach seems
>> unlikely to be able to handle trunking of VLANs, I tried adding a
>> sub-interface of one of the otherwise unused phy interfaces (renamed
>> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
> 
> At first glance, I think you are running into what's described in section
> "Design limitations" of DSA in [3]:"
> - inability to configure specific VLAN IDs / trunking VLANs between switches
>   when using a cascaded setup". (Sadly there isn't a link to a possible
> patch or discussion so I don't know the state of it).
> 
> However...
>  
>> This unfortunately results in a kernel panic when trying to add to the
>> bridge.
>>
>> Bridge br-lan initially set up with "default" UCI config[2]
>>
>> Full serial log available[4]
>>
>>ip link add link wan0 name wan0.100 type vlan id 100
>>ip link set wan0 up
>>ip link set wan0.100 up
>>ip link set wan0.100 master br-lan
>>(kernel panics)
>>
>>
>> I've traced this to passing of a null pointer to br_vlan_enabled()
>> with the diagnostic patch shown in [5]
> 
> Yes, this shouldn't crash. I think Florian has already a patch for this
> upstream [6].

Right, this specific commit omitted two key details which were that:

- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0

This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")

> 
> commit 061f6a505ac33659eab007731c0f6374df39ab55
> Author: Florian Fainelli 
> Date:   Wed Feb 20 14:35:39 2019 -0800
> 
> net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
> 
> That should help with the NPEs since it now checks whenever the
> bridge_dev is valid or not.
>  
> [3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
> [6] <https://patchwork.ozlabs.org/patch/1026172/>
> 
> 


-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 RFCv2] net: dsa: Add bindings for Realtek SMI DSAs

[Florian Fainelli]

On 05/28/2018 10:47 AM, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
> 
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---

> +
> + mdio {
> + compatible = "realtek,smi-mdio", "dsa-mdio";

You should drop the "dsa-mdio" compatible string here since it both non
documented and not matched either.

Other than that, this looks great, with that fixed:

Reviewed-by: Florian Fainelli 
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] net: dsa: Add Vitesse VSC73xx DSA router driver

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> This adds a DSA driver for:
> 
> Vitesse VSC7385 SparX-G5 5-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
> Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
> 
> These switches have a built-in 8051 CPU and can download and execute
> firmware in this CPU. They can also be configured to use an external
> CPU handling the switch in a memory-mapped manner by connecting to
> that external CPU's memory bus.
> 
> This driver (currently) only takes control of the switch chip over
> SPI and configures it to route packages around when connected to a
> CPU port. The chip has embedded PHYs and VLAN support so we model it
> using DSA as a best fit so we can easily add VLAN support and maybe
> later also exploit the internal frame header to get more direct
> control over the switch.

Yes having the internal frame header working would be really great,
DSA_TAG_PROTO_NONE is really difficult to use without knowing all the
DSA details which reminds that we should have the following action items:

- document how DSA_TAG_PROTO_NONE behave differently with respect to
bridges/VLAN configuration and the DSA master device

- possibly introduce DSA_TAG_PROTO_8021Q which would automatically
partition ports by allocating one VLAN ID per-port (e.g: from top to
bottom) that would effectively offer the same features/paradigms as what
a proper header would offer (Port separation, if nothing else) and it
could be made seemingly automatic from within DSA

- get rid of b53's DSA_TAG_PROTO_NONE

> 
> The four built-in GPIO lines are exposed using a standard GPIO chip.

What are those typically used for out of curiosity? Is this to connect
to an EEPROM?

> 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/net/dsa/Kconfig   |   12 +
>  drivers/net/dsa/Makefile  |1 +
>  drivers/net/dsa/vitesse-vsc73xx.c | 1362 +
>  3 files changed, 1375 insertions(+)
>  create mode 100644 drivers/net/dsa/vitesse-vsc73xx.c
> 
> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index 2b81b97e994f..2f6207b969e3 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -76,4 +76,16 @@ config NET_DSA_SMSC_LAN9303_MDIO
> Enable access functions if the SMSC/Microchip LAN9303 is configured
> for MDIO managed mode.
>  
> +config NET_DSA_VITESSE_VSC73XX
> + tristate "Vitesse VSC7385/7388/7395/7398 support"
> + depends on OF && SPI
> + depends on NET_DSA
> + select FIXED_PHY
> + select VITESSE_PHY
> + select NET_DSA_TAG_TRAILER

You advertise DSA_TAG_PROTO_NONE, so that appears to be unnecessary right?

[snip]
> +/**
> + * struct vsc73xx - VSC73xx state container
> + */
> +struct vsc73xx {
> + struct device   *dev;
> + struct gpio_desc*reset;
> + struct spi_device   *spi;
> + struct dsa_switch   *ds;
> + struct gpio_chipgc;
> + u16 chipid;
> + boolis_vsc7385;
> + boolis_vsc7388;
> + boolis_vsc7395;
> + boolis_vsc7398;

How about having an u16/u32 chip_id instead?

> + u8  addr[ETH_ALEN];
> + struct mutexlock; /* Protects SPI traffic */
> +};

[snip]

> +static enum dsa_tag_protocol vsc73xx_get_tag_protocol(struct dsa_switch *ds,
> +   int port)
> +{
> + /* The switch internally uses a 8 byte header with length,
> +  * source port, tag, LPA and priority. This is supposedly
> +  * only accessible when operating the switch using the internal
> +  * CPU or with an external CPU mapping the device in, but not
> +  * when operating the switch over SPI and putting frames in/out
> +  * on port 6 (the CPU port). So far we must assume that we
> +  * cannot access the tag. (See "Internal frame header" section
> +  * 3.9.1 in the manual.)

I would be really good if we could get this to work even in SPI with the
CPU controlling the switch, I cannot really think of why the 8051 would
have to be involved, because having the 8051 means either the switch is
entirely standalone and runs off an EEPROM (which is additional cost on
your BOM), or the host, through SPI can entirely take over.

Is the datasheet public somehow?

> +  */
> + return DSA_TAG_PROTO_NONE;
> +}

[snip]

> +static void vsc73xx_adjust_link(struct dsa_switch *ds, int port,
> + struct phy_device *phydev)
> +{
> + struct vsc73xx *vsc = ds->priv;
> + u32 val;

No is_pseudo_fixed_link() check, you really have to do all of this for
each front-panel port? That is really bad if that is the case... most
switches with front-panel built-in PHYs are at the very least capable of

Re: [OpenWrt-Devel] [PATCH 2/3] net: phy: vitesse: Add support for VSC73xx

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> The VSC7385, VSC7388, VSC7395 and VSC7398 are integrated
> switch/router chips for 5+1 or 8-port switches/routers. When
> managed directly by Linux using DSA we need to do a special
> set-up "dance" on the PHY. Unfortunately these sequences
> switches the PHY to undocumented pages named 2a30 and 52b6
> and does undocumented things. It is described by these opaque
> sequences also in the reference manual. This is a best
> effort to integrate it anyways.
> 
> Signed-off-by: Linus Walleij 

Probably as good as it can get given the information you have access to.
Maybe the guys at Mircochip could help, adding them.

Reviewed-by: Florian Fainelli 

Just one nit below:

> ---
>  drivers/net/phy/vitesse.c | 162 ++
>  1 file changed, 162 insertions(+)
> 
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
> index d9dd8fbfffc7..526c71ae7d96 100644
> --- a/drivers/net/phy/vitesse.c
> +++ b/drivers/net/phy/vitesse.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Is that needed?
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] net: dsa: Add DT bindings for Vitesse VSC73xx switches

[Florian Fainelli]

On 06/14/2018 05:35 AM, Linus Walleij wrote:
> This adds the device tree bindings for the Vitesse VSC73xx
> switches. We also add the vendor name for Vitesse.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../bindings/net/dsa/vitesse,vsc73xx.txt  | 81 +++
>  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
>  2 files changed, 82 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt 
> b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> new file mode 100644
> index ..474cdba5fa37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
> @@ -0,0 +1,81 @@
> +Vitess VSC73xx Switches
> +===
> +
> +This defines device tree bindings for the Vitesse VSC73xx switch chips.
> +The Vitesse company has been acquired by Microsemi and Microsemi in turn
> +acquired by Microchip but retains this vendor branding.
> +
> +The currently supported switch chips are:
> +Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
> +Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
> +
> +The device tree node is an SPI device so it must reside inside a SPI bus
> +device tree node, see spi/spi-bus.txt
> +
> +Required properties:
> +
> +- compatible: must be exactly one of:
> + "vitesse,vsc7385"
> + "vitesse,vsc7388"
> + "vitesse,vsc7395"
> + "vitesse,vsc7398"
> +- gpio-controller: indicates that this switch is also a GPIO controller,
> +  see gpio/

Missing reference here?

> +- #gpio-cells: this must be set to <2> and indicates that we are a twocell
> +  GPIO controller.

Should you also reference the standard binding here to interpret what
those two cells mean?

Other than that:

Reviewed-by: Florian Fainelli 

> +
> +Optional properties:
> +
> +- reset-gpios: a handle to a GPIO line that can issue reset of the chip.
> +  It should be tagged as active low.
> +
> +Required subnodes:
> +
> +See net/dsa/dsa.txt for a list of additional required and optional properties
> +and subnodes of DSA switches.
> +
> +Examples:
> +
> +switch@0 {
> + compatible = "vitesse,vsc7395";
> + reg = <0>;
> + /* Specified for 2.5 MHz or below */
> + spi-max-frequency = <250>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan1";
> + };
> + port@1 {
> + reg = <1>;
> + label = "lan2";
> + };
> + port@2 {
> + reg = <2>;
> + label = "lan3";
> + };
> + port@3 {
> + reg = <3>;
> + label = "lan4";
> + };
> + vsc: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <>;
> + phy-mode = "rgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index b5f978a4cac6..e8473894700c 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -385,6 +385,7 @@ v3V3 Semiconductor
>  varisciteVariscite Ltd.
>  via  VIA Technologies, Inc.
>  virtio   Virtual I/O Device Specification, developed by the OASIS 
> consortium
> +vitesse  Vitesse Semiconductor Corporation
>  vivante  Vivante Corporation
>  vocore VoCore Studio
>  voipac   Voipac Technologies s.r.o.
> 

-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add spi nand driver, the source code from

[Florian Fainelli]

On 05/17/2018 06:14 PM, Luochongjun wrote:
> ---
>  .../patches-4.9/491-mtd-spi-nand-driver.patch  | 2785 
> 
>  1 file changed, 2785 insertions(+)
>  create mode 100644 
> target/linux/ar71xx/patches-4.9/491-mtd-spi-nand-driver.patch

Instead of combining all upstream patches that got recently submitted on
the MTD mailing-list into one large patch, you should provide a patch
that includes all the necessary patches to bring the recent SPI-NAND
framework into the OpenWrt kernel tree. This makes it much easier to
drop dependencies and/or backport fixes as we move from either 4.9 to
another 4.9 stable release, or from 4.9 to say 4.14 for instance.

See how bcm53xx does it for instance.

Thank you!
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] kernel: rtl8366-smi: add Realtek switch management via mii-bus

[Florian Fainelli]

On 04/03/2018 10:13 AM, Сергей Василюгин wrote:
> Current version of rtl8366-smi module support Realtek switch
> managment via two gpio lines only. This patch add Realtek switch
> management via mii_bus. For my board Tp-link Archer C2 v1 (Mediatek
> SoC mt7620a based) dts-file configuration looks like:
> 
>   rtl8367rb {
>   compatible = "realtek,rtl8367b", "rtl8367b";
>   realtek,extif1 = <1 0 1 1 1 1 1 1 2>;
>   mii-bus = <>;

The switch node should be moved under the mdio controller node below,
parent/child relationships imply the control bus.

>   };
> 
>  {
>   status = "okay";
>   mtd-mac-address = < 0xf100>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins _pins _pins>;
> 
>   port@5 {
>   status = "okay";
>   mediatek,fixed-link = <1000 1 1 1>;
>   phy-mode = "rgmii";
>   };
> 
>   mdio0: mdio-bus {
>   status = "okay";
>   };
> };
> 
> Realtek rtl8367rb switch is ok.
> Other Realtek switches and archs are untested but must work too.
> 
> Version 2: add mii_bus mutex_lock
> 
> Signed-off-by: Serge Vasilugin 
> --
> 

[snip]

> @@ -1416,7 +1520,24 @@ int rtl8366_smi_probe_of(struct platform_device *pdev, 
> struct rtl8366_smi *smi)
>  {
>   int sck = of_get_named_gpio(pdev->dev.of_node, "gpio-sck", 0);
>   int sda = of_get_named_gpio(pdev->dev.of_node, "gpio-sda", 0);
> + struct device_node *np = pdev->dev.of_node;;
> + struct device_node *mdio_node = NULL;
> +
> + mdio_node = of_parse_phandle(np, "mii-bus", 0);
> + if (!mdio_node) {
> + dev_err(>dev, "cannot find mdio node phandle");
> + goto try_gpio;
> + }

You should have two entry points for your driver, and have shared code,
one entry point is a gpio/platform_driver and the other one is a
mdio_device/driver. They would both call into the same code that does
the register read/write code, but how they are probed should be different.

See drivers/net/dsa/b53/ for an example of a driver that can deal with
multiple control buses.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] What is the best approach to building the OpenWRT with external Kernel?

[Florian Fainelli]

On 03/07/2018 07:20 AM, Jorge Pereira wrote:
> Hi,
> 
> I have some specific board delivered with a Kernel 3.18.x that have some
> specific changes that definitely I cannot run using another kernel by
> now. So, what is the best approach to building the OpenWRT using this
> specific Kernel path?

There is an option for that:

make menuconfig
-> Advanced configuration options (for developers)  
- > Use external kernel tree

> 
> ps: The Kernel used by OpenWRT/LEDE has special changes for the project?

Yes it does, see target/linux/generic/patches*/

> 
> Thanks in advance.
> --
> Jorge Pereira
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update

[Florian Fainelli]

On January 17, 2018 11:41:01 AM PST, Zoltan HERPAI <wigy...@uid0.hu> wrote:
>Hi,
>
>This series will add support for microcode update on x86 targets,
>in light of the recent security issues.
>
>While other distributions use an early initramfs approach to update 
>the microcode as early as possible, in OpenWrt the earliest place
>where we can do this is preinit.
>
>The Intel microcode package is using the source package by Debian,
>the AMD microcode package is downloaded from the linux-firmware 
>git repository.
>
>This was tested on various Intel-based desktops with ancient BIOSes.
>
>Once the series is merged into trunk, this could/should be backported
>into 17.01 and 15.05 without too much hassle.

FWIW:

Reviewed-by: Florian Fainelli <f.faine...@gmail.com>

-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH RFC] mac80211: Don't check for platform files with external kernel trees

[Florian Fainelli]

When building with an external kernel tree, do not check the different
platform files since this is almost guaranteed they are going to differ.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 package/kernel/mac80211/Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 385bea4d2f5d..1740c956fe9f 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -1751,11 +1751,16 @@ ifneq 
($(CONFIG_PACKAGE_kmod-cfg80211)$(CONFIG_PACKAGE_kmod-lib80211),)
  endef
 endif
 
-define Build/Configure
+ifeq ($(strip $(CONFIG_EXTERNAL_KERNEL_TREE)),"")
+ define Build/Configure
cmp $(PKG_BUILD_DIR)/include/linux/ath9k_platform.h 
$(LINUX_DIR)/include/linux/ath9k_platform.h
cmp $(PKG_BUILD_DIR)/include/linux/ath5k_platform.h 
$(LINUX_DIR)/include/linux/ath5k_platform.h
cmp $(PKG_BUILD_DIR)/include/linux/rt2x00_platform.h 
$(LINUX_DIR)/include/linux/rt2x00_platform.h
-endef
+  endef
+else
+  define Build/Configure
+  endef
+endif
 
 define Build/Compile
$(SH_FUNC) var2file "$(call shvar,mac80211_config)" 
$(PKG_BUILD_DIR)/.config
-- 
2.14.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Florian Fainelli]

On 10/27/2017 02:34 AM, p...@oranjevos.nl wrote:
> Dear Imre,
> 
> On the info for the version of the patch: my error, must have overlooked the 
> included version info, it is indeed included.
> 
> About the use of openwrt email addresses in the SOB:
> This has been discussed before, and the arguments against using an openwrt 
> mail address as a personal address haven't vanished.
> The address in the SOB is meant to identify a contributor, most likely a 
> natural person, not some entity of the openwrt project. Usage of an openwrt 
> mail address suggests that the person using that address has another position 
> in the project than those that use mail addresses not within the openwrt.org 
> domain, which does not go well with LEDE rules.
> 
> IIRC, during discussions on the remerge, the following compromis was reached: 
> usage of personal openwrt addresses wasn't ruled out completely, but only in 
> passive sense, as a means to keep receiving mail on the address and active 
> usage for personal business is not allowed. John remerge proposal v3 states 
> clearly:
> - mail addresses may under no conditions be used for any personal business, 
> consultancy, applying for jobs, ... purposes

Did you purposely omit the next bullet item that says?

- any mail sent from an openwrt.org account needs to adhere the
trademark policy and should only be used for FOSS purposes

Link:
http://lists.infradead.org/pipermail/lede-adm/2017-May/000517.html

> 
> As a mail address in a SOB is a personal address, is meant to be that, using 
> an openwrt address in a SOB goes directly against the agreed on rules, and 
> certainly against the spirit of the LEDE rules that have proven to be 
> successful in making the project getting traction and commitment.

LEDE project rule #10 does only stipulate that new email addresses will
not be given away on the premises of and privacy and equality:

https://lede-project.org/rules

10. The project will not offer email accounts under its project domain
for privacy and equality reasons.


That sentence is written with the future tense, and therefore does not
try to impose or specify anything with respect to emails given before
(so in the past).

Therefore, my reading of the LEDE project rules and the remerge proposal
makes me so inclined as to think that Imre is not in direct violation of
the LEDE project rules regarding the use of an @openwrt.org email
contributor for FOSS perspectives.

Quite frankly, if the goal is just to give Zoltan and Imre a hard time
and nitpick on everything possible just to delay (purposely or not) the
remerge, then you are doing a great job at it, but this goes against
rule #12.

> Paul
> 
> 
>  
> 
>> Op 26 okt. 2017, om 18:32 heeft Imre Kaloz  het volgende 
>> geschreven:
>>
>> Hi Paul,
>>
>> On 2017-10-26 18:16, p...@oranjevos.nl wrote:
>>> Please, could you add some info on what has changed with the new version of 
>>> the patch ?
>>> And, it would be appreciated when the SOB would not use an openwrt.org mail 
>>> address (assuming Imre has another suitable mail available).
>>>
>>> Paul
>>>
>>>
 Op 26 okt. 2017, om 17:41 heeft Zoltan HERPAI 
  het volgende geschreven:

 Given that we've decided to sail under the same flag for
 the benefit of the whole community, and acknowledge the
 achievements of the LEDE project, let's start the final
 steps of the merge.

 The git and other sources are untouched until the infra merge.

 v2: - dismiss bugtracker and forum change
- update uhttpd cert gen
- update banner
- update busybox NSLOOKUP patch

 Signed-off-by: Zoltan HERPAI 
 

 Signed-off-by: Imre Kaloz 
 



>>
>> Please find the changes listed in the description, but left it in above as 
>> well. As for using another email address, I won't use my personal one for 
>> this as I don't use this for that, simply as that. This is fully following 
>> what the merge agreement that has been voted for and got accepted defined.
>>
>>
>> Best,
>> Imre
>>
> 
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt -> LEDE git tree merge

[Florian Fainelli]

On 10/22/2017 11:46 AM, Hauke Mehrtens wrote:
> Hi,
> 
> I am working on merging the missing commits from the OpenWrt git
> repository into the LEDE repository.
> 
> Here is a list of all non merge commits from the OpenWrt git repository
> and their corresponding LEDE commit IDs:
> https://github.com/hauke/openwrt-lede-merge/blob/master/commits.csv
> 
> I only looked into the non merge commits and assumed that commits with
> the same title are the same, if this is wrong please point me to some
> place where this causes problems.
> 
> I used this script to generate the csv table:
> https://github.com/hauke/openwrt-lede-merge/blob/master/openwrt-merge.py
> 
> The bigger topics I see are:
> * addition of SoCFPGA target with kernel 4.4 support
>  * Will someone port this to kernel 4.9 or provide me with hardware so I
>can try to port this and test it?
> * There are some commits without a Signed-off-by line, I will contact
>   the authors.
> * The realview target was removed from LEDE, but it got an update to
>   kernel 4.4 in OpenWrt, how do we want to handle this? Does anyone need
>   the realview target?

armvirt is now a superset of realview so this can be dropped.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

On October 14, 2017 2:59:22 PM PDT, Linus Walleij <linus.wall...@linaro.org> 
wrote:
>On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli
><f.faine...@gmail.com> wrote:
>
>> The most deployed switch device drivers have been converted to DSA
>> already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
>> tree, and now we are getting new submissions from Michrochip to
>support
>> their pretty large KSZ series. Converting from swconfig to DSA is
>> actually quite simple, but like anything requires time and testing,
>and
>> access to hardware and ideally datasheet.
>
>Hm, I have a Realtek RB8366RB in this router on my desk.
>
>I guess that means I should just take the old switchdev-based
>SMI-driver and convert it to DSA.
>
>I bet I can do that :D

Yes, it really should not be too hard. The OpenWrt/LEDE driver had mostly the 
same semantics as what is needed for being a proper DSA driver. You should of 
course start simple: get basic switching working, then add statistics, VLAN, 
FDB, etc. OpenWrt/LEDE models switches as PHY device objects which would not 
work upstream so you should have the driver be probed as a MDIO/SPI/I2C (see 
b53 for example) and set up fixed-link properties between the CPU and the 
switch.

>
>Well, I will try. Because it's blocking me to work on the Gemini
>ethernet driver.

Well usually the boot loader may leave the switch in a good enough state that 
you can work on the CPU controller mostly independently from dealing with the 
switch. This is not universally true, and a properly working bootloader should 
actually quiesce/reset both blocks prior to OS control.

Don't hesitate if you have questions.

Cheers.

-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

Hi,

On 10/14/2017 04:09 AM, Linus Walleij wrote:
> Top posting and resending since net...@vger.kernel.org
> is the right mail address for this. Mea culpa.
> 
> Linus Walleij
> 
> On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij
>  wrote:
>> On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu
>>  wrote:
>>
>>> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs
>>> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages
>>> switch objects discovered on the fsl-mc bus. A description of the driver
>>> can be found in the associated README file.
>>>
>>> The patchset consists of:
>>> * A set of libraries containing APIs for configuring and controlling
>>>   Management Complex (MC) switch objects
>>> * The DPAA2 Ethernet Switch driver
>>> * Patch adding ethtool support
>>
>> So it appears that ethernet switches is a class of device that need their own
>> subsystem in Linux, before this driver can move out of staging.

FWIW, I think the biggest dependency on this driver is not a switch
driver model because that exists but it's actually the specific bus (MC
AFAICT) that it depends on. More on the Ethernet switch device model below.

We do actually have a pretty good model for Ethernet switches now, in
fact, we got several options:

- Distributed Switching Architecture (DSA) should be used when the
CPU/management Ethernet controller is a traditional Ethernet MAC that is
either internally or externally attached to a switch. This usually comes
with the Ethernet switch capable of providing per-packet metadata (tag)
to indicate to the management interface why the packet is transmitted.
For older/dumber switches, using no management tag, but separating with
802.1Q tags is definitively an option that brings in the same
requirements for DSA. DSA does make use of switchdev to get notified
from the networking stack when there is an opportunity to offload
objects: VLAN, FDB, MDB, etc. DSA is both a device driver model and a
switch device abstraction model.

- switchdev should be used when the management interface is tightly
coupled with the switching hardware, such that, per-packet information
is obtained via DMA/PIO descriptors for instance. switchdev is not a
device driver model so the switch driver is responsible for creating its
own net_device instances and feeding the appropriate netdev_ops,
ethtool_ops and switchdev_ops, this is what is being done here, and this
is also perfectly fine.

>>
>> I ran into the problem in OpenWRT that has these out-of-tree patches for
>> off-chip ethernet switches, conveniently placed under net/phy:
>> https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy
>>
>> These are some 12 different ethernet switches. It is used in more or
>> less every home router out there.

The most deployed switch device drivers have been converted to DSA
already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
tree, and now we are getting new submissions from Michrochip to support
their pretty large KSZ series. Converting from swconfig to DSA is
actually quite simple, but like anything requires time and testing, and
access to hardware and ideally datasheet.

>>
>> It's not really working to have all of this out-of-tree, there must have been
>> discussions about the requirements for a proper ethernet switch subsystem.
>>
>> I'm not a good net developers, just a grumpy user having to deal with all
>> of this out-of-tree code that's not helpful with changing interfaces like
>> device tree and so on.
>>
>> Can you people who worked on this over the years pit in with your
>> requirements for an ethernet switch subsystem so we can house these
>> drivers in a proper way?
>>
>> What we need AFAICT:
>>
>> - Consensus on userspace ABI
>> - Consensus on ethtool extenstions
>> - Consensus on where in drivers/net this goes
>>
>> You can kick me for not knowing what I'm talking about and how complex the
>> problem is now.

Kicking you would not be fair, but you are about 3 years late ;) We had
such discussions in 2014 after a failed attempt at submitting swconfig
as a possible model. 3 years later we have 1 major switchdev driver:
mlxsw and quite a few active DSA drivers. The paradigms that apply are:

- normal Linux tools keep working: bridge, iproute2, ethtool
- every user-visible port has a corresponding network device, in order
to meet the first paradigm
- for every other part of the switch that does not have a net_device
representor, devlink can/should be used.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] MV88E6060 switch

[Florian Fainelli]

On Jul 23, 2017 11:28, "Nerijus Baliūnas" 
wrote:

2017-07-21 19:48, Nerijus Baliūnas via Lede-dev rašė:

> How do I configure vlan? Here I changed eth0 to eth0.1:
>
> config interface 'lan'
> option type 'bridge'
>option ifname 'eth0.1'
>option proto 'static'
>option ipaddr '192.168.1.1'
>option netmask '255.255.255.0'
>option ip6assign '60'
>

I tried
config 'switch' 'eth0'
   option 'enable'  '1'
   option 'enable_vlan' '1'
   option 'reset'   '1'

config 'switch_vlan'
   option 'vlan'   '1'
   option 'device' 'eth0'
   option 'ports'  '1 2 3 4 5t'

config 'switch_vlan'
   option 'vlan'   '2'
   option 'device' 'eth0'
   option 'ports'  '0 5t'

Does not work. Do I need to have swconfig installed in order to
get the switch working? Because by default it is not installed.


Yes, it is necessary with this switch driver to have swconfig installed,
otherwise nothing would push CLEAN configurations to the mv88e6060 switch.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V3

[Florian Fainelli]

On 05/28/2017 11:56 PM, John Crispin wrote:
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the comments
> people made into it, if anything is missing let me know. Please remeber
> that post remerge anything can be voted on, so cluttering the proposal
> with many details will delay the remerge even more.
> 
> Ideally we manage to vote during this week.

ACK from me.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Hackers] openwrt and lede - remerge proposal V3

[Florian Fainelli]

Le 05/29/17 à 00:03, John Crispin a écrit :
> (resend, this time as plain text)
> 
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the comments
> people made into it, if anything is missing let me know. Please remeber
> that post remerge anything can be voted on, so cluttering the proposal
> with many details will delay the remerge even more.
> 
> Ideally we manage to vote during this week.

Ack on everything, let's get this moving!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V2

[Florian Fainelli]

On 05/22/2017 02:02 AM, Rafał Miłecki wrote:
> On 05/22/2017 09:40 AM, John Crispin wrote:
>> *) branding
>> - the owrt side sees no option of using the lede brand
>> - a (minor) majority voted for openwrt as a name over lede whilst most
>> people said they did not care
>> - as the last vote had a 100% ACK for a remerge using the owrt brand
>> is the only feasible option
> 
> Since the project is going to be known/accessible under OpenWrt name now, I
> want also mbm and Kaloz to share #openwrt and #openwrt-devel privileges.
> 
> There were many times op was needed but mbm/Kaloz weren't around.
> 
> I was refused/ignored multiple times when asking for that, so I wanted to
> bring it as this point to be clear. Is that OK for you guys?

Yes that's fine, while your channel operator status is worked on, if
there is something specific you can private message me on IRC and I get
be op on these two channels for a little bit to do what is necessary.

Thanks!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS

[Florian Fainelli]

Hello,

On 05/20/2017 09:12 AM, Richard Weinberger wrote:
> Hi!
> 
> These days I had an interesting discussion with Christoph about overlayfs and
> its burden. The main use-case of overlayfs in combination with UBIFS is 
> having a
> squashfs as lower and UBIFS as upper directory. Such that all changes to the
> read-only squashfs go into UBIFS. Upon a factory reset all files within the
> UBIFS will be removed  and the merged directory is clean again. Christoph 
> argued
> that such a functionality  could be achieved without overlayfs if the 
> filesystem
> supported something like pre-seeded  files or directories. This would lower
> memory pressure and complexity.

As you may know, OpenWrt/LEDE have been using this scheme for many years
now (before it was named overlayfs, this was called mini fanout overlay
~10 yrs ago) with squashfs + jffs2 before on P-NOR flashes. There are
still devices like those that benefit from squashfs(ro)+jffs2(rw), so
while bringing a similar functionality using UBIFS exclusively would be
interesting, it would still make Linux distribution want to support a
more generic scheme which is using overlayfs as well.

> 
> Today I had a thought about this and I'm pretty sure we can implement this in
> UBIFS with not too much effort. The basic idea is marking files or whole
> directories as seed upon mkfs.ubifs time.
> If these files will be changed at run-time, the original contents will stay on
> the medium and at any time these files can be reverted back to their seed 
> state.
> This includes file contents, attributes and extended attributes. I can think 
> of
> an UBIFS specific IOCTL to put files into seed state and to revert them again.
> 
> Since UBIFS is already a pure copy-on-write filesystem, all we have to do is
> teaching the index tree about seeds. We could add a flag to the UBIFS key 
> which
> indicates that the node behind this key is seeded.
> i.e. file "foo" is seeded and the corresponding inode number is 0x1234,
> then every key of every UBIFS node that belongs to that file will wear the new
> flag UBIFS_SEED_KEY.
> ubifs_ino_node: 0x1234 | UBIFS_INO_KEY | UBIFS_SEED_KEY
> ubifs_data_node: 0x1234 |  | UBIFS_DATA_KEY | UBIFS_SEED_KEY
> 
> The inode itself will have a flag which denotes whether this file is seeded 
> and
> whether some modifications have happened. This will allow us to lookup 
> directly
> in the index tree with UBIFS_SEED_KEY set or no. Otherwise we'd have to do two
> lookups every time.
> 
> If a seeded node faces a modification it will stay referenced in the index 
> tree
> and a copy without UBIFS_SEED_KEY is made. Upon next lookup the new node will
> be used automatically. Reverting to the original state means purging all nodes
> that don't have the UBIFS_SEED_KEY flag.
> 
> There are corner cases to consider, mostly for lookup of data nodes.
> Currently a missing data node denotes a hole in a file.
> With seeded files a missing data node can also mean that we need to fall back
> to a UBIFS_SEED_KEY lookup.
> 
> Storing UBIFS_SEED_KEY itself into the UBIFS key is also not trivial since
> almost all bits of the 32bit tuple are in use. But I'm sure we find some way
> to encode it.
> 
> Another thing to consider are seeded directory entries. This requires us to
> implement our own whiteout mechanism. But this could also be re-used for
> overlayfs whiteouts.
> 
> That said, I consider this feature as doable but not trivial.
> Artem, Adrian, you designed UBIFS, what do you think?
> Maybe I missed some major show-stopper. :)
> 
> Thanks,
> //richard
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal

[Florian Fainelli]

On 05/08/2017 06:19 AM, John Crispin wrote:
> Hi,
> 
> Felix, Imre and myself had 2 calls last week lasting several hours and
> discussed the following proposal of conditions for a remerge that we
> would like to propose and have people vote on.
> 
> *) branding
> - the owrt side sees no option of using the lede brand
> 
> - a (minor) majority voted for openwrt as a name over lede whilst most
> people said they did not care
> 
> - as the last vote had a 100% ACK for a remerge using the owrt brand is
> the only feasible option
> 
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in
> various locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how to
> proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers so
> that the openwrt domain also points at them
> 
> *) SPI
> - TBD post remerge
> 
> *) github
> - stop pushing to lede-project organisation
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue
> tracker
> - go through the open openwrt and lede PRs, pickup whats useful and
> close the rest, asking people to repost (things wont be rebasable anyhow)
> - close the lede PR tracker
> - keep the lede organisation in its current state so that forked trees
> dont get obsoleted
> 
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current
> openwrt landing page
> - point openwrt.org at the lede landing page
> 
> *) trac
> - trac is already readonly, keep content so that search engines can
> still find the it
> - edit the trac html templates, adding a note pointing at the
> bug.openwrt.org instance
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
> anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up
> their accounts
> - mail addresses may under no conditions be used for any personal
> business, consultancy, applying for jobs, ... purposes
> 
> - any mail sent from an openwrt.org account needs to adhere the
> trademark policy and should only be used for FOSS purposes
> 
> 
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them both
> around
> - start a separate discussion regarding these post remerge
> 
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
> 
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot
> and pick up the useful bits (zoltan has done some prior work on this
> already)
> 
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - announce the switch to the infradead serves, asking people to
> unsubscribe if they have privacy issues with this
> - import the user DB from the current openwrt and lede ML into the 2 new
> mailing lists
> - find out if we can redirect/auto-reply  the existing lists to the new
> ones
> 
> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy
> 
> *) timeline
> - refine / vote / agree on the proposal withing the next 2 week
> - work on the action items in the 4 weeks after that

All of this sounds good me, and thanks for taking the time to talk to
each other and come to an agreement.

How can we help?
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge

[Florian Fainelli]

On 05/08/2017 02:16 PM, Tom Psyborg wrote:
> Is it ever going to be added so this endless spam can end?

It's the first iteration of the (S)ATA patchset, and if you are not
interested, just ignore the thread.

Linus is doing everyone a great favor here by making sure that this
platform gets properly supported upstream such that the cost of
maintaining in OpenWrt/LEDE/anywhere else comes down to almost zero.

Almost forgot: please don't top post.

> 
> 
> On 8 May 2017 at 22:33, Linus Walleij  > wrote:
> 
> On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
> > wrote:
> > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote:
> 
> >> +  Mode 3: ata0 master <-> sata0
> >> +  ata1 slave  <-> sata1
> >
> > ata0 slave?
> >
> >> +  ata1 master and slave interfaces brought out
> >> +   on IDE pads
> 
> Of course. Thanks for reading close, much appreciated!
> 
> Yours,
> Linus Walleij
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
> 
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT and multiplatform

[Florian Fainelli]

On 01/24/2017 12:47 PM, Linus Walleij wrote:
> Hans, Florian et al: does any of you have a copy of the kernel source
> dump(s) from Teltonika, Raidsonic or Wiliboard?
> 
> Would be nice to have the stuff that vendors are using.
> 
> On Tue, Jan 24, 2017 at 6:24 PM, Hans Ulli Kroll
>  wrote:
> 
>> AFAICR
>> This is a dual GMAC !
>>
>> They are two different base address for each GMAC and one shared
>> base address for both of them.
>> This is all in one address space which remaps the driver.
>>
>> And to make it worse two interrupt lines, one of them is also shared.
>>
>> Any ideas to "convert" this into DT ??
>> Because I think it's impossible to split both GMAC interfaces ??
> 
> Sounds odd.  Yeah hardware.h lists this:
> 
> #define GEMINI_TOE_BASE 0x6000
> #define GEMINI_GMAC0_BASE   0x6000A000
> #define GEMINI_GMAC1_BASE   0x6000E000
> 
> I guess one approach is to make a driver handling all of it in one,
> let it ioremap all regions and support one or two GMACs on the same
> TOE. More complex solutions is to share the TOE using
> syscons regmap mechanism but it looks cumbersome.
> 
> {
>compatible = "cortina,genesis-gmac-ethernet";
>reg = <0x6000 0xa000>, <0x6000a000 0x4000>, <0x6000e000 0x4000>;
>interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <2 IRQ_TYPE_LEVEL_HIGH>;
> }
> 
> Or something like that?

I'd recommend looking at how mv643xx_eth does it, there are shared and
individual portions of the register set in there, with concepts of
"ports" which result in network device instances.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT and multiplatform

[Florian Fainelli]

On 01/22/2017 04:15 AM, Linus Walleij wrote:
> I got a Gemini platform from Florian Fainelli over at OpenWRT
> some time back. I finally got around to "future-proofing" the
> platform, which was the idea when he paintakingly sent the box
> over to me.

I would have happily tested that series ;) thanks a lot for making it
happen!

> 
> This is the result: Gemini is converted to device tree and
> multiplatform, all existing drivers are rewritten into their
> proper subsystems and the old board-specific and machine-specific
> code is deleted.
> 
> I would ideally like the irqchip, clocksource, gpio, rtc and MTD
> patches (and bindings) to simply be merged into the respective
> subsystem and the remaining ARM/ARM SoC patches funnelled to the
> ARM SoC tree in a single pull request, lock stock and barrel,
> with changes to board files and DTS additions in one go. But I
> guess I could also switch the DTS files to a separate branch.
> 
> The OpenWRT tree still have a whole bunch of significant out-of
> tree drivers:
> 
> - Watchdog
> - GMAC (ethernet)

Been wondering about the GMAC driver a little bit, and it does not
appear to be neither a Synopsys/Designware core (although not 100%
sure), nor the ftgmac100 either.

This submission does appear to be in a good shape:
https://lwn.net/Articles/437889/

> - FOT2G USB EHCI host
> - PATA
> - PCI
> 
> But I do not see any big obstacle in porting these over to be
> probed from the device tree and upstreamed on top of this patch
> series. I might tinker with it if I get time.
> 
> The out-of-tree code can be found here:
> http://git.openwrt.org/?p=openwrt.git;a=tree;f=target/linux/gemini;h=b74c3d8f0100e2ac8a4d71c4d23c082db2993e63;hb=HEAD
> 
> Linus Walleij (22):
>   ARM: gemini: convert to MULTI_IRQ_HANDLER
>   irqchip: DT bindings for Cortina Gemini irqchip
>   irqchip: add a driver for Cortina Gemini
>   clocksource: add DT bindings for Cortina Gemini
>   clocksource: Add driver for the Cortina Gemini
>   gpio: add DT bindings for Cortina Gemini GPIO
>   gpio: Add a driver for Cortina Systems Gemini GPIO
>   rtc: Add device tree probing to the Gemini driver
>   mtd: add DT bindings for the Cortina Systems Gemini Flash
>   mtd: physmap_of: add a hook for Gemini flash probing
>   ARM: dts: add top-level DT bindings for Cortina Gemini
>   ARM: gemini: DT for the Cortina Gemini SoC platforms
>   ARM: dts: add device tree for Gemini SoC and SQ201
>   ARM: dts: add a devicetree for Raidsonic NAS IB-4220-B
>   ARM: dts: add a devicetree for Teltonika RUT1xx
>   ARM: dts: add a devicetree for Wiliboard WBD-111
>   ARM: dts: add a devicetree for Wiliboard WBD-222
>   ARM: gemini: delete all boardfiles
>   ARM: gemini: switch to sparse IRQs
>   ARM: gemini: select ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR
>   ARM: gemini: convert to ARMv4 multiplatform
>   ARM: configs: add a gemini defconfig
> 
>  Documentation/devicetree/bindings/arm/gemini.txt   |  58 +
>  .../bindings/gpio/cortina,gemini-gpio.txt  |  24 ++
>  .../cortina,gemini-interrupt-controller.txt|  22 ++
>  .../bindings/mtd/cortina,gemini-flash.txt  |  24 ++
>  .../devicetree/bindings/rtc/cortina,gemini.txt |  14 ++
>  .../bindings/timer/cortina,gemini-timer.txt|  22 ++
>  arch/arm/Kconfig   |   9 -
>  arch/arm/boot/dts/Makefile |   6 +
>  arch/arm/boot/dts/gemini-nas4220b.dts  |  68 +
>  arch/arm/boot/dts/gemini-rut1xx.dts|  63 +
>  arch/arm/boot/dts/gemini-sq201.dts |  94 +++
>  arch/arm/boot/dts/gemini-wbd111.dts| 101 
>  arch/arm/boot/dts/gemini-wbd222.dts| 101 
>  arch/arm/boot/dts/gemini.dtsi  |  96 +++
>  arch/arm/configs/gemini_defconfig  |  63 +
>  arch/arm/mach-gemini/Kconfig   |  52 +---
>  arch/arm/mach-gemini/Makefile  |  15 +-
>  arch/arm/mach-gemini/Makefile.boot |   9 -
>  arch/arm/mach-gemini/board-dt.c|  62 +
>  arch/arm/mach-gemini/board-nas4220b.c  | 106 
>  arch/arm/mach-gemini/board-rut1xx.c|  92 ---
>  arch/arm/mach-gemini/board-wbd111.c| 133 --
>  arch/arm/mach-gemini/board-wbd222.c| 133 --
>  arch/arm/mach-gemini/common.h  |  33 ---
>  arch/arm/mach-gemini/devices.c | 118 -
>  arch/arm/mach-gemini/gpio.c| 231 -
>  arch/arm/mach-gemini/idle.c|  31 ---
>  arch/arm/mach-gemini/include/mach/entry-macro.S|  33 ---
&

Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE

[Florian Fainelli]

On 12/21/2016 07:30 PM, Val Kulkov wrote:
> 
> On 21 December 2016 at 17:01, Florian Fainelli <f.faine...@gmail.com
> <mailto:f.faine...@gmail.com>> wrote:
> 
> On 12/21/2016 01:46 PM, Alberto Bursi wrote:
> > On 12/21/2016 09:42 PM, Dave Taht wrote:
> >> On Wed, Dec 21, 2016 at 12:29 PM, David Lang <da...@lang.hm
> <mailto:da...@lang.hm>> wrote:
> >>> On Wed, 21 Dec 2016, Kathy Giori wrote:
> >>>
> >>>> From a PR perspective, I strongly suggest keeping the term
> OpenWrt as
> >>>> part of the branding of the project moving forward. It can just be
> >>>> cosmetic (web site, etc.) but the name has so much history, and
> >>>> positive connotation, that you don't want to lose that brand
> attached
> >>>> to the development moving forward.
> >>>
> >>>
> >>> I agree, I think this is an obvious choice to make. OpenWRT has
> a lot of
> >>> name recognition, it would be foolish to throw that away.
> >>
> >> Just to take the other side for rhetorical purposes, a purpose of a
> >> re-branding exercise is to show a change in the "product" or
> >> organisation behind it. OpenWrt is widely known... as a bleeding
> edge,
> >> sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
> >> and Tomato get a lot more press for some reason. So do things like
> >> Yocto. If lede were to succeed in meeting its other goals,
> coherently,
> >> preserving "lede" and moving forward as a separate project does make
> >> sense.
> >>
> >
> > +1 for this. OpenWRT brand isn't 100% positive recognition, it has
> some
> > downsides too. Many people (I know and/or have seen around the
> internet)
> > were discouraged from contributing or using it due to the
> weaknesses of
> > OpenWRT project.
> >
> > I like more the LEDE branding for this reason. It conveys that it is
> > significantly different, possibly for the better, from OpenWRT
> project.
> >
> > But I don't have enough information to say for sure what is the better
> > brand to keep, so this is just my opinion.
> 
> Keeping or not the OpenWrt, or LEDE name is obviously part of the things
> that need to be agreed upon before proceeding with a merger. If not
> about the "brand", "recognition" or other more subjective criteria,
> OpenWrt is a trademark, so that needs to be factored in for the
> decision, in particular if there is any legal activity going on.
> 
> 
> A trademark exists to protect its owner's rights. The "OpenWRT"
> trademark is owned by SPI:
> http://tmsearch.uspto.gov/bin/showfield?f=doc=4805:r3y94m.2.1
> 
> If there is no unauthorised use of a trademark, there is no legal issue.
> In other words, if the merged project continues as "LEDE", there is no
> legal issue in respect of the "OpenWRT" trademark.
> 
> SPI also has the right to oppose registration or use of a trademark that
> appears confusingly similar to "OpenWRT". This seems to be a purely
> hypothetical situation, but here it is: if OpenWRT and LEDE do not merge
> and for some reason the LEDE folks decide to rename LEDE to FreeWRT or
> alike, SPI may have a legal claim against the use of the "FreeWRT"
> trademark that some people may see as confusingly similar to OpenWRT.
> 
> My main objection to "LEDE" is that I have no idea how to pronounce this
> name correctly. I suspect that many English speakers will find
> themselves equally confused about how to pronounce "LEDE". Is it like in
> "LEAD the way", or like in "LEAD, a heavy metal", or like "LE DE"? While
> the core LEDE community might know how to pronounce the name correctly,
> try explaining it to the world outside. For this reason, "OpenWRT" is a
> better choice imho.
> 
> However, I also agree with Dave, Alberto and Stefan that a name change
> may be a really smart way to communicate the fresh start of the project,
> a reboot, especially if the new name rides on the popularity of
> "OpenWRT". It could be for example "OpenLD" (LD for Linux Device) or
> "LibreWRT". Of course this is all conditional on the merge of OpenWRT
> and LEDE. If the projects do not merge, the OpenWRT folks and SPI may
> have a claim against the use of OpenLD or LibreWRT or alike.
> 
> By the way, there is a pending application at the USPTO for the
> registration of "LEDE" trademark for use in some software or websites:
> http://tmsearch.uspto.gov/bin/showfield?f=doc=4805:8zgvq2.8.1

The point was that OpenWrt is already registered and managed by SPI, so
we may as well keep using it, and that is just what I meant to say here,
nothing more.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE

[Florian Fainelli]

On 12/21/2016 01:46 PM, Alberto Bursi wrote:
> On 12/21/2016 09:42 PM, Dave Taht wrote:
>> On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:
>>> On Wed, 21 Dec 2016, Kathy Giori wrote:
>>>
 From a PR perspective, I strongly suggest keeping the term OpenWrt as
 part of the branding of the project moving forward. It can just be
 cosmetic (web site, etc.) but the name has so much history, and
 positive connotation, that you don't want to lose that brand attached
 to the development moving forward.
>>>
>>>
>>> I agree, I think this is an obvious choice to make. OpenWRT has a lot of
>>> name recognition, it would be foolish to throw that away.
>>
>> Just to take the other side for rhetorical purposes, a purpose of a
>> re-branding exercise is to show a change in the "product" or
>> organisation behind it. OpenWrt is widely known... as a bleeding edge,
>> sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
>> and Tomato get a lot more press for some reason. So do things like
>> Yocto. If lede were to succeed in meeting its other goals, coherently,
>> preserving "lede" and moving forward as a separate project does make
>> sense.
>>
> 
> +1 for this. OpenWRT brand isn't 100% positive recognition, it has some 
> downsides too. Many people (I know and/or have seen around the internet) 
> were discouraged from contributing or using it due to the weaknesses of 
> OpenWRT project.
> 
> I like more the LEDE branding for this reason. It conveys that it is 
> significantly different, possibly for the better, from OpenWRT project.
> 
> But I don't have enough information to say for sure what is the better 
> brand to keep, so this is just my opinion.

Keeping or not the OpenWrt, or LEDE name is obviously part of the things
that need to be agreed upon before proceeding with a merger. If not
about the "brand", "recognition" or other more subjective criteria,
OpenWrt is a trademark, so that needs to be factored in for the
decision, in particular if there is any legal activity going on.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] mac80211: Make wlcore platform-independent

[Florian Fainelli]

On 11/10/2016 04:28 AM, Alexey Brodkin wrote:
> TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
> that could be found on different existing boards.
> 
> But it is possible to get those modules as a separate
> component and use with existing boards as well as
> new boards equipped with either module may appear so we
> remove dependency on OMAP instead we add dependency on MMC
> because this Wi-Fi module uses SDIO interface.
> 
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Jo-Philipp Wich <j...@mein.io>
> Cc: Felix Fietkau <n...@nbd.name>
> Cc: Imre Kaloz <ka...@openwrt.org>

Reviewed-by: Florian Fainelli <f.faine...@gmail.com>

Makes sense!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] CVE-2016-5195 backport to linux-3.18.36 for Chaos Calmer

[Florian Fainelli]

On 10/21/2016 07:43 AM, revelstone wrote:
> Here is a backport for Chaos Calmer of commit
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619]19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
> that patches
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5195]CVE-2016-5195
> 
> /DL
> 
> Signed-off-by: dl12345 

While this is appreciated, why not just wait for the stable tree to get
updated and update to the next stable 3.18 (and others)?
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] boot-wrapper-aarch64.git repository missing/inaccessible; cannot build arm64 targets

[Florian Fainelli]

On 09/22/2016 02:38 PM, Alexander Duff wrote:
> Hello,
> 
> The quick version: a repository (boot-wrapper-aarch64.git) required for
> the default build of arm64 OpenWrt targets (default configuration) on
> the latest version of trunk seems to have disappeared from the Internet,
> and I'm unsure who to notify or how to proceed.  Furthermore, I can't
> seem to find anyone else reporting this issue or even talking about it
> and I can't understand why this isn't being reported anywhere, making me
> paranoid that I somehow messed up (which has been known to happen) or
> missed some announcement.

How about we use this copy:

https://github.com/artagnon/boot-wrapper-aarch64

or this one:

https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/

or even better, create a profile for the Foundation v8 simulator, for
which this boot wrapper is necessary, if you are using qemu, there is no
need for that.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns.  Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
> 
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?

Can you submit an official patch for this? Thanks a lot!

> 
> 
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
>  }
>  
>  list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
>  }
>  
>  # for each file print a line in following format
> 
> Thanks,
> Michal
> 


-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns.  Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
> 
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?

This patch works for me:

Tested-by: Florian Fainelli <f.faine...@gmail.com>

Kind of surprising that this has not showed up before, but maybe people
don't really go through the same steps while re-configuring/re-building
their kernels

Thanks Michal!

> 
> 
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
>  }
>  
>  list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
>  }
>  
>  # for each file print a line in following format
> 
> Thanks,
> Michal
> 


-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?

[Florian Fainelli]

Hi,

I have a root filesystem embedding filenames that look like these:

/lib/data/:

these are essentially files that can be matched against an USB
vendor/product id in an easy way.

Now, the fun part is that this is only a problem when doing the
following (using OpenWrt/LEDE as a build system):

1:
- set CONFIG_INITRAMFS_SOURCE=""
- build kernel modules
- build my user-space tools
- build the kernel image
- reconfigure the kernel to now use an initramfs
- build the kernel w/ initramfs

and then back to step 1 with the kernel build, would I hit this error:

usr/Makefile:64: *** multiple target patterns.  Stop.

which comes from usr/.initramfs_data.cpio.d containing these files
without escaping:

deps_initramfs := ./scripts/gen_initramfs_list.sh \
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib
\
...

/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan/19d2:0063
\

Which sorts of make sense here because the file name contains a ":"
which is not escaped, so GNU Make tries to interpret it.

Now the part that does not quite make sense to me is why this file is
even relevant here considering that the first thing we do is set
CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.

Any clues what could be wrong here? I am happy to provide any build
drops you may need to reproduce that.

Thanks!
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add ARC platforms to platforms wiki

[Florian Fainelli]

On 07/21/2016 10:45 AM, Alexey Brodkin wrote:
> Hello,
> 
> I'm wondering if there's a chance to add information about ARC
> platforms in the Wiki here https://dev.openwrt.org/wiki/platforms?

Done

> 
> I think something like this will work
> ==
> Target name   Platform   Architecture Endianness  
> Developer(s)Known
> Issues/Notes
> --
> arc770  Synopsys DesignWare ARC 770D   ARC  little
>   abrodkinarc770
> archs38 Synopsys DesignWare ARC HS38   ARC  little
>   abrodkinarchs38
> ==
> 
> Regards,
> Alexey
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH ubus] cmake: Fix find_library for ubusd and examples/server

[Florian Fainelli]

Both ubusd and cli TARGET_LINK_LIBRARIES reference ${json} which is
obtained via find_library(), but since the find_library() is searched
after the TARGET_LINK_LIBRARIES for ubusd, ubusd always gets an empty
${json} variable.

examples/server also links against libjson-c, but we were not setting
TARGET_LINK_LIBRARIES accordingly, so do that too with ${json} appended.

This was causing linking errors for ubusd and then examples/server using
an external toolchain (stbgcc-4.8-1.x).

Fixes: 9f52d1769b762 ("cli: use the new json-c library name")
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 CMakeLists.txt  | 3 ++-
 examples/CMakeLists.txt | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 70a0de6536d9..7123096a0f93 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -32,10 +32,11 @@ INCLUDE_DIRECTORIES(${ubox_include_dir})
 ADD_LIBRARY(ubus SHARED libubus.c libubus-io.c libubus-obj.c libubus-sub.c 
libubus-req.c libubus-acl.c)
 TARGET_LINK_LIBRARIES(ubus ${ubox_library})
 
+find_library(json NAMES json-c json)
+
 ADD_EXECUTABLE(ubusd ubusd.c ubusd_id.c ubusd_obj.c ubusd_proto.c 
ubusd_event.c ubusd_acl.c ubusd_monitor.c)
 TARGET_LINK_LIBRARIES(ubusd ${ubox_library} ${blob_library} ${json})
 
-find_library(json NAMES json-c json)
 ADD_EXECUTABLE(cli cli.c)
 SET_TARGET_PROPERTIES(cli PROPERTIES OUTPUT_NAME ubus)
 TARGET_LINK_LIBRARIES(cli ubus ${ubox_library} ${blob_library} ${json})
diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
index 006dac42a27c..81f999752950 100644
--- a/examples/CMakeLists.txt
+++ b/examples/CMakeLists.txt
@@ -5,7 +5,7 @@ INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/..)
 
 IF (BUILD_EXAMPLES)
ADD_EXECUTABLE(server server.c count.c)
-   TARGET_LINK_LIBRARIES(server ubus ${ubox_library} ${blob_library})
+   TARGET_LINK_LIBRARIES(server ubus ${ubox_library} ${blob_library} 
${json})
 
ADD_EXECUTABLE(client client.c count.c)
TARGET_LINK_LIBRARIES(client ubus ${ubox_library})
-- 
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFD] Future

[Florian Fainelli]

On 06/29/2016 01:31 PM, Hauke Mehrtens wrote:
> On 06/29/2016 04:55 PM, Imre Kaloz wrote:
>> All,
>>
>> There was an opportunity for a mini-meetup between Felix, Luka and
>> myself in Paris. We openly discussed the recent events. We've concluded
>> that it would be beneficial to members of both OpenWrt and LEDE to have
>> a face to face meeting in the near future.
>>
>> On that note, we would like to ask all project members to consider this
>> invitation as a way to move forward and resolve our issues.
> 
> I am against a Face-2-Face meeting. I think not everybody can travel to
> some other country for some 100$ on a short notice. For people that do
> OpenWrt/LEDE for a living and have their own company or get support form
> a company this is probably not problem, but some people have other jobs
> beside OpenWrt/LEDE and have to take some days off and then pay the
> money for traveling. The purpose of LEDE was to focus more on the community.
> 
> I am for a telephone conference like google hangout or this fuze meeting
> prpl uses, to make it easy for everybody to participate.

Pretty much on the same boat as you here, and on the west coast of the
US, so not very easy to travel in a short notice. If you actually meet
F2F and have the ability to make people join via Audio or Video that
would be terrific.

Thanks
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC 0/4] Add support for Raspberry Pi 3

[Florian Fainelli]

On Feb 29, 2016 12:08 PM, "Álvaro Fernández Rojas" 
wrote:
>
> This adds untested support for Raspberry Pi 3.
> I will be able to test it when I get my RPi 3 ;D.

Will give it a shot tomorrow morning, thanks for quickly sending the
patches out.

>
> In the meantime if anyone already has a RPi 3 and wants to test it here's
the image:
>
http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img
>
http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz
>
> Álvaro Fernández Rojas (4):
>   include: add Cortex-A53 CPU_TYPE
>   brcm2708-gpu-fw: update to latest version
>   brcm2708: update linux 4.4 patches to latest version
>   brcm2708: add Raspberry Pi 3 support
>
>  include/target.mk  |   1 +
>  package/kernel/brcm2708-gpu-fw/Makefile|   8 +-
>  target/linux/brcm2708/Makefile |   8 +-
>  target/linux/brcm2708/bcm2708/config-4.4   |   4 +-
>  target/linux/brcm2708/bcm2709/config-4.4   |   4 +-
>  target/linux/brcm2708/bcm2710/config-4.4   | 390 
>  .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |  14 +
>  target/linux/brcm2708/bcm2710/target.mk|  12 +
>  target/linux/brcm2708/image/Makefile   |  12 +-
>  target/linux/brcm2708/modules.mk   |  19 +
>  ...0001-smsx95xx-fix-crimes-against-truesize.patch |   4 +-
>  ...02-smsc95xx-Disable-turbo-mode-by-default.patch |   4 +-
>  ...around-for-issue-where-dirty-page-count-g.patch |   4 +-
>  .../0004-BCM2835_DT-Fix-I2S-register-map.patch |   4 +-
>  ...-Prevent-spurious-interrupts-and-trap-the.patch |   4 +-
>  .../0006-irqchip-bcm2835-Add-FIQ-support.patch |   4 +-
>  ...-irqchip-irq-bcm2835-Add-2836-FIQ-support.patch |   4 +-
>  ...erial-8250-Don-t-crash-when-nr_uarts-is-0.patch |   4 +-
>  ...2835-Set-base-to-0-give-expected-gpio-num.patch |   4 +-
>  ...2835-Fix-interrupt-handling-for-GPIOs-28-.patch |   4 +-
>  ...2835-Only-request-the-interrupts-listed-i.patch |   4 +-
>  ...cm2835-Support-pin-groups-other-than-7-11.patch |   4 +-
>  ...RM-bcm2835-Set-Serial-number-and-Revision.patch |   4 +-
>  ...-get-base-address-for-DMA-from-devicetree.patch |   4 +-
>  ...-add-24bit-support-update-bclk_ratio-to-m.patch |   4 +-
>  ...s-setup-clock-only-if-CPU-is-clock-master.patch |   4 +-
>  ...835-i2s-Eliminate-debugfs-directory-error.patch |   4 +-
>  .../0018-bcm2835-i2s-Register-PCM-device.patch |   4 +-
>  ...i2s-Enable-MMAP-support-via-a-DT-property.patch |   4 +-
>  ...0-dmaengine-bcm2835-Add-slave-dma-support.patch |   4 +-
>  ...ine-bcm2835-set-residue_granularity-field.patch |   4 +-
>  ...cm2835-Load-driver-early-and-support-lega.patch |   4 +-
>  ...-dma-Fix-dreq-not-set-for-slave-transfers.patch |   4 +-
>  ...-Limit-cyclic-transfers-on-lite-channels-.patch |   4 +-
>  .../0025-bcm2835-Add-support-for-uart1.patch   |   4 +-
>  ...irmware-bcm2835-Add-missing-property-tags.patch |   4 +-
>  .../0027-Main-bcm2708-bcm2709-linux-port.patch |   4 +-
>  ...-squash-include-ARCH_BCM2708-ARCH_BCM2709.patch |   4 +-
>  .../patches-4.4/0029-Add-dwc_otg-driver.patch  |   4 +-
>  .../0030-bcm2708-framebuffer-driver.patch  |   4 +-
>  .../0031-dmaengine-Add-support-for-BCM2708.patch   |   4 +-
>  ...-parameter-to-mmc-multi_io_quirk-callback.patch |   4 +-
>  .../0033-MMC-added-alternative-MMC-driver.patch|   4 +-
>  ...835-sdhost-driver-and-an-overlay-to-enabl.patch |   4 +-
>  ...ma-Add-vc_cma-driver-to-enable-use-of-CMA.patch |   4 +-
>  .../0036-bcm2708-alsa-sound-driver.patch   |   4 +-
>  .../patches-4.4/0037-bcm2708-vchiq-driver.patch|   4 +-
>  .../0038-vc_mem-Add-vc_mem-driver.patch|   4 +-
>  ...deoCore-shared-memory-service-for-BCM2835.patch |   4 +-
>  ...omem-device-for-rootless-user-GPIO-access.patch |   4 +-
>  .../brcm2708/patches-4.4/0041-Add-SMI-driver.patch |   4 +-
>  .../patches-4.4/0042-Add-SMI-NAND-driver.patch |   4 +-
>  ...3-lirc-added-support-for-RaspberryPi-GPIO.patch |   4 +-
>  .../patches-4.4/0044-Add-cpufreq-driver.patch  |   4 +-
>  ...-thermal-driver-for-reporting-core-temper.patch |   4 +-
>  .../0046-Add-Chris-Boot-s-i2c-driver.patch |   4 +-
>  .../0047-char-broadcom-Add-vcio-module.patch   |   4 +-
>  ...048-firmware-bcm2835-Support-ARCH_BCM270x.patch |   4 +-
>  .../0049-bcm2835-add-v4l2-camera-device.patch  |   4 +-
>  ...-mkknlimg-and-knlinfo-scripts-from-tools-.patch |   4 +-
>  ...port-for-the-CONFIG_CMDLINE_EXTEND-option.patch |   4 +-
>  ...0052-BCM2708-Add-core-Device-Tree-support.patch |   4 +-
>  ...3-bcm2835-Match-with-BCM2708-Device-Trees.patch |   4 +-
>  .../0054-fbdev-add-FBIOCOPYAREA-ioctl.patch|   4 +-
>  ...up-console-framebuffer-imageblit-function.patch |   4 +-
>  ...9-Allow-mac-address-to-be-set-in-smsc95xx.patch |   4 +-
>  ...e-realtime-clock-1-wire-chip-DS1307-and-1.patch |   4 +-
>  

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

Le 10/02/2016 03:43, Petr Štetiar a écrit :
> Florian Fainelli <flor...@openwrt.org> [2016-02-09 19:57:22]:
> 
>> Le 09/02/2016 12:16, Petr Štetiar a écrit :
>>> Petr Štetiar <yn...@true.cz> [2016-02-09 21:04:14]:
>>>
>>>>>define Kernel/SetNfsCmdline
>>>>>   rm -f $(LINUX_DIR)/.config.prev
>>>>> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
>>>>> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>>>> $(LINUX_DIR)/.config
>>>>> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
>>>>> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
>>>>> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>>>> $(LINUX_DIR)/.config.set
>>>>> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>>>>>endef
>>>>
>>>> This cut/sed kung-fu needs some improvements:
>>>>
>>>>  * it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
>>>>  * how to handle custom cmdline options? For example I don't want to use 
>>>> this
>>>>hardcoded cmdline options, but use instead options provided by the 
>>>> bootloader
>>>
>>> Hm, now I'm wondering why is this macro needed at all. In case I'll set
>>> CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
>>> right?
>>>
>>> Florian, what's your use case for this SetNfsCmdline macro, that you need to
>>> hardcode kernel cmdline options? Thanks.
>>
>> Not all platforms get their command-line from the bootloader, or Device
>> Tree, or whatever, some do actually hardcode the command-line into the
>> kernel, that's what motivated this change in the first place.
> 
> I see, but I'm not sure how to handle it properly so it works for other use
> cases as well. Maybe adding something like CONFIG_CMDLINE_NFSROOT option, but
> this seems like overdesigning to me...
> 
> FYI, I'm using this base-files-nfs[1] package for development over NFS for a
> few years already, currently on i.MX6 with u-boot like this:
> 
>   setenv nfsroot /opt/devel/openwrt-master.git/bin/imx6/rootfs
>   setenv nfsargs root=/dev/nfs nfsroot=${serverip}:${nfsroot} 
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:apalis:eth0:off nfsrootdebug
> 
> I've noticed, that you've added something similar to the OpenWRT config
> directly:
> 
>buildroot: add options to build the kernel for NFS boot
> 
> And I've to test it yet - just wondering if we don't need to use similar
> approach to skip network initialization in case we boot over NFS as it's
> currently done in base-files-nfs[1] package.

We do need to skip network initialization yes, your commit looks good to
me, though we would want the default base-files to be nfsroot aware, not
a specific package (seems like you do this because of local
customization, that seems fine).

Grepping for "nfsroot" is not exactly failsafe AFAIR, since you can just
have "root=/dev/nfs" and that would be enough to trump the script. Even
better is probably to look at /proc/mounts.

> 
>> I am fine dropping this, since obviously; if you turn on the option you
>> know what you are doing, can you re-submit the patch you think is
>> appropriate?
> 
> From my point of view this macro SetNfsCmdline is not needed as you can
> specify CONFIG_CMDLINE directly in your config. If you think also, that we
> don't need this SetNfsCmdline macro, then you can just revert it yourself,
> right? :-)

I just reverted this in r48689
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

On 09/02/16 09:08, Petr Štetiar wrote:
> This patch fixes SetNfsCmdline macro which is currently relying on old
> kernel .config file, which has been replaced with intermediate
> .config.set file. It was leading to the following kernel build error:
> 
>   rm -f linux-4.4/.config.prev
>   mv linux-4.4/.config linux-4.4/.config.old
>   mv: cannot stat 'linux-4.4/.config': No such file or directory
> 
> Signed-off-by: Petr Štetiar 

Thanks for fixing this, seems like I missed that while rebasing and
pushing the patch out.

> ---
>  include/kernel-defaults.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> index 4b5de5b..44e3c27 100644
> --- a/include/kernel-defaults.mk
> +++ b/include/kernel-defaults.mk
> @@ -107,9 +107,9 @@ endef
>  ifeq ($(CONFIG_KERNEL_ROOT_NFS),y)
>define Kernel/SetNfsCmdline
>   rm -f $(LINUX_DIR)/.config.prev
> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
> $(LINUX_DIR)/.config
> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
> $(LINUX_DIR)/.config.set
> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>endef
>  else
>define Kernel/SetNfsCmdline
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set

[Florian Fainelli]

Le 09/02/2016 12:16, Petr Štetiar a écrit :
> Petr Štetiar  [2016-02-09 21:04:14]:
> 
>>>define Kernel/SetNfsCmdline
>>> rm -f $(LINUX_DIR)/.config.prev
>>> -   mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
>>> -   grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>> $(LINUX_DIR)/.config
>>> -   grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
>>> +   mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
>>> +   grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old > 
>>> $(LINUX_DIR)/.config.set
>>> +   grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed 
>>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs 
>>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>>>endef
>>
>> This cut/sed kung-fu needs some improvements:
>>
>>  * it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
>>  * how to handle custom cmdline options? For example I don't want to use this
>>hardcoded cmdline options, but use instead options provided by the 
>> bootloader
> 
> Hm, now I'm wondering why is this macro needed at all. In case I'll set
> CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
> right?
> 
> Florian, what's your use case for this SetNfsCmdline macro, that you need to
> hardcode kernel cmdline options? Thanks.

Not all platforms get their command-line from the bootloader, or Device
Tree, or whatever, some do actually hardcode the command-line into the
kernel, that's what motivated this change in the first place.

I am fine dropping this, since obviously; if you turn on the option you
know what you are doing, can you re-submit the patch you think is
appropriate?
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes

[Florian Fainelli]

On Jan 13, 2016 10:07 PM, "Stefan Rompf"  wrote:
>
> Hi,
>
> On Montag, 11. Januar 2016 23:45:39 Rafał Miłecki wrote:
>
> > > Any comments to this usage/syntax? It doesn't look too nice (this long
> > > quoted string as a value), but swconfig is strongly focused on simple
> > > values.
> >
> > One more RFC... anyone?
>
> I am not an OpenWRT core developer so I cannot comment on the niceness of
the
> interface ;-) The string does not allow to specify combinations like
autoneg
> on, advertise 10 and 1000, but not 100, but that would be a very esoteric
use
> case and it is about configuring a switch port and not an ethernet tester.
> IMHO for the normal use case, it allows to specify everything that is
needed.
>
> So for me it's all right.

Same here, does not really bother me to go through several command lines to
get the desired settings.

Thanks!
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space

[Florian Fainelli]

Le 16 déc. 2015 09:19, "Rafał Miłecki"  a écrit :
>
> So far we were sending link data as a string. It got some drawbacks:
> 1) Didn't allow writing clean user space apps reading link state. It was
>needed to do some screen scraping.
> 2) Forced whole PORT_LINK communication to be string based. Adding
>support for *setting* port link required passing string and parting
>it in the kernel space.
>
> Signed-off-by: Rafał Miłecki 
> ---

[snip]

(struct sk_buff *msg, struct genl_info *info, int attr,
> +  const struct switch_port_link *link)
> +{
> +   struct nlattr *p = NULL;
> +   int err = 0;
> +
> +   p = nla_nest_start(msg, attr);
> +   if (nla_put_u32(msg, SWITCH_LINK_LINK, link->link))

Boolean?

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_DUPLEX, link->duplex))

Same here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_ANEG, link->aneg))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_TX_FLOW, link->tx_flow))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_RX_FLOW, link->rx_flow))

And here too

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_SPEED, link->speed))
> +   goto nla_put_failure;
> +   if (link->eee & ADVERTISED_100baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL))
> +   goto nla_put_failure;
> +   }
> +   if (link->eee & ADVERTISED_1000baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL))
> +   goto nla_put_failure;
> +   }

As mentioned by Stefan, these should reflect that is is EEE-related.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] swconfig: support receiving SWITCH_TYPE_LINK from kernel

[Florian Fainelli]

Le 16 déc. 2015 09:21, "Rafał Miłecki"  a écrit :
>
> When using cli, print link state the same way kernel used to do it.
> This will allow kernel switching PORT_LINK from SWITCH_TYPE_STRING.
>
> Signed-off-by: Rafał Miłecki 
> ---
[snip]
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_100BASET_FULL ? "eee100 " : "",
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_1000BASET_FULL ? "eee1000 " : "",

EEE needs to be advertised, supported, and enabled on both link partners to
be used,what you are printing here is not very clear, as this is just the
advertised side

> +   link->aneg ? "auto" : "");
> +   else
> +   printf("port:%d link:down", val->port_vlan);
> +   break;
> default:
> printf("?unknown-type?");
> }
> diff --git a/package/network/config/swconfig/src/swlib.c
b/package/network/config/swconfig/src/swlib.c
> index 0dbace5..5239bf7 100644
> --- a/package/network/config/swconfig/src/swlib.c
> +++ b/package/network/config/swconfig/src/swlib.c
> @@ -51,6 +51,15 @@ static struct nla_policy
portmap_policy[SWITCH_PORTMAP_MAX] = {
> [SWITCH_PORTMAP_VIRT] = { .type = NLA_U32 },
>  };
>
> +static struct nla_policy link_policy[SWITCH_LINK_ATTR_MAX] = {
> +   [SWITCH_LINK_LINK] = { .type = NLA_U32 },
> +   [SWITCH_LINK_DUPLEX] = { .type = NLA_U32 },
> +   [SWITCH_LINK_ANEG] = { .type = NLA_U32 },
> +   [SWITCH_LINK_SPEED] = { .type = NLA_U32 },

As mentioned in patch 1, some of this fits in a boolean.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/7] kirkwood: revamp Linksys EA3500 & EA4500 support

[Florian Fainelli]

Le 06/11/2015 18:29, Claudio Leite a écrit :
> This patch set reworks support for the Linksys EA3500 and EA4500,
> integrating significant amounts of code from the WRT1900AC port.
> 
> Previously these two routers were supported by flashing from the
> bootloader and setting new boot commands. They can now be flashed
> from the Linksys factory firmware and upgraded from within OpenWrt.
> This also adds support for the Linksys dual-image firmware layout
> and recovery mechanism.

Tested on a freshly purchased Linksys EA4500 and this worked like a
charm, really happy to see that!

Tested-by: Florian Fainelli <flor...@openwrt.org>

> 
> These patches also transition from a single read-write UBIFS to
> squashfs on UBI + UBIFS overlay.
> 
> Claudio Leite (7):
>   kirkwood: enable squashfs-on-ubiblock support
>   kirkwood: match factory partitions on EA[34]500
>   kirkwood: find active Linksys root partition
>   kirkwood: generate factory images for Linksys EA[34]500
>   kirkwood: support Linksys boot counter on EA[34]500
>   kirkwood: support sysupgrade on Linksys EA[34]500
>   kirkwood: add diag LED on Linksys EA3500
> 
>  package/boot/uboot-envtools/files/kirkwood |  2 +-
>  package/system/mtd/src/Makefile|  1 +
>  target/linux/kirkwood/Makefile |  2 +-
>  target/linux/kirkwood/base-files/etc/diag.sh   |  3 +
>  .../base-files/etc/init.d/linksys_recovery | 20 ++
>  .../kirkwood/base-files/lib/upgrade/linksys.sh | 79 
> ++
>  .../kirkwood/base-files/lib/upgrade/platform.sh| 32 +
>  target/linux/kirkwood/config-3.18  |  3 +-
>  target/linux/kirkwood/config-4.3   |  3 +-
>  target/linux/kirkwood/image/Makefile   | 45 ++--
>  .../patches-3.18/100-find_active_root.patch| 61 +
>  .../linux/kirkwood/patches-3.18/160-ea4500.patch   | 36 +++---
>  .../linux/kirkwood/patches-3.18/170-ea3500.patch   | 39 ---
>  .../patches-4.3/100-find_active_root.patch | 61 +
>  target/linux/kirkwood/patches-4.3/140-ea4500.patch | 36 +++---
>  target/linux/kirkwood/patches-4.3/150-ea3500.patch | 39 ---
>  16 files changed, 416 insertions(+), 46 deletions(-)
>  create mode 100755 
> target/linux/kirkwood/base-files/etc/init.d/linksys_recovery
>  create mode 100644 target/linux/kirkwood/base-files/lib/upgrade/linksys.sh
>  create mode 100644 target/linux/kirkwood/base-files/lib/upgrade/platform.sh
>  create mode 100644 
> target/linux/kirkwood/patches-3.18/100-find_active_root.patch
>  create mode 100644 
> target/linux/kirkwood/patches-4.3/100-find_active_root.patch
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] update config.guess & config.sub

[Florian Fainelli]

On 02/11/15 11:01, Kathy Giori wrote:
> On Mon, Nov 2, 2015 at 9:40 AM, Alexey Brodkin
> <alexey.brod...@synopsys.com> wrote:
>> Hi Felix,
>>
>> On Thu, 2015-07-30 at 11:43 +0300, Alexey Brodkin wrote:
>>> These are from today's master branch of:
>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
>>>
>>> In particular it adds support for ARC architecture plus some more
>>> improvements and fixes.
>>>
>>> This patch is built-tested against NetGear WNDR3800.
>>>
>>> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
>>> Cc: Florian Fainelli <flor...@openwrt.org>
>>> Cc: Imre Kaloz <ka...@openwrt.org>
>>> ---
>>>  scripts/config.guess | 378 
>>> +++
>>>  scripts/config.sub   | 150 
>>>  2 files changed, 238 insertions(+), 290 deletions(-)
>>
>> I'm wondering if there're any comments on this one.
>> Otherwise please consider applying.
>>
>> This patch is a prerequisite for ARC port submission I'm going to send out
>> shortly.
> 
> Alexey,
> 
> Is there a particular reason that this architecture must be submitted
> to OpenWrt under the terms GPL v3+? I would prefer that OpenWrt stick
> to GPL v2 in order to maintain better compatibility with the Linux
> kernel (kernel.org). The kernel is primarily GPL v2 licensed (or
> something FreeBSD-like which is more, not less, permissive). The
> OpenWrt distro has only a few GPL v3 package exceptions, such as
> samba.

This is a quick jump to invalid conclusions, the changes that Alexey is
submitting are to files under scripts/* which are only used during the
build process in this case, and there are no GPLv3 components being
included in the firmware image per-se.

These specific files are used by autotools and friends to detect the
architecture/machine we cross-compile for, and as such as a prerequisite
for supporting an ARC toolchain.

As such, the changes are completely fine, and have no bearing to the
resulting firmware image.

> 
> The OpenWrt core team are doing a good job building a better
> industry-community relationship for OpenWrt, which I think can be a
> win-win for overall project improvement (brings in more developer
> resources, much like kernel development depends on industry
> developers). Introducing more GPL v3 packages makes it problematic for
> certain industry partners to be able to fully collaborate.

Although I do share the same feeling, I think the justification is way
off, GPLv3 does not prevent anybody from contributing, it may just hurt
your distribution model, which is something entirely different.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 0/5] malta: changes for a better testing environment

[Florian Fainelli]

Le 30/10/2015 20:05, Yousong Zhou a écrit :
> The series is a refreshed version of a previous mixed one in September [1].
> 
> With many kind advices from linux-mips, the kernel patch was merged in 
> upstream
> since release 4.3-rc5.  It was run-tested with 3.18 kernel and only
> compile-tested with 4.0 and 4.1.

They have already been applied, but FWIW:

Reviewed-by: Florian Fainelli <flor...@openwrt.org>

Thanks

> 
> [1] 
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/thread.html#35515
> 
> v2 <- v1
> 
>   - Instead of setting the device type explicitly to router, just drop the
> definition and use the default
>   - Make eth0 the default ifname for wan interface and eth1 if exists the 
> lan
> interface
> 
> Yousong Zhou (5):
>   generic: fix unrecognized opcode wsbh when building for MIPS16.
>   target.mk: add optimization flags for MIPS 24Kc.
>   malta: set CPU_TYPE:=24kc.
>   malta: use as a default type device
>   malta: make eth0 the wan interface by default
> 
>  include/target.mk  |1 +
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  ...gnore-__arch_swab-16-32-64-when-using-MIP.patch |   58 
> 
>  target/linux/malta/Makefile|3 +-
>  .../malta/base-files/etc/uci-defaults/02-network   |5 +-
>  6 files changed, 180 insertions(+), 3 deletions(-)
>  create mode 100644 
> target/linux/generic/patches-3.18/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
>  create mode 100644 
> target/linux/generic/patches-4.0/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
>  create mode 100644 
> target/linux/generic/patches-4.1/133-MIPS-UAPI-Ignore-__arch_swab-16-32-64-when-using-MIP.patch
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 5/5] malta: use "static" proto for lan interface

[Florian Fainelli]

Le 28/10/2015 19:32, Yousong Zhou a écrit :
> On 29 October 2015 at 00:19, Florian Fainelli <flor...@openwrt.org> wrote:
>> On Oct 28, 2015 5:56 AM, "Yousong Zhou" <yszhou4t...@gmail.com> wrote:
>>>
>>> This is almost the default config of OpenWrt targets (currently even
>>> those sunxi boards with only one ethernet interface use static IP
>>> address for its lan interface).
>>
>> And this is intend intended, because Malta is primarily used under qemu,
>> from which you get your network to be NAT'd or bridged from/with the host.
>> Your change would force an user to reconfigure the network on boot, and that
>> seems like a less sensible default to me.
>>
> 
> The current default is not that sensible anyway.  If I understand it
> correctly, many packages in OpenWrt assume that lan is for the
> "internal" part of the network map, e.g. by default, dnsmasq will
> serve DHCP requests on lan interface, firewall will also allow
> forwarding on lan interface.  A workaround can be making eth0 the
> default wan interface.

But then again, by making eth0 the default wan interface, this is
enforcing a specific model of the networking, and with QEMU this is a
lot more flexible than that.

Since there does not see to be a good answer, then let's go with your
changes and I will do my local changes if I am unhappy with these...
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 5/5] malta: use "static" proto for lan interface

[Florian Fainelli]

On Oct 28, 2015 5:56 AM, "Yousong Zhou"  wrote:
>
> This is almost the default config of OpenWrt targets (currently even
> those sunxi boards with only one ethernet interface use static IP
> address for its lan interface).

And this is intend intended, because Malta is primarily used under qemu,
from which you get your network to be NAT'd or bridged from/with the host.
Your change would force an user to reconfigure the network on boot, and
that seems like a less sensible default to me.

>
> While at it, also configure a wan interface if eth1 exists.
>
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/malta/base-files/etc/uci-defaults/02-network |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/malta/base-files/etc/uci-defaults/02-network
b/target/linux/malta/base-files/etc/uci-defaults/02-network
> index e90ecbe..1b22ec5 100644
> --- a/target/linux/malta/base-files/etc/uci-defaults/02-network
> +++ b/target/linux/malta/base-files/etc/uci-defaults/02-network
> @@ -3,4 +3,7 @@
>  . /lib/functions/uci-defaults.sh
>
>  ucidef_set_interface_loopback
> -ucidef_set_interface_raw "lan" "eth0" "dhcp"
> +ucidef_set_interface_lan "eth0"
> +if [ -d "/sys/class/net/eth1" ]; then
> +   ucidef_set_interface_wan "eth1"
> +fi
> --
> 1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] malta: convert to router type target.

[Florian Fainelli]

On Oct 28, 2015 5:56 AM, "Yousong Zhou" <yszhou4t...@gmail.com> wrote:
>
> There is currently no relevant definition for developerboard device type
> in include/target.mk, thus packages like iptables, firewall, dnsmasq
> etc. are missing in the default images, rendering it almost useless
> for regular testing or normal use.

This is by design as well here, Malta being used mostly for kernel,
toolchain and user space development, but not being an ideal router
platform.

AFAIR, the default device type is already router, so you could just
eliminate that.

>
> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
> ---
>  target/linux/malta/Makefile |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/malta/Makefile b/target/linux/malta/Makefile
> index c9f1586..0cce15e 100644
> --- a/target/linux/malta/Makefile
> +++ b/target/linux/malta/Makefile
> @@ -15,7 +15,7 @@ MAINTAINER:=Florian Fainelli <flor...@openwrt.org>
>
>  KERNEL_PATCHVER:=3.18
>
> -DEVICE_TYPE:=developerboard
> +DEVICE_TYPE:=router
>
>  include $(INCLUDE_DIR)/target.mk
>
> --
> 1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-11 14:16 GMT-07:00 Attila Lendvai :
>> Just my 2-cents
>>
>> IF it isn't BROKENplease DON'T fix it.
>
>
> the question here is: how much time coders (maintainers, contributors,
> and users) would spare if the administration was shifted to a
> different infrastructure.
>
> i cannot grow to like git (i still prefer darcs), but github simply
> provides so many extra goodies around git, and with such a smooth
> learning curve, that i think it's very much worth taking that road.
>
> i think it'd also be worth having a separate kernel fork (repo) as
> a git submodule under the openwrt git repo. it could have branches for
> the corresponding openwrt branches, and with its separate commit
> history it would make comparison with the mainline kernel way much
> simpler than it is today.

One of the complaints OpenWrt receives a lot (aside from pushing the
actual kernel changes upstream) is that the patches are a combination
of patches applied to the kernel, and files being directly copied into
the Linux sources as-is. Although this model is not ideal for some
people, it still provides some maintenance benefit since there is only
one set of files to target multiple Linux versions.

If we are to move to an OpenWrt branch of the Linux kernel, which is
per-version of Linux (e.g: v4.1-openwrt), this creates a maintenance
difficulty for these shared files/drivers (across multiple Linux
versions), because each Linux kernel branch needs to be updated.

Are we going to expect e.g: v4.1-openwrt git history never to be
rewritten when changes to existing patches are made (look at the
Raspberry Pi kernels, this is awful)? How can we guarantee that the
same fix is easily applied throughout multiple branches? Do we also
want to start maintaining per-platform branches built on top of
v4.1-openwrt, e.g: v4.1-openwrt-ar71xx etc.?

The idealistic answer would of course be: well, get your damn Linux
changes upstream, bite the bullet now, but in few releases, you will
get most of your patches and platforms supported, so this will just be
ancient history. We all know this is not happening overnight, and
working with the upstream Linux community can be challenging for
different reasons so we still need something that is able to cope with
the fast paced embedded market with 10+ new devices everyday with just
one tiny GPIO variation, without rocking the entire way existing
platforms are supported.

>
> potentially the same for some other projects as well, e.g. the
> toolchain repos?

Yes potentially, but then, this is a shortcut we can take just because
we are natively using git, and not another SCM, and git submodules are
possible. It could become a support/maintenance nightmare if everybody
wants to start using custom snapshots all over the place.

>
>
>> Regarding downstream forks, would using Git also make it easier for
>> people like project turris to push appropriate changes back into
>> OpenWrt proper?
>
>
> git checkout -b fixing-this-and-that
> gitk [and cherrypick or tailor the branch with the gui as needed]
> git push
> go to github.com and create a pull request
>
> the whole process can be shorter than 5 minutes, and after that anyone
> can go and browse it among the open pull requests.

We are talking about something slightly different here, because
OpenWrt would switch to git does not mean that it needs to completely
moves away from being self-hosted, and moved to github. I understand
and value the benefits of github and its tools, and tend not to think
that self-hosting makes much sense these days, but others may see
things differently.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-10 10:45 GMT-07:00 nemesis :
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
> wrote:
>>
>> On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:
>>>
>>> Hi.
>>>
 Moving to Git seemed to have lots of traction at the summit, and I'll
 add my voice that this sounds like a step in the right direction for
 OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
 conversion, and Eric's help on this would be great, I think.  My
 discussion with Eric is over on Google+ and marked public:
 https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>>
>>>
>>> Why does the core system need to migrate from svn to git?
>>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>
>
> doing something because everybody is doing so is not the best argument IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches

I do not think it would make anything easier on that front, unless we
start putting existing git-managed projects as submodules of the
top-level openwrt.git repository, this could become fairly cumbersome
to maintain.

> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily

Fair enough, but then again, considering OpenWrt's development model,
the mailing-list should be good enough to get a grasp at what changes
are submitted/reviewed/commented on, no?

> * it would make life easier to the core contributors that prefer to work
> with git because git allows a very powerful development workflow compared to
> SVN

git-svn is kind of the best of both worlds right now.

There is a big problem with git, which is identifying what OpenWrt
release your image is based off. With subversion, it is fairly easy,
you have a revision number that keeps incrementing. With git, asking
people to give you their git-describe output might be a little harder.
On the plus side, we would know if someone had tampered with the
sources (-dirty), but we would not be able to track down changes
easily if someone just created branches and added patches there, since
these would be objects and references that are not accessible.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/5] brcm63xx: lzma-loader: add BCM3380 support

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

That is a first step, but there are additional kernel changes required
to boot on 3380, are you also going to submit these?

> ---
>  target/linux/brcm63xx/image/lzma-loader/src/board.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/target/linux/brcm63xx/image/lzma-loader/src/board.c 
> b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> index 46af525..28b9c53 100644
> --- a/target/linux/brcm63xx/image/lzma-loader/src/board.c
> +++ b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> @@ -70,6 +70,8 @@ void board_init(void)
>   case PRID_IMP_BMIPS43XX:
>   if ((prid & 0xff) == 0x04)
>   chipid_reg = 0xfff8c000;
> + else if ((prid & 0xff) == 0x70)
> + chipid_reg = 0xb4e0;
>   else if ((prid & 0xff) >= 0x30)
>   chipid_reg = 0xb000;
>   else
> @@ -95,6 +97,9 @@ void board_init(void)
>   case 0x6326:
>   uart_base = chipid_reg + 0x180;
>   break;
> + case 0x3380:
> + uart_base = chipid_reg + 0x200;
> + break;
>   case 0x6338:
>   case 0x6345:
>   case 0x6348:
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] brcm63xx: fix Netgear CVG834G HCS magic bytes

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas <nolt...@gmail.com>

Acked-by: Florian Fainelli <flor...@openwrt.org>

> ---
>  target/linux/brcm63xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  mode change 100755 => 100644 target/linux/brcm63xx/image/Makefile
> 
> diff --git a/target/linux/brcm63xx/image/Makefile 
> b/target/linux/brcm63xx/image/Makefile
> old mode 100755
> new mode 100644
> index 9d3ec9f..9581116
> --- a/target/linux/brcm63xx/image/Makefile
> +++ b/target/linux/brcm63xx/image/Makefile
> @@ -581,7 +581,7 @@ $(eval $(call 
> bcm63xxCfeRamdisk,VG50,vg50,vg50,VW6339GU,63268))
>  # Inventel Livebox 1
>  $(eval $(call bcm63xxRedBoot,Livebox,livebox,livebox-blue-5g))
>  # Netgear CVG834G
> -$(eval $(call bcm33xxHcsRamdisk,CVG834G,cvg834g,cvg834g,a020,0001,0022))
> +$(eval $(call bcm33xxHcsRamdisk,CVG834G,cvg834g,cvg834g,0xa020,0001,0022))
>  # Netgear DG834GT/PN
>  $(eval $(call bcm63xxCfe,DG834GTPN,DG834GT_PN,dg834gtpn,96348GW-10,6348))
>  # Netgear DG834G v4
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/5] brcm63xx: fix BCM3368 external interrupts

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas <nolt...@gmail.com>

Acked-by: Florian Fainelli <flor...@openwrt.org>

This matches arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h

> ---
>  target/linux/brcm63xx/dts/bcm3368.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm63xx/dts/bcm3368.dtsi 
> b/target/linux/brcm63xx/dts/bcm3368.dtsi
> index f3b0b02..5be5c6a 100644
> --- a/target/linux/brcm63xx/dts/bcm3368.dtsi
> +++ b/target/linux/brcm63xx/dts/bcm3368.dtsi
> @@ -71,7 +71,7 @@
>   #interrupt-cells = <2>;
>  
>   interrupt-parent = <_intc>;
> - interrupts = <24>, <25>, <26>, <27>;
> + interrupts = <25>, <26>, <27>, <28>;
>   };
>  
>   gpio1: gpio-controller@fff8c080 {
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] bmips: add new target

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 

Nice, a commit message telling what this is about would have been
welcome, especially with the diffstat below which is pretty gigantic.

Could you make sure that all patches that are not upstream yet get
submitted to their respective maintainers?

Finally, which devices has this been tested with?

We can talk about that patchset off list.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/5] brcm63xx: lzma-loader: add BCM3368 support

[Florian Fainelli]

On 09/10/15 13:29, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas <nolt...@gmail.com>

Acked-by: Florian Fainelli <flor...@openwrt.org>

> ---
>  target/linux/brcm63xx/image/lzma-loader/src/board.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm63xx/image/lzma-loader/src/board.c 
> b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> index 1c715e3..46af525 100644
> --- a/target/linux/brcm63xx/image/lzma-loader/src/board.c
> +++ b/target/linux/brcm63xx/image/lzma-loader/src/board.c
> @@ -68,7 +68,9 @@ void board_init(void)
>   chipid_reg = 0xfffe;
>   break;
>   case PRID_IMP_BMIPS43XX:
> - if ((prid & 0xff) >= 0x30)
> + if ((prid & 0xff) == 0x04)
> + chipid_reg = 0xfff8c000;
> + else if ((prid & 0xff) >= 0x30)
>   chipid_reg = 0xb000;
>   else
>   chipid_reg = 0xfffe;
> @@ -80,6 +82,7 @@ void board_init(void)
>   chipid = READREG(chipid_reg);
>  
>   switch (chipid >> 16) {
> + case 0x3368:
>   case 0x6318:
>   case 0x6328:
>   case 0x6358:
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r46981 - trunk/target/linux/generic/patches-3.18

[Florian Fainelli]

On 16/09/15 05:08, openwrt-comm...@openwrt.org wrote:
> Author: blogic
> Date: 2015-09-16 14:08:05 +0200 (Wed, 16 Sep 2015)
> New Revision: 46981
> 
> Modified:
>trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch
> Log:
> kernel: properly guard the lantiq atm abi hack with an ifdef

Would not it make sense to move this to target/linux/lantiq now that
this is target-specific?

> 
> Signed-off-by: John Crispin 
> 
> Modified: trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch
> ===
> --- trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch  
> 2015-09-16 09:37:39 UTC (rev 46980)
> +++ trunk/target/linux/generic/patches-3.18/652-atm_header_changes.patch  
> 2015-09-16 12:08:05 UTC (rev 46981)
> @@ -1,12 +1,14 @@
>  --- a/include/uapi/linux/atm.h
>  +++ b/include/uapi/linux/atm.h
> -@@ -154,6 +154,9 @@
> +@@ -154,6 +154,11 @@
>   unsigned int adtf  :10; /* ACR Decrease Time Factor (10-bit) */
>   unsigned int cdf   :3;  /* Cutoff Decrease Factor (3-bit) */
>   unsigned int spare :9;  /* spare bits */ 
> ++#ifdef CONFIG_LANTIQ
>  +int scr;/* sustained rate in cells per second */
>  +int mbs;/* maximum burst size (MBS) in cells */
>  +int cdv;/* Cell delay varition */
> ++#endif
>   };
>   
>   struct atm_qos {
> ___
> openwrt-commits mailing list
> openwrt-comm...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Florian Fainelli]

On Sep 13, 2015 2:00 PM, "Etienne Champetier" 
wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson" 
a écrit :
> >
> > I do think allowing to choose to disable the banner is a minor benefit,
however, as I've said, there are much more effective means of preventing
accidential exposure, and quite frankly if the user is *choosing* to open
the web interface I think an warning and disabling the banner if the user
foolishly insists on opening the interface despite the warning is more
useful thank disabling the banner by default.
> >
> > If you're going to argue it prevents against internal threats than I
would argue that if your internal network is hostile enough that you need
to worry about attacks on openwrt from your internal network AND you're not
skilled enough to limit access to LuCI (or better, build an image without
LuCI and just use SSH) to the specific trusted hosts (preferably by
combination of MAC address and IP address) in the firewall, or (better) to
use a 'management' VPN or VLAN that only trusted hosts can get on, then
you're in a lot more trouble than eliminating the banner for LuCI will
solve.
> >
> >
> > Regards,
> >
> > Daniel
> >
> > On 2015-09-13 10:21 AM, MauritsVB wrote:
> >>
> >> At the moment the OpenWRT www login screen provides *very* detailed
version information before anyone has even entered a password. It displays
not just “15.05” or “Chaos Calmer” but even the exact git version on the
banner.
> >>
> >> While it’s not advised to open this login screen to the world, fact is
that it does happen intentionally or accidentally. Just a Google search for
“Powered by LuCI Master (git-“ will provide many accessible OpenWRT login
screens, including exact version information.
> >>
> >> As soon as someone discovers a vulnerability in a OpenWRT version all
an attacker needs to do is perform a Google search to find many
installations with versions that are vulnerable (even if a patch is already
available).
> >>
> >> In the interest of hardening the default OpenWRT install, can I
suggest that by default OpenWRT doesn’t disclose the version (not even
15.05 or “Chaos Calmer”) on the login screen? For extra safety I would even
suggest to leave “OpenWRT” off the login screen, the only people who should
use this screen already know it’s running OpenWRT.
> >>
> >> Any thoughts?
> >>
> >> Maurits
> >>
>
> For me listenning only on lan will break all my setups (15+):
> - On most of my openwrt there is no lan, it's management, or
'name-of-the-site' ...
> - on some of them i can access from multiple interface (VPNs + ...)
>
> You can't prevent people from shooting themselves in the foot (maybe port
openning was on purpose),
> but you can:
> -Put a huge warning in luci when you set firewall default to 'ACCEPT'
> -add robots.txt (i think the router will still end up on shodan)
> -add a big warning if robots.txt is accessed (reliable way to know that
you're open on the internet)
>
> Also you are talking about luci but what about dropbear (ssh)? There is
no anti brute force, and maybe there is a banner (on my phone, can't check)

For that you could setup different things ranging from using iptables'
mlimit match per protocol all the way to having something like fail2ban
(written in python though) which can do more complex
blacklisting/blackholing.

All of that is more of a security policy that you deploy rather than want
it by default, even though it may seem very sensible for a default use case.

The bottom line is that if you are exposed to the wild internet, just brace
yourself, it is only a matter of time before your host gets scanned, brute
forced or even penetrated.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 6/6] malta: set CPU_TYPE:=24kc.

[Florian Fainelli]

Le 1 sept. 2015 05:22, "Yousong Zhou" <yszhou4t...@gmail.com> a écrit :
>
> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
> ---
>  target/linux/malta/Makefile |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/linux/malta/Makefile b/target/linux/malta/Makefile
> index 9352dfa..0cce15e 100644
> --- a/target/linux/malta/Makefile
> +++ b/target/linux/malta/Makefile
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk
>
>  BOARD:=malta
>  BOARDNAME:=MIPS Malta CoreLV board (qemu)
> +CPU_TYPE:=24kc

This is certainly valid, but needs to come up with a better explanation as
to why we would want this.

>  SUBTARGETS:=le be #le64 be64
>  INITRAMFS_EXTRA_FILES:=
>  MAINTAINER:=Florian Fainelli <flor...@openwrt.org>
> --
> 1.7.10.4
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/6] generic: fix unrecognized opcode wsbh when building for MIPS16.

[Florian Fainelli]

Le 1 sept. 2015 05:22, "Yousong Zhou"  a écrit :
>
> The issue was found and reported by hynman [1] when compiling reaver for
ar71xx
> (Big Endian MIPS).
>
> {standard input}: Assembler messages:
> {standard input}:79: Error: unrecognized opcode `wsbh $2,$2'
> {standard input}:90: Error: unrecognized opcode `wsbh $3,$17'
> {standard input}:208: Error: unrecognized opcode `wsbh $2,$2'
> make[3]: *** [builder.o] Error 1

Could you submit this to the linux-mips mailing list first so we only get
to backport an accepted patch?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 3/3] mcs814x: use firmware partition splitter on dLAN USB Extender

[Florian Fainelli]

On Jul 27, 2015 3:55 AM, Günther Kelleter guenther.kelle...@devolo.de
wrote:

Looks good to me, having a better commit message would be welcome.


 Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 ---
  target/linux/mcs814x/config-3.18  | 4

  .../mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts| 8

  target/linux/mcs814x/image/Makefile   | 2 +-
  3 files changed, 5 insertions(+), 9 deletions(-)

 diff --git a/target/linux/mcs814x/config-3.18
b/target/linux/mcs814x/config-3.18
 index e57f5ff..427a7c9 100644
 --- a/target/linux/mcs814x/config-3.18
 +++ b/target/linux/mcs814x/config-3.18
 @@ -159,6 +159,10 @@ CONFIG_MODULES_USE_ELF_REL=y
  # CONFIG_MTD_IMPA7 is not set
  CONFIG_MTD_JEDECPROBE=y
  CONFIG_MTD_PHYSMAP=y
 +# CONFIG_MTD_ROOTFS_SPLIT is not set
 +CONFIG_MTD_SPLIT_FIRMWARE=y
 +CONFIG_MTD_SPLIT_FIRMWARE_NAME=linux
 +CONFIG_MTD_SPLIT_UIMAGE_FW=y
  CONFIG_MULTI_IRQ_HANDLER=y
  CONFIG_NEED_DMA_MAP_STATE=y
  CONFIG_NEED_KUSER_HELPERS=y
 diff --git
a/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
b/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
 index 0c85b94..59830e8 100644
 ---
a/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
 +++
b/target/linux/mcs814x/files-3.18/arch/arm/boot/dts/dlan-usb-extender.dts
 @@ -48,14 +48,6 @@
 reg = 0x4 0x1;
 };
 partition@5 {
 -   label = kernel;
 -   reg = 0x5 0x10;
 -   };
 -   partition@15 {
 -   label = rootfs;
 -   reg = 0x15 0x3C;
 -   };
 -   partition@50001 {
 label = linux;
 reg = 0x5 0x4C;
 };
 diff --git a/target/linux/mcs814x/image/Makefile
b/target/linux/mcs814x/image/Makefile
 index 4c8af97..74f8ad4 100644
 --- a/target/linux/mcs814x/image/Makefile
 +++ b/target/linux/mcs814x/image/Makefile
 @@ -30,7 +30,7 @@ define Image/Build/DTB
  endef

  define Image/Build/Profile/dLAN_USB_Extender
 -   dd if=$(KDIR)/uImage-dlan-usb-extender bs=1M conv=sync
of=$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
 +   dd if=$(KDIR)/uImage-dlan-usb-extender bs=64k conv=sync
of=$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
 cat $(KDIR)/root.$(1) 
$(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
 cp $(KDIR)/$(IMG_PREFIX)-dlan-usb-extender-upgrade-$(1).bin
$(BIN_DIR)/
  endef
 --
 2.4.6.89.g851dcf4
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/3] mcs814x: fix debug UART

[Florian Fainelli]

On Jul 27, 2015 3:54 AM, Günther Kelleter guenther.kelle...@devolo.de
wrote:

 It was broken since kernel 3.14

True, but your patch does not explain how you are fixing this, which is
what matters for a good commit message. Could expand on why migrating to
the generic 8250 debug uart code is fixing things?


 Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 ---
  target/linux/mcs814x/config-3.18   | 10 --
  .../linux/mcs814x/patches-3.18/014-debuguart.patch | 41
++
  2 files changed, 48 insertions(+), 3 deletions(-)
  create mode 100644 target/linux/mcs814x/patches-3.18/014-debuguart.patch

 diff --git a/target/linux/mcs814x/config-3.18
b/target/linux/mcs814x/config-3.18
 index 87a8382..e57f5ff 100644
 --- a/target/linux/mcs814x/config-3.18
 +++ b/target/linux/mcs814x/config-3.18
 @@ -49,10 +49,15 @@ CONFIG_CRYPTO_CRC32C=y
  CONFIG_CRYPTO_HASH=y
  CONFIG_CRYPTO_HASH2=y
  CONFIG_DEBUG_LL=y
 -CONFIG_DEBUG_LL_INCLUDE=mach/debug-macro.S
 +CONFIG_DEBUG_LL_INCLUDE=debug/8250.S
  CONFIG_DEBUG_LL_UART_NONE=y
 -# CONFIG_DEBUG_UART_8250 is not set
 +CONFIG_DEBUG_UART_8250=y
 +# CONFIG_DEBUG_UART_8250_FLOW_CONTROL is not set
 +CONFIG_DEBUG_UART_8250_SHIFT=2
 +# CONFIG_DEBUG_UART_8250_WORD is not set
 +CONFIG_DEBUG_UART_PHYS=0x400dc000
  # CONFIG_DEBUG_UART_PL01X is not set
 +CONFIG_DEBUG_UART_VIRT=0xf00dc000
  # CONFIG_DEBUG_USER is not set
  CONFIG_DTC=y
  CONFIG_EARLY_PRINTK=y
 @@ -157,7 +162,6 @@ CONFIG_MTD_PHYSMAP=y
  CONFIG_MULTI_IRQ_HANDLER=y
  CONFIG_NEED_DMA_MAP_STATE=y
  CONFIG_NEED_KUSER_HELPERS=y
 -CONFIG_NEED_MACH_MEMORY_H=y
  CONFIG_NEED_PER_CPU_KM=y
  CONFIG_NET_KEY=y
  # CONFIG_NET_VENDOR_BROADCOM is not set
 diff --git a/target/linux/mcs814x/patches-3.18/014-debuguart.patch
b/target/linux/mcs814x/patches-3.18/014-debuguart.patch
 new file mode 100644
 index 000..5f1b67f
 --- /dev/null
 +++ b/target/linux/mcs814x/patches-3.18/014-debuguart.patch
 @@ -0,0 +1,41 @@
 +--- a/arch/arm/mach-mcs814x/include/mach/debug-macro.S
  /dev/null
 +@@ -1,11 +0,0 @@
 +-#include mach/mcs814x.h
 +-
 +-.macro  addruart, rp, rv, tmp
 +-  ldr \rp, =MCS814X_PHYS_BASE
 +-  ldr \rv, =MCS814X_VIRT_BASE
 +-  orr \rp, \rp, #MCS814X_UART
 +-  orr \rv, \rv, #MCS814X_UART
 +-.endm
 +-
 +-#define UART_SHIFT2
 +-#include asm/hardware/debug-8250.S
 +--- a/arch/arm/Kconfig.debug
  b/arch/arm/Kconfig.debug
 +@@ -1089,7 +1089,7 @@ config DEBUG_UART_8250
 +   (FOOTBRIDGE  !DEBUG_DC21285_PORT) || \
 +   ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
 +   ARCH_IOP33X || ARCH_IXP4XX || \
 +-  ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
 ++  ARCH_LPC32XX || ARCH_MCS814X || ARCH_MV78XX0 ||
ARCH_ORION5X || ARCH_RPC
 +
 + # Compatibility options for BCM63xx
 + config DEBUG_UART_BCM63XX
 +@@ -1124,6 +1124,7 @@ config DEBUG_UART_PHYS
 +   default 0x3e00 if DEBUG_BCM_KONA_UART
 +   default 0x4000e400 if DEBUG_LL_UART_EFM32
 +   default 0x4009 if ARCH_LPC32XX
 ++  default 0x400dc000 if ARCH_MCS814X
 +   default 0x4010 if DEBUG_PXA_UART1
 +   default 0x4200 if ARCH_GEMINI
 +   default 0x5000 if DEBUG_S3C24XX_UART  (DEBUG_S3C_UART0 || \
 +@@ -1178,6 +1179,7 @@ config DEBUG_UART_VIRT
 +   default 0xe0010fe0 if ARCH_RPC
 +   default 0xe100 if DEBUG_MSM_UART
 +   default 0xfbe0 if ARCH_EBSA110
 ++  default 0xf00dc000 if ARCH_MCS814X
 +   default 0xf01fb000 if DEBUG_NOMADIK_UART
 +   default 0xf0201000 if DEBUG_BCM2835
 +   default 0xf1000300 if DEBUG_BCM_5301X
 --
 2.4.6.89.g851dcf4
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/3] mcs814x: fix interrupts

[Florian Fainelli]

On Jul 27, 2015 3:54 AM, Günther Kelleter guenther.kelle...@devolo.de
wrote:

 create explicit 1:1 mapping before mcs814x_alloc_gc/irq_setup_generic_chip
 marks all interrupts used and prevents mapping by dts init.
 IRQ 0 is the timer interrupt and is not illegal!

Is the second hunk of the patch still necessary then? Some other people
seem to have run into similar problems on Dove, you might to look at what
they did to avoid having to remove the check against virq 0.


 Was broken since kernel 3.14.

 Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 ---
  target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c |  6 +-
  target/linux/mcs814x/patches-3.18/015-timer-irq.patch   | 11
+++
  2 files changed, 16 insertions(+), 1 deletion(-)
  create mode 100644 target/linux/mcs814x/patches-3.18/015-timer-irq.patch

 diff --git a/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
b/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
 index f84c412..fd4345f 100644
 --- a/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
 +++ b/target/linux/mcs814x/files-3.18/arch/arm/mach-mcs814x/irq.c
 @@ -71,6 +71,7 @@ static const struct of_device_id mcs814x_intc_ids[] = {
  void __init mcs814x_of_irq_init(void)
  {
 struct device_node *np;
 +   struct irq_domain *domain;

 np = of_find_matching_node(NULL, mcs814x_intc_ids);
 if (!np)
 @@ -80,7 +81,10 @@ void __init mcs814x_of_irq_init(void)
 if (!mcs814x_intc_base)
 panic(unable to map intc cpu registers\n);

 -   irq_domain_add_simple(np, 32, 0, irq_generic_chip_ops, NULL);
 +   domain = irq_domain_add_simple(np, 32, 0, irq_domain_simple_ops,
NULL);
 +   if (!domain)
 +   panic(unable to add irq domain\n);
 +   irq_create_strict_mappings(domain, 0, 0, 32);

 of_node_put(np);

 diff --git a/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
b/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
 new file mode 100644
 index 000..9bbb094
 --- /dev/null
 +++ b/target/linux/mcs814x/patches-3.18/015-timer-irq.patch
 @@ -0,0 +1,11 @@
 +--- a/kernel/irq/irqdesc.c
  b/kernel/irq/irqdesc.c
 +@@ -381,7 +381,7 @@ int __handle_domain_irq(struct irq_domai
 +* Some hardware gives randomly wrong interrupts.  Rather
 +* than crashing, do something sensible.
 +*/
 +-  if (unlikely(!irq || irq = nr_irqs)) {
 ++  if (unlikely(irq = nr_irqs)) {
 +   ack_bad_irq(irq);
 +   ret = -EINVAL;
 +   } else {
 --
 2.4.6.89.g851dcf4
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Split kernel modules out of the base opkg repo?

[Florian Fainelli]

On Jul 25, 2015 7:39 AM, Matthias Schiffer mschif...@universe-factory.net
wrote:

 On 07/25/2015 03:55 PM, John Crispin wrote:
 
 
  On 25/07/2015 14:46, Matthias Schiffer wrote:
  Hi,
  I'd like to propose to split the current base opkg repo into two, one
  for userspace applications and one for kernel modules. This would
  greatly simplify providing your own kernel module repository with
  modules for a customized kernel, while still being able to rely on the
  upstream base repo for userspace.
 
  I'll provide a patch for this if you think this is a reasonable idea.
 
  Matthias
 
 
  i think the current setup works very well for open drivers and code.
  fixing up openwrt for out of tree modules is imho not a good idea as it
  allows companies to easily avoid upstreaming stuff.
 
  why dont you just include your magic USP into openwrt and/or upstream ?

 I'm not talking about out-of-tree modules at all, I'm talking about the
 kmod-* packages in the base repo. I want to provide an own opkg repo
 with the same kernel modules, but built for a customized kernel.

 As these modules' ABI depends on the kernel configuration (and thus the
 kernel configuration is included in the version number as vermagic), I
 need to provide the kernel modules built matching my configuration. As
 far as I know there's no way to tell opkg to prefer the modules from my
 repo, regardless of the version number, so I'm asking for a base repo
 without any kmod-* packages.

But since this is already a custom repository, why not take care yourself
of synchronizing the base packages (but not kmod-*) from OpenWrt's upstream
directly?

If you dedicate a custom kernel image version to make sure that OpenWrt
kmods cannot be installed, does not that work already?



 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Prevent more gzip timestamps

[Florian Fainelli]

On 14/07/15 15:05, Reiner Herrmann wrote:
 On Sun, Jul 12, 2015 at 12:06:01PM -0700, Florian Fainelli wrote:
 2015-07-12 9:41 GMT-07:00 Reiner Herrmann rei...@reiner-h.de:
 To improve reproducibility, prevent the inclusion of timestamps
 in the gzip header.

 This looks fine to me, this also unveils a lot of repetition in how we
 invoke gzip and its parameters, would you mind factoring this in a
 variable such that we control how gzip options are set globally?
 Eventually someone will want to be able to turn back on timestamps and
 original names in how gzip generates compressed files, and we might as
 well have a single location to fix this.
 
 The commands that are currently available in variables are named
 just in uppercase (FIND, TAR, etc.).
 But gzip also interprets the variable GZIP to parse additional
 options, so naming the variable for the command also GZIP will
 probably cause problems.

Ah good point. How about GZIP_CMD then?

 Or would it be better to just globally export GZIP with the
 default parameters (which would then differ from the currents
 semantics of having the command inside the variable)?

We could do that, I am just wondering if this would make it a bit more
difficult to debug in case we forgot to patch a given Makefile or that
we do reset the environment/do not inherit it.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Prevent more gzip timestamps

[Florian Fainelli]

2015-07-12 9:41 GMT-07:00 Reiner Herrmann rei...@reiner-h.de:
 To improve reproducibility, prevent the inclusion of timestamps
 in the gzip header.

This looks fine to me, this also unveils a lot of repetition in how we
invoke gzip and its parameters, would you mind factoring this in a
variable such that we control how gzip options are set globally?
Eventually someone will want to be able to turn back on timestamps and
original names in how gzip generates compressed files, and we might as
well have a single location to fix this.

Let's just hope that nobody relies on the original file names (does
not look like it).


 Signed-off-by: Reiner Herrmann rei...@reiner-h.de
 ---
  docs/adding.tex| 2 +-
  include/image.mk   | 2 +-
  package/Makefile   | 2 +-
  target/imagebuilder/files/Makefile | 2 +-
  target/linux/adm5120/image/router_le.mk| 2 +-
  target/linux/adm8668/image/Makefile| 2 +-
  target/linux/ar71xx/image/Makefile | 6 +++---
  target/linux/ath25/image/Makefile  | 2 +-
  target/linux/brcm63xx/image/Makefile   | 2 +-
  target/linux/generic/files/crypto/ocf/Makefile | 2 +-
  target/linux/ipq806x/image/Makefile| 2 +-
  target/linux/malta/image/Makefile  | 2 +-
  target/linux/x86/image/Makefile| 4 ++--
  target/linux/xburst/image/Makefile | 2 +-
  14 files changed, 17 insertions(+), 17 deletions(-)

 diff --git a/docs/adding.tex b/docs/adding.tex
 index 97547ac..7b80c0d 100644
 --- a/docs/adding.tex
 +++ b/docs/adding.tex
 @@ -556,7 +556,7 @@ include $(INCLUDE_DIR)/image.mk

  define Image/BuildKernel
  cp $(KDIR)/vmlinux.elf $(BIN_DIR)/openwrt-$(BOARD)-vmlinux.elf
 -gzip -9 -c $(KDIR)/vmlinux  $(KDIR)/vmlinux.bin.gz
 +gzip -9n -c $(KDIR)/vmlinux  $(KDIR)/vmlinux.bin.gz
  $(STAGING_DIR_HOST)/bin/lzma e $(KDIR)/vmlinux $(KDIR)/vmlinux.bin.l7
  dd if=$(KDIR)/vmlinux.bin.l7 
 of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.lzma bs=65536 conv=sync
  dd if=$(KDIR)/vmlinux.bin.gz 
 of=$(BIN_DIR)/openwrt-$(BOARD)-vmlinux.gz bs=65536 conv=sync
 diff --git a/include/image.mk b/include/image.mk
 index 814e7dc..6767e76 100644
 --- a/include/image.mk
 +++ b/include/image.mk
 @@ -224,7 +224,7 @@ ifneq ($(CONFIG_TARGET_ROOTFS_UBIFS),)
  endif

  define Image/mkfs/cpiogz
 -   ( cd $(TARGET_DIR); find . | cpio -o -H newc | gzip -9 
 $(BIN_DIR)/$(IMG_PREFIX)-rootfs.cpio.gz )
 +   ( cd $(TARGET_DIR); find . | cpio -o -H newc | gzip -9n 
 $(BIN_DIR)/$(IMG_PREFIX)-rootfs.cpio.gz )
  endef

  define Image/mkfs/targz
 diff --git a/package/Makefile b/package/Makefile
 index 3ef34b1..cc691b5 100644
 --- a/package/Makefile
 +++ b/package/Makefile
 @@ -149,7 +149,7 @@ $(curdir)/index: FORCE
 mkdir -p $(PACKAGE_DIR)/$$d; \
 cd $(PACKAGE_DIR)/$$d || continue; \
 $(SCRIPT_DIR)/ipkg-make-index.sh . 21  Packages  \
 -   gzip -9c Packages  Packages.gz; \
 +   gzip -9nc Packages  Packages.gz; \
 ); done
  ifdef CONFIG_SIGNED_PACKAGES
 @echo Signing package index...
 diff --git a/target/imagebuilder/files/Makefile 
 b/target/imagebuilder/files/Makefile
 index e28660f..8f25c4a 100644
 --- a/target/imagebuilder/files/Makefile
 +++ b/target/imagebuilder/files/Makefile
 @@ -121,7 +121,7 @@ package_index: FORCE
 @echo Building package index...
 @mkdir -p $(TMP_DIR) $(TARGET_DIR)/tmp
 (cd $(PACKAGE_DIR); $(SCRIPT_DIR)/ipkg-make-index.sh .  Packages  \
 -   gzip -9c Packages  Packages.gz \
 +   gzip -9nc Packages  Packages.gz \
 ) /dev/null 2/dev/null
 $(OPKG) update || true

 diff --git a/target/linux/adm5120/image/router_le.mk 
 b/target/linux/adm5120/image/router_le.mk
 index 6df6dcd..1e3d7f7 100644
 --- a/target/linux/adm5120/image/router_le.mk
 +++ b/target/linux/adm5120/image/router_le.mk
 @@ -72,7 +72,7 @@ define Image/Build/Cellvision
 $(call Image/Build/Loader,$(2),bin,0x8050,0x6D8,y,$(3))
 mkdir -p $(BIN_DIR)/tmp
 cp $(KDIR)/loader-$(2).bin $(BIN_DIR)/tmp/vmlinux.bin
 -   gzip -9 $(BIN_DIR)/tmp/vmlinux.bin
 +   gzip -9n $(BIN_DIR)/tmp/vmlinux.bin
 dd if=$(BIN_DIR)/tmp/vmlinux.bin.gz of=$(call 
 imgname,$(1),$(2))-xmodem.bin bs=64k conv=sync
 rm -rf $(BIN_DIR)/tmp
 $(call Image/Build/TRXNoloader,$(call imgname,$(1),$(2)).trx,$(1))
 diff --git a/target/linux/adm8668/image/Makefile 
 b/target/linux/adm8668/image/Makefile
 index 9e25224..597b8f7 100644
 --- a/target/linux/adm8668/image/Makefile
 +++ b/target/linux/adm8668/image/Makefile
 @@ -16,7 +16,7 @@ endef


  define CompressGzip
 -   gzip -9 -c $(1)  $(2)
 +   gzip -9n -c $(1)  $(2)
  endef

  define MkImage
 diff --git a/target/linux/ar71xx/image/Makefile 
 b/target/linux/ar71xx/image/Makefile
 index 

Re: [OpenWrt-Devel] Hard float ABI for BCM2708/BCM2709

[Florian Fainelli]

Le 11 juil. 2015 09:52, Matthias Schiffer mschif...@universe-factory.net
a écrit :

 Hi,
 I've noticed that OpenWrt currently uses the soft-float ABI in the
 Raspberry Pi images. Is there a specific reason hard float is not used,
 even though most other distributions like Raspbian have switched to it?

I do not think there was any particular reason. This was one of the few
ARM-based targets that are not armv5, however armv5 may have been used as a
template to kick the initial port.


 I tried adding fpu to FEATURES to enable hard-float, and the generated
 images seem to work fine.

If you want to submit a patch doing this, I will gladly apply it, we may
have to set a different FPU ABI between brcm2708 and 09 though.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ar71xx: add spi nand driver support

[Florian Fainelli]

On 10/07/15 02:54, Pan, Miaoqing wrote:
 Agree with you,  I investigated this, tried to merge two into one.  E.g.  
 Implement the common core for spinand,  separate  vendors related codes,  but 
 give up finally as no device to verify mt29f:(  So I only add it to support 
 for ath79 platform.

There are some on-going efforts to come up with proper SPI NAND support
in the MTD layer, you might want to piggy back on that effort:

http://lists.infradead.org/pipermail/linux-mtd/2015-June/059837.html

 
 Thanks,
 Miaoqing
 
 -Original Message-
 From: Jonas Gorski [mailto:j...@openwrt.org] 
 Sent: Friday, July 10, 2015 5:44 PM
 To: Pan, Miaoqing
 Cc: OpenWrt Development List
 Subject: Re: [OpenWrt-Devel] [PATCH 3/3] ar71xx: add spi nand driver support
 
 Hi,
 
 On Fri, Jul 10, 2015 at 9:18 AM,  miaoq...@qti.qualcomm.com wrote:
 From: Miaoqing Pan miaoq...@codeaurora.org

 Derived from 'drivers/staging/mt29f_spinand'.

 Only support Giga Device SPI NAND device now,
 - GD5F1GQ4U 1G 3.3V 8-bit
 - GD5F2GQ4U 2G 3.3V 8-bit
 - GD5F1GQ4R 1G 1.8V 8-bit
 - GD5F2GQ4R 2G 1.8V 8-bit

 Signed-off-by: Miaoqing Pan miaoq...@codeaurora.org
 
 This looks exactly like mt29f_spinand, except with ath79_ prefixed to 
 everything. Also I don't see anything ath79 specific in here.
 
 Why can't you just use mt29f_spinand directly? And why do you need to create 
 a copy of it instead of just fixing it in the driver itself?
 
 
 Jonas
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] IPtables/NAT

[Florian Fainelli]

Hi,

Le 5 juil. 2015 20:20, John kerry kerry9...@gmail.com a écrit :

 Hi ,

 Hope you are doing great. I am working on Atheros QSDK.

You might get better support by contacting whoever maintains this QSDK ad
it is an OpenWrt derivative, however as far as OpenWrt is concerned, see
below.

i am able to compile the source code successfully and able to upgrade the
firmware using openWRT Luci GUI too. The OpenWRT being a linux distro for
embedded platform already has IPtables implemented. Before compiling the
source code i have to do a make menuconfig and enable the netfilter module
in networking. This would enable IPtables and compile it. Is my
undersatnding correct?

By default, OpennWrt comes with iptables and netfilter enabled.


 Could you please guide me to write the Iptables rule. Basically i have to
write the rules for iptables/NAT for the following condition.
 Router mode with NAT and iptables, the web page access to be available
only to LAN (WiFi/Wired).
 I have one LAN and one WAN Connection, the LAN ip set to some static IP
to access the GUI.

All of this is done by default by OpenWrt provided that you keep the
default selection of packages. You may have to ask the build system to
include luci (web gui) to include it in the image creation.

A lot of this is covered in details on the wiki, of course, working with
QSDK instead of the mainline OpenWrt, your mileage may vary.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Controlling POE passthrough via GPIO

[Florian Fainelli]

On 22/06/15 16:48, Lars Kruse wrote:
 Hi,
 
 within our wireless community we are using a couple of devices with the
 following features:
 * powered via POE through their first ethernet plug
 * another device can be powered via the second ethernet plug (POE passthrough
   switchable via GPIO)
 
 The POE passthrough feature can be controlled via GPIO pins.
 For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO
 pins #2, #8 or #20 (depending on the model).
 
 Currently we are using a custom script (see attached) for these models.
 
 I have the feeling that this kind of hardware capabilities should be available
 within openwrt (similar to the LED setup).
 
 Is there anything related already implemented within openwrt?
 If not: where would you recommend to put it?

You could eventually utilize the regulator framework to implement such
GPIO toggling to provide/remove power to a given device. I have not
looked at whether this is something controllable from user-space, but
there is an in-kernel API to be a consumer of the regulator API.

Of course this information should be made conditional to the device model.

My 2 cents.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add support for WeIO board

[Florian Fainelli]

Missing Signed-off-by tag and description of the patch.


Le 06/16/15 14:06, Drasko DRASKOVIC a écrit :
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add Support for WeIO Board (Chaos Calmer)

[Florian Fainelli]

On Jun 14, 2015 2:56 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com
wrote:

 Hello,
 please find below patch that adds support for WeIO board
 (http://we-io.net) to Chaos Calmer master branch.

 The board is based on Carambola2 module from 8Devices, and this patch
 adds a separate profile for WeIO.

Your patch has been mangled by your mailer, you might want to use
git-send-email instead. Since this is a new target, trunk is more
appropriate, once it gets there, backports to CC can be made.


 Best regards,
 Drasko




 From c68e410601b1fe656dad7b08ed41de470d0550c6 Mon Sep 17 00:00:00 2001
 From: Drasko DRASKOVIC drasko.drasko...@gmail.com
 Date: Sun, 14 Jun 2015 22:41:45 +0200
 Subject: [PATCH] Add support for WeIO board

 Signed-off-by: Drasko DRASKOVIC drasko.drasko...@gmail.com
 ---
  .../ar71xx/base-files/etc/uci-defaults/01_leds |   6 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
  .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
  target/linux/ar71xx/config-3.18|   1 +
  .../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 148
+
  target/linux/ar71xx/generic/profiles/weio.mk   |  17 +++
  target/linux/ar71xx/image/Makefile |   8 ++
  .../610-MIPS-ath79-openwrt-machines.patch  |  21 ++-
  8 files changed, 201 insertions(+), 6 deletions(-)
  create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
  create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk

 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 index 41b..b0fb36e 100644
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 @@ -63,6 +63,12 @@ carambola2)
   ucidef_set_led_wlan wlan WLAN carambola2:green:wlan phy0tpt
   ;;

 +weio)
 + ucidef_set_led_netdev lan LAN weio:orange:eth0 eth0
 + ucidef_set_led_netdev wan WAN weio:orange:eth1 eth1
 + ucidef_set_led_wlan wlan WLAN weio:green:wlan phy0tpt
 + ;;
 +
  cpe510)
   ucidef_set_led_switch lan0 LAN0 tp-link:green:lan0 switch0
0x20
   ucidef_set_led_switch lan1 LAN1 tp-link:green:lan1 switch0
0x10
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index b13be1e..fe7478c 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -892,6 +892,9 @@ ar71xx_board_detect() {
   8devices Carambola2*)
   name=carambola2
   ;;
 + *WeIO)
 + name=weio
 + ;;
   *Sitecom WLR-8100)
   name=wlr8100
   ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 3dbd91c..0f2920b 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -243,7 +243,8 @@ platform_check_image() {
   nbg460n_550n_550nh | \
   unifi | \
   unifi-outdoor | \
 - carambola2 )
 + carambola2 | \
 + weio )
   [ $magic != 2705 ]  {
   echo Invalid image type.
   return 1
 diff --git a/target/linux/ar71xx/config-3.18
b/target/linux/ar71xx/config-3.18
 index 543b77e..ae68a18 100644
 --- a/target/linux/ar71xx/config-3.18
 +++ b/target/linux/ar71xx/config-3.18
 @@ -43,6 +43,7 @@ CONFIG_ATH79_MACH_AW_NR580=y
  CONFIG_ATH79_MACH_BHU_BXU2000N2_A=y
  CONFIG_ATH79_MACH_CAP4200AG=y
  CONFIG_ATH79_MACH_CARAMBOLA2=y
 +CONFIG_ATH79_MACH_WEIO=y
  CONFIG_ATH79_MACH_CPE510=y
  CONFIG_ATH79_MACH_DB120=y
  CONFIG_ATH79_MACH_DGL_5500_A1=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
 new file mode 100644
 index 000..70ed543
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
 @@ -0,0 +1,148 @@
 +/**
 + * WEIO Web Of Things Platform
 + *
 + * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
 + *
 + *  ##  ##    ###
 + *  ##  ##  ## ####  ## ##
 + *  ##  ##  ## ####  ## ##
 + *  ##  ##  ## ####  ## ##
 + *  ##  ##  ## ####  ## ##
 + *  ##  ##  ## ####  ## ##
 + *   ###  ###     ###
 + *
 + *   Web Of Things Platform
 + *
 + * Authors :
 + * Drasko DRASKOVIC drasko.drasko...@gmail.com
 + * Uros PETREVSKI u...@nodesign.net
 + */
 +
 +#include asm/mach-ath79/ath79.h
 +#include asm/mach-ath79/ar71xx_regs.h
 +#include common.h
 +#include dev-eth.h
 +#include dev-gpio-buttons.h
 +#include dev-leds-gpio.h
 +#include dev-m25p80.h
 +#include dev-spi.h
 +#include dev-usb.h
 +#include dev-wmac.h
 +#include machtypes.h
 +#include linux/i2c-gpio.h
 +#include linux/platform_device.h
 +
 +#define WEIO_GPIO_LED_STA 1
 +#define WEIO_GPIO_LED_AP 16
 +//#define WEIO_GPIO_LED_ETH0 13
 +
 +#define WEIO_GPIO_BTN_AP20
 +#define 

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

[Florian Fainelli]

On Jun 9, 2015 7:36 AM, Christian Lamparter chunk...@googlemail.com
wrote:

 On Wednesday, June 03, 2015 05:20:22 PM Christian Lamparter wrote:
  The mynet range extender hardware is suffering from ethernet
  link loss when booting with a recent openwrt image. This only
  happens on 100mbps links, with 1Gbps speed the link was fine.
 
  The cause of the problem is that the AR8035 PHY (aka F1E)
  requires turning on and off the special TX delay setting
  depending on the speed of the link.
 
  The 10mbps mode only needed the proper pll value, which was
  extracted from the vendor code.
 
  Reported-by: Pascal Paradis
  Signed-off-by: Christian Lamparter chunk...@googlemail.com

 No comments so far (but also, no merge). Ping?

Actually, I have one question, most PHY s should disable these kinds of
delays when linking at 10/100Mbits/sec. Is not that working here because
the registers used have a special behavior (force or override), or is it
broken at the hardware level?


 Regards,
   Christian
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

[Florian Fainelli]

Florian
On Jun 5, 2015 2:18 PM, Dave Taht dave.t...@bufferbloat.net wrote:

 TX delay setting? What else can it do?

This is a delay between the transmit data lines and the transmit clock on a
RGMII interface. Based on PCB designs, this is something that may have to
be configured to align clock and data lines in a way that does not violate
timings and causes packet losses between the MAC and the PHY. These delays
are not valid when a RGMII interface operates at 10 or 100Mbits/sec since
the clock becomes slow enough the rise and fall times of the data lines are
negligable.


 My dream has been to find a way to set the tx completion interrupt
 to only return with a soft set rate. So if I had a gigE connection
 but my uplink was only 10Mbits, it would return the interrupt
 after 1.3ms had expired.

What you are referring to here is interrupt coalescing, which is different
and implemented at the Ethernet MAC and DMA engine levels and not all
controllers support that.


 this would let me get away entirely from using software rate limiting
 with htb, just program a register once with the uplink rate, and
 let bql and fq_codel handle the rest.

 On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
  The mynet range extender hardware is suffering from ethernet
  link loss when booting with a recent openwrt image. This only
  happens on 100mbps links, with 1Gbps speed the link was fine.
 
  The cause of the problem is that the AR8035 PHY (aka F1E)
  requires turning on and off the special TX delay setting
  depending on the speed of the link.
 
  The 10mbps mode only needed the proper pll value, which was
  extracted from the vendor code.
 
  Reported-by: Pascal Paradis
  Signed-off-by: Christian Lamparter chunk...@googlemail.com
  ---
   .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
   ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53
--
   2 files changed, 69 insertions(+), 4 deletions(-)
 
  diff --git
a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
  index 02d168e..3d48ca8 100644
  --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
  +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
  @@ -14,6 +14,7 @@
   #include linux/platform_device.h
   #include linux/ath9k_platform.h
   #include linux/ar8216_platform.h
  +#include linux/platform_data/phy-at803x.h
 
   #include asm/mach-ath79/ar71xx_regs.h
 
  @@ -124,6 +125,21 @@ static struct gpio_keys_button
mynet_rext_gpio_keys[] __initdata = {
},
   };
 
  +static struct at803x_platform_data mynet_rext_at803x_data = {
  + .disable_smarteee = 0,
  + .enable_rgmii_rx_delay = 1,
  + .enable_rgmii_tx_delay = 0,
  + .fixup_rgmii_tx_delay = 1,
  +};
  +
  +static struct mdio_board_info mynet_rext_mdio0_info[] = {
  +{
  +.bus_id = ag71xx-mdio.0,
  +.phy_addr = 4,
  +.platform_data = mynet_rext_at803x_data,
  +},
  +};
  +
   static void mynet_rext_get_mac(const char *name, char *mac)
   {
u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
  @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
 
ath79_register_mdio(0, 0x0);
 
  + mdiobus_register_board_info(mynet_rext_mdio0_info,
  + ARRAY_SIZE(mynet_rext_mdio0_info));
  +
/* LAN */
mynet_rext_get_mac(et0macaddr=, ath79_eth0_data.mac_addr);
 
/* GMAC0 is connected to an external PHY on Port 4 */
ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
ath79_eth0_data.phy_mask = BIT(4);
  + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
ath79_eth0_data.mii_bus_dev = ath79_mdio0_device.dev;
ath79_register_eth(0);
  diff --git
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
  index babc695..d046ede 100644
  ---
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
  +++
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
  @@ -32,6 +32,14 @@
#define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
#define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
 
  +@@ -50,6 +60,7 @@ MODULE_LICENSE(GPL);
  + struct at803x_priv {
  + bool phy_reset:1;
  + struct gpio_desc *gpiod_reset;
  ++int prev_speed;
  + };
  +
  + struct at803x_context {
   @@ -61,6 +71,43 @@ struct at803x_context {
u16 led_control;
};
  @@ -120,16 +128,53 @@
return 0;
}
 
  +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
  + static void at803x_link_change_notify(struct phy_device *phydev)
  + {
  + struct at803x_priv *priv = phydev-priv;
  ++

Re: [OpenWrt-Devel] [PATCH] Support Cisco/Linksys WAP-4410N

[Florian Fainelli]

Le 04/25/15 12:21, Caleb James DeLisle a écrit :
 This patch adds support for Cisco/Linksys WAP-4410N
 Currently there is no way to update from the factory firmware other than 
 using tricks
 but for the amount of times that is required, it's judged not to be a 
 significant problem.
 
 Also the location of the kernel is moved from the factory location because 
 the 3.x kernel
 is larger than the 2.6 kernel they were using so keeping the memory position 
 was not feasible,
 therefore there is no way to install without changing the uboot environment 
 variable.

In case this helps, this C program deconstructs Linksys' original firmware:
https://github.com/ffainelli/firmware-tools/blob/master/unlapbind.c

and attached is an attempt at re-creating their proprietary firmware
format. I was never sure if we could upgrade without re-flashing u-boot,
so I did not give this a try on a real device, device which is now with
Gabor.
--
Florian
From 8a3c7b1527d114b015286b6e89bf828d3130a340 Mon Sep 17 00:00:00 2001
From: Florian Fainelli f.faine...@gmail.com
Date: Wed, 26 Sep 2012 22:10:08 +0200
Subject: [PATCH 1/2] [tools] firmware-utils: add Linksys WAP4410N image
 creator

---
 tools/firmware-utils/Makefile   |   1 +
 tools/firmware-utils/src/wap4410n.c | 299 
 2 files changed, 300 insertions(+)
 create mode 100644 tools/firmware-utils/src/wap4410n.c

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index a490c9e..9954bea 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -60,6 +60,7 @@ define Host/Compile
 	$(call cc,mkbrnimg)
 	$(call cc,mkdapimg)
 	$(call cc, mkcameofw, -Wall)
+	$(call cc,wap4410n,-lcrypto)
 endef
 
 define Host/Install
diff --git a/tools/firmware-utils/src/wap4410n.c b/tools/firmware-utils/src/wap4410n.c
new file mode 100644
index 000..b438440
--- /dev/null
+++ b/tools/firmware-utils/src/wap4410n.c
@@ -0,0 +1,299 @@
+/*
+ * Cisco/Linksys WAP4410N image creator
+ *
+ * Copyright (C) 2012, Florian Fainelli flor...@openwrt.org
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include inttypes.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include getopt.h
+#include sys/stat.h
+#include sys/types.h
+#include openssl/md5.h
+
+/* Upgrade type is a bitmask, you can combine several upgrades */
+#define UPGRADE_TYPE_AUTO	0x00
+#define UPGRADE_TYPE_KERNEL	0x01
+#define UPGRADE_TYPE_ROOTFS	0x02
+#define UPGRADE_TYPE_BOOTROM	0x10
+#define UPGRADE_TYPE_BOARD_DATA	0x20
+
+#define PID_SIZE		112
+
+struct input_file {
+	const char *name;
+	uint8_t type;
+};
+
+/* valid upgrade types */
+static const struct input_file upgrade_types[] = {
+	{ auto, UPGRADE_TYPE_AUTO },
+	{ kernel, UPGRADE_TYPE_KERNEL },
+	{ rootfs, UPGRADE_TYPE_ROOTFS },
+	{ bootrom, UPGRADE_TYPE_BOOTROM },
+	{ board, UPGRADE_TYPE_BOARD_DATA },
+};
+
+#define ARRAY_SIZE(x)	(sizeof((x)) / sizeof((x[0])))
+
+/* Main header */
+struct lap_hdr {
+	uint32_t	length;
+	uint8_t		upgrade_type;
+} __attribute__ ((__packed__));
+
+/* File descriptors headers */
+struct lap_desc_hdr {
+	uint8_t upgrade_type;
+	uint16_t version;
+	uint32_t length;
+} __attribute__ ((__packed__));
+
+static void usage(void)
+{
+	fprintf(stdout, Usage: mkwap4410n [options]\n
+			-u:	upgrade type (auto, kernel, rootfs, bootrom...)\n
+			-p:	PID file\n
+			-b:	bootrom file\n
+			-k:	kernel file\n
+			-r:	roots file\n
+			-d:	board data file\n
+			-o:	output file\n);
+	exit(EXIT_FAILURE);
+}
+
+static uint8_t parse_upgrade_type(const char *upgrade_type)
+{
+	size_t i;
+
+	for (i = 0; i  ARRAY_SIZE(upgrade_types); i++) {
+		if (!strcmp(upgrade_types[i].name, upgrade_type))
+			return upgrade_types[i].type;
+	}
+
+	return 0xff;
+}
+
+static off_t get_file_size(const char *file)
+{
+	struct stat buf;
+	int ret;
+
+	ret = stat(file, buf);
+	if (ret  0)
+		return 0;
+	else
+		return buf.st_size;
+}
+
+#define MAX_FILES	5
+
+static int create_file(const char *upgrade_type, const char *version,
+			struct input_file *infiles, unsigned int num_infiles,
+			const char *outfile)
+{
+	int ret = 1;
+	char *buf;
+	FILE *fp;
+	struct lap_hdr *lap_hdr;
+	struct lap_desc_hdr *desc_hdr;
+	size_t offset = 0;
+	off_t file_size = 0;
+	MD5_CTX

Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports

[Florian Fainelli]

On 25/02/15 07:24, Alexandru Ardelean wrote:
 Feature implemented and tested on BCM53128.
 
 Slave devices logic copied from the Linux kernel from Marvell's DSA
 driver ( linux/net/dsa/ ).
 Also the logic for the Broadcom tag processing has been copied from there.

There are different efforts here going on, and I would like to at least
3 different people (you, Rafal and myself) can converge to an identical
solution that fits everybody here.

What net-next supports today is:

- broadcom tags in net/dsa/tag_brcm.c, 4-bytes format, identical to
yours AFAICT
- HW bridging support for bcm_sf2 (roboswitch successor)

What's missing:
- adding VLAN configuration, which is what Rafal has been doing using
here: http://thread.gmane.org/gmane.linux.network/351503

There are a number of things that I want to rework in DSA such that we
can almost immediately leverage OpenWrt's switch drivers, where the
entry point is a phy_driver, and have them register as switches (DSA or
something wider) eventually [1], such that DSA handles the slave devices
creation, and also handles the transmission/reception of Broadcom tags
for us. This is work in progress, but I expect the patches would be
ready by the end of this week.

[1]: http://www.spinics.net/lists/netdev/msg295942.html

 
 OpenWRT's eth_mangle_rx/tx() patch/code is being used to tap into
 the packets to/from the ethernet chip since it's convenient.
 
 This code will create lanX (X = 1..B53_N_PORTS) devices.
 All traffic from the ethX device will be forwarded the proper lanX device.
 So, sw_port0_traffic == lan1_traffic and so on.
 
 The slave devices logic has been put into it's own file.
 Should this logic be desired to be extended to swconfig or other
 switch chips, it should be convenient to just move the slave.c/h files.
 
 Note: if enable_vlan == 1, be sure to configure VLAN per lanX device
   in '/etc/config/network'
 
 Signed-off-by: Alexandru Ardelean ardeleana...@gmail.com
 ---
  .../generic/files/drivers/net/phy/b53/Makefile |   2 +-
  .../generic/files/drivers/net/phy/b53/b53_common.c |   3 +
  .../generic/files/drivers/net/phy/b53/b53_hdr.c| 114 +++-
  .../generic/files/drivers/net/phy/b53/b53_priv.h   |   2 +
  .../generic/files/drivers/net/phy/b53/slave.c  | 196 
 +
  .../generic/files/drivers/net/phy/b53/slave.h  |  38 
  6 files changed, 352 insertions(+), 3 deletions(-)
  create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.c
  create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.h
 
 diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile 
 b/target/linux/generic/files/drivers/net/phy/b53/Makefile
 index 6c809f9..c74f82b 100644
 --- a/target/linux/generic/files/drivers/net/phy/b53/Makefile
 +++ b/target/linux/generic/files/drivers/net/phy/b53/Makefile
 @@ -1,5 +1,5 @@
  obj-$(CONFIG_B53)+= b53_common.o
 -obj-$(CONFIG_B53_HDR)+= b53_hdr.o
 +obj-$(CONFIG_B53_HDR)+= b53_hdr.o slave.o
  
  obj-$(CONFIG_B53_PHY_FIXUP)  += b53_phy_fixup.o
  
 diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c 
 b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
 index 9459b22..3da9efe 100644
 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
 +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
 @@ -1377,6 +1377,9 @@ static int b53_global_reset_switch(struct switch_dev 
 *dev)
   priv-enable_management = 0;
  #ifdef CONFIG_B53_HDR
   priv-enable_brcm_hdr = 0;
 + /* Call this function before the memset on the priv-ports, 
 +  * otherwise we may leak devices */
 + b53_unregister_netdevs(priv);
  #endif
  
   memset(priv-vlans, 0, sizeof(priv-vlans) * dev-vlans);
 diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c 
 b/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
 index 2a562a9..8fa7929 100644
 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
 +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
 @@ -21,14 +21,32 @@
  
  #include b53_regs.h
  #include b53_priv.h
 +#include slave.h
  
  /* This tag length is 4 bytes, older ones were 6 bytes, we do not
   * handle them
   */
  #define BRCM_HDR_LEN4
  #define MIN_FRAME_LEN   64
 +#define BRCM_IG_DSTMAP2_MASK 1
 +#define BRCM_IG_DSTMAP1_MASK 0xff
 +#define BRCM_EG_PID_MASK 0x1f
  
 -static struct sk_buff *b53_mangle_tx(struct net_device *dev, struct sk_buff 
 *skb)
 +/* Ingress and egress opcodes */
 +#define BRCM_OPCODE_SHIFT   5
 +
 +static inline void b53_brcm_tag_set(struct sk_buff *skb, int port_idx)
 +{
 + u8 *brcm_tag = skb-data + 2 * ETH_ALEN;
 +
 + brcm_tag[0] = (1  BRCM_OPCODE_SHIFT);
 + brcm_tag[1] = 0;
 + brcm_tag[2] = (port_idx == 8) ? BRCM_IG_DSTMAP2_MASK : 0;
 + brcm_tag[3] = (1  port_idx)  BRCM_IG_DSTMAP1_MASK;
 +}
 +
 +static struct sk_buff *b53_mangle_tx_port(struct net_device *dev,
 + 

Re: [OpenWrt-Devel] raspberry pi v3.19

[Florian Fainelli]

On Feb 9, 2015 4:25 AM, John Crispin blo...@openwrt.org wrote:

 Hi,

 i synced our rpi port with the upstream tree on github. it boots and i
 can see the coloured palette test pic on the hdmi, however ethernet
 fails to come up. i attached a uart just to find out that my rpi is
 either broken or i am connecting it wrong.

 has anyone managed to get uart working ? to my understanding i need to
 connect pin6 to gnd and use 8 and 10 for the 2 data lines. should i see
 output from the bootloader prior to board detecting/loading the sd card

You will not get any UART output prior to the kernel boot, the GPU boot
code does not output anything (at least not in the builds we use).

Could you share the boot log to see if there is anything obvious?


 John
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v1 0/7] Add custom TRX header option

[Florian Fainelli]

On 09/02/15 08:29, Will Sheppard wrote:
 Patchset to essentially add custom TRX header to all firmware produced.
 
 This is most useful for the Belkin routers from my experience. I'm not
 how other trx based firmwares modify the header for their own purposes.
 
 This is applied across the board so that the kernel, trx tools and mtd 
 tools are all compiled with the specified header.
 
 I have modified the kernel specifically for the brcm47xx based boards to
 ensure the mtd parser looks for the correct magic. NOTE: This function will, 
 for other boards, fail.

I don't think this is desirable at all to have, for many reasons:

- how can an use figure out the proper TRX_MAGIC value he/she should use?

- this is extremely error prone and can result, as you mention in
failing to work with existing devices with well-defined TRX headers

- how can we get some level of reproducibility for both the kernel and
firmware tools builds?

I would really encourage you to extend the existing code to take an
arbitrary list of TRX magics, such that you can have maybe a single file
to modify and both mtd and the kernel can use that list of magic
values accordingly.

Out of curiosity, how many different TRX magic values should we have to
support with or without your patches?

 
 Will Sheppard (7):
   config: Add option to specify custom TRX header
   mtd: Add custom trx magic option to mtd tool
   mtd: Fix: Use TRX_MAGIC define not hard-coded number
   trx: Add custom TRX option to trx firmware tool
   mtd: Add debug showing header magic in use
   kernel: bcm47xx: Add custom TRX header option to kernel
   mtd: Fix makefile to work with quilt as per wiki
 
  config/Config-images.in| 15 ++
  package/system/mtd/Makefile|  9 +-
  package/system/mtd/src/trx.c   | 10 +--
  .../patches-3.14/162-Belkin_custom_trx_magic.patch | 35 
 ++
  tools/firmware-utils/Makefile  |  4 +++
  tools/firmware-utils/src/trx.c | 10 ++-
  6 files changed, 79 insertions(+), 4 deletions(-)
  create mode 100644 
 target/linux/brcm47xx/patches-3.14/162-Belkin_custom_trx_magic.patch
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v1 0/7] Add custom TRX header option

[Florian Fainelli]

On 09/02/15 13:12, Will Sheppard wrote:
 Hi - thanks for review; reply inline
 
 On 9 February 2015 at 20:52, Florian Fainelli flor...@openwrt.org
 mailto:flor...@openwrt.org wrote:
 
 On 09/02/15 08:29, Will Sheppard wrote:
  Patchset to essentially add custom TRX header to all firmware produced.
 
  This is most useful for the Belkin routers from my experience. I'm not
  how other trx based firmwares modify the header for their own purposes.
 
  This is applied across the board so that the kernel, trx tools and mtd
  tools are all compiled with the specified header.
 
  I have modified the kernel specifically for the brcm47xx based boards to
  ensure the mtd parser looks for the correct magic. NOTE: This function 
 will,
  for other boards, fail.
 
 I don't think this is desirable at all to have, for many reasons:
 
 - how can an use figure out the proper TRX_MAGIC value he/she should
 use?
 
 
 There's simply no hard-and-fast rule for this - just looking at a
 factory binary might not help - it worked for me. 

That was more of a rhetorical question, since this is not easy, someone
has to do it, and preferably in a way that makes the build reliable for
end-users.

 
 
 - this is extremely error prone and can result, as you mention in
 failing to work with existing devices with well-defined TRX headers
 
 
 Error prone inasmuch as it could be the wrong value and thus brick the
 router? ( I guess I'm always thinking from a have a serial port
 perspective ) 

Error prone on multiple levels: what happens if I wipe-out my original
config and can't remember the correct 32-bits magic value? What if the
option is renamed, what I upgrade the kernel but not mtd, etc...

 
 
 - how can we get some level of reproducibility for both the kernel and
 firmware tools builds?
 
 I would really encourage you to extend the existing code to take an
 arbitrary list of TRX magics, such that you can have maybe a single file
 to modify and both mtd and the kernel can use that list of magic
 values accordingly.
 
 
 I agree. As the mtd utility looks for this value though, it would have
 to know what router it was being used on - i'm not sure that is
 available as a value in user-space is it?

You can certainly extract the board you are running on, but that assumes
you already have a working user-space and kernel, hence the partition
parser needs to work etc... chicken and egg. The alternative, which is
likely what is happening today, is that you need to flash a special
image, with a special magic that only supports a particular set of
boards using a defined TRX magic value, that way you can become (at
least at the MTD level) board agnostic.

 
 
 Out of curiosity, how many different TRX magic values should we have to
 support with or without your patches?
 
 
 I know that Belkin seem to use different magics i.e. not HDR0, I'm not
 sure about other manufacturers. But presumably these values could be
 added as they become known.

That is the direction I would take, just add them one by one such that
you can control exactly when both user-space and kernel space can
properly support a given model (or family of).

 
 
 
  Will Sheppard (7):
config: Add option to specify custom TRX header
mtd: Add custom trx magic option to mtd tool
mtd: Fix: Use TRX_MAGIC define not hard-coded number
trx: Add custom TRX option to trx firmware tool
mtd: Add debug showing header magic in use
kernel: bcm47xx: Add custom TRX header option to kernel
mtd: Fix makefile to work with quilt as per wiki
 
   config/Config-images.in| 15 ++
   package/system/mtd/Makefile|  9 +-
   package/system/mtd/src/trx.c   | 10 +--
   .../patches-3.14/162-Belkin_custom_trx_magic.patch | 35
 ++
   tools/firmware-utils/Makefile  |  4 +++
   tools/firmware-utils/src/trx.c | 10 ++-
   6 files changed, 79 insertions(+), 4 deletions(-)
   create mode 100644
 target/linux/brcm47xx/patches-3.14/162-Belkin_custom_trx_magic.patch
 
 
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to enable EARLY_PRINTK by default on ARM target?

[Florian Fainelli]

Le 14/01/2015 22:54, Rafał Miłecki a écrit :
 I wanted bcm53xx kernels to be compiled with EARLY_PRINTK by default.
 This is safe, we enable earlyprintk using bootargs on tested devices
 only.
 
 So I have config option enabled in default configs:
 grep EARLY_PRINTK target/linux/bcm53xx/config-3.1*
 target/linux/bcm53xx/config-3.14:CONFIG_EARLY_PRINTK=y
 target/linux/bcm53xx/config-3.18:CONFIG_EARLY_PRINTK=y
 
 However it gets overwritten by KERNEL_EARLY_PRINTK defined in
 config/Config-kernel.in.
 
 KERNEL_EARLY_PRINTK:
 1) depends on arm - so non-ARM targets are not affected
 2) default n - which disables it by default

Would not default y if TARGET_bcm53xx achieve what you want here?
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel