From mangesh at opennetware.com  Mon May  1 04:38:04 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Mon, 1 May 2017 14:08:04 +0530
Subject: [OpenWrt-Devel] mipsel-openwrt-linux-musl-cpp: command not found
 while building ramips - rt305x.
Message-ID: <CAKhqrsBuWXTFORUAwGcFTRLzLpC-uGE3QFXcjuhfRr8GXpteXg@mail.gmail.com>

Hello OpenWRT/LEDE Team,

I am getting same error reported in this defect.
https://dev.openwrt.org/ticket/22415

Looks like it is open for quite long time now.  I do see there are builds
for ramips - rt305x on download.openwrt.com. However cannot build it
locally with imagebuilder.

Please help!

Regards,
Mangesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170501/e90f5caf/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Mon May  1 05:04:13 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Mon, 1 May 2017 14:34:13 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <20170213170350.572659eb@gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
 <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
 <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>
 <CAKhqrsA=h=1pm9U4fpKGD2og59O8+tJrJjJHZ_PQNPK+vajbTg@mail.gmail.com>
 <20170213170350.572659eb@gmail.com>
Message-ID: <CAKhqrsAfHAC5Q5fEmGdom1H_EK7MQAXtOYNReLLC5XqnQ5fw3Q@mail.gmail.com>

Hello,

Last time I reported this issue was for MT7620.  dnscrypt-proxy now failing
for MT7621.

http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7621/dnscrypt-proxy/compile.txt

I am not sure what was the fix made. Likely was related to SSL cert check.
Can anyone please look at this and fix it same way as MT7620 ?

Regards,
Mangesh

-- 
Regards,

*Mangesh Bhamre*
Co-founder & CTO | Open Netware <http://opennetware.com/>
+91-8879735272 | LinkedIn <https://in.linkedin.com/in/mangeshbhamre>


On Mon, Feb 13, 2017 at 9:33 PM, Ralph Sennhauser <
ralph.sennhauser at gmail.com> wrote:

> On Mon, 13 Feb 2017 21:03:07 +0530
> Mangesh Bhamre <mangesh at opennetware.com> wrote:
>
> > Hi Alex,
> >
> > Looking at build log -
> > http://buildbot.openwrt.org:8010/broken_packages/ramips.
> mt7620/dnscrypt-proxy/compile.txt
> >
> > Tar ball is available on download.dnscrypt.org . Build download fails
> > for some SSL issue.
>
> The site has HSTS enabled. Might that be the issue?
>
> Maybe just updating PKG_SOURCE_URL to use https might be all that
> is needed. There was another user having issues with a redirect and
> samba. I think he was using Ubuntu.
>
> Ralph
>
> >
> > Also, tar ball is missing on mirror2.openwrt.org and
> > downloads.openwrt.org/sources
> >
> > Not sure, how mirror2 or download.openwrt.org gets updated.  Any help
> > in getting is appreciated.
> >
> > Regards,
> > Mangesh
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170501/67943702/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Mon May  1 06:48:31 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Mon, 1 May 2017 13:48:31 +0300
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsAfHAC5Q5fEmGdom1H_EK7MQAXtOYNReLLC5XqnQ5fw3Q@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
 <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
 <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>
 <CAKhqrsA=h=1pm9U4fpKGD2og59O8+tJrJjJHZ_PQNPK+vajbTg@mail.gmail.com>
 <20170213170350.572659eb@gmail.com>
 <CAKhqrsAfHAC5Q5fEmGdom1H_EK7MQAXtOYNReLLC5XqnQ5fw3Q@mail.gmail.com>
Message-ID: <CA+U=DsqXYOYRvjj3Sdk++VZq1=yFZ-HOAPgzXvpQqfwNKdvFGA@mail.gmail.com>

On Mon, May 1, 2017 at 12:04 PM, Mangesh Bhamre <mangesh at opennetware.com> wrote:
>
> Hello,
>
> Last time I reported this issue was for MT7620.  dnscrypt-proxy now failing for MT7621.
>
> http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7621/dnscrypt-proxy/compile.txt
>
> I am not sure what was the fix made. Likely was related to SSL cert check. Can anyone please look at this and fix it same way as MT7620 ?
>
> Regards,
> Mangesh
>
> --
> Regards,
>
> Mangesh Bhamre
> Co-founder & CTO | Open Netware
> +91-8879735272 | LinkedIn
>
>
> On Mon, Feb 13, 2017 at 9:33 PM, Ralph Sennhauser <ralph.sennhauser at gmail.com> wrote:
>>
>> On Mon, 13 Feb 2017 21:03:07 +0530
>> Mangesh Bhamre <mangesh at opennetware.com> wrote:
>>
>> > Hi Alex,
>> >
>> > Looking at build log -
>> > http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/dnscrypt-proxy/compile.txt
>> >
>> > Tar ball is available on download.dnscrypt.org . Build download fails
>> > for some SSL issue.
>>
>> The site has HSTS enabled. Might that be the issue?
>>
>> Maybe just updating PKG_SOURCE_URL to use https might be all that
>> is needed. There was another user having issues with a redirect and
>> samba. I think he was using Ubuntu.
>>
>> Ralph
>>
>> >
>> > Also, tar ball is missing on mirror2.openwrt.org and
>> > downloads.openwrt.org/sources
>> >
>> > Not sure, how mirror2 or download.openwrt.org gets updated.  Any help
>> > in getting is appreciated.
>> >
>> > Regards,
>> > Mangesh
>> >
>> >
>
>

Looks like the package wasn't found on OpenWrt mirrors.
Maybe some intermittent failure.

You could try to setup your own cache/mirror [for packages/tarballs]
and point your build to use that as primary, and only then fallback to
OpenWrt's official repos.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From aospan at jokersys.com  Tue May  2 11:21:42 2017
From: aospan at jokersys.com (Abylay Ospan)
Date: Tue, 2 May 2017 11:21:42 -0400
Subject: [OpenWrt-Devel] OpenWrt and Open Compute Project (OCP)
Message-ID: <CAK3bHNWgoUMn3tNWQoXKzuodVntFqQyvkoLW1k4mrJJbVqW8jw@mail.gmail.com>

Hello All,

I'm working on Facebook's Open Compute CBW (Campus, Branch, and
Wireless) project [1]. OCP CBW mission is:
"Closed wireless and branch networking equipment have served well in the past
but now is the time to democratize wireless networking to make it programmable,
faster, easier, and less expensive for customers and give everyone the
power of choice like never before"

We have made some research and choose OpenWrt as base system (thanks
for OpenWrt advantages :).

Hardware options is:
3 Broadcom based designs (802.11 AC Wave 1)    [2]
2 Qualcomm based designs (802.11 AC WAVE 2)
More planned by other H/W ODMs in 2017/18

All devices is open hardware in some terms.

I have started github repo for adopting OpenWrt to this hardware:
https://github.com/aospan/openwrt/commits/ocp

Currently main AP I'm working on is EdgeCore ECW7220-L [2]. CPU, RAM,
Flash, Ethernet is supported now. There is also two wifi pci-e
adapters:
01:00.0 Class 0280: 14e4:43a2
01:00.0 Class 0280: 14e4:4331

"14e4:4331" is supported by b43 driver in 2.4GHz only mode (this is ok).
Second adapter "14e4:43a2" doesn't supported by brcmsmac (this adapter
is soft-mac). Now I'm trying to make this adapter working with
brcmsmac.
Also, there is plans to adopt/create solution for modern Software
Defined Network model based on OpenWRT. All projects will be Open
Source.
We are open for new participants. If you are interested please drop me
a message or send reply to ML for public discussion.
And happily we have possibilities to rise some funds to make some tasks payable.

Links:
 [1] http://www.opencompute.org/wiki/Networking/CBWCampus2cBranch2CAndWireless
 [2] http://www.edge-core.com/productsInfo.php?cls=3&cls2=19&cls3=24&id=112

-- 
Abylay Ospan,
JokerSys
http://jokersys.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From j.lancett at ntlworld.com  Tue May  2 17:03:15 2017
From: j.lancett at ntlworld.com (tapper)
Date: Tue, 2 May 2017 22:03:15 +0100
Subject: [OpenWrt-Devel] OpenWrt and Open Compute Project (OCP)
In-Reply-To: <CAK3bHNWgoUMn3tNWQoXKzuodVntFqQyvkoLW1k4mrJJbVqW8jw@mail.gmail.com>
References: <CAK3bHNWgoUMn3tNWQoXKzuodVntFqQyvkoLW1k4mrJJbVqW8jw@mail.gmail.com>
Message-ID: <027ac232-dcce-dffe-ca82-2be6d07d55f8@ntlworld.com>

On 02/05/2017 16:21, Abylay Ospan wrote:
> Hello All,
>
> I'm working on Facebook's Open Compute CBW (Campus, Branch, and
> Wireless) project [1]. OCP CBW mission is:
> "Closed wireless and branch networking equipment have served well in the past
> but now is the time to democratize wireless networking to make it programmable,
> faster, easier, and less expensive for customers and give everyone the
> power of choice like never before"
>
> We have made some research and choose OpenWrt as base system (thanks
> for OpenWrt advantages :).
>
> Hardware options is:
> 3 Broadcom based designs (802.11 AC Wave 1)    [2]
> 2 Qualcomm based designs (802.11 AC WAVE 2)
> More planned by other H/W ODMs in 2017/18
>
> All devices is open hardware in some terms.
>
> I have started github repo for adopting OpenWrt to this hardware:
> https://github.com/aospan/openwrt/commits/ocp
>
> Currently main AP I'm working on is EdgeCore ECW7220-L [2]. CPU, RAM,
> Flash, Ethernet is supported now. There is also two wifi pci-e
> adapters:
> 01:00.0 Class 0280: 14e4:43a2
> 01:00.0 Class 0280: 14e4:4331
>
> "14e4:4331" is supported by b43 driver in 2.4GHz only mode (this is ok).
> Second adapter "14e4:43a2" doesn't supported by brcmsmac (this adapter
> is soft-mac). Now I'm trying to make this adapter working with
> brcmsmac.
> Also, there is plans to adopt/create solution for modern Software
> Defined Network model based on OpenWRT. All projects will be Open
> Source.
> We are open for new participants. If you are interested please drop me
> a message or send reply to ML for public discussion.
> And happily we have possibilities to rise some funds to make some tasks payable.
>
> Links:
>  [1] http://www.opencompute.org/wiki/Networking/CBWCampus2cBranch2CAndWireless
>  [2] http://www.edge-core.com/productsInfo.php?cls=3&cls2=19&cls3=24&id=112
>

Hi you should look at LEDE:
https://lede-project.org/
The LEDE Project (?Linux Embedded Development Environment?) is a Linux 
operating system based on OpenWrt. It is a complete replacement for the 
vendor-supplied firmware of a wide range of wireless routers and 
non-network devices.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From david at lang.hm  Tue May  2 17:07:56 2017
From: david at lang.hm (David Lang)
Date: Tue, 2 May 2017 14:07:56 -0700 (PDT)
Subject: [OpenWrt-Devel] OpenWrt and Open Compute Project (OCP)
In-Reply-To: <027ac232-dcce-dffe-ca82-2be6d07d55f8@ntlworld.com>
References: <CAK3bHNWgoUMn3tNWQoXKzuodVntFqQyvkoLW1k4mrJJbVqW8jw@mail.gmail.com>
 <027ac232-dcce-dffe-ca82-2be6d07d55f8@ntlworld.com>
Message-ID: <nycvar.QRO.7.76.6.1705021406100.6746@qynat-yncgbc>

On Tue, 2 May 2017, tapper wrote:

> Hi you should look at LEDE:
> https://lede-project.org/
> The LEDE Project (?Linux Embedded Development Environment?) is a Linux 
> operating system based on OpenWrt. It is a complete replacement for the 
> vendor-supplied firmware of a wide range of wireless routers and 
> non-network devices.

More than that, all OpenWRT developers have commit access to LEDE and work is 
ongoing to re-merge the projects using the LEDE codebase (the OpenWRT devs are 
working to merge anything from the OpenWRT codebase that's missing in the LEDE 
codebase). Currently LEDE has about a year of development beyond the OpenWRT 
codebase.

David Lang
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ron.brash at gmail.com  Wed May  3 08:06:44 2017
From: ron.brash at gmail.com (Ron Brash)
Date: Wed, 3 May 2017 08:06:44 -0400
Subject: [OpenWrt-Devel] Fwd: Logd hangs after hitting X limit
In-Reply-To: <CAPZm7uUX4hxADeN+LTu1ft4OUtqs5H2L4dnshxq0xmGTD6inJQ@mail.gmail.com>
References: <CAPZm7uUCBoaMBey7J5tL4wj9u4d_Gwt9NP_azjwTK89i3vwK1Q@mail.gmail.com>
 <CAPZm7uWCuDMqeabU=9Z0Oxx24FZhrxZOCM68Ou=gMk0=1RYM6Q@mail.gmail.com>
 <CAPZm7uV1t_9cpe5n6+cm_8-f0p4pXKWuMQqtaimQvoFXU2AA+g@mail.gmail.com>
 <CAPZm7uXUFp5hdZ=1YosmU1nxu+B=P1zo9PtfG6S_3FzsqULbXA@mail.gmail.com>
 <CAPZm7uUX4hxADeN+LTu1ft4OUtqs5H2L4dnshxq0xmGTD6inJQ@mail.gmail.com>
Message-ID: <CAPZm7uVyaa8Cp0jKJpk=aHkwvMweYTHpaCHvijSYnz6K8wooXQ@mail.gmail.com>

Hello all,

I was testing using an older branch of logd from trunk; circa october
2016.  We noticed that the openwrt logd/readlog periodically hangs and
needs to be restarted.  This is only due to sending around 16k of logs
(default values).

I upgraded ubox and everything in between for the latest logd and while
logd does not hang now, this issue still persists albeit much better.
Simply sighuping and restarting logread restarts the logging versus before
- restarting everything.

In some situations, logd crashes as well.  I had a bash script running in
the background generating timestamped events repeatedly.  Procd did not
respawn logd, which was odd too.

Any notes on these or known bugs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170503/c26ddcf2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From aospan at jokersys.com  Wed May  3 10:38:13 2017
From: aospan at jokersys.com (Abylay Ospan)
Date: Wed, 3 May 2017 10:38:13 -0400
Subject: [OpenWrt-Devel] OpenWrt and Open Compute Project (OCP)
In-Reply-To: <nycvar.QRO.7.76.6.1705021406100.6746@qynat-yncgbc>
References: <CAK3bHNWgoUMn3tNWQoXKzuodVntFqQyvkoLW1k4mrJJbVqW8jw@mail.gmail.com>
 <027ac232-dcce-dffe-ca82-2be6d07d55f8@ntlworld.com>
 <nycvar.QRO.7.76.6.1705021406100.6746@qynat-yncgbc>
Message-ID: <CAK3bHNVy=E9NkM8=cAfmOyFQvkiPV2_YXhv9uHazMF6tMxCKkQ@mail.gmail.com>

Hi David,

Thanks for information! I have sent message to LEDE ML.

2017-05-02 17:07 GMT-04:00 David Lang <david at lang.hm>:
> On Tue, 2 May 2017, tapper wrote:
>
>> Hi you should look at LEDE:
>> https://lede-project.org/
>> The LEDE Project (?Linux Embedded Development Environment?) is a Linux
>> operating system based on OpenWrt. It is a complete replacement for the
>> vendor-supplied firmware of a wide range of wireless routers and non-network
>> devices.
>
>
> More than that, all OpenWRT developers have commit access to LEDE and work
> is ongoing to re-merge the projects using the LEDE codebase (the OpenWRT
> devs are working to merge anything from the OpenWRT codebase that's missing
> in the LEDE codebase). Currently LEDE has about a year of development beyond
> the OpenWRT codebase.
>
> David Lang



-- 
Abylay Ospan,
JokerSys
http://jokersys.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From xbing6 at gmail.com  Wed May  3 21:19:25 2017
From: xbing6 at gmail.com (Xuebing Wang)
Date: Thu, 4 May 2017 09:19:25 +0800
Subject: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on
	AR9331?
Message-ID: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>

Hi community,

I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
product.

I've used I2C on many projects, all with dedicated I2C controllers. I've 
never used GPIOs to simulate I2C on Linux.

I may be wrong, I am tending to think that there is no way to generate 
good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
all interrupts and maybe using high precision timer when outputing SCL/SDA?

Is "using gpio to simulate I2C bus" robust on AR9331?

Thanks.
Xuebing Wang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From msm-oss at mcclintock.net  Thu May  4 12:06:29 2017
From: msm-oss at mcclintock.net (Matthew McClintock)
Date: Thu, 4 May 2017 11:06:29 -0500
Subject: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on
	AR9331?
In-Reply-To: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
References: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
Message-ID: <CAEsOVNeSR3vx5tMSGdVvvCbJn5aZiV57z68PQ3mjcOc9Qqw4Pw@mail.gmail.com>

On Wed, May 3, 2017 at 8:19 PM, Xuebing Wang <xbing6 at gmail.com> wrote:
> Hi community,
>
> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial
> product.
>
> I've used I2C on many projects, all with dedicated I2C controllers. I've
> never used GPIOs to simulate I2C on Linux.
>
> I may be wrong, I am tending to think that there is no way to generate good
> I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable all
> interrupts and maybe using high precision timer when outputing SCL/SDA?
>
> Is "using gpio to simulate I2C bus" robust on AR9331?


What speeds are you trying to achieve? There is already a driver in
tree for bitbanged gpio.

-M
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From knaack.h at gmx.de  Thu May  4 17:18:36 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Thu, 4 May 2017 23:18:36 +0200
Subject: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on
 AR9331?
In-Reply-To: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
References: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
Message-ID: <8f97d1ea-21ed-6248-3c87-959cffbcfcf2@gmx.de>

Xuebing Wang schrieb am 04.05.2017 um 03:19:
> Hi community,
> 
> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
> product.
> 
> I've used I2C on many projects, all with dedicated I2C controllers. I've 
> never used GPIOs to simulate I2C on Linux.
> 
> I may be wrong, I am tending to think that there is no way to generate 
> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
> all interrupts and maybe using high precision timer when outputing SCL/SDA?
> 
> Is "using gpio to simulate I2C bus" robust on AR9331?
> 

I have been using a GPIO extender connected via I2C to a router powered by
an AR9132 (should be close enough), running for months without notable issues.
In that case, I2C traffic was pretty low, it just had to access the GPIOs of
the extender a couple of times per hour. It has been way better than using an
I2C-Tiny USB adapter, but that would be a different story.

> Thanks.
> Xuebing Wang
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170504/55d52274/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170504/55d52274/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From gareth41 at orcon.net.nz  Thu May  4 17:33:38 2017
From: gareth41 at orcon.net.nz (Gareth Parker)
Date: Fri, 5 May 2017 09:33:38 +1200
Subject: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on
	AR9331?
In-Reply-To: <8f97d1ea-21ed-6248-3c87-959cffbcfcf2@gmx.de>
References: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
 <8f97d1ea-21ed-6248-3c87-959cffbcfcf2@gmx.de>
Message-ID: <069401d2c51e$19a489b0$4ced9d10$@orcon.net.nz>

OpenWrt seems dead these days, active development is over at lede-project.

Also for i2c I would recommend using a PIC microcontroller, its far easier and designed for that purpose.  I use a PIC to control PLL IC's over i2c such as the TSA5511 in FM broadcast gear I design.

Gareth

-----Original Message-----
From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of Hartmut Knaack
Sent: Friday, 5 May 2017 9:19 a.m.
To: Xuebing Wang; OpenWrt Development List
Cc: John Crispin
Subject: Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on AR9331?

Xuebing Wang schrieb am 04.05.2017 um 03:19:
> Hi community,
> 
> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
> product.
> 
> I've used I2C on many projects, all with dedicated I2C controllers. 
> I've never used GPIOs to simulate I2C on Linux.
> 
> I may be wrong, I am tending to think that there is no way to generate 
> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
> all interrupts and maybe using high precision timer when outputing SCL/SDA?
> 
> Is "using gpio to simulate I2C bus" robust on AR9331?
> 

I have been using a GPIO extender connected via I2C to a router powered by an AR9132 (should be close enough), running for months without notable issues.
In that case, I2C traffic was pretty low, it just had to access the GPIOs of the extender a couple of times per hour. It has been way better than using an I2C-Tiny USB adapter, but that would be a different story.

> Thanks.
> Xuebing Wang
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From knaack.h at gmx.de  Thu May  4 17:57:32 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Thu, 4 May 2017 23:57:32 +0200
Subject: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on
 AR9331?
In-Reply-To: <069401d2c51e$19a489b0$4ced9d10$@orcon.net.nz>
References: <db8835b8-aab6-9fc0-97db-57aede57c9dc@gmail.com>
 <8f97d1ea-21ed-6248-3c87-959cffbcfcf2@gmx.de>
 <069401d2c51e$19a489b0$4ced9d10$@orcon.net.nz>
Message-ID: <f1f1fd69-7c34-8853-80d6-83b8a0ffc4d9@gmx.de>

Gareth Parker schrieb am 04.05.2017 um 23:33:
> OpenWrt seems dead these days, active development is over at lede-project.

True, but the question was not development-related.

> 
> Also for i2c I would recommend using a PIC microcontroller, its far easier and designed for that purpose.  I use a PIC to control PLL IC's over i2c such as the TSA5511 in FM broadcast gear I design.

And how do you connect to the PIC? First thing that would come to my mind would
be via rs232, but many OpenWrt devices provide just one such interface, and that
is already occupied for debugging messages and console login. Connecting via USB
doesn't look overly practical - I've used the I2C-Tiny USB and had lots of
troubles, caused by sudden USB disconnects and resets.
And any solution, where the kernel won't control the I2C bus, will prevent you from
using the massive amount of device drivers included in OpenWrt/LEDE or the Linux
kernel.

> 
> Gareth
> 
> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of Hartmut Knaack
> Sent: Friday, 5 May 2017 9:19 a.m.
> To: Xuebing Wang; OpenWrt Development List
> Cc: John Crispin
> Subject: Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on AR9331?
> 
> Xuebing Wang schrieb am 04.05.2017 um 03:19:
>> Hi community,
>>
>> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
>> product.
>>
>> I've used I2C on many projects, all with dedicated I2C controllers. 
>> I've never used GPIOs to simulate I2C on Linux.
>>
>> I may be wrong, I am tending to think that there is no way to generate 
>> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
>> all interrupts and maybe using high precision timer when outputing SCL/SDA?
>>
>> Is "using gpio to simulate I2C bus" robust on AR9331?
>>
> 
> I have been using a GPIO extender connected via I2C to a router powered by an AR9132 (should be close enough), running for months without notable issues.
> In that case, I2C traffic was pretty low, it just had to access the GPIOs of the extender a couple of times per hour. It has been way better than using an I2C-Tiny USB adapter, but that would be a different story.
> 
>> Thanks.
>> Xuebing Wang
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170504/56ab973d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170504/56ab973d/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat May  6 08:10:50 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat,  6 May 2017 14:10:50 +0200
Subject: [OpenWrt-Devel] [PATCH 1/4] ata: Add DT bindings for Faraday
	Technology FTIDE010
Message-ID: <20170506121053.11554-1-linus.walleij@linaro.org>

This adds device tree bindings for the Faraday Technology
FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC.

I am not 100% sure that this part if from Faraday Technology but
a lot points in that direction:

- A later IDE interface called FTIDE020 exist and share some
  properties.

- The SATA bridge has the same Built In Self Test (BIST) that the
  Faraday FTSATA100 seems to have, and it has version number 0100
  in the device ID register, so this is very likely a FTSATA100
  bundled with the FTIDE010.

Cc: devicetree at vger.kernel.org
Cc: John Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Greentime: I think this may be interesting to you since the
FTIDE020 will need the same bindings so we can probably
just reuse them and maybe make the parser a library if you
want to upstream the FTIDE020.

Faraday people: I do not have it from a source that this
hardware is really FTIDE010 but I would be VERY surprised
if it is not. U-Boot has an FTIDE020 IDE controller
synthesized in the Andestech platform, and it has a similar
yet different register layout, featuring similar timing
set-ups:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c
---
 .../devicetree/bindings/ata/faraday,ftide010.txt   | 63 ++++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/faraday,ftide010.txt

diff --git a/Documentation/devicetree/bindings/ata/faraday,ftide010.txt b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt
new file mode 100644
index 000000000000..5048408c07c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt
@@ -0,0 +1,63 @@
+* Faraday Technology FTIDE010 PATA controller
+
+This controller is the first Faraday IDE interface block, used in the
+StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini
+platform. The controller can do PIO modes 0 through 4, Multi-word DMA
+(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6.
+
+On the Gemini platform, this PATA block is accompanied by a PATA to
+SATA bridge in order to support SATA. This is why a phandle to that
+controller is compulsory on that platform.
+
+The timing properties are unique per-SoC, not per-board.
+
+Required properties:
+- compatible: should be one of
+  "cortina,gemini-pata", "faraday,ftide010"
+  "faraday,ftide010"
+- interrupts: interrupt for the block
+- reg: registers and size for the block
+
+  The unit of the below required timings is two clock periods of the ATA
+  reference clock which is 30 nanoseconds per unit at 66MHz and 20 nanoseconds
+  per unit at 50 MHz.
+
+- faraday,pio-active-time: array of 5 elements for T2 timing for Mode 0,
+  1, 2, 3 and 4. Range 0..15.
+- faraday,pio-recovery-time: array of 5 elements for T2l timing for Mode 0,
+  1, 2, 3 and 4. Range 0..15.
+- faraday,mdma-50-active-time: array of 4 elements for Td timing for multi
+  word DMA, Mode 0, 1, and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-50-recovery-time: array of 4 elements for Tk timing for
+  multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-66-active-time: array of 4 elements for Td timing for multi
+  word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-66-recovery-time: array of 4 elements for Tk timing for
+  multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,udma-50-setup-time: array of 4 elements for Tvds timing for ultra
+  DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz. Range 0..7.
+- faraday,udma-50-hold-time: array of 4 elements for Tdvh timing for
+  multi word DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz, Range 0..7.
+- faraday,udma-66-setup-time: array of 4 elements for Tvds timing for multi
+  word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+- faraday,udma-66-hold-time: array of 4 elements for Tdvh timing for
+  multi word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+
+Optional properties:
+- clocks: a SoC clock running the peripheral.
+- clock-names: should be set to "PCLK" for the peripheral clock.
+
+Required properties for "cortina,gemini-pata" compatible:
+- sata: a phande to the Gemini PATA to SATA bridge, see
+  cortina,gemini-sata-bridge.txt for details.
+
+Example:
+
+ata at 63000000 {
+	compatible = "cortina,gemini-pata", "faraday,ftide010";
+	reg = <0x63000000 0x100>;
+	interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+	clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+	clock-names = "PCLK";
+	sata = <&sata>;
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat May  6 08:10:51 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat,  6 May 2017 14:10:51 +0200
Subject: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini
	SATA bridge
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
Message-ID: <20170506121053.11554-2-linus.walleij@linaro.org>

This adds device tree bindings for the Cortina Systems Gemini
PATA to SATA bridge.

Cc: devicetree at vger.kernel.org
Cc: John Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../bindings/ata/cortina,gemini-sata-bridge.txt    | 55 ++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt

diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
new file mode 100644
index 000000000000..9fe92818b2fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
@@ -0,0 +1,55 @@
+* Cortina Systems Gemini SATA Bridge
+
+The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that
+takes two Faraday Technology FTIDE010 PATA controllers and bridges
+them in different configurations to two SATA ports.
+
+Required properties:
+- compatible: should be
+  "cortina,gemini-sata-bridge"
+- reg: registers and size for the block
+- resets: phandles to the reset lines for both SATA bridges
+- reset-names: must be "sata0", "sata1"
+- clocks: phandles to the compulsory peripheral clocks
+- clock-names: must be "SATA0_PCLK", "SATA1_PCLK"
+- syscon: a phandle to the global Gemini system controller
+- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for
+  the ATA controller and SATA bridges. Values 0..3:
+  Mode 0: ata0 master <-> sata0
+          ata1 master <-> sata1
+          ata0 slave interface brought out on IDE pads
+  Mode 1: ata0 master <-> sata0
+          ata1 master <-> sata1
+          ata1 slave interface brought out on IDE pads
+  Mode 2: ata1 master <-> sata1
+          ata1 slave  <-> sata0
+          ata0 master and slave interfaces brought out
+               on IDE pads
+  Mode 3: ata0 master <-> sata0
+          ata1 slave  <-> sata1
+          ata1 master and slave interfaces brought out
+               on IDE pads
+
+Optional boolean properties:
+- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection.
+  The muxmode setting decides whether ATA0 or ATA1 is brought out,
+  and whether master, slave or both interfaces get brought out.
+- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge
+  inside the Gemnini SoC. The Muxmode decides what PATA blocks will
+  be muxed out and how.
+
+Example:
+
+sata: sata at 46000000 {
+	compatible = "cortina,gemini-sata-bridge";
+	reg = <0x46000000 0x100>;
+	resets = <&rcon 26>, <&rcon 27>;
+	reset-names = "sata0", "sata1";
+	clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
+		 <&gcc GEMINI_CLK_GATE_SATA1>;
+	clock-names = "SATA0_PCLK", "SATA1_PCLK";
+	syscon = <&syscon>;
+	cortina,gemini-ata-muxmode = <3>;
+	cortina,gemini-enable-ide-pins;
+	cortina,gemini-enable-sata-bridge;
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat May  6 08:10:52 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat,  6 May 2017 14:10:52 +0200
Subject: [OpenWrt-Devel] [PATCH 3/4] ata: Add driver for Faraday Technology
	FTIDE010
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
Message-ID: <20170506121053.11554-3-linus.walleij@linaro.org>

This adds a driver for the Faraday Technology FTIDE010
PATA IP block.

When used with the Storlink/Storm/Cortina Systems Gemini
SoC, the PATA interface is accompanied by a PATA<->SATA
bridge, so while the device appear as a PATA controller,
it attaches physically to SATA disks, and also has a
designated memory area with registers to set up the bridge.

The Gemini SATA bridge is separated into its own driver
file to make things modular and make it possible to reuse
the PATA driver as stand-alone on other systems than the
Gemini.

dmesg excerpt from the D-Link DIR-685 storage router:
gemini-sata-bridge 46000000.sata: SATA ID 00000e00, PHY ID: 01000100
gemini-sata-bridge 46000000.sata: set up the Gemini IDE/SATA nexus
ftide010 63000000.ata: set up Gemini PATA0
ftide010 63000000.ata: device ID 00000500, irq 26, io base 0x63000000
ftide010 63000000.ata: SATA0 (master) start
gemini-sata-bridge 46000000.sata: SATA0 PHY ready
scsi host0: pata-ftide010
ata1: PATA max UDMA/133 irq 26
ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10302, max UDMA/133
ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      INTEL SSDSA2CW12 0302 PQ: 0 ANSI: 5
ata1.00: Enabling discard_zeroes_data
sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache:
                  enabled, doesn't support DPO or FUA
ata1.00: Enabling discard_zeroes_data
ata1.00: Enabling discard_zeroes_data
sd 0:0:0:0: [sda] Attached SCSI disk

After this I can flawlessly mount and read/write copy etc files
from /dev/sda[n].

Cc: John Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Faraday people: I do not have it from a source that this
hardware is really FTIDE010 but I would be VERY surprised
if it is not. U-Boot has an FTIDE020 IDE controller
synthesized in the Andestech platform, and it has a similar
yet different register layout, featuring similar timing
set-ups:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c
---
 MAINTAINERS                 |   9 +
 drivers/ata/Kconfig         |  21 ++
 drivers/ata/Makefile        |   2 +
 drivers/ata/pata_ftide010.c | 609 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/ata/sata_gemini.c   | 402 +++++++++++++++++++++++++++++
 drivers/ata/sata_gemini.h   |  20 ++
 6 files changed, 1063 insertions(+)
 create mode 100644 drivers/ata/pata_ftide010.c
 create mode 100644 drivers/ata/sata_gemini.c
 create mode 100644 drivers/ata/sata_gemini.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..95d1897683a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7405,6 +7405,15 @@ S:	Maintained
 F:	drivers/ata/pata_*.c
 F:	drivers/ata/ata_generic.c
 
+LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
+M:	Linus Walleij <linus.walleij at linaro.org>
+L:	linux-ide at vger.kernel.org
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git
+S:	Maintained
+F:	drivers/ata/pata_ftide010.c
+F:	drivers/ata/sata_gemini.c
+F:	drivers/ata/sata_gemini.h
+
 LIBATA SATA AHCI PLATFORM devices support
 M:	Hans de Goede <hdegoede at redhat.com>
 M:	Tejun Heo <tj at kernel.org>
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 70b57d2229d6..a8cd25b43502 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -205,6 +205,16 @@ config SATA_FSL
 
 	  If unsure, say N.
 
+config SATA_GEMINI
+	tristate "Gemini SATA bridge support"
+	depends on PATA_FTIDE010
+	default ARCH_GEMINI
+	help
+	  This enabled support for the FTIDE010 to SATA bridge
+	  found in Cortina Systems Gemini platform.
+
+	  If unsure, say N.
+
 config SATA_AHCI_SEATTLE
 	tristate "AMD Seattle 6.0Gbps AHCI SATA host controller support"
 	depends on ARCH_SEATTLE
@@ -582,6 +592,17 @@ config PATA_EP93XX
 
 	  If unsure, say N.
 
+config PATA_FTIDE010
+	tristate "Faraday Technology FTIDE010 PATA support"
+	depends on OF
+	depends on ARM
+	default ARCH_GEMINI
+	help
+	  This option enables support for the Faraday FTIDE010
+	  PATA controller found in the Cortina Gemini SoCs.
+
+	  If unsure, say N.
+
 config PATA_HPT366
 	tristate "HPT 366/368 PATA support"
 	depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 89a0a1915d36..85116267e487 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SATA_ACARD_AHCI)	+= acard-ahci.o libahci.o
 obj-$(CONFIG_SATA_AHCI_SEATTLE)	+= ahci_seattle.o libahci.o libahci_platform.o
 obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o libahci_platform.o
 obj-$(CONFIG_SATA_FSL)		+= sata_fsl.o
+obj-$(CONFIG_SATA_GEMINI)	+= sata_gemini.o
 obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
 obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
 obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
@@ -58,6 +59,7 @@ obj-$(CONFIG_PATA_CS5536)	+= pata_cs5536.o
 obj-$(CONFIG_PATA_CYPRESS)	+= pata_cypress.o
 obj-$(CONFIG_PATA_EFAR)		+= pata_efar.o
 obj-$(CONFIG_PATA_EP93XX)	+= pata_ep93xx.o
+obj-$(CONFIG_PATA_FTIDE010)	+= pata_ftide010.o
 obj-$(CONFIG_PATA_HPT366)	+= pata_hpt366.o
 obj-$(CONFIG_PATA_HPT37X)	+= pata_hpt37x.o
 obj-$(CONFIG_PATA_HPT3X2N)	+= pata_hpt3x2n.o
diff --git a/drivers/ata/pata_ftide010.c b/drivers/ata/pata_ftide010.c
new file mode 100644
index 000000000000..76ac2877b92d
--- /dev/null
+++ b/drivers/ata/pata_ftide010.c
@@ -0,0 +1,609 @@
+/*
+ * Faraday Technology FTIDE010 driver
+ * Copyright (C) 2017 Linus Walleij <linus.walleij at linaro.org>
+ *
+ * Includes portions of the SL2312/SL3516/Gemini PATA driver
+ * Copyright (C) 2003 StorLine, Inc <jason at storlink.com.tw>
+ * Copyright (C) 2009 Janos Laube <janos.dev at gmail.com>
+ * Copyright (C) 2010 Frederic Pecourt <opengemini at free.fr>
+ * Copyright (C) 2011 Tobias Waldvogel <tobias.waldvogel at gmail.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/libata.h>
+#include <linux/bitops.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include "sata_gemini.h"
+
+/**
+ * struct ftide010 - state container for the Faraday FTIDE010
+ * @dev: pointer back to the device representing this controller
+ * @base: remapped I/O space address
+ * @pclk: peripheral clock for the IDE block
+ * @host: pointer to the ATA host for this device
+ * @pio_timings: combined active/recovery values to be written to
+ * the PIO timing register for modes 0, 1, 2, 3 and 4.
+ * @mwdma_50_timings: combined active/recovery values to be written
+ * to the multiword DMA mode timing register for modes 0, 1 and 2
+ * at 50MHz speed
+ * @mwdma_66_timings: same as @mwdma_50_timings but for 66MHz
+ * @udma_50_timings: combined setup/hold values to be written
+ * to the ultra DMA mode timing register for modes 0-5 at 50MHz
+ * speed
+ * @udma_66_timings: combined setup/hold values to be written
+ * to the ultra DMA mode timing register for modes 0-6 at 66MHz
+ * speed
+ * @master_cbl: master cable type
+ * @slave_cbl: slave cable type
+ * @sg: Gemini SATA bridge pointer, if running on the Gemini
+ */
+struct ftide010 {
+	struct device *dev;
+	void __iomem *base;
+	struct clk *pclk;
+	struct ata_host *host;
+	u8 pio_timings[5];
+	u8 mwdma_50_timings[3];
+	u8 mwdma_66_timings[3];
+	u8 udma_50_timings[6];
+	u8 udma_66_timings[7];
+	unsigned int master_cbl;
+	unsigned int slave_cbl;
+	/* Gemini-specific properties */
+	struct sata_gemini *sg;
+	bool master_to_sata0;
+	bool slave_to_sata0;
+	bool master_to_sata1;
+	bool slave_to_sata1;
+};
+
+#define DMA_REG			0x00
+#define DMA_STATUS		0x02
+#define IDE_BMDTPR		0x04
+#define IDE_DEVICE_ID		0x08
+#define PIO_TIMING_REG		0x10
+#define MWDMA_TIMING_REG	0x11
+#define UDMA_TIMING0_REG	0x12 /* Master */
+#define UDMA_TIMING1_REG	0x13 /* Slave */
+#define CLK_MOD_REG		0x14
+/* These registers are mapped directly to the IDE registers */
+#define CMD_DATA_REG		0x20
+#define ERROR_FEATURES_REG	0x21
+#define NSECT_REG		0x22
+#define LBAL_REG		0x23
+#define LBAM_REG		0x24
+#define LBAH_REG		0x25
+#define DEVICE_REG		0x26
+#define STATUS_COMMAND_REG	0x27
+#define ALTSTAT_CTRL_REG	0x36
+
+/* Set this bit for UDMA mode 5 and 6 */
+#define UDMA_TIMING_MODE_56	BIT(7)
+
+/* 0 = 50 MHz, 1 = 66 MHz */
+#define CLK_MOD_DEV0_CLK_SEL	BIT(0)
+#define CLK_MOD_DEV1_CLK_SEL	BIT(1)
+/* Enable UDMA on a device */
+#define CLK_MOD_DEV0_UDMA_EN	BIT(4)
+#define CLK_MOD_DEV1_UDMA_EN	BIT(5)
+
+static struct scsi_host_template pata_ftide010_sht = {
+	ATA_BMDMA_SHT("pata-ftide010"),
+};
+
+/*
+ * We set 66 MHz for all MWDMA modes
+ */
+static const bool set_mdma_66_mhz[] = { true, true, true, true };
+
+/*
+ * We set 66 MHz for UDMA modes 3, 4 and 6 and no others
+ */
+static const bool set_udma_66_mhz[] = { false, false, false, true, true, false, true };
+
+static void ftide010_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+{
+	struct ftide010 *ftide = ap->host->private_data;
+	unsigned short speed = adev->dma_mode;
+	u8 devno = adev->devno & 1;
+	u8 udma_en_mask;
+	u8 f66m_en_mask;
+	u8 clkreg;
+	u8 timreg;
+	unsigned int i;
+
+	/* Target device 0 (master) or 1 (slave) */
+	if (!devno) {
+		udma_en_mask = CLK_MOD_DEV0_UDMA_EN;
+		f66m_en_mask = CLK_MOD_DEV0_CLK_SEL;
+	} else {
+		udma_en_mask = CLK_MOD_DEV1_UDMA_EN;
+		f66m_en_mask = CLK_MOD_DEV1_CLK_SEL;
+	}
+
+	clkreg = ioread8(ftide->base + CLK_MOD_REG);
+	clkreg &= ~udma_en_mask;
+	clkreg &= ~f66m_en_mask;
+
+	if (speed & XFER_UDMA_0) {
+		i = speed & ~XFER_UDMA_0;
+		dev_dbg(ftide->dev, "set UDMA mode %02x, index %d\n",
+			speed, i);
+
+		clkreg |= udma_en_mask;
+		if (set_udma_66_mhz[i]) {
+			clkreg |= f66m_en_mask;
+			timreg = ftide->udma_66_timings[i];
+		} else {
+			timreg = ftide->udma_50_timings[i];
+		}
+
+		/* A special bit needs to be set for modes 5 and 6 */
+		if (i >= 5)
+			timreg |= UDMA_TIMING_MODE_56;
+
+		dev_dbg(ftide->dev, "UDMA write clkreg = %02x, timreg = %02x\n",
+			clkreg, timreg);
+
+		writeb(clkreg, ftide->base + CLK_MOD_REG);
+		writeb(timreg, ftide->base + UDMA_TIMING0_REG + devno);
+	} else {
+		i = speed & ~XFER_MW_DMA_0;
+		dev_dbg(ftide->dev, "set MWDMA mode %02x, index %d\n",
+			speed, i);
+
+		if (set_mdma_66_mhz[i]) {
+			clkreg |= f66m_en_mask;
+			timreg = ftide->mwdma_66_timings[i];
+		} else {
+			timreg = ftide->mwdma_50_timings[i];
+		}
+		dev_dbg(ftide->dev,
+			"MWDMA write clkreg = %02x, timreg = %02x\n",
+			clkreg, timreg);
+		/* This will affect all devices */
+		writeb(clkreg, ftide->base + CLK_MOD_REG);
+		writeb(timreg, ftide->base + MWDMA_TIMING_REG);
+	}
+
+	return;
+}
+
+static void ftide010_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	struct ftide010 *ftide = ap->host->private_data;
+	unsigned int pio = adev->pio_mode - XFER_PIO_0;
+
+	dev_dbg(ftide->dev, "set PIO mode %02x, index %d\n",
+		adev->pio_mode, pio);
+	writeb(ftide->pio_timings[pio], ftide->base + PIO_TIMING_REG);
+}
+
+static struct ata_port_operations pata_ftide010_port_ops = {
+	.inherits	= &ata_bmdma_port_ops,
+	.set_dmamode	= ftide010_set_dmamode,
+	.set_piomode	= ftide010_set_piomode,
+};
+
+static struct ata_port_info ftide010_port_info[] = {
+	{
+		.flags		= ATA_FLAG_SLAVE_POSS,
+		.mwdma_mask	= ATA_MWDMA2,
+		.udma_mask	= ATA_UDMA6,
+		.pio_mask	= ATA_PIO4,
+		.port_ops	= &pata_ftide010_port_ops,
+	},
+};
+
+static int pata_ftide010_parse_timing_item(struct ftide010 *ftide,
+					   const char *activeprop,
+					   const char *recoveryprop,
+					   int index, u32 maxval,
+					   u8 *timing)
+{
+	struct device_node *np = ftide->dev->of_node;
+	u8 timing_ret;
+	int ret;
+	u32 val;
+
+	ret = of_property_read_u32_index(np, activeprop, index, &val);
+	if (ret) {
+		dev_err(ftide->dev, "error reading element %d of %s\n",
+			index, activeprop);
+		return ret;
+	}
+	if (val > maxval) {
+		dev_err(ftide->dev,
+			"element %d of %s is out of range (max 15)\n",
+			index, activeprop);
+		return -EINVAL;
+	}
+	timing_ret = (u8)(val << 4);
+
+	ret = of_property_read_u32_index(np, recoveryprop, index, &val);
+	if (ret) {
+		dev_err(ftide->dev, "error reading element %d of %s\n",
+			index, recoveryprop);
+		return ret;
+	}
+	if (val > maxval) {
+		dev_err(ftide->dev,
+			"element %d of %s is out of range (max 15)\n",
+			index, recoveryprop);
+		return -EINVAL;
+	}
+	timing_ret |= (u8)val;
+
+	*timing = timing_ret;
+	return 0;
+}
+
+static int pata_ftide010_parse_of_timings(struct ftide010 *ftide)
+{
+	int i;
+	u8 timing;
+	int ret;
+
+	for (i = 0; i < sizeof(ftide->pio_timings); i++) {
+		ret = pata_ftide010_parse_timing_item(ftide,
+				      "faraday,pio-active-time",
+				      "faraday,pio-recovery-time",
+				      i, 15,
+				      &timing);
+		if (ret)
+			return ret;
+		ftide->pio_timings[i] = timing;
+		dev_dbg(ftide->dev, "PIO time [%d] = %02x\n", i, timing);
+	}
+
+	for (i = 0; i < sizeof(ftide->mwdma_50_timings); i++) {
+		ret = pata_ftide010_parse_timing_item(ftide,
+				      "faraday,mdma-50-active-time",
+				      "faraday,mdma-50-recovery-time",
+				      i, 15,
+				      &timing);
+		if (ret)
+			return ret;
+		ftide->mwdma_50_timings[i] = timing;
+		dev_dbg(ftide->dev, "MWDMA 50 time [%d] = %02x\n", i, timing);
+	}
+
+	for (i = 0; i < sizeof(ftide->mwdma_66_timings); i++) {
+		ret = pata_ftide010_parse_timing_item(ftide,
+				      "faraday,mdma-66-active-time",
+				      "faraday,mdma-66-recovery-time",
+				      i, 15,
+				      &timing);
+		if (ret)
+			return ret;
+		ftide->mwdma_66_timings[i] = timing;
+		dev_dbg(ftide->dev, "MWDMA 66 time [%d] = %02x\n", i, timing);
+	}
+
+	for (i = 0; i < sizeof(ftide->udma_50_timings); i++) {
+		ret = pata_ftide010_parse_timing_item(ftide,
+				      "faraday,udma-50-setup-time",
+				      "faraday,udma-50-hold-time",
+				      i, 7,
+				      &timing);
+		if (ret)
+			return ret;
+		ftide->udma_50_timings[i] = timing;
+		dev_dbg(ftide->dev, "UDMA 50 time [%d] = %02x\n", i, timing);
+	}
+
+	for (i = 0; i < sizeof(ftide->udma_66_timings); i++) {
+		ret = pata_ftide010_parse_timing_item(ftide,
+				      "faraday,udma-66-setup-time",
+				      "faraday,udma-66-hold-time",
+				      i, 7,
+				      &timing);
+		if (ret)
+			return ret;
+		ftide->udma_66_timings[i] = timing;
+		dev_dbg(ftide->dev, "UMDMA 66 time [%d] = %02x\n", i, timing);
+	}
+
+	return 0;
+}
+
+#if IS_ENABLED(CONFIG_SATA_GEMINI)
+
+static int pata_ftide010_gemini_port_start(struct ata_port *ap)
+{
+	struct ftide010 *ftide = ap->host->private_data;
+	struct device *dev = ftide->dev;
+	struct sata_gemini *sg = ftide->sg;
+	int ret;
+
+	ret = ata_bmdma_port_start(ap);
+	if (ret)
+		return ret;
+
+	if (ftide->master_to_sata0) {
+		dev_info(dev, "SATA0 (master) start\n");
+		ret = gemini_sata_start_bridge(sg, 0);
+		if (ret)
+			return ret;
+	}
+	if (ftide->master_to_sata1) {
+		dev_info(dev, "SATA1 (master) start\n");
+		ret = gemini_sata_start_bridge(sg, 1);
+		if (ret)
+			return ret;
+	}
+	/* Avoid double-starting */
+	if (ftide->slave_to_sata0 && !ftide->master_to_sata0) {
+		dev_info(dev, "SATA0 (slave) start\n");
+		ret = gemini_sata_start_bridge(sg, 0);
+		if (ret)
+			return ret;
+	}
+	/* Avoid double-starting */
+	if (ftide->slave_to_sata1 && !ftide->master_to_sata1) {
+		dev_info(dev, "SATA1 (slave) start\n");
+		ret = gemini_sata_start_bridge(sg, 1);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static void pata_ftide010_gemini_port_stop(struct ata_port *ap)
+{
+	struct ftide010 *ftide = ap->host->private_data;
+	struct device *dev = ftide->dev;
+	struct sata_gemini *sg = ftide->sg;
+
+	if (ftide->master_to_sata0) {
+		dev_info(dev, "SATA0 (master) stop\n");
+		gemini_sata_stop_bridge(sg, 0);
+	}
+	if (ftide->master_to_sata1) {
+		dev_info(dev, "SATA1 (master) stop\n");
+		gemini_sata_stop_bridge(sg, 1);
+	}
+	/* Avoid double-stopping */
+	if (ftide->slave_to_sata0 && !ftide->master_to_sata0) {
+		dev_info(dev, "SATA0 (slave) stop\n");
+		gemini_sata_stop_bridge(sg, 0);
+	}
+	/* Avoid double-stopping */
+	if (ftide->slave_to_sata1 && !ftide->master_to_sata1) {
+		dev_info(dev, "SATA1 (slave) stop\n");
+		gemini_sata_stop_bridge(sg, 1);
+	}
+}
+
+static int pata_ftide010_gemini_cable_detect(struct ata_port *ap)
+{
+	struct ftide010 *ftide = ap->host->private_data;
+
+	/*
+	 * Return the master cable, I have no clue how to return a different
+	 * cable for the slave than for the master.
+	 */
+	return ftide->master_cbl;
+}
+
+static int pata_ftide010_gemini_init(struct ftide010 *ftide,
+				     bool is_ata1)
+{
+	struct device *dev = ftide->dev;
+	struct sata_gemini *sg;
+	enum gemini_muxmode muxmode;
+
+	/* Look up SATA bridge */
+	sg = gemini_sata_bridge_get();
+	if (IS_ERR(sg))
+		return PTR_ERR(sg);
+	ftide->sg = sg;
+
+	muxmode = gemini_sata_get_muxmode(sg);
+
+	/* Special ops */
+	pata_ftide010_port_ops.port_start =
+		pata_ftide010_gemini_port_start;
+	pata_ftide010_port_ops.port_stop =
+		pata_ftide010_gemini_port_stop;
+	pata_ftide010_port_ops.cable_detect =
+		pata_ftide010_gemini_cable_detect;
+
+	/* Flag port as SATA-capable */
+	if (gemini_sata_bridge_enabled(sg, is_ata1))
+		ftide010_port_info[0].flags |= ATA_FLAG_SATA;
+
+	if (!is_ata1) {
+		switch (muxmode) {
+		case GEMINI_MUXMODE_0:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_PATA40;
+			ftide->master_to_sata0 = true;
+			break;
+		case GEMINI_MUXMODE_1:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_NONE;
+			ftide->master_to_sata0 = true;
+			break;
+		case GEMINI_MUXMODE_2:
+			ftide->master_cbl = ATA_CBL_PATA40;
+			ftide->slave_cbl = ATA_CBL_PATA40;
+			break;
+		case GEMINI_MUXMODE_3:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_SATA;
+			ftide->master_to_sata0 = true;
+			ftide->slave_to_sata1 = true;
+			break;
+		}
+	} else {
+		switch (muxmode) {
+		case GEMINI_MUXMODE_0:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_NONE;
+			ftide->master_to_sata1 = true;
+			break;
+		case GEMINI_MUXMODE_1:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_PATA40;
+			ftide->master_to_sata1 = true;
+			break;
+		case GEMINI_MUXMODE_2:
+			ftide->master_cbl = ATA_CBL_SATA;
+			ftide->slave_cbl = ATA_CBL_SATA;
+			ftide->slave_to_sata0 = true;
+			ftide->master_to_sata1 = true;
+			break;
+		case GEMINI_MUXMODE_3:
+			ftide->master_cbl = ATA_CBL_PATA40;
+			ftide->slave_cbl = ATA_CBL_PATA40;
+			break;
+		}
+	}
+	dev_info(dev, "set up Gemini PATA%d\n", is_ata1);
+
+	return 0;
+}
+#else
+static int pata_ftide010_gemini_init(struct ftide010 *ftide,
+				     bool is_ata1)
+{
+	return -ENOTSUPP;
+}
+#endif
+
+static int pata_ftide010_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	const struct ata_port_info pi = ftide010_port_info[0];
+	const struct ata_port_info *ppi[] = { &pi, NULL };
+	struct ftide010 *ftide;
+	struct resource *res;
+	int irq;
+	int ret;
+	int i;
+
+	ftide = devm_kzalloc(dev, sizeof(*ftide), GFP_KERNEL);
+	if (!ftide)
+		return -ENOMEM;
+	ftide->dev = dev;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	ftide->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ftide->base))
+		return PTR_ERR(ftide->base);
+
+	ftide->pclk = devm_clk_get(dev, "PCLK");
+	if (!IS_ERR(ftide->pclk)) {
+		ret = clk_prepare_enable(ftide->pclk);
+		if (ret) {
+			dev_err(dev, "failed to enable PCLK\n");
+			return ret;
+		}
+	}
+
+	/* Read out timings from the device tree */
+	ret = pata_ftide010_parse_of_timings(ftide);
+	if (ret)
+		goto err_dis_clk;
+
+	/* Some special Cortina Gemini init, if needed */
+	if (of_device_is_compatible(np, "cortina,gemini-pata")) {
+		/*
+		 * We need to know which instance is probing (the
+		 * Gemini has two instances of FTIDE010) and we do
+		 * this simply by looking at the physical base
+		 * address, which is 0x63400000 for ATA1, else we
+		 * are ATA0. This will also set up the cable types.
+		 */
+		ret = pata_ftide010_gemini_init(ftide,
+				(res->start == 0x63400000));
+		if (ret)
+			goto err_dis_clk;
+	} else {
+		/* Else assume we are connected using PATA40 */
+		ftide->master_cbl = ATA_CBL_PATA40;
+		ftide->slave_cbl = ATA_CBL_PATA40;
+	}
+
+	ftide->host = ata_host_alloc_pinfo(dev, ppi, 1);
+	if (!ftide->host) {
+		ret = -ENOMEM;
+		goto err_dis_clk;
+	}
+	ftide->host->private_data = ftide;
+
+	for (i = 0; i < ftide->host->n_ports; i++) {
+		struct ata_port *ap = ftide->host->ports[i];
+		struct ata_ioports *ioaddr = &ap->ioaddr;
+
+		ioaddr->bmdma_addr = ftide->base + DMA_REG;
+		ioaddr->cmd_addr = ftide->base + CMD_DATA_REG;
+		ioaddr->ctl_addr = ftide->base + ALTSTAT_CTRL_REG;
+		ioaddr->altstatus_addr = ftide->base + ALTSTAT_CTRL_REG;
+		ata_sff_std_ports(ioaddr);
+	}
+
+	platform_set_drvdata(pdev, ftide);
+	dev_info(dev, "device ID %08x, irq %d, io base 0x%08x\n",
+		 readl(ftide->base + IDE_DEVICE_ID), irq, res->start);
+
+	ret = ata_host_activate(ftide->host, irq, ata_bmdma_interrupt,
+				0, &pata_ftide010_sht);
+	if (ret)
+		goto err_remove_host;
+
+
+	return 0;
+
+err_remove_host:
+	ata_host_detach(ftide->host);
+err_dis_clk:
+	if (!IS_ERR(ftide->pclk))
+		clk_disable_unprepare(ftide->pclk);
+	return ret;
+}
+
+static int pata_ftide010_remove(struct platform_device *pdev)
+{
+	struct ftide010 *ftide = platform_get_drvdata(pdev);
+
+	ata_host_detach(ftide->host);
+	if (!IS_ERR(ftide->pclk))
+		clk_disable_unprepare(ftide->pclk);
+
+	return 0;
+}
+
+static const struct of_device_id pata_ftide010_of_match[] = {
+	{
+		.compatible = "faraday,ftide010",
+	},
+	{},
+};
+
+static struct platform_driver pata_ftide010_driver = {
+	.driver = {
+		.name = "ftide010",
+		.of_match_table = of_match_ptr(pata_ftide010_of_match),
+	},
+	.probe = pata_ftide010_probe,
+	.remove = pata_ftide010_remove,
+};
+module_platform_driver(pata_ftide010_driver);
+
+MODULE_AUTHOR("Linus Walleij <linus.walleij at linaro.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pata-ftide010");
diff --git a/drivers/ata/sata_gemini.c b/drivers/ata/sata_gemini.c
new file mode 100644
index 000000000000..04491675f540
--- /dev/null
+++ b/drivers/ata/sata_gemini.c
@@ -0,0 +1,402 @@
+/*
+ * Cortina Systems Gemini SATA bridge add-on to Faraday FTIDE010
+ * Copyright (C) 2017 Linus Walleij <linus.walleij at linaro.org>
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include "sata_gemini.h"
+
+/**
+ * struct sata_gemini - a state container for a Gemini SATA bridge
+ * @dev: the containing device
+ * @base: remapped I/O memory base
+ * @muxmode: the current muxing mode
+ * @ide_pins: if the device is using the plain IDE interface pins
+ * @sata_bridge: if the device enables the SATA bridge
+ * @sata0_reset: SATA0 reset handler
+ * @sata1_reset: SATA1 reset handler
+ */
+struct sata_gemini {
+	struct device *dev;
+	void __iomem *base;
+	enum gemini_muxmode muxmode;
+	bool ide_pins;
+	bool sata_bridge;
+	struct reset_control *sata0_reset;
+	struct reset_control *sata1_reset;
+	struct clk *sata0_pclk;
+	struct clk *sata1_pclk;
+};
+
+/* Global IDE PAD Skew Control Register */
+#define GLOBAL_IDE_SKEW_CTRL		0x18
+#define IDE1_HOST_STROBE_DELAY_SHIFT	28
+#define IDE1_DEVICE_STROBE_DELAY_SHIFT	24
+#define IDE1_OUTPUT_IO_SKEW_SHIFT	20
+#define IDE1_INPUT_IO_SKEW_SHIFT	16
+#define IDE0_HOST_STROBE_DELAY_SHIFT	12
+#define IDE0_DEVICE_STROBE_DELAY_SHIFT	8
+#define IDE0_OUTPUT_IO_SKEW_SHIFT	4
+#define IDE0_INPUT_IO_SKEW_SHIFT	0
+
+/* Miscellaneous Control Register */
+#define GLOBAL_MISC_CTRL		0x30
+/*
+ * Values of IDE IOMUX bits in the misc control register
+ *
+ * Bits 26:24 are "IDE IO Select", which decides what SATA
+ * adapters are connected to which of the two IDE/ATA
+ * controllers in the Gemini. We can connect the two IDE blocks
+ * to one SATA adapter each, both acting as master, or one IDE
+ * blocks to two SATA adapters so the IDE block can act in a
+ * master/slave configuration.
+ *
+ * We also bring out different blocks on the actual IDE
+ * pins (not SATA pins) if (and only if) these are muxed in.
+ *
+ * 111-100 - Reserved
+ * Mode 0: 000 - ata0 master <-> sata0
+ *               ata1 master <-> sata1
+ *               ata0 slave interface brought out on IDE pads
+ * Mode 1: 001 - ata0 master <-> sata0
+ *               ata1 master <-> sata1
+ *               ata1 slave interface brought out on IDE pads
+ * Mode 2: 010 - ata1 master <-> sata1
+ *               ata1 slave  <-> sata0
+ *               ata0 master and slave interfaces brought out
+ *                    on IDE pads
+ * Mode 3: 011 - ata0 master <-> sata0
+ *               ata1 slave  <-> sata1
+ *               ata1 master and slave interfaces brought out
+ *                    on IDE pads
+ */
+#define IDE_IOMUX_MASK			(7 << 24)
+#define IDE_IOMUX_MODE0			(0 << 24)
+#define IDE_IOMUX_MODE1			(1 << 24)
+#define IDE_IOMUX_MODE2			(2 << 24)
+#define IDE_IOMUX_MODE3			(3 << 24)
+#define IDE_IOMUX_SHIFT			(24)
+#define IDE_PADS_ENABLE			BIT(4)
+#define PFLASH_PADS_DISABLE		BIT(1)
+
+/*
+ * Registers directly controlling the PATA<->SATA adapters
+ */
+#define SATA_ID				0x00
+#define SATA_PHY_ID			0x04
+#define SATA0_STATUS			0x08
+#define SATA1_STATUS			0x0c
+#define SATA0_CTRL			0x18
+#define SATA1_CTRL			0x1c
+
+#define SATA_STATUS_BIST_DONE		BIT(5)
+#define SATA_STATUS_BIST_OK		BIT(4)
+#define SATA_STATUS_PHY_READY		BIT(0)
+
+#define SATA_CTRL_PHY_BIST_EN		BIT(14)
+#define SATA_CTRL_PHY_FORCE_IDLE	BIT(13)
+#define SATA_CTRL_PHY_FORCE_READY	BIT(12)
+#define SATA_CTRL_PHY_AFE_LOOP_EN	BIT(10)
+#define SATA_CTRL_PHY_DIG_LOOP_EN	BIT(9)
+#define SATA_CTRL_HOTPLUG_DETECT_EN	BIT(4)
+#define SATA_CTRL_ATAPI_EN		BIT(3)
+#define SATA_CTRL_BUS_WITH_20		BIT(2)
+#define SATA_CTRL_SLAVE_EN		BIT(1)
+#define SATA_CTRL_EN			BIT(0)
+
+/*
+ * There is only ever one instance of this bridge on a system,
+ * so create a singleton so that the FTIDE010 instances can grab
+ * a reference to it.
+ */
+static struct sata_gemini *sg_singleton;
+
+struct sata_gemini *gemini_sata_bridge_get(void)
+{
+	if (sg_singleton)
+		return sg_singleton;
+	return ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL(gemini_sata_bridge_get);
+
+bool gemini_sata_bridge_enabled(struct sata_gemini *sg, bool is_ata1)
+{
+	if (!sg->sata_bridge)
+		return false;
+	/*
+	 * In muxmode 2 and 3 one of the ATA controllers is
+	 * actually not connected to any SATA bridge.
+	 */
+	if ((sg->muxmode == GEMINI_MUXMODE_2) &&
+	    !is_ata1)
+		return false;
+	if ((sg->muxmode == GEMINI_MUXMODE_3) &&
+	    is_ata1)
+		return false;
+	return true;
+}
+EXPORT_SYMBOL(gemini_sata_bridge_enabled);
+
+enum gemini_muxmode gemini_sata_get_muxmode(struct sata_gemini *sg)
+{
+	return sg->muxmode;
+}
+EXPORT_SYMBOL(gemini_sata_get_muxmode);
+
+static int gemini_sata_setup_bridge(struct sata_gemini *sg,
+				    unsigned int bridge)
+{
+	unsigned long timeout = jiffies + (HZ * 1);
+	u32 val;
+
+	if (bridge == 0) {
+		val = SATA_CTRL_HOTPLUG_DETECT_EN | SATA_CTRL_EN;
+		/* SATA0 slave mode is only used in muxmode 2 */
+		if (sg->muxmode == GEMINI_MUXMODE_2)
+			val |= SATA_CTRL_SLAVE_EN;
+		writel(val, sg->base + SATA0_CTRL);
+	} else {
+		val = SATA_CTRL_HOTPLUG_DETECT_EN | SATA_CTRL_EN;
+		/* SATA1 slave mode is only used in muxmode 3 */
+		if (sg->muxmode == GEMINI_MUXMODE_3)
+			val |= SATA_CTRL_SLAVE_EN;
+		writel(val, sg->base + SATA1_CTRL);
+	}
+
+	/* Vendor code waits 10 ms here */
+	msleep(10);
+
+	/* Wait for PHY to become ready */
+	do {
+		msleep(100);
+
+		if (bridge == 0)
+			val = readl(sg->base + SATA0_STATUS);
+		else
+			val = readl(sg->base + SATA1_STATUS);
+		if (val & SATA_STATUS_PHY_READY)
+			break;
+	} while (time_before(jiffies, timeout));
+
+	dev_info(sg->dev, "SATA%d PHY %s\n", bridge,
+		 (val & SATA_STATUS_PHY_READY) ? "ready" : "not ready");
+	return 0;
+}
+
+int gemini_sata_start_bridge(struct sata_gemini *sg, unsigned int bridge)
+{
+	if (bridge == 0)
+		clk_enable(sg->sata0_pclk);
+	else
+		clk_enable(sg->sata1_pclk);
+	msleep(10);
+	return gemini_sata_setup_bridge(sg, bridge);
+}
+EXPORT_SYMBOL(gemini_sata_start_bridge);
+
+void gemini_sata_stop_bridge(struct sata_gemini *sg, unsigned int bridge)
+{
+	if (bridge == 0)
+		clk_disable(sg->sata0_pclk);
+	else
+		clk_disable(sg->sata1_pclk);
+}
+EXPORT_SYMBOL(gemini_sata_stop_bridge);
+
+int gemini_sata_reset_bridge(struct sata_gemini *sg,
+			     unsigned int bridge)
+{
+	if (bridge == 0)
+		reset_control_reset(sg->sata0_reset);
+	else
+		reset_control_reset(sg->sata1_reset);
+	msleep(10);
+	return gemini_sata_setup_bridge(sg, bridge);
+}
+EXPORT_SYMBOL(gemini_sata_reset_bridge);
+
+static int gemini_sata_bridge_init(struct sata_gemini *sg)
+{
+	struct device *dev = sg->dev;
+	u32 sata_id, sata_phy_id;
+	int ret;
+
+	sg->sata0_pclk = devm_clk_get(dev, "SATA0_PCLK");
+	if (IS_ERR(sg->sata0_pclk)) {
+		dev_err(dev, "no SATA0 PCLK");
+		return -ENODEV;
+	}
+	sg->sata1_pclk = devm_clk_get(dev, "SATA1_PCLK");
+	if (IS_ERR(sg->sata1_pclk)) {
+		dev_err(dev, "no SATA1 PCLK");
+		return -ENODEV;
+	}
+
+	ret = clk_prepare_enable(sg->sata0_pclk);
+	if (ret) {
+		pr_err("failed to enable SATA0 PCLK\n");
+		return ret;
+	}
+	ret = clk_prepare_enable(sg->sata1_pclk);
+	if (ret) {
+		pr_err("failed to enable SATA1 PCLK\n");
+		return ret;
+	}
+
+	sg->sata0_reset = devm_reset_control_get(dev, "sata0");
+	if (IS_ERR(sg->sata0_reset)) {
+		dev_err(dev, "no SATA0 reset controller\n");
+		return PTR_ERR(sg->sata0_reset);
+	}
+	sg->sata1_reset = devm_reset_control_get(dev, "sata1");
+	if (IS_ERR(sg->sata1_reset)) {
+		dev_err(dev, "no SATA1 reset controller\n");
+		return PTR_ERR(sg->sata1_reset);
+	}
+
+	sata_id = readl(sg->base + SATA_ID);
+	sata_phy_id = readl(sg->base + SATA_PHY_ID);
+	sg->sata_bridge = true;
+	clk_disable(sg->sata0_pclk);
+	clk_disable(sg->sata1_pclk);
+
+	dev_info(dev, "SATA ID %08x, PHY ID: %08x\n", sata_id, sata_phy_id);
+
+	return 0;
+}
+
+static int gemini_sata_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct sata_gemini *sg;
+	static struct regmap *map;
+	struct resource *res;
+	enum gemini_muxmode muxmode;
+	u32 gmode;
+	u32 gmask;
+	u32 val;
+	int ret;
+
+	sg = devm_kzalloc(dev, sizeof(*sg), GFP_KERNEL);
+	if (!sg)
+		return -ENOMEM;
+	sg->dev = dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	sg->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(sg->base))
+		return PTR_ERR(sg->base);
+
+	map = syscon_regmap_lookup_by_phandle(np, "syscon");
+	if (IS_ERR(map)) {
+		dev_err(dev, "no global syscon\n");
+		return PTR_ERR(map);
+	}
+
+	/* Set up the SATA bridge if need be */
+	if (of_property_read_bool(np, "cortina,gemini-enable-sata-bridge")) {
+		ret = gemini_sata_bridge_init(sg);
+		if (ret)
+			return ret;
+	}
+
+	if (of_property_read_bool(np, "cortina,gemini-enable-ide-pins"))
+		sg->ide_pins = true;
+
+	if (!sg->sata_bridge && !sg->ide_pins) {
+		dev_err(dev, "neither SATA bridge or IDE output enabled\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(np, "cortina,gemini-ata-muxmode", &muxmode);
+	if (ret) {
+		dev_err(dev, "could not parse ATA muxmode\n");
+		return ret;
+	}
+	if (muxmode > GEMINI_MUXMODE_3) {
+		dev_err(dev, "illegal muxmode %d\n", muxmode);
+		return -EINVAL;
+	}
+	sg->muxmode = muxmode;
+	gmask = IDE_IOMUX_MASK;
+	gmode = (muxmode << IDE_IOMUX_SHIFT);
+
+	/*
+	 * If we mux out the IDE, parallel flash must be disabled.
+	 * SATA0 and SATA1 have dedicated pins and may coexist with
+	 * parallel flash.
+	 */
+	if (sg->ide_pins)
+		gmode |= IDE_PADS_ENABLE | PFLASH_PADS_DISABLE;
+	else
+		gmask |= IDE_PADS_ENABLE;
+
+	ret = regmap_update_bits(map, GLOBAL_MISC_CTRL, gmask, gmode);
+	if (ret) {
+		dev_err(dev, "unable to set up IDE muxing\n");
+		return -ENODEV;
+	}
+
+	/* FIXME: add more elaborate IDE skew control handling */
+	if (sg->ide_pins) {
+		ret = regmap_read(map, GLOBAL_IDE_SKEW_CTRL, &val);
+		if (ret) {
+			dev_err(dev, "cannot read IDE skew control register\n");
+			return ret;
+		}
+		dev_info(dev, "IDE skew control: %08x\n", val);
+	}
+
+	dev_info(dev, "set up the Gemini IDE/SATA nexus\n");
+	platform_set_drvdata(pdev, sg);
+	sg_singleton = sg;
+
+	return 0;
+}
+
+static int gemini_sata_remove(struct platform_device *pdev)
+{
+	struct sata_gemini *sg = platform_get_drvdata(pdev);
+
+	clk_unprepare(sg->sata0_pclk);
+	clk_unprepare(sg->sata1_pclk);
+	sg_singleton = NULL;
+
+	return 0;
+}
+
+static const struct of_device_id gemini_sata_of_match[] = {
+	{
+		.compatible = "cortina,gemini-sata-bridge",
+	},
+	{},
+};
+
+static struct platform_driver gemini_sata_driver = {
+	.driver = {
+		.name = "gemini-sata-bridge",
+		.of_match_table = of_match_ptr(gemini_sata_of_match),
+	},
+	.probe = gemini_sata_probe,
+	.remove = gemini_sata_remove,
+};
+module_platform_driver(gemini_sata_driver);
+
+MODULE_AUTHOR("Linus Walleij <linus.walleij at linaro.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gemini-sata-bridge");
diff --git a/drivers/ata/sata_gemini.h b/drivers/ata/sata_gemini.h
new file mode 100644
index 000000000000..519c119ec71c
--- /dev/null
+++ b/drivers/ata/sata_gemini.h
@@ -0,0 +1,20 @@
+/* Header for the Gemini SATA bridge */
+#ifdef CONFIG_SATA_GEMINI
+
+struct sata_gemini;
+
+enum gemini_muxmode {
+	GEMINI_MUXMODE_0 = 0,
+	GEMINI_MUXMODE_1,
+	GEMINI_MUXMODE_2,
+	GEMINI_MUXMODE_3,
+};
+
+struct sata_gemini *gemini_sata_bridge_get(void);
+bool gemini_sata_bridge_enabled(struct sata_gemini *sg, bool is_ata1);
+enum gemini_muxmode gemini_sata_get_muxmode(struct sata_gemini *sg);
+int gemini_sata_start_bridge(struct sata_gemini *sg, unsigned int bridge);
+void gemini_sata_stop_bridge(struct sata_gemini *sg, unsigned int bridge);
+int gemini_sata_reset_bridge(struct sata_gemini *sg, unsigned int bridge);
+
+#endif
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat May  6 08:10:53 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat,  6 May 2017 14:10:53 +0200
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add Gemini PATA/SATA support
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
Message-ID: <20170506121053.11554-4-linus.walleij@linaro.org>

The NAS4229B and SQ201 Gemini systems have a PATA controller
which is linked to a SATA bridge in the SoC. Enable both
platforms to use the PATA/SATA devices.

Cc: John Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
PATA maintainers: this file will be applied by me through the ARM
SoC git tree. It is provided for reference only so you see how
it will be used.
---
 arch/arm/boot/dts/gemini-nas4220b.dts | 10 +++++++
 arch/arm/boot/dts/gemini-sq201.dts    | 10 +++++++
 arch/arm/boot/dts/gemini.dtsi         | 56 +++++++++++++++++++++++++++++++++++
 3 files changed, 76 insertions(+)

diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index 7668ba52158e..55f6a4f1f801 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -98,5 +98,15 @@
 				read-only;
 			};
 		};
+
+		sata: sata at 46000000 {
+			cortina,gemini-ata-muxmode = <0>;
+			cortina,gemini-enable-sata-bridge;
+			status = "okay";
+		};
+
+		ata at 63000000 {
+			status = "okay";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
index 46309e79cc7b..4d200f0bcd45 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -93,6 +93,12 @@
 			};
 		};
 
+		sata: sata at 46000000 {
+			cortina,gemini-ata-muxmode = <0>;
+			cortina,gemini-enable-sata-bridge;
+			status = "okay";
+		};
+
 		pci at 50000000 {
 			status = "okay";
 			interrupt-map-mask = <0xf800 0 0 7>;
@@ -114,5 +120,9 @@
 				<0x6000 0 0 3 &pci_intc 1>,
 				<0x6000 0 0 4 &pci_intc 2>;
 		};
+
+		ata at 63000000 {
+			status = "okay";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 6fe678a68e31..a50ad49d38f5 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -89,6 +89,18 @@
 			clock-names = "PCLK", "EXTCLK";
 		};
 
+		sata: sata at 46000000 {
+			compatible = "cortina,gemini-sata-bridge";
+			reg = <0x46000000 0x100>;
+			resets = <&rcon 26>, <&rcon 27>;
+			reset-names = "sata0", "sata1";
+			clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
+				 <&gcc GEMINI_CLK_GATE_SATA1>;
+			clock-names = "SATA0_PCLK", "SATA1_PCLK";
+			syscon = <&syscon>;
+			status = "disabled";
+		};
+
 		intcon: interrupt-controller at 48000000 {
 			compatible = "faraday,ftintc010";
 			reg = <0x48000000 0x1000>;
@@ -183,5 +195,49 @@
 				#interrupt-cells = <1>;
 			};
 		};
+
+		ata at 63000000 {
+			compatible = "cortina,gemini-pata", "faraday,ftide010";
+			reg = <0x63000000 0x1000>;
+			interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+			resets = <&rcon 2>;
+			clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+			clock-names = "PCLK";
+			sata = <&sata>;
+			status = "disabled";
+			/* PIO timings assume 33 MHz bus speed */
+			faraday,pio-active-time = <10>, <10>, <10>, <3>, <3>;
+			faraday,pio-recovery-time = <10>, <3>, <1>, <3>, <1>;
+			faraday,mdma-50-active-time = <6>, <2>, <2>;
+			faraday,mdma-50-recovery-time = <6>, <2>, <1>;
+			faraday,mdma-66-active-time = <8>, <3>, <3>;
+			faraday,mdma-66-recovery-time = <8>, <2>, <1>;
+			faraday,udma-50-setup-time = <3>, <3>, <2>, <2>, <1>, <1>;
+			faraday,udma-50-hold-time = <3>, <1>, <1>, <1>, <1>, <1>;
+			faraday,udma-66-setup-time = <4>, <4>, <3>, <2>, <1>, <1>, <1>;
+			faraday,udma-66-hold-time = <4>, <2>, <1>, <1>, <1>, <1>, <1>;
+		};
+
+		ata at 63400000 {
+			compatible = "cortina,gemini-pata", "faraday,ftide010";
+			reg = <0x63400000 0x1000>;
+			interrupts = <5 IRQ_TYPE_EDGE_RISING>;
+			resets = <&rcon 2>;
+			clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+			clock-names = "PCLK";
+			sata = <&sata>;
+			status = "disabled";
+			/* PIO timings assume 33 MHz bus speed */
+			faraday,pio-active-time = <10>, <10>, <10>, <3>, <3>;
+			faraday,pio-recovery-time = <10>, <3>, <1>, <3>, <1>;
+			faraday,mdma-50-active-time = <6>, <2>, <2>;
+			faraday,mdma-50-recovery-time = <6>, <2>, <1>;
+			faraday,mdma-66-active-time = <8>, <3>, <3>;
+			faraday,mdma-66-recovery-time = <8>, <2>, <1>;
+			faraday,udma-50-setup-time = <3>, <3>, <2>, <2>, <1>, <1>;
+			faraday,udma-50-hold-time = <3>, <1>, <1>, <1>, <1>, <1>;
+			faraday,udma-66-setup-time = <4>, <4>, <3>, <2>, <1>, <1>, <1>;
+			faraday,udma-66-hold-time = <4>, <2>, <1>, <1>, <1>, <1>, <1>;
+		};
 	};
 };
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun May  7 06:33:52 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 7 May 2017 12:33:52 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2] clk: Add bindings for the Gemini
	Clock Controller
In-Reply-To: <20170428182401.rpn7ytxvu6shy5sn@rob-hp-laptop>
References: <20170424185545.26608-1-linus.walleij@linaro.org>
 <20170428182401.rpn7ytxvu6shy5sn@rob-hp-laptop>
Message-ID: <CACRpkdbMTete8j0PFUnZUQBSMtu+FR+7TSwMJ-gh-Tt=hY0v+w@mail.gmail.com>

On Fri, Apr 28, 2017 at 8:24 PM, Rob Herring <robh at kernel.org> wrote:
> On Mon, Apr 24, 2017 at 08:55:45PM +0200, Linus Walleij wrote:

>> This adds device tree bindings and a header for the Gemini SoC
>> Clock Controller.
(...)
>> +- compatible : shall contain the following:
>> +  "cortina,gemini-clock-controller"
>> +- #clock-cells should be <1>
(...)
>> +Example:
>> +
>> +syscon: syscon at 40000000 {
>> +     compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
>> +     reg = <0x40000000 0x1000>;
>> +
>> +     clock-controller {
>> +             compatible = "cortina,gemini-clock-controller";
>> +             #clock-cells = <1>;
>
> There's not really much reason to have a child node here. The parent can
> be the clock provider.

But I should still keep the special clock controller compatible-string?
I guess it is also possible to just bind all the drivers to
"cortina,gemini-syscon".

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Sun May  7 12:39:03 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Sun, 7 May 2017 18:39:03 +0200 (CEST)
Subject: [OpenWrt-Devel] [PATCH 1/4] ata: Add DT bindings for Faraday
 Technology FTIDE010
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
Message-ID: <alpine.LNX.2.00.1705071837310.18983@T420s>

Hi Linus

On Sat, 6 May 2017, Linus Walleij wrote:

> This adds device tree bindings for the Faraday Technology
> FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC.
> 
> I am not 100% sure that this part if from Faraday Technology but
> a lot points in that direction:
> 
> - A later IDE interface called FTIDE020 exist and share some
>   properties.
> 
> - The SATA bridge has the same Built In Self Test (BIST) that the
>   Faraday FTSATA100 seems to have, and it has version number 0100
>   in the device ID register, so this is very likely a FTSATA100
>   bundled with the FTIDE010.
> 
> Cc: devicetree at vger.kernel.org
> Cc: John Feng-Hsin Chiang <john453 at faraday-tech.com>
> Cc: Greentime Hu <green.hu at gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

nice work !
you can add my

Acked-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>

on the whole patch set.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun May  7 15:23:58 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 7 May 2017 21:23:58 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2] reset: Add a Gemini reset controller
In-Reply-To: <1493109822.2394.15.camel@pengutronix.de>
References: <20170424192802.27430-1-linus.walleij@linaro.org>
 <1493109822.2394.15.camel@pengutronix.de>
Message-ID: <CACRpkdaRkWY7qF43-XxOPu5h0cR3_w3ydHs3Ln-Oay+bzw4JWA@mail.gmail.com>

On Tue, Apr 25, 2017 at 10:43 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> [Me]
>> +/*
>> + * Cortina Gemini Reset controller driver
>> + * Copyright (c) 2017 Linus Walleij <linus.walleij at linaro.org>
>
> No license statement, choice or oversight?

Choice. I'm one of those guys who think that the top-level COPYING file
in the kernel is by far enough of legalese. If you want, I can put in a license
of course.

>> +struct gemini_reset {
>> +     struct regmap *map;
>> +     struct device *dev;
>
> dev is unused, can be dropped.

OK

> BIT(30) is called CPU1 reset in the DT binding, maybe add a #define?

OK I have the new .h file that Rob asked for.

>> +static int gemini_reset_probe(struct platform_device *pdev)
>> +{
>> +     struct gemini_reset *gr;
>> +     struct device *dev = &pdev->dev;
>> +     struct device_node *np = dev->of_node;
>> +     struct device_node *parent_np = np->parent;
>> +     int ret;
>> +
>> +     if (!parent_np) {
>
> Is this even possible?

Goes away anyways when i fuse the syscon and reset controller
as Rob suggested.

>> +     if (IS_ERR(gr->map)) {
>> +             dev_err(dev, "unable to get regmap");
>
> It might be helpful to print the error code here.

OK.

>> +     ret = devm_reset_controller_register(&pdev->dev, &gr->rcdev);
>> +     if (ret)
>> +             return ret;
>> +
>> +     dev_info(dev, "registered Gemini reset controller\n");
>
> This is a bit verbose. I'd remove it and shorten the last part to:
>
>         return devm_reset_controller_register(&pdev->dev, &gr->rcdev);

It's always this thing whether to be in the camp that like drivers to announce
themselves or not, but I can do as you suggest if it's a strong preference.

The reason I want it is: deselect the driver from Kconfig, something stops
working. Compare the dmesg: they both look the same. You don't immediately
see that something is missing.

So some people think that it is time to go around in /sys, and then what
if it is a boot regression, like the system can't mount root without the
reset controller. (Yeah I know, the thing mounting root should select the
reset controller then, OK another bug we would have seen with this...)

And then all of a sudden there is a lot of debug time spent looking for this
fact that would be spotted in no time if the was a dev_info() about the
driver being probed.

But if you insist, I will remove it.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pieter.smith at philips.com  Mon May  8 07:43:39 2017
From: pieter.smith at philips.com (Smith, Pieter)
Date: Mon, 8 May 2017 11:43:39 +0000
Subject: [OpenWrt-Devel] Factory startup issues since mount_root /
 libfstools improvements in Chaos Calmer
In-Reply-To: <4818aa28546948458468163f7200512e@VI1PR9003MB0253.MGDPHG.emi.philips.com>
References: <1b0f8ebd7c9748d099aea99949d7ffb8@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwkx+ypoHeVDUrcsDK7frOXMXOfjvpRhQvwJMb_9YNUtA@mail.gmail.com>
 <41c1b8bc4cf44d90a88d68faf0ca233c@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b9e3c74a-8439-fb49-c53d-c9a23beb0ba7@gmail.com>
 <4818aa28546948458468163f7200512e@VI1PR9003MB0253.MGDPHG.emi.philips.com>
Message-ID: <b560f9382a1e4953903be989fe42bdb3@VI1PR9003MB0253.MGDPHG.emi.philips.com>

Hi Rafa?,

I am still hoping to get confirmation from you on this patch. Is this acceptable for upstreaming?

> Hi Rafa?,
>
> > > On 03/29/2017 11:53 AM, Smith, Pieter wrote:
> > > > My apologies. I am not able to get mutt working with our corporate
> > > > infrastructure. I hope it arrives unmangled as an attachment. If
> > > > not, I'll use my personal mail.
> > >
> > > This would be acceptable for me to pick patch sent as attachment,
> > > but you really need to sign it off with your name. Please add a
> > > proper
> > > Signed-off-by:
> > > line and resend.
> >
> > Off-course! My bad...
>
> In adding more logging so that you can diagnose the issue, I tracked down the root cause and fixed the issue. Attached, > please find an updated patch with sign-off and a problem description.
>
> - Pieter

Regards,
Pieter


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May  8 09:19:40 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 8 May 2017 15:19:40 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
Message-ID: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>

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

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

From dwmw2 at infradead.org  Mon May  8 09:29:04 2017
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 08 May 2017 14:29:04 +0100
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <1494250144.5407.16.camel@infradead.org>

On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
> 
> *) 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

Yes, we can redirect the existing lists to the new ones ? so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.

I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170508/dd709740/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From toke at toke.dk  Mon May  8 09:43:41 2017
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 08 May 2017 15:43:41 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org> (John
 Crispin's message of "Mon, 8 May 2017 15:19:40 +0200")
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <87o9v3jwfm.fsf@alrua-kau>

John Crispin <john at phrozen.org> writes:

> 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.

Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?

> - update the landing page to have the same look & feel as the current openwrt
> landing page

Well, I like the L&F of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)

> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy

Links to these?

-Toke
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Mon May  8 10:51:41 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Mon, 8 May 2017 16:51:41 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <87o9v3jwfm.fsf@alrua-kau>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <87o9v3jwfm.fsf@alrua-kau>
Message-ID: <5bc08f5e-0d0a-2fc6-7da1-c9c8f26fb6c2@openwrt.org>

On 2017-05-08 15:43, Toke H?iland-J?rgensen wrote:
> John Crispin <john at phrozen.org> writes:
>
>> 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.
>
> Great to hear progress is being made on this! I think the proposal looks
> reasonable, generally. A few comments / questions:
>
> - What will this mean for the community rules and the release schedule?
>   Will they continue from the current LEDE practices?
>
>> - update the landing page to have the same look & feel as the current openwrt
>> landing page
>
> Well, I like the L&F of lede-project.org better - but it's not something
> worth bikeshedding over, so meh, fine... ;)

Well, the OpenWrt one might be from 2000s, but the LEDE one is from '95 
;) I think the CSS jow did for the OpenWrt forum looks the best TBH :)

>> *) trademark/sponsorship policy
>> - review/ack imres trademark policy
>> - review/ack jows sponsorship policy
>
> Links to these?

On the tm policy: https://openwrt.org/trademark - I guess jow will chime 
in with the location of the sponsorship one, too.




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

From john at phrozen.org  Mon May  8 10:54:02 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 8 May 2017 16:54:02 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1494250144.5407.16.camel@infradead.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <1494250144.5407.16.camel@infradead.org>
Message-ID: <e5259e4e-4e69-76ea-b5cb-17814c333de0@phrozen.org>



On 08/05/17 15:29, David Woodhouse wrote:
> On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
>> *) 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
> Yes, we can redirect the existing lists to the new ones ? so for
> example, mail sent to lede-dev will just turn up on the openwrt-dev
> list instead. Assuming that's what you meant.
>
> For importing subscribers, if that's what you want to do, I'd be
> inclined to send *invitations* not just subscribe people. So each
> person will get the 'someone has requested that your address be
> subscribed; click here to actually do it' message. We can write our own
> blurb to go out at the top of those invitations.

Hi David,

Thanks for clarifying this, sending out invites does sound reasonable.

>
> I still haven't worked out if I actually have a vote here or not but
> FWIW the rest of the proposal looked good to me.

glad that you like it.

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

From wigyori at uid0.hu  Mon May  8 15:19:42 2017
From: wigyori at uid0.hu (Zoltan HERPAI)
Date: Mon, 8 May 2017 21:19:42 +0200 (CEST)
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <ab3a399b4054233369f08cc896a5a14e@pyret.net>
References: <ab3a399b4054233369f08cc896a5a14e@pyret.net>
Message-ID: <alpine.DEB.2.02.1705082110400.31664@trabant.deployis.eu>

Hi,

On Mon, 8 May 2017, Daniel Engberg wrote:

> Trac:
> Is it really worth keeping trac at all? What value does it add? Just display 
> a page explaining that it's shutdown and forward to OpenWrt?

There is a lot of "added value" in the tickets submitted throughout the 
years, either as comments, notes, fixes or just the issue being raised, so
it's a good idea to keep it for archiving purposes. Older devices do die, 
but every year or so I come across shops selling brand new WRT54G 
(really), so keeping the knowledge base in an unsorted form (compared to a 
wiki) to the users can be useful. Whether that's a staticized archive or 
running the trac engine itself is another question.

Other than that, I very much welcome the groundwork for the planned merge 
- thanks John, Imre and Felix for putting it together.

Regards,
Zoltan H
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Mon May  8 15:43:20 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Mon, 8 May 2017 21:43:20 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <alpine.DEB.2.02.1705082110400.31664@trabant.deployis.eu>
References: <ab3a399b4054233369f08cc896a5a14e@pyret.net>
 <alpine.DEB.2.02.1705082110400.31664@trabant.deployis.eu>
Message-ID: <20170508194319.GB2636@makrotopia.org>

On Mon, May 08, 2017 at 09:19:42PM +0200, Zoltan HERPAI wrote:
> Hi,
> 
> On Mon, 8 May 2017, Daniel Engberg wrote:
> 
> > Trac:
> > Is it really worth keeping trac at all? What value does it add? Just
> > display a page explaining that it's shutdown and forward to OpenWrt?
> 
> There is a lot of "added value" in the tickets submitted throughout the
> years, either as comments, notes, fixes or just the issue being raised, so
> it's a good idea to keep it for archiving purposes. Older devices do die,
> but every year or so I come across shops selling brand new WRT54G (really),
> so keeping the knowledge base in an unsorted form (compared to a wiki) to
> the users can be useful. Whether that's a staticized archive or running the
> trac engine itself is another question.

I agree that there are a lot of references to dev.openwrt.org which
should remain intact. A non-interactive version would imho be
sufficient, tickets which are actually still relevant should be
re-opened on bugs.lede-project.org (which will become bugs.openwrt.org)
A grace period of 1 month starting from the notification until the
service is being shutdown (or archived read-only) would also be nice.

> 
> Other than that, I very much welcome the groundwork for the planned merge -
> thanks John, Imre and Felix for putting it together.

I agree. Thanks a lot for all the work done, this is great progress!


Cheers


Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:07:20 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 May 2017 22:07:20 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] reset: Add DT bindings for the
	Gemini reset controller
Message-ID: <20170508200720.26145-1-linus.walleij@linaro.org>

This is a simple reset controller in a single 32bit
register.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Move the reset controller node to be the same as the syscon
  node, no need for a specific child node.
- Add an include file with nice #defines.
---
 .../bindings/reset/cortina,gemini-reset.txt        | 58 ++++++++++++++++++++++
 include/dt-bindings/reset/cortina,gemini-reset.h   | 36 ++++++++++++++
 2 files changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
 create mode 100644 include/dt-bindings/reset/cortina,gemini-reset.h

diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
new file mode 100644
index 000000000000..aa3d1b2a9677
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
@@ -0,0 +1,58 @@
+Cortina Gemini Reset Controller
+
+This reset controller is found in Cortina Systems CS3516 and
+the predecessor StorLink SL3516.
+
+Required properties:
+- compatible: "cortina,gemini-reset"
+- #reset-cells: Must be 1
+
+The Gemini reset controller must be identical to the system controller node.
+Apart from this it follows the standard reset controller bindings.
+
+Valid reset line values:
+
+0:  DRAM controller
+1:  Flash controller
+2:  IDE controller
+3:  RAID controller
+4:  Security module
+5:  GMAC0 (ethernet)
+6:  GMAC1 (ethernet)
+7:  PCI host bridge
+8:  USB0 USB host controller
+9:  USB1 USB host controller
+10: General DMA controller
+11: APB bridge
+12: LPC (Low Pin Count) controller
+13: LCD module
+14: Interrupt controller 0
+15: Interrupt controller 1
+16: RTC module
+17: Timer module
+18: UART controller
+19: SSP controller
+20: GPIO0 GPIO controller
+21: GPIO1 GPIO controller
+22: GPIO2 GPIO controller
+23: Watchdog timer
+24: External device reset
+25: CIR module (infrared)
+26: SATA0 SATA bridge
+27: SATA1 SATA bridge
+28: TVE TV Encoder module
+29: Reserved
+30: CPU1 reset
+31: Global soft reset
+
+These also have shorthand defines in the include file:
+<dt-bindings/reset/cortina,gemini-reset.h>
+
+Example:
+
+syscon: syscon at 40000000 {
+	compatible = "cortina,gemini-syscon", "cortina,gemini-reset",
+		     "syscon", "simple-mfd";
+	reg = <0x40000000 0x1000>;
+	#reset-cells = <1>;
+};
diff --git a/include/dt-bindings/reset/cortina,gemini-reset.h b/include/dt-bindings/reset/cortina,gemini-reset.h
new file mode 100644
index 000000000000..aebecae43721
--- /dev/null
+++ b/include/dt-bindings/reset/cortina,gemini-reset.h
@@ -0,0 +1,36 @@
+#ifndef _DT_BINDINGS_RESET_CORTINA_GEMINI_H
+#define _DT_BINDINGS_RESET_CORTINA_GEMINI_H
+
+#define GEMINI_RESET_DRAM	0
+#define GEMINI_RESET_FLASH	1
+#define GEMINI_RESET_IDE	2
+#define GEMINI_RESET_RAID	3
+#define GEMINI_RESET_SECURITY	4
+#define GEMINI_RESET_GMAC0	5
+#define GEMINI_RESET_GMAC1	6
+#define GEMINI_RESET_PCI	7
+#define GEMINI_RESET_USB0	8
+#define GEMINI_RESET_USB1	9
+#define GEMINI_RESET_DMAC	10
+#define GEMINI_RESET_APB	11
+#define GEMINI_RESET_LPC	12
+#define GEMINI_RESET_LCD	13
+#define GEMINI_RESET_INTCON0	14
+#define GEMINI_RESET_INTCON1	15
+#define GEMINI_RESET_RTC	16
+#define GEMINI_RESET_TIMER	17
+#define GEMINI_RESET_UART	18
+#define GEMINI_RESET_SSP	19
+#define GEMINI_RESET_GPIO0	20
+#define GEMINI_RESET_GPIO1	21
+#define GEMINI_RESET_GPIO2	22
+#define GEMINI_RESET_WDOG	23
+#define GEMINI_RESET_EXTERN	24
+#define GEMINI_RESET_CIR	25
+#define GEMINI_RESET_SATA0	26
+#define GEMINI_RESET_SATA1	27
+#define GEMINI_RESET_TVE	28
+#define GEMINI_RESET_CPU1	30
+#define GEMINI_RESET_GLOBAL	31
+
+#endif
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:07:40 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 May 2017 22:07:40 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2 v2] reset: Add a Gemini reset controller
Message-ID: <20170508200740.26194-1-linus.walleij@linaro.org>

The Cortina Systems Gemini reset controller is a simple
32bit register with self-deasserting reset lines. It is
accessed using regmap over syscon.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Add an explicit GPL license statement.
- Move the reset controller to be identical to the sycon
  node, no need to a separate child node for this.
- Drop unneeded struct device *dev pointer from state
  container.
- Print error code on missing regmap.
- Use #define from the <dt-bindings/*> to indicate that we
  always set the CPU1 reset line to 1 when writing the
  resets.
---
 drivers/reset/Kconfig        |   7 +++
 drivers/reset/Makefile       |   1 +
 drivers/reset/reset-gemini.c | 110 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 118 insertions(+)
 create mode 100644 drivers/reset/reset-gemini.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index f4cdfe94b9ec..a82e1a78de25 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -27,6 +27,13 @@ config RESET_BERLIN
 	help
 	  This enables the reset controller driver for Marvell Berlin SoCs.
 
+config RESET_GEMINI
+	bool "Gemini Reset Driver" if COMPILE_TEST
+	default ARCH_GEMINI
+	select MFD_SYSCON
+	help
+	  This enables the reset controller driver for Cortina Systems Gemini.
+
 config RESET_LPC18XX
 	bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
 	default ARCH_LPC18XX
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 2cd3f6c45165..99e90ad18545 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_GEMINI) += reset-gemini.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
diff --git a/drivers/reset/reset-gemini.c b/drivers/reset/reset-gemini.c
new file mode 100644
index 000000000000..ebe59eb25b20
--- /dev/null
+++ b/drivers/reset/reset-gemini.c
@@ -0,0 +1,110 @@
+/*
+ * Cortina Gemini Reset controller driver
+ * Copyright (C) 2017 Linus Walleij <linus.walleij at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <dt-bindings/reset/cortina,gemini-reset.h>
+
+/**
+ * struct gemini_reset - gemini reset controller
+ * @map: regmap to access the containing system controller
+ * @rcdev: reset controller device
+ */
+struct gemini_reset {
+	struct regmap *map;
+	struct reset_controller_dev rcdev;
+};
+
+#define GEMINI_GLOBAL_SOFT_RESET 0x0c
+
+#define to_gemini_reset(p) \
+	container_of((p), struct gemini_reset, rcdev)
+
+/*
+ * This is a self-deasserting reset controller.
+ */
+static int gemini_reset(struct reset_controller_dev *rcdev,
+			unsigned long id)
+{
+	struct gemini_reset *gr = to_gemini_reset(rcdev);
+
+	/* Manual says to always set BIT 30 (CPU1) to 1 */
+	return regmap_write(gr->map,
+			    GEMINI_GLOBAL_SOFT_RESET,
+			    BIT(GEMINI_RESET_CPU1) | BIT(id));
+}
+
+static int gemini_reset_status(struct reset_controller_dev *rcdev,
+			     unsigned long id)
+{
+	struct gemini_reset *gr = to_gemini_reset(rcdev);
+	u32 val;
+	int ret;
+
+	ret = regmap_read(gr->map, GEMINI_GLOBAL_SOFT_RESET, &val);
+	if (ret)
+		return ret;
+
+	return !!(val & BIT(id));
+}
+
+static const struct reset_control_ops gemini_reset_ops = {
+	.reset = gemini_reset,
+	.status = gemini_reset_status,
+};
+
+static int gemini_reset_probe(struct platform_device *pdev)
+{
+	struct gemini_reset *gr;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	int ret;
+
+	gr = devm_kzalloc(dev, sizeof(*gr), GFP_KERNEL);
+	if (!gr)
+		return -ENOMEM;
+
+	gr->map = syscon_node_to_regmap(np);
+	if (IS_ERR(gr->map)) {
+		ret = PTR_ERR(gr->map);
+		dev_err(dev, "unable to get regmap (%d)", ret);
+		return ret;
+	}
+	gr->rcdev.owner = THIS_MODULE;
+	gr->rcdev.nr_resets = 32;
+	gr->rcdev.ops = &gemini_reset_ops;
+	gr->rcdev.of_node = pdev->dev.of_node;
+
+	ret = devm_reset_controller_register(&pdev->dev, &gr->rcdev);
+	if (ret)
+		return ret;
+
+	dev_info(dev, "registered Gemini reset controller\n");
+	return 0;
+}
+
+static const struct of_device_id gemini_reset_dt_ids[] = {
+	{ .compatible = "cortina,gemini-reset", },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver gemini_reset_driver = {
+	.probe	= gemini_reset_probe,
+	.driver = {
+		.name		= "gemini-reset",
+		.of_match_table	= gemini_reset_dt_ids,
+		.suppress_bind_attrs = true,
+	},
+};
+builtin_platform_driver(gemini_reset_driver);
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:11:59 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 May 2017 22:11:59 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini
	Clock Controller
Message-ID: <20170508201159.31634-1-linus.walleij@linaro.org>

This adds device tree bindings and a header for the Gemini SoC
Clock Controller.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Move the clock controller to be directly in the parent syscon
  node.
---
 .../clock/cortina,gemini-clock-controller.txt      | 22 ++++++++++++++++
 include/dt-bindings/clock/cortina,gemini-clock.h   | 29 ++++++++++++++++++++++
 2 files changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
 create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h

diff --git a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
new file mode 100644
index 000000000000..ae0046bccba0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
@@ -0,0 +1,22 @@
+Clock bindings for the Cortina Systems Gemini SoC Clock Controller
+
+Required properties :
+- compatible : shall contain the following:
+  "cortina,gemini-clock-controller"
+- #clock-cells should be <1>
+
+The Gemini clock controller needs to be identical to the system controller
+node.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
+tree sources.
+
+Example:
+
+syscon: syscon at 40000000 {
+	compatible = "cortina,gemini-syscon", "cortina,gemini-clock-controller",
+		     "syscon", "simple-mfd";
+	reg = <0x40000000 0x1000>;
+	#clock-cells = <1>;
+};
diff --git a/include/dt-bindings/clock/cortina,gemini-clock.h b/include/dt-bindings/clock/cortina,gemini-clock.h
new file mode 100644
index 000000000000..acf5cd550b0c
--- /dev/null
+++ b/include/dt-bindings/clock/cortina,gemini-clock.h
@@ -0,0 +1,29 @@
+#ifndef DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+#define DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+
+/* RTC, AHB, APB, CPU, PCI, TVC, UART clocks and 13 gates */
+#define GEMINI_NUM_CLKS 20
+
+#define GEMINI_CLK_RTC 0
+#define GEMINI_CLK_AHB 1
+#define GEMINI_CLK_APB 2
+#define GEMINI_CLK_CPU 3
+#define GEMINI_CLK_PCI 4
+#define GEMINI_CLK_TVC 5
+#define GEMINI_CLK_UART 6
+#define GEMINI_CLK_GATES 7
+#define GEMINI_CLK_GATE_SECURITY 7
+#define GEMINI_CLK_GATE_GMAC0 8
+#define GEMINI_CLK_GATE_GMAC1 9
+#define GEMINI_CLK_GATE_SATA0 10
+#define GEMINI_CLK_GATE_SATA1 11
+#define GEMINI_CLK_GATE_USB0 12
+#define GEMINI_CLK_GATE_USB1 13
+#define GEMINI_CLK_GATE_IDE 14
+#define GEMINI_CLK_GATE_PCI 15
+#define GEMINI_CLK_GATE_DDR 16
+#define GEMINI_CLK_GATE_FLASH 17
+#define GEMINI_CLK_GATE_TVC 18
+#define GEMINI_CLK_GATE_BOOT 19
+
+#endif /* DT_BINDINGS_CORTINA_GEMINI_CLOCK_H */
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:12:21 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 May 2017 22:12:21 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2 v2] clk: Add Gemini SoC clock controller
Message-ID: <20170508201221.31684-1-linus.walleij@linaro.org>

The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock
controller that derive all clocks from a single crystal, using some
documented and some undocumented PLLs, half dividers, counters and
gates. This is a best attempt to construct a clock driver for the
clocks so at least we can gate off unused hardware and driver the
PCI bus clock.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Move the clock controller to be part of the syscon node. No
  need for a separate child node for this.
---
 drivers/clk/Kconfig      |   7 +
 drivers/clk/Makefile     |   1 +
 drivers/clk/clk-gemini.c | 358 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 366 insertions(+)
 create mode 100644 drivers/clk/clk-gemini.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9356ab4b7d76..9e7619f9bf0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -118,6 +118,13 @@ config COMMON_CLK_CS2000_CP
 	help
 	  If you say yes here you get support for the CS2000 clock multiplier.
 
+config COMMON_CLK_GEMINI
+	bool "Clock driver for Cortina Systems Gemini SoC"
+	select MFD_SYSCON
+	---help---
+	  This driver supports the SoC clocks on the Cortina Systems Gemini
+	  platform, also known as SL3516 or CS3516.
+
 config COMMON_CLK_S2MPS11
 	tristate "Clock driver for S2MPS1X/S5M8767 MFD"
 	depends on MFD_SEC_CORE || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 92c12b86c2e8..e100d911a554 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_COMMON_CLK_CDCE925)	+= clk-cdce925.o
 obj-$(CONFIG_ARCH_CLPS711X)		+= clk-clps711x.o
 obj-$(CONFIG_COMMON_CLK_CS2000_CP)	+= clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
+obj-$(CONFIG_COMMON_CLK_GEMINI)		+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
 obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
new file mode 100644
index 000000000000..340c2570f24e
--- /dev/null
+++ b/drivers/clk/clk-gemini.c
@@ -0,0 +1,358 @@
+/*
+ * Cortina Gemini Clock Controller driver
+ * Copyright (c) 2017 Linus Walleij <linus.walleij at linaro.org>
+ */
+
+#define pr_fmt(fmt) "clk-gemini: " fmt
+
+#include <linux/clkdev.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <dt-bindings/clock/cortina,gemini-clock.h>
+
+/* Globally visible clocks */
+static DEFINE_SPINLOCK(gemini_clk_lock);
+static struct clk *gemini_clks[GEMINI_NUM_CLKS];
+static struct clk_onecell_data gemini_clk_data;
+
+#define GEMINI_GLOBAL_STATUS 0x04
+#define PLL_OSC_SEL BIT(30)
+#define AHBSPEED_SHIFT (15)
+#define AHBSPEED_MASK 0x07
+#define CPU_AHB_RATIO_SHIFT (18)
+#define CPU_AHB_RATIO_MASK 0x03
+
+#define GEMINI_GLOBAL_PLL_CONTROL 0x08
+
+#define GEMINI_GLOBAL_MISC_CONTROL 0x30
+#define PCI_CLK_66MHZ BIT(18)
+#define PCI_CLK_OE BIT(17)
+
+#define GEMINI_GLOBAL_CLOCK_CONTROL 0x34
+#define PCI_CLKRUN_EN BIT(16)
+#define TVC_HALFDIV_SHIFT (24)
+#define TVC_HALFDIV_MASK 0x1f
+#define SECURITY_CLK_SEL BIT(29)
+
+#define GEMINI_GLOBAL_PCI_DLL_CONTROL 0x44
+#define PCI_DLL_BYPASS BIT(31)
+#define PCI_DLL_TAP_SEL_MASK 0x1f
+
+struct gemini_gate_data {
+	u8 bit_idx;
+	const char *name;
+	const char *parent_name;
+	unsigned long flags;
+};
+
+/**
+ * struct clk_gemini_pci - Gemini PCI clock
+ * @hw: corresponding clock hardware entry
+ * @map: regmap to access the registers
+ * @rate: current rate
+ */
+struct clk_gemini_pci {
+	struct clk_hw hw;
+	struct regmap *map;
+	unsigned long rate;
+};
+
+/*
+ * FIXME: some clocks are marked as CLK_IGNORE_UNUSED: this is
+ * because their kernel drivers lack proper clock handling so we
+ * need to avoid them being gated off by default. Remove this as
+ * the drivers get fixed to handle clocks properly.
+ *
+ * The DDR controller may never have a driver, but certainly must
+ * not be gated off.
+ */
+static const struct gemini_gate_data gemini_gates[] __initconst = {
+	{ 1, "security-gate", "secdiv", 0 },
+	{ 2, "gmac0-gate", "ahb", 0 },
+	{ 3, "gmac1-gate", "ahb", 0 },
+	{ 4, "sata0-gate", "ahb", 0 },
+	{ 5, "sata1-gate", "ahb", 0 },
+	{ 6, "usb0-gate", "ahb", 0 },
+	{ 7, "usb1-gate", "ahb", 0 },
+	{ 8, "ide-gate", "ahb", 0 },
+	{ 9, "pci-gate", "ahb", 0 },
+	{ 10, "ddr-gate", "ahb", CLK_IGNORE_UNUSED },
+	{ 11, "flash-gate", "ahb", CLK_IGNORE_UNUSED },
+	{ 12, "tvc-gate", "ahb", 0 },
+	{ 13, "boot-gate", "apb", 0 },
+};
+
+#define to_pciclk(_hw) container_of(_hw, struct clk_gemini_pci, hw)
+
+static unsigned long gemini_pci_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct clk_gemini_pci *pciclk = to_pciclk(hw);
+	u32 val;
+	int ret;
+
+	ret = regmap_read(pciclk->map, GEMINI_GLOBAL_MISC_CONTROL, &val);
+	if (ret)
+		return ret;
+	if (val & PCI_CLK_66MHZ)
+		return 66000000;
+	return 33000000;
+}
+
+static long gemini_pci_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *prate)
+{
+	/* We support 33 and 66 MHz */
+	if (rate < 48000000)
+		return 33000000;
+	return 66000000;
+}
+
+static int gemini_pci_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+	if (rate == 33000000)
+		return regmap_update_bits(pciclk->map,
+					  GEMINI_GLOBAL_MISC_CONTROL,
+					  PCI_CLK_66MHZ, 0);
+	if (rate == 66000000)
+		return regmap_update_bits(pciclk->map,
+					  GEMINI_GLOBAL_MISC_CONTROL,
+					  0, PCI_CLK_66MHZ);
+	return -EINVAL;
+}
+
+static int gemini_pci_enable(struct clk_hw *hw)
+{
+	struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+	regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
+			   0, PCI_CLKRUN_EN);
+	regmap_update_bits(pciclk->map,
+			   GEMINI_GLOBAL_MISC_CONTROL,
+			   0, PCI_CLK_OE);
+	return 0;
+}
+
+static void gemini_pci_disable(struct clk_hw *hw)
+{
+	struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+	regmap_update_bits(pciclk->map,
+			   GEMINI_GLOBAL_MISC_CONTROL,
+			   PCI_CLK_OE, 0);
+	regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
+			   PCI_CLKRUN_EN, 0);
+}
+
+static int gemini_pci_is_enabled(struct clk_hw *hw)
+{
+	struct clk_gemini_pci *pciclk = to_pciclk(hw);
+	int ret;
+	unsigned int val;
+
+	ret = regmap_read(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
+	if (ret)
+		return ret;
+
+	return !!(val & PCI_CLKRUN_EN);
+}
+
+static const struct clk_ops gemini_pci_clk_ops = {
+	.recalc_rate = gemini_pci_recalc_rate,
+	.round_rate = gemini_pci_round_rate,
+	.set_rate = gemini_pci_set_rate,
+	.enable = gemini_pci_enable,
+	.disable = gemini_pci_disable,
+	.is_enabled = gemini_pci_is_enabled,
+};
+
+static struct clk *gemini_pci_clk_setup(const char *name,
+					const char *parent_name,
+					struct regmap *map)
+{
+	struct clk_gemini_pci *pciclk;
+	struct clk_init_data init;
+	struct clk *clk;
+
+	pciclk = kzalloc(sizeof(*pciclk), GFP_KERNEL);
+	if (!pciclk)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &gemini_pci_clk_ops;
+	init.flags = 0;
+	init.parent_names = (parent_name ? &parent_name : NULL);
+	init.num_parents = (parent_name ? 1 : 0);
+	pciclk->map = map;
+	pciclk->hw.init = &init;
+
+	clk = clk_register(NULL, &pciclk->hw);
+	if (IS_ERR(clk))
+		kfree(pciclk);
+
+	return clk;
+}
+
+static void __init gemini_cc_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct regmap *map;
+	struct clk *clk;
+	unsigned int mult, div;
+	unsigned long freq;
+	u32 val;
+	int ret;
+	int i;
+
+	/* Remap the system controller for the exclusive register */
+	base = of_iomap(np, 0);
+	if (!base) {
+		pr_err("no memory base\n");
+		return;
+	}
+	map = syscon_node_to_regmap(np);
+	if (IS_ERR(map)) {
+		pr_err("no syscon regmap\n");
+		return;
+	}
+
+	/* RTC clock 32768 Hz */
+	clk = clk_register_fixed_rate(NULL, "rtc", NULL, CLK_IGNORE_UNUSED,
+				      32768);
+	gemini_clks[GEMINI_CLK_RTC] = clk;
+
+	ret = regmap_read(map, GEMINI_GLOBAL_STATUS, &val);
+	if (ret) {
+		pr_err("failed to read global status register\n");
+		return;
+	}
+
+	/*
+	 * XTAL is the crystal oscillator, 60 or 30 MHz selected from
+	 * strap pin E6
+	 */
+	if (val & PLL_OSC_SEL)
+		freq = 30000000;
+	else
+		freq = 60000000;
+	clk = clk_register_fixed_rate(NULL, "xtal", NULL, CLK_IGNORE_UNUSED,
+				      freq);
+	pr_info("main crystal @%lu MHz\n", (freq/1000000));
+
+	/* VCO clock derived from the crystal */
+	mult = 13 + ((val >> AHBSPEED_SHIFT) & AHBSPEED_MASK);
+	div = 2;
+	/* If we run on 30 Mhz crystal we have to multiply with two */
+	if (val & PLL_OSC_SEL)
+		mult *= 2;
+	clk = clk_register_fixed_factor(NULL, "vco", "xtal", CLK_IGNORE_UNUSED,
+					mult, div);
+
+	/* The AHB clock is always 1/3 of the VCO */
+	clk = clk_register_fixed_factor(NULL, "ahb", "vco",
+					CLK_IGNORE_UNUSED, 1, 3);
+	gemini_clks[GEMINI_CLK_AHB] = clk;
+
+	/* The APB clock is always 1/6 of the AHB */
+	clk = clk_register_fixed_factor(NULL, "apb", "ahb",
+					CLK_IGNORE_UNUSED, 1, 6);
+	gemini_clks[GEMINI_CLK_APB] = clk;
+
+	/* CPU clock derived as a fixed ratio from the AHB clock */
+	switch ((val >> CPU_AHB_RATIO_SHIFT) & CPU_AHB_RATIO_MASK) {
+	case 0x0:
+		/* 1x */
+		mult = 1;
+		div = 1;
+		break;
+	case 0x1:
+		/* 1.5x */
+		mult = 3;
+		div = 2;
+		break;
+	case 0x2:
+		/* 1.85x */
+		mult = 24;
+		div = 13;
+		break;
+	case 0x3:
+		/* 2x */
+		mult = 2;
+		div = 1;
+		break;
+	}
+	clk = clk_register_fixed_factor(NULL, "cpu", "ahb",
+					CLK_IGNORE_UNUSED, mult, div);
+	gemini_clks[GEMINI_CLK_CPU] = clk;
+
+	/* Security clock is 1:1 or 0.75 of APB */
+	ret = regmap_read(map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
+	if (ret) {
+		pr_err("failed to read global clock control register\n");
+		return;
+	}
+	if (val & SECURITY_CLK_SEL) {
+		mult = 1;
+		div = 1;
+	} else {
+		mult = 3;
+		div = 4;
+	}
+	clk = clk_register_fixed_factor(NULL, "secdiv", "ahb",
+					0, mult, div);
+
+	/*
+	 * These are the leaf gates, at boot no clocks are gated.
+	 */
+	for (i = 0; i < ARRAY_SIZE(gemini_gates); i++) {
+		const struct gemini_gate_data *gd;
+
+		gd = &gemini_gates[i];
+		gemini_clks[GEMINI_CLK_GATES + i] =
+			clk_register_gate(NULL, gd->name,
+					  gd->parent_name,
+					  gd->flags,
+					  base + GEMINI_GLOBAL_CLOCK_CONTROL,
+					  gd->bit_idx,
+					  CLK_GATE_SET_TO_DISABLE,
+					  &gemini_clk_lock);
+	}
+
+	/*
+	 * The TV Interface Controller has a 5-bit half divider register.
+	 * This clock is supposed to be 27MHz as this is an exact multiple
+	 * of PAL and NTSC frequencies. The register is undocumented :(
+	 * FIXME: figure out the parent and how the divider works.
+	 */
+	mult = 1;
+	div = ((val >> TVC_HALFDIV_SHIFT) & TVC_HALFDIV_MASK);
+	pr_debug("TVC half divider value = %d\n", div);
+	div += 1;
+	clk = clk_register_fixed_rate(NULL, "tvcdiv", "xtal", 0, 27000000);
+	gemini_clks[GEMINI_CLK_TVC] = clk;
+
+	/* FIXME: very unclear what the parent is */
+	clk = gemini_pci_clk_setup("PCI", "xtal", map);
+	gemini_clks[GEMINI_CLK_PCI] = clk;
+
+	/* FIXME: very unclear what the parent is */
+	clk = clk_register_fixed_rate(NULL, "uart", "xtal", CLK_IGNORE_UNUSED,
+				      48000000);
+	gemini_clks[GEMINI_CLK_UART] = clk;
+
+	/* Register the clocks to be accessed by the device tree */
+	gemini_clk_data.clks = gemini_clks;
+        gemini_clk_data.clk_num = ARRAY_SIZE(gemini_clks);
+	of_clk_add_provider(np, of_clk_src_onecell_get, &gemini_clk_data);
+}
+CLK_OF_DECLARE_DRIVER(gemini_cc, "cortina,gemini-clock-controller",
+		      gemini_cc_init);
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:26:49 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 May 2017 22:26:49 +0200
Subject: [OpenWrt-Devel] [PATCH 1/4] ata: Add DT bindings for Faraday
	Technology FTIDE010
In-Reply-To: <1678111.DmiVNKW3dQ@amdc3058>
References: <CGME20170506121118epcas2p1b2a2d1a8005a37582a73c0e7be4b1a1b@epcas2p1.samsung.com>
 <20170506121053.11554-1-linus.walleij@linaro.org>
 <1678111.DmiVNKW3dQ@amdc3058>
Message-ID: <CACRpkdbmOsrxKX8=a7bvcF+c=Q2tfwYQVt0=cz+_jhDyadwa2A@mail.gmail.com>

On Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie at samsung.com> wrote:

> Also for all current drivers we just put timing values (or a logic
> to calculate them from the standard ATA timings) into the driver
> itself and not device tree (as they are based on values are dictated
> by ATA standard and should not change for a given controller type).

I had it like that at first (and I can of course switch it back). But I
came to think this is better.

I was looking at these values from the point that it depends a bit
on the silicon where it is synthesized. So the vendor tree has
things like this:

#ifndef SL2312_FPGA_IDE
static unsigned char PIO_TIMING[5] = { 0xaa, 0xa3, 0xa1, 0x33, 0x31 };
static unsigned char TIMING_MDMA_50M[3] = { 0x66, 0x22, 0x21 };
static unsigned char TIMING_MDMA_66M[3] = { 0x88, 0x32, 0x31 };
static unsigned char TIMING_UDMA_50M[6] = { 0x33, 0x31, 0x21, 0x21,
0x11, 0x91 };
static unsigned char TIMING_UDMA_66M[7] = { 0x44, 0x42, 0x31, 0x21,
0x11, 0x91,  0x91};
#else
static unsigned char PIO_TIMING[5] = { 0x88, 0x82, 0x81, 0x32, 0x21 };
static unsigned char TIMING_MDMA_50M[3] = { 0x33, 0x11, 0x11 };
static unsigned char TIMING_MDMA_66M[3] = { 0x33, 0x11, 0x11 };
static unsigned char TIMING_UDMA_50M[6] = { 0x22, 0x11, 0x11, 0x11 };
static unsigned char TIMING_UDMA_66M[7] = { 0x22, 0x11, 0x11, 0x11 };
#endif

(From D-Link DIR-685 source release from Storlink/Cortina board support.)

So depending on whether they use an FPGA or an ASIC the values are
different, no matter what frequency (50 or 66 MHz) is used. So it is not
derived from frequency.

So I think it makes most sense to have it in the device tree as we don't
know what designs are out there.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 16:33:15 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 May 2017 22:33:15 +0200
Subject: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini
	SATA bridge
In-Reply-To: <3791456.ZibJefW5cI@amdc3058>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
 <CGME20170506121119epcas5p437ea69e802ba94bd7df83d0bbac1b0bc@epcas5p4.samsung.com>
 <20170506121053.11554-2-linus.walleij@linaro.org>
 <3791456.ZibJefW5cI@amdc3058>
Message-ID: <CACRpkdYz9Oka0SGJDTr=y4EN-VfggbuKY2s5X43oXg1dgjh1nw@mail.gmail.com>

On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie at samsung.com> 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May  8 17:16:48 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 8 May 2017 23:16:48 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2 v2] clk: Add Gemini SoC clock
	controller
In-Reply-To: <20170508201221.31684-1-linus.walleij@linaro.org>
References: <20170508201221.31684-1-linus.walleij@linaro.org>
Message-ID: <CAKR_QV+7rSv5j9rD_AGca5n3wjABL9QLadqCE9ipse9-W-13QA@mail.gmail.com>

Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:12, Linus Walleij <linus.walleij at linaro.org> wrote:

> The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock
> controller that derive all clocks from a single crystal, using some
> documented and some undocumented PLLs, half dividers, counters and
> gates. This is a best attempt to construct a clock driver for the
> clocks so at least we can gate off unused hardware and driver the
> PCI bus clock.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v1->v2:
> - Move the clock controller to be part of the syscon node. No
>   need for a separate child node for this.
> ---
>  drivers/clk/Kconfig      |   7 +
>  drivers/clk/Makefile     |   1 +
>  drivers/clk/clk-gemini.c | 358 ++++++++++++++++++++++++++++++
> +++++++++++++++++
>  3 files changed, 366 insertions(+)
>  create mode 100644 drivers/clk/clk-gemini.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9356ab4b7d76..9e7619f9bf0e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -118,6 +118,13 @@ config COMMON_CLK_CS2000_CP
>         help
>           If you say yes here you get support for the CS2000 clock
> multiplier.
>
> +config COMMON_CLK_GEMINI
> +       bool "Clock driver for Cortina Systems Gemini SoC"
> +       select MFD_SYSCON
> +       ---help---
> +         This driver supports the SoC clocks on the Cortina Systems Gemini
> +         platform, also known as SL3516 or CS3516.
> +
>  config COMMON_CLK_S2MPS11
>         tristate "Clock driver for S2MPS1X/S5M8767 MFD"
>         depends on MFD_SEC_CORE || COMPILE_TEST
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 92c12b86c2e8..e100d911a554 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_COMMON_CLK_CDCE925)      += clk-cdce925.o
>  obj-$(CONFIG_ARCH_CLPS711X)            += clk-clps711x.o
>  obj-$(CONFIG_COMMON_CLK_CS2000_CP)     += clk-cs2000-cp.o
>  obj-$(CONFIG_ARCH_EFM32)               += clk-efm32gg.o
> +obj-$(CONFIG_COMMON_CLK_GEMINI)                += clk-gemini.o
>  obj-$(CONFIG_ARCH_HIGHBANK)            += clk-highbank.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686)      += clk-max77686.o
>  obj-$(CONFIG_ARCH_MB86S7X)             += clk-mb86s7x.o
> diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
> new file mode 100644
> index 000000000000..340c2570f24e
> --- /dev/null
> +++ b/drivers/clk/clk-gemini.c
> @@ -0,0 +1,358 @@
> +/*
> + * Cortina Gemini Clock Controller driver
> + * Copyright (c) 2017 Linus Walleij <linus.walleij at linaro.org>
> + */
> +
> +#define pr_fmt(fmt) "clk-gemini: " fmt
> +
> +#include <linux/clkdev.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <dt-bindings/clock/cortina,gemini-clock.h>
> +
> +/* Globally visible clocks */
> +static DEFINE_SPINLOCK(gemini_clk_lock);
> +static struct clk *gemini_clks[GEMINI_NUM_CLKS];
> +static struct clk_onecell_data gemini_clk_data;
> +
> +#define GEMINI_GLOBAL_STATUS 0x04
> +#define PLL_OSC_SEL BIT(30)
> +#define AHBSPEED_SHIFT (15)
> +#define AHBSPEED_MASK 0x07
> +#define CPU_AHB_RATIO_SHIFT (18)
> +#define CPU_AHB_RATIO_MASK 0x03
> +
> +#define GEMINI_GLOBAL_PLL_CONTROL 0x08
> +
> +#define GEMINI_GLOBAL_MISC_CONTROL 0x30
> +#define PCI_CLK_66MHZ BIT(18)
> +#define PCI_CLK_OE BIT(17)
> +
> +#define GEMINI_GLOBAL_CLOCK_CONTROL 0x34
> +#define PCI_CLKRUN_EN BIT(16)
> +#define TVC_HALFDIV_SHIFT (24)
> +#define TVC_HALFDIV_MASK 0x1f
> +#define SECURITY_CLK_SEL BIT(29)
> +
> +#define GEMINI_GLOBAL_PCI_DLL_CONTROL 0x44
> +#define PCI_DLL_BYPASS BIT(31)
> +#define PCI_DLL_TAP_SEL_MASK 0x1f
> +
> +struct gemini_gate_data {
> +       u8 bit_idx;
> +       const char *name;
> +       const char *parent_name;
> +       unsigned long flags;
> +};
> +
> +/**
> + * struct clk_gemini_pci - Gemini PCI clock
> + * @hw: corresponding clock hardware entry
> + * @map: regmap to access the registers
> + * @rate: current rate
> + */
> +struct clk_gemini_pci {
> +       struct clk_hw hw;
> +       struct regmap *map;
> +       unsigned long rate;
> +};
> +
> +/*
> + * FIXME: some clocks are marked as CLK_IGNORE_UNUSED: this is
> + * because their kernel drivers lack proper clock handling so we
> + * need to avoid them being gated off by default. Remove this as
> + * the drivers get fixed to handle clocks properly.
> + *
> + * The DDR controller may never have a driver, but certainly must
> + * not be gated off.
> + */
> +static const struct gemini_gate_data gemini_gates[] __initconst = {
> +       { 1, "security-gate", "secdiv", 0 },
> +       { 2, "gmac0-gate", "ahb", 0 },
> +       { 3, "gmac1-gate", "ahb", 0 },
> +       { 4, "sata0-gate", "ahb", 0 },
> +       { 5, "sata1-gate", "ahb", 0 },
> +       { 6, "usb0-gate", "ahb", 0 },
> +       { 7, "usb1-gate", "ahb", 0 },
> +       { 8, "ide-gate", "ahb", 0 },
> +       { 9, "pci-gate", "ahb", 0 },
> +       { 10, "ddr-gate", "ahb", CLK_IGNORE_UNUSED },
> +       { 11, "flash-gate", "ahb", CLK_IGNORE_UNUSED },
> +       { 12, "tvc-gate", "ahb", 0 },
> +       { 13, "boot-gate", "apb", 0 },
> +};
> +
> +#define to_pciclk(_hw) container_of(_hw, struct clk_gemini_pci, hw)
> +
> +static unsigned long gemini_pci_recalc_rate(struct clk_hw *hw,
> +                                           unsigned long parent_rate)
> +{
> +       struct clk_gemini_pci *pciclk = to_pciclk(hw);
> +       u32 val;
> +       int ret;
> +
> +       ret = regmap_read(pciclk->map, GEMINI_GLOBAL_MISC_CONTROL, &val);
> +       if (ret)
> +               return ret;
> +       if (val & PCI_CLK_66MHZ)
> +               return 66000000;
> +       return 33000000;
> +}
> +
> +static long gemini_pci_round_rate(struct clk_hw *hw, unsigned long rate,
> +                                 unsigned long *prate)
> +{
> +       /* We support 33 and 66 MHz */
> +       if (rate < 48000000)
> +               return 33000000;
> +       return 66000000;
> +}
> +
> +static int gemini_pci_set_rate(struct clk_hw *hw, unsigned long rate,
> +                              unsigned long parent_rate)
> +{
> +       struct clk_gemini_pci *pciclk = to_pciclk(hw);
> +
> +       if (rate == 33000000)
> +               return regmap_update_bits(pciclk->map,
> +                                         GEMINI_GLOBAL_MISC_CONTROL,
> +                                         PCI_CLK_66MHZ, 0);
> +       if (rate == 66000000)
> +               return regmap_update_bits(pciclk->map,
> +                                         GEMINI_GLOBAL_MISC_CONTROL,
> +                                         0, PCI_CLK_66MHZ);
> +       return -EINVAL;
> +}
> +
> +static int gemini_pci_enable(struct clk_hw *hw)
> +{
> +       struct clk_gemini_pci *pciclk = to_pciclk(hw);
> +
> +       regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
> +                          0, PCI_CLKRUN_EN);
> +       regmap_update_bits(pciclk->map,
> +                          GEMINI_GLOBAL_MISC_CONTROL,
> +                          0, PCI_CLK_OE);
> +       return 0;
> +}
> +
> +static void gemini_pci_disable(struct clk_hw *hw)
> +{
> +       struct clk_gemini_pci *pciclk = to_pciclk(hw);
> +
> +       regmap_update_bits(pciclk->map,
> +                          GEMINI_GLOBAL_MISC_CONTROL,
> +                          PCI_CLK_OE, 0);
> +       regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
> +                          PCI_CLKRUN_EN, 0);
> +}
> +
> +static int gemini_pci_is_enabled(struct clk_hw *hw)
> +{
> +       struct clk_gemini_pci *pciclk = to_pciclk(hw);
> +       int ret;
> +       unsigned int val;
> +
> +       ret = regmap_read(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
> +       if (ret)
> +               return ret;
> +
> +       return !!(val & PCI_CLKRUN_EN);
> +}
> +
> +static const struct clk_ops gemini_pci_clk_ops = {
> +       .recalc_rate = gemini_pci_recalc_rate,
> +       .round_rate = gemini_pci_round_rate,
> +       .set_rate = gemini_pci_set_rate,
> +       .enable = gemini_pci_enable,
> +       .disable = gemini_pci_disable,
> +       .is_enabled = gemini_pci_is_enabled,
> +};
> +
> +static struct clk *gemini_pci_clk_setup(const char *name,
> +                                       const char *parent_name,
> +                                       struct regmap *map)
> +{
> +       struct clk_gemini_pci *pciclk;
> +       struct clk_init_data init;
> +       struct clk *clk;
> +
> +       pciclk = kzalloc(sizeof(*pciclk), GFP_KERNEL);
> +       if (!pciclk)
> +               return ERR_PTR(-ENOMEM);
> +
> +       init.name = name;
> +       init.ops = &gemini_pci_clk_ops;
> +       init.flags = 0;
> +       init.parent_names = (parent_name ? &parent_name : NULL);
> +       init.num_parents = (parent_name ? 1 : 0);
> +       pciclk->map = map;
> +       pciclk->hw.init = &init;
> +
> +       clk = clk_register(NULL, &pciclk->hw);
> +       if (IS_ERR(clk))
> +               kfree(pciclk);
> +
> +       return clk;
> +}
> +
> +static void __init gemini_cc_init(struct device_node *np)
> +{
> +       void __iomem *base;
> +       struct regmap *map;
> +       struct clk *clk;
> +       unsigned int mult, div;
> +       unsigned long freq;
> +       u32 val;
> +       int ret;
> +       int i;
> +
> +       /* Remap the system controller for the exclusive register */
> +       base = of_iomap(np, 0);
> +       if (!base) {
> +               pr_err("no memory base\n");
> +               return;
> +       }
> +       map = syscon_node_to_regmap(np);
> +       if (IS_ERR(map)) {
> +               pr_err("no syscon regmap\n");
> +               return;
> +       }
> +
> +       /* RTC clock 32768 Hz */
> +       clk = clk_register_fixed_rate(NULL, "rtc", NULL, CLK_IGNORE_UNUSED,
> +                                     32768);
> +       gemini_clks[GEMINI_CLK_RTC] = clk;
> +
> +       ret = regmap_read(map, GEMINI_GLOBAL_STATUS, &val);
> +       if (ret) {
> +               pr_err("failed to read global status register\n");
> +               return;
> +       }
> +
> +       /*
> +        * XTAL is the crystal oscillator, 60 or 30 MHz selected from
> +        * strap pin E6
> +        */
> +       if (val & PLL_OSC_SEL)
> +               freq = 30000000;
> +       else
> +               freq = 60000000;
> +       clk = clk_register_fixed_rate(NULL, "xtal", NULL,
> CLK_IGNORE_UNUSED,
> +                                     freq);
> +       pr_info("main crystal @%lu MHz\n", (freq/1000000));
> +
> +       /* VCO clock derived from the crystal */
> +       mult = 13 + ((val >> AHBSPEED_SHIFT) & AHBSPEED_MASK);
> +       div = 2;
> +       /* If we run on 30 Mhz crystal we have to multiply with two */
> +       if (val & PLL_OSC_SEL)
> +               mult *= 2;
> +       clk = clk_register_fixed_factor(NULL, "vco", "xtal",
> CLK_IGNORE_UNUSED,
> +                                       mult, div);
> +
> +       /* The AHB clock is always 1/3 of the VCO */
> +       clk = clk_register_fixed_factor(NULL, "ahb", "vco",
> +                                       CLK_IGNORE_UNUSED, 1, 3);
> +       gemini_clks[GEMINI_CLK_AHB] = clk;
> +
> +       /* The APB clock is always 1/6 of the AHB */
> +       clk = clk_register_fixed_factor(NULL, "apb", "ahb",
> +                                       CLK_IGNORE_UNUSED, 1, 6);
> +       gemini_clks[GEMINI_CLK_APB] = clk;
> +
> +       /* CPU clock derived as a fixed ratio from the AHB clock */
> +       switch ((val >> CPU_AHB_RATIO_SHIFT) & CPU_AHB_RATIO_MASK) {
> +       case 0x0:
> +               /* 1x */
> +               mult = 1;
> +               div = 1;
> +               break;
> +       case 0x1:
> +               /* 1.5x */
> +               mult = 3;
> +               div = 2;
> +               break;
> +       case 0x2:
> +               /* 1.85x */
> +               mult = 24;
> +               div = 13;
> +               break;
> +       case 0x3:
> +               /* 2x */
> +               mult = 2;
> +               div = 1;
> +               break;
> +       }
> +       clk = clk_register_fixed_factor(NULL, "cpu", "ahb",
> +                                       CLK_IGNORE_UNUSED, mult, div);
> +       gemini_clks[GEMINI_CLK_CPU] = clk;
> +
> +       /* Security clock is 1:1 or 0.75 of APB */
> +       ret = regmap_read(map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
> +       if (ret) {
> +               pr_err("failed to read global clock control register\n");
> +               return;
> +       }
> +       if (val & SECURITY_CLK_SEL) {
> +               mult = 1;
> +               div = 1;
> +       } else {
> +               mult = 3;
> +               div = 4;
> +       }
> +       clk = clk_register_fixed_factor(NULL, "secdiv", "ahb",
> +                                       0, mult, div);
> +
> +       /*
> +        * These are the leaf gates, at boot no clocks are gated.
> +        */
> +       for (i = 0; i < ARRAY_SIZE(gemini_gates); i++) {
> +               const struct gemini_gate_data *gd;
> +
> +               gd = &gemini_gates[i];
> +               gemini_clks[GEMINI_CLK_GATES + i] =
> +                       clk_register_gate(NULL, gd->name,
> +                                         gd->parent_name,
> +                                         gd->flags,
> +                                         base +
> GEMINI_GLOBAL_CLOCK_CONTROL,
> +                                         gd->bit_idx,
> +                                         CLK_GATE_SET_TO_DISABLE,
> +                                         &gemini_clk_lock);
> +       }
> +
> +       /*
> +        * The TV Interface Controller has a 5-bit half divider register.
> +        * This clock is supposed to be 27MHz as this is an exact multiple
> +        * of PAL and NTSC frequencies. The register is undocumented :(
> +        * FIXME: figure out the parent and how the divider works.
> +        */
> +       mult = 1;
> +       div = ((val >> TVC_HALFDIV_SHIFT) & TVC_HALFDIV_MASK);
> +       pr_debug("TVC half divider value = %d\n", div);
> +       div += 1;
> +       clk = clk_register_fixed_rate(NULL, "tvcdiv", "xtal", 0, 27000000);
> +       gemini_clks[GEMINI_CLK_TVC] = clk;
> +
> +       /* FIXME: very unclear what the parent is */
> +       clk = gemini_pci_clk_setup("PCI", "xtal", map);
> +       gemini_clks[GEMINI_CLK_PCI] = clk;
> +
> +       /* FIXME: very unclear what the parent is */
> +       clk = clk_register_fixed_rate(NULL, "uart", "xtal",
> CLK_IGNORE_UNUSED,
> +                                     48000000);
> +       gemini_clks[GEMINI_CLK_UART] = clk;
> +
> +       /* Register the clocks to be accessed by the device tree */
> +       gemini_clk_data.clks = gemini_clks;
> +        gemini_clk_data.clk_num = ARRAY_SIZE(gemini_clks);
> +       of_clk_add_provider(np, of_clk_src_onecell_get, &gemini_clk_data);
> +}
> +CLK_OF_DECLARE_DRIVER(gemini_cc, "cortina,gemini-clock-controller",
> +                     gemini_cc_init);
> --
> 2.9.3
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170508/de5e0464/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May  8 17:16:57 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 8 May 2017 23:16:57 +0200
Subject: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini
 SATA bridge
In-Reply-To: <CACRpkdYz9Oka0SGJDTr=y4EN-VfggbuKY2s5X43oXg1dgjh1nw@mail.gmail.com>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
 <CGME20170506121119epcas5p437ea69e802ba94bd7df83d0bbac1b0bc@epcas5p4.samsung.com>
 <20170506121053.11554-2-linus.walleij@linaro.org>
 <3791456.ZibJefW5cI@amdc3058>
 <CACRpkdYz9Oka0SGJDTr=y4EN-VfggbuKY2s5X43oXg1dgjh1nw@mail.gmail.com>
Message-ID: <CAKR_QVJTbLMzqsUTEZJOquZ9T5aQ1_=73WAoRWrm+QK9wFhngA@mail.gmail.com>

Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:33, Linus Walleij <linus.walleij at linaro.org> wrote:

> On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie at samsung.com> 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 at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170508/f17e5b18/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May  8 17:17:07 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 8 May 2017 23:17:07 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini
 Clock Controller
In-Reply-To: <20170508201159.31634-1-linus.walleij@linaro.org>
References: <20170508201159.31634-1-linus.walleij@linaro.org>
Message-ID: <CAKR_QVKKocajdnuyivWCuaLQssxkcrfdiMqcFxeWeesmFfHhRw@mail.gmail.com>

Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:11, Linus Walleij <linus.walleij at linaro.org> wrote:

> This adds device tree bindings and a header for the Gemini SoC
> Clock Controller.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v1->v2:
> - Move the clock controller to be directly in the parent syscon
>   node.
> ---
>  .../clock/cortina,gemini-clock-controller.txt      | 22 ++++++++++++++++
>  include/dt-bindings/clock/cortina,gemini-clock.h   | 29
> ++++++++++++++++++++++
>  2 files changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/
> bindings/clock/cortina,gemini-clock-controller.txt
>  create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> b/Documentation/devicetree/bindings/clock/cortina,gemini-
> clock-controller.txt
> new file mode 100644
> index 000000000000..ae0046bccba0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/cortina,gemini-
> clock-controller.txt
> @@ -0,0 +1,22 @@
> +Clock bindings for the Cortina Systems Gemini SoC Clock Controller
> +
> +Required properties :
> +- compatible : shall contain the following:
> +  "cortina,gemini-clock-controller"
> +- #clock-cells should be <1>
> +
> +The Gemini clock controller needs to be identical to the system controller
> +node.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> +syscon: syscon at 40000000 {
> +       compatible = "cortina,gemini-syscon", "cortina,gemini-clock-
> controller",
> +                    "syscon", "simple-mfd";
> +       reg = <0x40000000 0x1000>;
> +       #clock-cells = <1>;
> +};
> diff --git a/include/dt-bindings/clock/cortina,gemini-clock.h
> b/include/dt-bindings/clock/cortina,gemini-clock.h
> new file mode 100644
> index 000000000000..acf5cd550b0c
> --- /dev/null
> +++ b/include/dt-bindings/clock/cortina,gemini-clock.h
> @@ -0,0 +1,29 @@
> +#ifndef DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
> +#define DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
> +
> +/* RTC, AHB, APB, CPU, PCI, TVC, UART clocks and 13 gates */
> +#define GEMINI_NUM_CLKS 20
> +
> +#define GEMINI_CLK_RTC 0
> +#define GEMINI_CLK_AHB 1
> +#define GEMINI_CLK_APB 2
> +#define GEMINI_CLK_CPU 3
> +#define GEMINI_CLK_PCI 4
> +#define GEMINI_CLK_TVC 5
> +#define GEMINI_CLK_UART 6
> +#define GEMINI_CLK_GATES 7
> +#define GEMINI_CLK_GATE_SECURITY 7
> +#define GEMINI_CLK_GATE_GMAC0 8
> +#define GEMINI_CLK_GATE_GMAC1 9
> +#define GEMINI_CLK_GATE_SATA0 10
> +#define GEMINI_CLK_GATE_SATA1 11
> +#define GEMINI_CLK_GATE_USB0 12
> +#define GEMINI_CLK_GATE_USB1 13
> +#define GEMINI_CLK_GATE_IDE 14
> +#define GEMINI_CLK_GATE_PCI 15
> +#define GEMINI_CLK_GATE_DDR 16
> +#define GEMINI_CLK_GATE_FLASH 17
> +#define GEMINI_CLK_GATE_TVC 18
> +#define GEMINI_CLK_GATE_BOOT 19
> +
> +#endif /* DT_BINDINGS_CORTINA_GEMINI_CLOCK_H */
> --
> 2.9.3
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170508/a6d84107/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May  8 17:17:56 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 8 May 2017 23:17:56 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] reset: Add DT bindings for the
 Gemini reset controller
In-Reply-To: <20170508200720.26145-1-linus.walleij@linaro.org>
References: <20170508200720.26145-1-linus.walleij@linaro.org>
Message-ID: <CAKR_QVKmgBObvQ-=knqQ0aNbWPmY0uwG_yRr_6_=5Tu2BWWDVw@mail.gmail.com>

Is it ever going to be added so this endless spam can end?


On 8 May 2017 at 22:07, Linus Walleij <linus.walleij at linaro.org> wrote:

> This is a simple reset controller in a single 32bit
> register.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v1->v2:
> - Move the reset controller node to be the same as the syscon
>   node, no need for a specific child node.
> - Add an include file with nice #defines.
> ---
>  .../bindings/reset/cortina,gemini-reset.txt        | 58
> ++++++++++++++++++++++
>  include/dt-bindings/reset/cortina,gemini-reset.h   | 36 ++++++++++++++
>  2 files changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/
> bindings/reset/cortina,gemini-reset.txt
>  create mode 100644 include/dt-bindings/reset/cortina,gemini-reset.h
>
> diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> new file mode 100644
> index 000000000000..aa3d1b2a9677
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> @@ -0,0 +1,58 @@
> +Cortina Gemini Reset Controller
> +
> +This reset controller is found in Cortina Systems CS3516 and
> +the predecessor StorLink SL3516.
> +
> +Required properties:
> +- compatible: "cortina,gemini-reset"
> +- #reset-cells: Must be 1
> +
> +The Gemini reset controller must be identical to the system controller
> node.
> +Apart from this it follows the standard reset controller bindings.
> +
> +Valid reset line values:
> +
> +0:  DRAM controller
> +1:  Flash controller
> +2:  IDE controller
> +3:  RAID controller
> +4:  Security module
> +5:  GMAC0 (ethernet)
> +6:  GMAC1 (ethernet)
> +7:  PCI host bridge
> +8:  USB0 USB host controller
> +9:  USB1 USB host controller
> +10: General DMA controller
> +11: APB bridge
> +12: LPC (Low Pin Count) controller
> +13: LCD module
> +14: Interrupt controller 0
> +15: Interrupt controller 1
> +16: RTC module
> +17: Timer module
> +18: UART controller
> +19: SSP controller
> +20: GPIO0 GPIO controller
> +21: GPIO1 GPIO controller
> +22: GPIO2 GPIO controller
> +23: Watchdog timer
> +24: External device reset
> +25: CIR module (infrared)
> +26: SATA0 SATA bridge
> +27: SATA1 SATA bridge
> +28: TVE TV Encoder module
> +29: Reserved
> +30: CPU1 reset
> +31: Global soft reset
> +
> +These also have shorthand defines in the include file:
> +<dt-bindings/reset/cortina,gemini-reset.h>
> +
> +Example:
> +
> +syscon: syscon at 40000000 {
> +       compatible = "cortina,gemini-syscon", "cortina,gemini-reset",
> +                    "syscon", "simple-mfd";
> +       reg = <0x40000000 0x1000>;
> +       #reset-cells = <1>;
> +};
> diff --git a/include/dt-bindings/reset/cortina,gemini-reset.h
> b/include/dt-bindings/reset/cortina,gemini-reset.h
> new file mode 100644
> index 000000000000..aebecae43721
> --- /dev/null
> +++ b/include/dt-bindings/reset/cortina,gemini-reset.h
> @@ -0,0 +1,36 @@
> +#ifndef _DT_BINDINGS_RESET_CORTINA_GEMINI_H
> +#define _DT_BINDINGS_RESET_CORTINA_GEMINI_H
> +
> +#define GEMINI_RESET_DRAM      0
> +#define GEMINI_RESET_FLASH     1
> +#define GEMINI_RESET_IDE       2
> +#define GEMINI_RESET_RAID      3
> +#define GEMINI_RESET_SECURITY  4
> +#define GEMINI_RESET_GMAC0     5
> +#define GEMINI_RESET_GMAC1     6
> +#define GEMINI_RESET_PCI       7
> +#define GEMINI_RESET_USB0      8
> +#define GEMINI_RESET_USB1      9
> +#define GEMINI_RESET_DMAC      10
> +#define GEMINI_RESET_APB       11
> +#define GEMINI_RESET_LPC       12
> +#define GEMINI_RESET_LCD       13
> +#define GEMINI_RESET_INTCON0   14
> +#define GEMINI_RESET_INTCON1   15
> +#define GEMINI_RESET_RTC       16
> +#define GEMINI_RESET_TIMER     17
> +#define GEMINI_RESET_UART      18
> +#define GEMINI_RESET_SSP       19
> +#define GEMINI_RESET_GPIO0     20
> +#define GEMINI_RESET_GPIO1     21
> +#define GEMINI_RESET_GPIO2     22
> +#define GEMINI_RESET_WDOG      23
> +#define GEMINI_RESET_EXTERN    24
> +#define GEMINI_RESET_CIR       25
> +#define GEMINI_RESET_SATA0     26
> +#define GEMINI_RESET_SATA1     27
> +#define GEMINI_RESET_TVE       28
> +#define GEMINI_RESET_CPU1      30
> +#define GEMINI_RESET_GLOBAL    31
> +
> +#endif
> --
> 2.9.3
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170508/ee67d2ab/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May  8 17:41:38 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 May 2017 23:41:38 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini
	Clock Controller
In-Reply-To: <CAL_JsqLAMObobPrBDdA8bjaKTX4rEo2=_qd86ibbA2kQP6AvBg@mail.gmail.com>
References: <20170508201159.31634-1-linus.walleij@linaro.org>
 <CAL_JsqLAMObobPrBDdA8bjaKTX4rEo2=_qd86ibbA2kQP6AvBg@mail.gmail.com>
Message-ID: <CACRpkdY+EzbbTy6PzN5-YhCnSxPoKej2z=t-7eC3CPqDa6Q4_w@mail.gmail.com>

On Mon, May 8, 2017 at 11:24 PM, Rob Herring <robh+dt at kernel.org> wrote:

>> +Example:
>> +
>> +syscon: syscon at 40000000 {
>> +       compatible = "cortina,gemini-syscon", "cortina,gemini-clock-controller",
>> +                    "syscon", "simple-mfd";
>
> There are no child nodes, so you don't need simple-mfd.

The example is taken from an actual device tree (look below),
where there are child nodes, I can trim it down.

>> +       reg = <0x40000000 0x1000>;
>
> Looks like you have 2 nodes pointing to the same address with your
> reset binding? You shouldn't have overlapping resources. It's allowed
> for historical reasons but breaks resource creation in Linux.

No... they are all in the same node, just sharing the same
resource by way of regmap (syscon).

In the end, as I think you requested, when you said:

>> +     clock-controller {
>> +             compatible = "cortina,gemini-clock-controller";
>> +             #clock-cells = <1>;
(...)
> There's not really much reason to have a child node here. The parent can
> be the clock provider.
(...)
> Same comment as clocks. The parent can be the provider.

So as you say, no specific child is needed and syscon provides
clocks and resets:

                syscon: syscon at 40000000 {
                        compatible = "cortina,gemini-syscon",
                                     "cortina,gemini-clock-controller",
                                     "cortina,gemini-reset",
                                     "syscon", "simple-mfd";
                        reg = <0x40000000 0x1000>;
                        #clock-cells = <1>;
                        #reset-cells = <1>;

                        syscon-reboot {
                                compatible = "syscon-reboot";
                                regmap = <&syscon>;
                                /* GLOBAL_RESET register */
                                offset = <0x0c>;
                                /* RESET_GLOBAL | RESET_CPU1 */
                                mask = <0xC0000000>;
                        };
                };

Before your (as I percieved it) requested changes to avoid
surplus children in the syscon it looked like this:

                syscon: syscon at 40000000 {
                        compatible = "cortina,gemini-syscon",
"syscon", "simple-mfd";
                        reg = <0x40000000 0x1000>;

                        syscon-reboot {
                                compatible = "syscon-reboot";
                                regmap = <&syscon>;
                                /* GLOBAL_RESET register */
                                offset = <0x0c>;
                                /* RESET_GLOBAL | RESET_CPU1 */
                                mask = <0xC0000000>;
                        };

                        rcon: reset-controller {
                                compatible = "cortina,gemini-reset";
                                #reset-cells = <1>;
                        };

                        gcc: clock-controller {
                                compatible = "cortina,gemini-clock-controller";
                                #clock-cells = <1>;
                        };
                };


Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From f.fainelli at gmail.com  Mon May  8 18:52:40 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 8 May 2017 15:52:40 -0700
Subject: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini
 SATA bridge
In-Reply-To: <CAKR_QVJTbLMzqsUTEZJOquZ9T5aQ1_=73WAoRWrm+QK9wFhngA@mail.gmail.com>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
 <CGME20170506121119epcas5p437ea69e802ba94bd7df83d0bbac1b0bc@epcas5p4.samsung.com>
 <20170506121053.11554-2-linus.walleij@linaro.org>
 <3791456.ZibJefW5cI@amdc3058>
 <CACRpkdYz9Oka0SGJDTr=y4EN-VfggbuKY2s5X43oXg1dgjh1nw@mail.gmail.com>
 <CAKR_QVJTbLMzqsUTEZJOquZ9T5aQ1_=73WAoRWrm+QK9wFhngA@mail.gmail.com>
Message-ID: <6e0751d2-8f78-c584-2990-c05bc3090214@gmail.com>

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 <linus.walleij at linaro.org
> <mailto:linus.walleij at linaro.org>> wrote:
> 
>     On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz
>     <b.zolnierkie at samsung.com <mailto:b.zolnierkie at samsung.com>> 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 at lists.openwrt.org <mailto:openwrt-devel at lists.openwrt.org>
>     https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>     <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
> 
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


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

From linus.walleij at linaro.org  Tue May  9 02:39:44 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 May 2017 08:39:44 +0200
Subject: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini
 SATA bridge
In-Reply-To: <6e0751d2-8f78-c584-2990-c05bc3090214@gmail.com>
References: <20170506121053.11554-1-linus.walleij@linaro.org>
 <CGME20170506121119epcas5p437ea69e802ba94bd7df83d0bbac1b0bc@epcas5p4.samsung.com>
 <20170506121053.11554-2-linus.walleij@linaro.org>
 <3791456.ZibJefW5cI@amdc3058>
 <CACRpkdYz9Oka0SGJDTr=y4EN-VfggbuKY2s5X43oXg1dgjh1nw@mail.gmail.com>
 <CAKR_QVJTbLMzqsUTEZJOquZ9T5aQ1_=73WAoRWrm+QK9wFhngA@mail.gmail.com>
 <6e0751d2-8f78-c584-2990-c05bc3090214@gmail.com>
Message-ID: <CACRpkdbPJDPs0bMHbKUGXt2E4O=e_rJveKy=hR-_J-GKG7oLkQ@mail.gmail.com>

On Tue, May 9, 2017 at 12:52 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
> 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.

I mailed with Tom and it turns out he thinks openwrt-devel is getting
spammed with these submissions.

It's true in a sense: the patches are targeted for upstream and not
for the openwrt repo.

It's no big deal, I don't want to unnecessarily increase traffic on
openwrt-devel if it is annoying to some.

> 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.

I am porting to D-Link DIR-685 and DNS-313 as part of the
process, so we have two new high-volume routers/NAS boxes
as part of the process. I don't know how to fix the OpenWRT
install and builds for these in the end though.

It is actually probably an even bigger win though.

We have learnt that Faraday Technology is sprinkling silicon blocks
all over any silicon foundries close to Taiwan. Their stuff appear
to be in a lot of cheap routers, NAS etc. They use the number of
successful deployments of the IP block as a selling point. I guess
these guys are commonly called in to consult when kickstarting
silicon design, simply.

It turns out that this and other silicon vendors such as Grain Media,
Andestech, Moschip etc are using the same silicon blocks, so
a bunch of out-of-tree code is actually just duplicate implementations
of Faraday drivers... we already merged Gemini and MoxaArt in
the upstream kernel so we have a common interrupt chip, timer,
PCI driver, and now this IDE/ATA driver (not the FTIDE200 yet though).

So there is maybe not as much unique silicon
in the world as we have come to think, we need to pay attention
to how register maps look on different things.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From zajec5 at gmail.com  Tue May  9 03:49:39 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 9 May 2017 09:49:39 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>

On 8 May 2017 at 15:19, John Crispin <john at phrozen.org> wrote:
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> (...)
>
> *) SPI
> - TBD post remerge

This is unclear to me. Are we postponing setting rules with SPI on how
they should manage domains? I guess it should be handled at the same
time: specifying rules (majority of votes?) and handling domains.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Tue May  9 03:50:52 2017
From: john at phrozen.org (John Crispin)
Date: Tue, 9 May 2017 09:50:52 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>
Message-ID: <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>



On 09/05/17 09:49, Rafa? Mi?ecki wrote:
> On 8 May 2017 at 15:19, John Crispin <john at phrozen.org> wrote:
>> *) domain
>> - transfer owner ship to SPI for openwrt.org and lede-project.org
>> (...)
>>
>> *) SPI
>> - TBD post remerge
> This is unclear to me. Are we postponing setting rules with SPI on how
> they should manage domains? I guess it should be handled at the same
> time: specifying rules (majority of votes?) and handling domains.
SPi will need a new liaison officer (team). we need to vote on who this 
will be. apart from that SPI will be pointed at the wiki page listing 
voters and rules. domains will be handed over to them

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

From zajec5 at gmail.com  Tue May  9 04:00:45 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 9 May 2017 10:00:45 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>
 <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>
Message-ID: <CACna6ryOqT5hCYRj7+qi12bfrrVn6eGVnrXOA7-jRNxZDW6h4A@mail.gmail.com>

On 9 May 2017 at 09:50, John Crispin <john at phrozen.org> wrote:
> On 09/05/17 09:49, Rafa? Mi?ecki wrote:
>>
>> On 8 May 2017 at 15:19, John Crispin <john at phrozen.org> wrote:
>>>
>>> *) domain
>>> - transfer owner ship to SPI for openwrt.org and lede-project.org
>>> (...)
>>>
>>> *) SPI
>>> - TBD post remerge
>>
>> This is unclear to me. Are we postponing setting rules with SPI on how
>> they should manage domains? I guess it should be handled at the same
>> time: specifying rules (majority of votes?) and handling domains.
>
> SPi will need a new liaison officer (team). we need to vote on who this will
> be. apart from that SPI will be pointed at the wiki page listing voters and
> rules. domains will be handed over to them

Sounds OK, we probably should just handle this at the same time as
handling the domains.

-- 
Rafa?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From dedeckeh at gmail.com  Tue May  9 04:12:24 2017
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Tue, 9 May 2017 10:12:24 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>
 <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>
Message-ID: <CAJLcKsFL19ALdwzkAcuNS2h8EjfiKSCcha7C7=dNdHc0YVZXUg@mail.gmail.com>

On Tue, May 9, 2017 at 9:50 AM, John Crispin <john at phrozen.org> wrote:
>
>
> On 09/05/17 09:49, Rafa? Mi?ecki wrote:
>>
>> On 8 May 2017 at 15:19, John Crispin <john at phrozen.org> wrote:
>>>
>>> *) domain
>>> - transfer owner ship to SPI for openwrt.org and lede-project.org
>>> (...)
>>>
>>> *) SPI
>>> - TBD post remerge
>>
>> This is unclear to me. Are we postponing setting rules with SPI on how
>> they should manage domains? I guess it should be handled at the same
>> time: specifying rules (majority of votes?) and handling domains.
>
> SPi will need a new liaison officer (team). we need to vote on who this will
> be. apart from that SPI will be pointed at the wiki page listing voters and
> rules. domains will be handed over to them
SPI offers different services to projects like accepting donations and
holding funds, legal assistance, technical services, etc ... Apart
from handing over the domains do we want to make use of any of the
services offered by SPI ?

Further nice to read we convergence again; thx for the effort !

Hans
>
>     John
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From zajec5 at gmail.com  Tue May  9 04:24:42 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 9 May 2017 10:24:42 +0200
Subject: [OpenWrt-Devel] Factory startup issues since mount_root /
 libfstools improvements in Chaos Calmer
In-Reply-To: <b560f9382a1e4953903be989fe42bdb3@VI1PR9003MB0253.MGDPHG.emi.philips.com>
References: <1b0f8ebd7c9748d099aea99949d7ffb8@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwkx+ypoHeVDUrcsDK7frOXMXOfjvpRhQvwJMb_9YNUtA@mail.gmail.com>
 <41c1b8bc4cf44d90a88d68faf0ca233c@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b9e3c74a-8439-fb49-c53d-c9a23beb0ba7@gmail.com>
 <4818aa28546948458468163f7200512e@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b560f9382a1e4953903be989fe42bdb3@VI1PR9003MB0253.MGDPHG.emi.philips.com>
Message-ID: <CACna6rwrm6eS-nGfepNeAU1LX_88WUMpLPuPip9nzyyj+oyX=g@mail.gmail.com>

On 8 May 2017 at 13:43, Smith, Pieter <pieter.smith at philips.com> wrote:
> I am still hoping to get confirmation from you on this patch. Is this acceptable for upstreaming?
>
>> Hi Rafa?,
>>
>> > > On 03/29/2017 11:53 AM, Smith, Pieter wrote:
>> > > > My apologies. I am not able to get mutt working with our corporate
>> > > > infrastructure. I hope it arrives unmangled as an attachment. If
>> > > > not, I'll use my personal mail.
>> > >
>> > > This would be acceptable for me to pick patch sent as attachment,
>> > > but you really need to sign it off with your name. Please add a
>> > > proper
>> > > Signed-off-by:
>> > > line and resend.
>> >
>> > Off-course! My bad...
>>
>> In adding more logging so that you can diagnose the issue, I tracked down the root cause and fixed the issue. Attached, > please find an updated patch with sign-off and a problem description.

Sorry, it took me more time than it was supposed to. Your patch went
into the fstools repository.

1) LEDE master branch
We'll bump package after fixing regression caused by commit
a19f2b3c21288 ("build: disable the format-truncation warning error to
fix gcc 7 build errors") which results in:
cc1: error: -Werror=format-truncation: no option -Wformat-truncation

2) LEDE lede-17.01 branch:
I sent patch to backport your fix:
https://patchwork.ozlabs.org/patch/759957/

3) OpenWrt 15.05 branch:
I don't really want to mess with that. I don't know if I have
privileges nor if my patch could be accepted. We need someone working
on OpenWrt to handle this.

-- 
Rafa?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pieter.smith at philips.com  Tue May  9 11:57:48 2017
From: pieter.smith at philips.com (Smith, Pieter)
Date: Tue, 9 May 2017 15:57:48 +0000
Subject: [OpenWrt-Devel] Factory startup issues since mount_root /
 libfstools improvements in Chaos Calmer
In-Reply-To: <CACna6rwrm6eS-nGfepNeAU1LX_88WUMpLPuPip9nzyyj+oyX=g@mail.gmail.com>
References: <1b0f8ebd7c9748d099aea99949d7ffb8@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwkx+ypoHeVDUrcsDK7frOXMXOfjvpRhQvwJMb_9YNUtA@mail.gmail.com>
 <41c1b8bc4cf44d90a88d68faf0ca233c@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b9e3c74a-8439-fb49-c53d-c9a23beb0ba7@gmail.com>
 <4818aa28546948458468163f7200512e@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b560f9382a1e4953903be989fe42bdb3@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwrm6eS-nGfepNeAU1LX_88WUMpLPuPip9nzyyj+oyX=g@mail.gmail.com>
Message-ID: <b8c20c84bfa346cababbb4498bc086fb@VI1PR9003MB0253.MGDPHG.emi.philips.com>

Hi Rafa?,

On 09 May 2017 at 10:25, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> On 8 May 2017 at 13:43, Smith, Pieter <pieter.smith at philips.com> wrote:
> > I am still hoping to get confirmation from you on this patch. Is this acceptable for upstreaming?
> >
> >> Hi Rafa?,
> >>
> >> > > On 03/29/2017 11:53 AM, Smith, Pieter wrote:
> >> > > > My apologies. I am not able to get mutt working with our
> >> > > > corporate infrastructure. I hope it arrives unmangled as an
> >> > > > attachment. If not, I'll use my personal mail.
> >> > >
> >> > > This would be acceptable for me to pick patch sent as attachment,
> >> > > but you really need to sign it off with your name. Please add a
> >> > > proper
> >> > > Signed-off-by:
> >> > > line and resend.
> >> >
> >> > Off-course! My bad...
> >>
> >> In adding more logging so that you can diagnose the issue, I tracked down the root cause and fixed the issue. Attached, > > please find an updated patch with sign-off and a problem description.
>
> Sorry, it took me more time than it was supposed to. Your patch went into the fstools repository.
>
> 1) LEDE master branch
> We'll bump package after fixing regression caused by commit
> a19f2b3c21288 ("build: disable the format-truncation warning error to fix gcc 7 build errors") which results in:
> cc1: error: -Werror=format-truncation: no option -Wformat-truncation
>
> 2) LEDE lede-17.01 branch:
> I sent patch to backport your fix:
> https://patchwork.ozlabs.org/patch/759957/
>
> 3) OpenWrt 15.05 branch:
> I don't really want to mess with that. I don't know if I have privileges nor if my patch could be accepted. We need someone > working on OpenWrt to handle this.
>
> --
> Rafa?

Thanks for the confirmation!
- Pieter


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Tue May  9 12:05:39 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Tue, 9 May 2017 10:05:39 -0600
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <1494250144.5407.16.camel@infradead.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <1494250144.5407.16.camel@infradead.org>
Message-ID: <E8BB854E-6D6F-45DF-85AA-B664F1B986D3@redfish-solutions.com>


> On May 8, 2017, at 7:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
>> 
>> *) 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
> 
> Yes, we can redirect the existing lists to the new ones ? so for
> example, mail sent to lede-dev will just turn up on the openwrt-dev
> list instead. Assuming that's what you meant.
> 
> For importing subscribers, if that's what you want to do, I'd be
> inclined to send *invitations* not just subscribe people. So each
> person will get the 'someone has requested that your address be
> subscribed; click here to actually do it' message. We can write our own
> blurb to go out at the top of those invitations.


I think that would be better.  I whitelist all of my mailing list subscriptions, so the reminder that I need to add a new one (when I?m not actually subscribing myself) is always helpful.

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Tue May  9 12:29:23 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Tue, 9 May 2017 10:29:23 -0600
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>


> On May 8, 2017, at 7:19 AM, John Crispin <john at phrozen.org> 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
> 
>    John



I?d like to suggest one more action item to this list if I can.  It would be handy to have a single database for user authentication/identification for submitting bugs, editing the Wiki, etc.

Previously there were too many places where you had to create an account.  If we can?t do ?single sign-on?, can we at least do ?single sign-up??

And part of a user?s profile should include their IRC handle (assuming they have one).

Thanks.

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Tue May  9 15:10:00 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Tue, 9 May 2017 21:10:00 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>
Message-ID: <22d05903-d553-42d0-3f89-f7725fc157f7@nbd.name>

On 2017-05-09 18:29, Philip Prindeville wrote:
> I?d like to suggest one more action item to this list if I can. It
> would be handy to have a single database for user
> authentication/identification for submitting bugs, editing the Wiki, etc.
> 
> Previously there were too many places where you had to create an
> account. If we can?t do ?single sign-on?, can we at least do ?single
> sign-up??
> 
> And part of a user?s profile should include their IRC handle
> (assuming they have one).
The todo list for the merge is already quite long, and we need to avoid
any unnecessary delay in getting it done.
Stuff like this will have to wait...

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From f.fainelli at gmail.com  Tue May  9 18:01:16 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 9 May 2017 15:01:16 -0700
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <90029dd3-175d-e15e-2c7e-f8f10cc1427b@gmail.com>

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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arunkumar.1993.2050 at gmail.com  Wed May 10 05:15:26 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Wed, 10 May 2017 14:45:26 +0530
Subject: [OpenWrt-Devel] GSOC 2017 - Implement NetJSON output in ubus
	(OpenWRT/LEDE)
Message-ID: <CAO4+10OuYE1JCdb2+PvD7qzo2qWcjk2QmJnbiUCt6mQogcdyvg@mail.gmail.com>

Hi Developers,

I am Arunkumar Ravichandran currently admitted for masters program at
University of California, San Diego. My proposal
<https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29>*Implement
NetJSON output in ubus (OpenWRT/LEDE)* has been accepted to the GSOC 2017
and I would like to tell more about my proposed project.

The main aim of this project is to implement parts of the NetJSON
specification in the OpenWRT/LEDE ecosystem.

*Why NetJSON ??* NetJSON would allow standardization similar to NETCONF.
Since NetJSON uses JSON format, it makes the management of configurations
done at a higher level and larger scale to be automated easily. By using
NetJSON objects to either produce or collect information, in different
vendor?s different hardware, it allows the developers to work on their
ideas faster and in a better way.

*Implementation:* The support for NETJSON
<https://github.com/netjson/netjson>is brought in at the interconnect
system- ubus <https://lede-project.org/docs/guide-developer/ubus>. To add
support for a new ubus API which allows retrieving these two NetJSON object
types: DeviceConfiguration and DeviceMonitoring. DeviceConfiguration
NetJSON objects are filled in using the plugins available in System
Configuration Abstraction Layer(SCAL
<https://github.com/prplfoundation/scal>). Full project proposal can be
read at: Google docs
<https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing>


I would welcome further suggestions from the LEDE/ OpenWRT community as
that would help in implementing this feature sooner and in a better way,
and also more resilient to multiple data models which are being used to
represent network configurations.
Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170510/ba1cfb45/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arunkumar.1993.2050 at gmail.com  Wed May 10 05:24:20 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Wed, 10 May 2017 14:54:20 +0530
Subject: [OpenWrt-Devel] GSOC 2017 - Implement NetJSON output in ubus
	(OpenWRT/LEDE)
Message-ID: <CAO4+10P0p+sLM_gDqjd0wV=Y92ybybNt018WW-EJnJz67CdmrQ@mail.gmail.com>

Hi Developers,

I am Arunkumar Ravichandran currently admitted for masters program at
University of California, San Diego. My proposal [1] Implement NetJSON
output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I
would like to tell more about my proposed project.

The main aim of this project is to implement parts of the NetJSON[2]
specification in the OpenWRT/LEDE ecosystem.

Why NetJSON ??
NetJSON would allow standardization similar to NETCONF. Since NetJSON
uses JSON format, it makes the management of configurations done at a
higher level and larger scale to be automated easily. By using NetJSON
objects to either produce or collect information, in different
vendor?s different hardware, it allows the developers to work on their
ideas faster and in a better way.

Implementation:
The support for NETJSON is brought in at the interconnect system-
ubus[3]. To add support for a new ubus API which allows retrieving
these two NetJSON object types: DeviceConfiguration[6] and
DeviceMonitoring[7]. The NetJSON objects are filled in using the
plugins available in System Configuration Abstraction Layer(SCAL)[4].
Full project proposal can be read at [5].

I would welcome further suggestions from the LEDE/ OpenWRT community
as that would help in implementing this feature sooner and in a better
way, and also more resilient to multiple data models which are being
used to represent network configurations.

[1] https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29
[2] https://github.com/netjson/netjson
[3] https://lede-project.org/docs/guide-developer/ubus
[4] https://github.com/prplfoundation/scal
[5] https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing
[6] http://netjson.org/docs/what.html#deviceconfiguration
[7] http://netjson.org/docs/what.html#devicemonitoring

Thanks,
Arun
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Wed May 10 05:35:39 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Wed, 10 May 2017 11:35:39 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>
Message-ID: <00648935-bf82-2cf3-b0e4-567e231d63a4@openwrt.org>

On 2017-05-09 18:29, Philip Prindeville wrote:

<snip>

> I?d like to suggest one more action item to this list if I can.  It would be handy to have a single database for user authentication/identification for submitting bugs, editing the Wiki, etc.
>
> Previously there were too many places where you had to create an account.  If we can?t do ?single sign-on?, can we at least do ?single sign-up??
>
> And part of a user?s profile should include their IRC handle (assuming they have one).

I agree, SSO would be way more user friendly. We should look into it for 
sure.


Best,

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

From yszhou4tech at gmail.com  Wed May 10 06:10:06 2017
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Wed, 10 May 2017 18:10:06 +0800
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <CAECwjAjxR3TG2==UJq1xfyrU6EkeS7v-nim5swv=+HhotLm5bA@mail.gmail.com>

So many items to vote and work on.  I would suggest we sort out those
formal things first, e.g. project rules, umbrella project etc.  I do
not know much about the past history apart from those posts in the
public mailing list.  But if these formal things were the major cause
of the split in the first place, they should be put forward and
tackled first.

Those technical ones are relatively easy for us I guess and not that
urgent anyway because we already have one infrastructure up and
running (not bad and I guess you will also agree) and the other one in
quiescent state for quite a while now.  From what I see it's mostly
just about how to do the name change...

my two cents

Regards,
                yousong


On 8 May 2017 at 21:19, John Crispin <john at phrozen.org> 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
>
>     John
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nemesis at ninux.org  Wed May 10 06:46:10 2017
From: nemesis at ninux.org (Nemesis)
Date: Wed, 10 May 2017 12:46:10 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] GSOC 2017 - Implement NetJSON output
 in ubus (OpenWRT/LEDE)
In-Reply-To: <CAO4+10P0p+sLM_gDqjd0wV=Y92ybybNt018WW-EJnJz67CdmrQ@mail.gmail.com>
References: <CAO4+10P0p+sLM_gDqjd0wV=Y92ybybNt018WW-EJnJz67CdmrQ@mail.gmail.com>
Message-ID: <653dc698-b43d-8f0a-b31e-ad51bf3eede9@ninux.org>

Hi Arun,

welcome to the community!

Just to provide more information, we have to thank Freifunk for their
help in getting this GSOC slot, here's the abstract that got this
project started:

https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29

Best regards
Federico


On 05/10/2017 11:24 AM, Arun Kumar wrote:
> Hi Developers,
> 
> I am Arunkumar Ravichandran currently admitted for masters program at
> University of California, San Diego. My proposal [1] Implement NetJSON
> output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I
> would like to tell more about my proposed project.
> 
> The main aim of this project is to implement parts of the NetJSON[2]
> specification in the OpenWRT/LEDE ecosystem.
> 
> Why NetJSON ??
> NetJSON would allow standardization similar to NETCONF. Since NetJSON
> uses JSON format, it makes the management of configurations done at a
> higher level and larger scale to be automated easily. By using NetJSON
> objects to either produce or collect information, in different
> vendor?s different hardware, it allows the developers to work on their
> ideas faster and in a better way.
> 
> Implementation:
> The support for NETJSON is brought in at the interconnect system-
> ubus[3]. To add support for a new ubus API which allows retrieving
> these two NetJSON object types: DeviceConfiguration[6] and
> DeviceMonitoring[7]. The NetJSON objects are filled in using the
> plugins available in System Configuration Abstraction Layer(SCAL)[4].
> Full project proposal can be read at [5].
> 
> I would welcome further suggestions from the LEDE/ OpenWRT community
> as that would help in implementing this feature sooner and in a better
> way, and also more resilient to multiple data models which are being
> used to represent network configurations.
> 
> [1] https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29
> [2] https://github.com/netjson/netjson
> [3] https://lede-project.org/docs/guide-developer/ubus
> [4] https://github.com/prplfoundation/scal
> [5] https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing
> [6] http://netjson.org/docs/what.html#deviceconfiguration
> [7] http://netjson.org/docs/what.html#devicemonitoring
> 
> Thanks,
> Arun
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Wed May 10 11:47:12 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 May 2017 17:47:12 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini
	Clock Controller
In-Reply-To: <CAL_Jsq+WQijqm43U_SzSVzCn6_eeFLjggcWnbwbCpW99ct4XOQ@mail.gmail.com>
References: <20170508201159.31634-1-linus.walleij@linaro.org>
 <CAL_JsqLAMObobPrBDdA8bjaKTX4rEo2=_qd86ibbA2kQP6AvBg@mail.gmail.com>
 <CACRpkdY+EzbbTy6PzN5-YhCnSxPoKej2z=t-7eC3CPqDa6Q4_w@mail.gmail.com>
 <CAL_Jsq+WQijqm43U_SzSVzCn6_eeFLjggcWnbwbCpW99ct4XOQ@mail.gmail.com>
Message-ID: <CACRpkdbMqwGj3gx1h_GXy1xxkxeEgj6LTy1y8rd04WRorGSymg@mail.gmail.com>

On Tue, May 9, 2017 at 4:23 PM, Rob Herring <robh+dt at kernel.org> wrote:
> On Mon, May 8, 2017 at 4:41 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Mon, May 8, 2017 at 11:24 PM, Rob Herring <robh+dt at kernel.org> wrote:
>>
>>>> +Example:
>>>> +
>>>> +syscon: syscon at 40000000 {
>>>> +       compatible = "cortina,gemini-syscon", "cortina,gemini-clock-controller",
>>>> +                    "syscon", "simple-mfd";
>>>
>>> There are no child nodes, so you don't need simple-mfd.
>>
>> The example is taken from an actual device tree (look below),
>> where there are child nodes, I can trim it down.
>>
>>>> +       reg = <0x40000000 0x1000>;
>>>
>>> Looks like you have 2 nodes pointing to the same address with your
>>> reset binding? You shouldn't have overlapping resources. It's allowed
>>> for historical reasons but breaks resource creation in Linux.
>>
>> No... they are all in the same node, just sharing the same
>> resource by way of regmap (syscon).
>
> Okay, then please document at least the parent syscon node in a single
> doc. Splitting it is very confusing.

I'm sorry. :(

I'll patch the document in arm/gemini.txt
where the syscon node is documented, with a single patch adding
both clock and reset bindings.

>>                 syscon: syscon at 40000000 {
>>                         compatible = "cortina,gemini-syscon",
>>                                      "cortina,gemini-clock-controller",
>>                                      "cortina,gemini-reset",
>
> This mostly looks fine, but you shouldn't need 3 compatible strings
> for the block.

OK I'll see if I can make it work with just "cortina,gemini-syscon"
and skip the two others.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Wed May 10 11:48:30 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 May 2017 17:48:30 +0200
Subject: [OpenWrt-Devel] [PATCH 1/4] ata: Add DT bindings for Faraday
	Technology FTIDE010
In-Reply-To: <6650456.qCJGCGKGLl@amdc3058>
References: <CGME20170506121118epcas2p1b2a2d1a8005a37582a73c0e7be4b1a1b@epcas2p1.samsung.com>
 <1678111.DmiVNKW3dQ@amdc3058>
 <CACRpkdbmOsrxKX8=a7bvcF+c=Q2tfwYQVt0=cz+_jhDyadwa2A@mail.gmail.com>
 <6650456.qCJGCGKGLl@amdc3058>
Message-ID: <CACRpkdbyPcC5FiqQ0khkNh4OvXeft_p4uwwH_yvpiiePkHcRhw@mail.gmail.com>

On Wed, May 10, 2017 at 3:59 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie at samsung.com> wrote:
> On Monday, May 08, 2017 10:26:49 PM Linus Walleij wrote:
>> On Mon, May 8, 2017 at 12:47 PM, Bartlomiej Zolnierkiewicz
>> <b.zolnierkie at samsung.com> wrote:

>> So depending on whether they use an FPGA or an ASIC the values are
>> different, no matter what frequency (50 or 66 MHz) is used. So it is not
>> derived from frequency.
>>
>> So I think it makes most sense to have it in the device tree as we don't
>> know what designs are out there.
>
> I still would prefer to keep timing values private to the driver and just
> select the controller type (FPGA/ASIC) using the device tree.

OK I'll revert to static timings in the driver, no problem.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From tmo26 at gmx.de  Wed May 10 14:42:07 2017
From: tmo26 at gmx.de (Thomas Endt)
Date: Wed, 10 May 2017 20:42:07 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <00648935-bf82-2cf3-b0e4-567e231d63a4@openwrt.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <0C27B28E-421E-4441-AADA-BA8AC0C68D36@redfish-solutions.com>
 <00648935-bf82-2cf3-b0e4-567e231d63a4@openwrt.org>
Message-ID: <000601d2c9bd$212bdb90$638392b0$@de>



> -----Urspr?ngliche Nachricht-----
> Von: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] Im
> Auftrag von Imre Kaloz
> Gesendet: Mittwoch, 10. Mai 2017 11:36
> 
> On 2017-05-09 18:29, Philip Prindeville wrote:
> 
> <snip>
> 
> > I?d like to suggest one more action item to this list if I can.  It
> would be handy to have a single database for user
> authentication/identification for submitting bugs, editing the Wiki,
> etc.
> >
> > Previously there were too many places where you had to create an
> account.  If we can?t do ?single sign-on?, can we at least do ?single
> sign-up??
> >
> > And part of a user?s profile should include their IRC handle
> (assuming they have one).
> 
> I agree, SSO would be way more user friendly. We should look into it
> for sure.


The LEDE wiki and LEDE forum currently offer login via github. Others are possible, e.g. Auth0, Google, Doorkeeper, Keycloak, ...

Thomas
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From hauke at hauke-m.de  Wed May 10 17:54:04 2017
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 10 May 2017 23:54:04 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <CAJLcKsFL19ALdwzkAcuNS2h8EjfiKSCcha7C7=dNdHc0YVZXUg@mail.gmail.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <CACna6rzBb=mbew9LETK+5z=kLwm3JwM0Uj1ssbtewMq=mhfJBg@mail.gmail.com>
 <c0a66a43-1964-32e7-33ed-ef7103d27515@phrozen.org>
 <CAJLcKsFL19ALdwzkAcuNS2h8EjfiKSCcha7C7=dNdHc0YVZXUg@mail.gmail.com>
Message-ID: <b38befe2-cfa2-0a8a-ffda-e54a4b0997d1@hauke-m.de>

On 05/09/2017 10:12 AM, Hans Dedecker wrote:
> On Tue, May 9, 2017 at 9:50 AM, John Crispin <john at phrozen.org> wrote:
>>
>>
>> On 09/05/17 09:49, Rafa? Mi?ecki wrote:
>>>
>>> On 8 May 2017 at 15:19, John Crispin <john at phrozen.org> wrote:
>>>>
>>>> *) domain
>>>> - transfer owner ship to SPI for openwrt.org and lede-project.org
>>>> (...)
>>>>
>>>> *) SPI
>>>> - TBD post remerge
>>>
>>> This is unclear to me. Are we postponing setting rules with SPI on how
>>> they should manage domains? I guess it should be handled at the same
>>> time: specifying rules (majority of votes?) and handling domains.
>>
>> SPi will need a new liaison officer (team). we need to vote on who this will
>> be. apart from that SPI will be pointed at the wiki page listing voters and
>> rules. domains will be handed over to them
> SPI offers different services to projects like accepting donations and
> holding funds, legal assistance, technical services, etc ... Apart
> from handing over the domains do we want to make use of any of the
> services offered by SPI ?
> 
> Further nice to read we convergence again; thx for the effort !

I would like if we take the same services as OpenWrt did in the past
from SPI (Software in the Public Interest) + the DNS / Domain service as
mentioned in this mail.

* SPI holds the OpenWrt trademark for the OpenWrt project
* SPI accepts donations for the OpenWrt project (incl. tax reduction)
* SPI manages the OpenWrt "bank" account
* SPI gave legal advice for the trademark and will help on other topics

OpenWrt had 6040.14 USD in the account at SPI by 1.1.2017, 1621.13 USD
were donated to OpenWrt in the year 2016:
http://www.spi-inc.org/treasurer/reports/201612/#index58h4

In my opinion SPI did a good job and did everything we asked them for
and did not try to take over the project or something like this. ;-)
From my understanding no one has a problem with the SPI, but some people
are a reluctant against some of the other organizations.

We need a new representation at the SPI and should vote about it.

Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From hauke at hauke-m.de  Wed May 10 18:17:37 2017
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Thu, 11 May 2017 00:17:37 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
Message-ID: <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>

Thanks for moving this forward.

On 05/08/2017 03:19 PM, John Crispin wrote:
> *) github
.....
> 
> - obsolete the lede github org after a grace period of 3-6 months

As long as it does not cost us effort I would like to keep the lede
domains and github project up running for longer.

> *) 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

I prefer the LEDE design, but with the news like content on the OpenWrt
page, but I do not really care and will not block the merge about this.
Is someone volunteering to prepare a design which also fulfills Imre's
requirements, I am also asking the non LEDE committers and non OpenWrt
core developers? I am not good at this. ;-)

> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy

I would like to put the sponsorship policy into the back to not block
things, the trademark policy looks OK. Did any lawyer looked at the
trademark policy?

Will someone work on a joint statement which then marks the official
merge? Will the SPI recognize also the LEDE members as OpenWrt members
after such a statement or when will this happen?

Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From hannu.nyman at iki.fi  Thu May 11 04:03:08 2017
From: hannu.nyman at iki.fi (Hannu Nyman)
Date: Thu, 11 May 2017 11:03:08 +0300
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
References: <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
Message-ID: <0e918499-8436-5583-6677-4e85c863df5e@iki.fi>

Hauke Mehrtens wrote on Wed May 10 15:17:37 PDT 2017:

 > On 05/08/2017 03:19 PM, John Crispin wrote:
 > > *) 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
 >
 > I prefer the LEDE design, but with the news like content on the OpenWrt
 > page, but I do not really care and will not block the merge about this.

My two cents to the design discussion:

The old www.openwrt.org, wiki and downloads site design is rather dusty and 
looks like 1990s.

The "news-like" content of the Openwrt www front page has been problematic 
due to the strange reason that the page contains a prominent "Headlines" lift 
box for OLD news but not for current news. Right now it highligts e.g. 
Backfire 10.03.1 release... Current news items are not listed in the 
Headlines-liftbox but just displayed in the wide middle column. But does 
anybody really scroll down that long page to find the next current news item 
below the topmost one? I have started to complain about that design already 
in 2011 so this opinion is not new...
https://dev.openwrt.org/ticket/10655
https://forum.openwrt.org/viewtopic.php?pid=313132#p313132
https://forum.openwrt.org/viewtopic.php?pid=314276#p314276

I hope that if any news-like content gets displayed on the new front page, 
the old design mistakes can be avoided.


 > > *) wiki / forum

Regarding wiki and forum, I prefer the LEDE's design and the LEDE forum's 
modern functionality (user targeting, easy picture copy-paste, responsivity 
etc.) over the old Openwrt forum. That opinion is based on rather active 
forum usage, as based on the number of posts I am currently the #2 poster on 
the Openwrt forum and #1 on the LEDE forum.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mschiffer at universe-factory.net  Thu May 11 04:30:12 2017
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Thu, 11 May 2017 10:30:12 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
Message-ID: <9253a3fd-a056-4616-afa5-027863107d8b@universe-factory.net>

On 05/11/2017 12:17 AM, Hauke Mehrtens wrote:
> Thanks for moving this forward.
>
> On 05/08/2017 03:19 PM, John Crispin wrote:
>> *) github
> .....
>>
>> - obsolete the lede github org after a grace period of 3-6 months
>
> As long as it does not cost us effort I would like to keep the lede
> domains and github project up running for longer.

This one is a bit tricky. On the one hand, people are referencing our
Github repositories in their scripts and dependent projects, so we should
keep it around at least for a while; on the other hand, Github doesn't
allow disabling PRs (AFAIK), so deleting the project would give developers
a clear signal where to contribute.


>
>> *) 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
>
> I prefer the LEDE design, but with the news like content on the OpenWrt
> page, but I do not really care and will not block the merge about this.
> Is someone volunteering to prepare a design which also fulfills Imre's
> requirements, I am also asking the non LEDE committers and non OpenWrt
> core developers? I am not good at this. ;-)

I realize this is bikeshedding, but I also very much prefer the LEDE
design, it looks much more modern. In particular:
- everything with a lot of text has a white background; generally colors
are used sparingly
- thin grey borders instead of thick black ones

The OpenWrt forum design looks a bit better than the landing page, but it
still feels too heavy due to the colored backgrounds.

Matthias


>
> Hauke
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170511/111afcbe/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mschiffer at universe-factory.net  Thu May 11 05:03:53 2017
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Thu, 11 May 2017 11:03:53 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <0abd5d06-381f-4db3-61f1-7b4ab190309b@mein.io>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <a0da6127-9ce8-8714-25a5-52c204e3286b@mein.io>
 <9ce12b05-58fb-ea33-f106-cc6b8152e370@openwrt.org>
 <0abd5d06-381f-4db3-61f1-7b4ab190309b@mein.io>
Message-ID: <ae799608-4e50-3c03-bb2e-945d3a6c2671@universe-factory.net>

[Some lists were dropped from this thread, adding again]


> 
>>> According to the rules there shall be no personal mail accounts at all.
>>> There should be plenty of time until the actual remerge to fade them out
>>> and to set up forwarding elsewhere.
>>
>> I hope you agree that a merge means both sides are adopting and need to
>> find some common ground.
>>
>> Some of the rules has to change, and as we've discussed it with John,
>> one might want to send upstream submissions to make OpenWrt show up
>> there like other projects do. You might also want to open a private
>> conversation between the upstream platform / driver maintainer where
>> having a project email address could be useful. Personally I only use my
>> owrt address for FOSS related stuff and as far as I know, most people do
>> the same.

It would be great to have a list of rules that are controversial in your
opinion (or the OpenWrt side in general), or even a proposal for a new set
of rules, so we have something concrete to discuss.

> 
> I do not know what was discussed in detail here but I am strongly
> against personal project email addresses for outgoing communication.
> 
> In my opinion a personal contribution record should stand for itself and
> leveraging *@openwrt.org sender credibility to get stuff accepted which
> would otherwise get rejected leaves a bad taste.
> 
> Doing that would encourage people to try to get part of the project
> solely to take advantage of the added credibility as "door opener". IMHO
> this might cause envy and discontent among the contributor base.
> 
> Personally I would have no problem adding inbound mail redirects for
> those few personal mail accounts that still exist but these redirects
> should merely forward to personal non-project mailboxes.

While I don't see people trying to get into the project just to get a mail
address as a serious threat, I generally agree with the rule not to allow
personal project mail addresses. But I guess this is also the most
controversial point of our rules...

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170511/b2efec97/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From francesco.borromini at inventati.org  Thu May 11 06:53:41 2017
From: francesco.borromini at inventati.org (Stijn Segers)
Date: Thu, 11 May 2017 12:53:41 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
Message-ID: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>

Hey guys,

This might be a bit lengthy, but I should get this off my chest. I feel 
people are mostly looking at the upside and glossing over the negatives, 
which is a time bomb, and both projects do not deserve this. Paul's 
e-mail [0] already touches a lot of the relevant points, and it 
motivated me to add my own insights to what so far seems to have been a 
'good news show' as we say in Dutch.

While, like most people, I'm happy progress has been made towards a 
re-merge, there still seems quite some passive-agressive behaviour 
present coming from certain people championing OpenWrt [1] - which, from 
where I stand, seemed one of the reasons for starting LEDE. Stifling 
'free' speech (recently, even to the point of removing messages about 
the pending re-merge on the OpenWrt forums) was another one; clearly, 
that one is still very much present as well. One could say old habits 
die hard, but it still feels like par for the course. What's up with 
that? You want to remerge with the LEDE project, yet you cannot tolerate 
any discussion about the actual process on the OpenWrt forums? That's 
some fine duplicity right there.

I can't help but feel very uneasy about this. I'm not implying people 
who stuck with OpenWrt don't want the best for the project and community 
(most do), but we all know LEDE was created to remedy exactly these (and 
other) shortcomings, which made OpenWrt languish to the point it had 
come to a standstill. Not only did LEDE try to tackle these problems; it 
has succeeded beyond expectation. Developers are more accessible, you 
can actually talk to people instead of getting your head bit off, 
contributions are booming, and the atmosphere overall is friendly and 
helpful. Discussion is encouraged, not repressed Soviet-style.

Some of the OpenWrt veterans come across as if they want the re-merge to 
be rushed, ignoring the actual issues that caused the fork in the first 
place. In itself, the desire to re-merge might a noble intent, if it 
didn't taste so much like driven by ulterior, more selfish motives. At 
the same time, while OpenWrt have little to offer beyond the OpenWrt 
name and legacy (which, at this point, feels more and more rotten to me, 
despite all the good things that once came from it), they field some 
pretty hard nos - very astonishing, given the position they are in: no 
to abandoning the OpenWrt name, no to abandoning the OpenWrt 'house 
style' [1]. Luckily, not everyone shares that same attitude [2], but it 
leaves a very bad taste. Almost like some people haven't learnt from the 
whole ordeal, and went back to their old ways pretty quickly.

It feels pushy, and seems to boil down to 'it's all fine and dandy what 
you did, but it's still OpenWrt; don't get any illusions, you're not 
running the show'. This is very toxic, even more so when you realise 
that an overwhelming majority of active (!) OpenWrt developers either 
started or joined the LEDE project. Some of the vocal veterans sticking 
with OpenWrt hardly contribute any code anymore, and haven't done so in 
a while, or other valuable input, but they were most vocal when the 
split happened, pointing fingers and accusing people (ironically, people 
who *did* contribute code, actively maintained infrastructure, and had 
the interests of the project and community at heart). Again, they are 
yelling the hardest now, and waving that OpenWrt flag like there's no 
tomorrow. Imre nothing short of ignores the whole LEDE effort by stating 
explicitly that LEDE 17.01 (which Hauke put forward as an official 
OpenWrt 15.01 successor in an initial communication draft about the 
merge [3]) was NOT its successor [4]. Combined with his push for the 
OpenWrt name and keeping pretty much everything else OpenWrt (the 
dysfunctional homepage, the forums), it reeks of a coverup: LEDE was a 
hiccup, an anomaly, a gene malfunction, something that needs to be 
corrected and removed from the 'history books' as soon as possible, so 
it can all feel hunky dory again - and mostly, so it looks and smells 
like OpenWrt. By now, that smell has turned into quite a stench though. 
Luckily, the industry and a lot of end users seem to be impervious to 
it...

For me, the OpenWrt name and project by now feels tainted. For months on 
end, you could browse the OpenWrt forums, or hang in #openwrt and never 
catch a dev or someone who knew what was (or wasn't) going on. Backends 
went down, sites disappeared, and it doesn't help to keep pointing to 
the OpenWrt name 'because the industry only knows OpenWrt', or 'because 
end users still don't know about LEDE'. Linux has been around for two 
decades now, and a lot of people with a computer still haven't heard of 
it. Before Mozilla, the internet only knew IE. Before Linux, sysadmins 
only knew Unices. Anyway, plenty of comparisons at hand - you get the 
gist. OpenWrt has served its purpose. It is time to part ways.

It looks like some people have resigned to adopting the name again for 
the greater good, because they want this mess to be over with 
(understandably). The last vote tally I found [3] was a tie on the most 
contentious issue - the name. A week ago [4], Hauke states there is a 
majority in favour of re-adopting the OpenWrt name. I have been looking 
up and down but seem to have overlooked the final tally - I cannot find 
it? Can somebody link me?

I'm sure a lot of people want this to be fixed, want things to be right 
again. Most of those have the best interests of the community and both 
projects in mind, but some do not, and the latter seem to be waging a 
war of attrition. I enjoy being part of the LEDE community. I never felt 
OpenWrt was much of a community in the months prior to the fork, and I'd 
hate to see LEDE go the same way as OpenWrt right before. There will be 
infighting again, snide remarks, stalled development... And meanwhile, 
people will say 'hey we need new blood', but that won't come with such a 
backstabbing culture.

My two cents.

Cheers

Stijn Segers

[0] http://lists.infradead.org/pipermail/lede-dev/2017-May/007403.html
[1] http://lists.infradead.org/pipermail/lede-dev/2017-May/007342.html
[2] http://lists.infradead.org/pipermail/lede-dev/2017-May/007347.html
[3] http://lists.infradead.org/pipermail/lede-adm/2017-May/000461.html
[4] http://lists.infradead.org/pipermail/lede-adm/2017-May/000462.html
[5] http://lists.infradead.org/pipermail/lede-adm/2017-March/000436.html
[6] http://lists.infradead.org/pipermail/lede-adm/2017-May/000461.html
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From francesco.borromini at inventati.org  Thu May 11 07:10:19 2017
From: francesco.borromini at inventati.org (Stijn Segers)
Date: Thu, 11 May 2017 13:10:19 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
References: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
Message-ID: <71f00b3aecfb85ea6868e4685db96088@inventati.org>

Of course you only see you numbered your notes the wrong way *after* you 
send your e-mail...

The second [3] and [4] should have been [5] and [6] (see inline).

Stijn Segers schreef op 2017-05-11 12:53:
> Hey guys,
> 
> This might be a bit lengthy, but I should get this off my chest. I
> feel people are mostly looking at the upside and glossing over the
> negatives, which is a time bomb, and both projects do not deserve
> this. Paul's e-mail [0] already touches a lot of the relevant points,
> and it motivated me to add my own insights to what so far seems to
> have been a 'good news show' as we say in Dutch.
> 
> While, like most people, I'm happy progress has been made towards a
> re-merge, there still seems quite some passive-agressive behaviour
> present coming from certain people championing OpenWrt [1] - which,
> from where I stand, seemed one of the reasons for starting LEDE.
> Stifling 'free' speech (recently, even to the point of removing
> messages about the pending re-merge on the OpenWrt forums) was another
> one; clearly, that one is still very much present as well. One could
> say old habits die hard, but it still feels like par for the course.
> What's up with that? You want to remerge with the LEDE project, yet
> you cannot tolerate any discussion about the actual process on the
> OpenWrt forums? That's some fine duplicity right there.
> 
> I can't help but feel very uneasy about this. I'm not implying people
> who stuck with OpenWrt don't want the best for the project and
> community (most do), but we all know LEDE was created to remedy
> exactly these (and other) shortcomings, which made OpenWrt languish to
> the point it had come to a standstill. Not only did LEDE try to tackle
> these problems; it has succeeded beyond expectation. Developers are
> more accessible, you can actually talk to people instead of getting
> your head bit off, contributions are booming, and the atmosphere
> overall is friendly and helpful. Discussion is encouraged, not
> repressed Soviet-style.
> 
> Some of the OpenWrt veterans come across as if they want the re-merge
> to be rushed, ignoring the actual issues that caused the fork in the
> first place. In itself, the desire to re-merge might a noble intent,
> if it didn't taste so much like driven by ulterior, more selfish
> motives. At the same time, while OpenWrt have little to offer beyond
> the OpenWrt name and legacy (which, at this point, feels more and more
> rotten to me, despite all the good things that once came from it),
> they field some pretty hard nos - very astonishing, given the position
> they are in: no to abandoning the OpenWrt name, no to abandoning the
> OpenWrt 'house style' [1]. Luckily, not everyone shares that same
> attitude [2], but it leaves a very bad taste. Almost like some people
> haven't learnt from the whole ordeal, and went back to their old ways
> pretty quickly.
> 
> It feels pushy, and seems to boil down to 'it's all fine and dandy
> what you did, but it's still OpenWrt; don't get any illusions, you're
> not running the show'. This is very toxic, even more so when you
> realise that an overwhelming majority of active (!) OpenWrt developers
> either started or joined the LEDE project. Some of the vocal veterans
> sticking with OpenWrt hardly contribute any code anymore, and haven't
> done so in a while, or other valuable input, but they were most vocal
> when the split happened, pointing fingers and accusing people
> (ironically, people who *did* contribute code, actively maintained
> infrastructure, and had the interests of the project and community at
> heart). Again, they are yelling the hardest now, and waving that
> OpenWrt flag like there's no tomorrow. Imre nothing short of ignores
> the whole LEDE effort by stating explicitly that LEDE 17.01 (which
> Hauke put forward as an official OpenWrt 15.01 successor in an initial
> communication draft about the merge [3]) was NOT its successor [4].
> Combined with his push for the OpenWrt name and keeping pretty much
> everything else OpenWrt (the dysfunctional homepage, the forums), it
> reeks of a coverup: LEDE was a hiccup, an anomaly, a gene malfunction,
> something that needs to be corrected and removed from the 'history
> books' as soon as possible, so it can all feel hunky dory again - and
> mostly, so it looks and smells like OpenWrt. By now, that smell has
> turned into quite a stench though. Luckily, the industry and a lot of
> end users seem to be impervious to it...
> 
> For me, the OpenWrt name and project by now feels tainted. For months
> on end, you could browse the OpenWrt forums, or hang in #openwrt and
> never catch a dev or someone who knew what was (or wasn't) going on.
> Backends went down, sites disappeared, and it doesn't help to keep
> pointing to the OpenWrt name 'because the industry only knows
> OpenWrt', or 'because end users still don't know about LEDE'. Linux
> has been around for two decades now, and a lot of people with a
> computer still haven't heard of it. Before Mozilla, the internet only
> knew IE. Before Linux, sysadmins only knew Unices. Anyway, plenty of
> comparisons at hand - you get the gist. OpenWrt has served its
> purpose. It is time to part ways.
> 

Note references below fixed.

> It looks like some people have resigned to adopting the name again for
> the greater good, because they want this mess to be over with
> (understandably). The last vote tally I found [5] was a tie on the
> most contentious issue - the name. A week ago [6], Hauke states there
> is a majority in favour of re-adopting the OpenWrt name. I have been
> looking up and down but seem to have overlooked the final tally - I
> cannot find it? Can somebody link me?
> 
> I'm sure a lot of people want this to be fixed, want things to be
> right again. Most of those have the best interests of the community
> and both projects in mind, but some do not, and the latter seem to be
> waging a war of attrition. I enjoy being part of the LEDE community. I
> never felt OpenWrt was much of a community in the months prior to the
> fork, and I'd hate to see LEDE go the same way as OpenWrt right
> before. There will be infighting again, snide remarks, stalled
> development... And meanwhile, people will say 'hey we need new blood',
> but that won't come with such a backstabbing culture.
> 
> My two cents.
> 
> Cheers
> 
> Stijn Segers
> 
> [0] http://lists.infradead.org/pipermail/lede-dev/2017-May/007403.html
> [1] http://lists.infradead.org/pipermail/lede-dev/2017-May/007342.html
> [2] http://lists.infradead.org/pipermail/lede-dev/2017-May/007347.html
> [3] http://lists.infradead.org/pipermail/lede-adm/2017-May/000461.html
> [4] http://lists.infradead.org/pipermail/lede-adm/2017-May/000462.html
> [5] 
> http://lists.infradead.org/pipermail/lede-adm/2017-March/000436.html
> [6] http://lists.infradead.org/pipermail/lede-adm/2017-May/000461.html
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Thu May 11 09:13:33 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Thu, 11 May 2017 15:13:33 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
References: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
Message-ID: <6b71ac29-455c-26f3-ef94-2d84ac9c9437@openwrt.org>

Well hello there,

On 2017-05-11 12:53, Stijn Segers wrote:
<snip>

> While, like most people, I'm happy progress has been made towards a
> re-merge, there still seems quite some passive-agressive behaviour
> present coming from certain people championing OpenWrt [1] - which, from
> where I stand, seemed one of the reasons for starting LEDE. Stifling
> 'free' speech (recently, even to the point of removing messages about
> the pending re-merge on the OpenWrt forums) was another one; clearly,
> that one is still very much present as well. One could say old habits
> die hard, but it still feels like par for the course. What's up with
> that? You want to remerge with the LEDE project, yet you cannot tolerate
> any discussion about the actual process on the OpenWrt forums? That's
> some fine duplicity right there.

I guess our vocabularies differ quite a bit, given I see no 
passive-aggressive statements there. I hope you just misunderstood the 
ways some things have been worded, as your mail overemphasized certain 
parts to twist the picture. I could very well say you're championing 
yourself but somehow I don't see mails from you sent to any lists nor me 
about questioning the forum moderators' behavior. Of course you could 
have also stepped up and volunteer to be one, but either of these would 
have required more energy then this mail.

Don't get me wrong, I'm not questioning if you're right, but you should 
also be a bit more empathetic and understand a few things.

First of all, forum moderator rights have been given out as we didn't 
have time to do it ourselves. This also means that after the first few 
days we didn't spend our time on monitoring what people with moderator 
rights are doing.

Second, and this might be harder to accept, but to a certain degree when 
the first reply to anything is "OpenWrt is dead, go with LEDE", your 
behavior might generate a hostile reply. Again, I'm not saying this is 
right, I'm saying this is standard human behavior.

Back to my reply you love referring to: for me it seems you are the one 
who can't tolerate the discussion and would like to silence opinions (or 
how they can be expressed) you don't like. You might prefer baroque, I'm 
free to like renaissance.

> I can't help but feel very uneasy about this. I'm not implying people
> who stuck with OpenWrt don't want the best for the project and community
> (most do), but we all know LEDE was created to remedy exactly these (and
> other) shortcomings, which made OpenWrt languish to the point it had
> come to a standstill. Not only did LEDE try to tackle these problems; it
> has succeeded beyond expectation. Developers are more accessible, you
> can actually talk to people instead of getting your head bit off,
> contributions are booming, and the atmosphere overall is friendly and
> helpful. Discussion is encouraged, not repressed Soviet-style.

The reasons of the fork have been discussed quite a few times, and if 
you think any project will be free of internal politics over a decade, 
you might want to look into the history of FOSS projects in general :)

As the rest of your mail is mostly FUD, let's stick to facts if you 
consider replying. As the saying goes, in any relationship, there are 
three sides of the story: his side, her side and the truth.

Both sides have hard feelings about certain topics, but this discussion 
started because we've decided to put those away. I can only ask you to 
try the same instead of sending mails like this.


Thanks,

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

From francesco.borromini at inventati.org  Thu May 11 09:39:49 2017
From: francesco.borromini at inventati.org (Stijn Segers)
Date: Thu, 11 May 2017 15:39:49 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <6b71ac29-455c-26f3-ef94-2d84ac9c9437@openwrt.org>
References: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
 <6b71ac29-455c-26f3-ef94-2d84ac9c9437@openwrt.org>
Message-ID: <d0db194e7ad3945f15892eb74be7b66b@inventati.org>

Thanks for the reply Imre.

Imre Kaloz schreef op 2017-05-11 15:13:
> Well hello there,
> 
> On 2017-05-11 12:53, Stijn Segers wrote:
> <snip>
> 
>> While, like most people, I'm happy progress has been made towards a
>> re-merge, there still seems quite some passive-agressive behaviour
>> present coming from certain people championing OpenWrt [1] - which, 
>> from
>> where I stand, seemed one of the reasons for starting LEDE. Stifling
>> 'free' speech (recently, even to the point of removing messages about
>> the pending re-merge on the OpenWrt forums) was another one; clearly,
>> that one is still very much present as well. One could say old habits
>> die hard, but it still feels like par for the course. What's up with
>> that? You want to remerge with the LEDE project, yet you cannot 
>> tolerate
>> any discussion about the actual process on the OpenWrt forums? That's
>> some fine duplicity right there.
> 
> I guess our vocabularies differ quite a bit, given I see no
> passive-aggressive statements there.

Well, the 'Our design might be from 2000 but LEDE's is from 95' does 
come across as agressive, and the wink certainly doesn't make it any 
lighter. But you're right, I might just be reading into it. Either way, 
I have seen your mails right after the split as well, granted, your tone 
is more constructive at the moment, which is great. But those mails were 
full of anger, like a bull in a china shop, or a kid losing his toy.

> I hope you just misunderstood the
> ways some things have been worded, as your mail overemphasized certain
> parts to twist the picture. I could very well say you're championing
> yourself but somehow I don't see mails from you sent to any lists nor
> me about questioning the forum moderators' behavior. Of course you
> could have also stepped up and volunteer to be one, but either of
> these would have required more energy then this mail.
> 
> Don't get me wrong, I'm not questioning if you're right, but you
> should also be a bit more empathetic and understand a few things.
> 
> First of all, forum moderator rights have been given out as we didn't
> have time to do it ourselves. This also means that after the first few
> days we didn't spend our time on monitoring what people with moderator
> rights are doing.

Understandably. But you also know that if people go berserk, that gives 
the project as a whole a bad name. It only further deteriorated the 
atmosphere. Some LEDE members hoped the OpenWrt forum would have been 
more welcoming to the project in the short term, since LEDE members from 
the onset made it clear that they did not intend to divide the 
community; but that didn't work out. But like you say: we're just human 
after all, and good intentions often aren't enough.

> 
> Second, and this might be harder to accept, but to a certain degree
> when the first reply to anything is "OpenWrt is dead, go with LEDE",
> your behavior might generate a hostile reply.

A statement a lot of people certainly fielded, but I'm not one to say 
that. Yet, you cannot deny between LEDE and OpenWrt, since the split, 
the latter has been showing a considerably weaker pulse.

> Again, I'm not saying
> this is right, I'm saying this is standard human behavior.
> 
> Back to my reply you love referring to: for me it seems you are the
> one who can't tolerate the discussion and would like to silence
> opinions (or how they can be expressed) you don't like. You might
> prefer baroque, I'm free to like renaissance.

Pointing the finger the other way does not invalidate my observations in 
any way, unfortunately.

> 
>> I can't help but feel very uneasy about this. I'm not implying people
>> who stuck with OpenWrt don't want the best for the project and 
>> community
>> (most do), but we all know LEDE was created to remedy exactly these 
>> (and
>> other) shortcomings, which made OpenWrt languish to the point it had
>> come to a standstill. Not only did LEDE try to tackle these problems; 
>> it
>> has succeeded beyond expectation. Developers are more accessible, you
>> can actually talk to people instead of getting your head bit off,
>> contributions are booming, and the atmosphere overall is friendly and
>> helpful. Discussion is encouraged, not repressed Soviet-style.
> 
> The reasons of the fork have been discussed quite a few times, and if
> you think any project will be free of internal politics over a decade,
> you might want to look into the history of FOSS projects in general :)
> 

I might be a bit naive, indeed :).

> As the rest of your mail is mostly FUD,

No doubt, just like the lethargy was all make believe, right? Two mails 
in, but it won't be long before we get into a Godwin here, I reckon.

> let's stick to facts if you consider replying.

I asked about the facts - the final tally on the most contentious issue 
- and I'm not finding that fact. We both know that was the major issue 
at hand, one of the few non-negotiable items for you (and maybe other 
people). I see the vote go from a tie to 'we'll go with the OpenWrt 
monniker again', yet I cannot find a trace of how that happened. Quite 
possible I overlooked it.

> As the saying goes, in any relationship, there are
> three sides of the story: his side, her side and the truth.
> 
> Both sides have hard feelings about certain topics, but this
> discussion started because we've decided to put those away. I can only
> ask you to try the same instead of sending mails like this.

All I asked for was a link to a mailing list post containing the final 
vote, which I cannot find. Since you're one of the pivotal members of 
this process, can you provide it?

Cheers

Stijn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From j.lancett at ntlworld.com  Thu May 11 11:27:51 2017
From: j.lancett at ntlworld.com (tapper)
Date: Thu, 11 May 2017 16:27:51 +0100
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <9253a3fd-a056-4616-afa5-027863107d8b@universe-factory.net>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
 <9253a3fd-a056-4616-afa5-027863107d8b@universe-factory.net>
Message-ID: <f42e927c-0869-08e7-4610-d0aaf328ac4c@ntlworld.com>

On 11/05/2017 09:30, Matthias Schiffer wrote:
> On 05/11/2017 12:17 AM, Hauke Mehrtens wrote:
>> Thanks for moving this forward.
>>
>> On 05/08/2017 03:19 PM, John Crispin wrote:
>>> *) github
>> .....
>>>
>>> - obsolete the lede github org after a grace period of 3-6 months
>>
>> As long as it does not cost us effort I would like to keep the lede
>> domains and github project up running for longer.
> 
> This one is a bit tricky. On the one hand, people are referencing our
> Github repositories in their scripts and dependent projects, so we should
> keep it around at least for a while; on the other hand, Github doesn't
> allow disabling PRs (AFAIK), so deleting the project would give developers
> a clear signal where to contribute.
> 
> 
>>
>>> *) 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
>>
>> I prefer the LEDE design, but with the news like content on the OpenWrt
>> page, but I do not really care and will not block the merge about this.
>> Is someone volunteering to prepare a design which also fulfills Imre's
>> requirements, I am also asking the non LEDE committers and non OpenWrt
>> core developers? I am not good at this. ;-)
> 
> I realize this is bikeshedding, but I also very much prefer the LEDE
> design, it looks much more modern. In particular:
> - everything with a lot of text has a white background; generally colors
> are used sparingly
> - thin grey borders instead of thick black ones
> 
> The OpenWrt forum design looks a bit better than the landing page, but it
> still feels too heavy due to the colored backgrounds.
> 
> Matthias
> 
> 
>>
>> Hauke
>>
One more thing about the LEDE forum is it is very hard to use with a 
screen reader where as the OpenWRT one is very good to use. For all 
blind people could we stick with the Openwrt forum but spruce it up a 
bit so it looks better for those of us that can see.
Tapper

> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From martin.tippmann at gmail.com  Thu May 11 13:42:37 2017
From: martin.tippmann at gmail.com (Martin Tippmann)
Date: Thu, 11 May 2017 19:42:37 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <f42e927c-0869-08e7-4610-d0aaf328ac4c@ntlworld.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
 <9253a3fd-a056-4616-afa5-027863107d8b@universe-factory.net>
 <f42e927c-0869-08e7-4610-d0aaf328ac4c@ntlworld.com>
Message-ID: <CABL_Pd_9F+mw_f3Ls_MxLmJQ6dh3iNuHJ_Q79Ar1Zf8_X=aoHg@mail.gmail.com>

On Thu, May 11, 2017 at 5:27 PM, tapper <j.lancett at ntlworld.com> wrote:
> On 11/05/2017 09:30, Matthias Schiffer wrote:
>>
>> On 05/11/2017 12:17 AM, Hauke Mehrtens wrote:
>>>
>>> Thanks for moving this forward.
>>>
>>> On 05/08/2017 03:19 PM, John Crispin wrote:
>>>>
>>>> *) github
>>>
>>> .....
>>>>
>>>>
>>>> - obsolete the lede github org after a grace period of 3-6 months
>>>
>>>
>>> As long as it does not cost us effort I would like to keep the lede
>>> domains and github project up running for longer.
>>
>>
>> This one is a bit tricky. On the one hand, people are referencing our
>> Github repositories in their scripts and dependent projects, so we should
>> keep it around at least for a while; on the other hand, Github doesn't
>> allow disabling PRs (AFAIK), so deleting the project would give developers
>> a clear signal where to contribute.
>>
>>
>>>
>>>> *) 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
>>>
>>>
>>> I prefer the LEDE design, but with the news like content on the OpenWrt
>>> page, but I do not really care and will not block the merge about this.
>>> Is someone volunteering to prepare a design which also fulfills Imre's
>>> requirements, I am also asking the non LEDE committers and non OpenWrt
>>> core developers? I am not good at this. ;-)
>>
>>
>> I realize this is bikeshedding, but I also very much prefer the LEDE
>> design, it looks much more modern. In particular:
>> - everything with a lot of text has a white background; generally colors
>> are used sparingly
>> - thin grey borders instead of thick black ones
>>
>> The OpenWrt forum design looks a bit better than the landing page, but it
>> still feels too heavy due to the colored backgrounds.
>>
>> Matthias
>>
>>
>>>
>>> Hauke
>>>
> One more thing about the LEDE forum is it is very hard to use with a screen
> reader where as the OpenWRT one is very good to use. For all blind people
> could we stick with the Openwrt forum but spruce it up a bit so it looks
> better for those of us that can see.

Hi, the used Discourse Software sadly does not seem to make screen
readers a priority :(, but they seem interested in feedback[0]

Just an idea: Would NNTP Support help here? There seems to be a
maintained plugin[1] and if that works well enough, access via any
NNTP client or a simple site / forum like the dlang forum[3] that
plays well with linux and screen readers might be an option.

regards
Martin


0: https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/23
1: https://github.com/sman591/discourse-nntp-bridge
3: http://forum.dlang.org
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Thu May 11 15:06:57 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Thu, 11 May 2017 13:06:57 -0600
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
References: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
Message-ID: <D4B4D458-B925-4C6C-9F40-5F3C80A5D60A@redfish-solutions.com>


> On May 11, 2017, at 4:53 AM, Stijn Segers <francesco.borromini at inventati.org> wrote:
> 
> Some of the OpenWrt veterans come across as if they want the re-merge to be rushed, ignoring the actual issues that caused the fork in the first place.


Yeah, I have to agree with this.  You don?t get married, then define your vows afterwards?

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Thu May 11 15:16:17 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Thu, 11 May 2017 13:16:17 -0600
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
In-Reply-To: <D4B4D458-B925-4C6C-9F40-5F3C80A5D60A@redfish-solutions.com>
References: <a5bb8461cb93d4f6c01fda1a7498eae3@inventati.org>
 <D4B4D458-B925-4C6C-9F40-5F3C80A5D60A@redfish-solutions.com>
Message-ID: <9484EB26-9E4F-4B06-BBF0-A713E61541D6@redfish-solutions.com>


> On May 11, 2017, at 1:06 PM, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
> 
> Yeah, I have to agree with this.  You don?t get married, then define your vows afterwards?

Actually, sticking with the ?marriage? paradigm a bit longer, what are the assets that the OpenWRT family brings to the union?  And what does LEDE bring to the union?

Maybe voting rights should be proportional to the assets brought to the table?  like in a corporate merger or acquisition.

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From david at lang.hm  Thu May 11 15:54:06 2017
From: david at lang.hm (David Lang)
Date: Thu, 11 May 2017 12:54:06 -0700 (PDT)
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal
In-Reply-To: <CABL_Pd_9F+mw_f3Ls_MxLmJQ6dh3iNuHJ_Q79Ar1Zf8_X=aoHg@mail.gmail.com>
References: <1df3c1a0-d673-94c0-7a3a-bd733196d24d@phrozen.org>
 <03a2c475-a60b-f6c8-a80a-93e657ff7e43@hauke-m.de>
 <9253a3fd-a056-4616-afa5-027863107d8b@universe-factory.net>
 <f42e927c-0869-08e7-4610-d0aaf328ac4c@ntlworld.com>
 <CABL_Pd_9F+mw_f3Ls_MxLmJQ6dh3iNuHJ_Q79Ar1Zf8_X=aoHg@mail.gmail.com>
Message-ID: <nycvar.QRO.7.76.6.1705111251160.16029@qynat-yncgbc>

On Thu, 11 May 2017, Martin Tippmann wrote:

> On Thu, May 11, 2017 at 5:27 PM, tapper <j.lancett at ntlworld.com> wrote:
>> On 11/05/2017 09:30, Matthias Schiffer wrote:
>>>
>>> The OpenWrt forum design looks a bit better than the landing page, but it
>>> still feels too heavy due to the colored backgrounds.
>>>
>>> Matthias
>
>> One more thing about the LEDE forum is it is very hard to use with a screen
>> reader where as the OpenWRT one is very good to use. For all blind people
>> could we stick with the Openwrt forum but spruce it up a bit so it looks
>> better for those of us that can see.
>
> Hi, the used Discourse Software sadly does not seem to make screen
> readers a priority :(, but they seem interested in feedback[0]
>
> Just an idea: Would NNTP Support help here? There seems to be a
> maintained plugin[1] and if that works well enough, access via any
> NNTP client or a simple site / forum like the dlang forum[3] that
> plays well with linux and screen readers might be an option.

The LEDE forum lets you interact with it strictly via e-mail, while the openwrt 
forum only has 'something is new' notifications via e-mail

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

From arunkumar.1993.2050 at gmail.com  Fri May 12 11:30:18 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Fri, 12 May 2017 21:00:18 +0530
Subject: [OpenWrt-Devel] GSOC 2017 - Implement NetJSON output in ubus
 (OpenWRT/LEDE) - Progress Report 1
Message-ID: <CAO4+10OZadT_HZzb+nu0GxitM-GLyr9oAn3YYv2goHTnzyBE7A@mail.gmail.com>

Hi Mentors and Developer community,

This is the 1st week's progress report of the project:
Implement NetJSON output in ubus (OpenWRT/LEDE)

1. To make myself familiar with the LEDE built an image without any
changes and loaded into the Raspberry Pi3.
2. Compiled SCAL package and understood its working.
3. Added a new CLI in the ubus architecture to get the inputs and call
dummy backend APIs.
"ubus call netjson config"
4. netjson namespace is registered in the libubus to support the above.

To be done next week:

1. Refine the timeline in the proposal [1] and update it in the
Friefunk blogpost.
2. Make the CLI to support other inputs as mentioned in [1] as a
separate function rather than exisiting ubus CLI functions which I
have implemented now.
3. Understand more about the json schema in the SCAL plugins and try
to add NetJSON schema to that.

[1] https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing

Thanks,
Arun
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon May 15 13:07:35 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 May 2017 19:07:35 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2 v2] reset: Add a Gemini reset
	controller
In-Reply-To: <1494593270.2965.5.camel@pengutronix.de>
References: <20170508200740.26194-1-linus.walleij@linaro.org>
 <1494593270.2965.5.camel@pengutronix.de>
Message-ID: <CACRpkdbjFgCJwjZ8j8XfmOEDqQYHZdLNoswgfC83yAoTdyyz_g@mail.gmail.com>

On Fri, May 12, 2017 at 2:47 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> On Mon, 2017-05-08 at 22:07 +0200, Linus Walleij wrote:
>> The Cortina Systems Gemini reset controller is a simple
>> 32bit register with self-deasserting reset lines. It is
>> accessed using regmap over syscon.
>>
>> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Add an explicit GPL license statement.
>> - Move the reset controller to be identical to the sycon
>>   node, no need to a separate child node for this.
>> - Drop unneeded struct device *dev pointer from state
>>   container.
>> - Print error code on missing regmap.
>> - Use #define from the <dt-bindings/*> to indicate that we
>>   always set the CPU1 reset line to 1 when writing the
>>   resets.
>
> Thank you, looks good to me. I'll include this with the next pull
> request after v4.12-rc1 is released.

I have to repost it because Rob requested that the reset
controller and clock controller be probed directly from the
system controller without any special reset/clock nodes.

I was planning to ask you to ACK it for merge through
ARM SoC instead: as it uses the <dt-bindings/*> things
and that needs to be there to work with the DTS files, we
either need to merge this wholesome through ARM SoC,
or we apply the binding patch into all three trees
(either works with me).

I'll post a v3 so we can discuss.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From denis.osvald at sartura.hr  Thu May 18 03:39:28 2017
From: denis.osvald at sartura.hr (Denis Osvald)
Date: Thu, 18 May 2017 09:39:28 +0200
Subject: [OpenWrt-Devel] [PATCH libubox] json_script: enable custom expr
	handler callback
Message-ID: <20170518073928.22437-1-denis.osvald@sartura.hr>

This wires in custom expression handler functionality, which was present
in json script since the original version, but never used.

Signed-off-by: Denis Osvald <denis.osvald at sartura.hr>
---
 json_script.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/json_script.c b/json_script.c
index 463aac8..8894901 100644
--- a/json_script.c
+++ b/json_script.c
@@ -415,8 +415,10 @@ static int json_process_expr(struct json_call *call, struct blob_attr *cur)
 	}
 
 	ret = __json_process_type(call, cur, expr, ARRAY_SIZE(expr), &found);
-	if (!found)
-		ctx->handle_error(ctx, "Unknown expression type", cur);
+	if (!found) {
+		const char *name = blobmsg_data(blobmsg_data(cur));
+		ctx->handle_expr(ctx, name, cur, call->vars);
+	}
 
 	return ret;
 }
-- 
2.12.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From denis.osvald at sartura.hr  Thu May 18 03:57:56 2017
From: denis.osvald at sartura.hr (Denis Osvald)
Date: Thu, 18 May 2017 09:57:56 +0200
Subject: [OpenWrt-Devel] [PATCH libubox] json_script: enable custom expr
	handler callback
In-Reply-To: <20170518073928.22437-1-denis.osvald@sartura.hr>
References: <20170518073928.22437-1-denis.osvald@sartura.hr>
Message-ID: <08203d78-5a7d-7cb9-f52d-2a8d387844e9@sartura.hr>

On 2017-05-18 09:39, Denis Osvald wrote:
> This wires in custom expression handler functionality, which was
> present in json script since the original version, but never used.

To add a bit of context:

Experimenting with procd service triggers, it was noticed that when
adding triggers for a network interface, trigger is activated too often.
I saw discussions related to both netifd (as sender of network interface
trigger events) and procd side of the problem a few times during past
months on the list, e.g.:

http://lists.infradead.org/pipermail/lede-dev/2017-April/007065.html
http://lists.infradead.org/pipermail/lede-dev/2017-April/007162.html
http://lists.infradead.org/pipermail/lede-dev/2017-March/006927.html

Quote from the last link:
> be nice if [...] there were ways to be better refine the interface 
> triggers to only a true interface reconfiguration

As one way of solving the problem, I wanted to make a trigger-handling
json_script which itself would check the trigger details, and decide
whether the event was relevant enough to warrant a reload. I tried this
via a patch to procd:

http://public.inteno.se/?p=iopsys.git;a=commitdiff;h=3cdd8f80433e21eacfb593e69361e8f217aba30c

However, json_script turned out not to support custom expression
handlers, hence this patch.

Regards,

Denis
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arunkumar.1993.2050 at gmail.com  Fri May 19 10:31:32 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Fri, 19 May 2017 20:01:32 +0530
Subject: [OpenWrt-Devel] GSOC 2017 - Implement NetJSON output in ubus
 (OpenWRT/LEDE) - Progress Report 2
Message-ID: <CAO4+10MpAOk=ThfZQwDR_yMjW4icLicb=XhZOYkKuEPGT3Jq9A@mail.gmail.com>

Hi Mentors and Developer Community,

This is the 2nd week's progress report of the project:
Implement NetJSON output in ubus (OpenWRT/LEDE)

1. Refined the timeline of the proposal and updated.
2. CLI is made to support other inputs as in [1] but the backend
functions havent been implemented.
3. Efforts made to understand the json schema of SCAL plugin. Added
debugs inside the code to know more about the working of JSON schema.

To be done next week:
1. As per Felix's comment, make the ubus object to support those data
models which are not supported in the SCAL module. Efforts to
understand the scope of this in detail is required as its critical for
completion of the project.
2. Commit the code changes made till now to the github public repository.

[1] https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing

Thanks,
Arun
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Fri May 19 14:17:07 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Fri, 19 May 2017 20:17:07 +0200
Subject: [OpenWrt-Devel] [PATCH 1/2] firmware: add firmware for rtl8821ae
	support
Message-ID: <20170519181708.16126-1-ulli.kroll@googlemail.com>

add needed firmware to support rtl8821ae pcie adapter

Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>
---
 package/firmware/linux-firmware/realtek.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/package/firmware/linux-firmware/realtek.mk b/package/firmware/linux-firmware/realtek.mk
index 8c3770eeea..fdd92c9a42 100644
--- a/package/firmware/linux-firmware/realtek.mk
+++ b/package/firmware/linux-firmware/realtek.mk
@@ -55,3 +55,11 @@ define Package/rtl8192su-firmware/install
 	$(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8712u.bin $(1)/lib/firmware/rtlwifi
 endef
 $(eval $(call BuildPackage,rtl8192su-firmware))
+
+Package/rtl8821ae-firmware = $(call Package/firmware-default,RealTek RTL8821AE firmware)
+define Package/rtl8821ae-firmware/install
+	$(INSTALL_DIR) $(1)/lib/firmware/rtlwifi
+	$(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw.bin $(1)/lib/firmware/rtlwifi
+	$(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw_wowlan.bin $(1)/lib/firmware/rtlwifi
+endef
+$(eval $(call BuildPackage,rtl8821ae-firmware))
-- 
2.13.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Fri May 19 14:17:08 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Fri, 19 May 2017 20:17:08 +0200
Subject: [OpenWrt-Devel] [PATCH 2/2] mac80211: add support for rtl8821ae
	pcie adapter
In-Reply-To: <20170519181708.16126-1-ulli.kroll@googlemail.com>
References: <20170519181708.16126-1-ulli.kroll@googlemail.com>
Message-ID: <20170519181708.16126-2-ulli.kroll@googlemail.com>

Add support for Realtek RTL8821AE/RTL8812AE PCIe adapter.
This device supports 802.11ac and bluetooth

testet on PC Engines APU with AP and STA mode

Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>
---
 package/kernel/mac80211/Makefile | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index fb72a892f9..71aae89360 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -42,8 +42,8 @@ PKG_DRIVERS = \
 	rt2800-lib rt2800-mmio rt2800-pci rt2800-soc rt2800-usb \
 	rt61-pci rt73-usb \
 	rtl8180 rtl8187 \
-	rtlwifi rtlwifi-pci rtlwifi-usb rtl8192c-common rtl8192ce rtl8192se \
-	rtl8192de rtl8192cu \
+	rtlwifi rtlwifi-pci rtlwifi-btcoexist rtlwifi-usb rtl8192c-common \
+	rtl8192ce rtl8192se rtl8192de rtl8192cu rtl8821ae \
 	rtl8xxxu \
 	wlcore wl12xx wl18xx \
 	zd1211rw
@@ -1314,6 +1314,15 @@ define KernelPackage/rtlwifi-pci
   HIDDEN:=1
 endef
 
+define KernelPackage/rtlwifi-btcoexist
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=Realtek BT coexist support
+  DEPENDS+= +kmod-rtlwifi
+  FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtlwifi/btcoexist/btcoexist.ko
+  AUTOLOAD:=$(call AutoProbe,btcoexist)
+  HIDDEN:=1
+endef
+
 define KernelPackage/rtlwifi-usb
   $(call KernelPackage/mac80211/Default)
   TITLE:=Realtek common driver part (USB support)
@@ -1363,6 +1372,13 @@ define KernelPackage/rtl8192cu
   AUTOLOAD:=$(call AutoProbe,rtl8192cu)
 endef
 
+define KernelPackage/rtl8821ae
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=Realtek RTL8821AE support
+  DEPENDS+= +kmod-rtlwifi-btcoexist +kmod-rtlwifi-pci +rtl8821ae-firmware
+  FILES:= $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/rtl8821ae.ko
+  AUTOLOAD:=$(call AutoProbe,rtl8821ae)
+endef
 
 define KernelPackage/rtl8xxxu
   $(call KernelPackage/mac80211/Default)
@@ -1627,12 +1643,14 @@ config-$(call config_package,zd1211rw) += ZD1211RW
 
 config-$(call config_package,rtlwifi) += RTL_CARDS RTLWIFI
 config-$(call config_package,rtlwifi-pci) += RTLWIFI_PCI
+config-$(call config_package,rtlwifi-btcoexist) += RTLBTCOEXIST
 config-$(call config_package,rtlwifi-usb) += RTLWIFI_USB
 config-$(call config_package,rtl8192c-common) += RTL8192C_COMMON
 config-$(call config_package,rtl8192ce) += RTL8192CE
 config-$(call config_package,rtl8192se) += RTL8192SE
 config-$(call config_package,rtl8192de) += RTL8192DE
 config-$(call config_package,rtl8192cu) += RTL8192CU
+config-$(call config_package,rtl8821ae) += RTL8821AE
 config-$(CONFIG_PACKAGE_RTLWIFI_DEBUG) += RTLWIFI_DEBUG
 
 config-$(call config_package,rtl8xxxu) += RTL8XXXU
@@ -1835,12 +1853,14 @@ $(eval $(call KernelPackage,rtl8180))
 $(eval $(call KernelPackage,rtl8187))
 $(eval $(call KernelPackage,rtlwifi))
 $(eval $(call KernelPackage,rtlwifi-pci))
+$(eval $(call KernelPackage,rtlwifi-btcoexist))
 $(eval $(call KernelPackage,rtlwifi-usb))
 $(eval $(call KernelPackage,rtl8192c-common))
 $(eval $(call KernelPackage,rtl8192ce))
 $(eval $(call KernelPackage,rtl8192se))
 $(eval $(call KernelPackage,rtl8192de))
 $(eval $(call KernelPackage,rtl8192cu))
+$(eval $(call KernelPackage,rtl8821ae))
 $(eval $(call KernelPackage,rtl8xxxu))
 $(eval $(call KernelPackage,wlcore))
 $(eval $(call KernelPackage,wl12xx))
-- 
2.13.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat May 20 13:56:34 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 May 2017 19:56:34 +0200
Subject: [OpenWrt-Devel] [PATCH 4/6] dma: pl08x: Add support for Faraday
	Technology FTDMAC020
In-Reply-To: <20170514123418.GH6263@localhost>
References: <20170408120457.22750-1-linus.walleij@linaro.org>
 <20170408120457.22750-4-linus.walleij@linaro.org>
 <20170514123418.GH6263@localhost>
Message-ID: <CACRpkdYm4LERyxi6jHkJMGB-D4JrE6oYcdSM_s_fW0jfHpso+A@mail.gmail.com>

On Sun, May 14, 2017 at 2:34 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> On Sat, Apr 08, 2017 at 02:04:55PM +0200, Linus Walleij wrote:
>
>> +#define FTDMAC020_CH_CSR_FIFOTH_MSK          (0x7 << 24)
>
> IIUC we can have a GENMASK(27, 25), won't that be a bit better here and
> other places?

I will send an additional patch at the end of the series switching *all*
of these to use GENMASK() so we keep it to one technical step
per patch, OK?

>> +#define FTDMAC020_CH_CSR_FIFOTH_SHIFT                (24)
>
> and you may use ffs(FTDMAC020_CH_CSR_FIFOTH_MSK) or keep a shift define

I'm more convenient with the shift at least here.

ffs(DEFINE) makes me thin ffs() is a function invoked all the
time even if I know very well the compiler will mangle it into
a constant... just confusing for my perception.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From f.fainelli at gmail.com  Sat May 20 14:39:33 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 May 2017 11:39:33 -0700
Subject: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
In-Reply-To: <8f4afb8e-7e98-d59f-abb6-64190ed717f5@nod.at>
References: <8f4afb8e-7e98-d59f-abb6-64190ed717f5@nod.at>
Message-ID: <3dcf8aac-5b84-8ced-fcf1-9fe026861cd6@gmail.com>

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 | <BLOCK_NO> | 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ralph.sennhauser at gmail.com  Sat May 20 15:36:54 2017
From: ralph.sennhauser at gmail.com (Ralph Sennhauser)
Date: Sat, 20 May 2017 21:36:54 +0200
Subject: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
In-Reply-To: <3dcf8aac-5b84-8ced-fcf1-9fe026861cd6@gmail.com>
References: <8f4afb8e-7e98-d59f-abb6-64190ed717f5@nod.at>
 <3dcf8aac-5b84-8ced-fcf1-9fe026861cd6@gmail.com>
Message-ID: <20170520213654.6b6d18eb@gmail.com>

On Sat, 20 May 2017 11:39:33 -0700
Florian Fainelli <f.fainelli at gmail.com> wrote:

> 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.
> 

There is also the size consideration. Unless a seeded ubifs can get
close to squashfs in terms of compression there would still be a
use-case for squashfs with an ubifs overlay. My current root as ubifs
instead of squashfs is 76.8% bigger.

> > 
> > 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 | <BLOCK_NO> | 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/
> >   
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ralph.sennhauser at gmail.com  Sat May 20 17:04:19 2017
From: ralph.sennhauser at gmail.com (Ralph Sennhauser)
Date: Sat, 20 May 2017 23:04:19 +0200
Subject: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
In-Reply-To: <aa843f51-b037-5a09-28f4-f0b7b5396ce5@nod.at>
References: <8f4afb8e-7e98-d59f-abb6-64190ed717f5@nod.at>
 <3dcf8aac-5b84-8ced-fcf1-9fe026861cd6@gmail.com>
 <20170520213654.6b6d18eb@gmail.com>
 <aa843f51-b037-5a09-28f4-f0b7b5396ce5@nod.at>
Message-ID: <20170520230419.30d4e496@gmail.com>

Hi Richard,

On Sat, 20 May 2017 21:57:36 +0200
Richard Weinberger <richard at nod.at> wrote:

> Ralph,
> 
> Am 20.05.2017 um 21:36 schrieb Ralph Sennhauser:
> >>> 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.
> >>  
> > 
> > There is also the size consideration. Unless a seeded ubifs can get
> > close to squashfs in terms of compression there would still be a
> > use-case for squashfs with an ubifs overlay. My current root as
> > ubifs instead of squashfs is 76.8% bigger.  
> 
> You seem to misunderstand this feature, the goal is not to void all
> uses of squashfs.
> I'm pretty sure for the LEDE usecase squashfs is the better choice.

Probably depends on the device but is beyond the point. Just wanted to
mention in response to the main point being the factory reset of the
squashfs + ubifs overlay setup that size is just as important or even
more important at least for some.

Whether you want to implement and maintain another solution to the
factory reset problem in ubifs which falls short of full snapshot
support is up to you.

Ralph
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ralph.sennhauser at gmail.com  Sun May 21 08:23:36 2017
From: ralph.sennhauser at gmail.com (Ralph Sennhauser)
Date: Sun, 21 May 2017 14:23:36 +0200
Subject: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
In-Reply-To: <b193086e-322b-16a6-0306-5d9c47068872@nod.at>
References: <8f4afb8e-7e98-d59f-abb6-64190ed717f5@nod.at>
 <3dcf8aac-5b84-8ced-fcf1-9fe026861cd6@gmail.com>
 <20170520213654.6b6d18eb@gmail.com>
 <CAMuHMdXQ4Tc92njixXKiP_JgasvgFELR15hqFpk4DjvfT453EQ@mail.gmail.com>
 <b193086e-322b-16a6-0306-5d9c47068872@nod.at>
Message-ID: <20170521142336.6bdc8782@gmail.com>

Hi Richard

On Sun, 21 May 2017 10:40:05 +0200
Richard Weinberger <richard at nod.at> wrote:

> Geert,
> 
> Am 21.05.2017 um 10:37 schrieb Geert Uytterhoeven:
> > On Sat, May 20, 2017 at 9:36 PM, Ralph Sennhauser
> > <ralph.sennhauser at gmail.com> wrote:  
> >> There is also the size consideration. Unless a seeded ubifs can get
> >> close to squashfs in terms of compression there would still be a
> >> use-case for squashfs with an ubifs overlay. My current root as
> >> ubifs instead of squashfs is 76.8% bigger.  
> > 
> > As seeded files are stored and kept unmodified, they could be
> > stored in compressed form?  
> 
> This is what UBIFS already does.

Right, or it would be some 400-500% difference.

Another advantage of the squashfs with overlay came to mind. OpenWrt
doesn't do a factory reset per se but boots into a "failsafe" mode which
just doesn't mount the overlay. This allows to fix the overlay (some
screwed up config value which prevents connection) or to reset the
password for example without having to reinstall packages and
reconfigure the device from ground up. Wiping the overlay is basically
the last resort.

With the expectation distributions to use the same approach for as many
devices possible I see the seeded ubifs running out of users fast. Some
commercial vendor backporting it to a 3.10 kernel maybe?

If the seeded ubifs could be generalized to snapshot support ala btrfs
that would change things a lot as it would enable uses far beyond just
factory reset. No idea how feasible that is but might be worth
considering instead.

Ralph

> 
> Thanks,
> //richard
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 22 03:40:46 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 22 May 2017 09:40:46 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
Message-ID: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>

Hi,

here is a V2 of the remerge proposal, I tried to fold all the comments 
people made into it, if anything is missing let me know.


         John

*) 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
- nominate a new liaison team (imre and john offer to do this, if anyone 
else is interested let us know)
- inform SPI of the new liaisons, voters and project rules
- this should be done early in the remerge process s.t. the domains can 
be handed over

*) github
- 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
- obsolete the lede github org after a grace period of 3-6 months

*) landing page
- add a letter of intent / notice to both current landing pages 
announcing the remerge
- 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
- try to find some design guru that will transform the owrt theme to one 
appropriate to this century

*) 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 (the 3 
owrt devs would like to keep theirs active)
- 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
- send out invitation mails to the new list
- setup redirect/auto-reply for the existing lists

*) trademark/sponsorship policy
- review/ack imres trademark policy (https://openwrt.org/trademark)
- review/ack jows sponsorship policy (link pending)

*) timeline
- vote / agree on the proposal within the next week
- work on the action items in the 4 weeks after that

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

From dasswapnil96 at gmail.com  Mon May 22 04:48:50 2017
From: dasswapnil96 at gmail.com (SWAPNIL DAS)
Date: Mon, 22 May 2017 16:48:50 +0800
Subject: [OpenWrt-Devel] Help for updating kernel drivers
Message-ID: <CADCBap0eL40e=YjiofL-97cONv3sJ5XP0LyAx9OjeDroLQY6sA@mail.gmail.com>

Hello,

If anyone can help me to figure out a way by which I can modify a driver of
linux kernel and make the change reflect in the router.

Till now I tried to download the tarballs by "make download" then I
inserted a print statement on one of the drivers and then used "make" to
build the image. Finally when I dmesg on the router the print statement
doesn't work. I think my code has been overwritten when "make" is called.

Please give some advice on how to do that.

Thanks
Swapnil Das
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170522/f47c3e12/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From zajec5 at gmail.com  Mon May 22 05:02:36 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 22 May 2017 11:02:36 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
In-Reply-To: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
Message-ID: <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>

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?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From j.lancett at ntlworld.com  Mon May 22 05:18:51 2017
From: j.lancett at ntlworld.com (tapper)
Date: Mon, 22 May 2017 10:18:51 +0100
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
In-Reply-To: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
Message-ID: <10d54a47-876b-455a-b98e-8728c76a5226@ntlworld.com>

Sounds good to me!

On 22/05/2017 08:40, John Crispin wrote:
> Hi,
> 
> here is a V2 of the remerge proposal, I tried to fold all the comments 
> people made into it, if anything is missing let me know.
> 
> 
>          John
> 
> *) 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
> - nominate a new liaison team (imre and john offer to do this, if anyone 
> else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can 
> be handed over
> 
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages 
> announcing the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to one 
> appropriate to this century
> 
> *) 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 (the 3 
> owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark/sponsorship policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> - review/ack jows sponsorship policy (link pending)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>      John
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From zajec5 at gmail.com  Mon May 22 05:27:56 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 22 May 2017 11:27:56 +0200
Subject: [OpenWrt-Devel] Factory startup issues since mount_root /
 libfstools improvements in Chaos Calmer
In-Reply-To: <CACna6rwrm6eS-nGfepNeAU1LX_88WUMpLPuPip9nzyyj+oyX=g@mail.gmail.com>
References: <1b0f8ebd7c9748d099aea99949d7ffb8@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwkx+ypoHeVDUrcsDK7frOXMXOfjvpRhQvwJMb_9YNUtA@mail.gmail.com>
 <41c1b8bc4cf44d90a88d68faf0ca233c@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b9e3c74a-8439-fb49-c53d-c9a23beb0ba7@gmail.com>
 <4818aa28546948458468163f7200512e@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <b560f9382a1e4953903be989fe42bdb3@VI1PR9003MB0253.MGDPHG.emi.philips.com>
 <CACna6rwrm6eS-nGfepNeAU1LX_88WUMpLPuPip9nzyyj+oyX=g@mail.gmail.com>
Message-ID: <CACna6rz3brN7g3QRkA+i24BNAoEx-eLrkEeb571+C36jgxY8Eg@mail.gmail.com>

On 9 May 2017 at 10:24, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> On 8 May 2017 at 13:43, Smith, Pieter <pieter.smith at philips.com> wrote:
>> I am still hoping to get confirmation from you on this patch. Is this acceptable for upstreaming?
>>
>>> Hi Rafa?,
>>>
>>> > > On 03/29/2017 11:53 AM, Smith, Pieter wrote:
>>> > > > My apologies. I am not able to get mutt working with our corporate
>>> > > > infrastructure. I hope it arrives unmangled as an attachment. If
>>> > > > not, I'll use my personal mail.
>>> > >
>>> > > This would be acceptable for me to pick patch sent as attachment,
>>> > > but you really need to sign it off with your name. Please add a
>>> > > proper
>>> > > Signed-off-by:
>>> > > line and resend.
>>> >
>>> > Off-course! My bad...
>>>
>>> In adding more logging so that you can diagnose the issue, I tracked down the root cause and fixed the issue. Attached, > please find an updated patch with sign-off and a problem description.
>
> Sorry, it took me more time than it was supposed to. Your patch went
> into the fstools repository.
>
> 1) LEDE master branch
> We'll bump package after fixing regression caused by commit
> a19f2b3c21288 ("build: disable the format-truncation warning error to
> fix gcc 7 build errors") which results in:
> cc1: error: -Werror=format-truncation: no option -Wformat-truncation

commit 65a3dc277f3f4 ("fstools: update to the latest version")


> 2) LEDE lede-17.01 branch:
> I sent patch to backport your fix:
> https://patchwork.ozlabs.org/patch/759957/

commit 0bef8f8011d11 ("fstools: backport regression fix for volume_identify")


> 3) OpenWrt 15.05 branch:
> I don't really want to mess with that. I don't know if I have
> privileges nor if my patch could be accepted. We need someone working
> on OpenWrt to handle this.

-- 
Rafa?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 22 06:10:34 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 22 May 2017 12:10:34 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
Message-ID: <a08fd293-f0d3-da54-5bb9-382947cbd195@phrozen.org>



On 22/05/17 11:02, 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?
>
i'll add it to V3

> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 22 06:11:08 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 22 May 2017 12:11:08 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <CAHjZ2x5u35XgcAaFdh0KekODDE_DwwpnsLxCqkWxFwMqHGWfVQ@mail.gmail.com>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <10d54a47-876b-455a-b98e-8728c76a5226@ntlworld.com>
 <CAHjZ2x5u35XgcAaFdh0KekODDE_DwwpnsLxCqkWxFwMqHGWfVQ@mail.gmail.com>
Message-ID: <b9e26a21-f92a-dc6a-5fc7-e5a1964583e7@phrozen.org>



On 22/05/17 11:39, Vincenzo Romano wrote:
> I also agree to everything.
> With am extra point.
>
> 2017-05-22 11:18 GMT+02:00 tapper <j.lancett at ntlworld.com>:
>>> *) SPI
>>> - nominate a new liaison team (imre and john offer to do this, if anyone
>>> else is interested let us know)
>>> - inform SPI of the new liaisons, voters and project rules
>>> - this should be done early in the remerge process s.t. the domains can be
>>> handed over
> There needs a way to be able to enlarge that team at any time by vote.
> And expunging a member out should be subjected to a vote too.
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

covered by the lede rules that will become the new owrt rules.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From toke at toke.dk  Mon May 22 06:22:39 2017
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 22 May 2017 12:22:39 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <b9e26a21-f92a-dc6a-5fc7-e5a1964583e7@phrozen.org> (John
 Crispin's message of "Mon, 22 May 2017 12:11:08 +0200")
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <10d54a47-876b-455a-b98e-8728c76a5226@ntlworld.com>
 <CAHjZ2x5u35XgcAaFdh0KekODDE_DwwpnsLxCqkWxFwMqHGWfVQ@mail.gmail.com>
 <b9e26a21-f92a-dc6a-5fc7-e5a1964583e7@phrozen.org>
Message-ID: <87k259xkb4.fsf@alrua-kau>

John Crispin <john at phrozen.org> writes:

> the lede rules that will become the new owrt rules.

You may want to mention this fact in the merge proposal itself. What
would happen to the rules was one of the points that was unclear in the
first round, I believe... :)

-Toke
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From f.fainelli at gmail.com  Mon May 22 12:14:44 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 22 May 2017 09:14:44 -0700
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
In-Reply-To: <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
Message-ID: <6867a09e-432b-b74c-d95b-c3578a6b997a@gmail.com>

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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Mon May 22 13:11:39 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Mon, 22 May 2017 10:11:39 -0700
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <a08fd293-f0d3-da54-5bb9-382947cbd195@phrozen.org>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
 <a08fd293-f0d3-da54-5bb9-382947cbd195@phrozen.org>
Message-ID: <9632c3f2-8a84-f0ee-64d3-32bad1450e34@openwrt.org>

Hi,

On 2017-05-22 03:10, John Crispin wrote:
>
>
> On 22/05/17 11:02, 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?
>>
> i'll add it to V3
Sorry Rafal, don't get me wrong but this isn't true. It might haven't 
been documented well (like quite a few things) but you have been told 
years ago: everyone who has a project cloak has access to everything. 
What have been refused is to make a special exception just for you to 
get it without that.


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

From wigyori at uid0.hu  Tue May 23 11:29:10 2017
From: wigyori at uid0.hu (Zoltan HERPAI)
Date: Tue, 23 May 2017 17:29:10 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
In-Reply-To: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
Message-ID: <59245546.8000106@uid0.hu>

Hi John,

John Crispin wrote:
> here is a V2 of the remerge proposal, I tried to fold all the comments 
> people made into it, if anything is missing let me know.
[snip]

Please let us know when you'll start a final vote on this proposal, or 
if you want to wait a few days if anything bumps in for a V3. I'm OK 
with this, thanks for putting it together.

Thanks,
Zoltan H
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Tue May 23 11:41:47 2017
From: john at phrozen.org (John Crispin)
Date: Tue, 23 May 2017 17:41:47 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V2
In-Reply-To: <59245546.8000106@uid0.hu>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <59245546.8000106@uid0.hu>
Message-ID: <0e5e92c7-d008-00ad-ca9c-9e0dba99c922@phrozen.org>



On 23/05/17 17:29, Zoltan HERPAI wrote:
> Hi John,
>
> John Crispin wrote:
>> here is a V2 of the remerge proposal, I tried to fold all the 
>> comments people made into it, if anything is missing let me know.
> [snip]
>
> Please let us know when you'll start a final vote on this proposal, or 
> if you want to wait a few days if anything bumps in for a V3. I'm OK 
> with this, thanks for putting it together.
>
> Thanks,
> Zoltan H
>
i plan to send a V3 later today or early tomorrow. i hope that we can 
vote on V3 and get things moving

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

From hauke at hauke-m.de  Tue May 23 16:42:02 2017
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 23 May 2017 22:42:02 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
Message-ID: <3fbf0a37-6851-0c8a-35a6-35321f50f8ea@hauke-m.de>

On 05/22/2017 09:40 AM, John Crispin wrote:
> Hi,
> 
> here is a V2 of the remerge proposal, I tried to fold all the comments
> people made into it, if anything is missing let me know.
> 
> 
>         John

.....

> *) SPI
> - nominate a new liaison team (imre and john offer to do this, if anyone
> else is interested let us know)

I am ok with you both representing us at the SPI. Is a majority vote
needed (LEDE rules) to put someone else into this position, or what
would be the process? ;-)

> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can
> be handed over

....

> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3
> owrt devs would like to keep theirs active)
> - 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

I am fine with forwarding the mails send to the personal accounts to
some other mail address of that person for the next years.

....
> 
> *) trademark/sponsorship policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> - review/ack jows sponsorship policy (link pending)

As the sponsorship policy is not ready can you remove it from the
remerge proposal and we can talk about it later.

> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>     John
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Wed May 24 04:45:30 2017
From: john at phrozen.org (John Crispin)
Date: Wed, 24 May 2017 10:45:30 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <3fbf0a37-6851-0c8a-35a6-35321f50f8ea@hauke-m.de>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <3fbf0a37-6851-0c8a-35a6-35321f50f8ea@hauke-m.de>
Message-ID: <3aca8a4a-b899-8e1c-6c5a-789fd0f64ba2@phrozen.org>



On 23/05/17 22:42, Hauke Mehrtens wrote:
> On 05/22/2017 09:40 AM, John Crispin wrote:
>> Hi,
>>
>> here is a V2 of the remerge proposal, I tried to fold all the comments
>> people made into it, if anything is missing let me know.
>>
>>
>>          John
> .....
>
>> *) SPI
>> - nominate a new liaison team (imre and john offer to do this, if anyone
>> else is interested let us know)
> I am ok with you both representing us at the SPI. Is a majority vote
> needed (LEDE rules) to put someone else into this position, or what
> would be the process? ;-)

this would be handled by our normal voting system
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Wed May 24 05:01:33 2017
From: john at phrozen.org (John Crispin)
Date: Wed, 24 May 2017 11:01:33 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V2
In-Reply-To: <20E3D3BD-BB67-420E-B2E4-B8AE9C231C5B@gmail.com>
References: <092210eb-265e-a32b-85f8-906364c31802@phrozen.org>
 <9fdcfb61-eadd-a85d-a353-2555f4b9c182@gmail.com>
 <a08fd293-f0d3-da54-5bb9-382947cbd195@phrozen.org>
 <9632c3f2-8a84-f0ee-64d3-32bad1450e34@openwrt.org>
 <20E3D3BD-BB67-420E-B2E4-B8AE9C231C5B@gmail.com>
Message-ID: <4ec9801b-129f-d05a-5fe1-02e817ed1391@phrozen.org>



On 24/05/17 10:13, Paul Oranje wrote:
> Who are/will be entitled to an [IRC] project cloak ?
> Paul
people with voting rights and probably also regular contributors ... 
that is however unrelated to the remerge discussion and would fall under 
the normal voting system



>> Op 22 mei 2017, om 19:11 heeft Imre Kaloz <kaloz at openwrt.org> het volgende geschreven:
>>
>> Hi,
>>
>> On 2017-05-22 03:10, John Crispin wrote:
>>>
>>> On 22/05/17 11:02, 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?
>>>>
>>> i'll add it to V3
>> Sorry Rafal, don't get me wrong but this isn't true. It might haven't been documented well (like quite a few things) but you have been told years ago: everyone who has a project cloak has access to everything. What have been refused is to make a special exception just for you to get it without that.
>>
>>
>> Imre
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arunkumar.1993.2050 at gmail.com  Fri May 26 11:27:06 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Fri, 26 May 2017 20:57:06 +0530
Subject: [OpenWrt-Devel] GSOC 2017 - Implement NetJSON output in ubus
 (OpenWRT/LEDE) - Progress Report 2
Message-ID: <CAO4+10O08dN=WjpxyMWCNmjnwg8x-krFtvToVYwotjqc6n_OMg@mail.gmail.com>

Hi Mentors and Developer Community,

This is the 3rd week's progress report of the project:
Implement NetJSON output in ubus (OpenWRT/LEDE)

1. Updated proposal can be found at [1].
2. Sample function to convert the output of JSON to NetJSON was
implemented.
3. Nodewatcher agent code was analyzed to identify functions which are
going to be used for DeviceMonitoring netjson object.
4. Added a function to block the SCAL output and instead use 2.

Plan from Next week till completion of project(unless there is a planned
delay):
1. 40 hours per week.
2. Daily reports to Mentors would be sent at IST 8PM.
3. Discussion with available mentors on Tuesday and Thursday.
4. Submit patch for review by Thursday IST 9PM.

[1] https://docs.google.com/document/d/1b6zersOA_
GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing

Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170526/c428bfe6/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 29 02:56:08 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 29 May 2017 08:56:08 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
Message-ID: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>

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.


         John

*) rules
- owrt will adopt the lede rules and voting system

*) 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
- nominate a new liaison team (imre and john offer to do this, if anyone 
else is interested let us know)
- inform SPI of the new liaisons, voters and project rules
- this should be done early in the remerge process s.t. the domains can 
be handed over

*) github
- 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
- obsolete the lede github org after a grace period of 3-6 months

*) landing page
- add a letter of intent / notice to both current landing pages 
announcing the remerge
- 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
- try to find some design guru that will transform the owrt theme to one 
appropriate to this century

*) 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

*) IRC
- add back cloaking
- give people channel ownership/admin rights

*) email accounts
- currently there are around ~20 active openwrt.org mail accounts (the 3 
owrt devs would like to keep theirs active)
- 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
- send out invitation mails to the new list
- setup redirect/auto-reply for the existing lists

*) trademark policy
- review/ack imres trademark policy (https://openwrt.org/trademark)

*) timeline
- vote / agree on the proposal within the next week
- work on the action items in the 4 weeks after that

     John



_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/f5280a07/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 29 03:03:57 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 29 May 2017 09:03:57 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
Message-ID: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>

(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.


         John

*) rules
- owrt will adopt the lede rules and voting system

*) 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
- nominate a new liaison team (imre and john offer to do this, if anyone 
else is interested let us know)
- inform SPI of the new liaisons, voters and project rules
- this should be done early in the remerge process s.t. the domains can 
be handed over

*) github
- 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
- obsolete the lede github org after a grace period of 3-6 months

*) landing page
- add a letter of intent / notice to both current landing pages 
announcing the remerge
- 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
- try to find some design guru that will transform the owrt theme to one 
appropriate to this century

*) 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

*) IRC
- add back cloaking
- give people channel ownership/admin rights

*) email accounts
- currently there are around ~20 active openwrt.org mail accounts (the 3 
owrt devs would like to keep theirs active)
- 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
- send out invitation mails to the new list
- setup redirect/auto-reply for the existing lists

*) trademark policy
- review/ack imres trademark policy (https://openwrt.org/trademark)

*) timeline
- vote / agree on the proposal within the next week
- work on the action items in the 4 weeks after that

     John



_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May 29 03:55:17 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 29 May 2017 09:55:17 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>
References: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>
Message-ID: <CAKR_QV+TA-_gx7zjL22M93xRErtW-jWws8ur7epufRH00Gn9hg@mail.gmail.com>

On 29 May 2017 at 08:56, John Crispin <john at phrozen.org> 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.
>
> *) 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
>
>
>     John
>
>

I'd vote for re-enabling trac for all users, instead of wasting time and
resources on another flyspray instance or even existing one which compared
to trac does not bring any breakthrough features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/b28125f2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From jo at mein.io  Mon May 29 04:19:43 2017
From: jo at mein.io (Jo-Philipp Wich)
Date: Mon, 29 May 2017 10:19:43 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <CAKR_QV+TA-_gx7zjL22M93xRErtW-jWws8ur7epufRH00Gn9hg@mail.gmail.com>
References: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>
 <CAKR_QV+TA-_gx7zjL22M93xRErtW-jWws8ur7epufRH00Gn9hg@mail.gmail.com>
Message-ID: <766ce0ce-df93-6850-b9b0-88915c27d56d@mein.io>

Hi Tom,

> I'd vote for re-enabling trac for all users, instead of wasting time and
> resources on another flyspray instance or even existing one which
> compared to trac does not bring any breakthrough features.

Compared to Flyspray, Trac is a nightmare to administer. It leaks
resources like a sieve and tends to slow down to a crawl under load.

Regards,
Jo
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Mon May 29 04:39:31 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Mon, 29 May 2017 10:39:31 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <766ce0ce-df93-6850-b9b0-88915c27d56d@mein.io>
References: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>
 <CAKR_QV+TA-_gx7zjL22M93xRErtW-jWws8ur7epufRH00Gn9hg@mail.gmail.com>
 <766ce0ce-df93-6850-b9b0-88915c27d56d@mein.io>
Message-ID: <CAKR_QVJdkSDQM1iAQdjXo6camvhyMK5eNDzemJ26zr7erWjnug@mail.gmail.com>

> Compared to Flyspray, Trac is a nightmare to administer. It leaks
> resources like a sieve and tends to slow down to a crawl under load.
>
> Regards,
> Jo
>
>
Could you be more specific? I don't see how can it leak resources. About
slow down, have you ever chekced the server it is hosted on, or checked for
updates/fixes to trac software? If you consider spam comments as nightmare
to administer I don't understand why not assign someone to remove these as
soon as they're posted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/f74c35a8/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 29 04:46:06 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 29 May 2017 10:46:06 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <CAKR_QVJdkSDQM1iAQdjXo6camvhyMK5eNDzemJ26zr7erWjnug@mail.gmail.com>
References: <b3c97320-c241-606b-bdc5-560d3d026d67@phrozen.org>
 <CAKR_QV+TA-_gx7zjL22M93xRErtW-jWws8ur7epufRH00Gn9hg@mail.gmail.com>
 <766ce0ce-df93-6850-b9b0-88915c27d56d@mein.io>
 <CAKR_QVJdkSDQM1iAQdjXo6camvhyMK5eNDzemJ26zr7erWjnug@mail.gmail.com>
Message-ID: <7a14cb51-8a63-e0e0-6795-15201ad6006a@phrozen.org>



On 29/05/17 10:39, Tom Psyborg wrote:
>
>
>
>     Compared to Flyspray, Trac is a nightmare to administer. It leaks
>     resources like a sieve and tends to slow down to a crawl under load.
>
>     Regards,
>     Jo
>
>
> Could you be more specific? I don't see how can it leak resources. 
> About slow down, have you ever chekced the server it is hosted on, or 
> checked for updates/fixes to trac software? If you consider spam 
> comments as nightmare to administer I don't understand why not assign 
> someone to remove these as soon as they're posted.

please start a new thread if you want to discuss trac vs flyspray.

     John



>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From c.lobrano at gmail.com  Mon May 29 06:01:59 2017
From: c.lobrano at gmail.com (Carlo Lobrano)
Date: Mon, 29 May 2017 12:01:59 +0200
Subject: [OpenWrt-Devel]  Unable to connect with uqmi ("No effect")
Message-ID: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>

Hello,

Hope this is the right place to ask for help and my apologies if it is not.

I'm testing uqmi with a Telit LE910 LTE modem on Ubuntu 16.10, but I'm
facing this weird issue.
Uqmi considers the modem connected from the very beginning, even if I
haven't run --start-network yet and even if I use --set-autoconnect
disabled first, and when I try to connect with a different APN it replies
with "no effect"


    $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
    "connected"
    $ sudo uqmi -d /dev/cdc-wdm1 --set-autoconnect disabled
    $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
    "connected"
    $ sudo uqmi -d /dev/cdc-wdm1 --start-network web.omnitel.it
 --autoconnect
    "No effect"

I think that reason is the default bearer established at the attach (since
it's LTE), but I'm not sure how to overcome this and any hints would be
very appreciated.

Best regards,
Carlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/b9732dbb/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From jamie at onebillion.org  Mon May 29 06:11:14 2017
From: jamie at onebillion.org (Jamie Stuart)
Date: Mon, 29 May 2017 13:11:14 +0300
Subject: [OpenWrt-Devel]   [LEDE-DEV] Remerge logo ideas
Message-ID: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>

Hi,
First of all, I?m glad to hear the process of remerging LEDE with OpenWrt is moving forward.
For what it?s worth, if prefer the LEDE name (it?s friendlier - ?leddy? - and not tied to the name of an old router!)

However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look?
Maybe a new logo? I?m personally not one for mascots, so I had a quick go at a few simple text-based designs:

http://i.imgur.com/9zyXSYR.png

What are you thoughts?

Jamie, onebillion
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From martin.tippmann at gmail.com  Mon May 29 06:28:59 2017
From: martin.tippmann at gmail.com (Martin Tippmann)
Date: Mon, 29 May 2017 12:28:59 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] Remerge logo ideas
In-Reply-To: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
References: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
Message-ID: <CABL_Pd98ymUzE-1-jhvr2pjJB-kh2Uu+Q7-gt3t+_81=i+BATg@mail.gmail.com>

On Mon, May 29, 2017 at 12:11 PM, Jamie Stuart <jamie at onebillion.org> wrote:
> Hi,
> First of all, I?m glad to hear the process of remerging LEDE with OpenWrt is moving forward.
> For what it?s worth, if prefer the LEDE name (it?s friendlier - ?leddy? - and not tied to the name of an old router!)
>
> However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look?
> Maybe a new logo? I?m personally not one for mascots, so I had a quick go at a few simple text-based designs:
>
> http://i.imgur.com/9zyXSYR.png
>
> What are you thoughts?

+1

The logo looks great. Is the used font free to use? There could be a
problems if it's a commercial font, depending on the licence?

Maybe LEDE/OpenWRT could create some minimal "corporate identity" like
some base colors and fonts that are used on all websites. I guess it
shouldn't more be than a few CSS rules but having a somewhat unified
look across all websites / pages is a nice thing to have. Arch Linux
is a good example, they also use Flyspray and a Wiki and gitweb but
have a similiar look and feel everywhere.

regards
Martin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Mon May 29 06:52:28 2017
From: john at phrozen.org (John Crispin)
Date: Mon, 29 May 2017 12:52:28 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV]  Remerge logo ideas
In-Reply-To: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
References: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
Message-ID: <7d06a557-8732-30a1-285a-80af4651b3f2@phrozen.org>



On 29/05/17 12:11, Jamie Stuart wrote:
> Hi,
> First of all, I?m glad to hear the process of remerging LEDE with OpenWrt is moving forward.
> For what it?s worth, if prefer the LEDE name (it?s friendlier - ?leddy? - and not tied to the name of an old router!)
>
> However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look?
> Maybe a new logo? I?m personally not one for mascots, so I had a quick go at a few simple text-based designs:
>
> http://i.imgur.com/9zyXSYR.png
>
> What are you thoughts?
>
> Jamie, onebillion

Hi,

the correct spelling is OpenWrt with a capital O and W. could you add 
that to the proposal aswell please ? ideally with and without the 
antenna feature

     John
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From jamie at onebillion.org  Mon May 29 07:10:20 2017
From: jamie at onebillion.org (Jamie Stuart)
Date: Mon, 29 May 2017 14:10:20 +0300
Subject: [OpenWrt-Devel] [LEDE-DEV]  Remerge logo ideas
In-Reply-To: <7d06a557-8732-30a1-285a-80af4651b3f2@phrozen.org>
References: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
 <7d06a557-8732-30a1-285a-80af4651b3f2@phrozen.org>
Message-ID: <CA4BD962-CB07-4DF0-B0D7-CAF55E596020@onebillion.org>

See another iteration, with:

- correct capitalisation
- antenna to the side (will not work with lowercase ?n?)
- open sans typeface (open source)
- mockups of website header
- accent colours

http://i.imgur.com/ZKtcFXo.png


> On 29 May 2017, at 13:52, John Crispin <john at phrozen.org> wrote:
> 
> 
> 
> On 29/05/17 12:11, Jamie Stuart wrote:
>> Hi,
>> First of all, I?m glad to hear the process of remerging LEDE with OpenWrt is moving forward.
>> For what it?s worth, if prefer the LEDE name (it?s friendlier - ?leddy? - and not tied to the name of an old router!)
>> 
>> However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look?
>> Maybe a new logo? I?m personally not one for mascots, so I had a quick go at a few simple text-based designs:
>> 
>> http://i.imgur.com/9zyXSYR.png
>> 
>> What are you thoughts?
>> 
>> Jamie, onebillion
> 
> Hi,
> 
> the correct spelling is OpenWrt with a capital O and W. could you add that to the proposal aswell please ? ideally with and without the antenna feature
> 
>    John
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bjorn at mork.no  Mon May 29 07:20:54 2017
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 29 May 2017 13:20:54 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 (Carlo Lobrano's message of "Mon, 29 May 2017 12:01:59 +0200")
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
Message-ID: <87h903rjs9.fsf@miraculix.mork.no>

Carlo Lobrano <c.lobrano at gmail.com> writes:

> Hello,
>
> Hope this is the right place to ask for help and my apologies if it is not.
>
> I'm testing uqmi with a Telit LE910 LTE modem on Ubuntu 16.10, but I'm
> facing this weird issue.
> Uqmi considers the modem connected from the very beginning, even if I
> haven't run --start-network yet and even if I use --set-autoconnect
> disabled first, and when I try to connect with a different APN it replies
> with "no effect"
>
>
>     $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
>     "connected"
>     $ sudo uqmi -d /dev/cdc-wdm1 --set-autoconnect disabled
>     $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
>     "connected"
>     $ sudo uqmi -d /dev/cdc-wdm1 --start-network web.omnitel.it
>  --autoconnect
>     "No effect"


AFAICS, that is the expected result.  The modem is connected and you do
not disconnect, so "start-network" has no effect.

If you do not want "autoconnect" then you should not include it with the
"start-network" request.

If "--set-autoconnect disabled" does not work as expected, then please
try "--stop-network --autoconnect".  This should both stop the current
session and disable autoconnect for future sessions.  Until you enable
it again with "--start-network --autoconnect".  Just don't do that if
you don't want autoconnect...


> I think that reason is the default bearer established at the attach (since
> it's LTE), but I'm not sure how to overcome this and any hints would be
> very appreciated.

I haven't seen any such issues with the Qualcomm based modems. They seem
to deal pretty well with the difference between their data bearers and
the initial default bearer.


Bj?rn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Mon May 29 07:45:17 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Mon, 29 May 2017 13:45:17 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] Remerge logo ideas
In-Reply-To: <CA4BD962-CB07-4DF0-B0D7-CAF55E596020@onebillion.org>
References: <018C9DAD-564F-4EC4-B08F-8ECD92DEF826@onebillion.org>
 <7d06a557-8732-30a1-285a-80af4651b3f2@phrozen.org>
 <CA4BD962-CB07-4DF0-B0D7-CAF55E596020@onebillion.org>
Message-ID: <0a7315a0-f07d-3106-eb70-5cbaf10e2814@openwrt.org>

On 2017-05-29 13:10, Jamie Stuart wrote:
> See another iteration, with:
> 
> - correct capitalisation
> - antenna to the side (will not work with lowercase ?n?)
> - open sans typeface (open source)
> - mockups of website header
> - accent colours
> 
> http://i.imgur.com/ZKtcFXo.png

Nice :) Personally I like the darker color set of the last, but the 
layout of the first the most (when the "signal" is at the end).


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

From c.lobrano at gmail.com  Mon May 29 07:45:17 2017
From: c.lobrano at gmail.com (Carlo Lobrano)
Date: Mon, 29 May 2017 13:45:17 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <87h903rjs9.fsf@miraculix.mork.no>
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
Message-ID: <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>

Hi Bj?rn,

thanks for the reply

> AFAICS, that is the expected result.  The modem is connected and you do
> not disconnect, so "start-network" has no effect.

Yes, you're right, but why am I connected in the first place? There is no
context configured

> If "--set-autoconnect disabled" does not work as expected, then please
> try "--stop-network --autoconnect".

doesn't stop-network require an handle?

    $ sudo uqmi -d /dev/cdc-wdm1 --stop-network --autoconnect
    "Invalid handle"

On 29 May 2017 at 13:20, Bj?rn Mork <bjorn at mork.no> wrote:

> Carlo Lobrano <c.lobrano at gmail.com> writes:
>
> > Hello,
> >
> > Hope this is the right place to ask for help and my apologies if it is
> not.
> >
> > I'm testing uqmi with a Telit LE910 LTE modem on Ubuntu 16.10, but I'm
> > facing this weird issue.
> > Uqmi considers the modem connected from the very beginning, even if I
> > haven't run --start-network yet and even if I use --set-autoconnect
> > disabled first, and when I try to connect with a different APN it replies
> > with "no effect"
> >
> >
> >     $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
> >     "connected"
> >     $ sudo uqmi -d /dev/cdc-wdm1 --set-autoconnect disabled
> >     $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
> >     "connected"
> >     $ sudo uqmi -d /dev/cdc-wdm1 --start-network web.omnitel.it
> >  --autoconnect
> >     "No effect"
>
>
> AFAICS, that is the expected result.  The modem is connected and you do
> not disconnect, so "start-network" has no effect.
>
> If you do not want "autoconnect" then you should not include it with the
> "start-network" request.
>
> If "--set-autoconnect disabled" does not work as expected, then please
> try "--stop-network --autoconnect".  This should both stop the current
> session and disable autoconnect for future sessions.  Until you enable
> it again with "--start-network --autoconnect".  Just don't do that if
> you don't want autoconnect...
>
>
> > I think that reason is the default bearer established at the attach
> (since
> > it's LTE), but I'm not sure how to overcome this and any hints would be
> > very appreciated.
>
> I haven't seen any such issues with the Qualcomm based modems. They seem
> to deal pretty well with the difference between their data bearers and
> the initial default bearer.
>
>
> Bj?rn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/008abdc4/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bjorn at mork.no  Mon May 29 07:54:44 2017
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 29 May 2017 13:54:44 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 (Carlo Lobrano's message of "Mon, 29 May 2017 13:45:17 +0200")
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
Message-ID: <87a85vri7v.fsf@miraculix.mork.no>

Carlo Lobrano <c.lobrano at gmail.com> writes:

>> AFAICS, that is the expected result.  The modem is connected and you do
>> not disconnect, so "start-network" has no effect.
>
> Yes, you're right, but why am I connected in the first place? There is no
> context configured

If autoconnect is enabled, then I believe the modem will try to connect
with whatever it has. Don't know if it tries an empty APN or reuse the
default bearer context in this case, but either will most likely work
(depending on operator, but still..)


>> If "--set-autoconnect disabled" does not work as expected, then please
>> try "--stop-network --autoconnect".
>
> doesn't stop-network require an handle?
>
>     $ sudo uqmi -d /dev/cdc-wdm1 --stop-network --autoconnect
>     "Invalid handle"

Probably.  My point was just that you could try to include
"--autoconnect", which will disable the autoconnect feature.  I am too
lazy to bother to write the whole command ;-)



Bj?rn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From c.lobrano at gmail.com  Mon May 29 08:14:24 2017
From: c.lobrano at gmail.com (Carlo Lobrano)
Date: Mon, 29 May 2017 14:14:24 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <87a85vri7v.fsf@miraculix.mork.no>
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 <87a85vri7v.fsf@miraculix.mork.no>
Message-ID: <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>

>
> Probably.  My point was just that you could try to include
> "--autoconnect", which will disable the autoconnect feature.  I am too
> lazy to bother to write the whole command ;-)


I understand :D

By the way, it looks like that the handle for
when-you-dont-know-what-the-handle-is is 0xFFFFFFFF

$ sudo uqmi -d /dev/cdc-wdm1 --stop-network 0xFFFFFFFF --autoconnect
$ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
"disconnected"




On 29 May 2017 at 13:54, Bj?rn Mork <bjorn at mork.no> wrote:

> Carlo Lobrano <c.lobrano at gmail.com> writes:
>
> >> AFAICS, that is the expected result.  The modem is connected and you do
> >> not disconnect, so "start-network" has no effect.
> >
> > Yes, you're right, but why am I connected in the first place? There is no
> > context configured
>
> If autoconnect is enabled, then I believe the modem will try to connect
> with whatever it has. Don't know if it tries an empty APN or reuse the
> default bearer context in this case, but either will most likely work
> (depending on operator, but still..)
>
>
> >> If "--set-autoconnect disabled" does not work as expected, then please
> >> try "--stop-network --autoconnect".
> >
> > doesn't stop-network require an handle?
> >
> >     $ sudo uqmi -d /dev/cdc-wdm1 --stop-network --autoconnect
> >     "Invalid handle"
>
> Probably.  My point was just that you could try to include
> "--autoconnect", which will disable the autoconnect feature.  I am too
> lazy to bother to write the whole command ;-)
>
>
>
> Bj?rn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/a614e376/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bjorn at mork.no  Mon May 29 08:24:21 2017
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 29 May 2017 14:24:21 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>
 (Carlo Lobrano's message of "Mon, 29 May 2017 14:14:24 +0200")
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 <87a85vri7v.fsf@miraculix.mork.no>
 <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>
Message-ID: <874lw3rgui.fsf@miraculix.mork.no>

Carlo Lobrano <c.lobrano at gmail.com> writes:

>>
>> Probably.  My point was just that you could try to include
>> "--autoconnect", which will disable the autoconnect feature.  I am too
>> lazy to bother to write the whole command ;-)
>
>
> I understand :D
>
> By the way, it looks like that the handle for
> when-you-dont-know-what-the-handle-is is 0xFFFFFFFF
>
> $ sudo uqmi -d /dev/cdc-wdm1 --stop-network 0xFFFFFFFF --autoconnect
> $ sudo uqmi -d /dev/cdc-wdm1 --get-data-status
> "disconnected"

Great!  And if you reboot the modem in this state, does it still come up
as connected?



Bj?rn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From c.lobrano at gmail.com  Mon May 29 08:36:00 2017
From: c.lobrano at gmail.com (Carlo Lobrano)
Date: Mon, 29 May 2017 14:36:00 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <874lw3rgui.fsf@miraculix.mork.no>
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 <87a85vri7v.fsf@miraculix.mork.no>
 <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>
 <874lw3rgui.fsf@miraculix.mork.no>
Message-ID: <CA+KuA8d=0tPzBKZwoRqp4axrd8nLpE-jGj+CLvz6nx94HCg6bg@mail.gmail.com>

On 29 May 2017 at 14:24, Bj?rn Mork <bjorn at mork.no> wrote:

>
> Great!  And if you reboot the modem in this state, does it still come up
> as connected?



?Nope, still "disconnected"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/278c5c48/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bjorn at mork.no  Mon May 29 08:46:43 2017
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 29 May 2017 14:46:43 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <CA+KuA8d=0tPzBKZwoRqp4axrd8nLpE-jGj+CLvz6nx94HCg6bg@mail.gmail.com>
 (Carlo Lobrano's message of "Mon, 29 May 2017 14:36:00 +0200")
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 <87a85vri7v.fsf@miraculix.mork.no>
 <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>
 <874lw3rgui.fsf@miraculix.mork.no>
 <CA+KuA8d=0tPzBKZwoRqp4axrd8nLpE-jGj+CLvz6nx94HCg6bg@mail.gmail.com>
Message-ID: <87r2z7q18s.fsf@miraculix.mork.no>

Carlo Lobrano <c.lobrano at gmail.com> writes:

> On 29 May 2017 at 14:24, Bj?rn Mork <bjorn at mork.no> wrote:
>
>>
>> Great!  And if you reboot the modem in this state, does it still come up
>> as connected?
>
>
>
> ?Nope, still "disconnected"?

Then I believe everything works as expected.


Bj?rn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From c.lobrano at gmail.com  Mon May 29 08:57:46 2017
From: c.lobrano at gmail.com (Carlo Lobrano)
Date: Mon, 29 May 2017 14:57:46 +0200
Subject: [OpenWrt-Devel] Unable to connect with uqmi ("No effect")
In-Reply-To: <87r2z7q18s.fsf@miraculix.mork.no>
References: <CA+KuA8d83rq+SmMqhq8jjbRUsdK1kWUZsjuUBi2w0ykzSqhpTg@mail.gmail.com>
 <87h903rjs9.fsf@miraculix.mork.no>
 <CA+KuA8fB-yDXdBJbpRm1De+mnozZmSnc5qXUU_Y+iN_25-2m9g@mail.gmail.com>
 <87a85vri7v.fsf@miraculix.mork.no>
 <CA+KuA8ctjdtbvSaKfy_3K9B6kYbGdGUgxMgbf-TVBMOFzZXcqg@mail.gmail.com>
 <874lw3rgui.fsf@miraculix.mork.no>
 <CA+KuA8d=0tPzBKZwoRqp4axrd8nLpE-jGj+CLvz6nx94HCg6bg@mail.gmail.com>
 <87r2z7q18s.fsf@miraculix.mork.no>
Message-ID: <CA+KuA8diDgK1RTTErJxw=SNWBfihe6eWwqkG5V=ggKGtu639SA@mail.gmail.com>

On 29 May 2017 at 14:46, Bj?rn Mork <bjorn at mork.no> wrote:

> Carlo Lobrano <c.lobrano at gmail.com> writes:
>
> > On 29 May 2017 at 14:24, Bj?rn Mork <bjorn at mork.no> wrote:
> >
> >>
> >> Great!  And if you reboot the modem in this state, does it still come up
> >> as connected?
> >
> >
> >
> > ?Nope, still "disconnected"?
>
> Then I believe everything works as expected.
>
>
> Bj?rn
>

?Perfect, thank you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/0ceba257/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mschiffer at universe-factory.net  Mon May 29 10:30:02 2017
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 29 May 2017 16:30:02 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <71ca409e-557f-3691-0ac4-e2de900611d1@universe-factory.net>

On 05/29/2017 09:03 AM, John Crispin wrote:
> (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.
> 
> 
>         John

The proposal looks very good, and I think all important points have been
discussed over the last weeks. So that's an ACK from my side.

Matthias


> 
> *) rules
> - owrt will adopt the lede rules and voting system
> 
> *) 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
> - nominate a new liaison team (imre and john offer to do this, if anyone
> else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can be
> handed over
> 
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages announcing
> the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to one
> appropriate to this century
> 
> *) 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
> 
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3
> owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>     John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170529/815ed4a7/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From stijn at linux-ipv6.be  Mon May 29 12:38:29 2017
From: stijn at linux-ipv6.be (Stijn Tintel)
Date: Mon, 29 May 2017 18:38:29 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <f33975d3-1df1-dbf6-8ba8-657f58f062b1@linux-ipv6.be>

On 29-05-17 09:03, John Crispin wrote:
> (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.
>
Full ACK from me.

Thanks,
Stijn
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From hauke at hauke-m.de  Mon May 29 15:32:13 2017
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Mon, 29 May 2017 21:32:13 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <de48a515-b9e5-2af0-f8a7-ec1692dedb91@hauke-m.de>

On 05/29/2017 09:03 AM, John Crispin wrote:
> (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.
> 
> 
>         John

Looks good, ack from me.

Hauke

> 
> *) rules
> - owrt will adopt the lede rules and voting system
> 
> *) 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
> - nominate a new liaison team (imre and john offer to do this, if anyone
> else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can
> be handed over
> 
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages
> announcing the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to one
> appropriate to this century
> 
> *) 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
> 
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3
> owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>     John
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From f.fainelli at gmail.com  Mon May 29 15:39:29 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 29 May 2017 12:39:29 -0700
Subject: [OpenWrt-Devel] [OpenWrt-Hackers] openwrt and lede - remerge
	proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <ce5db7c1-00b7-9076-5858-6a4e3bc9edd1@gmail.com>

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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Mon May 29 15:49:15 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Mon, 29 May 2017 21:49:15 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <20170529194914.GB1828@makrotopia.org>

On Mon, May 29, 2017 at 09:03:57AM +0200, John Crispin wrote:
> (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.

+1 ACK
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From dedeckeh at gmail.com  Mon May 29 16:31:04 2017
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon, 29 May 2017 22:31:04 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <CAJLcKsH5kk84XEG2kh5OVAK5w+xsMv52hNS_8EOCKtDcOygv7A@mail.gmail.com>

On Mon, May 29, 2017 at 9:03 AM, John Crispin <john at phrozen.org> wrote:
> (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.
>
>
>         John
>
> *) rules
> - owrt will adopt the lede rules and voting system
>
> *) 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
> - nominate a new liaison team (imre and john offer to do this, if anyone
> else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can be
> handed over
>
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
>
> *) landing page
> - add a letter of intent / notice to both current landing pages announcing
> the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to one
> appropriate to this century
>
> *) 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
>
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
>
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3
> owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
>
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
>
> *) timeline
> - vote / agree on the proposal within the next week
Ack from my side on all the listed items

Thx for compiling the list John

Hans
> - work on the action items in the 4 weeks after that
>
>     John
>
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Tue May 30 00:13:47 2017
From: john at phrozen.org (John Crispin)
Date: Tue, 30 May 2017 06:13:47 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <62ecc0b4-1e0b-9c0a-1014-82884b52dd8b@phrozen.org>


> *) rules
> - owrt will adopt the lede rules and voting system
>

ACK from me aswell.




> *) 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
> - nominate a new liaison team (imre and john offer to do this, if 
> anyone else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains 
> can be handed over
>
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
>
> *) landing page
> - add a letter of intent / notice to both current landing pages 
> announcing the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to 
> one appropriate to this century
>
> *) 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
>
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
>
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 
> 3 owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
>
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
>
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
>
>     John
>
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From zajec5 at gmail.com  Tue May 30 01:21:16 2017
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 30 May 2017 07:21:16 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <CACna6rx6des+8qsSACdMwcOQRubKx6z7JckcXe3MQ5MrYpfqgQ@mail.gmail.com>

On 29 May 2017 at 09:03, John Crispin <john at phrozen.org> wrote:
> 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.

Looks good
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Tue May 30 01:38:38 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Tue, 30 May 2017 07:38:38 +0200
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <3bc81320-9be0-fa00-f157-c4ac9ce27206@nbd.name>

On 2017-05-29 09:03, John Crispin wrote:
> (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.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Tue May 30 02:02:44 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Tue, 30 May 2017 06:02:44 +0000
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V3
In-Reply-To: <3bc81320-9be0-fa00-f157-c4ac9ce27206@nbd.name>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
 <3bc81320-9be0-fa00-f157-c4ac9ce27206@nbd.name>
Message-ID: <CA+U=DspX34+pA9i+GCEvpoyBzUBeDk+NoZ+t+jubHgsOpQ5Uog@mail.gmail.com>

On Tue, 30 May 2017 at 08:38, Felix Fietkau <nbd at nbd.name> wrote:

> On 2017-05-29 09:03, John Crispin wrote:
> > (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.
>
> - Felix


Ack


> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170530/d91f4a1b/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Tue May 30 02:32:34 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Tue, 30 May 2017 09:32:34 +0300
Subject: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
	V3
In-Reply-To: <3bc81320-9be0-fa00-f157-c4ac9ce27206@nbd.name>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
 <3bc81320-9be0-fa00-f157-c4ac9ce27206@nbd.name>
Message-ID: <CA+U=DsrDDnywbjWbGHu+21Ts4Stzk-==q-S9CR5K=X4vzOYytQ@mail.gmail.com>

On Tue, May 30, 2017 at 8:38 AM, Felix Fietkau <nbd at nbd.name> wrote:
> On 2017-05-29 09:03, John Crispin wrote:
>> (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.
>
> - Felix

ack

[forgot that GMail app does not support plain text mode, or is really
hidden somewhere ]

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pepe2k at gmail.com  Tue May 30 05:35:48 2017
From: pepe2k at gmail.com (Piotr Dymacz)
Date: Tue, 30 May 2017 11:35:48 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <bfbc6454-d215-7d49-4720-9ddc6b2ef6f4@gmail.com>

On 29.05.2017 09:03, John Crispin wrote:
> (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.

Thanks all involved for preparing the remerge proposal.

--
Cheers,
Piotr
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arunkumar.1993.2050 at gmail.com  Wed May 31 15:58:09 2017
From: arunkumar.1993.2050 at gmail.com (Arun Kumar)
Date: Thu, 1 Jun 2017 01:28:09 +0530
Subject: [OpenWrt-Devel] USB or SD card not mounted in Omega2+ router with
	LEDE iamge
Message-ID: <CAO4+10MiDibmT2m83h8yZ1TWbazujZj3SYhU0+qZsXijaom9Aw@mail.gmail.com>

Hi All,

I am facing an error where I can't find my USB or SD card and hence cant
upgrade to a new image.

SD Card or USB device plugged in would be usually automounted at
/tmp/mounts
But after sysupgrading to the latest LEDE image, the Omega2+ router detects
the USB device getting plugged in but doesnt display anywhere. Not even in
/dev/sdaX location.

When I plugin a USB device, I get this message:
[ 6382.201671] usb 1-1: new high-speed USB device number 3 using
ehci-platform

root at Omega-FB25:/# ls /dev/
bus                 mtd5ro              ttyS1
console             mtd6                ttyS10
cpu_dma_latency     mtd6ro              ttyS11
full                mtdblock0           ttyS12
hwrng               mtdblock1           ttyS13
kmsg                mtdblock2           ttyS14
log                 mtdblock3           ttyS15
memory_bandwidth    mtdblock4           ttyS2
mmcblk0             mtdblock5           ttyS3
mmcblk0p1           mtdblock6           ttyS4
mtd0                network_latency     ttyS5
mtd0ro              network_throughput  ttyS6
mtd1                null                ttyS7
mtd1ro              port                ttyS8
mtd2                ppp                 ttyS9
mtd2ro              ptmx                urandom
mtd3                pts                 watchdog
mtd3ro              random              watchdog0
mtd4                shm                 zero
mtd4ro              tty
mtd5                ttyS0
root at Omega-FB25:/# dmesg | grep usb
[    2.584787] usbcore: registered new interface driver usbfs
[    2.590508] usbcore: registered new interface driver hub
[    2.596060] usbcore: registered new device driver usb
[    2.630320] phy phy-10120000.usbphy.0: remote usb device wakeup disabled
[    2.637134] phy phy-10120000.usbphy.0: UTMI 16bit 30MHz
[    3.118388] usb 1-1: new high-speed USB device number 2 using
ehci-platform
[ 6377.744209] usb 1-1: USB disconnect, device number 2
[ 6382.201671] usb 1-1: new high-speed USB device number 3 using
ehci-platform

root at Omega-FB25:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    61.5M     56.0K     61.5M   0% /tmp
/dev/mtdblock6           28.3M    820.0K     27.4M   3% /overlay
overlayfs:/overlay       28.3M    820.0K     27.4M   3% /
tmpfs                   512.0K         0    512.0K   0% /dev
root at Omega-FB25:/# cd /tmp/mounts
/bin/ash: cd: can't cd to /tmp/mounts

Tried with both USB 1 and USB 2.0 devices. So tried to connect to Wifi and
download new image. But iwconfig is not working.

root at Omega-FB25:/# iwconfig
/bin/ash: iwconfig: not found

Note: This was working fine earlier and I did multiple image swaps between
my personal built ones and official images. I upgraded image from Omega2+
image to LEDE image[1].

Any suggestions on how to overcome this would be helpful.

[1]
https://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/lede-17.01.1-ramips-mt7688-omega2p-squashfs-sysupgrade.bin

Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170601/02f3a6ba/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From lynxis at fe80.eu  Wed May 31 16:27:21 2017
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 31 May 2017 22:27:21 +0200
Subject: [OpenWrt-Devel] openwrt and lede - remerge proposal V3
In-Reply-To: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
References: <88bfa9e9-634f-f504-bdc3-e01185c4acaa@phrozen.org>
Message-ID: <20170531222721.5ef8cfc4@lazus.yip>

On Mon, 29 May 2017 09:03:57 +0200
John Crispin <john at phrozen.org> wrote:

> (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.
> 
> 
>          John

ACK.


> 
> *) rules
> - owrt will adopt the lede rules and voting system
> 
> *) 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
> - nominate a new liaison team (imre and john offer to do this, if
> anyone else is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains
> can be handed over
> 
> *) github
> - 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
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages 
> announcing the remerge
> - 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
> - try to find some design guru that will transform the owrt theme to
> one appropriate to this century
> 
> *) 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
> 
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> (the 3 owrt devs would like to keep theirs active)
> - 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
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>      John
> 
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170531/e1590b57/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ryazanov.s.a at gmail.com  Wed May 31 17:01:23 2017
From: ryazanov.s.a at gmail.com (Sergey Ryazanov)
Date: Thu, 1 Jun 2017 00:01:23 +0300
Subject: [OpenWrt-Devel] Help for updating kernel drivers
In-Reply-To: <CADCBap0eL40e=YjiofL-97cONv3sJ5XP0LyAx9OjeDroLQY6sA@mail.gmail.com>
References: <CADCBap0eL40e=YjiofL-97cONv3sJ5XP0LyAx9OjeDroLQY6sA@mail.gmail.com>
Message-ID: <1196945790.20170601000123@gmail.com>

Hello Swapnil,

Monday, May 22, 2017, 11:48:50 AM, you wrote:
> If anyone can help me to figure out a way by which I can modify a
> driver of linux kernel and make the change reflect in the router.?

Could  you  specify,  please, that the driver you mentioned comes from
the  kernel  tarball  or  from a separate package? The workflow is the
same, but the commands for different cases are somewhat different.

> Till now I tried to download the tarballs by "make download" then I
> inserted a print statement on one of the drivers and then used
> "make" to build the image. Finally when I dmesg on the router the
> print  statement  doesn't work. I think my code has been overwritten
> when "make" is called.
>
> Please give some advice on how to do that.

There is a good step-by-step guide how to patch the source code before
the compilation: https://wiki.openwrt.org/doc/devel/patches

Feel free to ask, if in this guide something is not clear.

-- 
Sergey
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel