Re: [PATCH net-next] bridge: multicast to unicast
Am 09.01.2017 13:15, schrieb Johannes Berg: That is bridge fdb entries (need to) expire so the bridge might "forget" a still-connected station not sending but only consuming broadcast traffic. Ok, that I don't know. Somehow if you address a unicast packet there the bridge has to make a decision - so it really should know? If the bridge has not learned the unicast destination mac address on any port, it will flood the packet on all ports except the port it received the packet on. Regards, M. Braun
Re: [PATCH net-next] bridge: multicast to unicast
Am 09.01.2017 13:15, schrieb Johannes Berg: That is bridge fdb entries (need to) expire so the bridge might "forget" a still-connected station not sending but only consuming broadcast traffic. Ok, that I don't know. Somehow if you address a unicast packet there the bridge has to make a decision - so it really should know? If the bridge has not learned the unicast destination mac address on any port, it will flood the packet on all ports except the port it received the packet on. Regards, M. Braun
Re: [Projekt-wlan] Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi,
thanks for the quick reply.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
I applied it, but it does not make any difference on my platform.
Regards,
M. Braun
Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
Hi Braun,
It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
unstable,
introduced by patch "EHCI: centralize controller initialization".
I submitted a patch to fix it.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
Regards,
Shengzhou
-Original Message-
From: Michael Braun [mailto:michael-...@fami-braun.de]
Sent: Wednesday, April 17, 2013 6:08 PM
To: Liu Shengzhou-B36685
Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
Freescale P1020
Hi,
I'm running OpenWRT Kernel 3.8.3 (which already has
f66dea709cd9309b2ee9f715697818001fb518de and
5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
(QorlQ,
PPC) device.
Before updating the kernel from 3.3.0, USB host support was working
fine.
Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and the
lsusb output is empty, so USB host support is not working. When I
apply
the following patch, USB host support starts working again, so I
guess
3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
Do you have an idea how to fix it more appropriately?
Thanks,
M. Braun
--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
+0200
+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
+0200
@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
if (!spin_event_timeout(in_be32(non_ehci +
FSL_SOC_USB_CTRL) &
PHY_CLK_VALID,
FSL_USB_PHY_CLK_TIMEOUT,
0)) {
printk(KERN_WARNING "fsl-ehci: USB PHY clock
invalid\n");
- return -EINVAL;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Projekt-wlan] Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi,
thanks for the quick reply.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
I applied it, but it does not make any difference on my platform.
Regards,
M. Braun
Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
Hi Braun,
It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
unstable,
introduced by patch EHCI: centralize controller initialization.
I submitted a patch to fix it.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
Regards,
Shengzhou
-Original Message-
From: Michael Braun [mailto:michael-...@fami-braun.de]
Sent: Wednesday, April 17, 2013 6:08 PM
To: Liu Shengzhou-B36685
Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
Freescale P1020
Hi,
I'm running OpenWRT Kernel 3.8.3 (which already has
f66dea709cd9309b2ee9f715697818001fb518de and
5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
(QorlQ,
PPC) device.
Before updating the kernel from 3.3.0, USB host support was working
fine.
Now I get fsl-ehci: USB PHY clock invalid messages in dmesg and the
lsusb output is empty, so USB host support is not working. When I
apply
the following patch, USB host support starts working again, so I
guess
3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
Do you have an idea how to fix it more appropriately?
Thanks,
M. Braun
--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
+0200
+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
+0200
@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
if (!spin_event_timeout(in_be32(non_ehci +
FSL_SOC_USB_CTRL)
PHY_CLK_VALID,
FSL_USB_PHY_CLK_TIMEOUT,
0)) {
printk(KERN_WARNING fsl-ehci: USB PHY clock
invalid\n);
- return -EINVAL;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Notify userspace about bridge learning MAC on new port
Hi,
currently, the userspace is informed about the port the MAC is learned
on a bridge and about the bridge removing the MAC from its forwarding
table, but not when the MAC is learned on a different port. This is
inconsistent and makes it difficult for applications to keep track of
all MACs learned by a bridge on a subset of its ports.
Please find attached a patch that fixes this by sending an RTM_NEWNEIGH
message when the forwarding destination port changes.
Regards,
M. BraunNotify userspace about bridge learning MAC on new port
Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.
Signed-off-by: Michael Braun
--- a/net/bridge/br_fdb.c 2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_fdb.c 2013-04-15 11:23:55.941166319 +0200
@@ -408,6 +408,7 @@ static int fdb_insert(struct net_bridge
{
struct hlist_head *head = >hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
if (!is_valid_ether_addr(addr))
return -EINVAL;
@@ -471,8 +472,12 @@ void br_fdb_update(struct net_bridge *br
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb->dst;
fdb->dst = source;
fdb->updated = jiffies;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(>hash_lock);
[PATCH] Notify userspace about bridge learning MAC on new port
Hi,
currently, the userspace is informed about the port the MAC is learned
on a bridge and about the bridge removing the MAC from its forwarding
table, but not when the MAC is learned on a different port. This is
inconsistent and makes it difficult for applications to keep track of
all MACs learned by a bridge on a subset of its ports.
Please find attached a patch that fixes this by sending an RTM_NEWNEIGH
message when the forwarding destination port changes.
Regards,
M. BraunNotify userspace about bridge learning MAC on new port
Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.
Signed-off-by: Michael Braun michael-...@fami-braun.de
--- a/net/bridge/br_fdb.c 2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_fdb.c 2013-04-15 11:23:55.941166319 +0200
@@ -408,6 +408,7 @@ static int fdb_insert(struct net_bridge
{
struct hlist_head *head = br-hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
if (!is_valid_ether_addr(addr))
return -EINVAL;
@@ -471,8 +472,12 @@ void br_fdb_update(struct net_bridge *br
source-dev-name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb-dst;
fdb-dst = source;
fdb-updated = jiffies;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(br-hash_lock);
