These spots should be detecting the amd64 architecture, not the
specific target name. If additional amd64 targets were added, or
the target was renamed, these would fail to build.
Signed-off-by: Elliott Mitchell
---
package/firmware/intel-microcode/Makefile | 2 +-
package/kernel/linux/modules/
Point "generic" at amd64 which is far more important to nearly
everyone.
Signed-off-by: Elliott Mitchell
---
package/kernel/linux/modules/virt.mk| 2 +-
target/linux/x86/Makefile | 2 +-
.../x86/{64 => generic}/base-files/lib/prei
There are few (if any) non-64-bit x86 processors currently in
production, therefore calling non-64-bit "generic" is a major
misnomer.
Signed-off-by: Elliott Mitchell
---
package/kernel/linux/modules/virt.mk| 2 +-
target/linux/x86/Makefile
While many Intel P4 processors were produced, they do not represent
sufficient share of x86 to deserve an exclusive target. i686 is
a much larger share. Due to the feature of SMP, which was absent
from x86 before i686 this is still worthy of a distinct target.
Signed-off-by: Elliott Mitchell
--
"Pentium4" was never generic for x86. Certainly Intel made plenty of
P4s, and they kept their extras with the ia32-only Core processors. Yet
this excludes all AMD processors, all Cyrix processors, and all Transmeta
processors.
Further while those extras do add value, the value is limited. Meanw
The port_vlan_add method may be called while a port is already a member
of that VLAN, so it needs to be able to handle changed flags. Fix it to
properly handle when the PVID or UNTAGGED flag was previously set, but
now no longer is.
To reduce duplication, move PVID configuration to a separate func
The registers L2_PORT_STATIC_MV_ACT seem to specify the action to take
when the source address of a packet exists as a static fdb entry on
another port. By default the configured action is to drop such packets.
For standalone ports, this behaviour is undesired, as all traffic should
be forwarded t
Correctly update the isolation mask of the port being configured. The
port_bitmap variable should contain all other bridge members and needs
to be actually removed from the isolation mask instead of added to it.
Also actually remove the port being configured from the pm field of the
other ports, s
All ports are disabled by default, so configure the port isolation masks
and the pm field accordingly in the setup function. When port_enable is
called for a port, the isolation masks will be set up so that traffic
can flow between the port and the CPU.
While at it, change the code to also use the
This series fixes several bugs that can result in packets being
forwarded incorrectly. The port isolation and VLAN issues probably
remained unnoticed so far, because they only manifest when after a port
leaves a bridge, or an existing VLAN membership is changed.
Jan Hoffmann (4):
realtek: proper
Hi Petr,
thanks for the comments.
These patches are my minimal version to get something running. I will
try to extend it in the new few weeks.
On 3/11/23 09:57, Petr Štetiar wrote:
Hauke Mehrtens [2023-03-09 00:18:10]:
Hi,
thanks for taking care, LGTM for a start.
I'll just provide my pa
On 3/11/23 10:01, Petr Štetiar wrote:
Hauke Mehrtens [2023-03-09 00:18:09]:
Hi,
It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.
so maybe this should be detected and decided at runtime? Otherwise
On Fri, 2023-02-03 at 23:03 +0100, Sander Vanheule wrote:
> TP-Link is playing fast and loose with the safeloader format, having
> resulted in different types of images with their specific quirks.
>
> A new incompatible format is currently used in the wild, which places
> the payload partition tab
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
Home
14 matches
Mail list logo
