> The flag was introduced to enable hardware switch capabilities of
> drivers/net/wireless/quantenna/qtnfmac wifi driver. It does not have any
> switchdev functionality in upstream tree at this moment, and this patchset
> was intended as a preparatory change.
O.K. But i suggest you add basic switc
On 03/10/2018 02:08 PM, Andrew Lunn wrote:
Hi Igor
You don't appear to be adding any user of this. Please also make one
of the switchdev drivers actually use this new functionality.
Andrew
Hi Andrew, a first user is supposed to be
drivers/net/wireless/quantenna/qtnfmac wifi driver. I w
On Mon, 12 Mar 2018 23:42:48 +0100
Rafał Miłecki wrote:
> 2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility
>
> If we agree that 802.11f support in FullMAC firmware is acceptable, then
> we have to make sure Linux's bridge doesn't break it by passing 802.11f
> (broadcast) fr
On 03/10/2018 08:55 AM, Andrew Lunn wrote:
Is this sufficiently granular? There are a few different use cases for
flooding:
There is no fdb entry in the software switch for the destination MAC
address, so flood the packet out all ports of the bridge. The hardware
switch might have an entry in it
On 03/10/2018 08:38 AM, Andrew Lunn wrote:
+ return 0;
+
+ err = br_switchdev_set_port_flag(p, flags, mask);
+ if (err)
+ return err;
You might want to consider the br_warn() in
br_switchdev_set_port_flag(). Do we want to spam the kernel log? Or
should store_f
On 03/10/2018 08:32 AM, Stephen Hemminger wrote:
Yes hardware devices may come it with different default values.
But the user experience on Linux needs to be consistent.
Instead, it makes more sense to me for each device driver using switchdev
to program to the values that it sees in the bridge.
On 03/10/2018 08:30 AM, Andrew Lunn wrote:
+
+ ret = switchdev_port_attr_get(dev, &attr);
+ if (ret)
+ return BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
Hi Igor
Please check if ret == -EOPNOTSUPP and only then use the defaults. A
real error should be propaga
On Mon, Mar 12, 2018 at 12:08:56PM +0100, Linus Lüssing wrote:
> On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> > I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> > FullMAC WiFi chipset.
>
> Hi Rafał,
>
> Thanks for reporting this issue!
>
> > Can you see
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of
On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> FullMAC WiFi chipset.
Hi Rafał,
Thanks for reporting this issue!
> Can you see any solution for this problem? Is that an option to stop
> multicast-to-unicast
10 matches
Mail list logo