Re: [OpenWrt-Devel] [PATCH 6/8] ramips: improve mt7621 spi chip select

[John Crispin]

2 comments inline

On 11/10/2015 05:54, Michael Lee wrote:
> * use chip select register to control chip select function instead of
>   use chip select polarity
> * should support use gpio as cs pin
> * deselected the spi device when setup and add debug info
> 
> Signed-off-by: Michael Lee 
> ---
>  ...0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch | 95 
> --
>  1 file changed, 68 insertions(+), 27 deletions(-)
> 
> diff --git 
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
>  
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> index d1067ea..1b2476c 100644
> --- 
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> +++ 
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> @@ -25,7 +25,7 @@
>   obj-$(CONFIG_SPI_OC_TINY)   += spi-oc-tiny.o
>  --- /dev/null
>  +++ b/drivers/spi/spi-mt7621.c
> -@@ -0,0 +1,582 @@
> +@@ -0,0 +1,623 @@
>  +/*
>  + * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
>  + *
> @@ -53,6 +53,7 @@
>  +#include 
>  +#include 
>  +#include 
> ++#include 
>  +
>  +#include 
>  +
> @@ -208,30 +209,26 @@
>  +return (prescale << SPIMASTER_CLKSEL_OFFSET);
>  +}
>  +
> -+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
> ++static void mt7621_spi_set_cs(struct spi_device *spi, bool enable)
>  +{
> -+u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> -+
> -+master |= 7 << 29;
> -+master |= 1 << 2;
> -+if (duplex)
> -+master |= 1 << 10;
> -+else
> -+master &= ~(1 << 10);
> ++struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> ++u32 reg;
>  +
> -+mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
> -+}
> ++if (spi->mode & SPI_CS_HIGH)
> ++enable = !enable;
> ++enable = !enable;
>  +
> -+static void mt7621_spi_set_cs(struct spi_device *spi, int enable)
> -+{
> -+struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> -+int cs = spi->chip_select;
> -+u32 polar = 0;
> ++reg = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> ++reg &= ~(SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
>  +
> -+mt7621_spi_reset(rs, cs);
>  +if (enable)
> -+polar = BIT(cs);
> -+mt7621_spi_write(rs, MT7621_SPI_POLAR, polar);
> ++reg |= (spi->chip_select << SPIMASTER_CS_OFFSET);
> ++else {
> ++/* when disable just enable cs 8 instead */
> ++reg |= (SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
> ++}
> ++
> ++mt7621_spi_write(rs, MT7621_SPI_MASTER, reg);
>  +}
>  +
>  +static inline int mt7621_spi_wait_ready(struct mt7621_spi *rs, int len)
> @@ -247,6 +244,47 @@
>  +return -ETIMEDOUT;
>  +}
>  +
> ++static void mt7621_dump_reg(struct spi_master *master, const char *func)
> ++{
> ++struct mt7621_spi *rs = spi_master_get_devdata(master);
> ++
> ++dev_dbg(>dev, "%s trans: %08x, opcode: %08x, data0: %08x, "
> ++"data1: %08x, data2: %08x, data3: %08x, " \
> ++"data4: %08x, data5: %08x, data6: %08x, " \
> ++"data7: %08x, master: %08x, morebuf: %08x, " \
> ++"qctl: %08x, status: %08x, polar: %08x, " \
> ++"space: %08x\n",
> ++func,
> ++mt7621_spi_read(rs, MT7621_SPI_TRANS),
> ++mt7621_spi_read(rs, MT7621_SPI_OPCODE),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 4),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 8),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 12),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 16),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 20),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 24),
> ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 28),
> ++mt7621_spi_read(rs, MT7621_SPI_MASTER),
> ++mt7621_spi_read(rs, MT7621_SPI_MOREBUF),
> ++mt7621_spi_read(rs, MT7621_SPI_QUEUE_CTL),
> ++mt7621_spi_read(rs, MT7621_SPI_STATUS),
> ++mt7621_spi_read(rs, MT7621_SPI_POLAR),
> ++mt7621_spi_read(rs, MT7621_SPI_SPACE));
> ++}

this is an unrelated part in the patch.


> ++
> ++/* copy from spi.c */
> ++static void spi_set_cs(struct spi_device *spi, bool enable)
> ++{
> ++if (spi->mode & SPI_CS_HIGH)
> ++enable = !enable;
> ++
> ++if (spi->cs_gpio >= 0)
> ++gpio_set_value(spi->cs_gpio, !enable);
> ++else if (spi->master->set_cs)
> ++spi->master->set_cs(spi, !enable);
> ++}
> ++
>  +static int mt7621_spi_transfer_half_duplex(struct spi_master *master,
>  +   struct spi_message *m)
>  +{
> @@ -297,7 +335,7 @@
>  +

Re: [OpenWrt-Devel] [PATCH 6/8] ramips: improve mt7621 spi chip select

[Mingyu Li]

i have mention "add debug info" on comment. or you suggest me
move the debug info into another patch.

about num_chipselect. now we should use gpio pin as chip select
pin. so there is no limit on num_chipselect. we can connect more
spi devices by using gpio pin as chip select pin. you can check
spi_set_cs function.

2015-10-14 12:24 GMT+08:00 John Crispin :

> 2 comments inline
>
> On 11/10/2015 05:54, Michael Lee wrote:
> > * use chip select register to control chip select function instead of
> >   use chip select polarity
> > * should support use gpio as cs pin
> > * deselected the spi device when setup and add debug info
> >
> > Signed-off-by: Michael Lee 
> > ---
> >  ...0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch | 95
> --
> >  1 file changed, 68 insertions(+), 27 deletions(-)
> >
> > diff --git
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > index d1067ea..1b2476c 100644
> > ---
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > +++
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > @@ -25,7 +25,7 @@
> >   obj-$(CONFIG_SPI_OC_TINY)   += spi-oc-tiny.o
> >  --- /dev/null
> >  +++ b/drivers/spi/spi-mt7621.c
> > -@@ -0,0 +1,582 @@
> > +@@ -0,0 +1,623 @@
> >  +/*
> >  + * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
> >  + *
> > @@ -53,6 +53,7 @@
> >  +#include 
> >  +#include 
> >  +#include 
> > ++#include 
> >  +
> >  +#include 
> >  +
> > @@ -208,30 +209,26 @@
> >  +return (prescale << SPIMASTER_CLKSEL_OFFSET);
> >  +}
> >  +
> > -+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
> > ++static void mt7621_spi_set_cs(struct spi_device *spi, bool enable)
> >  +{
> > -+u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> > -+
> > -+master |= 7 << 29;
> > -+master |= 1 << 2;
> > -+if (duplex)
> > -+master |= 1 << 10;
> > -+else
> > -+master &= ~(1 << 10);
> > ++struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> > ++u32 reg;
> >  +
> > -+mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
> > -+}
> > ++if (spi->mode & SPI_CS_HIGH)
> > ++enable = !enable;
> > ++enable = !enable;
> >  +
> > -+static void mt7621_spi_set_cs(struct spi_device *spi, int enable)
> > -+{
> > -+struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> > -+int cs = spi->chip_select;
> > -+u32 polar = 0;
> > ++reg = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> > ++reg &= ~(SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
> >  +
> > -+mt7621_spi_reset(rs, cs);
> >  +if (enable)
> > -+polar = BIT(cs);
> > -+mt7621_spi_write(rs, MT7621_SPI_POLAR, polar);
> > ++reg |= (spi->chip_select << SPIMASTER_CS_OFFSET);
> > ++else {
> > ++/* when disable just enable cs 8 instead */
> > ++reg |= (SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
> > ++}
> > ++
> > ++mt7621_spi_write(rs, MT7621_SPI_MASTER, reg);
> >  +}
> >  +
> >  +static inline int mt7621_spi_wait_ready(struct mt7621_spi *rs, int len)
> > @@ -247,6 +244,47 @@
> >  +return -ETIMEDOUT;
> >  +}
> >  +
> > ++static void mt7621_dump_reg(struct spi_master *master, const char
> *func)
> > ++{
> > ++struct mt7621_spi *rs = spi_master_get_devdata(master);
> > ++
> > ++dev_dbg(>dev, "%s trans: %08x, opcode: %08x, data0: %08x, "
> > ++"data1: %08x, data2: %08x, data3: %08x, " \
> > ++"data4: %08x, data5: %08x, data6: %08x, " \
> > ++"data7: %08x, master: %08x, morebuf: %08x, " \
> > ++"qctl: %08x, status: %08x, polar: %08x, " \
> > ++"space: %08x\n",
> > ++func,
> > ++mt7621_spi_read(rs, MT7621_SPI_TRANS),
> > ++mt7621_spi_read(rs, MT7621_SPI_OPCODE),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 4),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 8),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 12),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 16),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 20),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 24),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 28),
> > ++mt7621_spi_read(rs, MT7621_SPI_MASTER),
> > ++mt7621_spi_read(rs, MT7621_SPI_MOREBUF),
> > ++mt7621_spi_read(rs, MT7621_SPI_QUEUE_CTL),
> > ++mt7621_spi_read(rs, MT7621_SPI_STATUS),
> > ++mt7621_spi_read(rs, MT7621_SPI_POLAR),
> > ++mt7621_spi_read(rs, 

Re: [OpenWrt-Devel] proto 'none' overwriting tun interfaces

[Roman Yeryomin]

On 13 October 2015 at 03:16,   wrote:
> Hi all,
>
> I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and 
> now a WD MyNet N750) for a number of years. I just recently encountered a 
> problem with the OpenVPN tun interfaces are showing up without IP addresses 
> after a reboot. I have the following in my /etc/config/network:
>
> config interface 'vpn_udp'
> option ifname 'tun0'
> option proto 'none'
>
> config interface 'vpn_tcp'
> option ifname 'tun1'
> option proto 'none'
>

