* [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings
From: esben.haabendal @ 2018-04-05 11:44 UTC (permalink / raw)
To: Richard Cochran, Andrew Lunn, Florian Fainelli,
open list:PTP HARDWARE CLOCK SUPPORT, open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-1-esben.haabendal@gmail.com>
From: Esben Haabendal <eha@deif.com>
Read configration settings, to allow automatic forced speed/duplex setup
by hardware strapping.
Signed-off-by: Esben Haabendal <eha@deif.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/net/phy/dp83640.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 654f42d00092..01e21b4998ad 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1134,6 +1134,10 @@ static int dp83640_probe(struct phy_device *phydev)
if (!dp83640)
goto no_memory;
+ err = genphy_read_config(phydev);
+ if (err)
+ goto no_config;
+
dp83640->phydev = phydev;
INIT_DELAYED_WORK(&dp83640->ts_work, rx_timestamp_work);
@@ -1166,6 +1170,7 @@ static int dp83640_probe(struct phy_device *phydev)
no_register:
clock->chosen = NULL;
+no_config:
kfree(dp83640);
no_memory:
dp83640_clock_put(clock);
--
2.16.3
^ permalink raw reply related
* [PATCH 1/2] net: phy: Helper function for reading strapped configuration values
From: esben.haabendal @ 2018-04-05 11:44 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, open list:ETHERNET PHY LIBRARY,
open list
Cc: Esben Haabendal, Rasmus Villemoes
From: Esben Haabendal <eha@deif.com>
Add a function for use in PHY driver probe functions, reading current
autoneg, speed and duplex configuration from BMCR register.
Useful for PHY that supports hardware strapped configuration, enabling
Linux to respect that configuration (i.e. strapped non-autoneg
configuration).
Signed-off-by: Esben Haabendal <eha@deif.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/net/phy/phy_device.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 1 +
2 files changed, 42 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 74664a6c0cdc..cc52ff2a2344 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1673,6 +1673,47 @@ int genphy_config_init(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_config_init);
+/**
+ * genphy_read_config - read configuration from PHY
+ * @phydev: target phy_device struct
+ *
+ * Description: Reads MII_BMCR and sets phydev autoneg, speed and duplex
+ * accordingly. For use in driver probe functions, to respect strapped
+ * configuration settings.
+ */
+int genphy_read_config(struct phy_device *phydev)
+{
+ int bmcr;
+
+ bmcr = phy_read(phydev, MII_BMCR);
+ if (bmcr < 0)
+ return bmcr;
+
+ if (BMCR_ANENABLE & bmcr) {
+ phydev->autoneg = AUTONEG_ENABLE;
+
+ phydev->speed = 0;
+ phydev->duplex = -1;
+ } else {
+ phydev->autoneg = AUTONEG_DISABLE;
+
+ if (bmcr & BMCR_FULLDPLX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (bmcr & BMCR_SPEED1000)
+ phydev->speed = SPEED_1000;
+ else if (bmcr & BMCR_SPEED100)
+ phydev->speed = SPEED_100;
+ else
+ phydev->speed = SPEED_10;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(genphy_read_config);
+
/* This is used for the phy device which doesn't support the MMD extended
* register access, but it does have side effect when we are trying to access
* the MMD register via indirect method.
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 7c4c2379e010..5a8821c8105d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -970,6 +970,7 @@ void phy_attached_info(struct phy_device *phydev);
/* Clause 22 PHY */
int genphy_config_init(struct phy_device *phydev);
+int genphy_read_config(struct phy_device *phydev);
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
--
2.16.3
^ permalink raw reply related
* [RFC] ethtool: Support for driver private ioctl's
From: Jose Abreu @ 2018-04-05 10:47 UTC (permalink / raw)
To: David Miller, Jakub Jelinek, Jeff Garzik, Tim Hockin,
Eli Kupermann, Chris Leech, Scott Feldman, Ben Hutchings
Cc: netdev, Joao Pinto
Hi All,
I would like to know your opinion regarding adding support for
driver private ioctl's in ethtool.
Background: Synopsys Ethernet IP's have a certain number of
features which can be reconfigured at runtime. Giving you two
examples: One of the most recent one is the safety features,
which can be enabled/disabled and forced at runtime. Another one
is a Flexible RX Parser which can route specific packets to
specific RX DMA channels. Given that these are features specific
to our IP's it would not be useful to add an uniform API for this
because the users would only be one or two drivers ...
This new feature would change the help usage for ethtool so that
each driver private option would be shown, and then each driver
specific file would have a structure with all the available
options. Finally, each driver would have to handle the private
IOCTL's.
We already have this working locally and now I would like to know
your opinion about upstreaming this ... Do you think this can be
useful for anyone else? Or should we change direction to use, for
example, debugfs/configfs?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: Best userspace programming API for XDP features query to kernel?
From: Daniel Borkmann via iovisor-dev @ 2018-04-05 10:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Eric Leblond, Victor Julien, Peter Manev
Cc: oisf-devel-ZwoEplunGu2j570ONfqVQLVmwVP6tfMwSoIsB4E12gc,
Jakub Kicinski, Alexei Starovoitov, netdev-u79uwXL29TY76Z2rM5mHXA,
iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org,
Saeed Mahameed, Daniel Borkmann
In-Reply-To: <20180404142856.284ee8c9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 04/04/2018 02:28 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
> Hi Suricata people,
>
> When Eric Leblond (and I helped) integrated XDP in Suricata, we ran
> into the issue, that at Suricata load/start time, we cannot determine
> if the chosen XDP config options, like xdp-cpu-redirect[1], is valid on
> this HW (e.g require driver XDP_REDIRECT support and bpf cpumap).
>
> We would have liked a way to report that suricata.yaml config was
> invalid for this hardware/setup. Now, it just loads, and packets gets
> silently dropped by XDP (well a WARN_ONCE and catchable via tracepoints).
>
> My question to suricata developers: (Q1) Do you already have code that
> query the kernel or drivers for features?
>
> At the IOvisor call (2 weeks ago), we discussed two options of exposing
> XDP features avail in a given driver.
>
> Option#1: Extend existing ethtool -k/-K "offload and other features"
> with some XDP features, that userspace can query. (Do you already query
> offloads, regarding Q1)
>
> Option#2: Invent a new 'ip link set xdp' netlink msg with a query option.
I don't really mind if you go via ethtool, as long as we handle this
generically from there and e.g. call the dev's ndo_bpf handler such that
we keep all the information in one place. This can be a new ndo_bpf command
e.g. XDP_QUERY_FEATURES or such.
More specifically, how would such feature mask look like? How fine grained
would this be? When you add a new minor feature to, say, cpumap that not
all drivers support yet, we'd need a new flag each time, no? Same for meta data,
then potentially for the redirect memory return work, or the af_xdp bits, the
xdp_rxq_info would have needed it, etc. What about nfp in terms of XDP
offload capabilities, should they be included as well or is probing to load
the program and see if it loads/JITs as we do today just fine (e.g. you'd
otherwise end up with extra flags on a per BPF helper basis)? To make a
somewhat reliable assertion whether feature xyz would work, this would
explode in new feature bits long term. Additionally, if we end up with a
lot of feature flags, it will be very hard for users to determine whether
this particular set of features a driver supports actually represents a
fully supported native XDP driver.
What about keeping this high level to users? E.g. say you have 2 options
that drivers can expose as netdev_features_strings 'xdp-native-full' or
'xdp-native-partial'. If a driver truly supports all XDP features for a
given kernel e.g. v4.16, then a query like 'ethtool -k foo' will say
'xdp-native-full', if at least one feature is missing to be feature complete
from e.g. above list, then ethtool will tell 'xdp-native-partial', and if
not even ndo_bpf callback exists then no 'xdp-native-*' is reported.
Side-effect might be that it would give incentive to keep drivers in state
'xdp-native-full' instead of being downgraded to 'xdp-native-partial'.
Potentially, in the 'xdp-native-partial' state, we can expose a high-level
list of missing features that the driver does not support yet, which would
over time converge towards 'zero' and thus 'xdp-native-full' again. ethtool
itself could get a new XDP specific query option that, based on this info,
can then dump the full list of supported and not supported features. In order
for this to not explode, such features would need to be kept on a high-level
basis, meaning if e.g. cpumap gets extended along with support for a number
of drivers, then those that missed out would need to be temporarily
re-flagged with e.g. 'cpumap not supported' until it gets also implemented
there. That way, we don't explode in adding too fine-grained feature bit
combinations long term and make it easier to tell whether a driver supports
the full set in native XDP or not. Thoughts?
> (Q2) Do Suricata devs have any preference (or other options/ideas) for
> the way the kernel expose this info to userspace?
>
> [1] http://suricata.readthedocs.io/en/latest/capture-hardware/ebpf-xdp.html#the-xdp-cpu-redirect-case
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Laurentiu Tudor @ 2018-04-05 10:30 UTC (permalink / raw)
To: Andrew Lunn, Stuart Yoder
Cc: Arnd Bergmann, Ioana Ciornei, gregkh, Linux Kernel Mailing List,
Ruxandra Ioana Ciocoi Radulescu, Razvan Stefanescu, Roy Pledge,
Networking
In-Reply-To: <20180404124246.GA20869@lunn.ch>
Hello,
My 2c below.
On 04/04/2018 03:42 PM, Andrew Lunn wrote:
>> I hear you. It is more complicated this way...having all these individual
>> objects vs just a single "bundle" of them that represents a NIC. But, that's
>> the way the DPAA2 hardware is, and we're implementing kernel support for
>> the hardware as it is.
>
> Hi Stuart
>
> I see we are not making any progress here.
>
> So what i suggest is you post the kernel code and configuration tool
> concept to netdev for a full review. You want reviews from David
> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
>
I think that the discussion steered too much towards networking related
topics, while this ioctl doesn't have much to do with networking.
It's just an ioctl for our mc-bus bus driver that is used to manage the
devices on this bus through userspace tools.
In addition, I'd drop any mention of our reference user space app
(restool) to emphasize that this ioctl is not added just for a
particular user space app. I think Stuart also mentioned this.
---
Thanks & Best Regards, Laurentiu
^ permalink raw reply
* [PATCH net] net: mvpp2: Fix parser entry init boundary check
From: Maxime Chevallier @ 2018-04-05 9:55 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
Boundary check in mvpp2_prs_init_from_hw must be done according to the
passed "tid" parameter, not the mvpp2_prs_entry index, which is not yet
initialized at the time of the check.
Fixes: 47e0e14eb1a6 ("net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 7fc1bbf51c44..54a038943c06 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -1604,7 +1604,7 @@ static int mvpp2_prs_init_from_hw(struct mvpp2 *priv,
{
int i;
- if (pe->index > MVPP2_PRS_TCAM_SRAM_SIZE - 1)
+ if (tid > MVPP2_PRS_TCAM_SRAM_SIZE - 1)
return -EINVAL;
memset(pe, 0, sizeof(*pe));
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Gustavo A. R. Silva @ 2018-04-05 9:51 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <347FC7F5-4BB3-4477-9EF1-BAAA98F1D107@holtmann.org>
On 04/05/2018 03:46 AM, Marcel Holtmann wrote:
>> By the way, what is you opinion on replacing crypto_shash_descsize(ctx) with PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
>>
>> Does it work for you?
>
> isn’t that just waste?
>
Agree.
> The macro itself is this.
>
> #define SHASH_DESC_ON_STACK(shash, ctx) \
> char __##shash##_desc[sizeof(struct shash_desc) + \
> crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \
> struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
>
> For AES-CMAC, we could always do this with a manual macro that gives us the right size. However that is error prone if any internals change. I think what has to happened that crypto_shash_decsize becomes something the compiler can evaluate at compile time.
>
Yeah. That would imply an analysis of the algorithm each of the callers
use. In the case of AES-CMAC, what is the maximum digest size?
I tried to find a fixed-length value for AES-CMAC but I didn't get any
output with git grep -n _DIGEST_SIZE | grep AES
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Edward Cree @ 2018-04-05 8:49 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20180405052820.eurpes52ilhofbg3@ast-mbp.dhcp.thefacebook.com>
On 05/04/18 06:28, Alexei Starovoitov wrote:
> On Thu, Apr 05, 2018 at 12:58:46AM +0100, Edward Cree wrote:
>> On 04/04/18 00:37, Alexei Starovoitov wrote:
>>> hmm. that doesn't fail for me and any other bots didn't complain.
>>> Are you sure you're running the latest kernel and tests?
>> Ah, test_progs isn't actually rebuilding because __NR_bpf is undeclared;
>> something must be going wrong with header files.
>> Never mind.
>>
>>> hmm. what's wrong with bsearch? It's trivial and fast.
>> bsearch is O(log n), and the sort() call on the subprog_starts (which happens
>> every time add_subprog() is called) is O(n log n).
>> Whereas reading aux->subprogno is O(1).
>> As far as I'm concerned, that's a sign that the latter data structure is the
>> appropriate one.
> only if it can be done as separate _first_ pass before cfg.
As I think I already said, I'm working on a next version of the patch that
does just that.
> No. It's worse. Your proposed approach to bounded loops completely
> relying on 'explore all paths' whereas John's does not.
> Can 'explore all paths' work with 1M bpf insns? No.
> Whereas an approach that builds dom graph, detects natural loops
> and loop invariants - can.
... IF it's possible at all, which I'm still doubtful about.
> This sounds like arbitrary assumptions what this new approach would do.
> Instead of rejecting it outright try to solve this very hard problem.
I'm not rejecting it outright; I'm just saying, be prepared for the possibility
that it can't be solved, and try to leave a line of retreat / have a plan B in
the case that it proves to be subject to a no-free-lunch theorem. Because my
intuition is that an entropy argument may require all algos to have the same
superexponential worst-case running time as 'explore all paths' does.
> Before this discussion gets carried away too far let's get back to this patch set.
> Having seen all arguments I still think that only patch 3 is worth pursuing further.
I think the next version of the patch series (coming real soon now) answers at
least most of your objections (and indeed the above debate isn't relevant to it).
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Marcel Holtmann @ 2018-04-05 8:46 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <2af25866-4e8a-7f9c-9298-e45abfab20c7@embeddedor.com>
Hi Gustavo,
>> so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
>
> Yeah. I agree.
>
> Based on Herbert's response to the discussion about SHASH_DESC_ON_STACK https://lkml.org/lkml/2018/3/27/300
>
> it seems it is feasible to fix that macro very easily. I will follow up on this.
>
> By the way, what is you opinion on replacing crypto_shash_descsize(ctx) with PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
>
> Does it work for you?
isn’t that just waste?
The macro itself is this.
#define SHASH_DESC_ON_STACK(shash, ctx) \
char __##shash##_desc[sizeof(struct shash_desc) + \
crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \
struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
For AES-CMAC, we could always do this with a manual macro that gives us the right size. However that is error prone if any internals change. I think what has to happened that crypto_shash_decsize becomes something the compiler can evaluate at compile time.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Gustavo A. R. Silva @ 2018-04-05 8:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <3BD15121-532A-45E2-B62E-1008C0289500@holtmann.org>
Hi Marcel,
On 04/05/2018 02:23 AM, Marcel Holtmann wrote:
> so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
>
Yeah. I agree.
Based on Herbert's response to the discussion about SHASH_DESC_ON_STACK
https://lkml.org/lkml/2018/3/27/300
it seems it is feasible to fix that macro very easily. I will follow up
on this.
By the way, what is you opinion on replacing crypto_shash_descsize(ctx)
with PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
Does it work for you?
Thanks
--
Gustavo
^ permalink raw reply
* [PATCH net] arp: fix arp_filter on l3slave devices
From: Miguel Fadon Perlines @ 2018-04-05 8:25 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Miguel Fadon Perlines
arp_filter performs an ip_route_output search for arp source address and
checks if output device is the same where the arp request was received,
if it is not, the arp request is not answered.
This route lookup is always done on main route table so l3slave devices
never find the proper route and arp is not answered.
Passing l3mdev_master_ifindex_rcu(dev) return value as oif fixes the
lookup for l3slave devices while maintaining same behavior for non
l3slave devices as this function returns 0 in that case.
Signed-off-by: Miguel Fadon Perlines <mfadon@teldat.com>
---
net/ipv4/arp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f28f06c..7333db1 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -437,7 +437,7 @@ static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
/*unsigned long now; */
struct net *net = dev_net(dev);
- rt = ip_route_output(net, sip, tip, 0, 0);
+ rt = ip_route_output(net, sip, tip, 0, l3mdev_master_ifindex_rcu(dev));
if (IS_ERR(rt))
return 1;
if (rt->dst.dev != dev) {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Marcel Holtmann @ 2018-04-05 7:23 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <20180321010527.GA16616@embeddedor.com>
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> ---
> Changes in v2:
> - Fix memory leak in previous patch.
>
> net/bluetooth/smp.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index a2ddae2..0fa7035 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -173,7 +173,7 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,
> size_t len, u8 mac[16])
> {
> uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
> - SHASH_DESC_ON_STACK(desc, tfm);
> + struct shash_desc *shash;
so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps
From: Arnd Bergmann @ 2018-04-05 6:50 UTC (permalink / raw)
To: Ulf Hansson
Cc: Boris Brezillon, Robert Jarzmik, Daniel Mack, Haojian Zhuang,
Bartlomiej Zolnierkiewicz, Tejun Heo, Vinod Koul,
Mauro Carvalho Chehab, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Nicolas Pitre, Samuel Ortiz, Greg Kroah-Hartman,
Jaroslav
In-Reply-To: <CAPDyKFoFz_HgYPOMGuOTpehrTR3DtWE3uZbcnVwUwVhDy02Mow@mail.gmail.com>
On Thu, Apr 5, 2018 at 8:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 4 April 2018 at 21:56, Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>> On Wed, 04 Apr 2018 21:49:26 +0200
>> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>
>>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>>
>>> > On 2 April 2018 at 16:26, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>> >> Hi,
>>> >>
>>> >> This serie is aimed at removing the dmaengine slave compat use, and transfer
>>> >> knowledge of the DMA requestors into architecture code.
>>> >> As this looks like a patch bomb, each maintainer expressing for his tree either
>>> >> an Ack or "I want to take through my tree" will be spared in the next iterations
>>> >> of this serie.
>>> >
>>> > Perhaps an option is to send this hole series as PR for 3.17 rc1, that
>>> > would removed some churns and make this faster/easier? Well, if you
>>> > receive the needed acks of course.
>>> For 3.17-rc1 it looks a bit optimistic with the review time ... If I have all
>>
>> Especially since 3.17-rc1 has been released more than 3 years ago :-),
>> but I guess you meant 4.17-rc1.
>
> Yeah, I realize that I was a bit lost in time yesterday. Even more
> people have been having fun about it (me too). :-)
I occasionally still type 2.6.17 when I mean 4.17.
Arnd
^ permalink raw reply
* Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps
From: Ulf Hansson @ 2018-04-05 6:29 UTC (permalink / raw)
To: Boris Brezillon
Cc: alsa-devel, Takashi Iwai, linux-ide, netdev, linux-mtd,
Robert Jarzmik, driverdevel, Boris Brezillon, Vinod Koul,
Richard Weinberger, Marek Vasut, Ezequiel Garcia, linux-media,
Samuel Ortiz, Arnd Bergmann, Bartlomiej Zolnierkiewicz,
Haojian Zhuang, dmaengine, Mark Brown, Jaroslav Kysela,
Mauro Carvalho Chehab, Linux ARM, Nicolas Pitre,
Greg Kroah-Hartman <gregk
In-Reply-To: <20180404215623.2bf07406@bbrezillon>
On 4 April 2018 at 21:56, Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> On Wed, 04 Apr 2018 21:49:26 +0200
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On 2 April 2018 at 16:26, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> >> Hi,
>> >>
>> >> This serie is aimed at removing the dmaengine slave compat use, and transfer
>> >> knowledge of the DMA requestors into architecture code.
>> >> As this looks like a patch bomb, each maintainer expressing for his tree either
>> >> an Ack or "I want to take through my tree" will be spared in the next iterations
>> >> of this serie.
>> >
>> > Perhaps an option is to send this hole series as PR for 3.17 rc1, that
>> > would removed some churns and make this faster/easier? Well, if you
>> > receive the needed acks of course.
>> For 3.17-rc1 it looks a bit optimistic with the review time ... If I have all
>
> Especially since 3.17-rc1 has been released more than 3 years ago :-),
> but I guess you meant 4.17-rc1.
Yeah, I realize that I was a bit lost in time yesterday. Even more
people have been having fun about it (me too). :-)
Kind regards
Uffe
^ permalink raw reply
* [PATCH ethtool] ethtool: Add register dump support for MICROCHIP LAN78xx
From: Raghuram Chary J @ 2018-04-05 6:11 UTC (permalink / raw)
To: davem; +Cc: netdev, unglinuxdriver, woojung.huh, raghuramchary.jallipalli
This patch adds support for Microchip's lan78xx families
of USB Ethernet controllers to ethtool's dump registers
command.
This patch is for use with the lan78xx driver.
Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
---
Makefile.am | 2 +-
ethtool.c | 1 +
internal.h | 4 +++
lan78xx.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 93 insertions(+), 1 deletion(-)
create mode 100644 lan78xx.c
diff --git a/Makefile.am b/Makefile.am
index edbda57..14f79b6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,7 @@ ethtool_SOURCES += \
pcnet32.c realtek.c tg3.c marvell.c vioc.c \
smsc911x.c at76c50x-usb.c sfc.c stmmac.c \
sff-common.c sff-common.h sfpid.c sfpdiag.c \
- ixgbevf.c tse.c vmxnet3.c qsfp.c qsfp.h fjes.c
+ ixgbevf.c tse.c vmxnet3.c qsfp.c qsfp.h fjes.c lan78xx.c
endif
TESTS = test-cmdline test-features
diff --git a/ethtool.c b/ethtool.c
index da7421c..3494402 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1160,6 +1160,7 @@ static const struct {
{ "altera_tse", altera_tse_dump_regs },
{ "vmxnet3", vmxnet3_dump_regs },
{ "fjes", fjes_dump_regs },
+ { "lan78xx", lan78xx_dump_regs },
#endif
};
diff --git a/internal.h b/internal.h
index 913f4eb..b239dc7 100644
--- a/internal.h
+++ b/internal.h
@@ -350,4 +350,8 @@ void sff8636_show_all(const __u8 *id, __u32 eeprom_len);
/* FUJITSU Extended Socket network device */
int fjes_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
+/* MICROCHIP LAN78XX USB ETHERNET Controller */
+int lan78xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
#endif /* ETHTOOL_INTERNAL_H__ */
diff --git a/lan78xx.c b/lan78xx.c
new file mode 100644
index 0000000..bb64e80
--- /dev/null
+++ b/lan78xx.c
@@ -0,0 +1,87 @@
+#include <stdio.h>
+#include <string.h>
+#include "internal.h"
+
+int lan78xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ unsigned int *lan78xx_reg = (unsigned int *)regs->data;
+
+ fprintf(stdout, "LAN78xx Registers:\n");
+ fprintf(stdout, "------------------\n");
+ fprintf(stdout, "ID_REV = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "INT_STS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "HW_CFG = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "PMT_CTRL = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "E2P_CMD = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "E2P_DATA = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "USB_STATUS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "VLAN_TYPE = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "MAC Registers:\n");
+ fprintf(stdout, "--------------\n");
+ fprintf(stdout, "MAC_CR = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MAC_RX = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MAC_TX = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "FLOW = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "ERR_STS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MII_ACC = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MII_DATA = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TX_LPI_REQ_DLY = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TW_TX_SYS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TX_LPI_REM_DLY = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "WUCSR = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "PHY Registers:\n");
+ fprintf(stdout, "--------------\n");
+ fprintf(stdout, "Mode Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Mode Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Device identifier1 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Device identifier2 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Advertisement = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Link Partner Ability = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Expansion = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Next Page TX = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Link Partner Next Page RX = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "MMD Access Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "MMD Access Address/Data = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status Extension1 = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-TX Status Extension = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status Extension2 = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Bypass Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout,
+ "100BASE-TX/1000BASE-T Rx Error Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout,
+ "100BASE-TX/1000BASE-T FC Err Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout,
+ "10BASE-T/100BASE-TX/1000BASE-T LD Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Extended 10BASE-T Control and Status = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Extended PHY Control1 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Extended PHY Control2 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Interrupt Mask = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Interrupt Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auxiliary Control and Status = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "LED Mode Select = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "LED Behavior = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Extended Page Access = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ return 0;
+}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 09/11] devlink: convert occ_get op to separate registration
From: Jiri Pirko @ 2018-04-05 5:36 UTC (permalink / raw)
To: David Ahern
Cc: Jakub Kicinski, Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <addb04b3-b63d-6675-f3a6-3fb8969eb980@gmail.com>
Thu, Apr 05, 2018 at 01:00:18AM CEST, dsahern@gmail.com wrote:
>On 4/4/18 4:59 PM, Jakub Kicinski wrote:
>> On Wed, 4 Apr 2018 08:25:11 +0200, Jiri Pirko wrote:
>>>> Jiri, I am not aware of any other API where a driver registers with it
>>>> yet doesn't want the handler to be called so either waits to register
>>>
>>> Again, the thing is, this is kind of unusual because of the reload
>>> thing.
>>
>> FWIW my knee jerk thought is that it's strange that devlink ops can
>> be executed at all while reload is happening (incl. another reload
>> request). I'm probably missing the real issue..
>>
>
>Just responding with the same question ...
>
>Why are you not unregistering resources on a reload?
Because you need the use the values of course!
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Alexei Starovoitov @ 2018-04-05 5:28 UTC (permalink / raw)
To: Edward Cree; +Cc: Daniel Borkmann, netdev
In-Reply-To: <3484e40e-57a7-e7c6-520d-b9ca795616e2@solarflare.com>
On Thu, Apr 05, 2018 at 12:58:46AM +0100, Edward Cree wrote:
> On 04/04/18 00:37, Alexei Starovoitov wrote:
> > hmm. that doesn't fail for me and any other bots didn't complain.
> > Are you sure you're running the latest kernel and tests?
> Ah, test_progs isn't actually rebuilding because __NR_bpf is undeclared;
> something must be going wrong with header files.
> Never mind.
>
> > hmm. what's wrong with bsearch? It's trivial and fast.
> bsearch is O(log n), and the sort() call on the subprog_starts (which happens
> every time add_subprog() is called) is O(n log n).
> Whereas reading aux->subprogno is O(1).
> As far as I'm concerned, that's a sign that the latter data structure is the
> appropriate one.
only if it can be done as separate _first_ pass before cfg.
> > Even if we don't see the solution today we have to work towards it.
> I guess I'm just not confident "towards" is the direction you think it is.
>
> > Compiler designers could have combined multiple of such passes into
> > fewer ones, but it's not done, because it increases complexity and
> > causes tough bugs where pass is partially complete.
> I'm not trying to combine together multiple 'for bb in prog/for insn in bb'-
> type passes. The combining I was doing was more on 'for all possible
> execution paths'-type passes, because it's those that explode combinatorially.
> Happily I think we can go a long way towards getting rid of them; but while I
> think we can get down to only having 1, I don't think we can reach 0.
we have to. That's the point. 'explore all possible paths' must be removed.
New code should not be relying on that in a way that it's difficult to remove
later. subprog boundaries is a typical example where doing it as
part of 'explore all paths' is harmful long term. Regardless of extra
O(num_of_subrogs) complexity it brings short term.
> > The prime example where more than 4k instructions and loops are mandatory
> > is user space stack analysis inside the program. Like walking python stack
> > requires non-trival pointer chasing. With 'pragma unroll' the stack depth
> > limit today is ~18. That's not really usable. Looping through 100 python
> > frames would require about 16k bpf assembler instructions.
> But this would be solved by having support for bounded loops, and I think I've
> successfully shown that this is not inherently incompatible with a do_check()
> style walk.
No. It's worse. Your proposed approach to bounded loops completely
relying on 'explore all paths' whereas John's does not.
Can 'explore all paths' work with 1M bpf insns? No.
Whereas an approach that builds dom graph, detects natural loops
and loop invariants - can.
> > Hence do_check approach must go. The rough idea is to compute per basic
> > block a set of INs (registers and stack) that basic block needs
> > to see to be safe and corresponding set of OUTs.
> > Then propagate this knowledge across cfg edges.
> > Once we have such set per bpf function, it will essentially answer the question
> > 'what arguments this function needs to see to be safe and what it returns'
> > To make bpf libraries scale we'd need to keep such information
> > around after the verification, so dynamic linking and indirect calls
> > are fast to verify.
> > It's very high level obviously. There are many gotchas to resolve.
> I agree that if we can do this it'll be ideal. But that's a big 'if'; my
> example code was intended to demonstrate that the "set of INs bb/func needs to
> see to be safe" can be an arbitrarily complicated disjunction, and that instead
> of a combinatorially exploding number of paths to walk (the do_check() approach)
> you now have combinatorially exploding IN-constraints to propagate backwards.
This sounds like arbitrary assumptions what this new approach would do.
Instead of rejecting it outright try to solve this very hard problem.
Before this discussion gets carried away too far let's get back to this patch set.
Having seen all arguments I still think that only patch 3 is worth pursuing further.
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF action
From: Alexei Starovoitov @ 2018-04-05 5:10 UTC (permalink / raw)
To: Mathieu Xhonneux
Cc: David Lebrun, Network Development, David Lebrun, Daniel Borkmann
On Wed, Apr 4, 2018 at 2:34 AM, Mathieu Xhonneux <m.xhonneux@gmail.com> wrote:
> 2018-04-03 16:25 GMT+02:00 David Lebrun <dav.lebrun@gmail.com>:
>> Actually I'm wrong here. dst_input() will call either ip6_input() or
>> ip6_forward(), not ipv6_rcv(). Both functions expect IP6CB() to be set,
>> so using skb->cb here will interfere with them.
>>
>> What about saving and restoring the IPv6 CB, similarly to what TCP does with
>> tcp_v6_restore_cb() ?
>
>
> Yes. I can change the call to bpf_prog_run_save_cb to bpf_prog_run_clear_cb,
> and then manually save/restore the IPv6 CB in input_action_end_bpf.
>
> Or is there maybe a better solution to share some state between the bpf caller
> and helpers, that does not need access to skb->cb ?
I think per-cpu scratch buffer approach can work for this
situation. Similar to one used by do_redirect and sockmap.
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Stuart Yoder @ 2018-04-05 4:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Arnd Bergmann, Ioana Ciornei, gregkh, Laurentiu Tudor,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <20180404124246.GA20869@lunn.ch>
On Wed, Apr 4, 2018 at 7:42 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> I hear you. It is more complicated this way...having all these individual
>> objects vs just a single "bundle" of them that represents a NIC. But, that's
>> the way the DPAA2 hardware is, and we're implementing kernel support for
>> the hardware as it is.
>
> Hi Stuart
>
> I see we are not making any progress here.
>
> So what i suggest is you post the kernel code and configuration tool
> concept to netdev for a full review. You want reviews from David
> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
I know Ioana has other feedback she is addressing so a respin will be coming
soon, and she can include those additional reviewers.
Thanks,
Stuart
^ permalink raw reply
* Re: [PATCH net-next] vxlan: add ttl inherit support
From: Hangbin Liu @ 2018-04-05 3:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20180404.120339.1405395328329628050.davem@davemloft.net>
On Wed, Apr 04, 2018 at 12:03:39PM -0400, David Miller wrote:
> The net-next tree is closed, please resubmit this when the net-next tree opens
> back up.
Sorry, I didn't pay much attention on the net-next open/close cycle before.
After re-read netdev-FAQ.txt. Now I understand the steps and I need send
net-next patch after rc1 released.
Sorry to bother you again...
Regards
Hangbin
^ permalink raw reply
* marvell switch
From: Ran Shalit @ 2018-04-05 2:47 UTC (permalink / raw)
To: netdev
Hello,
I am trying to use marvell switch in linux,
Is it that the kernel drivers from marvell switch are used just to
enable all ports, or do they also provide APIs to userspace to enable
specific ports only.
I have not find examples or wiki for marvell switch, so I am not too
sure as what are the drivers meant for.
Thank you,
ranran
^ permalink raw reply
* Re: [PATCH net] net: dsa: Discard frames from unused ports
From: Andrew Lunn @ 2018-04-05 2:17 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <ac81103a-97f4-c7ae-3f12-c78e617f4edc@gmail.com>
On Wed, Apr 04, 2018 at 05:49:10PM -0700, Florian Fainelli wrote:
> On 04/04/2018 04:56 PM, Andrew Lunn wrote:
> > The Marvell switches under some conditions will pass a frame to the
> > host with the port being the CPU port. Such frames are invalid, and
> > should be dropped. Not dropping them can result in a crash when
> > incrementing the receive statistics for an invalid port.
> >
> > Reported-by: Chris Healy <cphealy@gmail.com>
> > Fixes: 5f6b4e14cada ("net: dsa: User per-cpu 64-bit statistics")
>
> Are you sure this is the commit that introduced the problem?
Hi Florian
Well, the problem is it crashes when trying to update the
statistics. The CPU port is not allocated a p->stats64, only slave
ports get those. So before this patch, there was no crash and the
frame would be delivered to the master interface. This in itself is
probably not correct, but also not fatal. Talking to Chris, it seems
this behaviour has existing for a long while. I needed to use lldpd to
trigger the issue, because i assume the Marvell switch sees these as
special frames and forwards them to the CPU. The other thing is, the
code got refactored recently. So this fix will not rebase to too many
earlier versions. It needs a fix per tagging protocol for before the
common dsa_master_find_slave() was added.
> > - return ds->ports[port].slave;
> > + slave_port = &ds->ports[port];
> > +
> > + if (slave_port->type != DSA_PORT_TYPE_USER)
>
> Can we optimize this with an unlikely()?
Yes, that would make sense.
Andrew
^ permalink raw reply
* Re: [rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver
From: Pkshih @ 2018-04-05 2:06 UTC (permalink / raw)
To: 莊彥宣, kvalo@codeaurora.org,
gustavo@embeddedor.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180405012540.GA24241@embeddedor.com>
On Thu, 2018-04-05 at 01:25 +0000, Gustavo A. R. Silva wrote:
> Hi all,
>
> While doing some static analysis I came across the following piece of code at
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1581:
>
> 1581 static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist *btcoexist,
> 1582 u8 wifi_status)
> 1583 {
> 1584 /* tdma and coex table */
> 1585 btc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
> 1586
> 1587 if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
> 1588 wifi_status)
> 1589 btc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
> 1590 else
> 1591 btc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
> 1592 }
>
> The issue here is that the code for both branches of the if-else statement is identical.
>
> The if-else was introduced a year ago in this commit c6821613e653
>
> I wonder if an argument should be changed in any of the calls to
> btc8821a1ant_coex_table_with_type?
>
>
It looks weird. Since we're in spring vacation, I'll check my colleague next Monday.
PK
^ permalink raw reply
* [PULL] fwcfg, vhost: features and fixes
From: Michael S. Tsirkin @ 2018-04-05 1:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: kvm, virtualization, netdev, linux-kernel, bhe, dyoung,
marcandre.lureau, mst, somlo, sonnyrao
The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:
Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to dc32bb678e103afbcfa4d814489af0566307f528:
vhost: add vsock compat ioctl (2018-03-20 03:17:42 +0200)
----------------------------------------------------------------
fw_cfg, vhost: features fixes
This cleans up the qemu fw cfg device driver.
On top of this, vmcore is dumped there on crash to
help debugging witH kASLR enabled.
Also included are some fixes in vhost.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Marc-André Lureau (10):
fw_cfg: fix sparse warnings in fw_cfg_sel_endianness()
fw_cfg: fix sparse warnings with fw_cfg_file
fw_cfg: fix sparse warning reading FW_CFG_ID
fw_cfg: fix sparse warnings around FW_CFG_FILE_DIR read
fw_cfg: remove inline from fw_cfg_read_blob()
fw_cfg: handle fw_cfg_read_blob() error
fw_cfg: add a public uapi header
fw_cfg: add DMA register
crash: export paddr_vmcoreinfo_note()
fw_cfg: write vmcoreinfo details
Michael S. Tsirkin (1):
ptr_ring: fix build
Sonny Rao (2):
vhost: fix vhost ioctl signature to build with clang
vhost: add vsock compat ioctl
MAINTAINERS | 1 +
drivers/firmware/qemu_fw_cfg.c | 291 +++++++++++++++++++++++++++++++--------
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 4 +-
drivers/vhost/vsock.c | 11 ++
include/uapi/linux/qemu_fw_cfg.h | 97 +++++++++++++
kernel/crash_core.c | 1 +
tools/virtio/ringtest/ptr_ring.c | 5 +
8 files changed, 348 insertions(+), 64 deletions(-)
create mode 100644 include/uapi/linux/qemu_fw_cfg.h
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-04-05 1:47 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180329210751.11531-9-vinicius.gomes@intel.com>
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Thursday, March 29, 2018 2:08 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
> address support for ethtool nftuple filters
>
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
>
> In practical terms this adds support for the following use cases,
> characterized by these examples:
>
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
This is now working for me, testing with the dst MAC being the MAC on the i210. I set the filter and all the traffic to the destination MAC address gets routed to the chosen RX queue.
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)
However, I am still not getting the raw ethernet source filter to work. Even back to back with no other system to "confuse" the stream, I set the filter so the source MAC is the same as the MAC on the link partner, send traffic and the traffic bounces around the queues as if the filter is not set.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> ++++++++++++++++++++++++----
> 1 file changed, 31 insertions(+), 4 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox