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

2019-12-01 Thread 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

2019-07-13 Thread 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

2019-03-19 Thread 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

2018-08-20 Thread 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

2018-06-14 Thread 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

2018-06-14 Thread 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

2018-06-14 Thread 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

2018-05-17 Thread 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

2018-04-03 Thread 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?

2018-03-08 Thread 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

2018-01-17 Thread 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

2018-01-10 Thread 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

2017-10-27 Thread 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

2017-10-22 Thread 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

2017-10-14 Thread 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

2017-10-14 Thread 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

2017-07-23 Thread 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

2017-06-13 Thread 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

2017-05-29 Thread 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

2017-05-22 Thread 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

2017-05-20 Thread 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

2017-05-09 Thread 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

2017-05-08 Thread 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

2017-01-24 Thread 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

2017-01-22 Thread 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

2016-12-21 Thread 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

2016-12-21 Thread 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

2016-11-10 Thread 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

2016-10-21 Thread 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

2016-09-22 Thread 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?

2016-09-19 Thread 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?

2016-09-13 Thread 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?

2016-09-12 Thread 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

2016-07-21 Thread 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

2016-07-01 Thread 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

2016-06-29 Thread 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

2016-02-29 Thread 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

2016-02-10 Thread 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

2016-02-09 Thread 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

2016-02-09 Thread 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

2016-01-13 Thread 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

2015-12-20 Thread 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

2015-12-20 Thread 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

2015-11-07 Thread 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

2015-11-02 Thread 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

2015-10-31 Thread 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

2015-10-29 Thread 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

2015-10-28 Thread 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.

2015-10-28 Thread 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

2015-10-11 Thread 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

2015-10-10 Thread 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

2015-10-09 Thread 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

2015-10-09 Thread 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

2015-10-09 Thread 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

2015-10-09 Thread 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

2015-10-09 Thread 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

2015-09-16 Thread 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

2015-09-13 Thread 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.

2015-09-01 Thread 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.

2015-09-01 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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?

2015-07-25 Thread 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

2015-07-14 Thread 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

2015-07-12 Thread 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

2015-07-11 Thread 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

2015-07-10 Thread 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

2015-07-05 Thread 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

2015-06-22 Thread 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

2015-06-16 Thread 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)

2015-06-14 Thread 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

2015-06-09 Thread 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

2015-06-06 Thread 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

2015-04-25 Thread 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

2015-02-26 Thread 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

2015-02-09 Thread 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

2015-02-09 Thread 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

2015-02-09 Thread 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?

2015-01-25 Thread 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


Re: [OpenWrt-Devel] QEMU 2.0.0

2015-01-21 Thread Florian Fainelli
On 21/01/15 09:08, Ning Ye wrote:
 I am just wondering if anyone maintains QEMU in OpenWRT toolchain.  I want
 to use QEMU 2.0.0 or later as it fixed VHD virtual disk issues.  Of course,
 it has dependency on other library which is not simple to upgrade. That's
 where I am stuck now.  

Right, we don't want to pull in all of these libraries, can you find a
way to build qemu-img only, because this is the only thing we use from a
qemu host-build?

 
 I am currently use QEMU 2.0 separately from OpenWRT build and manually run
 the tools on my Linux Host to convert and generate VHD images.
 
 Any suggestions would be deeply appreciated.  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] feeds.conf.default: add dlan feed

2015-01-21 Thread Florian Fainelli
On 29/12/14 13:53, Michael Heimpold wrote:
 Since mcs814x/dLAN-USB-Extender profile refers to some packages in this
 feed, we should list it here.

blogic was asking whether these packages could be moved to the main
OpenWrt package feed instead, the answer is no, because they are
binary-only packages.

I have added instructions on how to include the feed to the profile in
r44071.

 
 Signed-off-by: Michael Heimpold m...@heimpold.de
 ---
  feeds.conf.default |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/feeds.conf.default b/feeds.conf.default
 index 208342c..16f07d0 100644
 --- a/feeds.conf.default
 +++ b/feeds.conf.default
 @@ -3,6 +3,7 @@ src-git luci https://github.com/openwrt/luci.git
  src-git routing https://github.com/openwrt-routing/packages.git
  src-git telephony https://github.com/openwrt/telephony.git
  src-git management https://github.com/openwrt-management/packages.git
 +src-git dlan https://github.com/ffainelli/dlan-usb-extender-3rd-party.git
  #src-git oldpackages http://git.openwrt.org/packages.git
  #src-svn xwrt http://x-wrt.googlecode.com/svn/trunk/package
  #src-svn phone svn://svn.openwrt.org/openwrt/feeds/phone
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.

2015-01-09 Thread Florian Fainelli
Le 9 janv. 2015 07:09, Vittorio G (VittGam) open...@vittgam.net a écrit
:

 Il 09.01.2015 10:48 John Crispin ha scritto:

 +mkhootoofw.sh $(DL_DIR)/hootoo_mtd_writer $(call
 sysupname,$(1),$(2)) $(call imgname,$(1),$(2))-factory.bin
 +endef +BuildFirmware/HooToo8M/initramfs=$(call
 BuildFirmware/OF/initramfs,$(1),$(2),$(3)) +



 this bit is really bad. you cannot install a binary from a random
 source and use that to flash the unit. the tool needs to be compiled
 during the build process


 Unfortunately the factory image uses an ancient version of uclibc, so
binaries compiled with the newer version bundled with OpenWrt do not work
on it... Anyway I've compiled that binary using the toolchain provided by
HooToo, and the build is reproducible, so you or anybody else can easily
verify that I'm not lying. :)

 Please let me know if you have a better solution, because in fact this is
not quite clean.

What about a statically linked binary at least?


 Cheers,
 Vittorio

 ___
 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 1/3] brcm63xx: add bcm6345-gpio driver

2014-12-15 Thread Florian Fainelli
2014-12-12 6:33 GMT-08:00 Jonas Gorski j...@openwrt.org:
 On Fri, Dec 12, 2014 at 3:17 PM, John Crispin blo...@openwrt.org wrote:


 On 12/12/2014 15:12, Jonas Gorski wrote:
 or the gpio-base problem, we should be able to register appropriate
 platform data for it as OF_DEV_AUXDATA() in of_platform_populate.

 e.g.

 struct bgpio_pdata gpio0_pdata  = {
   .base = 0,
 };

 struct bgpio_pdata gpio1_pdata  = {
   .base = 32,
 };

 tried it for ralink and lantiq and it got nak'ed by LinusW

 i keep that part of the code as a small patch inside owrt on top of the
 stuff i sent upstream.

 Wasn't the objection on putting the gpio base into the dts(i) file
 itself? I explicitly try to avoid that here, as gpio-base is something
 linux internal.

Right that is typically the objection, but with the new gpio
descriptor based API, we should not have that problem anymore, right?


 But It doesn't matter much for now as not even basic DT support is
 upstream, so these won't go anywhere soon.

--
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][RFC] ag71xx_ar7240 add new switch func export_netdevs

2014-12-09 Thread Florian Fainelli
Le 9 déc. 2014 11:22, Alexander Couzens lyn...@fe80.eu a écrit :

 export_netdevs will export a net device for every port. These netdev
represent a port
 with out traffic.
 When such a device is broght down via ifconfig the port is shutdown and
 vice versa. Carrier sense is working too and ethtool can be used to
 control advertise, autoneg, ...

And you just duplicated DSA, which now supports not using a particular
tagging protocol, just network devices for the ethtool control path. Can
you take a look at using DSA and coming up with an ar7240 driver if this is
the direction we want to take here?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] kernel: 3.18: Fix patch 644 dependency chain

2014-11-27 Thread Florian Fainelli
Le 07/11/2014 02:56, Maxime Ripard a écrit :
 This patch introduces some code that is compiled in whenever
 CONFIG_BRIDGE_NETFILTER is built, with the code called from code compiled 
 under
 CONFIG_BRIDGE, CONFIG_BRIDGE_IGMP_SNOOPING or CONFIG_BRIDGE_NF_EBTABLES.
 
 Unfortunately, these options aren't setting explicitly the dependency they now
 have on CONFIG_BRIDGE_NETFILTER, for obvious reasons for CONFIG_BRIDGE.
 
 However, this is not working really well when CONFIG_BRIDGE_NETFILTER is built
 as a module, since code statically compiled will now use a function that is 
 not
 in the kernel image, which makes the linker grumpy.
 
 Solve this by removing the option to build CONFIG_BRIDGE_NETFILTER as a 
 module,
 and protect our function definition by an IS_BUILTIN instead of a IS_ENABLED
 macro. This fixes the issue for CONFIG_BRIDGE and CONFIG_BRIDGE_IGMP_SNOOPING.
 
 Fixing CONFIG_BRIDGE_NF_EBTABLES has to be handled a bit differently, since it
 directly references a variable that will not be declared if
 CONFIG_BRIDGE_NETFILTER is not set. Protect the variable affectations by an
 ifdef to make sure this doesn't happen.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com

Applied in r43419, 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] kernel: 3.18: Fix kmod-ipt-nat

2014-11-23 Thread Florian Fainelli
Le 07/11/2014 07:20, Maxime Ripard a écrit :
 The 3.18 kernel introduced new Kconfig options for the xt_nat and iptable_nat
 kernel modules, that both belong to the ipt_nat kernel package.
 
 Enable this new options.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com

FWIW, applied in r43212.
--
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/2] kernel: Use defconfig instead of full fledged kernel configuration

2014-11-23 Thread Florian Fainelli
Le 18/11/2014 02:27, Maxime Ripard a écrit :
 Hi Felix,
 
 On Sun, Nov 09, 2014 at 11:54:15AM +0100, Felix Fietkau wrote:
 On 2014-11-07 11:58, Maxime Ripard wrote:
 Rely on the Kconfig defconfig mechanism to fill all the missing options,
 instead of needing to set them all in the kernel configurations like what 
 was
 previously done.

 This will allow to trim down a lot the configuration files, avoid carrying
 unused configuration options and preserve the developpers mental health.

 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 I think this is a very good idea. Did you verify on all relevant
 architectures that the resulting kernel config stays the same with this
 change?
 
 I've given a test-run on all the supported architectures, both with
 and without the patch.
 
 It pointed out that there was an incorrect assumption on my side that
 $(ARCH) would be the Linux architecture, which it isn't. A second
 version will follow shortly to address this.

I have not seen a v2 patchset which addresses that? Thanks!

 
 Beside ramips that failed to build on my build machine, and um that
 was missing the needed exception to convert it to the linux
 architecture, the only change in *all* the generated configuration is
 CONFIG_INITRAMFS_SOURCE being at a different location in the file.
 
 Note that this is just with this patch applied, so there was no
 trimmed version of the configuration files involved.
 
 You can find the build logs and kernel configuration files there:
 http://free-electrons.com/~maxime/pub/openwrt/, both with and without
 the patch applied.
 
 Maxime
 
 
 
 ___
 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] Configuring ethernet auto-negotiation off, setting speeds explicitly

2014-11-12 Thread Florian Fainelli
On Nov 11, 2014 6:09 PM, Shankar Unni shankaru...@netscape.net wrote:

 Our box has to deal with a few broken external switches that don't
auto-negotiate properly. (Our box is based on an Intel Rangeley Atom, with
the IGB driver for eth0/1, and we're running BB, more or less - tip of the
barrier_breaker branch).

 Is there any way to disable auto-negotiation on an ethernet interface and
manually set the speed and duplex parameters for it via netifd? (some
equivalent of option autonegotiate 0, etc.?) I couldn't find anything in
netifd that would allow us to specify this directly.  Failing this, are
there any clever tricks that can allow us to do this?

I do not think netifd supports that but one way to do it is to invoke
ethtool. That said, it should not be too hard to patch netifd to send the
ethtool ioctl() to force the speed/duplex/autoneg on a specific interface


 I'm guessing this will come down to writing some hotplug scripts to read
extra configs from /etc/config/network and invoke ethtool manually..

Right that's what I would do, unless you go patch netifd to do that.


 Thanks in advance!
 --
 Shankar Unni.
 ___
 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] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)

2014-10-29 Thread Florian Fainelli

Le 28/10/2014 11:46, Heiner Kallweit a écrit :

After a little more thinking about it and looking at the code I basically have 
two questions:

1.
Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg?
(At least for AR8327 it doesn't get called with an addr != 0 anyway)
Else we could remove ar8xxx_phy_config_aneg and directly register 
genphy_config_aneg as
callback for autoneg configuration.


Address 0 is special, since this is a MDIO broadcast address that will 
usually be handled by switches as write to all front-panel ports.




2.
Call sequence with regard to ar8216 is:
ar8216: ar8xxx_phy_probe
phy: phy_attach_direct
phy: phy_init_hw
ar8216: ar8xxx_phy_config_init
ar8216: ar8xxx_phy_config_aneg

ar8216 driver handles AR8327/AR8337 different from the other supported switch 
types.
ar8xxx_start incl. more detailed configuration is called from ar8xxx_phy_probe 
already.
For the other switch types it's called from ar8xxx_phy_config_init.

I wonder whether doing detailed configuration in the probe stage might be too 
early.
phy_init_hw resets the switch anyway later.
Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited 
however
there might be good reason why it's handled the way it is.


I suppose that you could re-advertise auto-negotiation by calling 
genphy_config_advert() in the config_init routine.




Rgds,
Heiner


Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:

With two different TPLINK routers (both with a AR8327N switch) I faced the 
issue that with
kernel 3.14 certain switch ports used 10MBit/half only.
Under kernel 3.10 everything was fine and the same ports used 1000MBit/full.

As the ar8216 driver is the same I had a look at the common phy code in 
drivers/net/phy.
In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst 3.10 
does not.

The issue turned out to be that when resetting only flag BMCR_RESET is set, not 
BMCR_ANENABLE.
(In ar8216.c always both flags are set when the switch is reset)
Therefore autoneg was not enabled. Also later in the boot process it doesn't 
get enabled.
Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports use 
1000MBit/full.

However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this 
generic phy function.
It might not be appropriate for other phy's.

After resetting the switch later in the boot process ar8xxx_phy_config_aneg is 
called with
phydev-addr being 0.
In this case the function returns immediately. Otherwise it would call 
genphy_config_aneg.
Calling genphy_config_aneg would also solve the problem as it checks for 
BMCR_ANENABLE
being set and sets it if needed.
I don't know the reason why genphy_config_aneg isn't called in case of addr 0.
Or is this a typo and the check actually should be addr != 0 ?

Rgds, Heiner


___
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] [kernel] kernel: add missing symbols for 3.14

2014-10-16 Thread Florian Fainelli
On 10/14/2014 03:59 AM, John Crispin wrote:
 these should really go into the at91 config file. the CONFIG_AT91_*
 ones for sure but most likely also the others.

The others seems like candidate for the generic kernel config to me,
since they are shared by more than one ARM platform.

earlyprintk on ARM is kind of a pita though since you always need to
select which UART implementation/location you want, maybe we should just
remove the earlyprintk selection for ARM entirely.

 
 
 
 
 On 11/10/2014 07:51, John Szakmeister wrote:
 --- Without these, my earlyprintk configuration was being lost.

 -John

 target/linux/generic/config-3.14 | 5 + 1 file changed, 5
 insertions(+)

 diff --git a/target/linux/generic/config-3.14
 b/target/linux/generic/config-3.14 index 830efff..5f16281 100644 
 --- a/target/linux/generic/config-3.14 +++
 b/target/linux/generic/config-3.14 @@ -240,6 +240,8 @@
 CONFIG_ARPD=y # CONFIG_ASYNC_TX_DMA is not set #
 CONFIG_AT76C50X_USB is not set # CONFIG_AT803X_PHY is not set +#
 CONFIG_AT91_DEBUG_LL_DBGU0 is not set +# CONFIG_AT91_DEBUG_LL_DBGU1
 is not set # CONFIG_ATA is not set # CONFIG_ATAGS is not set 
 CONFIG_ATAGS_PROC=y @@ -770,6 +772,9 @@ CONFIG_DEBUG_KERNEL=y #
 CONFIG_DEBUG_KOBJECT_RELEASE is not set # CONFIG_DEBUG_LIST is not
 set # CONFIG_DEBUG_LL is not set +# CONFIG_DEBUG_LL_UART_8250 is
 not set +# CONFIG_DEBUG_LL_UART_NONE is not set +#
 CONFIG_DEBUG_LL_UART_PL01X is not set # CONFIG_DEBUG_LOCKDEP is not
 set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set #
 CONFIG_DEBUG_LOCK_ALLOC is not set

 ___
 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] ffmpeg on au1500 --disable-mips32r2

2014-10-13 Thread Florian Fainelli
2014-10-13 9:16 GMT-07:00 Dirk Neukirchen dirkneukirc...@web.de:
 On 13.10.2014 17:55, Bruno Randolf wrote:
 Hello again,

 ffmpeg tries to automatically enable optimizations for the MIPS
 platform, but for au1500 it automatically enables mips32r2, which this
 CPU does not support.

 For now, I could fix the problem by adding --disable-mips32r2 to
 FFMPEG_CONFIGURE, but again, this is probably not the correct solution
 for all platforms. How should it be done right?

 use appropriate .config symbols (dunno which is the right one) and add 
 something like

 $(if $(CONFIG_TARGET_au1000),--disable-mips32r2)

I would test for CPU_TYPE instead of the target, since au1000 is not
the only one we support which is mips32r1 only. So something like:

$(ifeq $(CONFIG_CPU_TYPE),mips32,--disable-mips32r2) would probably
work just fine. Anything that is mips32r2 sets a different CPU_TYPE,
such as 24kec+dsp, 34kc, 74k or even mips32r2.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] [PATCH V2] [boot] /init: allow easier customisation of ramfs boot.

2014-10-13 Thread Florian Fainelli
2014-10-13 12:44 GMT-07:00 John Crispin blo...@openwrt.org:

 On 13/10/2014 00:03, Stephen Parry wrote:
 /init is the first pid 1 process in an initramfs environment. This fix adds
 lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and 
 exec
 if present. This allows packages to switch root early in the boot process. 
 This
 will help support booting or kexecing from external storage and go some way
 toward fixing ticket #17465.


 the ticket says extroot fails for !mtd. please elaborate on that. i
 would rather we fix extroot to handle this use case rather than build a
 way to bypass extroot

Agreed, should not we standardize on /linuxrc instead of ramfsinit,
even though that is an initramfs, people might get confused even more
with this custom script name.







 Signed-off-by: Stephen Parry sgpa...@mainscreen.com
 ---
 V2: Improved script structure using elif
 ---
  target/linux/generic/base-files/init | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/target/linux/generic/base-files/init 
 b/target/linux/generic/base-files/init
 index 514be57..e80b324 100755
 --- a/target/linux/generic/base-files/init
 +++ b/target/linux/generic/base-files/init
 @@ -1,4 +1,11 @@
  #!/bin/sh
  # Copyright (C) 2006 OpenWrt.org
  export INITRAMFS=1
 -exec /sbin/init
 +
 +if [ -e /bin/ramfsinit ]; then
 + exec /bin/ramfsinit
 +elif [ -e /sbin/ramfsinit ]; then
 + exec /sbin/ramfsinit
 +else
 + exec /sbin/init
 +fi
 ___
 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] cyassl is causing build errors

2014-10-13 Thread Florian Fainelli
2014-10-13 0:20 GMT-07:00 Alive4Ever alive4e...@live.com:
 I've experienced many build errors on bb-14.07 because of cyassl.

Is there a build log somewhere that shows these build failures or is
just download issues at this point?


 For your information, cyassl can't be downloaded directly from its
 official site. There is a form that needs to be filled before Wolfssl
 allows downloading of cyassl-3.2.0.zip. Any attemt to download cyassl
 directly will cause redirection to html download form here.

 http://wolfssl.com/yaSSL/download/downloadForm.php

 To simplify the download process, I suggest preparing pre-downloaded
 cyassl source on OpenWrt mirror and modifying PKG_SOURCE_URL accordingly
 and removing http://www.yassl.com from PKG_SOURCE_URL.

I am not seeing any checkbox for downloading cyassl-3.2.0.zip per se,
so I don't know whether this is a bug on their form, their form is
there because of the cryptography software restrictions that apply to
exporting such technology to other countries.

IANAL, but this export compliance restriction is not necessarily in
contradiction with GPLv2, so it is not as simple as putting their zip
archive on downloads.openwrt.org, by the same token, the agreement
button is about GPLv2, not the export compliance, so we might be just
fine after all with offering an alternate download method.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] support for D-Link DNS-320 NAS (Marvell Kirkwood)

2014-10-05 Thread Florian Fainelli

On 10/05/14 13:32, Tivadar Szemethy wrote:

Hello,

I have created a github fork (
https://github.com/szemtiv/openwrt-dns320.git ) that adds support
(selectable as a profile from Marvell Kirkwood) for the DNS-320 NAS.
Apart from some trivial stuff (based on existing support fot other
Kirkwoods), it has a patch for u-boot, and an userland daemon (scraped
from various parts of the net, with acknowledgements) that controls
the DNS-320 fan in a separate package within Utils.


Could you submit what's missing in the current OpenWrt trunk?

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


Re: [OpenWrt-Devel] some questions/observations about building qemu/malta image

2014-09-29 Thread Florian Fainelli
Hello,

(short emails for separate issues do help BTW)

On 09/29/2014 03:32 PM, Robert P. J. Day wrote:
 
   a few questions about things i ran into today trying to build a qemu
 malta image using the latest git checkout of openwrt -- some are
 admittedly trivial, i just want to make sure i'm understanding
 everything related to them. i started with the config.malta_le config
 file downloaded from openwrt.org.
 
   first, i'm aware that trying to run the pre-built qemu image from
 downloads.openwrt.org will fail with a kernel panic, as explained
 here:
 
   http://wiki.openwrt.org/doc/howto/qemu#openwrt.in.qemu.mips

And as explained in the ticket, get an updated qemu binary to fix that
problem.

 
 so during configuration, i deselected MIPS16 support. i'm not really
 familiar with the MIPS architecture but, as i read it, that support is
 really just an optimization so i can do away with it, yes?

MIPS16 allows compressing instructions, which are usually 32-bits, into
16-bits, increasing cache usage etc...

 
   next, haven't done this yet but to save piles of time, i'm going to
 deselect all config settings of the form:
 
   CONFIG_PACKAGE_...=m
 
 as i understand it, those selections represent packages that will be
 compiled and packaged, but not built into the final rootfs. and, just
 to be clear, while such a final image might be deficient in all sorts
 of features, it should still *theoretically* boot, which is all i care
 about right now.

Correct.

 
   next issue i ran into was this (which looks like a real bug):
 
 make[4]: Entering directory
 '/home/rpjday/openwrt/qemu_malta/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22'
 mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mno-branch-likely -mips32
 -mtune=mips32 -fno-caller-saves -fhonour-copts
 -Wno-error=unused-but-set-variable -msoft-float -mips16
 -minterlink-mips16  -c dump1090.c
 In file included from dump1090.c:31:0:
 dump1090.h:60:25: fatal error: rtl-sdr.h: No such file or directory
  #include rtl-sdr.h
  ^
 compilation terminated.
 Makefile:21: recipe for target 'dump1090.o' failed
 make[4]: *** [dump1090.o] Error 1
 
   not sure what to make of that ... i checked under the build dir and
 there is such a header file at this location:
 
 $ find build_dir/ -name rtl-sdr.h
 build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22/rtlsdr/rtl-sdr.h
 $
 
 is this a known issue? for now, i'll get around it by just
 deselecting the dump1090 package but that shouldn't be necessary.
 should i file a bug report on this?

This is a not a known issue, but really, that's not a necessary package
at all for testing purposes and going to a shell, why not just compile
it out for now?

 
   another issue was one i ran into before and that i reported here:
 
 https://github.com/openwrt/packages/issues/296
 
 a bit later this evening, i'll try applying the patch mentioned there.
 does anyone have any further info on this bug?
 
  finally (and this one is a bit weird), i was trying all of the above
 at a site where the corp firewall did not allow numerous fetching
 protocols, including git, ftp and wget, but i had most of the tarballs
 i needed already so i figured i was in good shape.  not so, it turns
 out.
 
   partway through the build, building gcc just hung, and i tracked it
 down to this:
 
 $ vi 
 build_dir/mipsel_mips32_uClibc-0.9.33.2/gcc-4.8.3/contrib/download_prerequisites
 
 MPFR=mpfr-2.4.2
 GMP=gmp-4.3.2
 MPC=mpc-0.8.1
 
 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1
 tar xjf $MPFR.tar.bz2 || exit 1
 ln -sf $MPFR mpfr || exit 1
 ... snip ...
 
   argh. so, as i read it, there is no way to preload tarballs to get
 around the above, is there? configuring gcc above *requires* net
 access, is that correct?

We should not be executing that make target in the contrib directory, it
sounds highly bogus and we already provide mpfr as a build
pre-requisite, I can take a look at this later though.

 
   anyway, feel free to comment on any of the above. thanks.
 
 rday
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] [kernel/brcm2708] fix for raspberry pi b+

2014-09-27 Thread Florian Fainelli

On 09/25/14 06:54, Morris Winkler wrote:

I attached a fix for package/kernel/brcm2708-gpu-fw/  that i diffed against 
14.07 from git.openwrt.org

it just patches the Makefile to download a newer source revision from 
https://github.com/Hexxeh/rpi-firmware/archive/


i tested that on a raspberry pi b and a b+, i don't have a a version here, 
but i am very confident it will boot too.


Applied a slightly more up to date firmware in r42676, thanks!




Cherrs

Morris Winkler









Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Morris Winkler m.wink...@laydrop.com



___
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] [RFC] Fix VLAN on Atheros AR8327N

2014-09-17 Thread Florian Fainelli
On 08/31/2014 10:42 AM, Jiri Pirko wrote:
 Sat, Jul 19, 2014 at 09:49:38PM CEST, nolt...@gmail.com wrote:
 Commit 40842 reverted the fix for tagged+untagged VLANs on AR8327:
 https://dev.openwrt.org/changeset/40777
 https://dev.openwrt.org/changeset/40842

 According to jow, some people experienced some issues on older devices. 
 Can anyone tell me what were those issues?

 Anyway, that patch modified some parts of the ar8216/ar8236, so I suppose 
 any device with those switches were affected.
 However, I've modified the patch keeping the ar8216/ar8236 as much untouched 
 as possible.
 Could anyone test it on those devices?

 BTW, this works for me on a TP-Link WDR4300 (ar8327).
 
 
 I tested the patch on TL-WR1043ND v2 with Atheros AR8327 rev. 4. Vlans
 are working as expected. Please include this into BB (might need repost)
 
 Thanks!
 
 Tested-by: Jiri Pirko j...@resnulli.us

Unless there are further objections, we should probably just go ahead
and apply this patch since it affects a bunch of users.

 
 

 Signed-off-by: Saverio Proto ziopr...@gmail.com
 Signed-off-by: Álvaro Fernández nolt...@gmail.com
 ---
 diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
 b/target/linux/generic/files/drivers/net/phy/ar8216.c
 index 3846159..9eae624 100644
 --- a/target/linux/generic/files/drivers/net/phy/ar8216.c
 +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
 @@ -78,7 +78,7 @@ struct ar8xxx_chip {
  u32 (*read_port_status)(struct ar8xxx_priv *priv, int port);
  int (*atu_flush)(struct ar8xxx_priv *priv);
  void (*vtu_flush)(struct ar8xxx_priv *priv);
 -void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vid, u32 port_mask);
 +void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vlan);

  const struct ar8xxx_mib_desc *mib_decs;
  unsigned num_mibs;
 @@ -112,7 +112,12 @@ struct ar8327_led {
  enum ar8327_led_pattern pattern;
 };

 +struct ar8216_data {
 +u8 vlan_tagged;
 +};
 +
 struct ar8327_data {
 +u8 vlan_tagged[AR8X16_MAX_VLANS];
  u32 port0_status;
  u32 port6_status;

 @@ -138,6 +143,7 @@ struct ar8xxx_priv {
  u8 chip_rev;
  const struct ar8xxx_chip *chip;
  union {
 +struct ar8216_data ar8216;
  struct ar8327_data ar8327;
  } chip_data;
  bool initialized;
 @@ -159,7 +165,6 @@ struct ar8xxx_priv {
  bool vlan;
  u16 vlan_id[AR8X16_MAX_VLANS];
  u8 vlan_table[AR8X16_MAX_VLANS];
 -u8 vlan_tagged;
  u16 pvid[AR8X16_MAX_PORTS];

  /* mirroring */
 @@ -641,7 +646,7 @@ ar8216_mangle_rx(struct net_device *dev, struct sk_buff 
 *skb)
  port = buf[0]  0xf;

  /* no need to fix up packets coming from a tagged source */
 -if (priv-vlan_tagged  (1  port))
 +if (priv-chip_data.ar8216.vlan_tagged  BIT(port))
  return;

  /* lookup port vid from local table, the switch passes an invalid vlan 
 id */
 @@ -695,10 +700,13 @@ ar8216_vtu_flush(struct ar8xxx_priv *priv)
 }

 static void
 -ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask)
 +ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan)
 {
  u32 op;

 +u32 vid = priv-vlan_id[vlan];
 +u32 port_mask = priv-vlan_table[vlan];
 +
  op = AR8216_VTU_OP_LOAD | (vid  AR8216_VTU_VID_S);
  ar8216_vtu_op(priv, op, port_mask);
 }
 @@ -1705,12 +1713,16 @@ ar8327_vtu_flush(struct ar8xxx_priv *priv)
 }

 static void
 -ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask)
 +ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan)
 {
  u32 op;
  u32 val;
  int i;

 +u32 vid = priv-vlan_id[vlan];
 +u32 port_mask = priv-vlan_table[vlan];
 +u32 tagged = priv-chip_data.ar8327.vlan_tagged[vlan];
 +
  op = AR8327_VTU_FUNC1_OP_LOAD | (vid  AR8327_VTU_FUNC1_VID_S);
  val = AR8327_VTU_FUNC0_VALID | AR8327_VTU_FUNC0_IVL;
  for (i = 0; i  AR8327_NUM_PORTS; i++) {
 @@ -1720,7 +1732,7 @@ ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 
 vid, u32 port_mask)
  mode = AR8327_VTU_FUNC0_EG_MODE_NOT;
  else if (priv-vlan == 0)
  mode = AR8327_VTU_FUNC0_EG_MODE_KEEP;
 -else if (priv-vlan_tagged  BIT(i))
 +else if (tagged  BIT(i))
  mode = AR8327_VTU_FUNC0_EG_MODE_TAG;
  else
  mode = AR8327_VTU_FUNC0_EG_MODE_UNTAG;
 @@ -1734,26 +1746,22 @@ static void
 ar8327_setup_port(struct ar8xxx_priv *priv, int port, u32 egress, u32 
 ingress,
u32 members, u32 pvid)
 {
 -u32 t;
 -u32 mode;
 +u32 mode, t;
 +
 +if (priv-vlan) {
 +pvid = priv-vlan_id[priv-pvid[port]];
 +mode = AR8327_PORT_VLAN1_OUT_MODE_UNMOD;
 +ingress = AR8216_IN_SECURE;
 +} else {
 +pvid = port;
 +mode = AR8327_PORT_VLAN1_OUT_MODE_UNTOUCH;
 +ingress = AR8216_IN_PORT_ONLY;
 +}

  t = pvid  AR8327_PORT_VLAN0_DEF_SVID_S;
  t |= pvid  

Re: [OpenWrt-Devel] [PATCH] at91: USB gadget cleanup

2014-08-18 Thread Florian Fainelli
Hi Owen,

On 08/18/2014 10:48 AM, Owen Kirby wrote:
 It's been a while since I submitted this to the mailing list. Has anyone
 had an opportunity to take a look at this patch? Anything I can do to
 help move it forward?

I have placed it in patchwork as Under review, will probably get it
committed soon since it looks good to me.

Thanks!

 
 Thanks,
 Owen
 
 On 14-06-11 02:38 PM, Owen Kirby wrote:
 The AT91 family of SoCs have a USB device controller, this patch
 should enable the feature
 and cleanup the default config of the at91 target to play nicely with
 the gadget modules.

 kmod-usb-eth-gadget is added as a default module to retain the same
 board functionality as
 before this patch, though, the 'debug' network interface in the
 default config is rather
 useless.

 Signed-off-by: Owen Kirby o...@exegin.com
 ---
 diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile
 index 8340d2a..9aed19f 100644
 --- a/target/linux/at91/Makefile
 +++ b/target/linux/at91/Makefile
 @@ -10,13 +10,13 @@ ARCH:=arm
  BOARD:=at91
  MAINTAINER:=Claudio Mignanti c.migna...@gmail.com
  BOARDNAME:=Atmel AT91
 -FEATURES:=squashfs targz ext2 usb
 +FEATURES:=squashfs targz ext2 usb usbgadget ubifs
  CPU_TYPE:=arm926ej-s

  LINUX_VERSION:=3.10.36

  include $(INCLUDE_DIR)/target.mk

 -DEFAULT_PACKAGES += kmod-usb-ohci
 +DEFAULT_PACKAGES += kmod-usb-ohci kmod-at91-udc kmod-usb-eth-gadget

  $(eval $(call BuildTarget))
 diff --git a/target/linux/at91/config-default
 b/target/linux/at91/config-default
 index e1c90a1..8281458 100644
 --- a/target/linux/at91/config-default
 +++ b/target/linux/at91/config-default
 @@ -236,13 +236,7 @@ CONFIG_UID16=y
  CONFIG_UIDGID_CONVERTED=y
  CONFIG_UNCOMPRESS_INCLUDE=mach/uncompress.h
  # CONFIG_USB_ARCH_HAS_XHCI is not set
 -CONFIG_USB_AT91=y
  CONFIG_USB_COMMON=y
 -CONFIG_USB_ETH=y
 -# CONFIG_USB_ETH_EEM is not set
 -CONFIG_USB_ETH_RNDIS=y
 -CONFIG_USB_GADGET=y
 -CONFIG_USB_LIBCOMPOSITE=y
  CONFIG_USB_SUPPORT=y
  CONFIG_USE_OF=y
  CONFIG_VECTORS_BASE=0x
 diff --git a/target/linux/at91/modules.mk b/target/linux/at91/modules.mk
 index 4678b92..9e82efc 100644
 --- a/target/linux/at91/modules.mk
 +++ b/target/linux/at91/modules.mk
 @@ -50,6 +50,20 @@ endef

  $(eval $(call KernelPackage,at91-adc))

 +define KernelPackage/at91-udc
 +  SUBMENU:=$(USB_MENU)
 +  TITLE:=USB Device on atmel SoC
 +  DEPENDS:=@TARGET_at91 +kmod-usb-gadget
 +  KCONFIG:=CONFIG_USB_AT91
 +  FILES:=$(LINUX_DIR)/drivers/usb/gadget/at91_udc.ko
 +  AUTOLOAD:=$(call AutoLoad,51,at91_udc)
 +endef
 +
 +define KernelPackage/at91-udc/description
 + Kernel module for the USB Device controller for Atmel AT91
 +endef
 +
 +$(eval $(call KernelPackage,at91-udc))

  I2C_AT91_MODULES:=\
CONFIG_I2C_AT91:drivers/i2c/busses/i2c-at91

 ___
 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] kernel module runtime configuration

2014-08-14 Thread Florian Fainelli
Hello Brent,

On 08/14/2014 03:45 PM, Brent Thomson wrote:
 Hey all. I'm working on my first Linux kernel module. It's an
 adaptation of an hd44780-over-GPIO driver. You can see it here:
 
 https://github.com/brnt/openwrt-hd44780
 
 The driver is working fine, but I'd like to allow the user to
 configure which GPIOs are used by the driver. Rather than hard-coding
 the values in the C file (as they're currently done) I'd prefer to
 read values from a config file (or the equivalent). Is there a best
 practice for doing this at the kernel level module? In my googling,
 I've seen comments indicating that reading from files at the kernel
 level is a no-no? I'd prefer not to have to pass commands to insmod
 and instead allow a static file (potentially managed by uci). What's
 the right way to do this?

I believe configfs is the prefered interface for specifying such a
configuration. You could take a look at
target/linux/generic/patches-3.10/863-gpiommc.patch to see how you can
leverage this.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


  1   2   3   4   5   6   7   8   9   10   >