Re: [OpenWrt-Devel] Inquery

[Stijn Segers]

Rosen Penev  schreef op 11 december 2019 22:17:34 CET:
>On Wed, Dec 11, 2019 at 11:32 AM Alberto Bursi
> wrote:
>>
>>
>>
>> On 11/12/19 18:54, Daniel Golle wrote:
>> > On Wed, Dec 11, 2019 at 05:37:26PM +0100, WRT Burner wrote:
>> >> On 11/12/2019 15:22, Daniel Golle wrote:
>> >>> And it's even needless to say that
>> >>> replying to a spam email in which ever way will always make it
>worse.
>> >>
>> >> +1. There is no constructive value in replying to spam. Let's keep
>openwrt-devel
>> >> nice and clean.
>> >>
>> >> On 11/12/2019 15:22, Daniel Golle wrote:
>> >>> You statement "suck it" (guess what) is also an obvious
>> >>> and disgusting example of a masculist culture which hurts our
>community
>> >>> as a whole and I strongly believe we should not tolerate that.
>> >>
>> >> -1. This is a software development mailing list, not tumblr.com.
>> >
>> > '-1'? So I get right, you are saying it's ok to be insulting other
>> > people because this mailing list is about software development?
>> > If that's really what you wanted to say, I'm glad that's only a
>single
>> > individual opinion coming from an email address which has never
>> > actually been used on this mailing list.
>> > And btw, this is your first 'contribution', and it's not even about
>> > software development...
>> >
>>
>> He is just disappointed at your pointing out the "masculinist
>culture"
>> in a place where he expected more maturity.
>>
>> Yours is mostly SJW-speak and I'm also not fond of it, I'll explain
>why.
>> It is a double-edged blade.
>> In this case your definition is technically correct, we all know what
>> "suck it" implies.
>> But this highly polarizing approach to life and people can (and does,
>> especially in its dens like tumblr.com as mentioned) slippery slope
>into
>> full blown hate and reverse oppression, which is equally bad.
>>
>> I'm not impressed by your reaction here, first thing you do is a
>blatant
>> strawman logical fallacy and then proceed to attack him on his
>personal
>> values as a person without even asking to clarify his position first.
>> He just posted a single short sentence, for heaven's sake.
>>
>> This is EXACTLY an example of slippery slope into blind hate rage as
>I
>> said above, and exactly why this kind of polarizing categorizations
>and
>> statements should be avoided at all costs in a serious and sane
>environment.
>>
>> We should really not jump at each other's throats on a moment's
>notice
>> like that, especially not in a software development mailing list.
>+1
>
>Unnecessary drama is not neStijn

Very much so. Thank you for this voice of reason.

Stijn

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


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

Re: [OpenWrt-Devel] Inquery

[Gio]

On Wednesday, 11 December 2019 15:22:09 CET Daniel Golle wrote:
> Hi Tomislav,
> 
> On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
> > suck it
> 
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each
> other." is meant just as serious as all the other rules.
> 
> So here, not for the first time, you are using language which has the
> only purpose to hurt other people (for which reason ever, it doesn't
> matter). This is therefore a very clear violation to the above
> mentioned rule. You statement "suck it" (guess what) is also an obvious
> and disgusting example of a masculist culture which hurts our community
> as a whole and I strongly believe we should not tolerate that.
> 
> And yes this was a spam mail. And it's even needless to say that
> replying to a spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion
> on that matter.
> 
> Please learn to behave or leave us alone.
> 
> [1]: https://openwrt.org/rules

+1

Thanks Daniel for the effort drawing attention to this issue




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

Re: [OpenWrt-Devel] Inquery

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Golle
> Sent: Mittwoch, 11. Dezember 2019 15:22
> To: Tom Psyborg 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Inquery
> 
> Hi Tomislav,
> 
> On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
> > suck it
> 
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each other." 
> is
> meant just as serious as all the other rules.
> 
> So here, not for the first time, you are using language which has the only
> purpose to hurt other people (for which reason ever, it doesn't matter). This
> is therefore a very clear violation to the above mentioned rule. You
> statement "suck it" (guess what) is also an obvious and disgusting example of
> a masculist culture which hurts our community as a whole and I strongly
> believe we should not tolerate that.
> 
> And yes this was a spam mail. And it's even needless to say that replying to a
> spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion on that
> matter.
> 
> Please learn to behave or leave us alone.

+1

The latest reply from Tom forced me to also express my consent with what Daniel 
wrote here.
I indeed think his reaction is very appropriate, keeping it to the matter of 
fact where the recent history of Tom's "contributions" might have tempted other 
people to react less sensibly.

Adrian

> 
> [1]: https://openwrt.org/rules
> 
> 
> >
> > On 11/12/2019, rqgxfc  wrote:
> > >
> > >
> > > Hello Sir ，
> > >
> > > We are  a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd
> .
> > > Now
> > > we are very interested in your products , we will plan to  sell your
> > > products in the Chinese market . If you are interested in
> > > cooperation, please send us a catalog and pricelist .w Looking
> > > forward to receiving your reply .
> > >
> > > Best regards,
> > > Catherina
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Inquery

[Rosen Penev]

On Wed, Dec 11, 2019 at 11:32 AM Alberto Bursi
 wrote:
>
>
>
> On 11/12/19 18:54, Daniel Golle wrote:
> > On Wed, Dec 11, 2019 at 05:37:26PM +0100, WRT Burner wrote:
> >> On 11/12/2019 15:22, Daniel Golle wrote:
> >>> And it's even needless to say that
> >>> replying to a spam email in which ever way will always make it worse.
> >>
> >> +1. There is no constructive value in replying to spam. Let's keep 
> >> openwrt-devel
> >> nice and clean.
> >>
> >> On 11/12/2019 15:22, Daniel Golle wrote:
> >>> You statement "suck it" (guess what) is also an obvious
> >>> and disgusting example of a masculist culture which hurts our community
> >>> as a whole and I strongly believe we should not tolerate that.
> >>
> >> -1. This is a software development mailing list, not tumblr.com.
> >
> > '-1'? So I get right, you are saying it's ok to be insulting other
> > people because this mailing list is about software development?
> > If that's really what you wanted to say, I'm glad that's only a single
> > individual opinion coming from an email address which has never
> > actually been used on this mailing list.
> > And btw, this is your first 'contribution', and it's not even about
> > software development...
> >
>
> He is just disappointed at your pointing out the "masculinist culture"
> in a place where he expected more maturity.
>
> Yours is mostly SJW-speak and I'm also not fond of it, I'll explain why.
> It is a double-edged blade.
> In this case your definition is technically correct, we all know what
> "suck it" implies.
> But this highly polarizing approach to life and people can (and does,
> especially in its dens like tumblr.com as mentioned) slippery slope into
> full blown hate and reverse oppression, which is equally bad.
>
> I'm not impressed by your reaction here, first thing you do is a blatant
> strawman logical fallacy and then proceed to attack him on his personal
> values as a person without even asking to clarify his position first.
> He just posted a single short sentence, for heaven's sake.
>
> This is EXACTLY an example of slippery slope into blind hate rage as I
> said above, and exactly why this kind of polarizing categorizations and
> statements should be avoided at all costs in a serious and sane environment.
>
> We should really not jump at each other's throats on a moment's notice
> like that, especially not in a software development mailing list.
+1

Unnecessary drama is not needed.
>
> -Alberto
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Inquery

[Tom Psyborg]

On 11/12/2019, Daniel Golle  wrote:
> Hi Tomislav,
>
> On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
>> suck it
>
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each
> other." is meant just as serious as all the other rules.
>
> So here, not for the first time, you are using language which has the
> only purpose to hurt other people (for which reason ever, it doesn't
> matter). This is therefore a very clear violation to the above
> mentioned rule. You statement "suck it" (guess what) is also an obvious
> and disgusting example of a masculist culture which hurts our community
> as a whole and I strongly believe we should not tolerate that.
>
> And yes this was a spam mail. And it's even needless to say that
> replying to a spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion
> on that matter.
>
> Please learn to behave or leave us alone.
>

i take "us" for a couple of you hire chinese or create dupe account to
spam with your nonsense. otherwise your +1 replies indeed do make it
worse

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

Re: [OpenWrt-Devel] (no subject)

[Roger Pueyo Centelles | Guifi.net]

Hi,

Have you checked https://openwrt.org/trademark ?

Cheers!

El 11/12/19 a les 20:43, sagar jain ha escrit:
>
> Can i sell OpenWRT based router ?
>
>  
>
> Sent from Mail  for
> Windows 10
>
>  
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] (no subject)

[sagar jain]

Can i sell OpenWRT based router ?

Sent from Mail for Windows 10

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

Re: [OpenWrt-Devel] Inquery

[Alberto Bursi]

On 11/12/19 18:54, Daniel Golle wrote:

On Wed, Dec 11, 2019 at 05:37:26PM +0100, WRT Burner wrote:

On 11/12/2019 15:22, Daniel Golle wrote:

And it's even needless to say that
replying to a spam email in which ever way will always make it worse.


+1. There is no constructive value in replying to spam. Let's keep openwrt-devel
nice and clean.

On 11/12/2019 15:22, Daniel Golle wrote:

You statement "suck it" (guess what) is also an obvious
and disgusting example of a masculist culture which hurts our community
as a whole and I strongly believe we should not tolerate that.


-1. This is a software development mailing list, not tumblr.com.


'-1'? So I get right, you are saying it's ok to be insulting other
people because this mailing list is about software development?
If that's really what you wanted to say, I'm glad that's only a single
individual opinion coming from an email address which has never
actually been used on this mailing list.
And btw, this is your first 'contribution', and it's not even about
software development...



He is just disappointed at your pointing out the "masculinist culture" 
in a place where he expected more maturity.


Yours is mostly SJW-speak and I'm also not fond of it, I'll explain why.
It is a double-edged blade.
In this case your definition is technically correct, we all know what 
"suck it" implies.
But this highly polarizing approach to life and people can (and does, 
especially in its dens like tumblr.com as mentioned) slippery slope into 
full blown hate and reverse oppression, which is equally bad.


I'm not impressed by your reaction here, first thing you do is a blatant 
strawman logical fallacy and then proceed to attack him on his personal 
values as a person without even asking to clarify his position first.

He just posted a single short sentence, for heaven's sake.

This is EXACTLY an example of slippery slope into blind hate rage as I 
said above, and exactly why this kind of polarizing categorizations and 
statements should be avoided at all costs in a serious and sane environment.


We should really not jump at each other's throats on a moment's notice 
like that, especially not in a software development mailing list.


-Alberto

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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

[Ben Greear]

On 12/11/19 11:16 AM, Paul Fertser wrote:

Hey Ben,

On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote:

On 12/11/19 6:44 AM, Paul Fertser wrote:

According to many bugreports [0][1][2] the default ath10k-ct kernel

...

And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or 
something
like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch to 
ath10k-ct
so that you don't need the patches.


I am offering my patch to the OpenWrt maintainers as kind of a
stop-gap measure to get ath10k-ct working for the release (or in any
way they think is appropriate). Another approach they can choose is to
select the upstream ath10k for those devices. Otherwise some
previously supported boards will require manual intervention to get
WiFi working after an upgrade.

Regarding your fwcfg idea, I am not sure it will work as it seems the
PCI initialisation is happening before fwcfg is parsed and applied.

Adding a Kconfig option is another possibility.

But what do you think about an additional module parameter, wouldn't
it be the cleanest solution in the long run?


If fwcfg will not work, and maybe it just will not due to the reasons you
suggest, then I'm fine with adding a module parameter to ath10k-ct.

You may want to conditionally compile the default value of that module parameter
so that on the small platforms the user does not actually have to set the module
param if they want the default (small) values?

Thanks,
Ben



BTW, according to the git logs the patches were initially added by
Christian Lamparter, so I hope he can clarify the situation a
bit. Probably there were some performance tests executed back than to
measure the impact.




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

[Paul Fertser]

Hey Ben,

On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote:
> On 12/11/19 6:44 AM, Paul Fertser wrote:
> > According to many bugreports [0][1][2] the default ath10k-ct kernel
...
> And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or 
> something
> like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch 
> to ath10k-ct
> so that you don't need the patches.

I am offering my patch to the OpenWrt maintainers as kind of a
stop-gap measure to get ath10k-ct working for the release (or in any
way they think is appropriate). Another approach they can choose is to
select the upstream ath10k for those devices. Otherwise some
previously supported boards will require manual intervention to get
WiFi working after an upgrade.

Regarding your fwcfg idea, I am not sure it will work as it seems the
PCI initialisation is happening before fwcfg is parsed and applied.

Adding a Kconfig option is another possibility.

But what do you think about an additional module parameter, wouldn't
it be the cleanest solution in the long run?

BTW, according to the git logs the patches were initially added by
Christian Lamparter, so I hope he can clarify the situation a
bit. Probably there were some performance tests executed back than to
measure the impact.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

[Ben Greear]

On 12/11/19 6:44 AM, Paul Fertser wrote:

According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.

Since the two patches in question might have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.

[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details_id=2664


I am fine with this approach.

And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or 
something
like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch to 
ath10k-ct
so that you don't need the patches.

Thanks,
Ben



Signed-off-by: Paul Fertser 
---
  package/kernel/ath10k-ct/Makefile | 30 +++-
  ...0-0010-ath10k-limit-htt-rx-ring-size.patch | 22 ++
  ...60-0011-ath10k-limit-pci-buffer-size.patch | 76 +++
  3 files changed, 127 insertions(+), 1 deletion(-)
  create mode 100644 
package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
  create mode 100644 
package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch

diff --git a/package/kernel/ath10k-ct/Makefile 
b/package/kernel/ath10k-ct/Makefile
index dbf75fe174..d5726a1c88 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -35,6 +35,7 @@ define KernelPackage/ath10k-ct
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
AUTOLOAD:=$(call AutoProbe,ath10k_pci)
PROVIDES:=kmod-ath10k
+  VARIANT:=regular
  endef
  
  define KernelPackage/ath10k-ct/config

@@ -42,7 +43,17 @@ define KernelPackage/ath10k-ct/config
 config ATH10K-CT_LEDS
 bool "Enable LED support"
 default y
-   depends on PACKAGE_kmod-ath10k-ct
+   depends on PACKAGE_kmod-ath10k-ct || 
PACKAGE_kmod-ath10k-ct-smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers
+$(call KernelPackage/ath10k-ct)
+  TITLE+= (small buffers to work on low-RAM devices)
+  VARIANT:=smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers/config
+$(call KernelPackage/ath10k-ct/config)
  endef
  
  NOSTDINC_FLAGS = \

@@ -90,6 +101,22 @@ ifeq ($(CONFIG_ATH10K-CT_LEDS),y)
NOSTDINC_FLAGS += -DCONFIG_ATH10K_LEDS
  endif
  
+define Build/Patch

+   $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p 
$(PKG_BUILD_DIR)/patches)
+   $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+   $(call 
PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+   $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used)
+endef
+
+define Quilt/Refresh/Package
+   $(call Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+   $(call 
Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+endef
+
  define Build/Configure
cp $(STAGING_DIR)/usr/include/mac80211/ath/*.h $(PKG_BUILD_DIR)
  endef
@@ -107,3 +134,4 @@ define Build/Compile
  endef
  
  $(eval $(call KernelPackage,ath10k-ct))

+$(eval $(call KernelPackage,ath10k-ct-smallbuffers))
diff --git 
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
new file mode 100644
index 00..f73b02e5ef
--- /dev/null
+++ 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
@@ -0,0 +1,22 @@
+--- a/ath10k-4.19/htt.h
 b/ath10k-4.19/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
+--- a/ath10k-5.2/htt.h
 b/ath10k-5.2/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
diff --git 
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
new file mode 100644
index 00..27c0032bfb
--- /dev/null
+++ 

Re: [OpenWrt-Devel] Inquery

[Daniel Golle]

On Wed, Dec 11, 2019 at 05:37:26PM +0100, WRT Burner wrote:
> On 11/12/2019 15:22, Daniel Golle wrote:
> > And it's even needless to say that
> > replying to a spam email in which ever way will always make it worse.
> 
> +1. There is no constructive value in replying to spam. Let's keep 
> openwrt-devel
> nice and clean.
> 
> On 11/12/2019 15:22, Daniel Golle wrote:
> > You statement "suck it" (guess what) is also an obvious
> > and disgusting example of a masculist culture which hurts our community
> > as a whole and I strongly believe we should not tolerate that.
> 
> -1. This is a software development mailing list, not tumblr.com.

'-1'? So I get right, you are saying it's ok to be insulting other
people because this mailing list is about software development?
If that's really what you wanted to say, I'm glad that's only a single
individual opinion coming from an email address which has never
actually been used on this mailing list.
And btw, this is your first 'contribution', and it's not even about
software development...

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

Re: [OpenWrt-Devel] Inquery

[Hans Dedecker]

On Wed, Dec 11, 2019 at 3:22 PM Daniel Golle  wrote:
>
> Hi Tomislav,
>
> On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
> > suck it
>
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each
> other." is meant just as serious as all the other rules.
>
> So here, not for the first time, you are using language which has the
> only purpose to hurt other people (for which reason ever, it doesn't
> matter). This is therefore a very clear violation to the above
> mentioned rule. You statement "suck it" (guess what) is also an obvious
> and disgusting example of a masculist culture which hurts our community
> as a whole and I strongly believe we should not tolerate that.
>
> And yes this was a spam mail. And it's even needless to say that
> replying to a spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion
> on that matter.
>
> Please learn to behave or leave us alone.
>
> [1]: https://openwrt.org/rules

+1


>
>
> >
> > On 11/12/2019, rqgxfc  wrote:
> > >
> > >
> > > Hello Sir ，
> > >
> > > We are  a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd  . 
> > > Now
> > > we are very interested in your products , we will plan to  sell your
> > > products in the Chinese market . If you are interested in cooperation,
> > > please send us a catalog and pricelist .w
> > > Looking forward to receiving your reply .
> > >
> > > Best regards,
> > > Catherina
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Inquery

[Jonas Gorski]

On Wed, 11 Dec 2019 at 15:22, Daniel Golle  wrote:
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each
> other." is meant just as serious as all the other rules.
>
> So here, not for the first time, you are using language which has the
> only purpose to hurt other people (for which reason ever, it doesn't
> matter). This is therefore a very clear violation to the above
> mentioned rule. You statement "suck it" (guess what) is also an obvious
> and disgusting example of a masculist culture which hurts our community
> as a whole and I strongly believe we should not tolerate that.
>
> And yes this was a spam mail. And it's even needless to say that
> replying to a spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion
> on that matter.
>
> Please learn to behave or leave us alone.

+1

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

Re: [OpenWrt-Devel] Inquery

[WRT Burner]

On 11/12/2019 15:22, Daniel Golle wrote:
> And it's even needless to say that
> replying to a spam email in which ever way will always make it worse.

+1. There is no constructive value in replying to spam. Let's keep openwrt-devel
nice and clean.

On 11/12/2019 15:22, Daniel Golle wrote:
> You statement "suck it" (guess what) is also an obvious
> and disgusting example of a masculist culture which hurts our community
> as a whole and I strongly believe we should not tolerate that.

-1. This is a software development mailing list, not tumblr.com.

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

Re: [OpenWrt-Devel] Inquery

[Petr Štetiar]

> Please learn to behave or leave us alone.

+2

-- ynezz

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

Re: [OpenWrt-Devel] Inquery

[Piotr Dymacz]

On 11.12.2019 15:22, Daniel Golle wrote:


As a community, we decided to give our self a set of minimal rules[1].
And even though it is in the last position, rule #12 "Be nice to each
other." is meant just as serious as all the other rules.

So here, not for the first time, you are using language which has the
only purpose to hurt other people (for which reason ever, it doesn't
matter). This is therefore a very clear violation to the above
mentioned rule. You statement "suck it" (guess what) is also an obvious
and disgusting example of a masculist culture which hurts our community
as a whole and I strongly believe we should not tolerate that.

And yes this was a spam mail. And it's even needless to say that
replying to a spam email in which ever way will always make it worse.
But that's not the point here and I will not engage in any discussion
on that matter.

Please learn to behave or leave us alone.

[1]: https://openwrt.org/rules


+1

--
Cheers,
Piotr

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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

[Paul Fertser]

On Wed, Dec 11, 2019 at 05:44:59PM +0300, Paul Fertser wrote:
> +define Build/Patch
> + $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p 
> $(PKG_BUILD_DIR)/patches)
> + $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
> +ifeq ($(BUILD_VARIANT),smallbuffers)
> + $(call 
> PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
> +endif
> + $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used)
> +endef

This is not correctly creating the patches-smallbuffers directory,
I'll fix it for v2 along with other review points (if this approach is
considered worthy at all).

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

[OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

[Paul Fertser]

According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.

Since the two patches in question might have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.

[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details_id=2664

Signed-off-by: Paul Fertser 
---
 package/kernel/ath10k-ct/Makefile | 30 +++-
 ...0-0010-ath10k-limit-htt-rx-ring-size.patch | 22 ++
 ...60-0011-ath10k-limit-pci-buffer-size.patch | 76 +++
 3 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 
package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
 create mode 100644 
package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch

diff --git a/package/kernel/ath10k-ct/Makefile 
b/package/kernel/ath10k-ct/Makefile
index dbf75fe174..d5726a1c88 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -35,6 +35,7 @@ define KernelPackage/ath10k-ct
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
   AUTOLOAD:=$(call AutoProbe,ath10k_pci)
   PROVIDES:=kmod-ath10k
+  VARIANT:=regular
 endef
 
 define KernelPackage/ath10k-ct/config
@@ -42,7 +43,17 @@ define KernelPackage/ath10k-ct/config
config ATH10K-CT_LEDS
bool "Enable LED support"
default y
-   depends on PACKAGE_kmod-ath10k-ct
+   depends on PACKAGE_kmod-ath10k-ct || 
PACKAGE_kmod-ath10k-ct-smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers
+$(call KernelPackage/ath10k-ct)
+  TITLE+= (small buffers to work on low-RAM devices)
+  VARIANT:=smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers/config
+$(call KernelPackage/ath10k-ct/config)
 endef
 
 NOSTDINC_FLAGS = \
@@ -90,6 +101,22 @@ ifeq ($(CONFIG_ATH10K-CT_LEDS),y)
   NOSTDINC_FLAGS += -DCONFIG_ATH10K_LEDS
 endif
 
+define Build/Patch
+   $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p 
$(PKG_BUILD_DIR)/patches)
+   $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+   $(call 
PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+   $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used)
+endef
+
+define Quilt/Refresh/Package
+   $(call Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+   $(call 
Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+endef
+
 define Build/Configure
cp $(STAGING_DIR)/usr/include/mac80211/ath/*.h $(PKG_BUILD_DIR)
 endef
@@ -107,3 +134,4 @@ define Build/Compile
 endef
 
 $(eval $(call KernelPackage,ath10k-ct))
+$(eval $(call KernelPackage,ath10k-ct-smallbuffers))
diff --git 
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
new file mode 100644
index 00..f73b02e5ef
--- /dev/null
+++ 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
@@ -0,0 +1,22 @@
+--- a/ath10k-4.19/htt.h
 b/ath10k-4.19/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+ 
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
+--- a/ath10k-5.2/htt.h
 b/ath10k-5.2/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+ 
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
diff --git 
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
new file mode 100644
index 00..27c0032bfb
--- /dev/null
+++ 
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
@@ -0,0 +1,76 @@
+--- a/ath10k-4.19/pci.c
 b/ath10k-4.19/pci.c
+@@ -131,7 +131,7 @@ static struct ce_attr host_ce_config_wla
+   .flags = CE_ATTR_FLAGS,
+   .src_nentries = 0,
+   .src_sz_max = 2048,
+-  

Re: [OpenWrt-Devel] Inquery

[John Crispin]

On 11/12/2019 15:22, Daniel Golle wrote:

As a community, we decided to give our self a set of minimal rules[1].
And even though it is in the last position, rule #12 "Be nice to each
other." is meant just as serious as all the other rules.

So here, not for the first time, you are using language which has the
only purpose to hurt other people (for which reason ever, it doesn't
matter). This is therefore a very clear violation to the above
mentioned rule. You statement "suck it" (guess what) is also an obvious
and disgusting example of a masculist culture which hurts our community
as a whole and I strongly believe we should not tolerate that.

And yes this was a spam mail. And it's even needless to say that
replying to a spam email in which ever way will always make it worse.
But that's not the point here and I will not engage in any discussion
on that matter.

Please learn to behave or leave us alone.

[1]:https://openwrt.org/rules


+1

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

Re: [OpenWrt-Devel] Inquery

[Daniel Golle]

Hi Tomislav,

On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
> suck it

As a community, we decided to give our self a set of minimal rules[1].
And even though it is in the last position, rule #12 "Be nice to each
other." is meant just as serious as all the other rules.

So here, not for the first time, you are using language which has the
only purpose to hurt other people (for which reason ever, it doesn't
matter). This is therefore a very clear violation to the above
mentioned rule. You statement "suck it" (guess what) is also an obvious
and disgusting example of a masculist culture which hurts our community
as a whole and I strongly believe we should not tolerate that.

And yes this was a spam mail. And it's even needless to say that
replying to a spam email in which ever way will always make it worse.
But that's not the point here and I will not engage in any discussion
on that matter.

Please learn to behave or leave us alone.

[1]: https://openwrt.org/rules


> 
> On 11/12/2019, rqgxfc  wrote:
> >
> >
> > Hello Sir ，
> >
> > We are  a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd  . Now
> > we are very interested in your products , we will plan to  sell your
> > products in the Chinese market . If you are interested in cooperation,
> > please send us a catalog and pricelist .w
> > Looking forward to receiving your reply .
> >
> > Best regards,
> > Catherina
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[OpenWrt-Devel] [PATCH v4] This separates the options for signature creation and verification

[Paul Spooren]

* SIGNED_PACKAGES create Packages.sig
* SIGNED_IMAGES add ucert signature to created images
* CHECK_SIGNATURE add verification capabilities to images
* INSTALL_LOCAL_KEY add local key-build to /etc/opkg/keys

Right now the buildbot.git contains some hacks to create images that
have signature verification capabilities while not storing private keys
on buildbot slaves. This commit allows to disable these steps for the
buildbots and only perform signing on the master.

Signed-off-by: Paul Spooren 
---
v4: replace ifdef with ifneq - Makefile magic
-ifdef CONFIG_SIGNED_PACKAGES
+ifneq ($(CONFIG_SIGNED_PACKAGES),)

 config/Config-build.in  | 12 ++--
 include/image-commands.mk   | 13 -
 package/base-files/Makefile | 20 +++-
 3 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/config/Config-build.in b/config/Config-build.in
index 872e5c12ab..af5de42ac6 100644
--- a/config/Config-build.in
+++ b/config/Config-build.in
@@ -37,13 +37,21 @@ menu "Global build settings"
  - Enabling per-device rootfs support
  ...
 
+   config INSTALL_LOCAL_KEY
+   bool "Install local usign key into image"
+   default y if !BUILDBOT
+
config SIGNED_PACKAGES
bool "Cryptographically signed package lists"
-   default y
+   default y if !BUILDBOT
+
+   config SIGNED_IMAGES
+   bool "Cryptographically signed firmware images"
+   default y if !BUILDBOT
 
config SIGNATURE_CHECK
bool "Enable signature checking in opkg"
-   default SIGNED_PACKAGES
+   default y
 
comment "General build options"
 
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 5dfd6a2c2f..3d10b18bc8 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -373,11 +373,14 @@ metadata_json = \
 
 define Build/append-metadata
$(if $(SUPPORTED_DEVICES),-echo $(call 
metadata_json,$(SUPPORTED_DEVICES)) | fwtool -I - $@)
-   [ ! -s "$(BUILD_KEY)" -o ! -s "$(BUILD_KEY).ucert" -o ! -s "$@" ] || { \
-   cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
-   usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
-   ucert -A -c "$@.ucert" -x "$@.sig" ;\
-   fwtool -S "$@.ucert" "$@" ;\
+   [ -z "$(SIGNED_IMAGES)" \
+   -o ! -s "$(BUILD_KEY)" \
+   -o ! -s "$(BUILD_KEY).ucert" \
+   -o ! -s "$@" ] || { \
+   cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
+   usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
+   ucert -A -c "$@.ucert" -x "$@.sig" ;\
+   fwtool -S "$@.ucert" "$@" ;\
}
 endef
 
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index cf5166772d..e95a155124 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -37,7 +37,7 @@ endif
 define Package/base-files
   SECTION:=base
   CATEGORY:=Base system
-  DEPENDS:=+netifd +libc +procd +jsonfilter +SIGNED_PACKAGES:usign 
+SIGNED_PACKAGES:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool
+  DEPENDS:=+netifd +libc +procd +jsonfilter +SIGNATURE_CHECK:usign 
+SIGNATURE_CHECK:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool
   TITLE:=Base filesystem for OpenWrt
   URL:=http://openwrt.org/
   VERSION:=$(PKG_RELEASE)-$(REVISION)
@@ -107,7 +107,7 @@ define Build/Compile/Default
 endef
 Build/Compile = $(Build/Compile/Default)
 
-ifdef CONFIG_SIGNED_PACKAGES
+ifneq ($(CONFIG_SIGNED_PACKAGES),)
   define Build/Configure
[ -s $(BUILD_KEY) -a -s $(BUILD_KEY).pub ] || \
$(STAGING_DIR_HOST)/bin/usign -G -s $(BUILD_KEY) -p 
$(BUILD_KEY).pub -c "Local build key"
@@ -116,12 +116,6 @@ ifdef CONFIG_SIGNED_PACKAGES
$(STAGING_DIR_HOST)/bin/ucert -I -c $(BUILD_KEY).ucert -p 
$(BUILD_KEY).pub -s $(BUILD_KEY)
 
   endef
-
-  define Package/base-files/install-key
-   mkdir -p $(1)/etc/opkg/keys
-   $(CP) $(BUILD_KEY).pub 
$(1)/etc/opkg/keys/`$(STAGING_DIR_HOST)/bin/usign -F -p $(BUILD_KEY).pub`
-
-  endef
 endif
 
 ifeq ($(CONFIG_NAND_SUPPORT),)
@@ -130,9 +124,17 @@ ifeq ($(CONFIG_NAND_SUPPORT),)
   endef
 endif
 
+ifneq ($(CONFIG_INSTALL_LOCAL_KEY),)
+  define Package/base-files/install-local-key
+   mkdir -p $(1)/etc/opkg/keys
+   $(CP) $(BUILD_KEY).pub 
$(1)/etc/opkg/keys/`$(STAGING_DIR_HOST)/bin/usign \
+   -F -p $(BUILD_KEY).pub`
+  endef
+endif
+
 define Package/base-files/install
$(CP) ./files/* $(1)/
-   $(Package/base-files/install-key)
+   $(Package/base-files/install-local-key)
$(Package/base-files/nand-support)
if [ -d $(GENERIC_PLATFORM_DIR)/base-files/. ]; then \
$(CP) $(GENERIC_PLATFORM_DIR)/base-files/* $(1)/; \
-- 
2.24.0


___
openwrt-devel mailing list

Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting

[Jo-Philipp Wich]

Hi,

> Question is, if it's worth the hassle for a feature which is targeted more
> towards the expert users.

from my pov - it is not worth overengineering this feature. The proposed
patch is more than adequate. It increases the probability of the message
getting delivered without additional code complexity.

~ Jo

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

Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting

[Paul Fertser]

On Wed, Dec 11, 2019 at 12:47:22PM +0100, Petr Štetiar wrote:
> Paul Fertser  [2019-12-11 14:03:53]:
> > Waiting with a timeout poses a question of what that timeout should be set
> > to; and if that's reasonable to extend current 2 seconds with any
> > significant amount.
> 
> As you've witnessed this default value doesn't work well in some cases.

The problem I faced was because the message is sent only once _before_
timeout starts ticking, so no matter what it's set to, the message
wouldn't be there.

> > Current documentation says a message should be sent.
> 
> So now, this would need to be rephrased from current 0 or 1, to 0 to N, where
> N depends on config settings (timeout value).

Documentation [0] says "Wait (with a packet sniffer) for a special
broadcast packet and press a button". So I think with this patch
documentation changes are not strictly necessary, it still works the
same way, you wait for the packet and press a button.

> > Do you have any other possible solution in mind?
> 
> (nope, just thinking aloud)
> 
> If the fixed value doesn't work for all use cases, then its not fixed variable
> anymore and should be variable, thus config option, probably finetuned per
> target/device.

Currently all devices wait for 2 seconds during normal bootup no
matter what. Without my patch any value for that timeout wouldn't help
with the UDP message.

[0] 
https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting

[Petr Štetiar]

Paul Fertser  [2019-12-11 14:03:53]:

> Waiting with a timeout poses a question of what that timeout should be set
> to; and if that's reasonable to extend current 2 seconds with any
> significant amount.

As you've witnessed this default value doesn't work well in some cases.

> Current documentation says a message should be sent.

So now, this would need to be rephrased from current 0 or 1, to 0 to N, where
N depends on config settings (timeout value).

> Do you have any other possible solution in mind?

(nope, just thinking aloud)

If the fixed value doesn't work for all use cases, then its not fixed variable
anymore and should be variable, thus config option, probably finetuned per
target/device.

Question is, if it's worth the hassle for a feature which is targeted more
towards the expert users.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4

[Paul Fertser]

Hello Lars,

On Fri, Nov 08, 2019 at 03:12:02PM +0700, Lars Melin wrote:
> On 11/8/2019 14:50, Paul Fertser wrote:
> >  From working with uIP before on an embedded target I know that it
> > doesn't support delayed ACKs in any form, for any packet it sends it
> > waits for an ACK before sending the next, and I would guess that for
> > any packet it receives it's better to wait for its ACK before sending
> > the next (as I see plenty of duplicated ACKs from this backup server
> > all confirming just the first packet received, and then long wait
> > before retransmission). The problem is in the number of packets sent,
> > not the size (so changing MTU/MSS doesn't help much).
> > 
> > I haven't been able to find a way to trick it into behaving, sorry.
> > 
> 
> Don't complicate simple things, all D-Link routers have a recovery web page
> and you access it with your browser, not with curl.

You quoted my message and it doesn't contradict "having a recovery web
page" idea. However, it clearly says that I can't meaningfully use it
_anyhow_, neither with curl nor with my browser. Please reread the
quote and you'll see it is not simple. Do you want me to send you a
PCAP file as a proof?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting

[Paul Fertser]

Hi,

On Tue, Dec 10, 2019 at 03:42:13PM +0100, Petr Štetiar wrote:
> Paul Fertser  [2019-12-10 17:24:20]:
> > in cases when the interface is brought up faster it leads to two messages
> 
> in cases when the interface is brought up slower it leads to no message.
> 
> To me it just seems like a workaround to fix your use case, not a proper fix.

You're right, I mentioned "inherently racy" in the commit message
exactly because of that.

Waiting for LOWER_UP there without a timeout is not a solution because
in the normal bootup case there might be nothing attached to the LAN
so the boot will be effectively halted forever. Waiting with a timeout
poses a question of what that timeout should be set to; and if that's
reasonable to extend current 2 seconds with any significant amount.

Current documentation says a message should be sent. Current code
works for some devices and fails for other devices. My patch improves
the situation without adding any code complexity (indeed, it's even
removing one line) or wasting boot time.

Do you have any other possible solution in mind?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: [OpenWrt-Devel] [PATCH 2/2] sunxi: construct DTS name from device node name and SOC

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: Tomasz Maciej Nowak [mailto:tome...@o2.pl]
> Sent: Dienstag, 10. Dezember 2019 14:39
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] sunxi: construct DTS name from
> device node name and SOC
> 
> Hi Adrian.
> 
> W dniu 07.12.2019 o 23:28, Adrian Schmutzler pisze:
> > The device part in the SUNXI_DTS variable always corresponds to
> > device node name. This is another redundancy that can be removed
> > by calculating the DTS name from a newly introduced SUNXI_SOC
> > variable and the node name.
> >
> > Signed-off-by: Adrian Schmutzler 
> > ---
> >  target/linux/sunxi/image/Makefile  |  5 ++-
> >  target/linux/sunxi/image/cortex-a53.mk | 18 +++
> >  target/linux/sunxi/image/cortex-a7.mk  | 44 +-
> >  target/linux/sunxi/image/cortex-a8.mk  | 13 
> >  4 files changed, 45 insertions(+), 35 deletions(-)
> >
> > diff --git a/target/linux/sunxi/image/Makefile
> b/target/linux/sunxi/image/Makefile
> > index 04e0abee49..929f4c70f9 100644
> > --- a/target/linux/sunxi/image/Makefile
> > +++ b/target/linux/sunxi/image/Makefile
> > @@ -32,12 +32,15 @@ endef
> >  # why \x00\x00\x00\x00 for zImage-initramfs
> >  define Device/Default
> >PROFILES := Default
> > -  DEVICE_VARS := SUNXI_DTS SUNXI_UBOOT
> > +  DEVICE_VARS := SUNXI_SOC SUNXI_DTS SUNXI_DTS_DIR SUNXI_UBOOT
> 
> Instead of adding new target speciffic variables, wouldn't using already
> specified ones be better? We have DEVICE_DTS and DEVICE_DTS_DIR. Also the

Based on
https://github.com/openwrt/openwrt/commit/7a8d3432c739c6ff038295176e8b6324e92fc116
I had the impression that DEVICE_DTS and DEVICE_DTS_DIR are reserved keywords 
for a particular mechanism to append DTB.

Thus, and since the target has been using "custom" SUNXI_DTS variable so far, I 
decided to stick to that pattern.

> SUNXI_SOC feels bit redundant since it needs to be specified for each device
> and it could be replaced with DEVICE_DTS := sun50i-h5-$(1) or simply full dts
> name.

No, because I need to cut down the device name, so it would be
DEVICE_DTS := sun50i-h5-$(lastword $(subst _, ,$(1)))
which I would not like to repeat over and over.

I admit that changing the DTS variable is the weakest part in my patchset. 
However, I think introducing the SUNXI_SOC and SUNXI_DTS_DIR will make the 
target more organized. Despite, by this it becomes more consistent with other 
targets where this has been reorganized recently (i.e. ath79 and ramips, where 
we use ATH_SOC and MTK_SOC to do the very same).
At least I personally think that this is better that repeating the very same 
name again in the DTS definition.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Inquery

[Tom Psyborg]

suck it

On 11/12/2019, rqgxfc  wrote:
>
>
> Hello Sir ，
>
> We are  a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd  . Now
> we are very interested in your products , we will plan to  sell your
> products in the Chinese market . If you are interested in cooperation,
> please send us a catalog and pricelist .w
> Looking forward to receiving your reply .
>
> Best regards,
> Catherina

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

Re: [OpenWrt-Devel] [PATCH] mac80211: switch to upstream owl-loader driver

[Russell Senior]

This commit broke wifi on the Buffalo WZR600DHP.  See:
https://bugs.openwrt.org/index.php?do=details_id=2668

On Fri, Nov 22, 2019 at 12:00 PM Christian Lamparter 
wrote:

> On Monday, 18 November 2019 00:34:01 CET Hauke Mehrtens wrote:
> > > +--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> > >  b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> > > +@@ -84,6 +84,10 @@
> > > +   val = swahb32(val);
> > > +   }
> > > +
> > > ++#ifdef CONFIG_LANTIQ
> > > ++  val = swab32(val);
> > > ++#endif
> >
> > Lantiq is big endian, are there other big endian system which do not
> > need this byte swap?
>
> From what I vaguely remember (I know that Mathias explained it to me
> once.),
> that special hack was necessary due to Lantiq's pci(e?)-host silicon doing
> byteswaps just for 32-bit writes. The only other system that uses the
> owl-loader
> is ath79/ar71xx. This is a big-endian MIPS as well that didn't need the
> swap.
>
> (That said, I don't remember what was the reason for going with
> __raw_writel
> rather than "iowrite32" though. At least ath9k is using it for the pci
> access
> just fine everywhere.)
>
> Anyone fancy checking out lantiq and ath79 devices with a AR92XX without
> the
> swap above and the __raw_writel replaced by iowrite32?
>
> > > ++
> > > +   __raw_writel(val, mem + reg);
> > > +   usleep_range(100, 120);
> > > +   }
>
> Regards,
> Christian
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Requesting a custom firmware for a router

[Alberto Bursi]

On 11/12/19 07:17, John Wick wrote:
Kind request to upload the custom firmware for router model TP-LINK 
TD-W8951ND v5.0 if possible





OpenWrt for that device is impossible. Device is using unsupported CPU 
(Ralink RT63365E) has 8MB RAM (which is less than half of the minimum 
required) and 2MB flash storage (also less than half minimum required).


See here for someone that opened that device and posted specifications 
and info (in russian) http://monitor.espec.ws/section5/topic269462.html


-Alberto


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