Hi,
Op vrijdag 17 juni 2022 om 09:54:56 +02:00:00 schreef Bjørn Mork
:
Sander Vanheule writes:
On Thu, 2022-06-16 at 22:28 +0200, Stijn Segers wrote:
Signed-off-by: Stijn Segers
You need to add at least one line describing why this change is
needed; now you
only have a commit title.
Make the u-boot environment partition for the NETGEAR
GS108T v3 and GS110TPP writable (they share a DTS), so
the values can be manipulated from userspace.
See https://forum.openwrt.org/t/57875/1567 for a real
world example.
Signed-off-by: Stijn Segers
---
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.--- Begin Message ---
Branch: refs/heads/master
Removing this gcc-12 error:
arch/mips/rtl838x/setup.c:64:30: error: comparison between two arrays
[-Werror=array-compare]
64 | else if (__dtb_start != __dtb_end)
Signed-off-by: Bjørn Mork
---
Kind of stupid
But this is how similar fallout has been fixed in mainline AFAICS. For
On 19/06/2022 13:46, Sander Vanheule wrote:
Priority values passed to the egress (TX) frame header initialiser are
invalid when smaller than 0, and should not be assigned to the frame.
Queue assignment is then left to the switch core logic.
Current code for RTL83xx forces the passed priority
Destination switch ports for outgoing frame can range from 0 to
CPU_PORT-1.
Refactor the code to only generate egress frame CPU headers when a valid
destination port number is available, and make the code a bit more
consistent between different switch generations. Change the dest_port
argument's
The flag to enable L2 address learning on egress frames is in bits 40,
with bit 0 being the leftmost bit of the header. This corresponds to
BIT(7) in the third 16-bit value of the header.
Correctly set L2LEARNING by fixing the off-by-one error.
Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag
Priority values passed to the egress (TX) frame header initialiser are
invalid when smaller than 0, and should not be assigned to the frame.
Queue assignment is then left to the switch core logic.
Current code for RTL83xx forces the passed priority value to be
positive, by always masking it to
The flags to enable the outgoing port mask is in bits 43, with bit 0
being the leftmost bit of the header. This corresponds to BIT(4) in the
third 16-bit value of the header.
Correctly set AS_DPM by fixing the off-by-one error.
Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag usage")
These patches contains a few code improvements and fixes for erroneous
bitfield assignments. Currently only compile tested, so until I can test
these patches, please let me know how this changes behaviour on the
affected platforms.
Sander Vanheule (4):
realtek: correct egress frame priority
Hi Birger,
On Sun, 2022-06-19 at 11:40 +0200, Birger Koblitz wrote:
> Hi,
>
> On 19.06.22 10:56, Sander Vanheule wrote:
>
> > - h->cpu_tag[1] = h->cpu_tag[2] = 0;
> > - if (prio >= 0)
> > - h->cpu_tag[2] = BIT(13) | prio << 8; // Enable and set
> > Priority Queue
> >
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.--- Begin Message ---
On 19.06.2022 11:56, Sander
Hi,
On 19.06.22 10:56, Sander Vanheule wrote:
> - h->cpu_tag[1] = h->cpu_tag[2] = 0;
> - if (prio >= 0)
> - h->cpu_tag[2] = BIT(13) | prio << 8; // Enable and set Priority
> Queue
> + h->cpu_tag[1] = 0;
> + /* Enable (AS_QID) and set Priority Queue (QID) */
> +
Destination switch ports for outgoing frame can range from 0 to
CPU_PORT-1, and frame priorities should also always be positive.
Refactor the code to only generate egress frame CPU headers when the a
valid destination port number is available, and make the code a bit more
consistent between
14 matches
Mail list logo