Why do you use proto=none?
Isn't it supposed to be used to actually disable/deconfigure that interface?

Regards,
Roman
___
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

[Roman Yeryomin]

On 13 October 2015 at 10:50, Bruno Randolf  wrote:
> On 10/12/2015 10:53 PM, Felix Fietkau wrote:
>>> git describe
>>>
>>> r-35387-g83c5a41
>>>
>>> If you prefer, cut the last part and get "r-35387".
>>>
>>> Looks familiar? Now you even have real linear numbering in each branch,
>>> without the gaps you get when committing to different branches in SVN +
>>> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
>>>
>>> Of course "r" is just an example to show the familiarity with SVN
>>> revisions, you could choose whatever seems fit, for example at this
>>> moment it would make sense to tag the moment when 15.05 was branched off
>>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
>>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
>>> use "git describe --tags" because the tag was not created with -a).
>>
>> That looks quite interesting. The issue I see with that is if somebody
>> adds a local commit on top and builds the tree, the number behind 'r' is
>> misleading and the hash is useless.
>
> Right, I see, the ambiguous numbering with local commits may be a weak
> point. But then, if you don't find the hash in the OpenWRT git, you also
> know that it's not a clean copy of trunk and that's also valuable
> information. People should report bugs from clean trunk, not containing
> random, unknown, additional commits.
>

and then, again, if a user is able to commit something usually that
means he is able to understand that reporting his local changes
doesn't make sense.
Though, I still think that appropriate, meaningful tags will be a
better option to just r (which would be just svn legacy).
Not sure but probably both options could be used in parallel.

Regards,
Roman
___
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

[Roman Yeryomin]

On 13 October 2015 at 00:18, Bruno Randolf  wrote:
> On 10/12/2015 03:22 PM, Felix Fietkau wrote:
 When using tags as a starting point (via git describe), somebody has to
 create those tags, which is cumbersome (and would mean adding lots of
 useless ones).
>>>
>>> What's cumbersome? And why would you have to create useless tags?
>>>
>> Many people follow current trunk, and we need to have precise version
>> information for that when they report a bug. We don't want to regularly
>> tag stuff just to keep reported version information up to date.
>
> You don't need to. Try this in your OpenWRT trunk git repo:
>
> git tag -a r 753606a51c979440e10771f0d11494b7b7c1eac2
>
> (Tagging the very first commit with "r".)
>
> Now do:
>
> git describe
>
> r-35387-g83c5a41
>

Bruno, +100500!
___
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

[Bruno Randolf]

On 10/12/2015 10:53 PM, Felix Fietkau wrote:
>> git describe
>>
>> r-35387-g83c5a41
>>
>> If you prefer, cut the last part and get "r-35387".
>>
>> Looks familiar? Now you even have real linear numbering in each branch,
>> without the gaps you get when committing to different branches in SVN +
>> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
>>
>> Of course "r" is just an example to show the familiarity with SVN
>> revisions, you could choose whatever seems fit, for example at this
>> moment it would make sense to tag the moment when 15.05 was branched off
>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
>> use "git describe --tags" because the tag was not created with -a).
>
> That looks quite interesting. The issue I see with that is if somebody
> adds a local commit on top and builds the tree, the number behind 'r' is
> misleading and the hash is useless.

Right, I see, the ambiguous numbering with local commits may be a weak
point. But then, if you don't find the hash in the OpenWRT git, you also
know that it's not a clean copy of trunk and that's also valuable
information. People should report bugs from clean trunk, not containing
random, unknown, additional commits.

bruno
___
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

[Roman Yeryomin]

On 12 October 2015 at 22:21, Jonathan Bennett  wrote:
>
>
> On Mon, Oct 12, 2015 at 2:11 PM David Lang  wrote:
>>
>> On Mon, 12 Oct 2015, Felix Fietkau wrote:
>>
>> > On 2015-10-12 16:11, Roman Yeryomin wrote:
>> >> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
>> >>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>>  Right now, the revision number (r) is really useful to
>>  figure
>>  out what particular openwrt version is being used, when people
>>  report
>>  bugs. The commit hash cannot be used as a replacement, since it
>>  might be
>>  one that isn't present in the official repo.
>>  When using tags as a starting point (via git describe), somebody
>>  has to
>>  create those tags, which is cumbersome (and would mean adding
>>  lots of
>>  useless ones).
>> 
>>  The tags would be the major versions and RCs. I don't believe other
>>  tags
>>  should be used.
>> 
>>  Apart from that, I understand that if someone cloned the SVN repo
>>  (full
>>  svn history), created it's own server, and developed on top of a
>>  given
>>  revision X, the same problem would arise.
>> >>> I haven't seen a single instance of somebody doing this, and in my
>> >>> opinion it would be kind of stupid anyway :)
>> >>> We don't even advertise the SVN server URL to users anymore for a
>> >>> reason.
>> >>>
>> >>
>> >> IMO git describe --dirty would work perfectly. You would see a short
>> >> hash and if user modified it or not.
>> > If the user made a local commit, the short hash becomes useless.
>>
>> if the user does a SVN checkout and then modifies things, the r is
>> also
>> not valid (although it does give you an idea where things branched)
>>
>> David Lang
>
> His point is that users don't ever do an SVN checkout. Because the r number
> is baked into the image, it's a really easy and obvious way for an end user
> to report the revision in a bug report.  I can see the advantage in this.
> If we are to move to git, we would want some way to preserve this feature,
> that is a super easy way for a user to report the revision.  We could bake
> the short hash into the image, but this would not be useful if any commits
> were added locally, whereas the r number would still show some useful
> information.
>
> Would it be possible to track the revision number in an automated way even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might address
> the problem.
>

If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.

Regards,
Roman
___
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 / paid patch-checking

[Sorin Burjan]

Hello Kaloz,

is there any initiative to create a non-profit organization ?

Regards,
Sorin B.

On Tue, Oct 13, 2015 at 1:44 PM, Imre Kaloz  wrote:

> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
>  wrote:
>
> 
>
> It should be easy possible to get funding from all the companies which
>> work with OpenWrt. Is this in option?
>>
>
> Not until we have a nonprofit organization as companies can't have tax
> deduction in exchange.. This is pretty much the main issue people from said
> companies brought up at the summit as well.
>
>
> Imre
>
> ___
> 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] SVN to GIT transition / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
 wrote:




It should be easy possible to get funding from all the companies which
work with OpenWrt. Is this in option?


Not until we have a nonprofit organization as companies can't have tax  
deduction in exchange.. This is pretty much the main issue people from  
said companies brought up at the summit as well.



Imre
___
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 / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:46:00 +0200, Sorin Burjan   
wrote:



Hello Kaloz,

is there any initiative to create a non-profit organization ?


We're looking into this as well other options ;)


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

Re: [OpenWrt-Devel] proto 'none' overwriting tun interfaces

[Adam Gensler]

> On Oct 13, 2015, at 4:50 AM, Roman Yeryomin  wrote:
> 
> On 13 October 2015 at 03:16,   wrote:
>> Hi all,
>> 
>> I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and 
>> now a WD MyNet N750) for a number of years. I just recently encountered a 
>> problem with the OpenVPN tun interfaces are showing up without IP addresses 
>> after a reboot. I have the following in my /etc/config/network:
>> 
>> config interface 'vpn_udp'
>>option ifname 'tun0'
>>option proto 'none'
>> 
>> config interface 'vpn_tcp'
>>option ifname 'tun1'
>>option proto 'none'
>> 
> 
> Why do you use proto=none?
> Isn't it supposed to be used to actually disable/deconfigure that interface?


I use proto=none because I don't want OpenWRT doing anything to the tun 
interfaces, which had been working for several years.

There's a separate "enabled" option that can be used to toggle interfaces 
on/off.


> 
> Regards,
> Roman
___
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 / paid patch-checking

[edgar . soldin]

On 13.10.2015 12:44, Imre Kaloz wrote:
> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
>  wrote:
> 
> 
> 
>> It should be easy possible to get funding from all the companies which
>> work with OpenWrt. Is this in option?
> 
> Not until we have a nonprofit organization as companies can't have tax 
> deduction in exchange.. This is pretty much the main issue people from said 
> companies brought up at the summit as well.
> 
> 

how about said companies simply employ(part time even)/pay core devs for 
working on openwrt? 

if they really want to give back tax deductability shouldn't be an issue. there 
are costs of business that are not deductible. why should openwrt people be 
forced into forming/maintaining organizational infrastructure, when they could 
spend that time enhancing openwrt instead.

..ede
___
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 / paid patch-checking

[Nemesis]

As far as I remember, there's no initiative going on, but the issue was
brought up at the summit by different speakers.

There was also a quick poll:

1. Kathy Giori asked the attendees to raise their hand if they backed
the idea of an OpenWRT foundation
I would say half of the presents raised their hands (I did not because
I'm not involved so much in OpenWRT and I don't feel entitled to take sides)

2. Kathy asked the attendees to raise their hand if they opposed the
idea of an OpenWRT foundation
I think there were almost no raised hands or not at all

Federico


On 10/13/2015 12:46 PM, Sorin Burjan wrote:
> Hello Kaloz,
>
> is there any initiative to create a non-profit organization ?
>
> Regards,
> Sorin B.
>
> On Tue, Oct 13, 2015 at 1:44 PM, Imre Kaloz  > wrote:
>
> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
> > wrote:
>
> 
>
> It should be easy possible to get funding from all the
> companies which
> work with OpenWrt. Is this in option?
>
>
> Not until we have a nonprofit organization as companies can't have
> tax deduction in exchange.. This is pretty much the main issue
> people from said companies brought up at the summit as well.
>
>
> Imre
>
> ___
> 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

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

[OpenWrt-Devel] [PATCH] musl: add upstream patch for open_[w]memstream

[Maxim Storchak]

This patch fixes corner case in open_memstrem, when stream is created,
but nothing is written.
This case is present in tgtadm, tgtd management tool.

Signed-off-by: Maxim Storchak 
---
 .../musl/patches/020-upstream_open_memstream.patch | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 toolchain/musl/patches/020-upstream_open_memstream.patch

diff --git a/toolchain/musl/patches/020-upstream_open_memstream.patch 
b/toolchain/musl/patches/020-upstream_open_memstream.patch
new file mode 100644
index 000..3d14404
--- /dev/null
+++ b/toolchain/musl/patches/020-upstream_open_memstream.patch
@@ -0,0 +1,79 @@
+From 7b9f57f207b51132f188f750161953b7baf32154 Mon Sep 17 00:00:00 2001
+From: Rich Felker 
+Date: Thu, 8 Oct 2015 22:03:53 +
+Subject: fix open_[w]memstream behavior when no writes take place
+
+the specification for these functions requires that the buffer/size
+exposed to the caller be valid after any successful call to fflush or
+fclose on the stream. the implementation's approach is to update them
+only at flush time, but that misses the case where fflush or fclose is
+called without any writes having taken place, in which case the write
+flushing callback will not be called.
+
+to fix both the observable bug and the desired invariant, setup empty
+buffers at open time and fail the open operation if no memory is
+available.
+---
+ src/stdio/open_memstream.c  | 11 +--
+ src/stdio/open_wmemstream.c | 11 +--
+ 2 files changed, 18 insertions(+), 4 deletions(-)
+
+diff --git a/src/stdio/open_memstream.c b/src/stdio/open_memstream.c
+index 58504c9..eab024d 100644
+--- a/src/stdio/open_memstream.c
 b/src/stdio/open_memstream.c
+@@ -59,14 +59,21 @@ FILE *open_memstream(char **bufp, size_t *sizep)
+ {
+   FILE *f;
+   struct cookie *c;
++  char *buf;
++
+   if (!(f=malloc(sizeof *f + sizeof *c + BUFSIZ))) return 0;
++  if (!(buf=malloc(sizeof *buf))) {
++  free(f);
++  return 0;
++  }
+   memset(f, 0, sizeof *f + sizeof *c);
+   f->cookie = c = (void *)(f+1);
+ 
+   c->bufp = bufp;
+   c->sizep = sizep;
+-  c->pos = c->len = c->space = 0;
+-  c->buf = 0;
++  c->pos = c->len = c->space = *sizep = 0;
++  c->buf = *bufp = buf;
++  *buf = 0;
+ 
+   f->flags = F_NORD;
+   f->fd = -1;
+diff --git a/src/stdio/open_wmemstream.c b/src/stdio/open_wmemstream.c
+index 7ab2c64..4d90cd9 100644
+--- a/src/stdio/open_wmemstream.c
 b/src/stdio/open_wmemstream.c
+@@ -61,14 +61,21 @@ FILE *open_wmemstream(wchar_t **bufp, size_t *sizep)
+ {
+   FILE *f;
+   struct cookie *c;
++  wchar_t *buf;
++
+   if (!(f=malloc(sizeof *f + sizeof *c))) return 0;
++  if (!(buf=malloc(sizeof *buf))) {
++  free(f);
++  return 0;
++  }
+   memset(f, 0, sizeof *f + sizeof *c);
+   f->cookie = c = (void *)(f+1);
+ 
+   c->bufp = bufp;
+   c->sizep = sizep;
+-  c->pos = c->len = c->space = 0;
+-  c->buf = 0;
++  c->pos = c->len = c->space = *sizep = 0;
++  c->buf = *bufp = buf;
++  *buf = 0;
+ 
+   f->flags = F_NORD;
+   f->fd = -1;
+-- 
+cgit v0.11.2
+
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Did CONFIG_NATIVE_TOOLCHAIN ever work?

[Zefir Kurtisi]

Hi all,

could someone confirm that building packages with the native toolchain ever 
worked?

At my side (x86_64 / gcc (Ubuntu 5.2.1-21ubuntu2) 5.2.1 20151003) I observe an
error and upon reading the scripts to me it looks it can't work as is.

To reproduce in git HEAD:
1. configure
  * target: x86
  * subtarget: x86_64
  * Advanced configuration options (for developers)
-> Use external toolchain
   -> Use host's toolchain *
2. prepare toolchain
  * run: make toolchain/prepare V=s
  * observe error:
> make[2]: Entering directory './openwrt.git/toolchain/wrapper'
> Testing external toolchain for ipv6 support ... Toolchain directory 
> '--cflags' does not exist.
> failed
> ERROR: CONFIG_IPV6 is enabled but the external toolchain does not support it
> Makefile:62: recipe for target 
> './openwrt.git/build_dir/toolchain-x86_64-linux-gnu/wrapper-1/.prepared' 
> failed
> make[2]: *** 
> [./openwrt.git/build_dir/toolchain-x86_64-linux-gnu/wrapper-1/.prepared] 
> Error 1
> make[2]: Leaving directory './openwrt.git/toolchain/wrapper'


Trying to dig into the problem, the issue is
1) toolchain/wrapper/Makefile calls
   $(SCRIPT_DIR)/ext-toolchain.sh --toolchain $(CONFIG_TOOLCHAIN_ROOT)
2) --toolchain is a mandatory parameter
3) but CONFIG_TOOLCHAIN_ROOT is never set


If I append 'CONFIG_TOOLCHAIN_ROOT="/usr"' to the .config file, the
toolchain/wrapper build succeeds, but the build breaks in later stages. 
Therefore
I assume I must be missing something.


Could somebody confirm that the native toolchain build is working?


Thanks,
Zefir
___
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 / paid patch-checking

[Bastian Bittorf]

* Nemesis  [12.10.2015 12:17]:
> The Django Framework moved from SVN to github in 2012but they kept their
> own bug tracker (which they redesigned with some funding to make it more
> usable): https://code.djangoproject.com/
> 
> I think they're a good example of an open source community which went
> through the process of improving the way people can join the community
> and contribute, they also raise funds to pay for hard tasks like
> redesigning the website, organizing sprints, periodically hire a
> "fellow" which reviews (accepts/closes and occasionally fixes) tickets
> and so on.
> Since they started doing this django has improved massively.

I think that is a good point. The active OpenWrt-Team seems
to consist of 3-4 people. Has somebody of them considered to work
fulltime for the project? This way the always growing Patchwork (~100
open patches) and Ticketsystem (>3000 open Tickets) would benefit.

It should be easy possible to get funding from all the companies which
work with OpenWrt. Is this in option?

bye, bastian
___
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 / paid patch-checking

[Daniel Golle]

Hi!

On Tue, Oct 13, 2015 at 01:22:14PM +0200, Emmanuel Deloget wrote:
> On Tue, Oct 13, 2015 at 1:04 PM, Nemesis  wrote:
> > As far as I remember, there's no initiative going on, but the issue was 
> > brought up at the summit by different speakers.
> >
> > There was also a quick poll:
> >
> > 1. Kathy Giori asked the attendees to raise their hand if they backed the 
> > idea of an OpenWRT foundation
> > I would say half of the presents raised their hands (I did not because I'm 
> > not involved so much in OpenWRT and I don't feel entitled to take sides)
> >
> > 2. Kathy asked the attendees to raise their hand if they opposed the idea 
> > of an OpenWRT foundation
> > I think there were almost no raised hands or not at all

I believe it's important to note that OpenWrt got quite a lot of users
and contributers who aren't commercially motivated and probably didn't
feel the need to come to an industry-funded summit in first place.
Many here got their roots in the wifi-mesh communities, ie. they are
activists and afaik most of OpenWrt was created as a leasure/hobby
activity. (correct me if that's terribly wrong)
Sure, now that even chip vendors use OpenWrt as the base of their SDKs
and major industry players provide OpenWrt-based BSPs the situation
has certainly changed.
However, I believe the extraordinarily high quality of the code was and
is only possible due to the lack of commercial pressure and because
things were done when people liked to do them and took as long as they
would take (rather than doing stuff you don't feel like doing in that
moment because of some dead-line or commercially motivated commitment)
Quality[1] itself can be quite a good motivator for many of us, and is
imho impossible to achieve if driven by anything but passion and love
for the matter and activity itself (that doesn't mean that it's bad
to be paid for good work, there's nothing wrong with that).
Being a software engineer myself, I'm aware that this is not what $corp
managers believe, and surely, it's still hard work to build something
and most people do need to get paid for at least some of their work in
order to have a good live and not needing to starve.

But yet, it's like comparing arts with advertisement or love with
prostitution. Given these extreme examples, almost everyone can
grasp the difference in quality I'm talking about which also applies
here.

If you want an industry-driven fork, go ahead. But don't force that
model upon an existing community without understanding how major parts
of that said community is operating.
Sure, we can all use funding :)
But my mode-of-operation doesn't have a price-tag on it.
I hope that applies also to the decission-making of most long-term
contributers.


> 
> Wouldn't it be easier if the project is adopted by an umbrella
> organization? There should be one that could be interested in managing
> the pitfalls and dirty bits of the organization, allowing the
> developers to spend their time on the project itself - and not on the
> maintenance of a foundation.

However, I'm happy we are arriving at the core of that matter. It's
(as usual among the technical croud) hidden behind a technical debate,
in this case git vs. subversion.
However, what it is really about is the mode of decission-making and
commercial usability and reliability.

It's ok to use our music, but don't tell anyone how to play.
And sure, feel free to find the magic hat :)


Cheers


Daniel


 [1]: https://en.wikipedia.org/wiki/Pirsig's_metaphysics_of_Quality
___
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

[José Vázquez]

2015-10-09 22:52 GMT+02:00, Álvaro Fernández Rojas :
> Not yet, also my patches for the kernel are based on yours, so maybe you
> should submit them, since you were the first one to implement the support.
> BTW, I boot tested bmips on BCM3380 with the following changes:
> https://github.com/openwrt-es/openwrt/commit/3c72e4dc2b2bf21f3b1a7ef412fdb60753febae1
> https://github.com/openwrt-es/openwrt/commits/bmips-4.1
> But I have to say it's painfully slow, because it takes like 150s to
> fully boot on 1 CPU and 400+ on 2CPU :/.
>
> And about bmips target, Jonas wants to add it as a brcm63xx subtarget in
> the future.
>
> Regards,
> Álvaro.
>
According to the CG3100 source code the BCM3380 uses only spi flash
and does not have hsspi but legacy spi like 6368, 6358 and others, but
with a max speed of 25MHz, which is not defined in .
This is a piece of code found in spiflash.c:

#if defined(CONFIG_BCM93380)
spi_flash_busnum = LEG_SPI_BUS_NUM;
spi_flash_clock = 2500;
#endif
#if defined(CONFIG_BCM93383)
spi_flash_busnum = HS_SPI_BUS_NUM;
#endif

IMHO bcm63xx patches #345 and #411 are related with the slow boot
speed you are experiencing. I have no idea if BCM3380 supports other
spi clocks.

Regards:

Pepe
___
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 / paid patch-checking

[Emmanuel Deloget]

Hello,

On Tue, Oct 13, 2015 at 1:04 PM, Nemesis  wrote:
>
> As far as I remember, there's no initiative going on, but the issue was 
> brought up at the summit by different speakers.
>
> There was also a quick poll:
>
> 1. Kathy Giori asked the attendees to raise their hand if they backed the 
> idea of an OpenWRT foundation
> I would say half of the presents raised their hands (I did not because I'm 
> not involved so much in OpenWRT and I don't feel entitled to take sides)
>
> 2. Kathy asked the attendees to raise their hand if they opposed the idea of 
> an OpenWRT foundation
> I think there were almost no raised hands or not at all

Wouldn't it be easier if the project is adopted by an umbrella
organization? There should be one that could be interested in managing
the pitfalls and dirty bits of the organization, allowing the
developers to spend their time on the project itself - and not on the
maintenance of a foundation.

> Federico
>

BR,

-- Emmanuel Deloget
___
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 / paid patch-checking

[Bastian Bittorf]

* Daniel Golle  [13.10.2015 16:53]:
> If you want an industry-driven fork, go ahead. But don't force that
> model upon an existing community without understanding how major parts
> of that said community is operating.

What I see since a long time, is that there is simply not
enough manpower for reviewing patches and "simple" maintainance
work (trac, buildbots) and this more and more leads to an unhappy
community and overloaded devs.

commercial pressure is'nt good, i agree - but maybe there is
a way to have at least 1 fulltime or 2 parttime devs.

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

[OpenWrt-Devel] [PATCH] generic: add 8139cp fixes, enable hardware csum/tso on 4.0+

[David Woodhouse]

This contains two sets of fixes for the 8139cp driver.

For all kernel versions older than 4.3, we can apply the fixes from the
4.3-rc4 kernel. In particular, these fix the TX timeout recovery which
is causing my Geos to lock up until the hardware watchdog kicks in.

For 4.0 and later kernels, we can also apply the additional improvements
which are going into 4.4 to fix and enable hardware checksum/TSO
offload. Backporting those to older kernels is non-trivial.

Signed-off-by: David Woodhouse 
---
 .../patches-3.18/760-8139cp-fixes-from-4.3.patch   | 367 +
 .../patches-4.0/760-8139cp-fixes-from-4.3.patch| 367 +
 .../patches-4.0/761-8139cp-fixes-from-4.4.patch| 105 ++
 .../patches-4.1/760-8139cp-fixes-from-4.3.patch| 367 +
 .../patches-4.1/761-8139cp-fixes-from-4.4.patch| 105 ++
 .../patches-4.3/761-8139cp-fixes-from-4.4.patch| 105 ++
 6 files changed, 1416 insertions(+)
 create mode 100644 
target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch
 create mode 100644 
target/linux/generic/patches-4.0/760-8139cp-fixes-from-4.3.patch
 create mode 100644 
target/linux/generic/patches-4.0/761-8139cp-fixes-from-4.4.patch
 create mode 100644 
target/linux/generic/patches-4.1/760-8139cp-fixes-from-4.3.patch
 create mode 100644 
target/linux/generic/patches-4.1/761-8139cp-fixes-from-4.4.patch
 create mode 100644 
target/linux/generic/patches-4.3/761-8139cp-fixes-from-4.4.patch

diff --git a/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch 
b/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch
new file mode 100644
index 000..de4c127
--- /dev/null
+++ b/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch
@@ -0,0 +1,367 @@
+commit 41b976414c88016e2c9d9b2f6667ee67a998d388
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:45:31 2015 +0100
+
+8139cp: Dump contents of descriptor ring on TX timeout
+
+We are seeing unexplained TX timeouts under heavy load. Let's try to get
+a better idea of what's going on.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 7f4c685633e2df9ba10d49a31dda13715745db37
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:45:16 2015 +0100
+
+8139cp: Fix DMA unmapping of transmitted buffers
+
+The low 16 bits of the 'opts1' field in the TX descriptor are supposed
+to still contain the buffer length when the descriptor is handed back to
+us. In practice, at least on my hardware, they don't. So stash the
+original value of the opts1 field and get the length to unmap from
+there.
+
+There are other ways we could have worked out the length, but I actually
+want a stash of the opts1 field anyway so that I can dump it alongside
+the contents of the descriptor ring when we suffer a TX timeout.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 0a5aeee0b79fa99d8e04c98dd4e87d4f52aa497b
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:57 2015 +0100
+
+8139cp: Reduce duplicate csum/tso code in cp_start_xmit()
+
+We calculate the value of the opts1 descriptor field in three different
+places. With two different behaviours when given an invalid packet to
+be checksummed — none of them correct. Sort that out.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit a3b804043f490aeec57d8ca5baccdd35e6250857
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:38 2015 +0100
+
+8139cp: Fix TSO/scatter-gather descriptor setup
+
+When sending a TSO frame in multiple buffers, we were neglecting to set
+the first descriptor up in TSO mode.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 26b0bad6ac3a0167792dc4ffb276c29bc597d239
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:06 2015 +0100
+
+8139cp: Fix tx_queued debug message to print correct slot numbers
+
+After a certain amount of staring at the debug output of this driver, I
+realised it was lying to me.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit aaa0062ecf4877a26dea66bee1039c6eaf906c94
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:43:41 2015 +0100
+
+8139cp: Do not re-enable RX interrupts in cp_tx_timeout()
+
+If an RX interrupt was already received but NAPI has not yet run when
+the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts
+already 

[OpenWrt-Devel] [PATCH][CC] generic: add 8139cp fixes from 4.3

[David Woodhouse]

This contains only the fixes from the 4.3-rc4 kernel.

Additional improvements are going into 4.4 which will fix and enable
hardware checksum/TSO offload, but backporting those to older kernels
is non-trivial.

Signed-off-by: David Woodhouse 
---
 .../patches-3.18/760-8139cp-fixes-from-4.3.patch   | 367 +
 1 file changed, 367 insertions(+)
 create mode 100644 
target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch

diff --git a/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch 
b/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch
new file mode 100644
index 000..de4c127
--- /dev/null
+++ b/target/linux/generic/patches-3.18/760-8139cp-fixes-from-4.3.patch
@@ -0,0 +1,367 @@
+commit 41b976414c88016e2c9d9b2f6667ee67a998d388
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:45:31 2015 +0100
+
+8139cp: Dump contents of descriptor ring on TX timeout
+
+We are seeing unexplained TX timeouts under heavy load. Let's try to get
+a better idea of what's going on.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 7f4c685633e2df9ba10d49a31dda13715745db37
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:45:16 2015 +0100
+
+8139cp: Fix DMA unmapping of transmitted buffers
+
+The low 16 bits of the 'opts1' field in the TX descriptor are supposed
+to still contain the buffer length when the descriptor is handed back to
+us. In practice, at least on my hardware, they don't. So stash the
+original value of the opts1 field and get the length to unmap from
+there.
+
+There are other ways we could have worked out the length, but I actually
+want a stash of the opts1 field anyway so that I can dump it alongside
+the contents of the descriptor ring when we suffer a TX timeout.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 0a5aeee0b79fa99d8e04c98dd4e87d4f52aa497b
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:57 2015 +0100
+
+8139cp: Reduce duplicate csum/tso code in cp_start_xmit()
+
+We calculate the value of the opts1 descriptor field in three different
+places. With two different behaviours when given an invalid packet to
+be checksummed — none of them correct. Sort that out.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit a3b804043f490aeec57d8ca5baccdd35e6250857
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:38 2015 +0100
+
+8139cp: Fix TSO/scatter-gather descriptor setup
+
+When sending a TSO frame in multiple buffers, we were neglecting to set
+the first descriptor up in TSO mode.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 26b0bad6ac3a0167792dc4ffb276c29bc597d239
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:44:06 2015 +0100
+
+8139cp: Fix tx_queued debug message to print correct slot numbers
+
+After a certain amount of staring at the debug output of this driver, I
+realised it was lying to me.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit aaa0062ecf4877a26dea66bee1039c6eaf906c94
+Author: David Woodhouse 
+Date:   Wed Sep 23 09:43:41 2015 +0100
+
+8139cp: Do not re-enable RX interrupts in cp_tx_timeout()
+
+If an RX interrupt was already received but NAPI has not yet run when
+the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts
+already disabled. Blindly re-enabling them will cause an IRQ storm.
+
+(This is made particularly horrid by the fact that cp_interrupt() always
+returns that it's handled the interrupt, even when it hasn't actually
+done anything. If it didn't do that, the core IRQ code would have
+detected the storm and handled it, I'd have had a clear smoking gun
+backtrace instead of just a spontaneously resetting router, and I'd have
+at *least* two days of my life back. Changing the return value of
+cp_interrupt() will be argued about under separate cover.)
+
+Unconditionally leave RX interrupts disabled after the reset, and
+schedule NAPI to check the receive ring and re-enable them.
+
+Signed-off-by: David Woodhouse 
+Signed-off-by: David S. Miller 
+
+commit 7a8a8e75d505147358b225173e890ada43a267e2
+Author: David Woodhouse 
+Date:   Fri Sep 18 00:21:54 2015 +0100
+
+8139cp: Call __cp_set_rx_mode() from cp_tx_timeout()
+

[OpenWrt-Devel] [PATCH] lantiq: Synchronize access to the DSL command pipe

[Martin Blumenstingl]

Whenever two processes were executing different commands at the same
time then one of the commands sometimes got the response of the other
command.

Signed-off-by: Martin Blumenstingl 
---
 target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh 
b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
index 7809d01..ce6aa50 100755
--- a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
+++ b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
@@ -12,8 +12,10 @@ fi
 #
 dsl_cmd() {
killall -0 ${XDSL_CTRL} && (
+   lock /var/lock/dsl_pipe
echo "$@" > /tmp/pipe/dsl_cpe0_cmd
cat /tmp/pipe/dsl_cpe0_ack
+   lock -u /var/lock/dsl_pipe
)
 }
 dsl_val() {
-- 
2.6.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Subject: [PATCH] [target] Addition of NixCore X1 Board

[Andrew Gaylo]

from: Andrew Gaylo 

This submission is for a the NixCore X1 board.  This board uses the
RT5350 Ralink processor already supported by a number of board in the
OpenWRT repository.  The DTS and profile MK provided is based on
existing boards included in the repo (VoCore).

Signed-off-by: Andrew Gaylo 
---
diff -uprN openwrt_vanilla/target/linux/ramips/dts/NIXCORE-X1.dts 
openwrt_submit/target/linux/ramips/dts/NIXCORE-X1.dts
--- openwrt_vanilla/target/linux/ramips/dts/NIXCORE-X1.dts	1969-12-31 
17:00:00.0 -0700
+++ openwrt_submit/target/linux/ramips/dts/NIXCORE-X1.dts	2015-10-13 
11:04:19.636954204 -0600

@@ -0,0 +1,186 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+   compatible = "NixcoreX1", "ralink,rt5350-soc";
+   model = "NixcoreX1";
+
+   palmbus@1000 {
+/* Re-enable the gpio1 ports */
+   gpio1: gpio@660 {
+   status = "okay";
+   };
+
+   i2c@900 {
+   status = "okay";
+   };
+   uart@500 {
+   status = "okay";
+/* Mix of uart and gpio */
+reset-names = "gpio uartf";
+   };
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "s25fl064k";
+   reg = <0>;
+   linux,modalias = "m25p80", "s25fl064k";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "uboot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "uboot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0x7b>;
+   };
+   };
+
+   spidev@1 {
+   compatible = "linux,spidev";
+   spi-max-frequency = <1000>;
+   reg = <1>;
+   };
+   };
+   };
+
+   pinctrl {
+   state_default: pinctrl0 {
+   gpio {
+/* Associate the tjag, uartf and led grps with gpio */
+   ralink,group = "jtag", "led", "spi_cs1";
+/* How do we set individual pins? */
+   ralink,function = "gpio";
+   };
+   };
+   };
+
+   ethernet@1010 {
+   mtd-mac-address = < 0x4>;
+   };
+
+   esw@1011 {
+   ralink,portmap = <0x17>;
+   };
+
+   wmac@1018 {
+   ralink,mtd-eeprom = < 0>;
+   };
+
+   ehci@101c {
+   status = "okay";
+   };
+
+   ohci@101c1000 {
+   status = "okay";
+   };
+
+chosen {
+   bootargs = "console=ttyS1,57600";
+   };
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   gpio0 {
+   gpio-export,name = "gpio0";
+   gpio-export,direction_may_change = <1>;
+   gpios = < 0 0>;
+   };
+
+/* GPIOs 1-6 are I2C,SPI */
+
+/* GPIO 7-14 are uart1 */
+
+/* GPIOs 15 & 16 are uart2 */
+
+   /* JTAG */
+   gpio17 {
+   /* JTAG_TDO */
+   gpio-export,name = "gpio17";
+   gpio-export,direction_may_change = <1>;
+   gpios = < 17 0>;
+   };
+   gpio18 {
+   /* JTAG_TDI */
+   gpio-export,name = "gpio18";
+   gpio-export,direction_may_change = <1>;
+   gpios = < 18 0>;
+   };
+   gpio19 {
+   /* JTAG_TMS */
+   gpio-export,name = "gpio19";
+   gpio-export,direction_may_change = <1>;
+   gpios = < 19 0>;
+   };

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Tue, 13 Oct 2015, Roman Yeryomin wrote:



Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.



If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.


I think the concern is that someone may do this and then make the resulting 
images available to others to install.


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

[OpenWrt-Devel] [PATCH v2 procd] cmake: use CMAKE_INSTALL_* variables

[Sergiy Kibrik]

Replace hard-coded installation directories with cmake-provided
variables, which gives more flexibility on where to install
final binaries. Great simplification for usage with e.g. BitBake recipes.

Signed-off-by: Sergiy Kibrik 
---
 CMakeLists.txt | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6af17a3..2ca6fbf 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,6 +1,7 @@
 cmake_minimum_required(VERSION 2.6)
 
 PROJECT(procd C)
+INCLUDE(GNUInstallDirs)
 ADD_DEFINITIONS(-Os -ggdb -Wall -Werror --std=gnu99 -Wmissing-declarations)
 
 SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
@@ -13,7 +14,7 @@ ENDIF()
 
 ADD_LIBRARY(setlbf SHARED service/setlbf.c)
 INSTALL(TARGETS setlbf
-   LIBRARY DESTINATION lib
+   LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
 )
 
 
@@ -39,7 +40,7 @@ ENDIF()
 ADD_EXECUTABLE(procd ${SOURCES})
 TARGET_LINK_LIBRARIES(procd ${LIBS})
 INSTALL(TARGETS procd
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 
 
@@ -47,19 +48,19 @@ ADD_EXECUTABLE(init initd/init.c initd/early.c 
initd/preinit.c initd/mkdev.c wat
utils/utils.c ${SOURCES_ZRAM})
 TARGET_LINK_LIBRARIES(init ${LIBS})
 INSTALL(TARGETS init
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 
 
 ADD_EXECUTABLE(udevtrigger plug/udevtrigger.c)
 INSTALL(TARGETS udevtrigger
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 
 
 ADD_EXECUTABLE(askfirst utils/askfirst.c)
 INSTALL(TARGETS askfirst
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 
 ADD_CUSTOM_COMMAND(
@@ -73,7 +74,7 @@ IF(SECCOMP_SUPPORT)
 ADD_LIBRARY(preload-seccomp SHARED jail/preload.c jail/seccomp.c)
 TARGET_LINK_LIBRARIES(preload-seccomp dl ubox blobmsg_json)
 INSTALL(TARGETS preload-seccomp
-   LIBRARY DESTINATION lib
+   LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
 )
 ADD_DEPENDENCIES(preload-seccomp headers)
 endif()
@@ -82,19 +83,19 @@ IF(JAIL_SUPPORT)
 ADD_EXECUTABLE(ujail jail/jail.c jail/elf.c)
 TARGET_LINK_LIBRARIES(ujail ubox)
 INSTALL(TARGETS ujail
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 
 ADD_EXECUTABLE(utrace trace/trace.c)
 TARGET_LINK_LIBRARIES(utrace ubox ${json} blobmsg_json)
 INSTALL(TARGETS utrace
-   RUNTIME DESTINATION sbin
+   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
 )
 ADD_DEPENDENCIES(utrace headers)
 
 ADD_LIBRARY(preload-trace SHARED trace/preload.c)
 TARGET_LINK_LIBRARIES(preload-trace dl)
 INSTALL(TARGETS preload-trace
-   LIBRARY DESTINATION lib
+   LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
 )
 endif()
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH procd] cmake: use CMAKE_INSTALL_* variables

[Sergiy Kibrik]

On 10/12/15 4:50 PM, Felix Fietkau wrote:
> On 2015-09-17 13:54, Sergiy Kibrik wrote:
>> Replace hard-coded installation directories with cmake-provided
>> variables, which gives more flexibility on where to install
>> final binaries. Great simplification for usage with e.g. BitBake recipes.
>>
>> Signed-off-by: Sergiy Kibrik 
> Doesn't work for me:
> 

indeed, forgot to include GNUInstallDirs module. Will fix in v2.

--
regards,
Sergey
___
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

[Etienne Champetier]

Hi again,

2015-10-12 23:49 GMT+02:00 Etienne Champetier 
:

> Hi All,
>
> Here are some commands to make a "full" git repo, from the "trunk" repo
> (the only complaint that everyone agrees on)
> We keep git commit sha's for the trunk, and we add all branches/tags
>
> It needs some more tunning, but it's a good start :)
>
> 1) clone the trunk repo
> git clone git://git.openwrt.org/openwrt.git openwrt-git-svn
> cd openwrt-git-svn
>
> 2) init git svn
> git svn init -T"/trunk" -t"/tags" -b"/branches" --prefix="svn/" svn://
> svn.openwrt.org/openwrt
>
> 3) tell git that we already have trunk
> git update-ref refs/remotes/svn/trunk refs/remotes/origin/master
>
> 4) download all branches/tags (except trunk because we already have it)
> git svn fetch
>
> resulting .git/config
>
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "origin"]
>> url = git://git.openwrt.org/openwrt.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [svn-remote "svn"]
>> url = svn://svn.openwrt.org/openwrt
>> fetch = trunk:refs/remotes/svn/trunk
>> branches = branches/*:refs/remotes/svn/*
>> tags = tags/*:refs/remotes/svn/tags/*
>>
>
>
> original SO post: http://stackoverflow.com/a/12251845
>
> Good night
> Etienne
>

Who has access/is running the script to mirror the svn on git.openwrt.org ?
I would like to know the exact commands used to update the git mirror

Here is an exemple of what we can have (I don't want to migrate to github,
i'm using it out of simplicity)
for now svn tags are git branches
https://github.com/champtar/openwrt-full

to do that i've added to my .git/config (after step 4)

> [remote "champtar"]
> url = g...@github.com:champtar/openwrt-full.git
> fetch = +refs/heads/*:refs/remotes/champtar/*
> push = refs/remotes/svn/*:refs/heads/*
>

and pushed with:
git push --mirror champtar

some more reading
http://john.albin.net/git/convert-subversion-to-git
http://wiki.gnucash.org/wiki/Git_Svn_Mirror

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

[OpenWrt-Devel] [PATCH][CC15.05] opkg: backport 'opkg list --size' option

[Hannu Nyman]

Backport from trunk to CC15.05 the --size option to optionally show also
the *.ipk size in the opkg package listing.

* Default behaviour is to list the available packages as earlier: 
  "name - version - description"
* with "--size" the output of is "name - version - size - description".

Signed-off-by: Hannu Nyman 
---

Implemented in trunk by r46980:
https://dev.openwrt.org/changeset/46980
http://git.openwrt.org/?p=openwrt.git;a=commit;h=97e7e2bae9beced5b079d352035a5e914e9715e2

I have included this in my CC15.05 build without problems.
If this gets accepted to Openwrt CC15.05, I will push the corresponding
change to Luci to also update the GUI to support this option.


diff --git a/package/system/opkg/Makefile b/package/system/opkg/Makefile
index 32bcf2b..76688f5 100644
--- a/package/system/opkg/Makefile
+++ b/package/system/opkg/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2014 OpenWrt.org
+# Copyright (C) 2006-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/feeds.mk
 PKG_NAME:=opkg
 PKG_REV:=9c97d5ecd795709c8584e972bfdf3aee3a5b846d
 PKG_VERSION:=$(PKG_REV)
-PKG_RELEASE:=8
+PKG_RELEASE:=9
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=$(PKG_REV)
diff --git a/package/system/opkg/patches/260-add-print-package-size.patch 
b/package/system/opkg/patches/260-add-print-package-size.patch
new file mode 100644
index 000..0cdf408
--- /dev/null
+++ b/package/system/opkg/patches/260-add-print-package-size.patch
@@ -0,0 +1,74 @@
+--- a/libopkg/opkg_conf.c
 b/libopkg/opkg_conf.c
+@@ -69,6 +69,7 @@ opkg_option_t options[] = {
+ { "proxy_passwd", OPKG_OPT_TYPE_STRING, &_conf.proxy_passwd },
+ { "proxy_user", OPKG_OPT_TYPE_STRING, &_conf.proxy_user },
+ { "query-all", OPKG_OPT_TYPE_BOOL, &_conf.query_all },
++{ "size", OPKG_OPT_TYPE_BOOL, &_conf.size },
+ { "tmp_dir", OPKG_OPT_TYPE_STRING, &_conf.tmp_dir },
+ { "verbosity", OPKG_OPT_TYPE_INT, &_conf.verbosity },
+ #if defined(HAVE_OPENSSL)
+--- a/libopkg/opkg_conf.h
 b/libopkg/opkg_conf.h
+@@ -88,6 +88,7 @@ struct opkg_conf
+  int query_all;
+  int verbosity;
+  int noaction;
++ int size;
+  int download_only;
+  char *cache;
+ 
+--- a/src/opkg-cl.c
 b/src/opkg-cl.c
+@@ -52,6 +52,7 @@ enum {
+   ARGS_OPT_AUTOREMOVE,
+   ARGS_OPT_CACHE,
+   ARGS_OPT_FORCE_SIGNATURE,
++  ARGS_OPT_SIZE,
+ };
+ 
+ static struct option long_options[] = {
+@@ -98,6 +99,7 @@ static struct option long_options[] = {
+   {"offline-root", 1, 0, 'o'},
+   {"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
+   {"add-dest", 1, 0, ARGS_OPT_ADD_DEST},
++  {"size", 0, 0, ARGS_OPT_SIZE},
+   {"test", 0, 0, ARGS_OPT_NOACTION},
+   {"tmp-dir", 1, 0, 't'},
+   {"tmp_dir", 1, 0, 't'},
+@@ -207,6 +209,9 @@ args_parse(int argc, char *argv[])
+   }
+   free(tuple);
+   break;
++  case ARGS_OPT_SIZE:
++  conf->size = 1;
++  break;
+   case ARGS_OPT_NOACTION:
+   conf->noaction = 1;
+   break;
+@@ -310,6 +315,7 @@ usage()
+   printf("\t--download-only   No action -- download only\n");
+   printf("\t--nodeps  Do not follow dependencies\n");
+   printf("\t--nocase  Perform case insensitive pattern 
matching\n");
++  printf("\t--sizePrint package size when listing 
available packages\n");
+   printf("\t--force-removal-of-dependent-packages\n");
+   printf("\t  Remove package and all dependencies\n");
+   printf("\t--autoremove  Remove packages that were installed\n");
+--- a/libopkg/opkg_cmd.c
 b/libopkg/opkg_cmd.c
+@@ -47,10 +47,12 @@ static void
+ print_pkg(pkg_t *pkg)
+ {
+   char *version = pkg_version_str_alloc(pkg);
++  printf("%s - %s", pkg->name, version);
++  if (conf->size)
++  printf(" - %lu", pkg->size);
+   if (pkg->description)
+-  printf("%s - %s - %s\n", pkg->name, version, pkg->description);
+-  else
+-  printf("%s - %s\n", pkg->name, version);
++  printf(" - %s", pkg->description);
++  printf("\n");
+   free(version);
+ }
+ 
___
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

[Roman Yeryomin]

On 13 October 2015 at 23:08, David Lang  wrote:
> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
>
>>>
>>> Would it be possible to track the revision number in an automated way
>>> even
>>> in a git repo?  So store the r number, and automatically increment on
>>> commits.  Not sure if that's an option, but it seems like it might
>>> address
>>> the problem.
>>>
>>
>> If a user is smart enough to commit something locally then he knows
>> what he is doing and is smart enough to report the changes he made.
>> It's so simple.
>
>
> I think the concern is that someone may do this and then make the resulting
> images available to others to install.

Someone can do this (change the revision) very easily now too (and
this is good, because allows using internal revision numbers for
custom fw builders), so there is no way you can protect from this (I
would even say there is no point in protecting from this).

Regards,
Roman
___
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

[David Lang]

On Wed, 14 Oct 2015, Roman Yeryomin wrote:


On 13 October 2015 at 23:08, David Lang  wrote:

On Tue, 13 Oct 2015, Roman Yeryomin wrote:



Would it be possible to track the revision number in an automated way
even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might
address
the problem.



If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.



I think the concern is that someone may do this and then make the resulting
images available to others to install.


Someone can do this (change the revision) very easily now too (and
this is good, because allows using internal revision numbers for
custom fw builders), so there is no way you can protect from this (I
would even say there is no point in protecting from this).


I think it's a good idea to encourage other builders to have a unique id in 
there. That's why I was talking earlier about adding the initials of the builder 
to the version string.


Even if they are compiling the same code, there are enough different ways to 
configure things that can cause problems that it's worth knowing if it's a stock 
build or a custom one.


David Lang
___
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

[Roman Yeryomin]

On 14 October 2015 at 00:20, David Lang  wrote:
> On Wed, 14 Oct 2015, Roman Yeryomin wrote:
>
>> On 13 October 2015 at 23:08, David Lang  wrote:
>>>
>>> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
>>>
>
> Would it be possible to track the revision number in an automated way
> even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might
> address
> the problem.
>

 If a user is smart enough to commit something locally then he knows
 what he is doing and is smart enough to report the changes he made.
 It's so simple.
>>>
>>>
>>>
>>> I think the concern is that someone may do this and then make the
>>> resulting
>>> images available to others to install.
>>
>>
>> Someone can do this (change the revision) very easily now too (and
>> this is good, because allows using internal revision numbers for
>> custom fw builders), so there is no way you can protect from this (I
>> would even say there is no point in protecting from this).
>
>
> I think it's a good idea to encourage other builders to have a unique id in
> there. That's why I was talking earlier about adding the initials of the
> builder to the version string.
>
> Even if they are compiling the same code, there are enough different ways to
> configure things that can cause problems that it's worth knowing if it's a
> stock build or a custom one.

You can put any initials (or other info) into your version number or
other configurable identifiers, but, IMO, forcing this is a bad idea.

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

[OpenWrt-Devel] [PATCH 1/3] imx6: add v4.1 support

[Pushpal Sidhu]

Build and boot tested on the following hardware:
 * GW54xx
 * GW53xx
 * GW52xx
 * GW51xx

Signed-off-by: Tim Harvey 
Signed-off-by: Pushpal Sidhu 
---
 target/linux/imx6/config-4.1   | 382 +
 .../linux/imx6/files-4.1/drivers/net/phy/gw16083.c | 950 +
 .../linux/imx6/files-4.1/drivers/net/phy/gw16083.h | 123 +++
 target/linux/imx6/patches-4.1/100-bootargs.patch   |  11 +
 ...-add-i210-i211-support-for-phy-read-write.patch | 129 +++
 ...-phy-read-write-functions-that-accept-phy.patch | 260 ++
 ...egister-mii_bus-for-SerDes-w-external-phy.patch | 308 +++
 ...ver-for-GW16083-Ethernet-Expansion-Mezzan.patch |  27 +
 ...-imx-ventana-added-GW16083-to-device-tree.patch |  56 ++
 9 files changed, 2246 insertions(+)
 create mode 100644 target/linux/imx6/config-4.1
 create mode 100644 target/linux/imx6/files-4.1/drivers/net/phy/gw16083.c
 create mode 100644 target/linux/imx6/files-4.1/drivers/net/phy/gw16083.h
 create mode 100644 target/linux/imx6/patches-4.1/100-bootargs.patch
 create mode 100644 
target/linux/imx6/patches-4.1/202-net-igb-add-i210-i211-support-for-phy-read-write.patch
 create mode 100644 
target/linux/imx6/patches-4.1/203-net-igb-add-phy-read-write-functions-that-accept-phy.patch
 create mode 100644 
target/linux/imx6/patches-4.1/204-net-igb-register-mii_bus-for-SerDes-w-external-phy.patch
 create mode 100644 
target/linux/imx6/patches-4.1/205-phy-add-driver-for-GW16083-Ethernet-Expansion-Mezzan.patch
 create mode 100644 
target/linux/imx6/patches-4.1/206-ARM-imx-ventana-added-GW16083-to-device-tree.patch

diff --git a/target/linux/imx6/config-4.1 b/target/linux/imx6/config-4.1
new file mode 100644
index 000..18a26d6
--- /dev/null
+++ b/target/linux/imx6/config-4.1
@@ -0,0 +1,382 @@
+CONFIG_AHCI_IMX=y
+CONFIG_ALIGNMENT_TRAP=y
+CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
+CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
+CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
+CONFIG_ARCH_HAS_RESET_CONTROLLER=y
+CONFIG_ARCH_HAS_SG_CHAIN=y
+CONFIG_ARCH_HAS_TICK_BROADCAST=y
+CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+CONFIG_ARCH_MULTIPLATFORM=y
+# CONFIG_ARCH_MULTI_CPU_AUTO is not set
+CONFIG_ARCH_MULTI_V6_V7=y
+CONFIG_ARCH_MULTI_V7=y
+CONFIG_ARCH_MXC=y
+CONFIG_ARCH_NR_GPIO=0
+CONFIG_ARCH_REQUIRE_GPIOLIB=y
+# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
+# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
+CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_USE_BUILTIN_BSWAP=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
+CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
+CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
+CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
+CONFIG_ARM=y
+# CONFIG_ARM_CPU_SUSPEND is not set
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_ARM_ERRATA_764369=y
+CONFIG_ARM_ERRATA_775420=y
+CONFIG_ARM_GIC=y
+CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_ARM_IMX6Q_CPUFREQ=y
+CONFIG_ARM_L1_CACHE_SHIFT=6
+CONFIG_ARM_L1_CACHE_SHIFT_6=y
+# CONFIG_ARM_LPAE is not set
+CONFIG_ARM_PATCH_PHYS_VIRT=y
+CONFIG_ARM_THUMB=y
+# CONFIG_ARM_THUMBEE is not set
+CONFIG_ARM_VIRT_EXT=y
+CONFIG_ATA=y
+CONFIG_ATAGS=y
+# CONFIG_ATA_SFF is not set
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_CACHE_L2X0=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_CLKDEV_LOOKUP=y
+CONFIG_CLKSRC_MMIO=y
+CONFIG_CLKSRC_OF=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_COMMON_CLK=y
+CONFIG_CPUFREQ_DT=y
+CONFIG_CPU_32v6K=y
+CONFIG_CPU_32v7=y
+CONFIG_CPU_ABRT_EV7=y
+# CONFIG_CPU_BPREDICT_DISABLE is not set
+CONFIG_CPU_CACHE_V7=y
+CONFIG_CPU_CACHE_VIPT=y
+CONFIG_CPU_COPY_V6=y
+CONFIG_CPU_CP15=y
+CONFIG_CPU_CP15_MMU=y
+CONFIG_CPU_FREQ=y
+# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
+CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
+# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
+CONFIG_CPU_FREQ_GOV_COMMON=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_STAT=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_HAS_ASID=y
+# CONFIG_CPU_ICACHE_DISABLE is not set
+CONFIG_CPU_PABRT_V7=y
+CONFIG_CPU_RMAP=y
+CONFIG_CPU_TLB_V7=y
+CONFIG_CPU_V7=y
+CONFIG_CRC16=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_DEFLATE=y
+CONFIG_CRYPTO_HASH=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_LZO=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_WORKQUEUE=y
+CONFIG_CRYPTO_XZ=y
+CONFIG_DCACHE_WORD_ACCESS=y
+CONFIG_DEBUG_IMX_UART_PORT=1
+CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
+# CONFIG_DEBUG_UART_8250 is not set
+# CONFIG_DEBUG_USER is not set
+CONFIG_DECOMPRESS_BZIP2=y
+CONFIG_DECOMPRESS_GZIP=y
+CONFIG_DECOMPRESS_LZO=y
+CONFIG_DECOMPRESS_XZ=y
+CONFIG_DMADEVICES=y
+CONFIG_DMA_ENGINE=y
+CONFIG_DMA_OF=y
+CONFIG_DTC=y
+# CONFIG_DW_DMAC_PCI is not set
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT2_FS_XATTR=y

[OpenWrt-Devel] [PATCH 2/3] imx6: add Gateworks GW551x support

[Pushpal Sidhu]

Upstream patch: e9d6d6b62f306ba83e1441af5daf2809a6167474

Add support for the Gateworks GW5510 board featuring:
 * i.MX6 SoC
 * up to 512MB DDR3
 * up to 2GB NAND flash
 * 1x miniPCIe socket (with USB)
 * HDMI out (micro-HDMI)
 * HDMI in (micro-HDMI) (currently supported by only vendor kernel)
 * TTL level I/O (supported by GW16111 breakout board):
  * I2C
  * 2x UART
  * CAN
  * 2x DIO (GPIO/PWM)
  * USB OTG

Also add support to OpenWrt build system

Signed-off-by: Tim Harvey 
Signed-off-by: Pushpal Sidhu 
---
 target/linux/imx6/base-files/lib/imx6.sh   |   5 +
 ...20-ARM-dts-Gateworks-GW5510-support-i.MX6.patch | 500 +
 target/linux/imx6/profiles/120-gateworks.mk|   2 +
 3 files changed, 507 insertions(+)
 create mode 100644 
target/linux/imx6/patches-4.1/020-ARM-dts-Gateworks-GW5510-support-i.MX6.patch

diff --git a/target/linux/imx6/base-files/lib/imx6.sh 
b/target/linux/imx6/base-files/lib/imx6.sh
index 360ec58..32440aa 100755
--- a/target/linux/imx6/base-files/lib/imx6.sh
+++ b/target/linux/imx6/base-files/lib/imx6.sh
@@ -34,6 +34,11 @@ imx6_board_detect() {
name="gw54xx"
;;
 
+   "Gateworks Ventana i.MX6 Dual/Quad GW551X" |\
+   "Gateworks Ventana i.MX6 Solo/DualLite GW551X")
+   name="gw551x"
+   ;;
+
"Gateworks Ventana i.MX6 DualLite/Solo GW552X" |\
"Gateworks Ventana i.MX6 Dual/Quad GW552X")
name="gw552x"
diff --git 
a/target/linux/imx6/patches-4.1/020-ARM-dts-Gateworks-GW5510-support-i.MX6.patch
 
b/target/linux/imx6/patches-4.1/020-ARM-dts-Gateworks-GW5510-support-i.MX6.patch
new file mode 100644
index 000..551b221
--- /dev/null
+++ 
b/target/linux/imx6/patches-4.1/020-ARM-dts-Gateworks-GW5510-support-i.MX6.patch
@@ -0,0 +1,500 @@
+From e9d6d6b62f306ba83e1441af5daf2809a6167474 Mon Sep 17 00:00:00 2001
+From: Tim Harvey 
+Date: Thu, 7 May 2015 08:38:00 -0700
+Subject: [PATCH] ARM: dts: Gateworks GW5510 support (i.MX6)
+
+Add support for the Gateworks GW5510 board featuring:
+ * i.MX6 SoC
+ * up to 512MB DDR3
+ * up to 2GB NAND flash
+ * 1x miniPCIe socket (with USB)
+ * HDMI out (micro-HDMI)
+ * HDMI in (micro-HDMI) (currently supported by only vendor kernel)
+ * TTL level I/O (supported by GW16111 breakout board):
+  * I2C
+  * 2x UART
+  * CAN
+  * 2x DIO (GPIO/PWM)
+  * USB OTG
+
+For more details see:
+ http://www.gateworks.com/product/item/ventana-gw5510-single-board-computer
+
+Signed-off-by: Tim Harvey 
+Reviewed-by: Fabio Estevam 
+Signed-off-by: Shawn Guo 
+---
+ arch/arm/boot/dts/Makefile|   2 +
+ arch/arm/boot/dts/imx6dl-gw551x.dts   |  55 ++
+ arch/arm/boot/dts/imx6q-gw551x.dts|  55 ++
+ arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 314 ++
+ 4 files changed, 426 insertions(+)
+ create mode 100644 arch/arm/boot/dts/imx6dl-gw551x.dts
+ create mode 100644 arch/arm/boot/dts/imx6q-gw551x.dts
+ create mode 100644 arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 86217db..8932e6e 100644
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -262,6 +262,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
+   imx6dl-gw52xx.dtb \
+   imx6dl-gw53xx.dtb \
+   imx6dl-gw54xx.dtb \
++  imx6dl-gw551x.dtb \
+   imx6dl-gw552x.dtb \
+   imx6dl-hummingboard.dtb \
+   imx6dl-nitrogen6x.dtb \
+@@ -288,6 +289,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
+   imx6q-gw53xx.dtb \
+   imx6q-gw5400-a.dtb \
+   imx6q-gw54xx.dtb \
++  imx6q-gw551x.dtb \
+   imx6q-gw552x.dtb \
+   imx6q-hummingboard.dtb \
+   imx6q-nitrogen6x.dtb \
+diff --git a/arch/arm/boot/dts/imx6dl-gw551x.dts 
b/arch/arm/boot/dts/imx6dl-gw551x.dts
+new file mode 100644
+index 000..82d5f85
+--- /dev/null
 b/arch/arm/boot/dts/imx6dl-gw551x.dts
+@@ -0,0 +1,55 @@
++/*
++ * Copyright 2014 Gateworks Corporation
++ *
++ * This file is dual-licensed: you can use it either under the terms
++ * of the GPL or the X11 license, at your option. Note that this dual
++ * licensing only applies to this file, and not this project as a
++ * whole.
++ *
++ *  a) This file is free software; you can redistribute it and/or
++ * modify it under the terms of the GNU General Public License as
++ * published by the Free Software Foundation; either version 2 of
++ * the License, or (at your option) any later version.
++ *
++ * This file is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public
++ * License along with this file; if not, write to the Free

[OpenWrt-Devel] [PATCH 3/3] imx6: switch to v4.1

[Pushpal Sidhu]

Signed-off-by: Pushpal Sidhu 
---
 target/linux/imx6/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/imx6/Makefile b/target/linux/imx6/Makefile
index 479b48e..cd938c8 100644
--- a/target/linux/imx6/Makefile
+++ b/target/linux/imx6/Makefile
@@ -14,7 +14,7 @@ CPU_TYPE:=cortex-a9
 CPU_SUBTYPE:=neon
 MAINTAINER:=Luka Perkov 
 
-KERNEL_PATCHVER:=3.18
+KERNEL_PATCHVER:=4.1
 
 include $(INCLUDE_DIR)/target.mk
 
-- 
2.6.0
___
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

[Bruno Randolf]

On 10/13/2015 09:08 PM, David Lang wrote:
> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
> 
>>>
>>> Would it be possible to track the revision number in an automated way
>>> even
>>> in a git repo?  So store the r number, and automatically increment on
>>> commits.  Not sure if that's an option, but it seems like it might
>>> address
>>> the problem.
>>>
>>
>> If a user is smart enough to commit something locally then he knows
>> what he is doing and is smart enough to report the changes he made.
>> It's so simple.
> 
> I think the concern is that someone may do this and then make the
> resulting images available to others to install.

One way to avoid the ambiguity of the r-number would be to use
"git describe origin/master" then even if the local master branch has
commits, you'd get the "upstream" revision number. But, I think it's
more important to know that there have been local changes.

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

[OpenWrt-Devel] [PATCH 0/3] Bump imx6 to kernel 4.1

[Pushpal Sidhu]

Adds support for kernel 4.1 for target imx6. Don't carry over 
200-pci_designware_add-ability-for-custom-swizzle.patch, 
201-pci_imx6_ventana_fixup-for-IRQ-mismapping.patch, and 
207-ARM-dts-imx6-ventana-Add-PCI-nodes-for-on-board-PCI-.patch, 
from 3.18 as they causes some breakage with pci.

imx6: add v4.1 support
 target/linux/imx6/config-4.1   
 | 382 
 target/linux/imx6/files-4.1/drivers/net/phy/gw16083.c  
 | 950 
 target/linux/imx6/files-4.1/drivers/net/phy/gw16083.h  
 | 123 ++
 target/linux/imx6/patches-4.1/100-bootargs.patch   
 |  11 +
 
.../imx6/patches-4.1/202-net-igb-add-i210-i211-support-for-phy-read-write.patch 
| 129 ++
 
.../imx6/patches-4.1/203-net-igb-add-phy-read-write-functions-that-accept-phy.patch
 | 260 +++
 
.../imx6/patches-4.1/204-net-igb-register-mii_bus-for-SerDes-w-external-phy.patch
   | 308 +
 
.../imx6/patches-4.1/205-phy-add-driver-for-GW16083-Ethernet-Expansion-Mezzan.patch
 |  27 ++
 
.../linux/imx6/patches-4.1/206-ARM-imx-ventana-added-GW16083-to-device-tree.patch
   |  56 +++
 9 files changed, 2246 insertions(+)
imx6: add Gateworks GW551x support
 target/linux/imx6/base-files/lib/imx6.sh   
|   5 +
 target/linux/imx6/patches-4.1/020-ARM-dts-Gateworks-GW5510-support-i.MX6.patch 
| 500 +
 target/linux/imx6/profiles/120-gateworks.mk
|   2 +
 3 files changed, 507 insertions(+)
imx6: switch to v4.1
 target/linux/imx6/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

- Pushpal
___
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

[Javier Domingo Cansino]

>
> One way to avoid the ambiguity of the r-number would be to use
> "git describe origin/master" then even if the local master branch has
> commits, you'd get the "upstream" revision number. But, I think it's
> more important to know that there have been local changes.
>

The git-describe two liner I traced that. Anyway, we don't really need a
number from version X because it's meaningless in git.

We've talked about how we would obtain the fork point, and a solution is
been already been stated (take Bruno's, mine, combine them, etc)

It is also clear that we can create tools to make testing PRs directly from
Github/Gitlab avoiding checkouts and just applying the patches, also we are
able to run checks automatically on PRs without intervention.

What is there left?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel