Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID

[Jonas Gorski]

On Tue, 7 May 2024 at 12:16, Bjørn Mork  wrote:
>
> Stijn Tintel  writes:
>
> > On 27/04/2024 11:16, Bjørn Mork wrote:
> >> st...@linux-ipv6.be writes:
> >>
> >>> phy_write_paged(phydev, 31, 27, 0x0002);
> >>> val = phy_read_paged(phydev, 31, 28);
> >> ..
> >>> phy_write_paged(phydev, 0x1f, 0x1b, 0x0002);
> >>> val = phy_read_paged(phydev, 0x1f, 0x1c);
> >>
> >> While you're doing spring cleaning  That piece of cut-n-paste code
> >> looks very funny.
> >>
> > I'd gladly do some more spring cleaning, but what's your actual
> > suggestion here? Use hex everywhere instead of mixed hex/base 10?
>
> I would have used hex since that 0x1f looks like a mask.

We can find out if we look at the function signature:

int phy_read_paged(struct phy_device *phydev, int page, u32 regnum);

so that's a page, not a mask. Upstream usage is mostly hex, with the
icplus phy driver being the sole exception. And unsurprisingly,
realtek drivers always use magic numbers, never defines. Can't have
other people understand how the hardware works.

Best Regards,
Jonas

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

Re: snort3 (at least) not building in 23.05

[Jonas Gorski]

Hi Eric,

On Tue, 9 Apr 2024 at 18:59, Eric via openwrt-devel
 wrote:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- Forwarded message --
> From: Eric 
> To: openwrt-devel 
> Cc:
> Bcc:
> Date: Tue, 09 Apr 2024 16:59:01 +
> Subject: snort3 (at least) not building in 23.05
> I noticed this before, but never looked at it.  snort3 is building packages 
> for all releases and snapshot since it was introduced, but it is not building 
> in 23.05.
> https://forum.openwrt.org/t/snort-on-openwrt-23-05-3/194225
>
> If I run
> $ scripts/feeds clean
> $ make clean
> $ git checkout main (or v23.05.3)
> $ scripts/feeds update -a
> $ scripts/feeds install -1
>
> then
> $ find . -iname '*snort3*'
>
> everything looks fine, both main and 23.05 branch show the expected package
>
> $ ll package/feeds/packages/snort3/
> Permissions Size User  Date ModifiedGit Name
> drwxr-xr-x@- efahlgren 2024-04-09 09:27  -- .
> drwxr-xr-x@- efahlgren 2024-04-09 09:27  -- ..
> drwxr-xr-x@- efahlgren 2024-04-09 09:27  -- files
> .rw-r--r--@ 4.3k efahlgren 2024-04-09 09:27  -- Makefile
>
> I do
> $ make menuconfig
> and then search '/snort3', both v23.05.3 and main show expected path at 
> 'Network -> Firewall', but in 23.05 when I navigate to that tree, snort3 does 
> not appear at the expected location.
>
> So, I manually modify .config, adding 'CONFIG_PACKAGE_snort3=m', then run 
> 'make defconfig', it disappears from .config
>
> $ grep snort .config
> CONFIG_PACKAGE_snort3=m
>
> $ make defconfig
> WARNING: Makefile 'package/feeds/packages/libmpc/Makefile' has a dependency 
> on 'libmpfr', which does not exist
> WARNING: Makefile 'package/feeds/packages/python-gmpy2/Makefile' has a 
> dependency on 'libmpfr', which does not exist
> #
> # configuration written to .config
> #
>
> $ grep snort .config
> # CONFIG_PACKAGE_snort is not set
>
> And then, of course, building results in no snort3...
>
> Anyone have a clue what could do this?

A quick look at the package history points at
https://github.com/openwrt/packages/commit/cd5f6637f2c500aa24ed453f510d5e5821c25496
which added a dependency on HAS_LUAJIT_ARCH, but the commit adding the
symbol 
https://github.com/openwrt/packages/commit/5eea661fdb797462412530a07e73c27e57eb8677
was never backported to 23.05. So snort3 in 23.05 depends on a
non-existing symbol, causing it to be unselectable/buildable.

Can you open an issue for that at https://github.com/openwrt/packages/issues ?

Best Regards,
Jonas

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

Re: [PATCH v2 6/9] router: Apply updated values from RFC8319 (updates RFC4861) to RA/ND

[Jonas Gorski]

Hi,

On Fri, 5 Apr 2024 at 13:11, Paul Donald  wrote:
>
> From: Paul Donald 
>
> https://www.rfc-editor.org/rfc/rfc8319#section-4
>
> Signed-off-by: Paul Donald 
> Reviewed-by: Daniel Golle 
> ---
>  src/router.c |  6 --
>  src/router.h | 21 -
>  2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/src/router.c b/src/router.c
> index a1a7829..4239aa8 100644
> --- a/src/router.c
> +++ b/src/router.c
> @@ -377,8 +377,10 @@ static uint32_t calc_ra_lifetime(struct interface 
> *iface, uint32_t maxival)
> lifetime = iface->ra_lifetime;
> if (lifetime > 0 && lifetime < maxival)
> lifetime = maxival;
> -   else if (lifetime > 9000)
> -   lifetime = 9000;
> +   else if (lifetime > AdvDefaultLifetime)
> +   lifetime = AdvDefaultLifetime;

This clamping should be done in src/config.c, where we get
iface->ra_lifetime from ubus.

> +   else if (lifetime > RouterLifetime)
> +   lifetime = RouterLifetime;

The only caller of calc_ra_lifetime() already clamps the returned
value to UINT16_MAX ( = 65535), you could as well drop all limiting
here now.

> }
>
> return lifetime;
> diff --git a/src/router.h b/src/router.h
> index 0444da8..b91c60a 100644
> --- a/src/router.h
> +++ b/src/router.h
> @@ -32,8 +32,27 @@ struct icmpv6_opt {
>
>  #define MaxInitialRtrAdvInterval   16
>  #define MaxInitialRtAdvs   3
> -#define MaxRtrAdvInterval  1800
> +/* RFC8319 §4
> +   This document updates §4.2 and 6.2.1 of [RFC4861] to change
> +   the following router configuration variables.
> +
> +   In §6.2.1, inside the paragraph that defines
> +   MaxRtrAdvInterval, change 1800 to 65535 seconds.
> +
> +   In §6.2.1, inside the paragraph that defines
> +   AdvDefaultLifetime, change 9000 to 65535 seconds.
> +*/
> +#define MaxRtrAdvInterval  65535

This is a configuration variable, not a constant, naming it like a
defined configuration variable is confusing.

RFC4861 says the default for MaxRtrAdvInterval is 600 seconds (which
we use in src/config.c), not 65535. The maximum allowed value is
increased to 65535 in RFC8319.

Where this limit should be applied is in src/config.c, where we get
the IFACE_ATTR_RA_MAXINTERVAL value (which is currently missing a
range check).

>  #define MinRtrAdvInterval  3
> +#define AdvDefaultLifetime 65535

Likewise, this should be used in src/config.c for a range check of
IFACE_ATTR_RA_LIFETIME.

IFACE_ATTR_RA_MININTERVAL could also use a range check.

> +/* RFC8319 §4
> +   This document updates §4.2 and 6.2.1 of [RFC4861] to change
> +   the following router configuration variables.
> +
> +   In §4.2, inside the paragraph that defines Router Lifetime,
> +   change 9000 to 65535 seconds.
> +*/
> +#define RouterLifetime  65535

This is a limit, not the value to use, so it should be named appropriately.

Best Regards,
Jonas

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

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[Jonas Gorski]

On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel
 wrote:
> Am 7. Februar 2024 11:53:55 MEZ schrieb Jonas Gorski :
> >On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
> >>
> >> Create a script for automating kernel version changes.  This
> >> generates a pair of commits which cause history to remain attached
> >> to all versioned configuration files.
> >
> >Why is this script needed? What exactly does it do? Does it preserve
> >bisectability? How would you use it? I see neither a help message nor
> >any usage examples.
> >
> >Please provide more detailed explanation in the commit message,
> >especially since perl isn't the most common or easy to read language.
> >
> >Regards,
> >Jonas
>
> This might be of help
> <https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html>
> Elliott linked it in his previous mail.
>
> It explains the problem fairly well.
>
> Short version:
> Right now every new kernel version creates a new kernel config file as a copy 
> of the old one which doesn't preserve the git history which hinders the usage 
> of git blame.

I'm aware of the discussion, my point is that the information /
context should to be in the commit description, not in an external
place with no reference to it. If someone not aware of the email
thread looks at the commit I doubt they will be able to understand the
issue this is trying to solve, or how it is solving it. And since
neither the issue, the solution, nor the script itself are trivial all
three need some sort of explanation in the commit message.

FWIW, git blame also supports a find copies harder (-C) that can
detect copies, not just delete/adds as renames (can be passed multiple
times for even harder finding). Unfortunately it's rather slow and
does not work as well as other git command's find copies harder. Not
sure why. Might be worth investigating.

> git bisect should still work fairly well even without the change.

What does "fairly well" mean? Either this produces commits that work,
or it produces commits that break the build. There is no in between.

Regards,
Jonas

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

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[Jonas Gorski]

On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
>
> Create a script for automating kernel version changes.  This
> generates a pair of commits which cause history to remain attached
> to all versioned configuration files.

Why is this script needed? What exactly does it do? Does it preserve
bisectability? How would you use it? I see neither a help message nor
any usage examples.

Please provide more detailed explanation in the commit message,
especially since perl isn't the most common or easy to read language.

Regards,
Jonas

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

Re: kernel config files and subtarget config-default files

[Jonas Gorski]

Hi,

On Mon, 22 Jan 2024 at 21:27, Tim Harvey  wrote:
>
> Greetings,
>
> What is the best known method to add items to config-$KVER when you
> have subtargets with individual config-default files - specifically
> how are the items in this file ordered properly? Maybe the norm is to
> put them alphabetically (even though the kernel doesn't always do
> this) or to put them at the bottom? When using config-default and even
> config-$KVER config fragments they don't compare well to a full linux
> .config file in order to know where they should be placed.

The original intended way is via kernel's menuconfig:

make kernel_menuconfig CONFIG_TARGET=subtarget_target

which will sort them for you and drop any duplicated configs with the
same value as the generic/subtarget config.

this may produce a lot of changes though through if this hasn't been
done for a while.

Likewise to modify the subtarget config you would use CONFIG_TARGET=subtarget

You could also use kernel_oldconfig to refresh the configs after
adding the option manually.

Best Regards,
Jonas

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

Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"

[Jonas Gorski]

On Wed, 13 Dec 2023 at 23:55, Elliott Mitchell  wrote:
>
> On Wed, Dec 13, 2023 at 01:59:07PM +0100, Martin Schiller wrote:
> > On 2023-12-13 02:45, Elliott Mitchell wrote:
> > >
> > > No idea, I wasn't able to find very much information when I looked at
> > > this.
> > >
> > > I did find:
> > > https://lists.openwrt.org/pipermail/openwrt-devel/2018-August/019479.html
> > >
> > > This doesn't tell me what platform Martin Schiller was trying for.
> > > 17f30bfcf7 makes me suspect Martin Schiller was simply trying to do
> > > this
> > > to all x86 platforms and didn't realize geode was a specialized target.
> > >
> > > Alternatively Martin Schiller may have been trying to use a MCP23S08 on
> > > a
> > > Geode processor.  Unfortunately using CONFIG_X86_INTEL_LPSS is a
> > > bizzare
> > > choice since CONFIG_X86_AMD_PLATFORM_DEVICE has fewer side-effects and
> > > then current Geodes were AMD processors.
> > >
> > > With sparse information the former is my present belief.  Is anyone
> > > reading this list using a Geode processor with a MCP23S08?  Otherwise
> > > my
> > > present belief is only people with Intel x86 processors are interested
> > > in
> > > the MCP23S08.
>
> > The problem was and is that the PINCTRL subsystem can only be used on
> > x86
> > platforms if either X86_INTEL_LPSS or X86_AMD_PLATFORM_DEVICE is
> > activated.
> > I no longer know why I chose the former at the time.
>
> Which leaves me suspecting the reason was you had a computer with a
> processor from Intel.
>
> > X86_AMD_PLATFORM_DEVICE is now activated for x86/generic and x86/64.
> >
> >  From my point of view, we can deactivate X86_INTEL_LPSS if no one else
> > need it.
>
> Seeing how Xiaopo Zhang submitted patches to enable them, I assume at
> least 1 other person used them on x86/64 at some point.
>
> What situation/hardware were YOU using CONFIG_PINCTRL for?
>
> Were you using CONFIG_PINCTRL on a desktop which had an Intel processor?
>
> Were you using CONFIG_PINCTRL on a system which had a Geode processor?
>
> If someone out there is actively using CONFIG_PINCTRL on a system with a
> Geode processor, I would disable CONFIG_X86_INTEL_LPSS and enable
> CONFIG_X86_AMD_PLATFORM_DEVICE.  The reason is both options select
> CONFIG_COMMON_CLK and CONFIG_PINCTRL, but CONFIG_X86_INTEL_LPSS
> additionally selects CONFIG_IOSF_MBI (less bloat).
>
> If my belief no one is using CONFIG_PINCTRL on a Geode platform is
> correct, then the original patch is correct.  From examination of the
> Linux kernel source, I believe none of Geode's normal peripherals go
> through the PINCTRL subsystem.
>
> Problem is too few people have systems with Geode processors in use, so
> support is difficult.

Here, I'll do some research work for you:

1. To select the MCP23S08 driver you need to have PINCTRL enabled
since 4.13 (see also [1]).
2. At time of Linux 4.14, PINCTRL was a non user-selectable symbol [2].
3. Therefore, a driver selecting this was needed in the kernel config
(it didn't matter which one).
4. In a later Linux release (4.15), PINCTRL was changed to a
user-selectable symbol [3].
5. Therefore, the intel driver is not needed anymore, but PINCTRL
needs to stay enabled.

And since we build the MCP23S08 driver as a module/kmod package, it
really doesn't matter if this driver is used or not; having it
available makes sure it can be installed if needed.

Micromanaging which drivers/modules should be available to which
(sub-)targets really doesn't provide much benefit compared to the
effort for it, unless the driver/module is one specific to the
hardware targeted by the (sub)target. And as you said, too few people
have systems with Geode processors, so getting a definite answer there
is difficult.

Best Regards,
Jonas

[1] 
https://github.com/openwrt/openwrt/commit/a904003b9b5fe2744ee5d5d8718c54d001f1c93e
[2] https://elixir.bootlin.com/linux/v4.14.333/source/drivers/pinctrl/Kconfig#L5
[3] 
https://github.com/torvalds/linux/commit/d219b924611a5cceb17cc6b9a8dd103ab9668c94

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

Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"

[Jonas Gorski]

Hi,

On Sun, 10 Dec 2023 at 18:51, Elliott Mitchell  wrote:
>
> Date: Fri, 3 Nov 2023 22:57:43 -0700
>
> Enabling an Intel chipset feature on a platform originally made by
> National Semiconductor and later bought by AMD.  Could we cut the Intel
> enthusiasm?
>
> This reverts commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f.

commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f says "This makes it
possible to use the MCP23S08 i/o expander on geode platforms with
linux 4.14."

So we don't need to enable PINCTRL (via other symbols) anymore for this?

Please add an explanation why this is fine now to the commit message.

Best Regards,
Jonas

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

Re: [PATCH RESEND 02/11] kernel/generic: remove CONFIG_FB_NOTIFY

[Jonas Gorski]

Hi,

On Sun, 10 Dec 2023 at 18:49, Elliott Mitchell  wrote:
>
> Date: Tue, 25 Apr 2023 16:23:20 -0700
>
> This option is automatically enabled by CONFIG_FB=y.  There is no
> reason to specifically enable it.

Unfortunately this change will cause the symbol to appear in target
configs when using make kernel_*config. Ideally a make kernel_*config
without any changes should result in no changed files (currently it
does so for many targets).

To avoid that, I guess adding the symbol to
target/linux/generic/config-filter should do the trick so it becomes
properly ignored for config management.

Best Regards,
Jonas

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

Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image

[Jonas Gorski]

Hi,

On Mon, 20 Nov 2023 at 02:37, Elliott Mitchell  wrote:
>
> On Sat, Nov 18, 2023 at 07:57:35AM +0100, Felix Fietkau wrote:
> > On 17.11.23 22:31, Elliott Mitchell wrote:
> > > On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote:
> > >> On 11.11.23 01:21, Elliott Mitchell wrote:
> > >> > This removes the requirement for to create a package for all modules.
> > >> > Now devices can simply specify in-tree drivers/other to be built as
> > >> > modules and they will be present in the resultant image.
> > >> >
> > >> > Signed-off-by: Elliott Mitchell 
> > >>
> > >> It seems to me that this completely ignores the use case of having
> > >> release builds that ship a lot of kernel modules as installable
> > >> packages. Did I misread something?
> > >> If not, this gets a strong NACK from me.
> > >
> > > Should be completely orthogonal, though it could have bugs.
> > >
> > > Using `cp -l` has two valuable effects:  First, it reduces storage space
> > > usage.  Second, it serves to mark module files as belonging to a package.
> > >
> > > My goal is previously setting a kernel option to "m" in a configuration
> > > file, but not having a package causes it to be built, then ignored.  I
> > > want this to do something sensible, not simply waste electricity
> > > building a module and then tossing it in the garbage.
> > >
> > > Hmm, come to think of it, that should be $(XARGS) (fix on commit?).
> >
> > Thanks for the explanation, it makes more sense to me now.
> > That said, I see a few pitfalls here:
> >
> > 1. If you select kernel modules that depend on other modules selected
> > via kmod packages, you end up with non-functional modules with missing
> > dependencies in the rootfs.
>
> Is this actually that much of a problem?  From what I've seen most kmod
> packages handled during image build get preinstalled onto the root fs
> image.  As such these would nominally function as long as the packages
> weren't removed.

If you do a build with ALL_KMODS=y because you don't know which kmods
you may need later on, and want to avoid having to reflash in this
case, there will be plenty of kmod packages build but not installed
into the rootfs.

>
> Wouldn't this also indicate breakage in the module package anyway?

No, not necessarily. Let's say there is a kmod-foo that packages FOO
(foo.ko). This is selected as =m.

Then you run kernel_*config and select BAR=m (bar.ko), since there is
no kmod defined for it. bar.ko has a dependency on foo.ko

With your patch (AFAIU) the bar.ko would be then installed in the
rootfs, but since foo.ko is packaged separately as a m-package, it
won't be in the rootfs => bar.ko is missing its dependencies in the
rootfs.

> > 2. If the kmod package selection accidentally ends up selecting extra
> > modules that aren't stored in the package, you end up with rootfs bloat.
>
> Eww, that would be gross.  As with the above, wouldn't this be indicating
> breakage in the module packaging anyway?

Maybe, but sometimes modules/drivers in the kernel default to =m for
silly reasons. And again as the above example, if the triggering kmod
package is selected as =m, then the additional modules land in the
rootfs without their dependencies.

> > I'm fine with the cp -l change, but I think adding all remaining modules
> > to the rootfs is not something we should do by default (maybe opt-in?)
>
> Perhaps.  This could also be handled by the approach the series as a
> whole is aiming for.  If kernel module building used a separate object
> directory from the kernel build, then modules selected in the device
> configuration could be isolated.

Maybe instead of putting them into the rootfs, we could wrap them in a
special package? Then you can select it if you want to include them in
your image or not. No idea what to name it, kmod-remaining?
kmod-unaccounted-for? kmod-not-appearing-in-the-definitions?

We could also try to wrap any unexpected .kos into autogenerated kmod
packages based in their names (e.g. if we find a foo.ko, we
autogenerate a kmod-foo.ipk for it), but these wouldn't be selectable
then in menuconfig. Also not sure how well the build system would
handle dynamic package generation.

Also going the other way around, maybe the build system should
warn/complain about any .ko found that isn't wrapped in a kmod-*
package.

WARNING: unpackaged kernel module found: foo/bar.ko

etc.

Regards,
Jonas

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

Re: [PATCH] Deactivate _FORTIFY_SOURCE in jitterentropy-base.c

[Jonas Gorski]

Hi,

On Mon, 30 Oct 2023 at 23:11, Hauke Mehrtens  wrote:
>
> This fixes compilation with glibc.
>
> _FORTIFY_SOURCE only works with compiler optimizations activated.
> We have to deactivate it when we set -O0.
>
> This fixes the following error message with glibc:
>  error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
> [-Werror=cpp]
>
> musl libc does not show an error message in this case, but has the same
> internal problems.
>
> Signed-off-by: Hauke Mehrtens 
> ---
>  CMakeLists.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index a1ee0c1..78954c0 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -22,8 +22,9 @@ ADD_EXECUTABLE(urngd
>  )
>  TARGET_LINK_LIBRARIES(urngd ${ubox})
>
> -# jitter RNG must not be compiled with optimizations
> +# jitter RNG must not be compiled with optimizations, _FORTIFY_SOURCE needs 
> optimizations
>  SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES 
> COMPILE_FLAGS -O0)
> +SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES 
> COMPILE_FLAGS -U_FORTIFY_SOURCE)

You dropped the -O0 here, that needs to stay to disable optimizations.

Regards,
Jonas

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

Re: [PATCH] build: explicitly specify Makefile generator

[Jonas Gorski]

On Sun, 8 Oct 2023 at 18:56,  wrote:
>
> From: Eicke Herbertz 
>
> When CMAKE_GENERATOR environment variable is defined, CMake will use the
> specified generator by default instead of "Unix Makefiles".
> This breaks the build of packages setting PKG_USE_NINJA to 0, like
> package/kernel/mt76.

Where does that CMAKE_GENERATOR environment variable come from? Would
it make sense to undefine it instead?

Regards,
Jonas

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

Re: [PATCH v2 0/9] Resurrect OpenWrt IXP4xx support

[Jonas Gorski]

Hi,

On Thu, 28 Sept 2023 at 15:29, Linus Walleij  wrote:
>
> XP4xx was deleted because of lack of maintenance in 2020.
>
> In the years since, the upstream Linux support for IXP4xx has
> been rewritten from scratch. It is now pretty well supported
> using device tree and modern subsystems that didn't exist
> 20 years ago when the first IXP4xx port was done.
>
> With the switch to kernel v6.1, OpenWrt has the required
> baseline to bring IXP4xx back.
>
> With the (suspiciously similarly named!) IPQ4xxx now supporting
> v6.1 exclusively, the door should be open for IXP4xx!
>
> This is a reimplementation of the IXP4xx support which is
> using all the contemporary abstractions, the only thing
> actually resurrected is the APEX boot loader. The port is
> thus "slim" and not patching a lot on the mainline kernel
> as pretty much everything is upstream.
>
> As a starter, we bring back two Gateworks reference designs,
> one for IXP42x and one for IXP43x, and the classic NSLU2
> NAS. We also bring back USRobotics USR8200 because it has
> active users and testers.
>
> Here you find binaries and illustrations if you want to check
> out how the support works right now, if you have an NSLU2
> you can flash the binary and rootfs and it "just works",
> though NSLU2 is not a default build:
> https://dflund.se/~triad/krad/ixp4xx/
>
> Thanks to Imre Kaloz add Krzysztof Halasa for all cheering
> and reference designs :)
>
> Thanks to Howard Harte and Joseph for stepping in and helping
> out with device support and debugging.
>
> Thanks for Hauke for the the in-depth review of the v1
> patch set.
>
> I am pretty confident that we can bring back any IXP4xx with
> this, they just need some time and focus. I will add more
> routers as time permits.
>
> I don't know who can import this from patches or pull request:
> it may be best if I just apply for commit access to the
> OpenWrt git repository and import it myself perhaps?

Fails to build for me when enabling all kmods:

Package kmod-crypto-lib-chacha20poly1305 is missing dependencies for
the following libraries:
chacha-neon.ko
poly1305-arm.ko
make[3]: *** [modules/crypto.mk:570:
/home/jonas/git/openwrt/bin/targets/ixp4xx/generic/packages/kmod-crypto-lib-chacha20poly1305_6.1.55-1_armeb_xscale.ipk]
Error 1

.config:
CONFIG_TARGET_ixp4xx=y
CONFIG_ALL_KMODS=y

Best Regards,
Jonas

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

Re: [PATCH v2 1/9] boot/apex: Restore the APEX boot loader

[Jonas Gorski]

On Wed, 4 Oct 2023 at 14:51, Robert Marko  wrote:
>
> On Thu, 28 Sept 2023 at 15:29, Linus Walleij  wrote:
> >
> > This is a partial revert of the deletion of the IXP4xx
> > target: we restore the APEX boot loader so we can use it
> > for the NSLU2 and related targets.
> >
> > The APEX upstream is as dead as it gets so I have applied
> > OpenWrts old patches on top of the never released
> > v1.6.10 version and forked it into an OpenWrt variant
> > on GitHub. If the upstream comes back alive I will
> > happily switch over to it.
> >
> > The file refers to the external GitHub, I suppose when
> > integrating this patch the file should be copied to OpenWrts
> > file repository and the file link changed.
> >
> > Signed-off-by: Linus Walleij 
> > ---
> > ChangeLog v1->v2:
> > - Do not default to "y", instead make the device target
> >   select apex by default.
> > - Do not package the boot loader into the rootfs image.
> >   Who wants that.
> > ---
> >  package/boot/apex/Makefile | 55 
> > ++
> >  1 file changed, 55 insertions(+)
> >
> > diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile
> > new file mode 100644
> > index ..817e15d8e643
> > --- /dev/null
> > +++ b/package/boot/apex/Makefile
> > @@ -0,0 +1,55 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# Copyright (C) 2006-2023 OpenWrt.org
> > +
> > +include $(TOPDIR)/rules.mk
> > +include $(INCLUDE_DIR)/kernel.mk
> > +
> > +PKG_NAME:=apex
> > +# This version was created from the stalled and unreleased v1.6.10
> > +# with some patches on top.
> > +PKG_VERSION:=1.6.10-openwrt
> > +PKG_RELEASE:=1
> > +
> > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> > +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/
> > +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640
> > +PKG_TARGETS:=bin
> > +
> > +include $(INCLUDE_DIR)/package.mk
> > +
> > +export GCC_HONOUR_COPTS=s
> > +
> > +define Package/apex
> > +  SECTION:=boot
> > +  CATEGORY:=Boot Loaders
> > +  DEPENDS:=@TARGET_ixp4xx
>
> This will probably break the package if one tries to bisect as there
> is no ixp4xx target yet.

No it's fine, it just depends on a non-existing symbol, so will be
unselectable until the ixp4xx target is added.

So exactly the right order here.

Best Regards,
Jonas

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

Re: [PATCH] bmips: bcm6368-enetsw: Bump max MTU to 1536

[Jonas Gorski]

On Sun, 1 Oct 2023 at 22:40, Linus Walleij  wrote:
>
> The max MTU for this ethernet switch is 1536 bytes, not 1510 as it is

The maximum *frame* size accepted is 1536 bytes, not MTU. A difference
of 14 bytes.

> right now. The available overhead is needed when using the DSA switch with
> a cascaded DSA switch, which is something that exist in real products,
> in this case the Inteno XG6846.
>
> Before this patch (on the lan1 DSA port in this case):
> dsa_slave_change_mtu: master->max_mtu = 9724, dev->max_mtu = 10218, DSA 
> overhead = 8
> dsa_slave_change_mtu: master = extsw, dev = lan1
> dsa_slave_change_mtu: master->max_mtu = 1510, dev->max_mtu = 9724, DSA 
> overhead = 6
> dsa_slave_change_mtu: master = eth0, dev = extsw
> dsa_slave_change_mtu new_master_mtu 1514 > mtu_limit 1510
> mdio_mux-0.1:00: nonfatal error -34 setting MTU to 1500 on port 0
>
> After this patch the error is gone.

Did you test this? As in verified that 1536 bytes long frames are
correctly received and sent?

> Cc: Álvaro Fernández Rojas 
> Cc: Jonas Gorski 
> Signed-off-by: Linus Walleij 
> ---
>  .../bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git 
> a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c 
> b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c
> index 321e95dbbb3d..96f4c303a433 100644
> --- a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c
> +++ b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c
> @@ -24,6 +24,7 @@
>
>  /* MTU */
>  #define ENETSW_TAG_SIZE(6 + VLAN_HLEN)
> +#define ENETSW_MAX_MTU 1536

Again, not MTU. FRAME_LEN.

>  #define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \
>  ENETSW_TAG_SIZE)
>  #define ENETSW_FRAG_SIZE(x)(SKB_DATA_ALIGN(NET_SKB_PAD + x + \
> @@ -1067,7 +1068,7 @@ static int bcm6368_enetsw_probe(struct platform_device 
> *pdev)
> ndev->netdev_ops = _enetsw_ops;
> ndev->min_mtu = ETH_ZLEN;
> ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
> -   ndev->max_mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
> +   ndev->max_mtu = ENETSW_MAX_MTU;

And here you would need to subtract the ETH_HLEN first, else you will
allow 14 bytes too much. Also not sure if the ENETSW_TAG_SIZE should
be still added here, as it is stripped on rx and added on tx on the
cpu port.

Best Regards,
Jonas

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

Re: [PATCH] urngd: fixes compilation with glibc

[Jonas Gorski]

Hi,

On Sat, 16 Sept 2023 at 05:57, Chukun Pan  wrote:
>
> When compiling with glibc it will result in error:
> 1. #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
> [-Werror=cpp]
> Fix this by compiling with optimization (-O2) by default.
>
> 2. jitterentropy-base.c:(.text+0x39f8): undefined reference to `pthread_join'
> Fix this by always linking pthread.
>
> Signed-off-by: Chukun Pan 
> ---
>  CMakeLists.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index a1ee0c1..20f4774 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -23,7 +23,8 @@ ADD_EXECUTABLE(urngd
>  TARGET_LINK_LIBRARIES(urngd ${ubox})
>
>  # jitter RNG must not be compiled with optimizations
> -SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES 
> COMPILE_FLAGS -O0)
> +SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES 
> COMPILE_FLAGS -O2)

As mentioned by Andre, -O0 is intentional. Instead, try adding
-U_FORTIFY_SOURCE which disables it for this unit only.

For both glibc and musl, optimizatios need to be enabled for fortify
source to do anything, but only glibc warns about it, so disabling it
for this unit shouldn't change the generated code at all, just silence
the warning for glibc.

Regards,
Jonas

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

Re: [PATCH] ath79: fix MikroTik CPLD driver build error on kernel 6.1

[Jonas Gorski]

Hi,

On Sat, 9 Sept 2023 at 04:44, Shiji Yang  wrote:
>
> From: Shiji Yang 
>
> Since kernel 5.18, the return type in device remove function has
> changed from 'int' to 'void'.
>
> Signed-off-by: Shiji Yang 
> ---
>  target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c 
> b/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
> index da18424c63..f10ddef9e2 100644
> --- a/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
> +++ b/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -151,9 +152,14 @@ static int rb4xx_cpld_probe(struct spi_device *spi)
> NULL, 0, NULL);
>  }
>
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,18,0)
> +static void rb4xx_cpld_remove(struct spi_device *spi)
> +{
> +#else
>  static int rb4xx_cpld_remove(struct spi_device *spi)
>  {
> return 0;
> +#endif

I'm pretty sure having a remove callback is optional, so why not just
delete it since it doesn't do anything anyway?

If we ever need one, we can just add one again.

Best Regards,
Jonas

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

Re: [PATCH] bcm53xx: Unconditionally build U-Boot for DIR-890L

[Jonas Gorski]

On Mon, 4 Sept 2023 at 23:00, Linus Walleij  wrote:
>
> On Mon, Sep 4, 2023 at 12:03 PM Rafał Miłecki  wrote:
>
> > I don't see anything incorrect with Linus's original patch. Maybe we
> > just have some dependency handling issue in u-boot generic .mk code?
>
> I have transient problem with the dependencies at times, then
> I just chose another target (entirely different!) in menuconfig and
> then back to the intended target. Problem fixed, dependency
> selected. It feels a bit shaky though, but usually all autobuilds
> work fine.

You might want to set HIDDEN for the u-boot packages. Then they aren't
a user selectable package (config symbol) anymore, and their selection
state will follow the defaults automatically.

Should avoid the u-boot packages (not) being built/selected when
changing the device.

Best Regards,
Jonas

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

Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]

[Jonas Gorski]

On Mon, 5 Dec 2022 at 11:00, Arnd Bergmann  wrote:
>
> On Sat, Dec 3, 2022, at 23:59, Bjørn Mork wrote:
> > "Arnd Bergmann"  writes:
> >> On Sat, Dec 3, 2022, at 18:02, Bjørn Mork wrote:
> >>
> >>> Yes, I realize that ALL_KMODS only changes a small subset of symbols
> >>> related to kmod packages.  And I'm pretty sure HSR isn't part of that
> >>> set.  But I don't think that changes anything.  This is a bug waiting to
> >>> happen again.
> >>
> >> Do you have any alternative suggestions? Changing the dependency logic
> >> would just cause runtime failures, and turning the dependencies all
> >> into 'bool' symbols would cause a significant increase in kernel size
> >> for distro builds that usually rely on things being in loadable modules.
> >
> > I was referring to the ALL_KMODS feature in OpenWrt, not to the
> > PTP_1588_CLOCK_OPTIONAL symbol.  As noted, there are many similar
> > constructs in the kernel. Personally I think
> > PTP_1588_CLOCK || PTP_1588_CLOCK=n would have been better, but I
> > see your point and am definitely not going to argue about that ;-)
> >
> > Should have made it clearer that I believe the bug is in OpenWrt, not in
> > the kernel. Just didn't notice that you were CC'ed into the discussion.
> > Thought we were having an OpenWrt conversation... Sorry about the
> > confusion.
>
> Ok, got it. Indeed this is a general problem for anyone wanting
> to enable all kernel modules. I don't know how ALL_KMODS works
> in OpenWRT, but there are other related problems that make this
> a hard problem, which means you need a whitelist or blacklist
> of some sort anyway:
>
> - Some modules are only visible depending on some other 'bool'
>   symbol, so you have to know which of those symbols to turn
>   on first
>
> - Some 'tristate' symbols not only control whether a module
>   is built but also impact the rest of the kernel.
>
> - Some modules are related to 'choice' statement or other
>   options that have mutually incompatible settings.

Luckily we already have solutions or workarounds in place for most of
these, like encoding a hash of the kernel configuration in the version
of the kernel (module) packages, and requiring an exact match on
installation.

Coming back to the original issue, I think there are only two viable
(short-term) solutions for mvebu (and any other target affected):

a) Set PTP_1588_CLOCK=y for mvebu, forcing it always on.
b) Disallow PTP_1588_CLOCK for mvebu, preventing it from being enabled.

so essentially treating it like a bool.

Since most mvebu devices are on the beefier side with plenty of RAM
and flash, I think a) is fine and shouldn't hurt too much.

In theory it would also be possible to make the switch driver a module
and let preinit load it (and include the ptp module optionally), but
this would be effectively the same as a) for releases/ALL_KMOD builds,
just more complicated, and less space efficient.


Jonas

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

Re: [PATCH] treewide: remove label = "cpu" from DSA dt-binding

[Jonas Gorski]

On Wed, 30 Nov 2022 at 15:43, Arınç ÜNAL  wrote:
>
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Link: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
> Signed-off-by: Arınç ÜNAL 
>
> ---
>
> These devicetrees do not define the ethernet property for CPU ports.
> target/linux/bcm63xx/dts/bcm63169-comtrend-vg-8050.dts
> target/linux/bcm63xx/dts/bcm6362-huawei-hg253s-v2.dts
> target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> target/linux/bcm63xx/dts/bcm6369-comtrend-wap-5813n.dts
> target/linux/mpc85xx/files/arch/powerpc/boot/dts/panda.dts
>
> There might be OpenWrt maintained code somewhere that checks for label cpu
> on these. If anyone has got one of these devices, please test network
> connectivity with this patch applied.

The swconfig b53 driver uses the label to identify the cpu port, so
NAK for bcm63xx, and I guess panda / mpc85xx/p1020.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/net/phy/b53/b53_common.c;h=87d731ec3e2a868dc8389f554b1dc9ab42c30be2;hb=HEAD#l1508

Jonas

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

Re: [PATCH] ramips: fix Unifi 6 Lite boot failure with v5.15 kernels

[Jonas Gorski]

On Sun, 6 Nov 2022 at 12:50, Bjørn Mork  wrote:
>
> Jonas Gorski  writes:
>
> > An option is also to set a load address for the dtb in the FIT image,
> > then U-Boot will relocate it before passing it to the kernel.
>
> Yes, that is worth trying.  I thought this would be part of the fdt
> relocation step, but I see that the "load" property is used before the
> final relocation.
>
> I'll test this when I have console again.  Or earlier if someone can
> tell me how to calculate a semi-safe load address.  Will the kernel
> $loadaddr + aligned(8, 32, 512. 4096?) kernelsize be ok?

You'll probably then have the chance to land in the .bss section,
which gets zeroed on boot.

Safest might be a static address like RAMSTART + 16MiB. This is what
e.g. DentOS does.

Not sure if 16 MiB is enough for ramdisk kernels.

> And how do I figure out where in memory the fdt ended up, without seeing
> the console output from u-boot?  Can't see anything obvious in dmesg or
> in sysfs.  Do I need to enable a memory debug device, or is this address
> directly available somewhere?

I don't think so, at least I don't see anything obvious.

So I guess you'll need to sprinkle some debug printks there (e.g.
fw_arg0 or argument passed to __dt_setup_arch()).

Jonas

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

Re: [PATCH] ramips: fix Unifi 6 Lite boot failure with v5.15 kernels

[Jonas Gorski]

On Sat, 5 Nov 2022 at 09:46, Bjørn Mork  wrote:
>
> David Bauer  writes:
> > On 11/4/22 09:29, Bjørn Mork wrote:
> >> You are right that the bootloader must be fixed.  But the vendor isn't
> >> likely to do that as long as they run older kernels. I believe the
> >> OpenWrt policy in such cases is to try to work around the issue.
> >> Replacing the vendor bootloader is a last resort.  Please correct me if
> >> I'm wrong.
> >
> > I haven't tried this yet, but I think we should be able to boot a FIT
> > image configuration which only contains a kernel image. We could then simply
> > use the legacy append-DT like we do for legacy uImage ramips.
> >
> > Not the nicest way, but considering we need it for the target anyways, i 
> > consider
> > this the simpler solution.
>
> Yes, that sounds acceptable if it is supported.  Which I guess it should
> be.
>
> I can test it the next time I get a chance.  But that might take a while
> before I'm close enough to these APs to use the console.  Should have
> had a console I could access remotely there, but I don't.

An option is also to set a load address for the dtb in the FIT image,
then U-Boot will relocate it before passing it to the kernel.

This way U-Boot also retains access to the dtb, in case it wants to
update/modify it (e.g. updating the /memory/ node with the actual
memory present, setting the cmdline, setting mac addresses etc).

Jonas

___
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] The meaning of Signed-off-by for netifd [Was: Re: [PATCH netifd] interface: warn if ip6hint is truncated]

[Jonas Gorski]

Hi,

On Tue, 3 Dec 2019 at 16:29, Hans Dedecker  wrote:
>
> On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König  
> wrote:
> >
> > Hello Hans,
> >
> > On 12/3/19 8:50 AM, Hans Dedecker wrote:
> > > On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König  
> > > wrote:
> > >>
> > >> On 11/29/19 8:50 PM, Hans Dedecker wrote:
> > >>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König 
> > >>>  wrote:
> > 
> >  When for example a /60 is assigned to a network the last 4 bits of the
> >  ip6hint are unused. Emit a warning if any of these unused bits is set 
> >  as
> >  it indicates that someone didn't understand how the hint is used. (As I
> >  did earlier today resulting in spending some time understanding the
> >  code.)
> > >>> Patch applied with some minor tweaks
> > >>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397);
> > >>
> > >> The updated warning message is fine.
> > >>
> > >>> I added your SoB as this was missing in the patch
> > >>
> > >> I wonder what the significance of the SoB is given that a) it's not
> > >> documented (at least in the netifd sources) and b) it seems to be ok to
> > >> "fake" someone else's SoB and c) there are several commits in the newer
> > >> history of netifd that don't have a SoB of either Author or Committer
> > >> (or both).
> > > For details why a SoB is required; see
> > > https://openwrt.org/submitting-patches#sign_your_work.
> > > If there're any commits in the netifd repo which don't have a SoB this
> > > must rather stay an exception than becoming a general rule.
> >
> > ok, so you claim my SoB means that *I* confirmed that my change is
> > compatible to the netifd's license. I didn't do that though.
> >
> > Even if it was me who added that line I doubt is has any relevance for
> > netifd because nothing in the netifd sources explains what an SoB means.
> > And the link you sent applies only to patches for openwrt, not netifd.
> > (Also if this is the only place for openwrt where the significance of an
> > SoB is described I wonder if this is relevant given that from the POV of
> > openwrt.git the wiki is an external resource that can be modified by
> > anyone. What if someone removes item (d) from the wiki or introduces an
> > (e)?)
> >
> > Don't get me wrong, my patch is compatible to netifd's license. But if
> > you want that netifd's license situation stays reasonably safe and
> > clean, it IMHO cannot be that you add a SoB for someone else, and give
> > that SoB a meaning that isn't documented for your project and assumes
> > things about that someone else that you cannot know for sure. So if you
> > require a formalism, please formalize it properly. (Of course INAL, but
> > that's my understanding of how open source licensing works.)
> I won't waste further my time and energy on this ...
> I acted in good faith and next time if I find a patch from you without
> SoB I will just simply reject it to avoid contra productive
> discussions

I have to agree with everyone, so please don't add SoBs for *anyone*
except yourself. This is basically similar to forging a signature
(just without the direct legal consequences of that).

> Patches delivered for all projects (netifd/libubox/ubus/...)
> maintained by OpenWrt must have a SoB in line what is described on the
> Wiki; this does not solely apply to the OpenWrt repo

Indeed, so patches without one, or a broken one need to be fixed by
the submitter/author. This cannot be fixed up by the maintainer
(except maybe with an explicit permission of the author).

Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] uci: Fix Wformat-nonliteral warning

[Jonas Gorski]

On Tue, 3 Dec 2019 at 01:54, Rosen Penev  wrote:
>
> A const char * variable is being passed as a format string. Unfortunately,
> this is not correct.
>
> A constant expression needs to be passed so that GCC can determine the
> types of the format properly.
>
> Also fixed a different warning that needs a printf attribute.
>
> Fixes:
>
> error: format not a string literal, argument types not checked
> [-Werror=format-nonliteral]
>   176 |error_info);
>   |^~
> error: format not a string literal, argument types not checked
> [-Werror=format-nonliteral]
>   185 |error_info);
>
> cli.c:196:19: error: format string is not a string literal
> [-Werror=format-nonliteral]
>vfprintf(stderr, fmt, ap);
>
> Signed-off-by: Rosen Penev 
> ---
>  v3: Moved define to top of file.
>  v2: Fixed extra warning from clang 10.
>  cli.c|  1 +
>  libuci.c | 15 ---
>  2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/cli.c b/cli.c
> index 8970f4f..6ba97ea 100644
> --- a/cli.c
> +++ b/cli.c
> @@ -185,6 +185,7 @@ static void cli_perror(void)
> uci_perror(ctx, appname);
>  }
>
> +__attribute__((format(printf, 1, 2)))
>  static void cli_error(const char *fmt, ...)
>  {
> va_list ap;
> diff --git a/libuci.c b/libuci.c
> index a9e70e8..0f0211a 100644
> --- a/libuci.c
> +++ b/libuci.c
> @@ -40,6 +40,12 @@ static const char *uci_errstr[] = {
>  #include "uci_internal.h"
>  #include "list.c"
>
> +#define errstr \

As mentioned in my previous email, please use all caps for #defines.
And maybe give it a more descriptive less generic name. E.g.
UCI_ERR_FORMAT, as it is a format string, and should be uci
"namespaced" (as much as you can namespace stuff in C).


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] firewall: Fix Wformat-nonliteral warning

[Jonas Gorski]

Hi,

On Fri, 29 Nov 2019 at 22:06, Rosen Penev  wrote:
>
> Allows GCC to check the formats by switching to a define, which is a
> constant expression.
>
> Fixes:
>
> warning: format not a string literal, argument types not checked
> [-Wformat-nonliteral]
>   207 |  snprintf(buf, sizeof(buf), tmpl, include->path);
>
> Signed-off-by: Rosen Penev 
> ---
>  includes.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/includes.c b/includes.c
> index 23b2244..1e759fb 100644
> --- a/includes.c
> +++ b/includes.c
> @@ -188,11 +188,11 @@ run_include(struct fw3_include *include)
>  {
> int rv;
> struct stat s;
> -   const char *tmpl =
> -   "config() { "
> -   "echo \"You cannot use UCI in firewall includes!\" 
> >&2; "
> -   "exit 1; "
> -   "}; . %s";
> +   #define tmpl \
> +   "config() { " \
> +   "echo \"You cannot use UCI in firewall includes!\" 
> >&2; " \
> +   "exit 1; " \
> +   "}; . %s"

defines are global, so they should be at top of the file, use caps for
the name, and have a less generic name than "templ" (or "format").
Same comment for the other patches doing the same thing.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH 2/4] kernel: add backported phy/phylink/sfp patches

[Jonas Gorski]

On Wed, 27 Nov 2019 at 14:27, Russell King - ARM Linux admin
 wrote:
>
> On Wed, Nov 27, 2019 at 02:03:40PM +0100, Jonas Gorski wrote:
> > On Wed, 27 Nov 2019 at 13:14, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Wed, Nov 27, 2019 at 12:57:35PM +0100, Petr Štetiar wrote:
> > > > Russell King - ARM Linux admin  [2019-11-27 
> > > > 10:35:10]:
> > > >
> > > > > It makes it very difficult to understand.  For example, where is the
> > > > > kernel + kmod package version/release set
> > > >
> > > > from 
> > > > kmod-libphy_4.19.85-1_aarch64_cortex-a53.ipk/control.tar.gz/control:
> > > >
> > > >  Package: kmod-libphy
> > > >  Version: 4.19.85-1
> > > >  Depends: kernel (=4.19.85-1-f24e301be88eb921523d0eb26012ec0f)
> > > >
> > > > I'm interested how the Version: is set:
> > > >
> > > >  $ git grep Version: include/
> > > >  include/package-dumpinfo.mk:)Version: $(VERSION)
> > > >
> > > > So then I need to know how the VERSION is set:
> > > >
> > > >  $ git grep VERSION.*:.*= include/kernel*
> > > >  include/kernel.mk:VERSION:=$(LINUX_VERSION)$(if 
> > > > $(PKG_VERSION),+$(PKG_VERSION))-$(if 
> > > > $(PKG_RELEASE),$(PKG_RELEASE),$(LINUX_RELEASE))
> > > >
> > > > So from above it's PKG_RELEASE or LINUX_RELEASE now:
> > > >
> > > >  $ git grep -E '(PKG_RELEASE|LINUX_RELEASE)' include/kernel*
> > > >  include/kernel-version.mk:LINUX_RELEASE?=1
> > > >
> > > > So in order to bump the release in the 4.19.85-1 from 1 to 2 I would 
> > > > probably
> > > > need to set LINUX_RELEASE:=2 somewhere in the Make files or provide it 
> > > > to Make
> > > > via commandline, as `make ... LINUX_RELEASE=2`.
> > >
> > > Thanks, that's useful information.
> >
> > To add to this, the f24e301be88eb921523d0eb26012ec0f part is the hash
> > of the kernel config used during the build of the module/kernel. This
> > is to avoid installing kernel modules build with a different ABI due
> > to different config.
> >
> > See 
> > https://github.com/openwrt/openwrt/blob/master/include/kernel-defaults.mk#L108
> > for how it's generated.
> >
> > > > > > AFAIK Jonas plans to borrow few SFP modules and test this on his 
> > > > > > ClearFog PRO
> > > > > > and he is eventually going to merge this as well.
> > > > >
> > > > > Surely only one person should be merging this?
> > > >
> > > > I'm not implying that, but Jonas is already involved and has access to 
> > > > the
> > > > actual hardware, so it makes sense to let him test and merge it.
> > >
> > > Hmm, so you're saying that the mainline kernel maintainer (me)
> > > shouldn't be pushing these patches for OpenWrt, because you don't
> > > trust me to test them, despite testing them on the uDPU, SolidRun
> > > Clearfog and cex7 platforms with multiple different SFP and SFP+
> > > modules from several vendors.
> > >
> > > Instead you'd rather trust someone with only one SFP module, who's
> > > patch that was merged into OpenWrt will break some modules that
> > > have been tested to work with the upstream kernel?
> > >
> > > Sound sane?
> > >
> > > I think you're actually confused about what I've asked Jonas to do.
> > > I haven't asked him to test these patches with a view to merging
> > > them, I've asked him to report back what the situation is with this
> > > patch set without his "450-reprobe_sfp_phy" patch applied, which
> > > never made it into the upstream kernel - and then we'll work on a
> > > way to make his module work with *both* OpenWrt and the mainline
> > > kernel.
> >
> > The bit you are probably missing is that I also happen to be an
> > OpenWrt maintainer with commit access.
> >
> > So unless you also have commit access yourself you would need someone
> > from the maintainer group to accept and merge your patches. And since
> > I have access to a device with an SFP port, I can do both the checks
> > you asked me to do as well as do the merge. Two birds with one stone
> > ;-)
> >
> > And sometimes changes can have unexpected side effects due to the
> > amount of local patches we have for each target, and I don't expect
> > anyone to be

Re: [OpenWrt-Devel] [PATCH 2/4] kernel: add backported phy/phylink/sfp patches

[Jonas Gorski]

On Wed, 27 Nov 2019 at 13:14, Russell King - ARM Linux admin
 wrote:
>
> On Wed, Nov 27, 2019 at 12:57:35PM +0100, Petr Štetiar wrote:
> > Russell King - ARM Linux admin  [2019-11-27 
> > 10:35:10]:
> >
> > > It makes it very difficult to understand.  For example, where is the
> > > kernel + kmod package version/release set
> >
> > from kmod-libphy_4.19.85-1_aarch64_cortex-a53.ipk/control.tar.gz/control:
> >
> >  Package: kmod-libphy
> >  Version: 4.19.85-1
> >  Depends: kernel (=4.19.85-1-f24e301be88eb921523d0eb26012ec0f)
> >
> > I'm interested how the Version: is set:
> >
> >  $ git grep Version: include/
> >  include/package-dumpinfo.mk:)Version: $(VERSION)
> >
> > So then I need to know how the VERSION is set:
> >
> >  $ git grep VERSION.*:.*= include/kernel*
> >  include/kernel.mk:VERSION:=$(LINUX_VERSION)$(if 
> > $(PKG_VERSION),+$(PKG_VERSION))-$(if 
> > $(PKG_RELEASE),$(PKG_RELEASE),$(LINUX_RELEASE))
> >
> > So from above it's PKG_RELEASE or LINUX_RELEASE now:
> >
> >  $ git grep -E '(PKG_RELEASE|LINUX_RELEASE)' include/kernel*
> >  include/kernel-version.mk:LINUX_RELEASE?=1
> >
> > So in order to bump the release in the 4.19.85-1 from 1 to 2 I would 
> > probably
> > need to set LINUX_RELEASE:=2 somewhere in the Make files or provide it to 
> > Make
> > via commandline, as `make ... LINUX_RELEASE=2`.
>
> Thanks, that's useful information.

To add to this, the f24e301be88eb921523d0eb26012ec0f part is the hash
of the kernel config used during the build of the module/kernel. This
is to avoid installing kernel modules build with a different ABI due
to different config.

See 
https://github.com/openwrt/openwrt/blob/master/include/kernel-defaults.mk#L108
for how it's generated.

> > > > AFAIK Jonas plans to borrow few SFP modules and test this on his 
> > > > ClearFog PRO
> > > > and he is eventually going to merge this as well.
> > >
> > > Surely only one person should be merging this?
> >
> > I'm not implying that, but Jonas is already involved and has access to the
> > actual hardware, so it makes sense to let him test and merge it.
>
> Hmm, so you're saying that the mainline kernel maintainer (me)
> shouldn't be pushing these patches for OpenWrt, because you don't
> trust me to test them, despite testing them on the uDPU, SolidRun
> Clearfog and cex7 platforms with multiple different SFP and SFP+
> modules from several vendors.
>
> Instead you'd rather trust someone with only one SFP module, who's
> patch that was merged into OpenWrt will break some modules that
> have been tested to work with the upstream kernel?
>
> Sound sane?
>
> I think you're actually confused about what I've asked Jonas to do.
> I haven't asked him to test these patches with a view to merging
> them, I've asked him to report back what the situation is with this
> patch set without his "450-reprobe_sfp_phy" patch applied, which
> never made it into the upstream kernel - and then we'll work on a
> way to make his module work with *both* OpenWrt and the mainline
> kernel.

The bit you are probably missing is that I also happen to be an
OpenWrt maintainer with commit access.

So unless you also have commit access yourself you would need someone
from the maintainer group to accept and merge your patches. And since
I have access to a device with an SFP port, I can do both the checks
you asked me to do as well as do the merge. Two birds with one stone
;-)

And sometimes changes can have unexpected side effects due to the
amount of local patches we have for each target, and I don't expect
anyone to be aware of all of them, or having tested all of them.

I hope that clears it a bit up? Nothing about not trusting you and
your code, just not trusting it blindly. Especially since you
mentioned having issues with the OpenWrt build system.


Best regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH 1/4] kernel: remove obsolete phylink/SFP patches

[Jonas Gorski]

On Mon, 25 Nov 2019 at 18:29, Russell King - ARM Linux admin
 wrote:
>
> On Mon, Nov 25, 2019 at 06:10:18PM +0100, Jonas Gorski wrote:
> > On Mon, 25 Nov 2019 at 17:49, Russell King  wrote:
> > >
> > > Remove the old phylink/SFP patches from the OpenWRT build; these will
> > > be updated with a new set in subsequent.
> > >
> > > 450-reprobe_sfp_phy is also removed for several reasons:
> > > 1) it is not in mainline.
> > > 2) it breaks copper modules that do not have a PHY.
> > > 3) it makes backporting the current patch set harder.
> > >
> > > Discussion is ongoing with the patch author for a mainline Linux kernel
> > > patch for this.
> >
> > You can also just put me in Cc ;P
> >
> > Is using this patchset enough for the tests you asked, or are there
> > some additional changes in your branch?
>
> Hi,
>
> Yes, for the test I've asked for.  The series basically brings OpenWRT
> 4.19 kernel to parity on SFP stuff with the current state of play.

Nice! Thanks for the work. That makes testing a lot easier for me.

Regards
Jonas

P.S: it's OpenWrt, not OpenWRT ;p

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

Re: [OpenWrt-Devel] [PATCH 1/4] kernel: remove obsolete phylink/SFP patches

[Jonas Gorski]

On Mon, 25 Nov 2019 at 17:49, Russell King  wrote:
>
> Remove the old phylink/SFP patches from the OpenWRT build; these will
> be updated with a new set in subsequent.
>
> 450-reprobe_sfp_phy is also removed for several reasons:
> 1) it is not in mainline.
> 2) it breaks copper modules that do not have a PHY.
> 3) it makes backporting the current patch set harder.
>
> Discussion is ongoing with the patch author for a mainline Linux kernel
> patch for this.

You can also just put me in Cc ;P

Is using this patchset enough for the tests you asked, or are there
some additional changes in your branch?


Regards

Jonas
 --   * this time, that's fine too.
> --   */
> --  sfp_sm_next(sfp, SFP_S_INIT, T_INIT_JIFFIES);
> --  sfp->sm_retries = 5;
> -+  sfp_module_tx_enable(sfp);
> -
> -   /* Setting the serdes link mode is guesswork: there's no
> -* field in the EEPROM which indicates what mode should
> -@@ -1485,7 +1482,22 @@ static void sfp_sm_mod_init(struct sfp *
> -   if (sfp->id.base.e1000_base_t ||
> -   sfp->id.base.e100_base_lx ||
> -   sfp->id.base.e100_base_fx)
> --  sfp_sm_probe_phy(sfp);
> -+  ret = sfp_sm_probe_phy(sfp);
> -+
> -+  if (!ret) {
> -+  /* Wait t_init before indicating that the link is up, provided
> -+   * the current state indicates no TX_FAULT.  If TX_FAULT 
> clears
> -+   * this time, that's fine too.
> -+   */
> -+  sfp_sm_next(sfp, SFP_S_INIT, T_INIT_JIFFIES);
> -+  sfp->sm_retries = 5;
> -+  return;
> -+  }
> -+
> -+  if (ret == -EAGAIN)
> -+  sfp_sm_set_timer(sfp, T_PROBE_RETRY);
> -+  else
> -+  sfp_sm_next(sfp, SFP_S_TX_DISABLE, 0);
> - }
> -
> - static int sfp_sm_mod_hpower(struct sfp *sfp)
> --
> 2.20.1
>
>
> ___
> 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] [PATCH libubox 1/9] enable extra compiler checks

[Jonas Gorski]

On Wed, 20 Nov 2019 at 13:00, Petr Štetiar  wrote:
>
> Let's enforce additional automatic checks enforced by the compiler in
> order to catch possible errors during compilation.

Does it still compile when only applying this patch? If not, you need
to move it to after fixing all issues it now warns about (and I guess
errors), to keep bisectability.

Regards
Jonas

>
> Signed-off-by: Petr Štetiar 
> ---
>  CMakeLists.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 57804cf007bf..7a86854841e3 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -3,7 +3,7 @@ INCLUDE(CheckLibraryExists)
>  INCLUDE(CheckFunctionExists)
>
>  PROJECT(ubox C)
> -ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -g3 -Wmissing-declarations)
> +ADD_DEFINITIONS(-Os -Wextra -Wall -Werror --std=gnu99 -g3 
> -Wmissing-declarations -Wno-unused-parameter)
>
>  OPTION(BUILD_LUA "build Lua plugin" ON)
>  OPTION(BUILD_EXAMPLES "build examples" ON)
>
> ___
> 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] [PATCH] ath79: enable all space on Netgear ar9344-based WNDR routers

[Jonas Gorski]

On Tue, 19 Nov 2019 at 17:59, Michal Cieslakiewicz
 wrote:
>
> >
> > That was my question, if the "new" OpenWrt sysupgrade.bin still works
> > in the initial flash.
> >
>
> sysupgrade.bin for this model is in format tar+metadata, it is not
> designed to be put into flash directly.

Typo, I did mean factory.bin ... . The type you use to initially flash
OpenWrt ;-)

Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] ath79: enable all space on Netgear ar9344-based WNDR routers

[Jonas Gorski]

On Tue, 19 Nov 2019 at 17:33, Michal Cieslakiewicz
 wrote:
>
> Hello,
>
> >
> > Have you checked that flashing a factory.bin image through tftp still
> > works?
> >
>
> Yes, it works. On this router the easiest way to flash memory via tftp
> is to enter uboot and execute 'fw_recovery' command, then factory.img
> file can be uploaded via tftp client.  I hope this answers your
> question.

That was my question, if the "new" OpenWrt sysupgrade.bin still works
in the initial flash.

Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] ath79: enable all space on Netgear ar9344-based WNDR routers

[Jonas Gorski]

On Tue, 19 Nov 2019 at 16:18, Michal Cieslakiewicz
 wrote:
>
> Hello David,
>
> Two questions were raised just after publishing 'all-flash-space' patch.
> Now I am ready to provide more information on these issues:
>
> 0. Downgrade to vendor firmware.
>
> It is possible. Just don't forget to erase both ubi concat partitions:
> 'mtd -r erase ubi' does the job fine.
>
> 1. Sysupgrade:
>
> > >
> > > Have you tried if this breaks sysupgrade from an older OpenWrt
> > > firmware? I'm not sure if an UBI resize works without additional
> > > steps.
> > >

How about

2. Initial installation:

Have you checked that flashing a factory.bin image through tftp still works?


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH v2 maintainer-tools] patchwork-apply.sh: try to fix DMARC mangled patches

[Jonas Gorski]

On Sun, 10 Nov 2019 at 10:05, Petr Štetiar  wrote:
>
> In order to avoid DMARC plague in the commit messages:
>
>  87f9292300cf hostapd: add IEEE 802.11k support
>  450d44a8ead2 openssl: change defaults: ENGINE:on, NPN:off, misc
>  eabc1ddc4541 build: Honour NO_COLOR in include/scan.mk
>  3fb45576ac16 cryptodev-linux: move from packages feed
>  a73283dc10f7 kernel: nf-nathelper-extra depends on ipt-raw
>  0317fc3658eb libpcap: patch to add limits.h to pcap-usb-linux.c
>  26dbf79f4905 libevent2: Don't build tests and samples
>  d59126040701 brcm63xx: initial support for Sky SR102 router
>  094d49cddf93 kernel: bump 4.14 to 4.14.51
>  247055cbfbf1 igmpproxy: bump to 0.2.1
>  c451434b963d cake: bump to 20180504 bake
>  080fb7a3fbb6 iproute2: import latest cake
>  ad5af37ca793 iproute2: backport json_print-fix-hidden-64-bit-type-promotion
>  78f4305933b9 iftop: bump to latest
>  7783f31359cb base-files: nand: use CI_KERNPART whenever the kernel volume is 
> needed
>
> Signed-off-by: Petr Štetiar 
> ---
>  patchwork-apply.sh | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/patchwork-apply.sh b/patchwork-apply.sh
> index 5506adbfe451..1543c7fdaceb 100755
> --- a/patchwork-apply.sh
> +++ b/patchwork-apply.sh
> @@ -140,6 +140,13 @@ echo "$1" | grep -sqE '^[0-9]+$' || {
> }
>  }
>
> +grep --color --context=3 "DMARC Reject/Quarantine" "$1.patch" && {
> +   if ! yesno "DMARC manled patch detected, attempt to fix it?" "y"; then
> +   exit 4
> +   fi
> +   sed -i '/The sender domain has a DMARC/,/automatically by the mailing 
> list software./d' "$1.patch"
> +}
> +

The patch author itself also needs unmangling. it currently is "foo
bar via openwrt-devel <...>". The original author seems to be
available in a "Reply-To:" header - no idea how stable that is.

After that it looks good IMHO. And yes, having a sanity check as a
commit hook would be good, but is a separate thing from this patch.
Same for a fixed patchwork version, but there has been no release yet
with the fix[1].


Regards
Jonas

[1] 
https://github.com/getpatchwork/patchwork/commit/8279a84238c10acbcadd075e4e998dffdc39f2e9


>  git am "$1.patch" || {
> echo "Failed to apply patch $1" >&2
> git am --abort
>
> ___
> 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] [PATCH maintainer-tools] patchwork-apply.sh: help spotting DMARC mangled patches

[Jonas Gorski]

On Sat, 9 Nov 2019 at 13:55, Petr Štetiar  wrote:
>
> Avoid DMARC plague in the commit messages:
>
>  87f9292300cf hostapd: add IEEE 802.11k support
>  450d44a8ead2 openssl: change defaults: ENGINE:on, NPN:off, misc
>  eabc1ddc4541 build: Honour NO_COLOR in include/scan.mk
>  3fb45576ac16 cryptodev-linux: move from packages feed
>  a73283dc10f7 kernel: nf-nathelper-extra depends on ipt-raw
>  0317fc3658eb libpcap: patch to add limits.h to pcap-usb-linux.c
>  26dbf79f4905 libevent2: Don't build tests and samples
>  d59126040701 brcm63xx: initial support for Sky SR102 router
>  094d49cddf93 kernel: bump 4.14 to 4.14.51
>  247055cbfbf1 igmpproxy: bump to 0.2.1
>  c451434b963d cake: bump to 20180504 bake
>  080fb7a3fbb6 iproute2: import latest cake
>  ad5af37ca793 iproute2: backport json_print-fix-hidden-64-bit-type-promotion
>  78f4305933b9 iftop: bump to latest
>  7783f31359cb base-files: nand: use CI_KERNPART whenever the kernel volume is 
> needed
>
> Signed-off-by: Petr Štetiar 
> ---
>  patchwork-apply.sh | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/patchwork-apply.sh b/patchwork-apply.sh
> index 5506adbfe451..506a09fd4fd5 100755
> --- a/patchwork-apply.sh
> +++ b/patchwork-apply.sh
> @@ -140,6 +140,12 @@ echo "$1" | grep -sqE '^[0-9]+$' || {
> }
>  }
>
> +grep --color --context=3 "DMARC Reject/Quarantine" "$1.patch" && {
> +   if yesno "Beware DMARC text detected! Set to 'Changes Requested'?" 
> "y"; then
> +   pwclient update -s "Changes Requested" "$1"

This DMARC thing is nothing the submitter can fix unless they run
their own mail server. At best a sed script fixing up the patch would
work here, if this can be sufficiently expressed.

A better place would be a git hook on our server rejecting any commits
with it (like we already have for missing SOB).


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI of mac address

[Jonas Gorski]

On Sat, 9 Nov 2019 at 12:04,  wrote:
>
> Hi,
>
> > -Original Message-
> > From: Jonas Gorski [mailto:jonas.gor...@gmail.com]
> > Sent: Samstag, 9. November 2019 10:37
> > To: Adrian Schmutzler 
> > Cc: OpenWrt Development List ; Rosy
> > Song 
> > Subject: Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI
> > of mac address
> >
> > On Fri, 8 Nov 2019 at 12:49, Adrian Schmutzler
> >  wrote:
> > >
> > > If the label MAC address is provided for a device, the default SSID
> > > will be set to contain the EUI of this address, e.g. OpenWrt-ddeeff.
> > >
> > > With multiple routers, this will help the user to identify his device
> > > based on the MAC address printed on the device.
> > >
> > > If no label MAC address is specified, this will use "OpenWrt" as done
> > > before.
> > >
> > > Using a uci-defaults script for this is necessary as mac80211.sh is
> > > executed before /etc/board.json is created, so label MAC addresses set
> > > in 02_network would not be available there.
> >
> > Unfortunately since we detect wifi async these days this is quite racy, and
> > there is no guarantee /etc/config/wireless is fully populated by the time 
> > the
> > uci defaults are run. E.g. mwl8k takes quite a while since it uses different
> > firmwares for STA and AP modes, and it needs to re-initialize to switch
> > between them (triggered by by mac80211.sh trying to detect the supporte
> > features).
>
> So, in the end, it might be like Manuel Giganto suggested in GitHub and one 
> might
> either have to wait in mac80211.sh until /etc/board.json is available (ugly) 
> or
> just put the same code (the few lines of SSID change) in both locations 
> (uci_defaults AND mac80211.sh).

How about just generating the board.json at an earlier time before
loading the wifi drivers, so it's always there once mac80211.sh runs?

We already generate it in preinit (unless failsafe is disabled) to
configure the switch and find the proper lan if, we might as well make
it unconditional and then rely on it for mac80211.sh.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI of mac address

[Jonas Gorski]

On Fri, 8 Nov 2019 at 12:49, Adrian Schmutzler
 wrote:
>
> If the label MAC address is provided for a device, the default SSID
> will be set to contain the EUI of this address, e.g. OpenWrt-ddeeff.
>
> With multiple routers, this will help the user to identify his device
> based on the MAC address printed on the device.
>
> If no label MAC address is specified, this will use "OpenWrt" as
> done before.
>
> Using a uci-defaults script for this is necessary as mac80211.sh is
> executed before /etc/board.json is created, so label MAC addresses
> set in 02_network would not be available there.

Unfortunately since we detect wifi async these days this is quite
racy, and there is no guarantee /etc/config/wireless is fully
populated by the time the uci defaults are run. E.g. mwl8k takes quite
a while since it uses different firmwares for STA and AP modes, and it
needs to re-initialize to switch between them (triggered by by
mac80211.sh trying to detect the supporte features).


Regards
Jonas

>
> Suggested-by: Rosy Song 
> Signed-off-by: Adrian Schmutzler 
>
> ---
>
> This effectively uses a workaround to prevent SSID from being reset
> after upgrade (match SSID vs. "OpenWrt"). If there is a nicer option,
> please propose it.
>
> Another option for this would be to explicitly mark the wireless uci
> config as 'default setup' by a to-be-introduced option, which is
> to be removed in a late uci-defaults script. This could then be
> exploited for several other objectives, e.g. further config-dependent
> WiFi setup tasks.
> ---
>  .../etc/uci-defaults/15_wifi-ssid-mac-address | 22 +++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
>
> diff --git 
> a/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address 
> b/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
> new file mode 100644
> index 00..aeb46e39c0
> --- /dev/null
> +++ b/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
> @@ -0,0 +1,22 @@
> +. /lib/functions.sh
> +. /lib/functions/system.sh
> +
> +set_wifi_ssid() {
> +   local iface="$1"
> +
> +   [ "$(uci get "wireless.${iface}.ssid")" = "OpenWrt" ] && \
> +   uci set "wireless.${iface}.ssid=$ssid"
> +}
> +
> +label_macaddr=$(get_mac_label)
> +
> +[ -n "$label_macaddr" ] || exit 0
> +
> +ssid="OpenWrt-$(macaddr_geteui $label_macaddr)"
> +
> +config_load wireless
> +config_foreach set_wifi_ssid wifi-iface
> +
> +uci commit wireless
> +
> +exit 0
> --
> 2.20.1
>
>
> ___
> 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] [PATCH 1/4] dnsmasq: Activate LTO

[Jonas Gorski]

On Fri, 1 Nov 2019 at 21:55, Hauke Mehrtens  wrote:
>
> This decreases the binary size when PIE ASLR is activated by 8% on MIPS BE.
>
> old:
> 202,020 /usr/sbin/dnsmasq
>
> new:
> 185,676 /usr/sbin/dnsmasq

Nice reduction.

>
> Signed-off-by: Hauke Mehrtens 
> ---
>  package/network/services/dnsmasq/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/network/services/dnsmasq/Makefile 
> b/package/network/services/dnsmasq/Makefile
> index 5c114eb1c6..e86b031e3f 100644
> --- a/package/network/services/dnsmasq/Makefile
> +++ b/package/network/services/dnsmasq/Makefile
> @@ -127,8 +127,8 @@ endef
>  Package/dnsmasq-dhcpv6/conffiles = $(Package/dnsmasq/conffiles)
>  Package/dnsmasq-full/conffiles = $(Package/dnsmasq/conffiles)
>
> -TARGET_CFLAGS += -ffunction-sections -fdata-sections
> -TARGET_LDFLAGS += -Wl,--gc-sections
> +TARGET_CFLAGS += -flto
> +TARGET_LDFLAGS += -flto=jobserver

Maybe add a PKG_LTO (or so) flag packages can set, and add these flags
then automatically? Less code churn per package.


Regards
Jonas

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

Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

[Jonas Gorski]

On Sun, 8 Sep 2019 at 21:19, Tom Psyborg  wrote:
> there seem to exist at least a dozen of critical bugs that one would
> not like to have as a part of final release, to name a few:
>
> Mainline ath10k causes crahes in ipq806x / R7800 ->
> https://bugs.openwrt.org/index.php?do=details_id=2480

We ship ath10k-ct by default, so issues with ath10 shouldn't be a
(rc-)release blocker. It should be fixed for final though.

> TP-Link CPE210v3 wifi not working ->
> https://bugs.openwrt.org/index.php?do=details_id=2478 (there are
> multiple reports for CPE v2 too)
>
> eth0 doesn't work on ath79 and AR7240 Rev 2 for ubnt-bullet-m ->
> https://bugs.openwrt.org/index.php?do=details_id=2442

These seem to be ath79 issues, since 19.07 still has ar71xx (which I
assume still works fine for those) just not providing ath79 images for
these devices would be fine IMHO.

> TD-W8980: Kernel panic - not syncing: Fatal exception in interrupt ->
> https://bugs.openwrt.org/index.php?do=details_id=2410

This should be ideally investigated and fixed by final, but guessing
from the lack of additional reports it seems it doesn't affect many
users.

> ath79: sysupgrade will brick devices with RedBoot bootloader ->
> https://bugs.openwrt.org/index.php?do=details_id=2428
>
> Flow offload regression with 4.19 kernel ->
> https://bugs.openwrt.org/index.php?do=details_id=2389

19.07 uses 4.14, not 4.19, so neither is an issue for the branch/release.


Regards

Jonas

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

Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

[Jonas Gorski]

On Sun, 15 Sep 2019 at 12:49, Paul Spooren  wrote:
> > What you suggest is about what we have right now. This kind of creates a 
> > misleading situation where for some targets subtargets are present, while 
> > for others paths and image names are "fixed" in several places to include a 
> > "generic". The reason for Paul's patch was to get rid of the fixes at 
> > individual places (which was/is applied somewhat inconsistently) by just 
> > making all targets apply to the same logic (i.e. that there is at least one 
> > subtarget).
> > So, the empty files are introduced to make the process of building and 
> > creating images afterwards simpler (to follow/understand).
> >
> > I was suffering from the same problem when I dealt with OpenWrt-derived 
> > firmware, where I suddenly encountered a target without subtargets and had 
> > to implement extra code to work around that.
> >
> > However, I also wondered whether one couldn't code around the necessity of 
> > the empty file, and just add the SUBTARGET/SUBTARGETS variables here...
>
> Thanks for commenting, that's very much my point!
>
> Maybe the easiest solution is to add `SUBTARGET ?= generic` to
> include/image.mk instead of introducing empty files. Will try that tomorrow.

Thanks, this is what I meant, providing some sensible default value(s).

I have to admit, even after reading your changelog and Adrian's email
twice, I still don't quite grasp what issue this change is trying to
fix. An example might be nice in the changelog.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH v2] brcm63xx: R5010UNv2: fix flash partitions for 16MB flash

[Jonas Gorski]

On Wed, 21 Aug 2019 at 20:57, Daniel Gonzalez Cabanelas
 wrote:
>
> The router Nucom R5010UN v2 has the partitions defined for a 8MB flash, but 
> the
> flash chip is 16MB size. Fix it
>
> Fixes: 474cde61234c ("brcm63xx: probe SPI flash through DT")
> ---

You are missing a SOB.

Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

[Jonas Gorski]

On Fri, 23 Aug 2019 at 11:04, Paul Spooren  wrote:
> As in 853e4dd OpenWrt should follow a unified structure, where every
> device has a target/subtarget combination, if there is only one
> subtarget, call it "Generic". This introduces predictable filenames.

If it's about (I assume generated) filenames, wouldn't it be easier to
just use "Generic" for the subtarget part of the filename if there are
no subtargets? I'm not really a fan of unnecessary code fluff without
any real function, especially if it means additional, mainly empty
files.

Regards
Jonas

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

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

[Jonas Gorski]

On Sun, 1 Sep 2019 at 13:52, Russell Senior  wrote:
>
> >>>>> "Jonas" == Jonas Gorski  writes:
>
> >> It contains a patch at the end titled: "[PATCH] base-files: pad
> >> root.squashfs to 64KiB in ubi volumes" This is another approach that
> >> just deals with the UBI+squashfs issue but works with
> >> "-nopad". Soo do we all agree there?
>
> Jonas> a) 64k is excessive, we only need 4k (actually 1k would be
> Jonas> enough, since we don't enable CONFIG_SQUASHFS_4K_DEVBLK_SIZE).
>
> Jonas> The referenced issue with 64k page size happens when
> Jonas> loop-mounting a squashfs, since loop defaults to PAGE_SIZE as its
> Jonas> block size. But we never do that in OpenWrt, and we don't support
> Jonas> any targets with that huge PAGE_SIZE - biggest is ARC with 8k.
>
> Jonas> b) it misses the squashfs's in generic sysupgrade images itself -
> Jonas> we need to pad their length as well, to avoid breaking devices
> Jonas> with a sysupgrade image hitting the corner case being flashed
> Jonas> from an unfixed firmware with the old nand.sh.
>
> Jonas> Also IMHO "1c0290c5cc6258c48b8ba46b4f9c85a21de4f875" should be
> Jonas> reverted, for the previously mentioned issues.
>
> Afaict, only devices with LEB sizes of non-integer kilobytes (like the
> MR24 with its 15.5k LEBs) need any intervention at all. Because
> squashfs's are read in 1k blocks, there is a 1 in 62 chance of creating
> a rootfs that is an inopportune size on 15.5k LEBs.  I have a PogoPlug
> v3 with LEBs of 126k, and a MikroTik RouterBOARD 493G with LEBs of
> 124k. Neither of those is affected.
>
> I still kind of like my solution where we explicitly ask for padding for
> devices that need it.

The PogoPlug would also be affected if we enabled
SQUASHFS_4K_DEVBLK_SIZE - the 493G wouldn't be. In that case we would
need to pad to 4k.

But in the current situation, If we just pad to 1k, neither one would
see an increase in LEBs used. At worst will the padding make the
squashfs image fit exactly, but it will not cause it to overspill into
a new LEB.

So padding to 1k is harmless for devices with LEBs of a multiple of
1k, and fixes devices with LEBs that have an odd .5k size.


Jonas

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

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

[Jonas Gorski]

On Sat, 31 Aug 2019 at 15:31, Christian Lamparter  wrote:
>
> Hello,
>
> On Saturday, August 31, 2019 2:09:55 PM CEST Jonas Gorski wrote:
> > On Sat, 31 Aug 2019 at 01:19, Christian Lamparter  
> > wrote:
> > >
> > > On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> > > > >>>>> "Christian" == Christian Lamparter  writes:
> > > >
> > > > Christian> Ok.
> > > >
> > > > Christian> I did push a patch titled: "build: remove harmful -nopad
> > > > Christian> option from mksquashfs"
> > > > Christian> 
> > > > <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c0290c5cc6258c48b8ba46b4f9c85a21de4f875>
> > > >
> > > > Christian> so, let's see if this triggers more undefined behaviour and
> > > > Christian> exposes more hidden broken code.
> > > >
> > > > Just to re-iterate my earlier worry, if for example:
> > > >
> > > >   kernel_size + rootfs_with_padding_size
> > > >
> > > > crosses an erase block boundary that:
> > > >
> > > >   kernel_size + rootfs_without_padding_size
> > > >
> > > > does not, then we'll be wasting an erase block of flash space on NOR.
> > > Not to worry. I guess that part of the magic is also explained in the 
> > > wiki:
> > > <https://openwrt.org/docs/techref/flash.layout#example_flash_partitioning>
> > > <https://openwrt.org/docs/techref/flash.layout#explanations>
> > > In case my attempt now gets too confusing :-/.
> > >
> > > The "rootfs" partition also contains the rootfs_data inside. It should
> > > be possible to verify this with any of the routers that use the "firmware"
> > > parition label.
> > >
> > > Please check /proc/mtd. For example on my WNDR3700v2 (which is very 
> > > similar
> > > to your WNDR3800). It looks like this
> > >
> > > |# cat /proc/mtd
> > > |dev:size   erasesize  name
> > > |mtd0: 0005 0001 "u-boot"
> > > |mtd1: 0002 0001 "u-boot-env"
> > > |mtd2: 00f8 0001 "firmware"
> > > |mtd3: 0018c440 0001 "kernel"
> > > |mtd4: 00df3bc0 0001 "rootfs"
> > > |mtd5: 0062 0001 "rootfs_data"
> > > |mtd6: 0001 0001 "art
> > >
> > > The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
> > > fills out the remaining ~2MiB to a total of 16 MiB). So the padding we 
> > > both
> > > are talking about already has to exists between the squashfs portion and 
> > > the
> > > jffs2/overlay portion inside the "rootfs" partition and it's a full 
> > > erase-size
> > > block. Sadly, OpenWrt does not readily print the "end" of just the 
> > > squashfs
> > > partition (as it does with the kernel partition above) and your message 
> > > from
> > > earlier with the three routers didn't include the "squashfs-split" and its
> > > results. (I think that maybe this is the missing information that got 
> > > lost?)
> >
> > After a bit more investigation, those devices that use padjffs2 (or
> > have the rootfs
> > start at an at least 4k aligned offset) will be fine.
> >
> > The issue are those devices with an unaligned rootfs start, which put their 
> > own
> > EOF marker in the image by the firmware util (e.g. brcm63xx or tp-link 
> > devices).
> >
> > There it can happen that e.g. we get
> >
> > 0x18fff2   00 00 00 00
> > 0x19000 00 00 00 00 ...  FF FF
> > 0x19010 FF FF FF ...
> > *
> > 0x2 DE AD C0 DE
> >
> > The 0xff are only a guess, I haven't checked what the different
> > firmware utils use for padding the end of the rootfs - but mksquashfs
> > definitely uses 0x00.
> >
> > which leads to:
> >
> > 1. squashfs-split will put the roofs_data partition start at 0x19000
> > because that's the first aligned erase block after the end of the
> > rootfs start + squashfs length
> > 2. jffs2 will see that the first block is neither a valid jff2 node,
> > an EOF marker, nor all 0xff
> > 3. jffs2 will refuse to erase/mount the filesystem (AFAIU the code) [1]
> >
> > So removing the -nopad might actually break those devices.
> >
> > We could fix this case by making sure that mksquashfs and all firm

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

[Jonas Gorski]

Hi,

On Sat, 31 Aug 2019 at 01:19, Christian Lamparter  wrote:
>
> On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> > > "Christian" == Christian Lamparter  writes:
> >
> > Christian> Ok.
> >
> > Christian> I did push a patch titled: "build: remove harmful -nopad
> > Christian> option from mksquashfs"
> > Christian> 
> > 
> >
> > Christian> so, let's see if this triggers more undefined behaviour and
> > Christian> exposes more hidden broken code.
> >
> > Just to re-iterate my earlier worry, if for example:
> >
> >   kernel_size + rootfs_with_padding_size
> >
> > crosses an erase block boundary that:
> >
> >   kernel_size + rootfs_without_padding_size
> >
> > does not, then we'll be wasting an erase block of flash space on NOR.
> Not to worry. I guess that part of the magic is also explained in the wiki:
> 
> 
> In case my attempt now gets too confusing :-/.
>
> The "rootfs" partition also contains the rootfs_data inside. It should
> be possible to verify this with any of the routers that use the "firmware"
> parition label.
>
> Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
> to your WNDR3800). It looks like this
>
> |# cat /proc/mtd
> |dev:size   erasesize  name
> |mtd0: 0005 0001 "u-boot"
> |mtd1: 0002 0001 "u-boot-env"
> |mtd2: 00f8 0001 "firmware"
> |mtd3: 0018c440 0001 "kernel"
> |mtd4: 00df3bc0 0001 "rootfs"
> |mtd5: 0062 0001 "rootfs_data"
> |mtd6: 0001 0001 "art
>
> The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
> fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
> are talking about already has to exists between the squashfs portion and the
> jffs2/overlay portion inside the "rootfs" partition and it's a full erase-size
> block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
> partition (as it does with the kernel partition above) and your message from
> earlier with the three routers didn't include the "squashfs-split" and its
> results. (I think that maybe this is the missing information that got lost?)

After a bit more investigation, those devices that use padjffs2 (or
have the rootfs
start at an at least 4k aligned offset) will be fine.

The issue are those devices with an unaligned rootfs start, which put their own
EOF marker in the image by the firmware util (e.g. brcm63xx or tp-link devices).

There it can happen that e.g. we get

0x18fff2   00 00 00 00
0x19000 00 00 00 00 ...  FF FF
0x19010 FF FF FF ...
*
0x2 DE AD C0 DE

The 0xff are only a guess, I haven't checked what the different
firmware utils use for padding the end of the rootfs - but mksquashfs
definitely uses 0x00.

which leads to:

1. squashfs-split will put the roofs_data partition start at 0x19000
because that's the first aligned erase block after the end of the
rootfs start + squashfs length
2. jffs2 will see that the first block is neither a valid jff2 node,
an EOF marker, nor all 0xff
3. jffs2 will refuse to erase/mount the filesystem (AFAIU the code) [1]

So removing the -nopad might actually break those devices.

We could fix this case by making sure that mksquashfs and all firmware
utils use 0xff's to pad (so the erase block will then be treated as
empty/all 0xff). But then there is the question how jffs2 reacts if
the first block is 0xff, and the second block is a valid jffs2 node,
which happens when we sysupgrade with keeping config on NOR devices.
The jffs2 code isn't the most readable code ... .


Regards
Jonas

[1]  https://elixir.bootlin.com/linux/latest/source/fs/jffs2/scan.c#L263

all dirty nodes will increase neither c->nr_free_blocks nor
empty_blocks nor badblocks, so the sum will be different from
c->nr_blocks, so jffs2 will refuse to mount

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

Re: [OpenWrt-Devel] KERNEL_PATCHVER in master

[Jonas Gorski]

On Wed, 12 Jun 2019 at 11:02, Koen Vandeputte
 wrote:
>
>
> On 11.06.19 23:12, Jonas Gorski wrote:
> > Hi,
> >
> > On Tue, 11 Jun 2019 at 23:08, Stijn Tintel  wrote:
> >> Hi,
> >>
> >> Since we now have a 19.07 branch, is it OK to switch KERNEL_PATCHVER for
> >> targets in master that have 4.19 support to 4.19?
> > Fine by me. The earlier we start testing 4.19, the faster we can iron
> > out the kinks, hopefully reducing the maturation phase of the next
> > release.
> >
> Fine for me, but please hold off a little bit until I pushed my kernel
> bump later today. (already in staging)
>
> Otherwise there's a chance I need to redo it ;-)

This is only about enabling 4.19 by default if supported, not adding
4.19 support where missing. So shouldn't affect any kernel bumps.

Regards

Jonas

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

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: package module for SafeXcel crypto engine

[Jonas Gorski]

On Wed, 5 Jun 2019 at 16:32, Tomasz Maciej Nowak  wrote:
>
> Supports EIP97 and EIP197 found on Armada 37xx, 7k and 8k SoCs.
> Unfortunately firmware for EIP197 is not easily obtainable, therefore
> to not cause lot of user requests directed at OpenWrt, package it as
> module with explanation where to obtain the firmware.
>
> Cc: Marek Behún 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
>  package/kernel/linux/modules/crypto.mk | 28 ++
>  1 file changed, 28 insertions(+)
>
> diff --git a/package/kernel/linux/modules/crypto.mk 
> b/package/kernel/linux/modules/crypto.mk
> index 9cab04c6ed..ed2ab6aed7 100644
> --- a/package/kernel/linux/modules/crypto.mk
> +++ b/package/kernel/linux/modules/crypto.mk
> @@ -350,6 +350,34 @@ endef
>  $(eval $(call KernelPackage,crypto-hw-padlock))
>
>
> +define KernelPackage/crypto-hw-safexcel
> +  TITLE:= MVEBU SafeXcel Crypto Engine module
> +  DEPENDS:=@LINUX_4_19 @(TARGET_mvebu_cortexa53||TARGET_mvebu_cortexa72) \

Assuming this is isn't exclusive to 4.19, a @!LINUX_4_14 would be more
future proof

> +   +kmod-crypto-authenc +kmod-crypto-md5
> +  KCONFIG:= \
> +   CONFIG_CRYPTO_AES=y \
> +   CONFIG_CRYPTO_BLKCIPHER=y \

These two are already set to =y by the default config, no need to
specify them here.

> +   CONFIG_CRYPTO_DEV_SAFEXCEL \
> +   CONFIG_CRYPTO_HMAC=y \

+kmod-crypto-hmac

> +   CONFIG_CRYPTO_HW=y \
> +   CONFIG_CRYPTO_SHA256=y \

+kmod-crypto-sha256

> +   CONFIG_CRYPTO_SHA512=y

+kmod-crypto-sha512

> +  FILES:=$(LINUX_DIR)/drivers/crypto/inside-secure/crypto_safexcel.ko
> +  AUTOLOAD:=$(call AutoLoad,90,crypto_safexcel)
> +  $(call AddDepends/crypto)
> +endef
> +
> +define KernelPackage/crypto-hw-safexcel/description
> +MVEBU's EIP97 and EIP197 Cryptographic Engine driver designed by
> +Inside Secure. This is found on Marvell Armada 37xx/7k/8k SoCs.
> +
> +Particural version of these IP (EIP197B and EIP197D) require firmware.

s/Particural/Particular/

> +It can be obtained at https://extranet.marvell.com.

You need an NDA to obtain it, which isn't something possible for the
average end user. The description should make it clear that this isn't
a simple "download here" situation. Are there any boards supported by
OpenWrt usable without the firmware?


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 15:28, John Crispin  wrote:
>
>
> On 05/06/2019 15:26, Jonas Gorski wrote:
> > On Wed, 5 Jun 2019 at 15:16, John Crispin  wrote:
> >>
> >> On 05/06/2019 15:11, Jonas Gorski wrote:
> >>> On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
> >>>> On 05/06/2019 14:54, Jonas Gorski wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
> >>>>>> On 05/06/2019 13:35, Karl Palsson wrote:
> >>>>>>> John Crispin  wrote:
> >>>>>>>> On 05/06/2019 12:17, Karl Palsson wrote:
> >>>>>>>>> John Crispin  wrote:
> >>>>>>>>>> This can be used inside build setups for easy feeds.conf
> >>>>>>>>>> generation.
> >>>>>>>>> Could you give us an example of how this is actually easy, or
> >>>>>>>>> what sort of functionality this is providing beyond "cat
> >>>>>>>>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>>>>>>>
> >>>>>>>>> It seems like a lot of perl for a narrow usecase.
> >>>>>>>>>
> >>>>>>>>> Sincerely,
> >>>>>>>>> Karl Palsson
> >>>>>>>> This was brought up as a missing feature by the prpl folks. I
> >>>>>>>> considered on how to best implement this and find that having
> >>>>>>>> proper tooling is much better than having to carry around an
> >>>>>>>> extra file that is cat. being able to build the feeds.conf
> >>>>>>>> dynamically like this just seems much cleaner to me and will
> >>>>>>>> allow downstream users, vendors, odms and integrators to have
> >>>>>>>> less need to patch their trees to death.
> >>>>>>> So, they still have to have a script, but now the script has...
> >>>>>>>
> >>>>>>>
> >>>>>>> ...
> >>>>>>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>>>>>> src-link,private-bb,/wop/blah
> >>>>>>> ...
> >>>>>>>
> >>>>>>> instead of
> >>>>>>> ...
> >>>>>>> cp feeds.conf.default feeds.conf
> >>>>>>> echo "src-git private-aa git://blah" >> feeds.conf
> >>>>>>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>>>>>> ...
> >>>>>>>
> >>>>>>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>>>>>> new tools with new layers of abstraction. I really question
> >>>>>>> whether that's actually simpler for anyone in the long run, and
> >>>>>>> also how this really counts as a "missing feature" There's still
> >>>>>>> going to be a requirement for that vendor script.
> >>>>>>>
> >>>>>>> Sincerely,
> >>>>>>> Karl Palsson
> >>>>>> Its not a new tool, its an extra call to an already existing one. I
> >>>>>> believe that the one liner is much cleaner than the 3 line scriptage.
> >>>>>> there is no requirement for a vendor script. they ship with a PDF that
> >>>>>> has the build steps. This oneline will be much easier to use I believe.
> >>>>> Since the use case is having additional custom feeds to the normal
> >>>>> package feeds, maybe it would make more sense to have a e.g.
> >>>>> feeds.conf.custom that is used as an addition to the
> >>>>> feeds.conf.default instead of completely replacing it. That way you
> >>>>> would avoid missing upstream changes in the feeds.conf.default when
> >>>>> updating your build environment.
> >>>> Hi,
> >>>>
> >>>> The patch does not manipulate the default file at all.
> >>>>
> >>>>
> >>>>> Then we could add a few commands to scripts/feeds for manipulating
> >>>>> that feeds.conf.custom (adding/removing feeds, changing their
> >>>>> types/addresses/names etc).
> >

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 15:16, John Crispin  wrote:
>
>
> On 05/06/2019 15:11, Jonas Gorski wrote:
> > On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
> >>
> >> On 05/06/2019 14:54, Jonas Gorski wrote:
> >>> Hi,
> >>>
> >>> On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
> >>>> On 05/06/2019 13:35, Karl Palsson wrote:
> >>>>> John Crispin  wrote:
> >>>>>> On 05/06/2019 12:17, Karl Palsson wrote:
> >>>>>>> John Crispin  wrote:
> >>>>>>>> This can be used inside build setups for easy feeds.conf
> >>>>>>>> generation.
> >>>>>>> Could you give us an example of how this is actually easy, or
> >>>>>>> what sort of functionality this is providing beyond "cat
> >>>>>>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>>>>>
> >>>>>>> It seems like a lot of perl for a narrow usecase.
> >>>>>>>
> >>>>>>> Sincerely,
> >>>>>>> Karl Palsson
> >>>>>> This was brought up as a missing feature by the prpl folks. I
> >>>>>> considered on how to best implement this and find that having
> >>>>>> proper tooling is much better than having to carry around an
> >>>>>> extra file that is cat. being able to build the feeds.conf
> >>>>>> dynamically like this just seems much cleaner to me and will
> >>>>>> allow downstream users, vendors, odms and integrators to have
> >>>>>> less need to patch their trees to death.
> >>>>> So, they still have to have a script, but now the script has...
> >>>>>
> >>>>>
> >>>>> ...
> >>>>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>>>> src-link,private-bb,/wop/blah
> >>>>> ...
> >>>>>
> >>>>> instead of
> >>>>> ...
> >>>>> cp feeds.conf.default feeds.conf
> >>>>> echo "src-git private-aa git://blah" >> feeds.conf
> >>>>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>>>> ...
> >>>>>
> >>>>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>>>> new tools with new layers of abstraction. I really question
> >>>>> whether that's actually simpler for anyone in the long run, and
> >>>>> also how this really counts as a "missing feature" There's still
> >>>>> going to be a requirement for that vendor script.
> >>>>>
> >>>>> Sincerely,
> >>>>> Karl Palsson
> >>>> Its not a new tool, its an extra call to an already existing one. I
> >>>> believe that the one liner is much cleaner than the 3 line scriptage.
> >>>> there is no requirement for a vendor script. they ship with a PDF that
> >>>> has the build steps. This oneline will be much easier to use I believe.
> >>> Since the use case is having additional custom feeds to the normal
> >>> package feeds, maybe it would make more sense to have a e.g.
> >>> feeds.conf.custom that is used as an addition to the
> >>> feeds.conf.default instead of completely replacing it. That way you
> >>> would avoid missing upstream changes in the feeds.conf.default when
> >>> updating your build environment.
> >> Hi,
> >>
> >> The patch does not manipulate the default file at all.
> >>
> >>
> >>> Then we could add a few commands to scripts/feeds for manipulating
> >>> that feeds.conf.custom (adding/removing feeds, changing their
> >>> types/addresses/names etc).
> >> so instead of using script/commands to create the already existing
> >> feeds.conf file we should introduce a 3rd file ? that makes no sense to me.
> > No, in that case there would be no feeds.conf. Just feeds.conf.default
> > + feeds.conf.custom (a "diff"), so still only two files. Different
> > name to not break existing feeds.conf setups. Or add a marker to
> > feeds.conf to mark it as a "snippet/diff". Or maybe use the include
> > thing proposed by Bjørn at the top line of the generated feeds.conf.
> >
> > So the feeds.conf generated by your command would then be
> >
> > src-include feeds.conf.default
> > src-git custom_stuff git://example.com:foo
> >
> > avoiding having to have a local, unchanging copy of contents of
> > feeds.conf.default in there.
> >
> > A bit like we split up the opkg feeds configuration to basic/dist
> > feeds files and custom feeds file.
> >
> >
> > Regards
> > Jonas
>
>
> That will yet again require an additional git tree, which is not
> deployable inside a tar file + pdf and is voodoo to the users. I do like
> the idea though, but it is fitting for a foss developer and not a
> corporate coder.

??? Where does the additional git tree come from?

If the feeds.conf.default doesn't change, that's fine. But not having
the default feeds in a (local) configuration file has the advantage
that if you e.g. update your base distribution/sdk from e.g. 19.06 to
19.12, you don't need to update your feeds.conf to point to the 19.12
branches. Or re-create it.

Jonas

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

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
>
>
> On 05/06/2019 14:54, Jonas Gorski wrote:
> > Hi,
> >
> > On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
> >>
> >> On 05/06/2019 13:35, Karl Palsson wrote:
> >>> John Crispin  wrote:
> >>>> On 05/06/2019 12:17, Karl Palsson wrote:
> >>>>> John Crispin  wrote:
> >>>>>> This can be used inside build setups for easy feeds.conf
> >>>>>> generation.
> >>>>> Could you give us an example of how this is actually easy, or
> >>>>> what sort of functionality this is providing beyond "cat
> >>>>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>>>
> >>>>> It seems like a lot of perl for a narrow usecase.
> >>>>>
> >>>>> Sincerely,
> >>>>> Karl Palsson
> >>>> This was brought up as a missing feature by the prpl folks. I
> >>>> considered on how to best implement this and find that having
> >>>> proper tooling is much better than having to carry around an
> >>>> extra file that is cat. being able to build the feeds.conf
> >>>> dynamically like this just seems much cleaner to me and will
> >>>> allow downstream users, vendors, odms and integrators to have
> >>>> less need to patch their trees to death.
> >>> So, they still have to have a script, but now the script has...
> >>>
> >>>
> >>> ...
> >>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>> src-link,private-bb,/wop/blah
> >>> ...
> >>>
> >>> instead of
> >>> ...
> >>> cp feeds.conf.default feeds.conf
> >>> echo "src-git private-aa git://blah" >> feeds.conf
> >>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>> ...
> >>>
> >>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>> new tools with new layers of abstraction. I really question
> >>> whether that's actually simpler for anyone in the long run, and
> >>> also how this really counts as a "missing feature" There's still
> >>> going to be a requirement for that vendor script.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> Its not a new tool, its an extra call to an already existing one. I
> >> believe that the one liner is much cleaner than the 3 line scriptage.
> >> there is no requirement for a vendor script. they ship with a PDF that
> >> has the build steps. This oneline will be much easier to use I believe.
> > Since the use case is having additional custom feeds to the normal
> > package feeds, maybe it would make more sense to have a e.g.
> > feeds.conf.custom that is used as an addition to the
> > feeds.conf.default instead of completely replacing it. That way you
> > would avoid missing upstream changes in the feeds.conf.default when
> > updating your build environment.
>
> Hi,
>
> The patch does not manipulate the default file at all.
>
>
> >
> > Then we could add a few commands to scripts/feeds for manipulating
> > that feeds.conf.custom (adding/removing feeds, changing their
> > types/addresses/names etc).
> so instead of using script/commands to create the already existing
> feeds.conf file we should introduce a 3rd file ? that makes no sense to me.

No, in that case there would be no feeds.conf. Just feeds.conf.default
+ feeds.conf.custom (a "diff"), so still only two files. Different
name to not break existing feeds.conf setups. Or add a marker to
feeds.conf to mark it as a "snippet/diff". Or maybe use the include
thing proposed by Bjørn at the top line of the generated feeds.conf.

So the feeds.conf generated by your command would then be

src-include feeds.conf.default
src-git custom_stuff git://example.com:foo

avoiding having to have a local, unchanging copy of contents of
feeds.conf.default in there.

A bit like we split up the opkg feeds configuration to basic/dist
feeds files and custom feeds file.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

Hi,

On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
>
>
> On 05/06/2019 13:35, Karl Palsson wrote:
> > John Crispin  wrote:
> >> On 05/06/2019 12:17, Karl Palsson wrote:
> >>> John Crispin  wrote:
>  This can be used inside build setups for easy feeds.conf
>  generation.
> >>> Could you give us an example of how this is actually easy, or
> >>> what sort of functionality this is providing beyond "cat
> >>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>
> >>> It seems like a lot of perl for a narrow usecase.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> This was brought up as a missing feature by the prpl folks. I
> >> considered on how to best implement this and find that having
> >> proper tooling is much better than having to carry around an
> >> extra file that is cat. being able to build the feeds.conf
> >> dynamically like this just seems much cleaner to me and will
> >> allow downstream users, vendors, odms and integrators to have
> >> less need to patch their trees to death.
> > So, they still have to have a script, but now the script has...
> >
> >
> > ...
> > ./scripts/feeds setup -b src-git,private-aa,git://blah
> > src-link,private-bb,/wop/blah
> > ...
> >
> > instead of
> > ...
> > cp feeds.conf.default feeds.conf
> > echo "src-git private-aa git://blah" >> feeds.conf
> > echo "src-link private-bb /wop/blah" >> feeds.conf
> > ...
> >
> > I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> > new tools with new layers of abstraction. I really question
> > whether that's actually simpler for anyone in the long run, and
> > also how this really counts as a "missing feature" There's still
> > going to be a requirement for that vendor script.
> >
> > Sincerely,
> > Karl Palsson
>
> Its not a new tool, its an extra call to an already existing one. I
> believe that the one liner is much cleaner than the 3 line scriptage.
> there is no requirement for a vendor script. they ship with a PDF that
> has the build steps. This oneline will be much easier to use I believe.

Since the use case is having additional custom feeds to the normal
package feeds, maybe it would make more sense to have a e.g.
feeds.conf.custom that is used as an addition to the
feeds.conf.default instead of completely replacing it. That way you
would avoid missing upstream changes in the feeds.conf.default when
updating your build environment.

Then we could add a few commands to scripts/feeds for manipulating
that feeds.conf.custom (adding/removing feeds, changing their
types/addresses/names etc).

We should also sanity check the arguments, as IIRC dashes are actually
not allowed in feed names ;P


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices

[Jonas Gorski]

On Tue, 15 Jan 2019 at 15:42, Daniel Golle  wrote:
>
> Hi Jonas,
>
> On Mon, Jan 07, 2019 at 03:48:29PM +0100, Daniel Golle wrote:
> > On Mon, Jan 07, 2019 at 02:39:26PM +, Jonas Gorski wrote:
> > > On Mon, 7 Jan 2019 at 14:21, Daniel Golle  wrote:
> > > >
> > > > On Mon, Jan 07, 2019 at 01:17:34PM +, Jonas Gorski wrote:
> > > > > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar  wrote:
> > > > > >
> > > > > > Daniel Golle  [2019-01-07 10:03:09]:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be 
> > > > > > > converted to
> > > > > > > a more sane flash partition layout to gain another megabyte or so.
> > > > > >
> > > > > > I've looked only at mt7621, so this was just example from one 
> > > > > > subtarget of
> > > > > > ramips target. So I tend to believe, that there's quite more such 
> > > > > > cases hidden
> > > > > > in the tree. Please correct me if I'm wrong.
> > > > > >
> > > > > > > Why specific devices? Wouldn't all devices with the resources 
> > > > > > > (which
> > > > > > > boils down to !SMALL_FLASH) be potentially more useful with those
> > > > > > > kernel features enabled?
> > > > > >
> > > > > > You currently can't use !SMALL_FLASH, because this is 
> > > > > > target/subtarget
> > > > > > specific feature, not per device feature. I think, that in order to 
> > > > > > use this
> > > > > > feature, you would need to convert/fix all devices like that 
> > > > > > TP-Link RE350
> > > > > > from all (sub)targets into tiny subtarget and then you could freely 
> > > > > > use
> > > > > > !SMALL_FLASH.
> > > > >
> > > > > I agree with not abusing small_flash for that. It has a clear defined
> > > > > meaning, and shouldn't have unrelated side effects.
> > > >
> > > > So what else would the SMALL_FLASH symbol be used for then?
> > > > A quick grep reveals that currently already quite a few kernel config
> > > > defaults are set according to SMALL_FLASH, see
> > > >
> > > > origin/master:Config-kernel.in-
> > > > origin/master:Config-kernel.in-config KERNEL_SWAP
> > > > origin/master:Config-kernel.in- bool "Support for paging of anonymous 
> > > > memory (swap)"
> > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH
> > > > --
> > > > origin/master:Config-kernel.in-
> > > > origin/master:Config-kernel.in-config KERNEL_KALLSYMS
> > > > origin/master:Config-kernel.in- bool "Compile the kernel with symbol 
> > > > table information"
> > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH
> > > > --
> > > > origin/master:Config-kernel.in-
> > > > origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO
> > > > origin/master:Config-kernel.in- bool "Compile the kernel with debug 
> > > > information"
> > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH
> > > > --
> > > > origin/master:Config-kernel.in-config KERNEL_ELF_CORE
> > > > origin/master:Config-kernel.in- bool "Enable process core dump support"
> > > > origin/master:Config-kernel.in- select KERNEL_COREDUMP
> > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH
> > > > ...
> > >
> > > Most of these option only influence the size of the kernel, and have
> > > no further runtime side effects. Also small_flash has impact on the
> > > compression options used.
> >
> > They sure do, cache size on small CPUs is a very finite resource
> > and having a kernel with debug symbols will make things slower, of
> > course. SWAP also makes every single malloc call more expensive and
> > is just as well only useful on devices with block storage (ok, and
> > zramswap, but lets not talk about that).
> >
> > >
> > > >
> > > > >
> > > > > I think a new opt-in symbol for those targets with hardware
> > > > > virtualization support and/or beefy enough cpus would make more sense.
> > > >

Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices

[Jonas Gorski]

On Mon, 7 Jan 2019 at 14:21, Daniel Golle  wrote:
>
> On Mon, Jan 07, 2019 at 01:17:34PM +, Jonas Gorski wrote:
> > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar  wrote:
> > >
> > > Daniel Golle  [2019-01-07 10:03:09]:
> > >
> > > Hi,
> > >
> > > > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be converted to
> > > > a more sane flash partition layout to gain another megabyte or so.
> > >
> > > I've looked only at mt7621, so this was just example from one subtarget of
> > > ramips target. So I tend to believe, that there's quite more such cases 
> > > hidden
> > > in the tree. Please correct me if I'm wrong.
> > >
> > > > Why specific devices? Wouldn't all devices with the resources (which
> > > > boils down to !SMALL_FLASH) be potentially more useful with those
> > > > kernel features enabled?
> > >
> > > You currently can't use !SMALL_FLASH, because this is target/subtarget
> > > specific feature, not per device feature. I think, that in order to use 
> > > this
> > > feature, you would need to convert/fix all devices like that TP-Link RE350
> > > from all (sub)targets into tiny subtarget and then you could freely use
> > > !SMALL_FLASH.
> >
> > I agree with not abusing small_flash for that. It has a clear defined
> > meaning, and shouldn't have unrelated side effects.
>
> So what else would the SMALL_FLASH symbol be used for then?
> A quick grep reveals that currently already quite a few kernel config
> defaults are set according to SMALL_FLASH, see
>
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_SWAP
> origin/master:Config-kernel.in- bool "Support for paging of anonymous memory 
> (swap)"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_KALLSYMS
> origin/master:Config-kernel.in- bool "Compile the kernel with symbol table 
> information"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO
> origin/master:Config-kernel.in- bool "Compile the kernel with debug 
> information"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-config KERNEL_ELF_CORE
> origin/master:Config-kernel.in- bool "Enable process core dump support"
> origin/master:Config-kernel.in- select KERNEL_COREDUMP
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> ...

Most of these option only influence the size of the kernel, and have
no further runtime side effects. Also small_flash has impact on the
compression options used.

>
> >
> > I think a new opt-in symbol for those targets with hardware
> > virtualization support and/or beefy enough cpus would make more sense.
> > Those virtualization options (probably) don't come for free, they will
> > have also a memory and performance impact even when not actively used.
> > How much that is (and if this assumption is true) would be nice to
> > have in the PR/patch for it.
>
> This is not about virtualization and none of the features selected
> requires any special hardware support apart from the few extra
> kilobytes of flash and memory. You are still right, it doesn't come
> all for free at runtime in terms of CPU cycles, but the impact is
> hardly measurable.
>
> But sure, I understand that this can be opt-in, so lets call it
> 'full_kernel' or something like that and have target maintainers
> decide themselves. In the picture I get after browsing through
> all targets, it would still end up such that
> full_kernel == !small_flash is true for all cases.

"Full kernel" really has no real meaning and would describe
everything. The name should clearly describe the (non-default) feature
set it enables.

> And sure, I can carry out some size measurements and compare memory
> allocation after boot. I'm sure the run-time CPU impact is hardly
> measurable at all.

Please do so especially on low end devices. Maybe something like
routing throughput with/without.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices

[Jonas Gorski]

On Mon, 7 Jan 2019 at 11:42, Petr Štetiar  wrote:
>
> Daniel Golle  [2019-01-07 10:03:09]:
>
> Hi,
>
> > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be converted to
> > a more sane flash partition layout to gain another megabyte or so.
>
> I've looked only at mt7621, so this was just example from one subtarget of
> ramips target. So I tend to believe, that there's quite more such cases hidden
> in the tree. Please correct me if I'm wrong.
>
> > Why specific devices? Wouldn't all devices with the resources (which
> > boils down to !SMALL_FLASH) be potentially more useful with those
> > kernel features enabled?
>
> You currently can't use !SMALL_FLASH, because this is target/subtarget
> specific feature, not per device feature. I think, that in order to use this
> feature, you would need to convert/fix all devices like that TP-Link RE350
> from all (sub)targets into tiny subtarget and then you could freely use
> !SMALL_FLASH.

I agree with not abusing small_flash for that. It has a clear defined
meaning, and shouldn't have unrelated side effects.

I think a new opt-in symbol for those targets with hardware
virtualization support and/or beefy enough cpus would make more sense.
Those virtualization options (probably) don't come for free, they will
have also a memory and performance impact even when not actively used.
How much that is (and if this assumption is true) would be nice to
have in the PR/patch for it.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] brcm63xx: perform a soft reset on the ehternet switch before its initializiation

[Jonas Gorski]

Hi,

On Sun, 11 Nov 2018 at 15:15, Daniel Gonzalez Cabanelas
 wrote:
> Add a switch reset on brcm63xx SoCs to ensure a sane state before
> initializiating the switch.
>
> Performing this reset on BCM6368 solves the ticket #1925 on the
> Observa VH4032N:
>
>   - brcm63xx: VH4032N: no traffic between b53 lan switch ports.
>
> Other devices with different SoCs may be also affected but they
> wasn't still  tested, so don't perform the reset on them for now.
>
> Furthermore some bcm63xx SoCs doesn't have registers to perform
> the reset (i.e BCM6358, BCM6348).

The core reset should have been taken care of by the clock driver
(don't ask), but the reset mask wasn't set for the ethernet core on
6368 due to a copy & paste error. I pushed a fix for that to master,
please check if it's now fixed.


Regards
Jonas
Jonas

>
> Signed-off-by: Daniel Gonzalez Cabanelas 
> ---
>  .../425-bcm63xx_enet_add_switch_soft_reset.patch   | 64 
> ++
>  1 file changed, 64 insertions(+)
>  create mode 100644 
> target/linux/brcm63xx/patches-4.14/425-bcm63xx_enet_add_switch_soft_reset.patch
>
> diff --git 
> a/target/linux/brcm63xx/patches-4.14/425-bcm63xx_enet_add_switch_soft_reset.patch
>  
> b/target/linux/brcm63xx/patches-4.14/425-bcm63xx_enet_add_switch_soft_reset.patch
> new file mode 100644
> index 000..2726593
> --- /dev/null
> +++ 
> b/target/linux/brcm63xx/patches-4.14/425-bcm63xx_enet_add_switch_soft_reset.patch
> @@ -0,0 +1,64 @@
> +--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
>  b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
> +@@ -2691,6 +2691,48 @@ static const struct ethtool_ops bcm_enet
> +   .set_ringparam  = bcm_enetsw_set_ringparam,
> + };
> +
> ++static void bcm_enetsw_soft_reset(void)
> ++{
> ++  u32 reg, mask, offs;
> ++
> ++  if (BCMCPU_IS_6318()) {
> ++  offs = PERF_SOFTRESET_6318_REG;
> ++  mask = SOFTRESET_6318_ENETSW_MASK;
> ++  }
> ++  else if (BCMCPU_IS_6328()) {
> ++  offs = PERF_SOFTRESET_6328_REG;
> ++  mask = SOFTRESET_6328_ENETSW_MASK;
> ++  }
> ++  else if (BCMCPU_IS_6358()) {
> ++  offs = PERF_SOFTRESET_6358_REG;
> ++  mask = 0;
> ++  }
> ++  else if (BCMCPU_IS_6362()) {
> ++  offs = PERF_SOFTRESET_6362_REG;
> ++  mask = SOFTRESET_6362_ENETSW_MASK;
> ++  }
> ++  else if (BCMCPU_IS_6368()) {
> ++  offs = PERF_SOFTRESET_6368_REG;
> ++  mask = SOFTRESET_6368_ENETSW_MASK;
> ++  }
> ++  else if (BCMCPU_IS_63268()) {
> ++  offs = PERF_SOFTRESET_63268_REG;
> ++  mask = SOFTRESET_63268_ENETSW_MASK;
> ++  }
> ++  else {
> ++  offs = PERF_SOFTRESET_REG;
> ++  mask = 0;
> ++  }
> ++
> ++  reg = bcm_perf_readl(offs);
> ++  reg &= ~mask;
> ++  bcm_perf_writel(reg, offs);
> ++  udelay(1000);
> ++  reg |= mask;
> ++  bcm_perf_writel(reg, offs);
> ++  udelay(1000);
> ++}
> ++
> + /* allocate netdevice, request register memory and register device. */
> + static int bcm_enetsw_probe(struct platform_device *pdev)
> + {
> +@@ -2784,6 +2826,12 @@ static int bcm_enetsw_probe(struct platf
> +   priv->pdev = pdev;
> +   priv->net_dev = dev;
> +
> ++  /* Reset the switch to ensure a sane state on the required SoCs.
> ++   * Only tested on 6368. More SoCs may also need this
> ++   */
> ++  if (BCMCPU_IS_6368())
> ++  bcm_enetsw_soft_reset();
> ++
> +   /* reset mib */
> +   val = enetsw_readb(priv, ENETSW_GMCR_REG);
> +   val |= ENETSW_GMCR_RST_MIB_MASK;
> --
> 2.6.4
>
>
>
> ___
> 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] [PATCH] mvebu: fix the cortex-a9 fpu configure

[Jonas Gorski]

On 30 August 2018 at 04:31, ayaka  wrote:
> Both Marvell Armada 37x and 38x support NEON and VFPv3,
> so we enable the NEON FPU with the SIMD aliases.

But the Armada XP doesn't, so this would break devices based on it
(like the WRT1900AC v1).


Regards
Jonas

>
> Signed-off-by: ayaka 
> ---
>  include/target.mk | 1 +
>  target/linux/mvebu/cortexa9/target.mk | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/target.mk b/include/target.mk
> index 53d7436311..330eb175cc 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -201,6 +201,7 @@ ifeq ($(DUMP),1)
>CPU_CFLAGS_neon = -mfpu=neon
>CPU_CFLAGS_vfp = -mfpu=vfp
>CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16
> +  CPU_CFLAGS_simd = -mfpu=neon-vfpv3
>CPU_CFLAGS_neon-vfpv4 = -mfpu=neon-vfpv4
>  endif
>endif
> diff --git a/target/linux/mvebu/cortexa9/target.mk 
> b/target/linux/mvebu/cortexa9/target.mk
> index 2a75599bc9..9e6119bf6b 100644
> --- a/target/linux/mvebu/cortexa9/target.mk
> +++ b/target/linux/mvebu/cortexa9/target.mk
> @@ -10,5 +10,5 @@ include $(TOPDIR)/rules.mk
>  ARCH:=arm
>  BOARDNAME:=Marvell Armada 37x/38x/XP
>  CPU_TYPE:=cortex-a9
> -CPU_SUBTYPE:=vfpv3
> +CPU_SUBTYPE:=simd
>  KERNELNAME:=zImage dtbs
> --
> 2.14.4
>
>
> ___
> 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] [PATCH] [RFC] ath79: ag71xx: apply interface mode to MII0/1_CNTL on ar71xx/ar913x

[Jonas Gorski]

Hi,

On 16 August 2018 at 05:05, Chuanhong Guo  wrote:
> Signed-off-by: Chuanhong Guo 
> ---
> RFC:
> Previous discussion about this patch can be found on GitHub PR#1271.
> This patch applies correct interface mode to MII0/1_CNTL register at 
> 0x1807/
> 0x18070004. But there is a small difference in values for these two registers:
> | GMAC0| GMAC1   |
> |--|-|
> | 0 GMII   | 0 RGMII |
> | 1 MII| 1 RMII  |
> | 2 RGMII  | |
> | 3 RMII   | |
> I currently have 4 ways of dealing with this:
> 1. Use a bool value in dts indicating whether this is the second GMAC. This 
> one
>is pretty dirty and I dropped it.
> 2. Split MII_CNTL into separated dt node and use different compatible for them
>like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some 
> discussion
>on GitHub it turns out to be unreasonable to treat those in separated 
> nodes.
> 3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done in
>this patch I sent here. But I think my way of using compatible string here 
> is ugly :(
>A possible cleaner implementation would be introducing 
> ar7100-eth0/ar7100-eth1/
>ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt 
> whether
>introducing 4 new compatible strings for such a slight difference is 
> worthy.
> 4. Somehow write all the possible values for each interface mode in device 
> tree.
>e.g. qca,if-modes = "gmii","mii","rgmii","rmii"; for eth0 and
> qca,if-modes = "rgmii","rmii"; for eth1.
>
> Which one is better? Is there any other possible solutions for this problem?

I'd prefer 4, or a modified 3:

do something like

aliases {
 
 ethernet0 = 
 ethernet1 = 
};


and then you can find out if you are eth0 or eth1 by calling

id = of_alias_get_id(node, "ethernet");

and maybe warn (and don't configure mii mode) if it returns neither 0 or 1.


Regards
Jonas

>
>  target/linux/ath79/dts/ar7100.dtsi|  4 +-
>  target/linux/ath79/dts/ar9132.dtsi|  2 +-
>  .../net/ethernet/atheros/ag71xx/ag71xx_main.c | 61 +++
>  3 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/target/linux/ath79/dts/ar7100.dtsi 
> b/target/linux/ath79/dts/ar7100.dtsi
> index 8994a7d688..89c17bcede 100644
> --- a/target/linux/ath79/dts/ar7100.dtsi
> +++ b/target/linux/ath79/dts/ar7100.dtsi
> @@ -171,7 +171,7 @@
>  };
>
>   {
> -   compatible = "qca,ar7100-eth";
> +   compatible = "qca,ar7100-eth0", "qca,ar7100-eth";
> reg = <0x1900 0x200
> 0x1807 0x4>;
>
> @@ -189,7 +189,7 @@
>  };
>
>   {
> -   compatible = "qca,ar7100-eth";
> +   compatible = "qca,ar7100-eth1", "qca,ar7100-eth";
> reg = <0x1a00 0x200
> 0x18070004 0x4>;
>
> diff --git a/target/linux/ath79/dts/ar9132.dtsi 
> b/target/linux/ath79/dts/ar9132.dtsi
> index 9d8ddcf9ba..a136b06e69 100644
> --- a/target/linux/ath79/dts/ar9132.dtsi
> +++ b/target/linux/ath79/dts/ar9132.dtsi
> @@ -185,7 +185,7 @@
>  };
>
>   {
> -   compatible = "qca,ar9130-eth", "syscon";
> +   compatible = "qca,ar9130-eth", "qca,ar7100-eth0", "syscon";
> reg = <0x1900 0x200
> 0x1807 0x4>;
> pll-data = <0x1a00 0x13000a44 0x00441099>;
> diff --git 
> a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c 
> b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> index 1e0bb6937f..5ea9ef40d2 100644
> --- 
> a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> +++ 
> b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> @@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
> udelay(100);
>  }
>
> +static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
> +{
> +   u32 t;
> +
> +   t = __raw_readl(ag->mii_base);
> +   t &= ~(AR71XX_MII_CTRL_IF_MASK);
> +   t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
> +   __raw_writel(t, ag->mii_base);
> +}
> +
> +static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
> +{
> +   unsigned int mii_if;
> +
> +   switch (ag->phy_if_mode) {
> +   case PHY_INTERFACE_MODE_MII:
> +   mii_if = AR71XX_MII0_CTRL_IF_MII;
> +   break;
> +   case PHY_INTERFACE_MODE_GMII:
> +   mii_if = AR71XX_MII0_CTRL_IF_GMII;
> +   break;
> +   case PHY_INTERFACE_MODE_RGMII:
> +   mii_if = AR71XX_MII0_CTRL_IF_RGMII;
> +   break;
> +   case PHY_INTERFACE_MODE_RMII:
> +   mii_if = AR71XX_MII0_CTRL_IF_RMII;
> +   break;
> +   default:
> +   WARN(1, "Impossible PHY mode defined.\n");
> +   return;
> +   }
> +
> +   ath79_mii_ctrl_set_if(ag, mii_if);
> +}
> +
> +static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
> +{
> +   unsigned int mii_if;
> +
> +   switch 

Re: [OpenWrt-Devel] [PATCH 2/5] ath79: port cybertan_part from ar71xx

[Jonas Gorski]

On 10 August 2018 at 23:24, Christian Lamparter  wrote:
> The cybertan_part mtd parser is ported over from ar71xx and converted
> to integrate into the "firmware" mtd splitter. It will no longer add
> the u-boot, nvram and art partitions, which were never part of the
> special Cybertan header.
>
> Instead these partitions have to be specified in the DT, which has the
> upside of making it possible to add properties (i.e.: read-only), labels
> and references to these important partitions.

Instead of using the OpenWrt proprietary FIRMWARE_PARSER thingy, there
is now an upstream (device tree) solution for that.

By giving the parser an of_mach_table (with e.g. "foo,cybertan") you
can then define it as

partitions {
   ...

   partition@4 {
   label = "firmware";
   reg = <0x4 0x7a>;
   compatible = "foo,cybertan";
   };
   ...
};

and the parser will be called for the firmware partition.

And then we can eventually drop the FIRMWARE_PARSER stuff from OpenWrt.

See 
http://git.infradead.org/linux-mtd-next.git/blob/HEAD:/drivers/mtd/parsers/parser_trx.c
for an example of such a parser. Should be really not much change
needed for that (also it should then reside in the parsers sub
directory). The hardest part will be figuring out, what the right
compatible name is ;-)


>
> Signed-off-by: Christian Lamparter 
> ---
>  target/linux/ath79/config-4.14|   1 +
>  .../ath79/files/drivers/mtd/cybertan_part.c   | 176 ++
>  .../404-mtd-cybertan-trx-parser.patch |  25 +++
>  .../405-mtd-tp-link-partition-parser.patch|   6 +-
>  4 files changed, 205 insertions(+), 3 deletions(-)
>  create mode 100644 target/linux/ath79/files/drivers/mtd/cybertan_part.c
>  create mode 100644 
> target/linux/ath79/patches-4.14/404-mtd-cybertan-trx-parser.patch
>
> diff --git a/target/linux/ath79/config-4.14 b/target/linux/ath79/config-4.14
> index a8349040a1..312740ed17 100644
> --- a/target/linux/ath79/config-4.14
> +++ b/target/linux/ath79/config-4.14
> @@ -171,6 +171,7 @@ CONFIG_MTD_SPLIT_SEAMA_FW=y
>  CONFIG_MTD_SPLIT_TPLINK_FW=y
>  CONFIG_MTD_SPLIT_UIMAGE_FW=y
>  CONFIG_MTD_SPLIT_WRGG_FW=y
> +CONFIG_MTD_CYBERTAN_PARTS=y
>  CONFIG_MTD_TPLINK_PARTS=y
>  CONFIG_NEED_DMA_MAP_STATE=y
>  CONFIG_NEED_PER_CPU_KM=y
> diff --git a/target/linux/ath79/files/drivers/mtd/cybertan_part.c 
> b/target/linux/ath79/files/drivers/mtd/cybertan_part.c
> new file mode 100644
> index 00..47742b2674
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/mtd/cybertan_part.c
> @@ -0,0 +1,176 @@
> +/*
> + * Copyright (C) 2009 Christian Daniel 
> + * Copyright (C) 2009 Gabor Juhos 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * TRX flash partition table.
> + * Based on ar7 map by Felix Fietkau 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct cybertan_header {
> +   charmagic[4];
> +   u8  res1[4];
> +   charfw_date[3];
> +   charfw_ver[3];
> +   charid[4];
> +   charhw_ver;
> +   charunused;
> +   u8  flags[2];
> +   u8  res2[10];
> +};
> +
> +#define TRX_PARTS  3
> +#define TRX_MAGIC  0x30524448
> +#define TRX_MAX_OFFSET 3
> +
> +struct trx_header {
> +   uint32_t magic;   /* "HDR0" */
> +   uint32_t len; /* Length of file including header */
> +   uint32_t crc32;   /* 32-bit CRC from flag_version to end of 
> file */
> +   uint32_t flag_version;/* 0:15 flags, 16:31 version */
> +   uint32_t offsets[TRX_MAX_OFFSET]; /* Offsets of partitions from start 
> of header */
> +};
> +
> +#define IH_MAGIC   0x27051956  /* Image Magic Number */
> +#define IH_NMLEN   32  /* Image Name Length */
> +
> +struct uimage_header {
> +   uint32_tih_magic;   /* Image Header Magic Number */
> +   uint32_tih_hcrc;/* Image Header CRC Checksum */
> +   uint32_tih_time;/* Image Creation Timestamp */
> +   uint32_tih_size;/* Image Data Size */
> +  

Re: [OpenWrt-Devel] [PATCH v3] base-files: make wifi report unknown command

[Jonas Gorski]

On 9 August 2018 at 20:35, Thibaut  wrote:
>
>> On 9 Aug 2018, at 19:58, Jonas Gorski  wrote:
>>
>> On 9 August 2018 at 18:49, Thibaut VARÈNE  wrote:
>>> Avoid having /sbin/wifi silently ignore unknown keywords and execute
>>> "enable"; instead display the help message and exit with an error.
>>>
>>> Spell out the 'enable' keyword and preserve the implicit assumption
>>> that runing /sbin/wifi without argument performs "enable".
>>>
>>> Signed-off-by: Thibaut VARÈNE 
>>> ---
>>
>> Please keep a changelog here to know what's changed between submissions.
>
> it’s a 2-liner patch. I don’t think it warrants a changelog in the commit 
> message :)

The fact that you needed to send 4 versions should be enough of an
argument to keep a changelog regardless of the size of the patch ;)

Also the changelog belongs below the tear-off line ("---") so it
doesn't end in the commit message.

So please keep that in mind for future patches.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH v3] base-files: make wifi report unknown command

[Jonas Gorski]

On 9 August 2018 at 18:49, Thibaut VARÈNE  wrote:
> Avoid having /sbin/wifi silently ignore unknown keywords and execute
> "enable"; instead display the help message and exit with an error.
>
> Spell out the 'enable' keyword and preserve the implicit assumption
> that runing /sbin/wifi without argument performs "enable".
>
> Signed-off-by: Thibaut VARÈNE 
> ---

Please keep a changelog here to know what's changed between submissions.

>  package/base-files/files/sbin/wifi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/package/base-files/files/sbin/wifi 
> b/package/base-files/files/sbin/wifi
> index 83befc0d6f..68536ed25f 100755
> --- a/package/base-files/files/sbin/wifi
> +++ b/package/base-files/files/sbin/wifi
> @@ -241,5 +241,6 @@ case "$1" in
> reload) wifi_reload "$2";;
> reload_legacy) wifi_reload_legacy "$2";;
> --help|help) usage;;
> -   *) ubus call network reload; wifi_updown "enable" "$2";;
> +   ''|enable) ubus call network reload; wifi_updown "enable" "$2";;

Not that I particularily want to bikeshed here, but the disable
command is "down", so the enable command should be "up", not "enable".

There are actually existing users of "up": see

https://github.com/openwrt/openwrt/blob/master/package/network/config/netifd/files/sbin/ifup#L43

and

https://github.com/openwrt/openwrt/blob/master/package/network/config/netifd/files/sbin/ifup#L75

or

https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/rc.button/rfkill#L30

so it isn't just a should, it's a must. Or the existing users must be
changed before.

> +   *) usage; exit 1;;
>  esac


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] mediatek: Fix amount of memory on U7623

[Jonas Gorski]

On 6 August 2018 at 19:46, Kristian Evensen  wrote:
> While finalizing support for the U7623 with 512MB RAM, I made an embarrassing
> error and configured 1GB RAM for the board. I also forgot to move memory
> from the dtsi and to the dts. This commit takes care of my errors.
>
> While I am confessing my mistakes, I also note that I made a mistake in
> the commit message of the initial U7623 commit. It is the .bin-file, and
> not the .gz file that shall be sent to the device via tftp.
>
> Signed-off-by: Kristian Evensen 
> ---
>  .../0227-arm-dts-Add-Unielec-U7623-DTS.patch   | 37 
> +-
>  1 file changed, 22 insertions(+), 15 deletions(-)
>
> diff --git 
> a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch 
> b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
> index eb864e4657..8c0b7611b6 100644
> --- 
> a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
> +++ 
> b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
> @@ -1,16 +1,18 @@
> -From 13872b8abfadfe70598c065c19d1db759477c4e6 Mon Sep 17 00:00:00 2001
> +From 1ebcba67d45f1365bcb1b5eb8b0cd8c847610ef2 Mon Sep 17 00:00:00 2001
>  From: Kristian Evensen 
>  Date: Sun, 17 Jun 2018 14:41:47 +0200
>  Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
>
>  ---
>   arch/arm/boot/dts/Makefile |   1 +
> - .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  17 +
> - .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 375 
> +
> - 3 files changed, 393 insertions(+)
> + .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  22 ++
> + .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 366 
> +
> + 3 files changed, 389 insertions(+)
>   create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
>   create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
>
> +diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> +index 3fec84fa0..e685ce9a4 100644
>  --- a/arch/arm/boot/dts/Makefile
>  +++ b/arch/arm/boot/dts/Makefile
>  @@ -1062,6 +1062,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> @@ -21,9 +23,12 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
> mt7623n-rfb-nand.dtb \
> mt7623n-bananapi-bpi-r2.dtb \
> mt8127-moose.dtb \
> +diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts 
> b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
> +new file mode 100644
> +index 0..6efa6e159
>  --- /dev/null
>  +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
> -@@ -0,0 +1,17 @@
> +@@ -0,0 +1,22 @@
>  +/*
>  + * Copyright 2018 Kristian Evensen 
>  + *
> @@ -40,10 +45,18 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
>  +  memory {
>  +  reg = <0 0x8000 0 0x2000>;
>  +  };
> ++
> ++  memory@8000 {
> ++  device_type = "memory";
> ++  reg = <0 0x8000 0 0x2000>;
> ++  };

You are adding a second memory node with the same register range as
the one directly above here, that looks wrong.


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] kernel: modules: fix kmod-regmap

[Jonas Gorski]

On 3 August 2018 at 18:00, Christian Lamparter  wrote:
> diff --git a/package/kernel/linux/modules/other.mk 
> b/package/kernel/linux/modules/other.mk
> index dd037cf86c..7e18a21db3 100644
> --- a/package/kernel/linux/modules/other.mk
> +++ b/package/kernel/linux/modules/other.mk
> @@ -718,7 +718,7 @@ define KernelPackage/regmap
>SUBMENU:=$(OTHER_MENU)
>TITLE:=Generic register map support
>DEPENDS:=+kmod-lib-lzo +kmod-i2c-core
> -  KCONFIG:=CONFIG_REGMAP=y \
> +  KCONFIG:=CONFIG_REGMAP \
>CONFIG_REGMAP_MMIO \
>CONFIG_REGMAP_SPI \
>CONFIG_REGMAP_I2C \
> diff --git a/target/linux/generic/hack-4.14/259-regmap_dynamic.patch 
> b/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> index 1c6e78df30..458b7c35a1 100644
> --- a/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> +++ b/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> @@ -103,7 +103,7 @@ Signed-off-by: Felix Fietkau 
>   })
>
>  -#ifdef CONFIG_REGMAP
> -+#if IS_ENABLED(CONFIG_REGMAP)
> ++#if IS_REACHABLE(CONFIG_REGMAP)
>
>   enum regmap_endian {
> /* Unspecified -> 0 -> Backwards compatible default */
> ---
>
> I think this should do just that. To quote IS_REACHABLE help text:"
> IS_REACHABLE(CONFIG_FOO) evaluates to 1 if the currently compiled
> code can call a function defined in code compiled based on CONFIG_FOO.
> This is similar to IS_ENABLED(), but returns false when invoked from
> built-in code when CONFIG_FOO is set to 'm'."
>
> and it should combine the best of both worlds. (And maybe make it
> possible to disable the REGMAP=y from ath79-tiny. Any testers?)

Ooh, I didn't know that one exists! Nice find! Yes, that should
fix it in a clean way without introducing more hacks.

I really like this one!


Regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] kernel: modules: fix kmod-regmap

[Jonas Gorski]

On 1 August 2018 at 22:44, Christian Lamparter  wrote:
> On Wednesday, August 1, 2018 3:21:00 PM CEST Jonas Gorski wrote:
>> On 30 July 2018 at 22:35, John Crispin  wrote:
>> > On 30/07/18 22:33, Christian Lamparter wrote:
>> >>
>> >> This patch fixes the a compile issue that was triggered by
>> >> apm821xx/sata when kmod-regmap was selected.
>> >>
>> >> The CONFIG_REGMAP is declared in drivers/base/regmap/Kconfig
>> >> as type "bool" and not "tristate". Hence the symbol should
>> >> never be set to module, as this confuses the #if CONFIG_REGMAP
>> >> guards in include/linux/regmap.h:
>> >>
>> >> |.../drivers/regulator/core.c:4041: undefined reference to
>> >> `dev_get_regmap'
>> >> |.../drivers/regulator/core.c:4042: undefined reference to
>> >> `dev_get_regmap'
>> >> |.../drivers/regulator/core.c:4044: undefined reference to
>> >> `dev_get_regmap'
>> >> |.../drivers/regulator/helpers.o: In function
>> >> `regulator_is_enabled_regmap':
>> >> |.../drivers/regulator/helpers.c:36: undefined reference to `regmap_read'
>> >> |...
>> >
>> > i started a test build 2 minutes ago to figure this one out :-) thanks !
>>
>> This is actually the wrong fix and papers over an issue in one of our
>> local patches.
>>
>> We intentionally allow regmap to be built as a module, see
>>
>> https://github.com/openwrt/openwrt/blob/master/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
>>
>> So there are likely some additional EXPORT_SYMBOL_GPL()s required instead.
>
> Thanks for FYI, I missed this patch completely.
>
> I found that the issue lies in the upstream regulator core code.
> It is using these regmap's functions. And the CONFIG_REGULATOR symbol that 
> pulls
> in the core's code is sadly a bool menuconfig option... so CONFIG_REGMAP 
> pretty
> much becomes a requirement/select for the REGULATOR.

This is one of the more trickier variants, it optionally supports
regmap thanks to the stubs provided if regmap is disabled - which
breaks if you compile regmap as a module. I expect this to happen more
in the future.

This is a bit tricky to solve. We can't just generally stub out the
regmap stuff unless compiled in, as a lot of regulators depend on it.
A proper fix is likely a bit more work (as usual).

>
> ---
> diff --git a/target/linux/generic/hack-4.14/259-regmap_dynamic.patch 
> b/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> index 1c6e78df30..35803c3181 100644
> --- a/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> +++ b/target/linux/generic/hack-4.14/259-regmap_dynamic.patch
> @@ -9,8 +9,9 @@ Signed-off-by: Felix Fietkau 
>   drivers/base/regmap/Kconfig  | 15 ++-
>   drivers/base/regmap/Makefile | 12 
>   drivers/base/regmap/regmap.c |  3 +++
> + drivers/regulator/Kconfig|  1 +
>   include/linux/regmap.h   |  2 +-
> - 4 files changed, 22 insertions(+), 10 deletions(-)
> + 5 files changed, 23 insertions(+), 10 deletions(-)
>
>  --- a/drivers/base/regmap/Kconfig
>  +++ b/drivers/base/regmap/Kconfig
> @@ -96,6 +97,15 @@ Signed-off-by: Felix Fietkau 
>   postcore_initcall(regmap_initcall);
>  +
>  +MODULE_LICENSE("GPL");
> +--- a/drivers/regulator/Kconfig
>  b/drivers/regulator/Kconfig
> +@@ -1,5 +1,6 @@
> + menuconfig REGULATOR
> +   bool "Voltage and Current Regulator Support"
> ++  select REGMAP

