* Re: [Patch net-next] net_sched: only create filter chains for new filters/actions
From: Cong Wang @ 2017-05-26 16:55 UTC (permalink / raw)
To: David Miller
Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko
In-Reply-To: <20170526.105443.1489276661727770629.davem@davemloft.net>
On Fri, May 26, 2017 at 7:54 AM, David Miller <davem@davemloft.net> wrote:
> And I also didn't find the boolean logic hard to understand at all.
>
> It is in fact a very common pattern to pass a "create" boolean into
> lookup functions, to tell them whether to create a new object on
> lookup failure or not. And then also to control that boolean via
> what kind of netlink request we are processing.
+10
It is a widely used pattern among the kernel source code.
I'd be surprised if an experienced kernel developer is not
aware of this pattern. ;)
^ permalink raw reply
* Re: [for-next 5/6] net/mlx5: Bump driver version
From: Dennis Dalessandro @ 2017-05-26 16:55 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, David S. Miller, Doug Ledford, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Ilan Tayari, Tariq Toukan
In-Reply-To: <CALzJLG_ha-XiPAMnoKrUgm_EwPx2yH0T2y4EBRfrWNYSZi1cTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 5/26/2017 12:35 PM, Saeed Mahameed wrote:
> On Fri, May 26, 2017 at 3:56 PM, Dennis Dalessandro
> <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
>>>
>>> From: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>
>>> Remove date and bump version for mlx5_core driver.
>>>
>>> Signed-off-by: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>
>>
>> So I just complained about the bnxt_re doing this. I guess I need to raise a
>> flag here too. Now to be clear I'm not against doing this version stuff. I'm
>> against using it for some internal tracking that is meaningless to the
>> kernel community.
>>
>> There is no detail in your commit message as to what this driver version is
>> used for. Can you please explain how your use of driver version is valid
>> while theirs is not?
>>
>
> Hi Denny,
>
> We don't use this for internal or any kind of tracking at all, if you
> look at the driver change log, we hardly touch the version if at all !
>
> but since we decided to remove the date since it is very misleading
> and we got some complaints that some think they have an old driver
> just because of the date, also we bumped the version so it would align
> with our drivers external package (OFED).
To me that's not a reason to include something in the kernel. At least
your external package is something that is available and not an internal
development process, but still probably no interest to anyone in the kernel.
> Anyway i don't think we are going to change this frequently or even use it.
> But if you are that much against touching this ethtool field, why
> don't you just jump into the mud and remove it from the tree, I
> imagine it is really hard for you to watch for patches doing this and
> nack them on the list.
I have no interest in policing that. I complained about the other driver
because I know patches like that were NAKed by Greg KH in the past
(ours). I'd rather not see the rdma subsystem keep making the same
mistakes is all. We want to improve our standing in the community after
all. As I said I'm not personally against it as evidenced by our driver.
>> I realize Dave has already pulled this and I'm not asking for it to be
>> reverted but maybe some discussion will help guide future patch submissions
>> which do this stuff.
>>
>
> Sure, although i don't think we are going to use those version fields
> in the future,
> please allow me to ask, how do you do your driver versioning ? how do
> you track things ?
> and what is your future vision regarding ethool->drv_version ?
That's just the thing, we don't do anything with it either really. I'm
trying to justify its existence to myself and if you folks had some whiz
bang idea for a driver version I was interested in hearing what it was.
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: A bug report for Linux TCP congestion control algorithms
From: Yuchung Cheng @ 2017-05-26 16:51 UTC (permalink / raw)
To: Wei Sun; +Cc: netdev
In-Reply-To: <CAMN46fP_a_Jti_rcLze=7yoaDroQ7qn8kek9HMKtFEQpbm7R3A@mail.gmail.com>
On Thu, May 25, 2017 at 11:08 PM, Wei Sun <wsun@cse.unl.edu> wrote:
>
> Hi there,
>
> we find a special case for Linux TCP undo operations where
> tp->snd_cwnd could be extremely large (e.g., 4294967294) by two
> consecutive cwnd undo operations when using
> reno/veno/vegas/highspeed/HTCP/yeah/westwood/hybla/illinois/scalable/lp
> congestion control algorithms in the latest long-term kernel 4.9.
>
> e.g., a simple trace for sender-side tcp state variables
> cwnd ssthresh ca_state
> 10 2147483647 0
> 10 2147483647 0
> 1 5 4
> 11 2147483647 4 first
> undo operation
> 4294967294 2147483647 0 second undo operation
> 4294967294 2147483647 0
>
>
> By debugging the code, we find that the second undo operation was
> triggered by F-RTO mechanism without checking current tp->undo_marker.
>
> The case should be existing for all kernel versions depending on F-RTO
> internals (i.e., this bug exists for kernels 4.10 and earlier)
Thanks for discovering that. Note this issue is addressed by
commit 89fe18e44f7ee5ab1c90d0dff5835acee7751427
Author: Yuchung Cheng <ycheng@google.com>
Date: Thu Jan 12 22:11:37 2017 -0800
tcp: extend F-RTO to catch more spurious timeouts
>
>
> Just Let you know in case of some vulnerabilities as it is not hard to
> trigger this specific case.
>
> Attached is a simple Google's packetdrill script to trigger it and a
> possible patch to fix it. Thanks
^ permalink raw reply
* Re: [PATCH] mwifiex: simplify the code around ra_list
From: Brian Norris @ 2017-05-26 16:46 UTC (permalink / raw)
To: Shawn Lin
Cc: Amitkumar Karwar, Kalle Valo, Xinming Hu,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1495762909-46795-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Fri, May 26, 2017 at 09:41:49AM +0800, Shawn Lin wrote:
> We don't need to check if the list is empty separately
> as we could use list_first_entry_or_null to cover it.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Looks fine to me.
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
^ permalink raw reply
* Re: [for-next 5/6] net/mlx5: Bump driver version
From: Saeed Mahameed @ 2017-05-26 16:35 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: Saeed Mahameed, David S. Miller, Doug Ledford, Linux Netdev List,
linux-rdma, Ilan Tayari, Tariq Toukan
In-Reply-To: <3733699c-480b-a1aa-14e1-4f27f86cfead@intel.com>
On Fri, May 26, 2017 at 3:56 PM, Dennis Dalessandro
<dennis.dalessandro@intel.com> wrote:
> On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
>>
>> From: Tariq Toukan <tariqt@mellanox.com>
>>
>> Remove date and bump version for mlx5_core driver.
>>
>> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>
>
> So I just complained about the bnxt_re doing this. I guess I need to raise a
> flag here too. Now to be clear I'm not against doing this version stuff. I'm
> against using it for some internal tracking that is meaningless to the
> kernel community.
>
> There is no detail in your commit message as to what this driver version is
> used for. Can you please explain how your use of driver version is valid
> while theirs is not?
>
Hi Denny,
We don't use this for internal or any kind of tracking at all, if you
look at the driver change log, we hardly touch the version if at all !
but since we decided to remove the date since it is very misleading
and we got some complaints that some think they have an old driver
just because of the date, also we bumped the version so it would align
with our drivers external package (OFED).
Anyway i don't think we are going to change this frequently or even use it.
But if you are that much against touching this ethtool field, why
don't you just jump into the mud and remove it from the tree, I
imagine it is really hard for you to watch for patches doing this and
nack them on the list.
> I realize Dave has already pulled this and I'm not asking for it to be
> reverted but maybe some discussion will help guide future patch submissions
> which do this stuff.
>
Sure, although i don't think we are going to use those version fields
in the future,
please allow me to ask, how do you do your driver versioning ? how do
you track things ?
and what is your future vision regarding ethool->drv_version ?
Thanks,
Saeed.
> -Denny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next v3] ibmvnic: Enable TSO support
From: Thomas Falcon @ 2017-05-26 16:15 UTC (permalink / raw)
To: netdev; +Cc: davem, Thomas Falcon, Nathan Fontenot, John Allen
Enable TSO in the ibmvnic driver. Scatter-gather is also enabled,
though there currently is no support for scatter-gather in
vNIC-compatible hardware, resulting in forced linearization
of all fragmented SKB's. Though not ideal, given the throughput
improvement gained by enabling TSO, it has been decided
that this is an acceptable tradeoff.
The feature is also enabled by a module parameter.
This parameter is necessary because TSO can not easily be
enabled or disabled in firmware without reinitializing the driver.
CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
CC: John Allen <jallen@linux.vnet.ibm.com>
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
v3: Remove module parameter, TSO will be set through ethtool
include ibmvnic_fix_features to manage scatter-gather
v2: Fix kbuild robot warning from module parameter init
---
drivers/net/ethernet/ibm/ibmvnic.c | 42 +++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index abe2b6e..b1f4a95 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -149,6 +149,20 @@ struct ibmvnic_stat {
{"internal_mac_rx_errors", IBMVNIC_STAT_OFF(internal_mac_rx_errors)},
};
+static netdev_features_t ibmvnic_fix_features(struct net_device *dev,
+ netdev_features_t features)
+{
+ /* Scatter-gather is not currently supported by firmware.
+ * It will only be enabled to support TSO operations.
+ */
+ if (!(features & (NETIF_F_TSO | NETIF_F_TSO6)))
+ features &= ~NETIF_F_SG;
+ else
+ features |= NETIF_F_SG;
+
+ return features;
+}
+
static long h_reg_sub_crq(unsigned long unit_address, unsigned long token,
unsigned long length, unsigned long *number,
unsigned long *irq)
@@ -1025,6 +1039,17 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev)
goto out;
}
+ /* All scatter-gather SKB's will be linearized for the time being, but
+ * scatter-gather is only enabled if the user wishes to use TSO.
+ */
+ if (skb_shinfo(skb)->nr_frags && __skb_linearize(skb)) {
+ dev_kfree_skb_any(skb);
+ tx_send_failed++;
+ tx_dropped++;
+ ret = NETDEV_TX_OK;
+ goto out;
+ }
+
tx_pool = &adapter->tx_pool[queue_num];
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, skb_get_queue_mapping(skb));
@@ -1082,6 +1107,11 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev)
tx_crq.v1.flags1 |= IBMVNIC_TX_CHKSUM_OFFLOAD;
hdrs += 2;
}
+ if (skb_is_gso(skb)) {
+ tx_crq.v1.flags1 |= IBMVNIC_TX_LSO;
+ tx_crq.v1.mss = cpu_to_be16(skb_shinfo(skb)->gso_size);
+ hdrs += 2;
+ }
/* determine if l2/3/4 headers are sent to firmware */
if ((*hdrs >> 7) & 1 &&
(skb->protocol == htons(ETH_P_IP) ||
@@ -1520,6 +1550,7 @@ static void ibmvnic_netpoll_controller(struct net_device *dev)
.ndo_set_mac_address = ibmvnic_set_mac,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = ibmvnic_tx_timeout,
+ .ndo_fix_features = ibmvnic_fix_features,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = ibmvnic_netpoll_controller,
#endif
@@ -2629,10 +2660,10 @@ static void handle_query_ip_offload_rsp(struct ibmvnic_adapter *adapter)
adapter->ip_offload_ctrl.udp_ipv4_chksum = buf->udp_ipv4_chksum;
adapter->ip_offload_ctrl.tcp_ipv6_chksum = buf->tcp_ipv6_chksum;
adapter->ip_offload_ctrl.udp_ipv6_chksum = buf->udp_ipv6_chksum;
+ adapter->ip_offload_ctrl.large_tx_ipv4 = buf->large_tx_ipv4;
+ adapter->ip_offload_ctrl.large_tx_ipv6 = buf->large_tx_ipv6;
- /* large_tx/rx disabled for now, additional features needed */
- adapter->ip_offload_ctrl.large_tx_ipv4 = 0;
- adapter->ip_offload_ctrl.large_tx_ipv6 = 0;
+ /* large_rx disabled for now, additional features needed */
adapter->ip_offload_ctrl.large_rx_ipv4 = 0;
adapter->ip_offload_ctrl.large_rx_ipv6 = 0;
@@ -2648,6 +2679,11 @@ static void handle_query_ip_offload_rsp(struct ibmvnic_adapter *adapter)
(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM)))
adapter->netdev->features |= NETIF_F_RXCSUM;
+ if (buf->large_tx_ipv4)
+ adapter->netdev->hw_features |= NETIF_F_TSO;
+ if (buf->large_tx_ipv6)
+ adapter->netdev->hw_features |= NETIF_F_TSO6;
+
memset(&crq, 0, sizeof(crq));
crq.control_ip_offload.first = IBMVNIC_CRQ_CMD;
crq.control_ip_offload.cmd = CONTROL_IP_OFFLOAD;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] ibmvnic: Enable TSO support
From: Thomas Falcon @ 2017-05-26 16:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nfont, jallen
In-Reply-To: <20170525.144935.732861960034229990.davem@davemloft.net>
On 05/25/2017 01:49 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 25 May 2017 14:46:26 -0400 (EDT)
>
>> From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
>> Date: Wed, 24 May 2017 21:29:26 -0500
>>
>>> The feature is also enabled by a module parameter.
>>> This parameter is necessary because TSO can not easily be
>>> enabled or disabled in firmware without reinitializing the driver.
>> Sorry, this is unacceptable. When I say no module parameters,
>> I really really mean it.
>>
>> Users should not be burdoned with having to know a special knob for
>> every driver in order to adjust what is a generic feature.
>>
>> You'll have to find another way to accomodate this.
> Also, TSO helps without SG only because you haven't implemented
> support for xmit_more in this driver to decrease the number of
> doorball updates and VM enters.
>
> I bet if you added xmit_more support, TSO wouldn't give you much
> if any performance boost if you have to linearize.
>
Thanks for the feedback. I'm looking into providing that support, but for the time being we would like to continue with supporting TSO, without using a module parameter this time.
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: David Daney @ 2017-05-26 16:10 UTC (permalink / raw)
To: Alexei Starovoitov, David Daney
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-kernel,
linux-mips, ralf, Markos Chandras
In-Reply-To: <20170526022300.c4gtxhqt3tyiukz2@ast-mbp>
On 05/25/2017 07:23 PM, Alexei Starovoitov wrote:
> On Thu, May 25, 2017 at 05:38:26PM -0700, David Daney wrote:
>> Since the eBPF machine has 64-bit registers, we only support this in
>> 64-bit kernels. As of the writing of this commit log test-bpf is showing:
>>
>> test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
>>
>> All current test cases are successfully compiled.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>> ---
>> arch/mips/Kconfig | 1 +
>> arch/mips/net/bpf_jit.c | 1627 ++++++++++++++++++++++++++++++++++++++++++++++-
>> arch/mips/net/bpf_jit.h | 7 +
>> 3 files changed, 1633 insertions(+), 2 deletions(-)
>
> Great stuff. I wonder what is the performance difference
> interpreter vs JIT
It depends if we are calling library code:
/proc/sys/net/core # echo 0 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=275
test_bpf: #275 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 131733 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [0/1 JIT'ed]
/proc/sys/net/core # rmmod test-bpf
/proc/sys/net/core # echo 1 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=275
test_bpf: #275 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:1 85453 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [1/1 JIT'ed]
About 1.5X faster.
Or doing atomic operations:
/proc/sys/net/core # rmmod test-bpf
/proc/sys/net/core # echo 0 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=229
test_bpf: #229 STX_XADD_DW: X + 1 + 1 + 1 + ... jited:0 209020 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [0/1 JIT'ed]
/proc/sys/net/core # rmmod test-bpf
/proc/sys/net/core # echo 1 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=229
test_bpf: #229 STX_XADD_DW: X + 1 + 1 + 1 + ... jited:1 158004 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [1/1 JIT'ed]
About 1.3X faster, probably limited by coherent memory system more than
code quality.
Simple register operations not touching memory are best:
/proc/sys/net/core # rmmod test-bpf
/proc/sys/net/core # echo 0 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=38
test_bpf: #38 INT: ADD 64-bit jited:0 1819 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [0/1 JIT'ed]
/proc/sys/net/core # rmmod test-bpf
/proc/sys/net/core # echo 1 > bpf_jit_enable
/proc/sys/net/core # modprobe test-bpf test_id=38
test_bpf: #38 INT: ADD 64-bit jited:1 83 PASS
test_bpf: Summary: 1 PASSED, 0 FAILED, [1/1 JIT'ed]
This one is fairly good. 21X faster.
>
>> + * eBPF stack frame will be something like:
>> + *
>> + * Entry $sp ------> +--------------------------------+
>> + * | $ra (optional) |
>> + * +--------------------------------+
>> + * | $s0 (optional) |
>> + * +--------------------------------+
>> + * | $s1 (optional) |
>> + * +--------------------------------+
>> + * | $s2 (optional) |
>> + * +--------------------------------+
>> + * | $s3 (optional) |
>> + * +--------------------------------+
>> + * | tmp-storage (if $ra saved) |
>> + * $sp + tmp_offset --> +--------------------------------+ <--BPF_REG_10
>> + * | BPF_REG_10 relative storage |
>> + * | MAX_BPF_STACK (optional) |
>> + * | . |
>> + * | . |
>> + * | . |
>> + * $sp --------> +--------------------------------+
>> + *
>> + * If BPF_REG_10 is never referenced, then the MAX_BPF_STACK sized
>> + * area is not allocated.
>> + */
>
> It's especially great to see that you've put the tmp storage
> above program stack and made the stack allocation optional.
> At the moment I'm working on reducing bpf program stack size,
> so that JIT and interpreter can use only the stack they need.
> Looking at this JIT code only minimal changes will be needed.
>
I originally recorded the minimum and maximum offsets from BPF_REG_10
seen, and generated a minimally sized stack frame. Then I see things like:
{
"STX_XADD_DW: Test side-effects, r10: 0x12 + 0x10 = 0x22",
.u.insns_int = {
BPF_ALU64_REG(BPF_MOV, R1, R10),
BPF_ALU32_IMM(BPF_MOV, R0, 0x12),
BPF_ST_MEM(BPF_DW, R10, -40, 0x10),
BPF_STX_XADD(BPF_DW, R10, R0, -40),
BPF_ALU64_REG(BPF_MOV, R0, R10),
BPF_ALU64_REG(BPF_SUB, R0, R1),
BPF_EXIT_INSN(),
},
INTERNAL,
{ },
{ { 0, 0 } },
},
Here we see that the value of BPF_REG_10 can escape, and be used for who
knows what, and we must assume the worst case.
I guess we could see if the BPF_REG_10 value ever escapes, and if it
doesn't, then use an optimally sized stack frame, and only fall back to
MAX_BPF_STACK if we cannot prove it is safe to do this.
^ permalink raw reply
* Dearest One.
From: Safiatou Ibrahim @ 2017-05-26 16:08 UTC (permalink / raw)
Dear Ma/Sir,
My Name is Miss Safiatou Ibrahim from Libya, I am 22 years old, I am
in St. Christopher's Parish for refugee in Burkina Faso under United
Nations High commission for Refugee ,I lost my parents in the recent
war in Libya, right now am in Burkina Faso, please save my life i am
in danger need your help in transferring my inheritance my father left
behind for me in a Bank in Burkina Faso here, I have every document
for the transfer, all i need is a foreigner who will stand as the
foreign partner to my father and beneficiary of the fund. The money
deposited in the Bank is US$10.500.000, (TEN MILLION FIVE HUNDRED
THOUSAND UNITED STATES DOLLAR)
I just need this fund to be transfer to your account so that i will
come over to your country and complete my education as you know that
my country have been in deep crisis due to the war .and I cannot go
back there again because I have nobody again all of my family were
killed in the war.
If you are interested to save me and help me receive my inheritance
fund Please get back to me for more details about me and the
inheritance funds.
Miss Safiatou Ibrahim.
^ permalink raw reply
* [PATCH v2 2/6] stmmac: pci: Use stmmac_pci_info for all devices
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
Make stmmac_default_data compatible with stmmac_pci_info.setup and use
an info structure for all devices. This allows to make the probing more
regular.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 33 +++++++++++++++---------
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 0efe42659a37..9aca14f8b55e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -100,7 +100,9 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static void stmmac_default_data(struct plat_stmmacenet_data *plat)
+static int stmmac_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
/* Set common default data first */
common_default_data(plat);
@@ -112,8 +114,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
plat->dma_cfg->pbl = 32;
plat->dma_cfg->pblx8 = true;
/* TODO: AXI */
+
+ return 0;
}
+static const struct stmmac_pci_info stmmac_pci_info = {
+ .setup = stmmac_default_data,
+};
+
static int quark_default_data(struct pci_dev *pdev,
struct plat_stmmacenet_data *plat,
const struct stmmac_pci_info *info)
@@ -236,14 +244,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- if (info) {
- if (info->setup) {
- ret = info->setup(pdev, plat, info);
- if (ret)
- return ret;
- }
- } else
- stmmac_default_data(plat);
+ ret = info->setup(pdev, plat, info);
+ if (ret)
+ return ret;
pci_enable_msi(pdev);
@@ -273,10 +276,16 @@ static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+ PCI_DEVICE(vendor_id, dev_id), \
+ .driver_data = (kernel_ulong_t)&info \
+ }
+
static const struct pci_device_id stmmac_id_table[] = {
- {PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID)},
- {PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC)},
- {PCI_VDEVICE(INTEL, STMMAC_QUARK_ID), (kernel_ulong_t)&quark_pci_info},
+ STMMAC_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID, stmmac_pci_info),
+ STMMAC_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC,
+ stmmac_pci_info),
+ STMMAC_DEVICE(PCI_VENDOR_ID_INTEL, STMMAC_QUARK_ID, quark_pci_info),
{}
};
--
2.12.0
^ permalink raw reply related
* [PATCH v2 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
By now, stmmac_pci_info only contains a single entry. Register this
directly with the PCI device table, removing one indirection.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 35 +++++++++---------------
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 061cb28f642d..485216369705 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -35,9 +35,7 @@ struct stmmac_pci_dmi_data {
int phy_addr;
};
-struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
-};
+typedef int (*stmmac_setup)(struct pci_dev *, struct plat_stmmacenet_data *);
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
const struct dmi_system_id *dmi_list)
@@ -87,8 +85,8 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int stmmac_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -104,10 +102,6 @@ static int stmmac_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info stmmac_pci_info = {
- .setup = stmmac_default_data,
-};
-
static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data[] = {
{
.func = 6,
@@ -160,8 +154,8 @@ static const struct dmi_system_id quark_pci_dmi[] = {
{}
};
-static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int quark_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -197,10 +191,6 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info quark_pci_info = {
- .setup = quark_default_data,
-};
-
/**
* stmmac_pci_probe
*
@@ -216,7 +206,7 @@ static const struct stmmac_pci_info quark_pci_info = {
static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- struct stmmac_pci_info *info = (struct stmmac_pci_info *)id->driver_data;
+ stmmac_setup setup = (stmmac_setup)id->driver_data;
struct plat_stmmacenet_data *plat;
struct stmmac_resources res;
int i;
@@ -257,7 +247,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- ret = info->setup(pdev, plat);
+ ret = setup(pdev, plat);
if (ret)
return ret;
@@ -289,16 +279,17 @@ static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
-#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+#define STMMAC_DEVICE(vendor_id, dev_id, setup) { \
PCI_DEVICE(vendor_id, dev_id), \
- .driver_data = (kernel_ulong_t)&info \
+ .driver_data = (kernel_ulong_t)&setup \
}
static const struct pci_device_id stmmac_id_table[] = {
- STMMAC_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID, stmmac_pci_info),
+ STMMAC_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID, stmmac_default_setup),
STMMAC_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC,
- stmmac_pci_info),
- STMMAC_DEVICE(PCI_VENDOR_ID_INTEL, STMMAC_QUARK_ID, quark_pci_info),
+ stmmac_default_setup),
+ STMMAC_DEVICE(PCI_VENDOR_ID_INTEL, STMMAC_QUARK_ID,
+ quark_default_setup),
{}
};
--
2.12.0
^ permalink raw reply related
* [PATCH v2 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++++++++++++++----------
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 07af42531fd4..061cb28f642d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -31,9 +31,7 @@
* with PHY.
*/
struct stmmac_pci_dmi_data {
- const char *name;
- const char *asset_tag;
- unsigned int func;
+ int func;
int phy_addr;
};
@@ -42,24 +40,19 @@ struct stmmac_pci_info {
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- struct stmmac_pci_dmi_data *dmi_data)
+ const struct dmi_system_id *dmi_list)
{
- const char *name = dmi_get_system_info(DMI_BOARD_NAME);
- const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(pdev->devfn);
- struct stmmac_pci_dmi_data *dmi;
+ const struct stmmac_pci_dmi_data *dmi_data;
+ const struct dmi_system_id *dmi_id;
+ int func = PCI_FUNC(pdev->devfn);
- if (!name)
+ dmi_id = dmi_first_match(dmi_list);
+ if (!dmi_id)
return -ENODEV;
- for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
- if (!strcmp(dmi->name, name) && dmi->func == func) {
- /* If asset tag is provided, match on it as well. */
- if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
- continue;
- return dmi->phy_addr;
- }
- }
+ for (dmi_data = dmi_id->driver_data; dmi_data->func >= 0; dmi_data++)
+ if (dmi_data->func == func)
+ return dmi_data->phy_addr;
return -ENODEV;
}
@@ -115,34 +108,54 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data[] = {
{
- .name = "Galileo",
.func = 6,
.phy_addr = 1,
},
+ {-1, -1},
+};
+
+static const struct stmmac_pci_dmi_data iot2040_stmmac_dmi_data[] = {
{
- .name = "GalileoGen2",
.func = 6,
.phy_addr = 1,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
+ .func = 7,
.phy_addr = 1,
},
+ {-1, -1},
+};
+
+static const struct dmi_system_id quark_pci_dmi[] = {
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Galileo"),
+ },
+ .driver_data = (void *)galileo_stmmac_dmi_data,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
+ },
+ .driver_data = (void *)galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-0YA2"),
+ },
+ .driver_data = (void *)galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-1YA2"),
+ },
+ .driver_data = (void *)iot2040_stmmac_dmi_data,
},
{}
};
@@ -159,7 +172,7 @@ static int quark_default_data(struct pci_dev *pdev,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi_data);
+ ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi);
if (ret < 0) {
/*
* Galileo boards with old firmware don't support DMI. We always
--
2.12.0
^ permalink raw reply related
* [PATCH v2 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
No need to carry this reference in stmmac_pci_info - the Quark-specific
setup handler knows that it needs to use the Quark-specific DMI table.
This also allows to drop the stmmac_pci_info reference from the setup
handler parameter list.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 83 +++++++++++-------------
1 file changed, 39 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 1a89fa9ee39d..07af42531fd4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,13 +38,11 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info);
- struct stmmac_pci_dmi_data *dmi;
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- const struct stmmac_pci_info *info)
+ struct stmmac_pci_dmi_data *dmi_data)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
@@ -54,7 +52,7 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
if (!name)
return -ENODEV;
- for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
+ for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
/* If asset tag is provided, match on it as well. */
if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
@@ -97,8 +95,7 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
}
static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -118,9 +115,40 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
+static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+ {
+ .name = "Galileo",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "GalileoGen2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-0YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 7,
+ .phy_addr = 1,
+ },
+ {}
+};
+
static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -131,7 +159,7 @@ static int quark_default_data(struct pci_dev *pdev,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(pdev, info);
+ ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi_data);
if (ret < 0) {
/*
* Galileo boards with old firmware don't support DMI. We always
@@ -156,41 +184,8 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
- {
- .name = "Galileo",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "GalileoGen2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
- },
- {}
-};
-
static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
- .dmi = quark_pci_dmi_data,
};
/**
@@ -249,7 +244,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- ret = info->setup(pdev, plat, info);
+ ret = info->setup(pdev, plat);
if (ret)
return ret;
--
2.12.0
^ permalink raw reply related
* [PATCH v2 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
Move the special case for the early Galileo firmware into
quark_default_setup. This allows to use stmmac_pci_find_phy_addr for
non-quark cases.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 9aca14f8b55e..1a89fa9ee39d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -51,12 +51,8 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
- /*
- * Galileo boards with old firmware don't support DMI. We always return
- * 1 here, so at least first found MAC controller would be probed.
- */
if (!name)
- return 1;
+ return -ENODEV;
for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
@@ -136,8 +132,17 @@ static int quark_default_data(struct pci_dev *pdev,
* does not connect to any PHY interface.
*/
ret = stmmac_pci_find_phy_addr(pdev, info);
- if (ret < 0)
- return ret;
+ if (ret < 0) {
+ /*
+ * Galileo boards with old firmware don't support DMI. We always
+ * use 1 here as PHY address, so at least the first found MAC
+ * controller would be probed.
+ */
+ if (!dmi_get_system_info(DMI_BOARD_NAME))
+ ret = 1;
+ else
+ return ret;
+ }
plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
plat->phy_addr = ret;
--
2.12.0
^ permalink raw reply related
* [PATCH v2 1/6] stmmac: pci: Make stmmac_pci_info structure constant
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1495814872.git.jan.kiszka@siemens.com>
By removing the PCI device reference from the structure and passing it
as parameters to the interested functions, we can make quark_pci_info
const.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 22f910795be4..0efe42659a37 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,17 +38,17 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- struct pci_dev *pdev;
- int (*setup)(struct plat_stmmacenet_data *plat,
- struct stmmac_pci_info *info);
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info);
struct stmmac_pci_dmi_data *dmi;
};
-static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
+static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
+ const struct stmmac_pci_info *info)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(info->pdev->devfn);
+ unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
/*
@@ -114,10 +114,10 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
/* TODO: AXI */
}
-static int quark_default_data(struct plat_stmmacenet_data *plat,
- struct stmmac_pci_info *info)
+static int quark_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
- struct pci_dev *pdev = info->pdev;
int ret;
/* Set common default data first */
@@ -127,7 +127,7 @@ static int quark_default_data(struct plat_stmmacenet_data *plat,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(info);
+ ret = stmmac_pci_find_phy_addr(pdev, info);
if (ret < 0)
return ret;
@@ -175,7 +175,7 @@ static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
{}
};
-static struct stmmac_pci_info quark_pci_info = {
+static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
.dmi = quark_pci_dmi_data,
};
@@ -237,9 +237,8 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
if (info) {
- info->pdev = pdev;
if (info->setup) {
- ret = info->setup(plat, info);
+ ret = info->setup(pdev, plat, info);
if (ret)
return ret;
}
--
2.12.0
^ permalink raw reply related
* [PATCH v2 0/6] stmmac: pci: Refactor DMI probing
From: Jan Kiszka @ 2017-05-26 16:07 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
Some cleanups of the way we probe DMI platforms in the driver. Reduces
a bit of open-coding and makes the logic easier reusable for any
potential DMI platform != Quark.
Tested on IOT2000 and Galileo Gen2.
Changes in v2:
- fixed bug that broke x86-64 build (and likely more)
- refactored series to do smaller steps
All this remains cosmetic from a certain distance, but the result looks
more appealing, at least to me.
Jan
Jan Kiszka (6):
stmmac: pci: Make stmmac_pci_info structure constant
stmmac: pci: Use stmmac_pci_info for all devices
stmmac: pci: Make stmmac_pci_find_phy_addr truly generic
stmmac: pci: Select quark_pci_dmi_data from quark_default_data
stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
stmmac: pci: Remove setup handler indirection via stmmac_pci_info
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 184 ++++++++++++-----------
1 file changed, 98 insertions(+), 86 deletions(-)
--
2.12.0
^ permalink raw reply
* Re: [PATCH net-next 3/4] tls: kernel TLS support
From: Eric Dumazet @ 2017-05-26 15:49 UTC (permalink / raw)
To: David Miller
Cc: davejwatson, ilyal, aviadye, borisp, liranl, matanb, netdev, tom,
herbert, linux-crypto, hannes, alexei.starovoitov, nmav,
fridolin.pokorny
In-Reply-To: <20170526.111852.235696953256744250.davem@davemloft.net>
On Fri, 2017-05-26 at 11:18 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 26 May 2017 07:16:59 -0700
>
> > On Wed, 2017-05-24 at 09:27 -0700, Dave Watson wrote:
> >> Software implementation of transport layer security, implemented using ULP
> >> infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg and
> >> sendpage.
> >
> > ...
> >
> >> +
> >> +int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> >> +{
> > ...
> >> +
> >> + lock_sock(sk);
> >> +
> >> + /* Only one writer at a time is allowed */
> >> + if (sk->sk_write_pending)
> >> + return -EBUSY;
> >
> > Ouch...
>
> Well, as I understand it, it is the same restriction userspace must
> itself enforce either in the application or in the SSL library.
The problem here is to lock_sock(sk), then returning without releasing
the socket.
Some basic lock imbalance really.
^ permalink raw reply
* Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down
From: Stephen Hemminger @ 2017-05-26 15:43 UTC (permalink / raw)
To: David Miller; +Cc: jemele, jemele, netdev, jemele, mlindner, linux-kernel
In-Reply-To: <20170525.235830.986562840550889246.davem@davemloft.net>
On Thu, 25 May 2017 23:58:30 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Thu, 25 May 2017 15:05:02 -0700
>
> > Ok, the issue is that lockdep is being stupid and thinking that
> > seqcount's behave like locks.
>
> Well.. they do. That's why they have that annotation.
Your right, but it has some lock like properties because
the seqcount's assumption about odd and even values.
Lockdep is reporting that accessing a sequence count with softirq disabled
and in another case with softirq enabled is a problem.
Potential race theoretical race:
seqcount_begin() ++count
...
---> IRQ
---> Soft IRQ
seqcount_begin() ++count
update stats
seqcount_end() ++count
Anything doing seqcount read during this softirq
will spin thinking still in critical section
But for this case of statistics, there is nothing reading statistics in softirq
context so it can't happen. Lockdep needs to be smarter to know that.
Simplest way to shut this up is to just disable softirq during the cleanup.
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: David Daney @ 2017-05-26 15:39 UTC (permalink / raw)
To: Daniel Borkmann, David Daney, Alexei Starovoitov, netdev,
linux-kernel, linux-mips, ralf
Cc: Markos Chandras
In-Reply-To: <5928463C.5000204@iogearbox.net>
On 05/26/2017 08:14 AM, Daniel Borkmann wrote:
> On 05/26/2017 02:38 AM, David Daney wrote:
>> Since the eBPF machine has 64-bit registers, we only support this in
>> 64-bit kernels. As of the writing of this commit log test-bpf is
>> showing:
>>
>> test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
>>
>> All current test cases are successfully compiled.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>
> Awesome work!
>
> Did you also manage to run tools/testing/selftests/bpf/ fine with
> the JIT enabled?
I haven't done that yet, I will before the next revision.
>
> [...]
>> +struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> +{
>> + struct jit_ctx ctx;
>> + unsigned int alloc_size;
>> +
>> + /* Only 64-bit kernel supports eBPF */
>> + if (!IS_ENABLED(CONFIG_64BIT) || !bpf_jit_enable)
>
> Isn't this already reflected by the following?
>
> select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
Not exactly. The eBPF JIT is in the same file as the classic-BPF JIT,
so when HAVE_EBPF_JIT is false this will indeed never be called. But
the kernel would otherwise contain all the JIT code.
By putting in !IS_ENABLED(CONFIG_64BIT) we allow gcc to eliminate all
the dead code when compiling the JITs.
>
>> + return prog;
>> +
>> + memset(&ctx, 0, sizeof(ctx));
>> +
>> + ctx.offsets = kcalloc(prog->len + 1, sizeof(*ctx.offsets),
>> GFP_KERNEL);
>> + if (ctx.offsets == NULL)
>> + goto out;
>> +
>> + ctx.reg_val_types = kcalloc(prog->len + 1,
>> sizeof(*ctx.reg_val_types), GFP_KERNEL);
>> + if (ctx.reg_val_types == NULL)
>> + goto out;
>> +
>> + ctx.skf = prog;
>> +
>> + if (reg_val_propagate(&ctx))
>> + goto out;
>> +
>> + /* First pass discovers used resources */
>> + if (build_int_body(&ctx))
>> + goto out;
>> +
>> + /* Second pass generates offsets */
>> + ctx.idx = 0;
>> + if (gen_int_prologue(&ctx))
>> + goto out;
>> + if (build_int_body(&ctx))
>> + goto out;
>> + if (build_int_epilogue(&ctx))
>> + goto out;
>> +
>> + alloc_size = 4 * ctx.idx;
>> +
>> + ctx.target = module_alloc(alloc_size);
>
> You would need to use bpf_jit_binary_alloc() like all other
> eBPF JITs do, otherwise kallsyms of the JITed progs would
> break.
OK, I was just copying code from the classic-BPF JIT in the same file.
I will fix this.
>
>> + if (ctx.target == NULL)
>> + goto out;
>> +
>> + /* Clean it */
>> + memset(ctx.target, 0, alloc_size);
>> +
>> + /* Third pass generates the code */
>> + ctx.idx = 0;
>> + if (gen_int_prologue(&ctx))
>> + goto out;
>> + if (build_int_body(&ctx))
>> + goto out;
>> + if (build_int_epilogue(&ctx))
>> + goto out;
>> + /* Update the icache */
>> + flush_icache_range((ptr)ctx.target, (ptr)(ctx.target + ctx.idx));
>> +
>> + if (bpf_jit_enable > 1)
>> + /* Dump JIT code */
>> + bpf_jit_dump(prog->len, alloc_size, 2, ctx.target);
>> +
>> + prog->bpf_func = (void *)ctx.target;
>> + prog->jited = 1;
>> +
>> +out:
>> + kfree(ctx.offsets);
>> + kfree(ctx.reg_val_types);
>> +
>> + return prog;
>> +}
>
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: Daniel Borkmann @ 2017-05-26 15:35 UTC (permalink / raw)
To: David Daney, Alexei Starovoitov, netdev, linux-kernel, linux-mips,
ralf
Cc: Markos Chandras
In-Reply-To: <5928463C.5000204@iogearbox.net>
On 05/26/2017 05:14 PM, Daniel Borkmann wrote:
> On 05/26/2017 02:38 AM, David Daney wrote:
>> Since the eBPF machine has 64-bit registers, we only support this in
>> 64-bit kernels. As of the writing of this commit log test-bpf is showing:
>>
>> test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
>>
>> All current test cases are successfully compiled.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>
> Awesome work!
>
> Did you also manage to run tools/testing/selftests/bpf/ fine with
> the JIT enabled?
>
> [...]
>> +struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> +{
>> + struct jit_ctx ctx;
>> + unsigned int alloc_size;
>> +
>> + /* Only 64-bit kernel supports eBPF */
>> + if (!IS_ENABLED(CONFIG_64BIT) || !bpf_jit_enable)
>
> Isn't this already reflected by the following?
>
> select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
Oh, overlooked that you keep both JITs in the same file. ppc and
sparc also carry cBPF JITs, but strictly separated at compile time,
x86 threw out the cBPF one and only uses eBPF. Have you considered
separating them as well (which the current model assumes right now)?
(Need to double check all assumption we currently make and whether
they would still hold, but separation like all others do would
definitely be preferred.)
>> + return prog;
>> +
>> + memset(&ctx, 0, sizeof(ctx));
>> +
>> + ctx.offsets = kcalloc(prog->len + 1, sizeof(*ctx.offsets), GFP_KERNEL);
>> + if (ctx.offsets == NULL)
>> + goto out;
>> +
>> + ctx.reg_val_types = kcalloc(prog->len + 1, sizeof(*ctx.reg_val_types), GFP_KERNEL);
>> + if (ctx.reg_val_types == NULL)
>> + goto out;
>> +
>> + ctx.skf = prog;
>> +
>> + if (reg_val_propagate(&ctx))
>> + goto out;
>> +
>> + /* First pass discovers used resources */
>> + if (build_int_body(&ctx))
>> + goto out;
>> +
>> + /* Second pass generates offsets */
>> + ctx.idx = 0;
>> + if (gen_int_prologue(&ctx))
>> + goto out;
>> + if (build_int_body(&ctx))
>> + goto out;
>> + if (build_int_epilogue(&ctx))
>> + goto out;
>> +
>> + alloc_size = 4 * ctx.idx;
>> +
>> + ctx.target = module_alloc(alloc_size);
>
> You would need to use bpf_jit_binary_alloc() like all other
> eBPF JITs do, otherwise kallsyms of the JITed progs would
> break.
>
>> + if (ctx.target == NULL)
>> + goto out;
>> +
>> + /* Clean it */
>> + memset(ctx.target, 0, alloc_size);
>> +
>> + /* Third pass generates the code */
>> + ctx.idx = 0;
>> + if (gen_int_prologue(&ctx))
>> + goto out;
>> + if (build_int_body(&ctx))
>> + goto out;
>> + if (build_int_epilogue(&ctx))
>> + goto out;
>> + /* Update the icache */
>> + flush_icache_range((ptr)ctx.target, (ptr)(ctx.target + ctx.idx));
>> +
>> + if (bpf_jit_enable > 1)
>> + /* Dump JIT code */
>> + bpf_jit_dump(prog->len, alloc_size, 2, ctx.target);
>> +
>> + prog->bpf_func = (void *)ctx.target;
>> + prog->jited = 1;
>> +
>> +out:
>> + kfree(ctx.offsets);
>> + kfree(ctx.reg_val_types);
>> +
>> + return prog;
>> +}
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: David Miller @ 2017-05-26 15:29 UTC (permalink / raw)
To: david.daney
Cc: ast, daniel, netdev, linux-kernel, linux-mips, ralf,
markos.chandras
In-Reply-To: <20170526003826.10834-6-david.daney@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Thu, 25 May 2017 17:38:26 -0700
> +static int gen_int_prologue(struct jit_ctx *ctx)
> +{
> + int stack_adjust = 0;
> + int store_offset;
> + int locals_size;
> +
> + if (ctx->flags & EBPF_SAVE_RA)
> + /*
> + * If RA we are doing a function call and may need
> + * extra 8-byte tmp area.
> + */
> + stack_adjust += 16;
> + if (ctx->flags & EBPF_SAVE_S0)
> + stack_adjust += 8;
> + if (ctx->flags & EBPF_SAVE_S1)
> + stack_adjust += 8;
> + if (ctx->flags & EBPF_SAVE_S2)
> + stack_adjust += 8;
> + if (ctx->flags & EBPF_SAVE_S3)
> + stack_adjust += 8;
> +
> + BUILD_BUG_ON(MAX_BPF_STACK & 7);
> + locals_size = (ctx->flags & EBPF_SEEN_FP) ? MAX_BPF_STACK : 0;
You will also need to use MAX_BPF_STACK here when you see a tail call,
but it appears you haven't implemented tail call support yet.
Which also several of the eBPF samples won't JIT and thus be tested
under this new MIPS JIT, since they make use of tail calls.
> +/*
> + * Track the value range (i.e. 32-bit vs. 64-bit) of each register at
> + * each eBPF insn. This allows unneeded sign and zero extension
> + * operations to be omitted.
> + *
> + * Doesn't handle yet confluence of control paths with conflicting
> + * ranges, but it is good enough for most sane code.
> + */
> +static int reg_val_propagate(struct jit_ctx *ctx)
Very interesting technique. I may adopt this for Sparc as well :-)
Perhaps at a some point, when the BPF verifier has real data flow
analysis, it can compute this for the JIT.
^ permalink raw reply
* Re: [PATCH net-next 3/4] tls: kernel TLS support
From: David Miller @ 2017-05-26 15:18 UTC (permalink / raw)
To: eric.dumazet
Cc: davejwatson, ilyal, aviadye, borisp, liranl, matanb, netdev, tom,
herbert, linux-crypto, hannes, alexei.starovoitov, nmav,
fridolin.pokorny
In-Reply-To: <1495808219.6465.118.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 26 May 2017 07:16:59 -0700
> On Wed, 2017-05-24 at 09:27 -0700, Dave Watson wrote:
>> Software implementation of transport layer security, implemented using ULP
>> infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg and
>> sendpage.
>
> ...
>
>> +
>> +int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>> +{
> ...
>> +
>> + lock_sock(sk);
>> +
>> + /* Only one writer at a time is allowed */
>> + if (sk->sk_write_pending)
>> + return -EBUSY;
>
> Ouch...
Well, as I understand it, it is the same restriction userspace must
itself enforce either in the application or in the SSL library.
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: Daniel Borkmann @ 2017-05-26 15:14 UTC (permalink / raw)
To: David Daney, Alexei Starovoitov, netdev, linux-kernel, linux-mips,
ralf
Cc: Markos Chandras
In-Reply-To: <20170526003826.10834-6-david.daney@cavium.com>
On 05/26/2017 02:38 AM, David Daney wrote:
> Since the eBPF machine has 64-bit registers, we only support this in
> 64-bit kernels. As of the writing of this commit log test-bpf is showing:
>
> test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
>
> All current test cases are successfully compiled.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Awesome work!
Did you also manage to run tools/testing/selftests/bpf/ fine with
the JIT enabled?
[...]
> +struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> +{
> + struct jit_ctx ctx;
> + unsigned int alloc_size;
> +
> + /* Only 64-bit kernel supports eBPF */
> + if (!IS_ENABLED(CONFIG_64BIT) || !bpf_jit_enable)
Isn't this already reflected by the following?
select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
> + return prog;
> +
> + memset(&ctx, 0, sizeof(ctx));
> +
> + ctx.offsets = kcalloc(prog->len + 1, sizeof(*ctx.offsets), GFP_KERNEL);
> + if (ctx.offsets == NULL)
> + goto out;
> +
> + ctx.reg_val_types = kcalloc(prog->len + 1, sizeof(*ctx.reg_val_types), GFP_KERNEL);
> + if (ctx.reg_val_types == NULL)
> + goto out;
> +
> + ctx.skf = prog;
> +
> + if (reg_val_propagate(&ctx))
> + goto out;
> +
> + /* First pass discovers used resources */
> + if (build_int_body(&ctx))
> + goto out;
> +
> + /* Second pass generates offsets */
> + ctx.idx = 0;
> + if (gen_int_prologue(&ctx))
> + goto out;
> + if (build_int_body(&ctx))
> + goto out;
> + if (build_int_epilogue(&ctx))
> + goto out;
> +
> + alloc_size = 4 * ctx.idx;
> +
> + ctx.target = module_alloc(alloc_size);
You would need to use bpf_jit_binary_alloc() like all other
eBPF JITs do, otherwise kallsyms of the JITed progs would
break.
> + if (ctx.target == NULL)
> + goto out;
> +
> + /* Clean it */
> + memset(ctx.target, 0, alloc_size);
> +
> + /* Third pass generates the code */
> + ctx.idx = 0;
> + if (gen_int_prologue(&ctx))
> + goto out;
> + if (build_int_body(&ctx))
> + goto out;
> + if (build_int_epilogue(&ctx))
> + goto out;
> + /* Update the icache */
> + flush_icache_range((ptr)ctx.target, (ptr)(ctx.target + ctx.idx));
> +
> + if (bpf_jit_enable > 1)
> + /* Dump JIT code */
> + bpf_jit_dump(prog->len, alloc_size, 2, ctx.target);
> +
> + prog->bpf_func = (void *)ctx.target;
> + prog->jited = 1;
> +
> +out:
> + kfree(ctx.offsets);
> + kfree(ctx.reg_val_types);
> +
> + return prog;
> +}
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] nfp: devlink port implementation
From: David Miller @ 2017-05-26 15:02 UTC (permalink / raw)
To: jiri; +Cc: jakub.kicinski, netdev, oss-drivers
In-Reply-To: <20170526082532.GC1898@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 26 May 2017 10:25:32 +0200
> Fri, May 26, 2017 at 10:03:30AM CEST, jakub.kicinski@netronome.com wrote:
>>Hi!
>>
>>This series adds basic devlink support. The operations we can perform
>>are port show and port split/unsplit.
>>
>>v2:
>>Register devlink first, and then register all the ports. Port {,un}split
>>searches the port list, which is protected by a mutex. If port split
>>is requested before ports are registered we will simply not find the port
>>and return -EINVAL.
>
> Looks fine to me now. Thanks!
Wow, you review stuff fast :-)
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] nfp: devlink port implementation
From: David Miller @ 2017-05-26 15:00 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, jiri, oss-drivers
In-Reply-To: <20170526080336.32689-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 26 May 2017 01:03:30 -0700
> This series adds basic devlink support. The operations we can perform
> are port show and port split/unsplit.
>
> v2:
> Register devlink first, and then register all the ports. Port {,un}split
> searches the port list, which is protected by a mutex. If port split
> is requested before ports are registered we will simply not find the port
> and return -EINVAL.
Great, I'll give Jiri a chance to review this.
^ 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