This will cause REGMAP to be included regardless if needed or not, but
would be acceptable (at least to me) as an interim build fix (most
targets using REGULATORs likely won't be part of the 4/32 gang
anyway).

The correct fix is likely to

a) add this REGMAP select to all REGULATOR drivers depending on/using
it (this can probably even be upstreamed)
b) (OpenWrt only) Change the usage in regulator/core.c and
regulator/helper.c to work like REGMAP is disabled if it is build as a
module.

b) is to allow building REGMAP as =m even when REGULATOR is enabled,
if no REGMAP requiring REGULATOR driver is enabled.


regards
Jonas

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

Re: [OpenWrt-Devel] [PATCH] kernel: modules: fix kmod-regmap

[Jonas Gorski]

On 30 July 2018 at 22:35, John Crispin  wrote:
>
>
> On 30/07/18 22:33, Christian Lamparter wrote:
>>
>> This patch fixes the a compile issue that was triggered by
>> apm821xx/sata when kmod-regmap was selected.
>>
>> The CONFIG_REGMAP is declared in drivers/base/regmap/Kconfig
>> as type "bool" and not "tristate". Hence the symbol should
>> never be set to module, as this confuses the #if CONFIG_REGMAP
>> guards in include/linux/regmap.h:
>>
>> |.../drivers/regulator/core.c:4041: undefined reference to
>> `dev_get_regmap'
>> |.../drivers/regulator/core.c:4042: undefined reference to
>> `dev_get_regmap'
>> |.../drivers/regulator/core.c:4044: undefined reference to
>> `dev_get_regmap'
>> |.../drivers/regulator/helpers.o: In function
>> `regulator_is_enabled_regmap':
>> |.../drivers/regulator/helpers.c:36: undefined reference to `regmap_read'
>> |...
>
> i started a test build 2 minutes ago to figure this one out :-) thanks !

This is actually the wrong fix and papers over an issue in one of our
local patches.

We intentionally allow regmap to be built as a module, see

https://github.com/openwrt/openwrt/blob/master/target/linux/generic/hack-4.14/259-regmap_dynamic.patch

So there are likely some additional EXPORT_SYMBOL_GPL()s required instead.


Regards
Jonas

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

Re: [OpenWrt-Devel] [LEDE-DEV] [RFC 1/2] downloads.mk: introduce name-agnostic PROJECT_GIT variable

[Jonas Gorski]

On 5 January 2018 at 10:53, Jo-Philipp Wich  wrote:
> Introduce a name-agnostic PROJECT_GIT variable poiting to
> https://git.openwrt.org/ and declare LEDE_GIT and OPENWRT_GIT
> as aliases to it.
>
> After some transition time we can drop this alias variables.
>
> Signed-off-by: Jo-Philipp Wich 

Generally looks good, but we should defer it until the old
git.openwrt.org entry got purged from dns caches (which is still like
4 or 5 days or so?)


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

[OpenWrt-Devel] Ownership for LEDE Members on OpenWrt (Was: extending OpenWrt packages maintainers by a new member)

[Jonas Gorski]

On 19 December 2017 at 15:10, Ted Hess  wrote:
> Ack from me.
>
> While you're at it - Alexander Couzens (@lynxis) should have Member status
> too.
>
> And... I wouldn't mind Owner status here since I have it everywhere else (If
> someone would be so kind).

Since we agreed to remerge anyway, I gave everyone with owner status
of lede-project owner status on OpenWrt. Which means I upgraded

Daniel Golle (@dangowrt)
Matthias Shiffer (@neorider)
Álvaro Fernández Rojas (@noltari)
Stijn Tintel (@stintel)
Ted Hess (thess)

from member to owner, and invited

Hans Dedecker (@dedeckeh)
Alexander Couzens (@lynxis)
Mathias Kresin (@mkresin)
Piotr Dymacz (@pepe2k)

I did not the reverse in the assumption lede-project will function as
a simple mirror in the near future anyway.


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

Re: [OpenWrt-Devel] [PATCH] linux: Get rid of 000-keep_initrafs_the_default.patch

[Jonas Gorski]

Hi,

On 22 July 2016 at 12:18, Alexey Brodkin  wrote:
> With that patch in place for initramfs no additional options are
> reported for "/" partition. What's really important is missing
> info about sizes. Which in its turn makes opkg think that there's
> no space on "/" partition to install software.
>
> I understand that's a sort of corner-case, people rarely install
> packages on ramfs but anyways why not?
>
> Just in case that's what I see with the patch:
> -->8
> root@lede:/# cat /proc/mounts
> rootfs / rootfs rw 0 0
> proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
> sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
> tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
> tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
> debugfs /sys/kernel/debug debugfs rw,noatime 0 0
> -->8
>
> And without:
> -->8
> root@lede:/# cat /proc/mounts
> rootfs / rootfs rw,size=256168k,nr_inodes=32021 0 0
> proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
> sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
> tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
> tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
> debugfs /sys/kernel/debug debugfs rw,noatime 0 0
> -->8
>
> Note how different is entry for rootfs.
>
> And given there's no known rationale for that patch we're
> getting rid of it.

I gave this a small spin on brcm63xx and didn't see anything broken by
it. Actually I didn't see anything changing at all, the /proc/mounts
contents stayed the same with or without the patch.


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

Re: [OpenWrt-Devel] [PATCH 1/2] layerscape: add ls1043ardb-64b target

[Jonas Gorski]

Hi,

On 13 July 2016 at 19:56,   wrote:
> From: Yutang Jiang 
>
> Add support for NXP layerscape ls1043ardb-64b Dev board.

Nice to see support for it here. A few things first, though

>
> ls1043ardb-64b target is using 4.1 kernel and rcw/u-boot/fman images from
>  NXP QorIQ SDK V2.0 release.

Please update your codebase to 4.4 first. The next release kernel is
currently planned to be 4.4.

> All of 4.1 kernel patches will be in the second patch, it have more than
>  100 kernel patches: platform/flash/dpaa/mmc/usb/pcie etc, porting from
>  SDK release or upstream.

Please add them at the same time. If it's too large for an email, you
can also put the commit in a public git repository. You can also
create a pull request on github.

I guess several of the patches will be obsolete with the switch to 4.4 anyway?

>
> Signed-off-by: Yutang Jiang 
> ---
>  target/linux/layerscape-64b/Makefile   |   26 +
>  target/linux/layerscape-64b/README.ls1043ardb  |  860 ++
>  target/linux/layerscape-64b/base-files/etc/inittab |6 +
>  target/linux/layerscape-64b/image/Makefile |   64 +
>  .../linux/layerscape-64b/image/checkimagesize.sh   |   16 +
>  .../linux/layerscape-64b/ls1043ardb/config-default | 3146 
> 
>  target/linux/layerscape-64b/ls1043ardb/target.mk   |   16 +
>  7 files changed, 4134 insertions(+)
>  create mode 100644 target/linux/layerscape-64b/Makefile
>  create mode 100644 target/linux/layerscape-64b/README.ls1043ardb
>  create mode 100644 target/linux/layerscape-64b/base-files/etc/inittab
>  create mode 100644 target/linux/layerscape-64b/image/Makefile
>  create mode 100755 target/linux/layerscape-64b/image/checkimagesize.sh
>  create mode 100644 target/linux/layerscape-64b/ls1043ardb/config-default
>  create mode 100644 target/linux/layerscape-64b/ls1043ardb/target.mk
>
> diff --git a/target/linux/layerscape-64b/Makefile 
> b/target/linux/layerscape-64b/Makefile
> new file mode 100644
> index 000..63d55b9
> --- /dev/null
> +++ b/target/linux/layerscape-64b/Makefile
> @@ -0,0 +1,26 @@
> +#
> +# Copyright (C) 2016 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +include $(TOPDIR)/rules.mk
> +
> +ARCH:=aarch64
> +BOARD:=layerscape-64b
> +BOARDNAME:=layerscape 64b
> +CFLAGS:=-Os -pipe -fno-caller-saves
> +DEVICE_TYPE:=developerboard
> +KERNEL_PATCHVER:=4.1
> +KERNELNAME:=Image dtbs
> +FEATURES:=squashfs
> +SUBTARGETS:=ls1043ardb
> +MAINTAINER:=Jiang Yutang 
> +
> +include $(INCLUDE_DIR)/target.mk
> +
> +define Target/Description
> +   Build firmware images for $(BOARDNAME) SoC devices.
> +endef
> +
> +$(eval $(call BuildTarget))
> diff --git a/target/linux/layerscape-64b/README.ls1043ardb 
> b/target/linux/layerscape-64b/README.ls1043ardb
> new file mode 100644
> index 000..9f6a0af
> --- /dev/null
> +++ b/target/linux/layerscape-64b/README.ls1043ardb
> @@ -0,0 +1,860 @@
(snip)

I think a lot of this information (like the bootlog) is better served
on the wiki, or shouldn't be here at all (like the contents of various
uci files, which are subject to change, and nobody will remember to
update the example output here).

> diff --git a/target/linux/layerscape-64b/image/Makefile 
> b/target/linux/layerscape-64b/image/Makefile
> new file mode 100644
> index 000..43e7269
> --- /dev/null
> +++ b/target/linux/layerscape-64b/image/Makefile
> @@ -0,0 +1,64 @@
> +#
> +# Copyright (C) 2016 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +include $(TOPDIR)/rules.mk
> +include $(INCLUDE_DIR)/image.mk
> +
> +# make uImage and dtb
> +define Image/uImage-dtb
> +   gzip -9c < $(KDIR)/Image > $(KDIR)/Image.gz
> +   $(eval ARCH_BACK = $(ARCH))
> +   $(eval ARCH = $(LINUX_KARCH))
> +   $(call Image/BuildKernel/MkuImage, gzip, $(KERNEL_LOADADDR), \
> +   $(KERNEL_ENTRY_POINT), $(KDIR)/Image.gz, \
> +   $(KDIR)/$(IMG_PREFIX)-uImage)
> +   $(eval ARCH = $(ARCH_BACK))
> +
> +   $(call 
> Image/BuildDTB,$(DTS_DIR)/$(DEVICE_DTS).dts,$(KDIR)/$(IMG_PREFIX)-dtb)
> +endef
> +
> +# $(1) source image name
> +# $(2) partition image name
> +# $(3) partition image size(M)
> +define Image/Build/flashpartitionimage
> +   ./checkimagesize.sh $(1) $(3)
> +   dd if=/dev/zero bs=1M count=$(3) | sed 's/\x00/\xff/g' > $(2)
> +   dd if=$(1) of=$(2) conv=notrunc
> +endef
> +
> +# make squashfs then merge uImage/dtb/squashfs to one firmware image arranged
> +# by individual partition
> +define Image/Build/squashfs
> +   $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
> +
> +   $(call 
> Image/Build/flashpartitionimage,$(KDIR)/$(IMG_PREFIX)-dtb,$(KDIR)/$(IMG_PREFIX)-dtb-par,$(DTB_PARTITION_SIZE))
> +   $(call 
> 

Re: [OpenWrt-Devel] [PATCH 1/2] swconfig: implement (PHY) generic PORT_LINK setter

[Jonas Gorski]

Hi,

On 21 January 2016 at 14:55, Rafał Miłecki  wrote:
> It's quite common for switches to have PHY per port so we may use a
> generic function for setting port link. We just need an API to access
> PHYs which this patch also adds.
>
> Signed-off-by: Rafał Miłecki 
> ---
>  .../linux/generic/files/drivers/net/phy/swconfig.c | 44 
> --
>  target/linux/generic/files/include/linux/switch.h  |  3 ++
>  2 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/swconfig.c 
> b/target/linux/generic/files/drivers/net/phy/swconfig.c
> index 9a5f1e9..8b9bb51 100644
> --- a/target/linux/generic/files/drivers/net/phy/swconfig.c
> +++ b/target/linux/generic/files/drivers/net/phy/swconfig.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define SWCONFIG_DEVNAME   "switch%d"
>
> @@ -131,10 +132,47 @@ static int
>  swconfig_set_link(struct switch_dev *dev, const struct switch_attr *attr,
> struct switch_val *val)
>  {
> -   if (!dev->ops->set_port_link)
> -   return -EOPNOTSUPP;
> +   struct switch_port_link *link = val->value.link;
> +   int port = val->port_vlan;
> +
> +   if (port == dev->cpu_port)
> +   return -EINVAL;

The cpu port might not be the only port that may not be modified;
sometimes there is more than one fixed connection, sometimes the phy
ports aren't contiguous.

I think it would make more sense to add a function for switch drivers
to call than to do it directly in the callback, so they can do
something like

int b53_set_link(...)
{
   /* TODO: BCM63XX requires special handling as it can have
external phys, and ports might be GE or only FE */
   if (is63xx(dev))
  return -EINVAL;

  if (port == dev->CPU_PORT)
  return -EINVAL;

  if (!(BIT(port) & dev->enabled_ports))
  return -EINVAL;

   if (link->speed == SWITCH_PORT_SPEED_1000 && (is5325() || is5365())
  return -EINVAL;

   if (link->speed == SWITCH_PORT_SPEED_1000 && !link->duplex)
  return -EINVAL;

   return switch_generic_set_link(...);
}

> +
> +   /* Custom implementation */
> +   if (dev->ops->set_port_link)
> +   return dev->ops->set_port_link(dev, port, link);
> +

And the following being the generic function to call:

> +   /* Chceck if we can use generic implementation */

*Check

> +   if (!dev->ops->phy_write16)
> +   return -ENOTSUPP;
> +

this-^ one maybe with a WARN_ON() to spot misusage.

> +   /* Generic implementation */
> +   if (link->aneg) {
> +   dev->ops->phy_write16(dev, port, MII_BMCR, 0x);
> +   dev->ops->phy_write16(dev, port, MII_BMCR, BMCR_ANENABLE | 
> BMCR_ANRESTART);
> +   } else {
> +   u16 bmcr = 0;
>
> -   return dev->ops->set_port_link(dev, val->port_vlan, val->value.link);
> +   if (link->duplex)
> +   bmcr |= BMCR_FULLDPLX;
> +
> +   switch (link->speed) {
> +   case SWITCH_PORT_SPEED_10:
> +   break;
> +   case SWITCH_PORT_SPEED_100:
> +   bmcr |= BMCR_SPEED100;
> +   break;
> +   case SWITCH_PORT_SPEED_1000:
> +   bmcr |= BMCR_SPEED1000;
> +   break;
> +   default:
> +   return -ENOTSUPP;
> +   }
> +
> +   dev->ops->phy_write16(dev, port, MII_BMCR, bmcr);
> +   }
> +
> +   return 0;
>  }
>
>  static int
> diff --git a/target/linux/generic/files/include/linux/switch.h 
> b/target/linux/generic/files/include/linux/switch.h
> index 4ada0e5..ab587ea 100644
> --- a/target/linux/generic/files/include/linux/switch.h
> +++ b/target/linux/generic/files/include/linux/switch.h
> @@ -99,6 +99,9 @@ struct switch_dev_ops {
>  struct switch_port_link *link);
> int (*get_port_stats)(struct switch_dev *dev, int port,
>   struct switch_port_stats *stats);
> +
> +   int (*phy_read16)(struct switch_dev *dev, int addr, u8 reg, u16 
> *value);
> +   int (*phy_write16)(struct switch_dev *dev, int addr, u8 reg, u16 
> value);
>  };
>
>  struct switch_dev {
> --
> 1.8.4.5


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

Re: [OpenWrt-Devel] [PATCH] brcm63xx: Let the CFE partition in HG556a to be writeable

[Jonas Gorski]

Hi,

On Wed, Dec 2, 2015 at 9:37 PM, dani  wrote:
> In the HG556a router the partition mtd0, where CFE lives, is read only.
> This patch allows this partition to be writeable.
>
> The BCM6358 SoC has two cores, but they are not identical. The second core has
> half icache.
> core0: icache=32kB
> core1: icache=16kB
>
> As default the HG556a uses the second core as the main one (configured by 
> CFE).
> Since currently there isn't SMP support for using both cores, we want to use 
> the
> one with the best performance.
>
> For using the core0 as the main one, we need to write some bytes at the offset
> 0x014 of mtd0 (CFE). Therefore we need the mtd0 partition to be writeable.
>
> After setting the core0 as the main one, the performance can increase up to
> +20% (tested). The performance gain isn't marginal.
>
> For setting the core0 as the main one in an easy way I wrote a very simple 
> utility:
> https://wiki.openwrt.org/_media/media/huawei/tp0set.tar.gz
> It can switch from core0 to core1 or vice versa in OpenWrt writing proper 
> bytes
> into bcm6358 CFE (fully tested in the HG556a, no bricks).

To be honest, I'm not very comfortable with making the CFE partition
writable, and rather add code to lzma-loader that switches back to
thread 0, then add lzma-loader for the affected devices.


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

Re: [OpenWrt-Devel] [PATCH] brcm63xx: add support for ZyXEL P870HNU-51b

[Jonas Gorski]

Hi,

On 20 December 2015 at 04:52, Mohammed Berdai  wrote:
> This router is a ZyXEL VDSL2 router and its board has :
> chip ID: BCM6368B2, MIPS: 400MHz,
> Total Flash size: 16384K with 128 sectors
> Total Memory: 67108864 bytes (64MB)
> Board Id (0-15): 96368MVWG
>
> with a usb port, and wifi Broadcom bcm43222.
> This router requires the image to have: --signature "ZyXEL_4004" -pad
> 8 --image-offset 0x2
>
> this patch is for Trunk (compiled and tested against  trunk@47953
> 3c298f89-4303-0410-b956-a3cf2f4a3e73 )
>
>

You are missing a Signed-off-by, also your patch does not apply:

Applying patch #559307 using 'git am'
Description: [OpenWrt-Devel] brcm63xx: add support for ZyXEL P870HNU-51b
Applying: brcm63xx: add support for ZyXEL P870HNU-51b
fatal: corrupt patch at line 167

it looks like your email program broke the patch by wrapping lines,
replacing all tabs with spaces and removing trailing spaces. Please
fix and resend. I highly suggest using git send-email for sending
patches.

Also ..

> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index c01aba8..061871c 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -88,6 +88,7 @@ fast2504n |\
>  fast2704v2 |\
>  hg655b |\
>  p870hw-51a_v2 |\
> +p870hnu-51b |\

Please use alphabetical ordering where appropriate.

(snipped rest)


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

Re: [OpenWrt-Devel] [PATCH 1/2] b53: add internal API for accessing PHY regs

[Jonas Gorski]

Hi,

On 6 January 2016 at 20:02, Rafał Miłecki  wrote:
> Signed-off-by: Rafał Miłecki 

Please don't leave the commit log empty. E.g. state why you need to
add this new function.
> ---
>  .../generic/files/drivers/net/phy/b53/b53_mdio.c | 20 
> 
>  .../generic/files/drivers/net/phy/b53/b53_priv.h | 14 ++
>  .../generic/files/drivers/net/phy/b53/b53_srab.c | 15 +++
>  3 files changed, 49 insertions(+)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c 
> b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> index 3c25f0e..185c95f 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> @@ -238,6 +238,24 @@ static int b53_mdio_write64(struct b53_device *dev, u8 
> page, u8 reg,
> return b53_mdio_op(dev, page, reg, REG_MII_ADDR_WRITE);
>  }
>
> +static int b53_mdio_phy_read16(struct b53_device *dev, int addr, u8 reg,
> +  u16 *value)
> +{
> +   struct mii_bus *bus = dev->priv;
> +
> +   *value = mdiobus_read(bus, addr, reg);
> +
> +   return 0;
> +}
> +
> +static int b53_mdio_phy_write16(struct b53_device *dev, int addr, u8 reg,
> +   u16 value)
> +{
> +   struct mii_bus *bus = dev->priv;
> +
> +   return mdiobus_write(bus, addr, reg, value);
> +}
> +
>  static struct b53_io_ops b53_mdio_ops = {
> .read8 = b53_mdio_read8,
> .read16 = b53_mdio_read16,
> @@ -249,6 +267,8 @@ static struct b53_io_ops b53_mdio_ops = {
> .write32 = b53_mdio_write32,
> .write48 = b53_mdio_write48,
> .write64 = b53_mdio_write64,
> +   .phy_read16 = b53_mdio_phy_read16,
> +   .phy_write16 = b53_mdio_phy_write16,
>  };
>
>  static int b53_phy_probe(struct phy_device *phydev)
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h 
> b/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
> index 0c4c394..7891238 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
> @@ -36,6 +36,8 @@ struct b53_io_ops {
> int (*write32)(struct b53_device *dev, u8 page, u8 reg, u32 value);
> int (*write48)(struct b53_device *dev, u8 page, u8 reg, u64 value);
> int (*write64)(struct b53_device *dev, u8 page, u8 reg, u64 value);
> +   int (*phy_read16)(struct b53_device *dev, int addr, u8 reg, u16 
> *value);
> +   int (*phy_write16)(struct b53_device *dev, int addr, u8 reg, u16 
> value);
>  };
>
>  enum {
> @@ -299,6 +301,18 @@ static inline int b53_write64(struct b53_device *dev, u8 
> page, u8 reg,
> return ret;
>  }
>
> +static inline int b53_phy_read16(struct b53_device *dev, int addr, u8 reg,
> +u16 *value)
> +{
> +   return dev->ops->phy_read16(dev, addr, reg, value);

Since you only add the functions to phy and srab and you don't check
for NULL, this will OOPS for spi and mmap.

> +}
> +
> +static inline int b53_phy_write16(struct b53_device *dev, int addr, u8 reg,
> + u16 value)
> +{
> +   return dev->ops->phy_write16(dev, addr, reg, value);
> +}
> +
>  #ifdef CONFIG_BCM47XX
>
>  #include 
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_srab.c 
> b/target/linux/generic/files/drivers/net/phy/b53/b53_srab.c
> index 012daa3..438c6f8 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_srab.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_srab.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>
> +#include "b53_regs.h"
>  #include "b53_priv.h"
>
>  /* command and status register of the SRAB */
> @@ -321,6 +322,18 @@ err:
> return ret;
>  }
>
> +static int b53_srab_phy_read16(struct b53_device *dev, int addr, u8 reg,
> +  u16 *value)
> +{
> +   return b53_read16(dev, B53_PORT_MII_PAGE(addr), reg, value);
> +}
> +
> +static int b53_srab_phy_write16(struct b53_device *dev, int addr, u8 reg,
> +   u16 value)
> +{
> +   return b53_write16(dev, B53_PORT_MII_PAGE(addr), reg, value);

Since these will be the default implementations for everything but
mdio, how about rather doing someting like

static inline int b53_phy_read16(...)
{
   if (dev->ops->phy_read16)
  return dev->ops->phy_read16(...);

   return b53_read16(dev, B53_PORT_MII_PAGE(addr), reg, value);
}

That way you don't need to add a version for every connector.

> +}
> +
>  static struct b53_io_ops b53_srab_ops = {
> .read8 = b53_srab_read8,
> .read16 = b53_srab_read16,
> @@ -332,6 +345,8 @@ static struct b53_io_ops b53_srab_ops = {
> .write32 = b53_srab_write32,
> .write48 = b53_srab_write48,
> .write64 = b53_srab_write64,
> +   .phy_read16 = b53_srab_phy_read16,
> + 

Re: [OpenWrt-Devel] [PATCH 2/2] b53: support setting port link state

[Jonas Gorski]

Hi,

On 6 January 2016 at 20:02, Rafał Miłecki  wrote:
> Signed-off-by: Rafał Miłecki 
> ---
>  .../generic/files/drivers/net/phy/b53/b53_common.c | 40 
> ++
>  1 file changed, 40 insertions(+)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c 
> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> index 859d8d1..42a1679 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "b53_regs.h"
>  #include "b53_priv.h"
> @@ -794,6 +795,42 @@ static int b53_port_get_link(struct switch_dev *dev, int 
> port,
>
>  }
>
> +static int b53_port_set_link(struct switch_dev *dev, int port,
> +struct switch_port_link *link)
> +{
> +   struct b53_device *priv = sw_to_b53(dev);
> +
> +   if (!priv->ops->phy_write16)
> +   return -ENOTSUPP;

Oh, you do the check here, that was unexpected.

You should also disallow reconfiguration of non-(e)phy ports like the cpu port.

> +
> +   if (link->aneg) {
> +   b53_phy_write16(priv, port, MII_BMCR, 0x);
> +   b53_phy_write16(priv, port, MII_BMCR, BMCR_ANENABLE | 
> BMCR_ANRESTART);
> +   } else {
> +   u16 bmcr = 0;
> +
> +   if (link->duplex)
> +   bmcr |= BMCR_FULLDPLX;
> +
> +   switch (link->speed) {
> +   case SWITCH_PORT_SPEED_10:
> +   break;
> +   case SWITCH_PORT_SPEED_100:
> +   bmcr |= BMCR_SPEED100;
> +   break;
> +   case SWITCH_PORT_SPEED_1000:
> +   bmcr |= BMCR_SPEED1000;

b53 supports switches with fast ethernet only ports, so you need to
make sure that you don't try to set gige speed on them.

> +   break;
> +   default:
> +   return -ENOTSUPP;
> +   }
> +
> +   b53_phy_write16(priv, port, MII_BMCR, bmcr);
> +   }
> +
> +   return 0;

This function does nothing broadcom/b53 specific. I would think that
exposing the phys over the mdio bus is rather common for switches, so
I wonder if it wouldn't make more sense to have generic write/read mii
page function pointers for swconfig and move this function to the
swconfig common code.


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

Re: [OpenWrt-Devel] [PATCH] brcm63xx: fix gpio ephy-reset

[Jonas Gorski]

Hi,

On 12 December 2015 at 14:10, dani  wrote:
> Currently ephy-reset, which uses a GPIO for enabling external ethernet phys, 
> is broken.
> This patch fix the problem.
>
> This problem causes in boards with external phys with a reset pin connected 
> to gpio, are
> initialized without lan interfaces.
>
> The line
> ephy_reset.table[0].chip_label = gpio_chip_labels[hw_gpio / 32];
> always returns bcm63xx-gpio.1. As a result of this, reset pins connected to 
> gpios <32
> will return messages "gpio X out of range", and ethernet fails to initialize.
>
> The array *gpio_chip_labels[] should be initialized with different names for 
> each element,
> otherwise sprintf will copy the label of the gpio chip for both elements at 
> the same time.
> And the name of both elements of the array will be the same.
>
> Using a different name on the second array element solves the problem.
> Signed-off-by: Daniel Gonzalez 

I added a slightly different approach in r48303, can you verify it
works for you?


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

Re: [OpenWrt-Devel] [PATCH] brcm63xx: add support for Huawei HG622

[Jonas Gorski]

Hi,

On 16 December 2015 at 23:05, Álvaro Fernández Rojas  wrote:
> Signed-off-by: Álvaro Fernández Rojas 

in the future I will reject patches with an empty commit message.

Applied in r48305.


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

Re: [OpenWrt-Devel] [PATCH v3] Add support for C-style in dtsi files

[Jonas Gorski]

Hi,

you still haven't answered my questions:

On Mon, Dec 7, 2015 at 4:07 PM, Nikolay Martynov  wrote:
> Current way of compuling dts files involves calling C preprocessor on
> main dts file only. This means that dtsi includes cannot have C-style 
> includes.

Why not? Shouldn't they get processed as well as long as they are
included with #include, not /include/? Can you give an example that
doesn't work?

> This patch addresses this problem. It uses approach similar to one
> use in linux kernel: it preprocesses all dtsi's in current dir into
> tmp dir and then uses that tmp dir as include dir for main dts compilation.

I can't find this code in the kernel at all. Can you please point that out?


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

Re: [OpenWrt-Devel] [PATCH] [ipq806x] Add initial support for TP-Link Archer C2600

[Jonas Gorski]

tb \
> ++ qcom-ipq8064-c2600.dtb \
> + qcom-msm8660-surf.dtb \
> + qcom-msm8960-cdp.dtb \
> + qcom-msm8974-sony-xperia-honami.dtb
> +diff -urN a/arch/arm/boot/dts/qcom-ipq8064-c2600.dts
> b/arch/arm/boot/dts/qcom-ipq8064-c2600.dts
> +--- a/arch/arm/boot/dts/qcom-ipq8064-c2600.dts 1970-01-01
> 01:00:00.0 +0100
>  b/arch/arm/boot/dts/qcom-ipq8064-c2600.dts 2015-12-06
> 14:20:05.152365670 +0100
> +@@ -0,0 +1,231 @@
> ++#include "qcom-ipq8064-v1.0.dtsi"
> ++
> ++/ {
> ++ model = "TP-Link Archer C2600";
> ++ compatible = "tplink,c2600", "qcom,ipq8064";
> ++
> ++ memory@0 {
> ++ reg = <0x4200 0x1e00>;
> ++ device_type = "memory";
> ++ };
> ++
> ++ reserved-memory {
> ++ #address-cells = <1>;
> ++ #size-cells = <1>;
> ++ ranges;
> ++ rsvd@4120 {
> ++ reg = <0x4120 0x30>;
> ++ no-map;
> ++ };
> ++ };
> ++
> ++ aliases {
> ++ serial0 = 
> ++ mdio-gpio0 = 
> ++ };
> ++
> ++ chosen {
> ++ linux,stdout-path = "serial0:115200n8";
> ++ };
> ++
> ++ soc {
> ++ pinmux@80 {
> ++ i2c4_pins: i2c4_pinmux {
> ++ pins = "gpio12", "gpio13";
> ++ function = "gsbi4";
> ++ bias-disable;
> ++ };
> ++
> ++ spi_pins: spi_pins {
> ++ mux {
> ++ pins = "gpio18", "gpio19", "gpio21";
> ++ function = "gsbi5";
> ++ drive-strength = <10>;
> ++ bias-none;
> ++ };
> ++ };
> ++
> ++ nand_pins: nand_pins {
> ++ mux {
> ++ pins = "gpio34", "gpio35", "gpio36",
> ++   "gpio37", "gpio38", "gpio39",
> ++   "gpio40", "gpio41", "gpio42",
> ++   "gpio43", "gpio44", "gpio45",
> ++   "gpio46", "gpio47";
> ++ function = "nand";
> ++ drive-strength = <10>;
> ++ bias-disable;
> ++ };
> ++
> ++ pullups {
> ++ pins = "gpio39";
> ++ bias-pull-up;
> ++ };
> ++
> ++ hold {
> ++ pins = "gpio40", "gpio41", "gpio42",
> ++   "gpio43", "gpio44", "gpio45",
> ++   "gpio46", "gpio47";
> ++ bias-bus-hold;
> ++ };
> ++ };
> ++
> ++ mdio0_pins: mdio0_pins {
> ++ mux {
> ++ pins = "gpio0", "gpio1";
> ++ function = "gpio";
> ++ drive-strength = <8>;
> ++ bias-disable;
> ++ };
> ++ };
> ++
> ++ rgmii2_pins: rgmii2_pins {
> ++ mux {
> ++ pins = "gpio27", "gpio28", "gpio29", "gpio30", "gpio31", "gpio32",
> ++   "gpio51", "gpio52", "gpio59", "gpio60", "gpio61", "gpio62" ;
> ++ function = "rgmii2";
> ++ drive-strength = <8>;
> ++ bias-disable;
> ++ };
> ++ };
> ++ };
> ++
> ++ gsbi@1630 {
> ++ qcom,mode = ;
> ++ status = "ok";
> ++ serial@1634 {
> ++ status = "ok";
> ++ };
> ++ /*
> ++ * The i2c device on gsbi4 should not be enabled.
> ++ * On ipq806x designs gsbi4 i2c is meant for exclusive
> ++ * RPM usage. Turning this on in kernel manifests as
> ++ * i2c failure for the RPM.
> ++ */
> ++ };
> ++
> ++ gsbi5: gsbi@1a20 {
> ++ qcom,mode = ;
> ++ status = "ok";
> ++
> ++ spi4: spi@1a28 {
> ++ status = "ok";
> ++ spi-max-frequency = <5000>;
> ++
> ++ pinctrl-0 = <_pins>;
> ++ pinctrl-names = "default";
> ++
> ++ cs-gpios = <_pinmux 20 0>;
> ++
> ++ flash: m25p80@0 {
> ++ compatible = "s25fl256s1";
> ++ #address-cells = <1>;
> ++ #size-cells = <1>;
> ++ spi-max-frequency = <5000>;
> ++ reg = <0>;

So it has both nor and nand flash?

> ++
> ++ linux,part-probe = "qcom-smem";
> ++ };
> ++ };
> ++ };
> ++
> ++ phy@100f8800 { /* USB3 port 1 HS phy */
> ++ status = "ok";
> ++ };
> ++
> ++ phy@100f8830 { /* USB3 port 1 SS phy */
> ++ status = "ok";
> ++ };
> ++
> ++ phy@110f8800 { /* USB3 port 0 HS phy */
> ++ status = "ok";
> ++ };
> ++
> ++ phy@110f8830 { /* USB3 port 0 SS phy */
> ++ status = "ok";
> ++ };
> ++
> ++ usb30@0 {
> ++ status = "ok";
> ++ };
> ++
> ++ usb30@1 {
> ++ status = "ok";
> ++ };
> ++
> ++ pcie0: pci@1b50 {
> ++ status = "ok";
> ++ phy-tx0-term-offset = <7>;
> ++ };
> ++
> ++ pcie1: pci@1b70 {
> ++ status = "ok";
> ++ phy-tx0-term-offset = <7>;
> ++ };
> ++
> ++ nand@1ac0 {
> ++ status = "ok";
> ++
> ++ pinctrl-0 = <_pins>;
> ++ pinctrl-names = "default";
> ++
> ++ nand-ecc-strength = <4>;
> ++ nand-bus-width = <8>;
> ++
> ++ linux,part-probe = "qcom-smem";
> ++ };
> ++
> ++ mdio0: mdio {
> ++ compatible = "virtual,mdio-gpio";
> ++ #address-cells = <1>;
> ++ #size-cells = <0>;
> ++ gpios = <_pinmux 1 0 _pinmux 0 0>;
> ++ pinctrl-0 = <_pins>;
> ++ pinctrl-names = "default";
> ++
> ++ phy0: ethernet-phy@0 {
> ++ device_type = "ethernet-phy";
> ++ reg = <0>;
> ++ qca,ar8327-initvals = <
> ++ 0x4 0x760   /* PAD0_MODE */
> ++ 0x8 0x100   /* PAD5_MODE */
> ++ 0xc 0x80/* PAD6_MODE */
> ++ 0x000e4 0xaa545 /* MAC_POWER_SEL */
> ++ 0x000e0 0xc74164de  /* SGMII_CTRL */
> ++ 0x0007c 0x4e/* PORT0_STATUS */
> ++ 0x00094 0x4e/* PORT6_STATUS */
> ++ >;
> ++ };
> ++
> ++ phy4: ethernet-phy@4 {
> ++ device_type = "ethernet-phy";
> ++ reg = <4>;
> ++ };
> ++ };
> ++
> ++ gmac1: ethernet@3720 {
> ++ status = "ok";
> ++ phy-mode = "rgmii";
> ++ phy-handle = <>;

So your wan port works fine with a 10 or 100 Mbit connection?

> ++ qcom,id = <1>;
> ++
> ++ pinctrl-0 = <_pins>;
> ++ pinctrl-names = "default";
> ++ };
> ++
> ++ gmac2: ethernet@3740 {
> ++ status = "ok";
> ++ phy-mode = "sgmii";
> ++ qcom,id = <2>;
> ++
> ++ fixed-link {
> ++ speed = <1000>;
> ++ full-duplex;
> ++ };
> ++ };
> ++ };
> ++};
> ++
> ++_dma {
> ++ status = "ok";
> ++};

(snip)

>
>
> On 5 December 2015 at 15:08, Jonas Gorski <j...@openwrt.org> wrote:

Please don't top post or send new versions as replies to older version.


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

Re: [OpenWrt-Devel] [PATCH] [ipq806x] Add initial support for TP-Link Archer C2600

[Jonas Gorski]

Hi,

please try to keep the number of replies low, ideally one.

On Mon, Dec 7, 2015 at 5:05 PM, Josh Bendavid  wrote:
> (Sorry about the top posting)
>

and keep some context to what you are replying to.

> For the flash, the stock firmware, and the factory images built with these
> patches are using only the NOR flash as far as I know.
>
> I am not 100% sure whether the NAND is physically there or not (what would
> be the easiest way to check?)

check for lines like this:

[0.965016] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[0.966215] nand: Micron MT29F2G08ABBEAH4
[0.972816] nand: 256MiB, SLC, page size: 2048, OOB size: 64

On Mon, Dec 7, 2015 at 4:57 PM, Josh Bendavid  wrote:
> For the WAN link, I did not test it myself yet with 10 or 100mbps, but the
> situation should be the same as described here
> https://dev.openwrt.org/changeset/47695/trunk/target/linux/ipq806x

That was intended as a hint that your dts file did not include the fix
mentioned in the commit, in case it is wired up the same.


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

Re: [OpenWrt-Devel] [PATCH v3] Add support for C-style in dtsi files

[Jonas Gorski]

On 07.12.2015 17:16, Nikolay Martynov wrote:
> Sorry, I've missed those questions. Let me try answering them.
>
> Now also including the list.
>
> 2015-12-07 10:39 GMT-05:00 Jonas Gorski <j...@openwrt.org>:
>> Hi,
>>
>> you still haven't answered my questions:
>>
>> On Mon, Dec 7, 2015 at 4:07 PM, Nikolay Martynov <mar.ko...@gmail.com> wrote:
>>> Current way of compuling dts files involves calling C preprocessor on
>>> main dts file only. This means that dtsi includes cannot have C-style 
>>> includes.
>>
>> Why not? Shouldn't they get processed as well as long as they are
>> included with #include, not /include/? Can you give an example that
>> doesn't work?
>
> You are right and this will work.
> That being said, in my very humble opinion this seems somewhat odd to
> do this not in a way kernel does it. I.e. it is kind of confusing to
> introduce include syntax that is different from one used dts.
> Approach I'm suggesting covers all cases currently used in OpenWrt
> dts files and doesn't force one to use '#include' for dtsi.

Using #include is exactly how the kernel does it, see e.g:

http://lxr.free-electrons.com/source/arch/arm/boot/dts/armada-370.dtsi#L52
http://lxr.free-electrons.com/source/arch/metag/boot/dts/tz1090.dtsi
http://lxr.free-electrons.com/source/arch/mips/boot/dts/ingenic/jz4740.dtsi

(Yes there are examples where /include/ is used, but they are in the
minority and don't use any macros).

>>> This patch addresses this problem. It uses approach similar to one
>>> use in linux kernel: it preprocesses all dtsi's in current dir into
>>> tmp dir and then uses that tmp dir as include dir for main dts compilation.
>>
>> I can't find this code in the kernel at all. Can you please point that out?
> It's in scripts/Makefile.lib, look for cmd_dtc.

That one only produces a list of files the dts includes for Make to
know when to recompile the dts file, but it does not (pre-)process any
of the dependencies.

dtc itself is only invoced once per dts file (unless I'm misreading something).


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

Re: [OpenWrt-Devel] [PATCH] [ipq806x] Add initial support for TP-Link Archer C2600

[Jonas Gorski]

Hi,

On Sat, Dec 5, 2015 at 5:13 AM, Josh Bendavid  wrote:
> From: Josh Bendavid 
>
> Add initial support for Archer C2600 to Makefiles and profiles.  This is
> sufficient to build a working factory image.  Sysupgrade image is not
> implemented yet.  Currently wired network is working, but
> LED's/buttons/wireless are not.
>
> Signed-off-by: Josh Bendavid 
> ---
>
> diff --git a/include/image.mk b/include/image.mk
> index fd5e3f4..9ad2d43 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -327,6 +327,16 @@ define Build/netgear-dni
>   mv $@.new $@
>  endef
>
> +define Build/tplink-safe
> + $(STAGING_DIR_HOST)/bin/tplink-safeloader \
> + -B $(TPLINK_BOARD_ID) -V OpenWrt.$(REVISION) \
> + -k $(word 1,$^) \
> + -r $(word 2,$^) \
> + -j \
> + -o $@.new
> + mv $@.new $@
> +endef
> +
>  define Build/fit
>   $(TOPDIR)/scripts/mkits.sh \
>   -D $(DEVICE_NAME) -o $@.its -k $@ \
> diff --git a/target/linux/ipq806x/image/Makefile
> b/target/linux/ipq806x/image/Makefile
> index 14cf442..8e6a174 100644
> --- a/target/linux/ipq806x/image/Makefile
> +++ b/target/linux/ipq806x/image/Makefile
> @@ -85,6 +85,18 @@ define Device/DniImage
>  endef
>  DEVICE_VARS += KERNEL_SIZE NETGEAR_BOARD_ID NETGEAR_HW_ID DEVICE_BLOCK_SIZE
> DEVICE_PAGE_SIZE
>
> +define Device/TpSafeImage
> + PROFILES += $$(DEVICE_NAME)
> + FILESYSTEMS := squashfs
> + KERNEL_SUFFIX := -uImage
> + KERNEL = kernel-bin | append-dtb | uImage none
> + KERNEL_NAME := zImage
> + TPLINK_BOARD_ID :=
> + IMAGES := factory.bin
> + IMAGE/factory.bin := tplink-safe
> +endef
> +DEVICE_VARS += TPLINK_BOARD_ID
> +
>  define Device/AP148
>   $(call Device/FitImage)
>   $(call Device/UbiFit)
> @@ -103,6 +115,15 @@ define Device/AP148-legacy
>   BOARD_NAME := ap148
>  endef
>
> +define Device/C2600
> + $(call Device/TpSafeImage)
> + DEVICE_DTS := qcom-ipq8064-ap148

The TP-Link doesn't have a eSATA port, so please create its own dts file for it.


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

Re: [OpenWrt-Devel] [PATCH v2] Add support for C-style in dtsi files

[Jonas Gorski]

Hi,

On Fri, Dec 4, 2015 at 12:40 AM, Nikolay Martynov  wrote:
> Current way of compuling dts files involves calling C preprocessor on
> main dts file only. This means that dtsi includes cannot have C-style 
> includes.

Why not? Shouldn't they get processed as well as long as they are
included with #include, not /include/? Can you give an example that
doesn't work?

> This patch addresses this problem. It uses approach similar to one
> use in linux kernel: it preprocesses all dtsi's in current dir into
> tmp dir and then uses that tmp dir as include dir for main dts compilation.

I can't find this code in the kernel at all. Can you please point that out?

> Note: this patch preprocesses onlt *.dtsi, not *.dts, so only *.dtsi
> can be includes, but it looks like all current architectures follow this 
> convention.
>
> This approach should be compatible with all current architectures.
>
> This patch also updates ramips arch to use new dtsi comilation code.
>
> v2: Use LINUX_KARCH to get to linux dh bindings.

This issue was copied from the DTS_DIR decleration, so maybe you can
fix that one up and then use -I$(DTS_DIR) -I$(DTS_DIR)/include ?

>
> Signed-off-by: Nikolay Martynov 
> ---
>  include/image.mk   | 24 ++--
>  target/linux/ramips/image/Makefile |  2 +-
>  2 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/include/image.mk b/include/image.mk
> index fd5e3f4..fa0314f 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -138,19 +138,31 @@ define Image/BuildKernel/MkFIT
>  endef
>
>  # $(1) source dts file
> +# $(2) target dts file
> +# $(3) extra CPP flags
> +define Image/PreprocessDTS
> +   $(CPP) -nostdinc -x assembler-with-cpp \
> +   -I$(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts \
> +   -I$(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts/include \
> +   -undef -D__DTS__ $(3) \
> +   -o $(2) $(1);
> +endef
> +
> +
> +# $(1) source dts file
>  # $(2) target dtb file
>  # $(3) extra CPP flags
>  # $(4) extra DTC flags
>  define Image/BuildDTB
> -   $(CPP) -nostdinc -x assembler-with-cpp \
> -   -I$(LINUX_DIR)/arch/$(ARCH)/boot/dts \
> -   -I$(LINUX_DIR)/arch/$(ARCH)/boot/dts/include \
> -   -undef -D__DTS__ $(3) \
> -   -o $(2).tmp $(1)
> +   mkdir -p $(2).inc.tmp
> +   $(foreach inc,$(wildcard $(dir $(1))*.dtsi), \
> +   $(call Image/PreprocessDTS,$(inc),$(2).inc.tmp/$(notdir 
> $(inc)),$(3)))

If I read this right you preprocess all dtsi files found there every
time you want to compile a dts file. This sounds like a lot of
unnecessary processing on e.g. arm, where arch/arm/boot/dts contains
435 .dtsi files as of 4.1. And since you remove the preprocessed
files, you need to do it again for the next dts file.


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

Re: [OpenWrt-Devel] [PATCH v2] brcm63xx: Add NuCom R5010UNv2 support

[Jonas Gorski]

Hi,

On Mon, Nov 30, 2015 at 10:50 PM, dani  wrote:
> This patch adds support for the NuCom R5010UNv2.
>
> It's a BCM6328 based board. It has an onboard BCM43217 wifi chip. For this
> wifi chip looks like the brcmsmac driver isn't still supported, b43 drivers 
> are used
> for the profile of the router.
>
> It's worth mentioning this board was affected by a bug solved with
> https://dev.openwrt.org/changeset/46707
>
> Tested-by: Angel Fontan 
> Signed-off-by: Daniel Gonzalez 

What's the difference to v1? Please include a changelog like in
https://patchwork.ozlabs.org/patch/549851/ (under the tear-off line
("--"), so it doesn't land in the actual commit).


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

Re: [OpenWrt-Devel] [PATCH v2] brcm63xx: Add NuCom R5010UNv2 support

[Jonas Gorski]

Hi,

On Tue, Dec 1, 2015 at 11:40 AM, dani  wrote:
> This patch adds support for the NuCom R5010UNv2.
>
> It's a BCM6328 based board. It has an onboard BCM43217 wifi chip. For this
> wifi chip looks like the brcmsmac driver isn't still supported, b43 drivers 
> are used
> for the profile of the router.
>
> It's worth mentioning this board was affected by a bug solved with
> https://dev.openwrt.org/changeset/46707
>
> Tested-by: Angel Fontan 
> Signed-off-by: Daniel Gonzalez 
> ---
> change in v2:
> usb led trigger was wrong
> added 8 MB padding to the image generator because its CFE has double image 
> protection
> added colors naming to the leds in dts file to meet the same layout of other 
> boards
> ---
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index 7826fad..c0fb31e 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -102,6 +102,9 @@ set_state() {
> p870hw-51a_v2)
> status_led="P870HW-51a:green:power"
> ;;
> +   r5010un_v2)
> +   status_led="96328ang:green:power"
> +   ;;
> rta770bw)
> status_led="RTA770BW:green:diag"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds 
> b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
> index bdb3dad..34d5c51 100644
> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
> @@ -46,6 +46,9 @@ homehub2a)
> ucidef_set_led_usbdev "usb1" "USB1" "HOMEHUB2A:blue:phone" "1-1"
> ucidef_set_led_usbdev "usb2" "USB2" "HOMEHUB2A:green:phone" "2-1"
> ;;
> +r5010un_v2)
> +   ucidef_set_led_usbdev "usb" "USB" "96328ang:green:usb" "1-1"
> +   ;;
>  esac
>
>  ucidef_commit_leds
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network 
> b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
> index 129514b..70f18cb 100644
> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
> @@ -94,6 +94,7 @@ fast2504n |\
>  fast2704v2 |\
>  hg655b |\
>  p870hw-51a_v2 |\
> +r5010un_v2 |\
>  vr-3025un |\
>  vr-3025u |\
>  vr-3026e)
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 
> b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> index f307a4c..bc9ae21 100644
> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> @@ -23,6 +23,7 @@ case "$(brcm63xx_board_name)" in
> dsl-274xb-f |\
> magic |\
> p870hw-51a_v2 |\
> +   r5010un_v2 |\
> rta770bw |\
> rta770w |\
> spw303v |\
> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh 
> b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> index 1a97c86..7dc57fd 100755
> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> @@ -180,6 +180,9 @@ brcm63xx_dt_detect() {
> "Netgear DGND3700v1/DGND3800B")
> board_name="dgnd3700v1_dgnd3800b"
> ;;
> +   "NuCom R5010UN v2")
> +   board_name="r5010un_v2"
> +   ;;
> "Pirelli A226G")
> board_name="a226g"
> ;;
> diff --git a/target/linux/brcm63xx/dts/r5010unv2.dts 
> b/target/linux/brcm63xx/dts/r5010unv2.dts
> new file mode 100644
> index 000..8c83483
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/r5010unv2.dts
> @@ -0,0 +1,64 @@
> +/dts-v1/;
> +
> +#include "bcm6328.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "NuCom R5010UN v2";
> +   compatible = "nucom,r5010unv2", "brcm,bcm6328";
> +
> +   gpio-keys-polled {
> +   compatible = "gpio-keys-polled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   poll-interval = <20>;
> +   debounce-interval = <60>;
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 23 1>;
> +   linux,code = ;
> +   };
> +   wps {
> +   label = "wps";
> +   gpios = < 24 1>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +
> +   inet_green {
> +   label = "96328ang:green:inet";

Please use the device name, not the boardid.

> +   gpios = < 1 1>;
> +   };
> +   inet_fail_red {
> +   label = "96328ang:red:inet-fail";
> +   gpios = < 2 1>;
> +   };
> + 

Re: [OpenWrt-Devel] [PATCH] include/image.mk: Add dtb-install build function

[Jonas Gorski]

Hi,

On Tue, Dec 1, 2015 at 11:43 AM, Petr Štetiar  wrote:
> Signed-off-by: Petr Štetiar 

Please try to avoid empty commit logs.

Also you don't add any users of this, so why should need this?


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

Re: [OpenWrt-Devel] ath9k-htc init

[Jonas Gorski]

On Thu, Nov 26, 2015 at 2:07 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Jonas,
>
> On Mon, 2015-11-23 at 16:48 +0100, Jonas Gorski wrote:
>> On Mon, Nov 23, 2015 at 9:21 AM, Alexey Brodkin
>> <alexey.brod...@synopsys.com> wrote:
>> > Hi Felix, Jonas,
>> >
>> > While playing with my AXS101 board and USB WI-Fi dongles I bumped in
>> > a couple of issues. Fortunately I found at least one dongle that
>> > works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
>> > which is based on Atheros AR9271 chip even though it did require
>> > one unexpected tweak.
>> >
>> > For starters I just selected "kmod-ath9k-htc" in menuconfig and
>> > on boot saw USB device recognized, its firmware was loaded,
>> > "wifi detect" recognized it as well, see log below.
>> >
>> > But then "wlan0" interface was not created on "wifi" command.
>> >
>> > After some googling I somehow came to resolution that "hostapd"
>> > package installation fixes this problem. And indeed once I got
>> > image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
>> > and I was able to use my board as a Wi-Fi access point.
>> >
>> > So the question is if this is expected (requirement for "hostapd")
>> > [for "ath9k_htc"]?
>>
>> Yes, hostapd[-mini] (or wpad[-mini]) is required for AP mode, and
>> wpasupplicant or wpad for encrypted STA mode.
>
> Ooops I didn't realize that right away, indeed I'm trying to setup WiFi
> AP and hostAPD (which is really just "host AP Daemon") or alike is a must.
>
> The next question would be which option should I use then?
>  1) good olde HostAPD
>  2) its -mini sibling
>  3) wpad
>  4) its -mini sibling

OpenWrt default is wpad-mini for wifi capable devices (which is just a
unified binary of hostapd and wpasupplicant to prevent code
duplication and save space). The non-mini versions add support for
enterprisey stuff like radius athentication, which aren't needed for
most home setups.


>> > Another minor issue is that USB dongle gets recognized a bit late
>> > so that automatic "wifi detect" gets already executed and
>> > "/etc/config/wireless" isn't created. That requires manual execution of
>> > "wifi detect > /etc/config/wireless". Essentially extending delay in
>> > "package/base-files/files/etc/init.d/boot" makes a difference:
>> > -->8---
>> > # allow wifi modules time to settle
>> > sleep 15 # instead of 1
>> > -->8---
>> > but I'm not sure if we want to do that change for all devices.
>> > Then if there's a better way to make auto population of
>> > "/etc/config/wireless"?
>>
>> Likely the firmware is loaded asynchronously, so the _probe function
>> returns quickly. Our workaround in OpenWrt  for other drivers is to
>> make the _probe function wait for the firmware to have loaded. and
>> thus the wifi device registered in the linux kernel. This will ensure
>> the wifi subsystem knows about it when wifi detect is called. This
>> seems to be missing for ath9k-htc.
>
> May I get a reference to an example of that workaround?

see

package/kernel/mac80211/patches/861-brcmfmac-register-wiphy-s-during-module_init.patch
package/kernel/mac80211/patches/921-ath10k_init_devices_synchronously.patch
package/kernel/mac80211/patches/940-mwl8k_init_devices_synchronously.patch


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

Re: [OpenWrt-Devel] [PATCH V2] oxnas: set irq of usb to cpu1

[Jonas Gorski]

On Mon, Nov 23, 2015 at 8:43 AM, Shonn Lu  wrote:
>Subject: oxnas: set irq of usb to cpu1

Why? Please explain why this is needed/wanted.


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

Re: [OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

[Jonas Gorski]

On Mon, Nov 23, 2015 at 9:28 AM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> ARC SDP board sports only 1 network interface - eth0,
> so to operate as an access point it requires at least
> another interface (preferably wireless),
> so USB Wi-Fi dongle is what we want.
>
> And with USB Wi-Fi dongle attached ARC SDP board could be
> used as a "dumb" wireless access point.
>
> Now with modified network setup script it is only required
> to enable wireless radio on the first boot with
> -->8
> uci set wireless.radio0.disabled=0
> uci commit wireless
> wifi
> -->8
>
> Note if by the time initscripts are executed USB Wi-Fi
> dongle not yet recognized and set up by Linux kernel
> its autodetection by "wifi" tool may not happen
> automatically. In that case before issuing command above
> one needs to populate /etc/config/wireless config:
> -->8
> wifi detect > /etc/config/wireless
> -->8
>
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Felix Fietkau <n...@openwrt.org>
> Cc: Jo-Philipp Wich <j...@openwrt.org>
> Cc: Jonas Gorski <j...@openwrt.org>
> ---
>  target/linux/arc770/base-files/etc/uci-defaults/02_network | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network 
> b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> index 87cfe81..7503f85 100644
> --- a/target/linux/arc770/base-files/etc/uci-defaults/02_network
> +++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> @@ -14,7 +14,17 @@ ucidef_set_interface_loopback
>
>  case "$( arc_board_name )" in
>  "arc-sdp"*)
> -   ucidef_set_interface_raw "lan" "eth0" "dhcp"

Keep this line instead

> +   uci set network.lan.type='bridge'

And only add this line.

> +   uci set network.lan.ifname='eth0 wlan0'

This is unneeded, as netifd will automatically join the wifi interface
to the bridge in the default config (with the option network 'lan'
line in /etc/config/wireless).

> +   # With multicast-to-unicast enabled kernel crashes
> +   # on the first wireless client connection in
> +   # br_multicast_add_group() -> br_port_group_equal() ->
> +   # ether_addr_equal() due to misaligned read.
> +   # For some reason "src" being "eth_hdr(skb)->h_source"
> +   # is not 16-bit aligned as it is supposed to be.
> +   uci set network.lan.multicast_to_unicast='0'

And this doesn't belong here at all, this is a complete separate issue
and should be fixed where it occurs, not worked around (sounds like an
issue in the ath9k-htc driver). Does ARC not provide emulation of
unaligned accesses like mips does?


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

Re: [OpenWrt-Devel] ath9k-htc init

[Jonas Gorski]

On Mon, Nov 23, 2015 at 9:21 AM, Alexey Brodkin
 wrote:
> Hi Felix, Jonas,
>
> While playing with my AXS101 board and USB WI-Fi dongles I bumped in
> a couple of issues. Fortunately I found at least one dongle that
> works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
> which is based on Atheros AR9271 chip even though it did require
> one unexpected tweak.
>
> For starters I just selected "kmod-ath9k-htc" in menuconfig and
> on boot saw USB device recognized, its firmware was loaded,
> "wifi detect" recognized it as well, see log below.
>
> But then "wlan0" interface was not created on "wifi" command.
>
> After some googling I somehow came to resolution that "hostapd"
> package installation fixes this problem. And indeed once I got
> image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
> and I was able to use my board as a Wi-Fi access point.
>
> So the question is if this is expected (requirement for "hostapd")
> [for "ath9k_htc"]?

Yes, hostapd[-mini] (or wpad[-mini]) is required for AP mode, and
wpasupplicant or wpad for encrypted STA mode.


> Another minor issue is that USB dongle gets recognized a bit late
> so that automatic "wifi detect" gets already executed and
> "/etc/config/wireless" isn't created. That requires manual execution of
> "wifi detect > /etc/config/wireless". Essentially extending delay in
> "package/base-files/files/etc/init.d/boot" makes a difference:
> -->8---
> # allow wifi modules time to settle
> sleep 15 # instead of 1
> -->8---
> but I'm not sure if we want to do that change for all devices.
> Then if there's a better way to make auto population of
> "/etc/config/wireless"?

Likely the firmware is loaded asynchronously, so the _probe function
returns quickly. Our workaround in OpenWrt  for other drivers is to
make the _probe function wait for the firmware to have loaded. and
thus the wifi device registered in the linux kernel. This will ensure
the wifi subsystem knows about it when wifi detect is called. This
seems to be missing for ath9k-htc.


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

Re: [OpenWrt-Devel] [PATCH v2 1/2] pinctrl/lantiq: split xway_mfp into dedicated tables

[Jonas Gorski]

On Mon, Nov 16, 2015 at 2:55 PM, Martin Schiller <mschil...@tdt.de> wrote:
> On Mon, Nov 16, 2015 at 2:06 PM, Jonas Gorski <j...@openwrt.org>
> wrote:
>> On Mon, Nov 16, 2015 at 12:01 PM, Martin Schiller <mschil...@tdt.de>
>> wrote:
>> > This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9"
>> > settings into dedicated "pinctrl-ase", "pinctrl-danube",
>> > "pinctrl-xrx100" and "pinctrl-xrx200" configuration tables.
>> >
>> > Based on the newest Lantiq Hardware Description it turend out, that
>> > there are some differences in the GPIO alternative functions of the
>> > Danube, xRX100 and xRX200 families, which makes it impossible to use
>> only one xway_mfp table.
>> >
>> > This patch is also the first step to add support for the xRX300
>> family.
>> >
>> > Signed-off-by: Martin Schiller <mschil...@tdt.de>
>> > ---
>> >  .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1059
>> +++-
>> >  .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059
>> +++-
>> >  2 files changed, 2098 insertions(+), 20 deletions(-)
>> >
>> > diff --git
>> > a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
>> > b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
>> > index 84adbe6..3fc0432 100644
>> > --- a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
>> > +++ b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
>> > @@ -1,15 +1,1054 @@
>> >  --- a/drivers/pinctrl/pinctrl-xway.c
>> >  +++ b/drivers/pinctrl/pinctrl-xway.c
>>
>> (snip)
>>
>> > +@@ -769,9 +1153,10 @@ static struct pinctrl_gpio_range xway_gp  };
>> > +
>> > + static const struct of_device_id xway_match[] = {
>> > +-  { .compatible = "lantiq,pinctrl-xway", .data = _cfg[0]},
>> > +-  { .compatible = "lantiq,pinctrl-xr9", .data = _cfg[1]},
>> > +-  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[2]},
>> > ++  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[0]},
>> > ++  { .compatible = "lantiq,pinctrl-danube", .data =
>> _cfg[1]},
>> > ++  { .compatible = "lantiq,pinctrl-xrx100", .data =
>> _cfg[2]},
>> > ++  { .compatible = "lantiq,pinctrl-xrx200", .data =
>> _cfg[3]},
>>
>> Unfortunately that ship has sailed, and "lantiq,pinctrl-xway" etc are
>> the Documented bindings for it in upstream linux; you can't just drop
>> support for the older bindings. At least you will never get this
>> accepted upstream. Also if you update bindings, you need to update the
>> documentation in Documentation/devicetree/bindings as well.
>
> OK, you are right. We also need to patch the bindings and the Documentation.
>
> "that ship has sailed": Do you mean, it's impossible to bring this changes 
> upstream?
>
> Or would it be a solution to let the pinctrl-xway and pinctrl-xr9 in the code 
> and mark it as deprecated somehow?

Device tree blobs using the old bindings must still work with newer
kernels. So adding support for new bindings and deprecating the old
ones is possible, but you can't drop support for them.


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

Re: [OpenWrt-Devel] [PATCH v2 1/2] pinctrl/lantiq: split xway_mfp into dedicated tables

[Jonas Gorski]

Hi,

On Mon, Nov 16, 2015 at 12:01 PM, Martin Schiller  wrote:
> This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9" settings
> into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100" and
> "pinctrl-xrx200" configuration tables.
>
> Based on the newest Lantiq Hardware Description it turend out, that there are
> some differences in the GPIO alternative functions of the Danube, xRX100 and
> xRX200 families, which makes it impossible to use only one xway_mfp table.
>
> This patch is also the first step to add support for the xRX300 family.
>
> Signed-off-by: Martin Schiller 
> ---
>  .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1059 
> +++-
>  .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059 
> +++-
>  2 files changed, 2098 insertions(+), 20 deletions(-)
>
> diff --git a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch 
> b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> index 84adbe6..3fc0432 100644
> --- a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> +++ b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> @@ -1,15 +1,1054 @@
>  --- a/drivers/pinctrl/pinctrl-xway.c
>  +++ b/drivers/pinctrl/pinctrl-xway.c

(snip)

> +@@ -769,9 +1153,10 @@ static struct pinctrl_gpio_range xway_gp
> + };
> +
> + static const struct of_device_id xway_match[] = {
> +-  { .compatible = "lantiq,pinctrl-xway", .data = _cfg[0]},
> +-  { .compatible = "lantiq,pinctrl-xr9", .data = _cfg[1]},
> +-  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[2]},
> ++  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[0]},
> ++  { .compatible = "lantiq,pinctrl-danube", .data = _cfg[1]},
> ++  { .compatible = "lantiq,pinctrl-xrx100", .data = _cfg[2]},
> ++  { .compatible = "lantiq,pinctrl-xrx200", .data = _cfg[3]},

Unfortunately that ship has sailed, and "lantiq,pinctrl-xway" etc are
the Documented bindings for it in upstream linux; you can't just drop
support for the older bindings. At least you will never get this
accepted upstream. Also if you update bindings, you need to update the
documentation in Documentation/devicetree/bindings as well.


> +   {},
> + };
> + MODULE_DEVICE_TABLE(of, xway_match);


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

Re: [OpenWrt-Devel] [PATCH 2/2 v4] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

Hi Alexey,

On Tue, Nov 10, 2015 at 5:40 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Jonas,
>
> On Tue, 2015-11-10 at 12:02 +0100, Jonas Gorski wrote:
>> Hi Alexey,
>>
>> On Sat, Nov 7, 2015 at 2:25 PM, Alexey Brodkin
>> <alexey.brod...@synopsys.com> wrote:
>> > This patch introduces support of new boards with ARC cores.
>> (snip)
>>
>> > diff --git a/target/linux/arc770/base-files/lib/arc.sh 
>> > b/target/linux/arc770/base-files/lib/arc.sh
>> > new file mode 100644
>> > index 000..17ce657
>> > --- /dev/null
>> > +++ b/target/linux/arc770/base-files/lib/arc.sh
>> > @@ -0,0 +1,49 @@
>> > +#!/bin/sh
>> > +#
>> > +# Copyright (C) 2015 OpenWrt.org
>> > +#
>> > +
>> > +# defaults
>> > +ARC_BOARD_NAME="generic"
>> > +ARC_BOARD_MODEL="Generic ARC board"
>> > +
>> > +arc_board_detect() {
>> > +   local board
>> > +   local model
>> > +
>> > +   [ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"
>> > +
>> > +   model="$( cat /proc/device-tree/model )"
>> > +
>> > +   # Extract just one "compatible" value out of 
>> > "snps,axs101snps,arc-sdp"
>> > +   # which is a concatenation of "snps,axs101" and "snps,arc-sdp".
>> > +   if cat /proc/device-tree/compatible | grep -q "snps,arc-sdp"; then
>> > +   board="arc-sdp";
>> > +   fi
>> > +
>> > +   if cat /proc/device-tree/compatible | grep -q "snps,nsim"; then
>> > +   board="nsim";
>> > +   fi
>>
>> I guess I wasn't clear enough, the idea of using the model property is
>> so that you can then just do
>>
>> case "$model" in
>> "Synopsys AXS101 Development Board";)
>> board="arc-sdp";
>> ;;
>> "Synopsys ARC770 nSIM simulator")
>> board="nsim";
>> ;;
>> esac
>
> Well my implementation was intentional.
> See we have 2 flavors of ARC SDP board: AXS101 and AXS103.
> They have the same base-board (where all peripherals really reside)
> and different CPU-cards: AXS101 sports CPU-card with ARC770-based ASIC;
> AXS103 sports CPU-card with ARC HS38 in FPGA.
>
> So I wanted to detect existence of ARC SDP base-board and then set
> say network interfaces according to available devices.
>
> And difference in CPU type is not important here because it has
> no impact on the board behavior.
>
> Makes any sense?

I see what you want, but the way you are doing it is quite error prone
and inefficient. If you insist on using the compatible, i suggest:

1. Extract the first one instead of grepping through the full
compatible set, so you don't need to invoke grep for each comparison
(also dropping the misuse of cat ;p).
2. Do a full string comparison instead of grep, else you will have a
hard time telling apart "foo,bar" and "foo,bar-variant".

So then it would be

compatible = /* magic */;

case "$compatible" in
"snps,arc-sdp")
board="arc-sdp";
;;
"snps,nsim")
board="arc-nsim";
;;
esac


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

Re: [OpenWrt-Devel] [PATCH 2/2 v4] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

On Wed, Nov 11, 2015 at 1:38 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Jonas,
>
> On Wed, 2015-11-11 at 12:19 +0100, Jonas Gorski wrote:
>> Hi Alexey,
>>
>> On Tue, Nov 10, 2015 at 5:40 PM, Alexey Brodkin
>> <alexey.brod...@synopsys.com> wrote:
>> > Hi Jonas,
>> >
>> > On Tue, 2015-11-10 at 12:02 +0100, Jonas Gorski wrote:
>
>> > > Hi Alexey,
>> I see what you want, but the way you are doing it is quite error prone
>> and inefficient. If you insist on using the compatible, i suggest:
>>
>> 1. Extract the first one instead of grepping through the full
>> compatible set, so you don't need to invoke grep for each comparison
>> (also dropping the misuse of cat ;p).
>
> The problem is how multientry compatible string is presented in /proc fs:
> >8
> $ cat /proc/device-tree/compatible
> snps,axs101snps,arc-sdp
> >8
>
> You see there's no delimiter between "snps,axs101" and "snps,arc-sdp".
> So how should I extract "snps,arc-sdp" from /proc/device-tree/compatible?

Well, you want to use it, you figure it out ;p.

This is mostly a display issue. If you look at the actual data with
e.g. hexdump:

62 72 63 6d 2c 62 63 6d  39 36 33 32 38 61 76 6e  |brcm,bcm96328avn|
67 00 62 72 63 6d 2c 62  63 6d 36 33 32 38 00 |g.brcm,bcm6328.|

you will see that these are two properly null-terminated strings. It's
just that printing to stdout swallows the terminators, but anything
working with the data should properly see them as two distinct values.


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

Re: [OpenWrt-Devel] [PATCH 2/2 v4] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

Hi Alexey,

On Sat, Nov 7, 2015 at 2:25 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> This patch introduces support of new boards with ARC cores.
>
>  [1] Synopsys SDP board
>  This is a new-generation development board from Synopsys that
>  consists of base-board and CPU tile-board (which might have a real
>  ASIC or FPGA with CPU image).
>  It sports a lot of DesignWare peripherals like GMAC, USB, SPI, I2C
>  etc and is intended to be used for early development of ARC-based
>  products.
>
>  [2] nSIM
>  This is a virtual board implemented in Synopsys proprietary
>  software simulator (even though available for free for open source
>  community). This board has only serial port as a peripheral and so
>  it is meant to be used for runtime testing which is especially
>  useful during bring-up of new tools and platforms.
>  What's also important ARC cores are very configurable so there're
>  many variations of options like cache sizes, their line lengths,
>  additional hardware blocks like multipliers, dividers etc. And this
>  board could be used to make sure built software still runs on
>  different HW configurations.
>
> Cc: Felix Fietkau <n...@openwrt.org>
> Cc: Jo-Philipp Wich <j...@openwrt.org>
> Cc: Jonas Gorski <j...@openwrt.org>
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> ---
>
> Changes compared to v3:
>  * Accomodate new KERNEL_INITRAMFS_NAME variable for building .elfs
>  * Add and use "model" property in device tree description
>  * Remove extra console from kernel command line
>  * Use new buildsystem for resulting images
>  * Nuked ARC-specific inittab, use default one instead
>  * Linux kernel config is passed through "make kernel_oldconfig"
>  * eth0 is now LAN instead of WAN
>
> Changes compared to v2:
>  * Fixed copyright dates
>  * Cleaned-up init scripts
>
> Changes compared to v1:
>  * Switched to SoC-centered design. Now instead of common ARC700
>support we claim support of boards based on ARC770D.
>This allows to use the same one build of kernel binary for both
>boards.
>
>  * Implemented run-time scripts that parse Device Tree compatible
>tag and according to it do configuration of serial port and network.
>
>  * Implemented ability to patch in built Linux kernel external .dtb
>
>  * Linux kernel switched from 4.1 to 4.3
>
>  * Rebased on current master
>
>  include/kernel.mk  |   2 +
>  target/linux/arc770/Makefile   |  26 +++
>  target/linux/arc770/base-files.mk  |   3 +
>  .../arc770/base-files/etc/uci-defaults/02_network  |  23 +++
>  target/linux/arc770/base-files/lib/arc.sh  |  49 +
>  .../base-files/lib/preinit/01_preinit_arc.sh   |   9 +
>  target/linux/arc770/config-4.3 | 179 
>  target/linux/arc770/dts/axc001.dtsi| 100 +
>  target/linux/arc770/dts/axs101.dts |  22 ++
>  target/linux/arc770/dts/axs10x_mb.dtsi | 224 
> +
>  target/linux/arc770/dts/nsim_700.dts   |  71 +++
>  target/linux/arc770/dts/skeleton.dtsi  |  37 
>  target/linux/arc770/generic/profiles/00-default.mk |  16 ++
>  target/linux/arc770/generic/profiles/01-minimal.mk |  15 ++
>  target/linux/arc770/generic/profiles/02-axs101.mk  |  17 ++
>  .../linux/arc770/generic/profiles/03-nsim_700.mk   |  16 ++
>  target/linux/arc770/generic/target.mk  |   8 +
>  target/linux/arc770/image/Makefile |  40 
>  ...openwrt-arc-remove-dependency-on-DEVTMPFS.patch |  36 
>  .../0002-openwrt-arc-add-OWRTDTB-section.patch |  91 +
>  20 files changed, 984 insertions(+)
>  create mode 100644 target/linux/arc770/Makefile
>  create mode 100644 target/linux/arc770/base-files.mk
>  create mode 100644 target/linux/arc770/base-files/etc/uci-defaults/02_network
>  create mode 100644 target/linux/arc770/base-files/lib/arc.sh
>  create mode 100644 
> target/linux/arc770/base-files/lib/preinit/01_preinit_arc.sh
>  create mode 100644 target/linux/arc770/config-4.3
>  create mode 100644 target/linux/arc770/dts/axc001.dtsi
>  create mode 100644 target/linux/arc770/dts/axs101.dts
>  create mode 100644 target/linux/arc770/dts/axs10x_mb.dtsi
>  create mode 100644 target/linux/arc770/dts/nsim_700.dts
>  create mode 100644 target/linux/arc770/dts/skeleton.dtsi
>  create mode 100644 target/linux/arc770/generic/profiles/00-default.mk
>  create mode 100644 target/linux/arc770/generic/profiles/01-minimal.mk
>  create mode 100644 target/linux/arc770/g

Re: [OpenWrt-Devel] [PATCH 2/2 v3] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

Hi Alexey,

On Thu, Nov 5, 2015 at 8:39 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Jonas,
>
> On Thu, 2015-11-05 at 20:04 +0100, Jonas Gorski wrote:
>> Hi Alexey,
>>
>> On Thu, Nov 5, 2015 at 7:14 PM, Alexey Brodkin
>> <alexey.brod...@synopsys.com> wrote:
>> > Hi Jonas,
>> >
>> > On Wed, 2015-11-04 at 20:22 +0300, Alexey Brodkin wrote:
>> > > Hi Jonas,
>> > >
>> > > On Wed, 2015-11-04 at 13:06 +0100, Jonas Gorski wrote:
>> > > > Hi,
>> > > >
>> > > > On Tue, Nov 3, 2015 at 12:27 AM, Alexey Brodkin
>> > > > <alexey.brod...@synopsys.com> wrote:
>> > > > > +   ;;
>> > > > > +esac
>> > > > > +
>> > > > > +uci commit network
>> > > > > +
>> > > > > +exit 0
>> > > > > diff --git a/target/linux/arc770/base-files/lib/arc.sh 
>> > > > > b/target/linux/arc770/base-files/lib/arc.sh
>> > > > > new file mode 100644
>> > > > > index 000..b15e94b
>> > > > > --- /dev/null
>> > > > > +++ b/target/linux/arc770/base-files/lib/arc.sh
>> > > > > @@ -0,0 +1,76 @@
>> > > > > +#!/bin/sh
>> > > > > +#
>> > > > > +# Copyright (C) 2015 OpenWrt.org
>> > > > > +#
>> > > > > +
>> > > > > +# defaults
>> > > > > +ARC_BOARD_NAME="generic"
>> > > > > +ARC_BOARD_MODEL="Generic arc board"
>> > > > > +
>> > > > > +arc_board_detect() {
>> > > > > +   local board
>> > > > > +   local model
>> > > > > +
>> > > > > +   [ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"
>> > > > > +
>> > > > > +   model="$( cat /proc/device-tree/compatible )"
>> > > > > +
>> > > > > +   # We cannot just use "model" as it is because in case of SDP 
>> > > > > board
>> > > >
>> > > > ePAPR says your dts root nodes must have a "model" property that
>> > > > uniquely identifies the board. I see that is currently missing even in
>> > > > upstream, so please fix your dts files. Then you won't need to grep in
>> > > > the compatible. On a side node, ePAPR also says that the recommended
>> > > > format is the same as compatible but .. *looks at arm* .. apparently
>> > > > nobody does that.
>> > >
>> > > Indeed "model" is a required property.
>> > > So thanks for that suggestion.
>> > >
>> > > Then we'll have:
>> > > >8--
>> > > compatible = "snps,arc-sdp";
>> > > model = "snps,axs101";
>>
>> Grepping through the different arch's dts directories, some arches use
>> compatible like model values (e.g. powerpc), some use free text values
>> (e.g. arm). Might be something discuss worthy for devicetree ML how
>> this spec "violation" should be handled. Especially since the example
>> in Documentation/devicetree/usage-model.txt doesn't have one.
>>
>> > > >8--
>> > > which looks for sure much better!
>> > >
>> > > Will do this for starters here in OpenWRT and will submit a patch 
>> > > upstream
>> > > in Linux kernel.
>> >
>> > I started to think about it and now I understand why we use complicated
>> > "compatible" value.
>> >
>> > This allows us to use multiple platform-specific parts at once.
>> > We use "snps,arc-sdp" here:
>> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/kernel/devtree.c#n35
>> > and "snps,axs101" here:
>> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-axs10x/axs10x.c#n464
>> >
>> > In the first case it's not really necessary to use "compatible" node but
>> > it's usage is quite convenient, see we only need to execute this oneliner:
>> > >8--
>> > of_flat_dt_is_compatible(dt_root, "snps,arc-sdp")
>> > >8--
>> >
>> > But if we use "model" node instead we'll need to do:
>> > 1) of_get_property
>> > 2) strcmp
>> >
>> > This is a bit longer, still possible solution.
>> >
>> > So even though your proposal is very useful and I'm going to discuss it
>> > with Vineet Gupta (ARC Linux maintainer) but if you don't mind I'd go
>> > without that change for this submission. Then if your proposal is 
>> > implemented
>> > I'll need to rework OpenWRT scripts anyways because newer upstream kernel
>> > will require that.
>> >
>> > Are you OK with that?
>>
>> My suggestion was only for the model detection script part, not to
>> modify anything in the kernel (apart from adding a model property to
>> the dts files). The kernel should just keep using the compatible
>> property as it properly handles multiple compatible names etc, and it
>> doesn't need to be unique.
>
> So should I just add "model" property in .dts files in OpenWRT and correct
> init scripts? This all without patching kernel itself essentially.

Yes, that is my suggestion. Just add a new model property without
touching any of the other ones.


Jonas

P.S: It's "OpenWrt", not "OpenWRT" ;p
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2 v3] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

Hi Alexey,

On Thu, Nov 5, 2015 at 7:14 PM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Jonas,
>
> On Wed, 2015-11-04 at 20:22 +0300, Alexey Brodkin wrote:
>> Hi Jonas,
>>
>> On Wed, 2015-11-04 at 13:06 +0100, Jonas Gorski wrote:
>> > Hi,
>> >
>> > On Tue, Nov 3, 2015 at 12:27 AM, Alexey Brodkin
>> > <alexey.brod...@synopsys.com> wrote:
>> > > +   ;;
>> > > +esac
>> > > +
>> > > +uci commit network
>> > > +
>> > > +exit 0
>> > > diff --git a/target/linux/arc770/base-files/lib/arc.sh 
>> > > b/target/linux/arc770/base-files/lib/arc.sh
>> > > new file mode 100644
>> > > index 000..b15e94b
>> > > --- /dev/null
>> > > +++ b/target/linux/arc770/base-files/lib/arc.sh
>> > > @@ -0,0 +1,76 @@
>> > > +#!/bin/sh
>> > > +#
>> > > +# Copyright (C) 2015 OpenWrt.org
>> > > +#
>> > > +
>> > > +# defaults
>> > > +ARC_BOARD_NAME="generic"
>> > > +ARC_BOARD_MODEL="Generic arc board"
>> > > +
>> > > +arc_board_detect() {
>> > > +   local board
>> > > +   local model
>> > > +
>> > > +   [ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"
>> > > +
>> > > +   model="$( cat /proc/device-tree/compatible )"
>> > > +
>> > > +   # We cannot just use "model" as it is because in case of SDP 
>> > > board
>> >
>> > ePAPR says your dts root nodes must have a "model" property that
>> > uniquely identifies the board. I see that is currently missing even in
>> > upstream, so please fix your dts files. Then you won't need to grep in
>> > the compatible. On a side node, ePAPR also says that the recommended
>> > format is the same as compatible but .. *looks at arm* .. apparently
>> > nobody does that.
>>
>> Indeed "model" is a required property.
>> So thanks for that suggestion.
>>
>> Then we'll have:
>> >8--
>> compatible = "snps,arc-sdp";
>> model = "snps,axs101";

Grepping through the different arch's dts directories, some arches use
compatible like model values (e.g. powerpc), some use free text values
(e.g. arm). Might be something discuss worthy for devicetree ML how
this spec "violation" should be handled. Especially since the example
in Documentation/devicetree/usage-model.txt doesn't have one.

>> >8--
>> which looks for sure much better!
>>
>> Will do this for starters here in OpenWRT and will submit a patch upstream
>> in Linux kernel.
>
> I started to think about it and now I understand why we use complicated
> "compatible" value.
>
> This allows us to use multiple platform-specific parts at once.
> We use "snps,arc-sdp" here:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/kernel/devtree.c#n35
> and "snps,axs101" here:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-axs10x/axs10x.c#n464
>
> In the first case it's not really necessary to use "compatible" node but
> it's usage is quite convenient, see we only need to execute this oneliner:
> >8--
> of_flat_dt_is_compatible(dt_root, "snps,arc-sdp")
> >8--
>
> But if we use "model" node instead we'll need to do:
> 1) of_get_property
> 2) strcmp
>
> This is a bit longer, still possible solution.
>
> So even though your proposal is very useful and I'm going to discuss it
> with Vineet Gupta (ARC Linux maintainer) but if you don't mind I'd go
> without that change for this submission. Then if your proposal is implemented
> I'll need to rework OpenWRT scripts anyways because newer upstream kernel
> will require that.
>
> Are you OK with that?

My suggestion was only for the model detection script part, not to
modify anything in the kernel (apart from adding a model property to
the dts files). The kernel should just keep using the compatible
property as it properly handles multiple compatible names etc, and it
doesn't need to be unique.


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

Re: [OpenWrt-Devel] [PATCH 2/2 v3] linux: add support of Synopsys ARC770-based boards

[Jonas Gorski]

Hi,

On Tue, Nov 3, 2015 at 12:27 AM, Alexey Brodkin
 wrote:
> This patch introduces support of new boards with ARC cores.
>
>  [1] Synopsys SDP board
>  This is a new-generation development board from Synopsys that
>  consists of base-board and CPU tile-board (which might have a real
>  ASIC or FPGA with CPU image).
>  It sports a lot of DesignWare peripherals like GMAC, USB, SPI, I2C
>  etc and is intended to be used for early development of ARC-based
>  products.
>
>  [2] nSIM
>  This is a virtual board implemented in Synopsys proprietary
>  software simulator (even though available for free for open source
>  community). This board has only serial port as a peripheral and so
>  it is meant to be used for runtime testing which is especially
>  useful during bring-up of new tools and platforms.
>  What's also important ARC cores are very configurable so there're
>  many variations of options like cache sizes, their line lengths,
>  additional hardware blocks like multipliers, dividers etc. And this
>  board could be used to make sure built software still runs on
>  different HW configurations.
>
> Cc: Felix Fietkau 
> Cc: Jo-Philipp Wich 
> Signed-off-by: Alexey Brodkin 
> ---
>
> Changes compared to v2:
>  * Fixed copyright dates
>  * Cleaned-up init scripts
>
> Changes compared to v1:
>  * Switched to SoC-centered design. Now instead of common ARC700
>support we claim support of boards based on ARC770D.
>This allows to use the same one build of kernel binary for both
>boards.
>
>  * Implemented run-time scripts that parse Device Tree compatible
>tag and according to it do configuration of serial port and network.
>
>  * Implemented ability to patch in built Linux kernel external .dtb
>
>  * Linux kernel switched from 4.1 to 4.3
>
>  * Rebased on current master
>
>  include/kernel.mk  |   2 +
>  target/Config.in   |   9 +
>  target/linux/arc770/Makefile   |  26 +++
>  target/linux/arc770/base-files/etc/inittab |   4 +
>  .../arc770/base-files/etc/uci-defaults/02_network  |  23 +++
>  target/linux/arc770/base-files/lib/arc.sh  |  76 +++
>  .../base-files/lib/preinit/01_preinit_arc.sh   |  10 +
>  target/linux/arc770/config-4.3 | 142 +
>  target/linux/arc770/dts/axc001.dtsi| 100 +
>  target/linux/arc770/dts/axs101.dts |  21 ++
>  target/linux/arc770/dts/axs10x_mb.dtsi | 224 
> +
>  target/linux/arc770/dts/nsim_700.dts   |  70 +++
>  target/linux/arc770/dts/skeleton.dtsi  |  37 
>  target/linux/arc770/generic/profiles/00-default.mk |  16 ++
>  target/linux/arc770/generic/profiles/01-minimal.mk |  15 ++
>  target/linux/arc770/generic/profiles/02-axs101.mk  |  17 ++
>  .../linux/arc770/generic/profiles/03-nsim_700.mk   |  16 ++
>  target/linux/arc770/generic/target.mk  |   8 +
>  target/linux/arc770/image/Makefile |  42 
>  ...openwrt-arc-remove-dependency-on-DEVTMPFS.patch |  36 
>  .../0002-openwrt-arc-add-OWRTDTB-section.patch |  91 +
>  21 files changed, 985 insertions(+)
>  create mode 100644 target/linux/arc770/Makefile
>  create mode 100644 target/linux/arc770/base-files/etc/inittab
>  create mode 100644 target/linux/arc770/base-files/etc/uci-defaults/02_network
>  create mode 100644 target/linux/arc770/base-files/lib/arc.sh
>  create mode 100644 
> target/linux/arc770/base-files/lib/preinit/01_preinit_arc.sh
>  create mode 100644 target/linux/arc770/config-4.3
>  create mode 100644 target/linux/arc770/dts/axc001.dtsi
>  create mode 100644 target/linux/arc770/dts/axs101.dts
>  create mode 100644 target/linux/arc770/dts/axs10x_mb.dtsi
>  create mode 100644 target/linux/arc770/dts/nsim_700.dts
>  create mode 100644 target/linux/arc770/dts/skeleton.dtsi
>  create mode 100644 target/linux/arc770/generic/profiles/00-default.mk
>  create mode 100644 target/linux/arc770/generic/profiles/01-minimal.mk
>  create mode 100644 target/linux/arc770/generic/profiles/02-axs101.mk
>  create mode 100644 target/linux/arc770/generic/profiles/03-nsim_700.mk
>  create mode 100644 target/linux/arc770/generic/target.mk
>  create mode 100644 target/linux/arc770/image/Makefile
>  create mode 100644 
> target/linux/arc770/patches-4.3/0001-openwrt-arc-remove-dependency-on-DEVTMPFS.patch
>  create mode 100644 
> target/linux/arc770/patches-4.3/0002-openwrt-arc-add-OWRTDTB-section.patch
>

(snip)

> diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network 
> b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> new file mode 100644
> index 000..7db8451
> --- /dev/null
> +++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> @@ -0,0 +1,23 

Re: [OpenWrt-Devel] Target profiles: making "make" build every profile

[Jonas Gorski]

Hi,

On Mon, Sep 14, 2015 at 11:30 AM, Rafał Miłecki  wrote:
> Quick summary:
> Subtargets - used for building modified kernels
> Profiles - used for including specific software
>
> There are two ways of using profiles:
>
> 1) Changing some software for all devices
> Used when profile is used for all devices (no filtering, no per device
> profiles).
> This is used e.g. by brcm47xx. Normally all images will be built with
> b43. However by changing a profile you can get *all* images to include
> wl.ko.
>
> 2) Including extra software for specific devices
> Used when profile is (group) device specific. E.g. including USB
> drivers for devices with USB only.
> This is something I'd like to use with bcm53xx. I'd like to include
> brcmfmac.ko in two images only (R8000 and SR400ac). Of course, I'll
> need to adjust target/bcm53xx/image/Makefile to:
> a) Stop building SR400ac and R8000 images for TARGET_bcm53xx_Generic
> b) Build above images for something new like TARGET_bcm53xx_brcmfmac

I don't think there is an issue with letting Generic build all images
with a "common" package set as default, and still having a defined
profile for it with a specialized package set.

> If I add TARGET_bcm53xx_brcmfmac as explained above, its images won't
> be build anymore by default.
> I'd like to to have a way to ask "make" for building all profiles by
> setting some variable in target/bcm53xx/Makefile
>
> Can someone give me some help with implementing this?

Changing the buildroot for that would be a lot of work, as you would
need to force all packages needed by all images as =m, and you would
have to require them, as else the image generation will fail if the
user decides to delect any of them (or silently drop it). And then the
issue of deciding if a package should be included in the image or not
based on the selected profile's default packages, the image's default
profile's packages, and the actual selection states in .config

I think a better place would be the image builder for that. There we
could just add e.g. a new build target like allimages that will
iterate over all available images and build them. Or maybe
"alldevices", and it would hook into the new Device-stuff and iterate
over all defined devices, with the assumption that these define their
specific profile so we don't need to add code to skip the common
profiles.

so we would then have something like

define Device/FooDevice
DEVICE_PROFILE=Foo
endef

define Device/BarDevice
   DEVICE_PROFILE=Bar
endef


and enhance the code in include/image.mk to collect these
DEVICE_PROFILEs to iterate over.


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

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

[Jonas Gorski]

Hi,

On Tue, Sep 8, 2015 at 9:00 PM, Drasko DRASKOVIC
 wrote:
> Subject: [PATCH] [SIGNED-OFF] Add initial support for WeIO board

Please version your patches if you change them ([PATCH V2] etc)
> Add support for WeIO board (http://we-io.net), which is based on
> Carambola2 board from 8Devices.
>
> Signed-off-by: Drasko DRASKOVIC 
> ---

Please keep a changelog here about the changes between submitssions
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   3 +-
>  target/linux/ar71xx/config-4.1 |   1 +
>  .../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 145 
> +
>  target/linux/ar71xx/generic/profiles/weio.mk   |  17 +++
>  target/linux/ar71xx/image/Makefile |   8 ++
>  .../700-MIPS-ath79-openwrt-machines.patch  |  21 ++-

I don't see you updating etc/uci-defaults/02_network or any of the
uci-defaults files, so this won't have any proper config.


>  7 files changed, 192 insertions(+), 6 deletions(-)
>  create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>  create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
>
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index e1f345e..e30cac2 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -832,6 +832,9 @@ ar71xx_board_detect() {
> *"UniFi AP Pro")
> name="uap-pro"
> ;;
> +   *"WeIO")
> +   name="weio"
> +   ;;
> *WHR-G301N)
> name="whr-g301n"
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index c1962e4..b681fb8 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -250,7 +250,8 @@ platform_check_image() {
> nbg460n_550n_550nh | \
> unifi | \
> unifi-outdoor | \
> -   carambola2 )
> +   carambola2 | \
> +   weio )
> [ "$magic" != "2705" ] && {
> echo "Invalid image type."
> return 1
> diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
> index 21c4601..7d836d9 100644
> --- a/target/linux/ar71xx/config-4.1
> +++ b/target/linux/ar71xx/config-4.1
> @@ -139,6 +139,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
>  CONFIG_ATH79_MACH_TUBE2H=y
>  CONFIG_ATH79_MACH_UBNT=y
>  CONFIG_ATH79_MACH_UBNT_XM=y
> +CONFIG_ATH79_MACH_WEIO=y
>  CONFIG_ATH79_MACH_WHR_HP_G300N=y
>  CONFIG_ATH79_MACH_WLAE_AG300N=y
>  CONFIG_ATH79_MACH_WLR8100=y
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
> new file mode 100644
> index 000..791991c
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
> @@ -0,0 +1,145 @@
> +/**
> + * WEIO Web Of Things Platform
> + *
> + * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
> + *
> + *  ##  ##    ###
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *  ##  ##  ## ####  ## ##
> + *   ###  ###     ###
> + *
> + *   Web Of Things Platform
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + *
> + * Authors :
> + * Drasko DRASKOVIC 
> + * Uros PETREVSKI 
> + */
> +
> +#include 
> +#include 
> +#include "common.h"
> +#include "dev-eth.h"
> +#include "dev-gpio-buttons.h"
> +#include "dev-leds-gpio.h"
> +#include "dev-m25p80.h"
> +#include "dev-spi.h"
> +#include "dev-usb.h"
> +#include "dev-wmac.h"
> +#include "machtypes.h"
> +#include "linux/i2c-gpio.h"
> +#include "linux/platform_device.h"
> +
> +#define WEIO_GPIO_LED_STA  1
> +#define WEIO_GPIO_LED_AP   16
> +
> +#define 

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

[Jonas Gorski]

Hi,

On Thu, Sep 10, 2015 at 3:00 PM, Dmitry Ivanov
 wrote:
> Bridge hairpin mode must be off by default when multicast_to_unicast is
> off. Enabling this mode leads to broadcast frames such as ARP and DHCP
> being retransmitted back to AP in WDS configurations.
>
> Signed-off-by: Dmitry Ivanov 

Commit subject/message does not match what the patch does:

> ---
>  system-linux.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/system-linux.c b/system-linux.c
> index 01500a5..6994ace 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -576,12 +576,11 @@ static char *system_get_bridge(const char *name, char 
> *buf, int buflen)
>  static void
>  system_bridge_set_wireless(struct device *bridge, struct device *dev)
>  {
> -   bool mcast_to_ucast = true;
> +   bool mcast_to_ucast = false;
> bool hairpin = true;
>
> -   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST &&
> -   !bridge->settings.multicast_to_unicast)
> -   mcast_to_ucast = false;
> +   if (bridge->settings.flags & DEV_OPT_MULTICAST_TO_UNICAST)
> +   mcast_to_ucast = bridge->settings.multicast_to_unicast;
>
> if (!mcast_to_ucast || dev->wireless_isolate)
> hairpin = false;

hairpin mode will already be disabled if macst_to_ucast is disabled.

What this patch does is change the default of multicast to unicast to
off. Changing the default of hairpin mode to off is only a side effect
of that.


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