* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-15 15:33 UTC (permalink / raw)
To: Kalle Valo
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel, Luis R. Rodriguez
In-Reply-To: <87d1gtli57.fsf@purkki.adurom.net>
On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@codeaurora.org> wrote:
> (Adding Luis because he has been working on request_firmware() lately)
>
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > > > So no, there is no argument against... request_firmware() in
> > > > fallback mode with userspace helper is by design blocking and
> > > > waiting for userspace. But waiting for some change in DTS in
> > > > kernel is just nonsense.
> > >
> > > I would just mark the wlan device with status = "disabled" and
> > > enable it in the overlay together with adding the NVS & MAC info.
> >
> > So if you think that this solution make sense, we can wait what net
> > wireless maintainers say about it...
> >
> > For me it looks like that solution can be:
> >
> > extending request_firmware() to use only userspace helper
>
> I haven't followed the discussion very closely but this is my preference
> what drivers should do:
>
> 1) First the driver should do try to get the calibration data and mac
> address from the device tree.
>
Ok, but there is no (dynamic, device specific) data in DTS for N900. So 1) is noop.
> 2) If they are not in DT the driver should retrieve the calibration data
> with request_firmware(). BUT with an option for user space to
> implement that with a helper script so that the data can be created
> dynamically, which I believe openwrt does with ath10k calibration
> data right now.
Currently there is flag for request_firmware() that it should fallback to user helper if direct VFS access not find needed firmware.
But this flag is not suitable as /lib/firmware already provides default (not device specific) calibration data.
So I would suggest to add another flag/function which will primary use user helper.
> > and load mac address also via request_firmware() either by appending
> > it into NVS data or via separate call
>
> I'm not really fan of the idea providing permanent mac address through
> request_firmware(). For example, how to handle multiple devices on the
> same host, would there be a need for some kind of bus ids encoded to the
> filename? And what about devices with multiple mac addresses?
For N900 there is only one wl1251 device. And... wl12xx is already using appended MAC address in calibration data read by request firmware. So reason why I prefer similar usage also for wl1251.
> I wish there would be a better way than request_firmware() to provide
> the permanent mac addresses from user space (if device tree is not
> available), I just don't know what that could be :) But if we would
> start to use request_firmware() for this at least there should be a
> wider concensus about that and it should be properly documented, just
> like the device tree bindings.
>
> --
> Kalle Valo
I do not know about any other, so reason why I'm asking :-) and there are my proposed solutions. If you (or any other) came up with better we can discuss about it :-)
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH net] sctp: sctp_transport_lookup_process should rcu_read_unlock when transport is null
From: Xin Long @ 2016-12-15 15:05 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
Prior to this patch, sctp_transport_lookup_process didn't rcu_read_unlock
when it failed to find a transport by sctp_addrs_lookup_transport.
This patch is to fix it by moving up rcu_read_unlock right before checking
transport and also to remove the out path.
Fixes: 1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/socket.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index d5f4b4a..318c678 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4472,18 +4472,17 @@ int sctp_transport_lookup_process(int (*cb)(struct sctp_transport *, void *),
const union sctp_addr *paddr, void *p)
{
struct sctp_transport *transport;
- int err = -ENOENT;
+ int err;
rcu_read_lock();
transport = sctp_addrs_lookup_transport(net, laddr, paddr);
+ rcu_read_unlock();
if (!transport)
- goto out;
+ return -ENOENT;
- rcu_read_unlock();
err = cb(transport, p);
sctp_transport_put(transport);
-out:
return err;
}
EXPORT_SYMBOL_GPL(sctp_transport_lookup_process);
--
2.1.0
^ permalink raw reply related
* [PATCH net] sctp: sctp_epaddr_lookup_transport should be protected by rcu_read_lock
From: Xin Long @ 2016-12-15 15:00 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Neil Horman, Dmitry Vyukov
Since commit 7fda702f9315 ("sctp: use new rhlist interface on sctp transport
rhashtable"), sctp has changed to use rhlist_lookup to look up transport, but
rhlist_lookup doesn't call rcu_read_lock inside, unlike rhashtable_lookup_fast.
It is called in sctp_epaddr_lookup_transport and sctp_addrs_lookup_transport.
sctp_addrs_lookup_transport is always in the protection of rcu_read_lock(),
as __sctp_lookup_association is called in rx path or sctp_lookup_association
which are in the protection of rcu_read_lock() already.
But sctp_epaddr_lookup_transport is called by sctp_endpoint_lookup_assoc, it
doesn't call rcu_read_lock, which may cause "suspicious rcu_dereference_check
usage' in __rhashtable_lookup.
This patch is to fix it by adding rcu_read_lock in sctp_endpoint_lookup_assoc
before calling sctp_epaddr_lookup_transport.
Fixes: 7fda702f9315 ("sctp: use new rhlist interface on sctp transport rhashtable")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/endpointola.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 1f03065..410ddc1 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -331,7 +331,9 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
* on this endpoint.
*/
if (!ep->base.bind_addr.port)
- goto out;
+ return NULL;
+
+ rcu_read_lock();
t = sctp_epaddr_lookup_transport(ep, paddr);
if (!t)
goto out;
@@ -339,6 +341,7 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
*transport = t;
asoc = t->asoc;
out:
+ rcu_read_unlock();
return asoc;
}
--
2.1.0
^ permalink raw reply related
* Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap
From: arvind Yadav @ 2016-12-15 15:00 UTC (permalink / raw)
To: David Daney, peter.chen, fw, david.daney, f.fainelli; +Cc: netdev, linux-kernel
In-Reply-To: <41599714-309c-8590-b2b0-e468cffb57b5@caviumnetworks.com>
Hi David,
I did not tested this feature. I have build it and flashed on hardware.
You can check below commit id. Which has similar check for ioremap.
1- Commit id - de9e397e40f56b9f34af4bf6a5bd7a75ea02456c
In 'drivers/net/phy/mdio-octeon.c'
2- Commit id - 592569de4c247fe4f25db8369dc0c63860f9560b
In 'drivers/gpio/gpio-octeon.c'
Thanks
Arvind
On Thursday 15 December 2016 12:58 AM, David Daney wrote:
> On 12/14/2016 11:03 AM, Arvind Yadav wrote:
>> Here, If devm_ioremap will fail. It will return NULL.
>> Kernel can run into a NULL-pointer dereference.
>> This error check will avoid NULL pointer dereference. t
>
> I have asked you twice already this question, but could not determine
> from your response what the answer is:
>
> Q: Have you tested the patch on OCTEON based hardware that contains
> the "octeon_mgmt" Ethernet ports? Please answer either "yes" or "no".
>
>
> Thanks,
> David Daney
>
>
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> ---
>> drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
>> b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
>> index 4ab404f..33c2fec 100644
>> --- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
>> +++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
>> @@ -1479,6 +1479,12 @@ static int octeon_mgmt_probe(struct
>> platform_device *pdev)
>> p->agl = (u64)devm_ioremap(&pdev->dev, p->agl_phys, p->agl_size);
>> p->agl_prt_ctl = (u64)devm_ioremap(&pdev->dev, p->agl_prt_ctl_phys,
>> p->agl_prt_ctl_size);
>> + if (!p->mix || !p->agl || !p->agl_prt_ctl) {
>> + dev_err(&pdev->dev, "failed to map I/O memory\n");
>> + result = -ENOMEM;
>> + goto err;
>> + }
>> +
>> spin_lock_init(&p->lock);
>>
>> skb_queue_head_init(&p->tx_list);
>>
>
^ permalink raw reply
* Re: [PATCH net 2/2] net/sched: cls_flower: Use masked key when calling HW offloads
From: Jiri Pirko @ 2016-12-15 14:59 UTC (permalink / raw)
To: Simon Horman
Cc: Paul Blakey, David S. Miller, netdev, Jiri Pirko, Or Gerlitz,
Roi Dayan, Shahar Klein, Hadar Hen Zion
In-Reply-To: <20161215135043.GA7104@penelope.horms.nl>
Thu, Dec 15, 2016 at 02:50:44PM CET, simon.horman@netronome.com wrote:
>Hi Paul,
>
>On Wed, Dec 14, 2016 at 07:00:58PM +0200, Paul Blakey wrote:
>> Zero bits on the mask signify a "don't care" on the corresponding bits
>> in key. Some HWs require those bits on the key to be zero. Since these
>> bits are masked anyway, it's okay to provide the masked key to all
>> drivers.
>>
>> Fixes: 5b33f48842fa ('net/flower: Introduce hardware offload support')
>> Signed-off-by: Paul Blakey <paulb@mellanox.com>
>> Reviewed-by: Roi Dayan <roid@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
>While I don't have a specific use case in mind that this change would break
>it seems to me that it would be better to handle hardware requirements
>at the driver level.
Even though, makes no sense to pass unmasked key down. Is is only
confusing. This patch fixes it.
>
>> ---
>> net/sched/cls_flower.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>> index 9758f5a..35ac28d 100644
>> --- a/net/sched/cls_flower.c
>> +++ b/net/sched/cls_flower.c
>> @@ -252,7 +252,7 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
>> offload.cookie = (unsigned long)f;
>> offload.dissector = dissector;
>> offload.mask = mask;
>> - offload.key = &f->key;
>> + offload.key = &f->mkey;
>> offload.exts = &f->exts;
>>
>> tc->type = TC_SETUP_CLSFLOWER;
>> --
>> 1.8.3.1
>>
^ permalink raw reply
* Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
From: Hannes Frederic Sowa @ 2016-12-15 14:56 UTC (permalink / raw)
To: David Laight, Jason A. Donenfeld
Cc: Netdev, kernel-hardening@lists.openwall.com,
Jean-Philippe Aumasson, LKML, Linux Crypto Mailing List,
Daniel J . Bernstein, Linus Torvalds, Eric Biggers
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0240437@AcuExch.aculab.com>
On 15.12.2016 14:56, David Laight wrote:
> From: Hannes Frederic Sowa
>> Sent: 15 December 2016 12:50
>> On 15.12.2016 13:28, David Laight wrote:
>>> From: Hannes Frederic Sowa
>>>> Sent: 15 December 2016 12:23
>>> ...
>>>> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8
>>>> bytes on 32 bit. Do you question that?
>>>
>>> Yes.
>>>
>>> The linux ABI for x86 (32 bit) only requires 32bit alignment for u64 (etc).
>>
>> Hmm, u64 on 32 bit is unsigned long long and not unsigned long. Thus I
>> am actually not sure if the ABI would say anything about that (sorry
>> also for my wrong statement above).
>>
>> Alignment requirement of unsigned long long on gcc with -m32 actually
>> seem to be 8.
>
> It depends on the architecture.
> For x86 it is definitely 4.
May I ask for a reference? I couldn't see unsigned long long being
mentioned in the ia32 abi spec that I found. I agree that those accesses
might be synthetically assembled by gcc and for me the alignment of 4
would have seemed natural. But my gcc at least in 32 bit mode disagrees
with that.
> It might be 8 for sparc, ppc and/or alpha.
This is something to find out...
Right now ipv6 addresses have an alignment of 4. So we couldn't even
naturally pass them to siphash but would need to copy them around, which
I feel like a source of bugs.
Bye,
Hannes
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: ira.weiny @ 2016-12-15 14:52 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jeff Kirsher, David S. Miller
Cc: Vishwanathapura, Niranjana, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20161215091226.GC811-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Thu, Dec 15, 2016 at 11:12:26AM +0200, Leon Romanovsky wrote:
> On Wed, Dec 14, 2016 at 11:59:32PM -0800, Vishwanathapura, Niranjana wrote:
> > Thanks Jason for the valuable feedback.
> > Here is the revised HFI VNIC patch series.
> >
> > ChangeLog:
> > =========
> > v1 => v2:
> > a) Removed hfi_vnic bus, instead make hfi_vnic driver an 'ib client',
> > as per feedback from Jason Gunthorpe.
> > b) Interface changes, data structure changes and variable name changes
> > associated with (a).
> > c) Add hfi_ibdev abstraction to provide VNIC control operations to
> > hfi_vnic client.
> > d) Minor fixes
> > e) Moved hfi_vnic driver from .../sw/intel/vnic/hfi_vnic to
> > .../sw/intel/hfi_vnic.
>
> To put it into proportion, Jason asked you to do different thing.
> http://marc.info/?l=linux-rdma&m=147977108302151&w=2
> http://marc.info/?l=linux-rdma&m=148000415401842&w=2
>
> And Christoph,
> http://marc.info/?l=linux-rdma&m=147985587425861&w=2
Understood. However, we never heard back from Niranjanas analysis of the code
which stated that > 60% of the code was dealing with the OPA MADs used to
configure this device.
https://www.spinics.net/lists/linux-rdma/msg43579.html
Furthermore, neither Dave nor Doug has had time to weigh in on what we should
do.
So before we make that change we wanted to get consensus on using the
hfi1_ibdev abstraction rather than the bus. This was the _real_ technical
change.
Beyond that it is really just which maintainer wants this driver. To that end
I've also cc'ed Jeff Kirsher who maintains drivers/net/ethernet/intel. Perhaps
Dave would like the driver to go through that tree?
I think there are pros and cons to both subtrees and in the end we will do
whatever is decided.
For maintainer review:
1) The driver encapsulates ethernet packets with OPA headers
2) VNIC uses OPA management packets (MADs) for its configuration
3) A significant portion (> 60% +) of the code is specific to OPA
https://www.spinics.net/lists/linux-rdma/msg43579.html
4) The driver is from Intel and we expect Intel to be the primary
contributor to the code.
5) The driver, like hfi1, is dual licensed (GPL/BSD)
6) Based on Christophs feedback we will be adding device capability
bits to the IB core to indicate HFI VNIC support.
https://www.spinics.net/lists/linux-rdma/msg44113.html
Doug, Dave, Jeff any thoughts?
Ira
--
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: [PATCHv3 perf/core 0/7] Reuse libbpf from samples/bpf
From: Arnaldo Carvalho de Melo @ 2016-12-15 14:33 UTC (permalink / raw)
To: Joe Stringer; +Cc: Daniel Borkmann, LKML, netdev, Wang Nan, ast
In-Reply-To: <CAPWQB7E-i+m0Ukz6O39AV-pHMB=GsoUTTa1862QUjGWM3RQJyQ@mail.gmail.com>
Em Wed, Dec 14, 2016 at 02:46:23PM -0800, Joe Stringer escreveu:
> On 14 December 2016 at 06:55, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > So, Joe, can you try refreshing this work, starting from what I have in
> > perf/core? It has the changes coming from net-next that Daniel warned us about
> > and some more.
> I've just respun this series based on the version you previously
> applied to perf/core. Since bpf_prog_{attach,detach}() were added to
> samples/libbpf, a new patch will shift these over to tools/lib/bpf.
> Other than that, I folded "samples/bpf: Drop unnecessary build
> targets." back into "samples/bpf: Switch over to libbpf", and I
> noticed that there were a couple of unnecessary log buffers with the
> latest changes. For any new sample programs, those were fixed up to
> use libbpf as well.
> Don't forget to do a "make headers_install" before attempting to build
> the samples, access to the latest headers is required (as per the
> readme in samples/bpf).
Ah, README, I should read that ;-)
I got used to how tools/perf/ work, i.e. it is self sufficient wrt
in-flux stuff in the kernel, i.e. headers that are related to features
it supports and that are under constant improvements, such as eBPF, kvm,
syscall tables, etc.
Anyway, will do the headers_install step inside a container, to avoid
polluting my workstation.
Thanks for doing the respin and for the clarifications about building
samples/bpf/.
- Arnaldo
^ permalink raw reply
* [PATCH net] ixgbe: update the rss key on h/w, when ethtool ask for it.
From: Paolo Abeni @ 2016-12-15 14:20 UTC (permalink / raw)
To: netdev; +Cc: Jeff Kirsher, intel-wired-lan
Currently ixgbe_set_rxfh() updates the rss_key copy in the driver
memory, but does not push the new value into the h/w. This commit
add a new helper for the latter operation and call it in
ixgbe_set_rxfh(), so that the h/w rss key value can be really
updated via ethtool.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 ++++++++++++++++---
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index ef81c3d..8fb9fbf 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -1026,6 +1026,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
struct ixgbe_adapter *adapter,
struct ixgbe_ring *tx_ring);
u32 ixgbe_rss_indir_tbl_entries(struct ixgbe_adapter *adapter);
+void ixgbe_store_key(struct ixgbe_adapter *adapter);
void ixgbe_store_reta(struct ixgbe_adapter *adapter);
s32 ixgbe_negotiate_fc(struct ixgbe_hw *hw, u32 adv_reg, u32 lp_reg,
u32 adv_sym, u32 adv_asm, u32 lp_sym, u32 lp_asm);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index fd192bf..e40f9ce 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -3003,8 +3003,10 @@ static int ixgbe_set_rxfh(struct net_device *netdev, const u32 *indir,
}
/* Fill out the rss hash key */
- if (key)
+ if (key) {
memcpy(adapter->rss_key, key, ixgbe_get_rxfh_key_size(netdev));
+ ixgbe_store_key(adapter);
+ }
ixgbe_store_reta(adapter);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 1e2f39e..0c23ab8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3411,6 +3411,21 @@ u32 ixgbe_rss_indir_tbl_entries(struct ixgbe_adapter *adapter)
}
/**
+ * ixgbe_store_key - Write the RSS key to HW
+ * @adapter: device handle
+ *
+ * Write the RSS key stored in adapter.rss_key to HW.
+ */
+void ixgbe_store_key(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ int i;
+
+ for (i = 0; i < 10; i++)
+ IXGBE_WRITE_REG(hw, IXGBE_RSSRK(i), adapter->rss_key[i]);
+}
+
+/**
* ixgbe_store_reta - Write the RETA table to HW
* @adapter: device handle
*
@@ -3475,7 +3490,6 @@ static void ixgbe_store_vfreta(struct ixgbe_adapter *adapter)
static void ixgbe_setup_reta(struct ixgbe_adapter *adapter)
{
- struct ixgbe_hw *hw = &adapter->hw;
u32 i, j;
u32 reta_entries = ixgbe_rss_indir_tbl_entries(adapter);
u16 rss_i = adapter->ring_feature[RING_F_RSS].indices;
@@ -3488,8 +3502,7 @@ static void ixgbe_setup_reta(struct ixgbe_adapter *adapter)
rss_i = 4;
/* Fill out hash function seeds */
- for (i = 0; i < 10; i++)
- IXGBE_WRITE_REG(hw, IXGBE_RSSRK(i), adapter->rss_key[i]);
+ ixgbe_store_key(adapter);
/* Fill out redirection table */
memset(adapter->rss_indir_tbl, 0, sizeof(adapter->rss_indir_tbl));
--
1.8.3.1
^ permalink raw reply related
* RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
From: David Laight @ 2016-12-15 13:56 UTC (permalink / raw)
To: 'Hannes Frederic Sowa', Jason A. Donenfeld
Cc: Netdev, kernel-hardening@lists.openwall.com,
Jean-Philippe Aumasson, LKML, Linux Crypto Mailing List,
Daniel J . Bernstein, Linus Torvalds, Eric Biggers
In-Reply-To: <0f3c3694-c00b-aae2-5b08-25bc64bf6372@stressinduktion.org>
From: Hannes Frederic Sowa
> Sent: 15 December 2016 12:50
> On 15.12.2016 13:28, David Laight wrote:
> > From: Hannes Frederic Sowa
> >> Sent: 15 December 2016 12:23
> > ...
> >> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8
> >> bytes on 32 bit. Do you question that?
> >
> > Yes.
> >
> > The linux ABI for x86 (32 bit) only requires 32bit alignment for u64 (etc).
>
> Hmm, u64 on 32 bit is unsigned long long and not unsigned long. Thus I
> am actually not sure if the ABI would say anything about that (sorry
> also for my wrong statement above).
>
> Alignment requirement of unsigned long long on gcc with -m32 actually
> seem to be 8.
It depends on the architecture.
For x86 it is definitely 4.
It might be 8 for sparc, ppc and/or alpha.
David
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc/m_tunnel_key: Add dest UDP port to tunnel key action
From: Simon Horman @ 2016-12-15 13:53 UTC (permalink / raw)
To: Hadar Hen Zion
Cc: Stephen Hemminger, netdev, Or Gerlitz, Roi Dayan, Amir Vadai
In-Reply-To: <20161215130335.GA30716@penelope.horms.nl>
On Thu, Dec 15, 2016 at 02:03:36PM +0100, Simon Horman wrote:
> On Tue, Dec 13, 2016 at 10:07:47AM +0200, Hadar Hen Zion wrote:
> > Enhance tunnel key action parameters by adding destination UDP port.
> >
> > Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
> > Reviewed-by: Roi Dayan <roid@mellanox.com>
>
> Hi,
>
> this looks good to me but could you also update tc/m_tunnel_key.c:usage(); ?
It seems that I was a bit hasty here as I now see that Stephen has
indicated that he has applied this series. I also notice that
patch 1/2 of this series also misses updating usage(). Let me know
if sending some follow-up patches is the best way forwards.
^ permalink raw reply
* Re: [PATCH net 2/2] net/sched: cls_flower: Use masked key when calling HW offloads
From: Simon Horman @ 2016-12-15 13:50 UTC (permalink / raw)
To: Paul Blakey
Cc: David S. Miller, netdev, Jiri Pirko, Or Gerlitz, Roi Dayan,
Shahar Klein, Hadar Hen Zion
In-Reply-To: <1481734858-37474-3-git-send-email-paulb@mellanox.com>
Hi Paul,
On Wed, Dec 14, 2016 at 07:00:58PM +0200, Paul Blakey wrote:
> Zero bits on the mask signify a "don't care" on the corresponding bits
> in key. Some HWs require those bits on the key to be zero. Since these
> bits are masked anyway, it's okay to provide the masked key to all
> drivers.
>
> Fixes: 5b33f48842fa ('net/flower: Introduce hardware offload support')
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
While I don't have a specific use case in mind that this change would break
it seems to me that it would be better to handle hardware requirements
at the driver level.
> ---
> net/sched/cls_flower.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index 9758f5a..35ac28d 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -252,7 +252,7 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
> offload.cookie = (unsigned long)f;
> offload.dissector = dissector;
> offload.mask = mask;
> - offload.key = &f->key;
> + offload.key = &f->mkey;
> offload.exts = &f->exts;
>
> tc->type = TC_SETUP_CLSFLOWER;
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH] net: ipv4: tcp_offload: check segs for NULL
From: Tobias Klauser @ 2016-12-15 13:43 UTC (permalink / raw)
To: shakya.das; +Cc: davem, netdev, shakya89.das, vidushi.koul
In-Reply-To: <1481791661-21670-1-git-send-email-shakya.das@samsung.com>
On 2016-12-15 at 09:47:41 +0100, shakya.das@samsung.com <shakya.das@samsung.com> wrote:
> From: Shakya Sundar Das <shakya.das@samsung.com>
>
> This patch will check segs for being NULL in tcp_gso_segment()
> before calling skb_shinfo(segs) from skb_is_gso(segs), otherwise
> kernel can run into a NULL-pointer dereference.
How can segs ever be NULL here? skb_segment() will always either return
an skb or an ERR_PTR(err).
^ permalink raw reply
* Re: [PATCH iproute2 1/2] tc: flower: Fix typo in the flower man page
From: Simon Horman @ 2016-12-15 12:56 UTC (permalink / raw)
To: Roi Dayan; +Cc: Stephen Hemminger, netdev, Amir Vadai, Hadar Hen Zion
In-Reply-To: <1481607232-1342-2-git-send-email-roid@mellanox.com>
On Tue, Dec 13, 2016 at 07:33:51AM +0200, Roi Dayan wrote:
> Replace vlan_eth_type with vlan_ethtype.
>
> Fixes: 745d91726006 ("tc: flower: Introduce vlan support")
> Signed-off-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* [PATCH net 3/3] MAINTAINERS: net: add entry for Freescale QorIQ DPAA Ethernet driver
From: Madalin Bucur @ 2016-12-15 13:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807586-4798-1-git-send-email-madalin.bucur@nxp.com>
Add record for Freescale QORIQ DPAA Ethernet driver adding myself as
maintainer.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e2463ba..0ff9757 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5058,6 +5058,12 @@ S: Maintained
F: drivers/net/ethernet/freescale/fman
F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+FREESCALE QORIQ DPAA ETHERNET DRIVER
+M: Madalin Bucur <madalin.bucur@nxp.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/ethernet/freescale/dpaa
+
FREESCALE QUICC ENGINE LIBRARY
L: linuxppc-dev@lists.ozlabs.org
S: Orphan
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/3] dpaa_eth: remove redundant dependency on FSL_SOC
From: Madalin Bucur @ 2016-12-15 13:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807586-4798-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/dpaa/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/Kconfig b/drivers/net/ethernet/freescale/dpaa/Kconfig
index f3a3454..a654736 100644
--- a/drivers/net/ethernet/freescale/dpaa/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa/Kconfig
@@ -1,6 +1,6 @@
menuconfig FSL_DPAA_ETH
tristate "DPAA Ethernet"
- depends on FSL_SOC && FSL_DPAA && FSL_FMAN
+ depends on FSL_DPAA && FSL_FMAN
select PHYLIB
select FSL_FMAN_MAC
---help---
--
2.1.0
^ permalink raw reply related
* [PATCH net 1/3] dpaa_eth: use big endian accessors
From: Madalin Bucur @ 2016-12-15 13:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807586-4798-1-git-send-email-madalin.bucur@nxp.com>
From: Claudiu Manoil <claudiu.manoil@nxp.com>
Ensure correct access to the big endian QMan HW through proper
accessors.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 71 ++++++++++++++------------
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 3c48a84..624ba90 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -733,7 +733,7 @@ static int dpaa_eth_cgr_init(struct dpaa_priv *priv)
priv->cgr_data.cgr.cb = dpaa_eth_cgscn;
/* Enable Congestion State Change Notifications and CS taildrop */
- initcgr.we_mask = QM_CGR_WE_CSCN_EN | QM_CGR_WE_CS_THRES;
+ initcgr.we_mask = cpu_to_be16(QM_CGR_WE_CSCN_EN | QM_CGR_WE_CS_THRES);
initcgr.cgr.cscn_en = QM_CGR_EN;
/* Set different thresholds based on the MAC speed.
@@ -747,7 +747,7 @@ static int dpaa_eth_cgr_init(struct dpaa_priv *priv)
cs_th = DPAA_CS_THRESHOLD_1G;
qm_cgr_cs_thres_set64(&initcgr.cgr.cs_thres, cs_th, 1);
- initcgr.we_mask |= QM_CGR_WE_CSTD_EN;
+ initcgr.we_mask |= cpu_to_be16(QM_CGR_WE_CSTD_EN);
initcgr.cgr.cstd_en = QM_CGR_EN;
err = qman_create_cgr(&priv->cgr_data.cgr, QMAN_CGR_FLAG_USE_INIT,
@@ -896,18 +896,18 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
if (dpaa_fq->init) {
memset(&initfq, 0, sizeof(initfq));
- initfq.we_mask = QM_INITFQ_WE_FQCTRL;
+ initfq.we_mask = cpu_to_be16(QM_INITFQ_WE_FQCTRL);
/* Note: we may get to keep an empty FQ in cache */
- initfq.fqd.fq_ctrl = QM_FQCTRL_PREFERINCACHE;
+ initfq.fqd.fq_ctrl = cpu_to_be16(QM_FQCTRL_PREFERINCACHE);
/* Try to reduce the number of portal interrupts for
* Tx Confirmation FQs.
*/
if (dpaa_fq->fq_type == FQ_TYPE_TX_CONFIRM)
- initfq.fqd.fq_ctrl |= QM_FQCTRL_HOLDACTIVE;
+ initfq.fqd.fq_ctrl |= cpu_to_be16(QM_FQCTRL_HOLDACTIVE);
/* FQ placement */
- initfq.we_mask |= QM_INITFQ_WE_DESTWQ;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_DESTWQ);
qm_fqd_set_destwq(&initfq.fqd, dpaa_fq->channel, dpaa_fq->wq);
@@ -920,8 +920,8 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
if (dpaa_fq->fq_type == FQ_TYPE_TX ||
dpaa_fq->fq_type == FQ_TYPE_TX_CONFIRM ||
dpaa_fq->fq_type == FQ_TYPE_TX_CONF_MQ) {
- initfq.we_mask |= QM_INITFQ_WE_CGID;
- initfq.fqd.fq_ctrl |= QM_FQCTRL_CGE;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_CGID);
+ initfq.fqd.fq_ctrl |= cpu_to_be16(QM_FQCTRL_CGE);
initfq.fqd.cgid = (u8)priv->cgr_data.cgr.cgrid;
/* Set a fixed overhead accounting, in an attempt to
* reduce the impact of fixed-size skb shells and the
@@ -932,7 +932,7 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
* insufficient value, but even that is better than
* no overhead accounting at all.
*/
- initfq.we_mask |= QM_INITFQ_WE_OAC;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_OAC);
qm_fqd_set_oac(&initfq.fqd, QM_OAC_CG);
qm_fqd_set_oal(&initfq.fqd,
min(sizeof(struct sk_buff) +
@@ -941,9 +941,9 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
}
if (td_enable) {
- initfq.we_mask |= QM_INITFQ_WE_TDTHRESH;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_TDTHRESH);
qm_fqd_set_taildrop(&initfq.fqd, DPAA_FQ_TD, 1);
- initfq.fqd.fq_ctrl = QM_FQCTRL_TDE;
+ initfq.fqd.fq_ctrl = cpu_to_be16(QM_FQCTRL_TDE);
}
if (dpaa_fq->fq_type == FQ_TYPE_TX) {
@@ -951,7 +951,8 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
if (queue_id >= 0)
confq = priv->conf_fqs[queue_id];
if (confq) {
- initfq.we_mask |= QM_INITFQ_WE_CONTEXTA;
+ initfq.we_mask |=
+ cpu_to_be16(QM_INITFQ_WE_CONTEXTA);
/* ContextA: OVOM=1(use contextA2 bits instead of ICAD)
* A2V=1 (contextA A2 field is valid)
* A0V=1 (contextA A0 field is valid)
@@ -959,8 +960,8 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
* ContextA A2: EBD=1 (deallocate buffers inside FMan)
* ContextB B0(ASPID): 0 (absolute Virtual Storage ID)
*/
- initfq.fqd.context_a.hi = 0x1e000000;
- initfq.fqd.context_a.lo = 0x80000000;
+ qm_fqd_context_a_set64(&initfq.fqd,
+ 0x1e00000080000000ULL);
}
}
@@ -968,13 +969,13 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
if (priv->use_ingress_cgr &&
(dpaa_fq->fq_type == FQ_TYPE_RX_DEFAULT ||
dpaa_fq->fq_type == FQ_TYPE_RX_ERROR)) {
- initfq.we_mask |= QM_INITFQ_WE_CGID;
- initfq.fqd.fq_ctrl |= QM_FQCTRL_CGE;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_CGID);
+ initfq.fqd.fq_ctrl |= cpu_to_be16(QM_FQCTRL_CGE);
initfq.fqd.cgid = (u8)priv->ingress_cgr.cgrid;
/* Set a fixed overhead accounting, just like for the
* egress CGR.
*/
- initfq.we_mask |= QM_INITFQ_WE_OAC;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_OAC);
qm_fqd_set_oac(&initfq.fqd, QM_OAC_CG);
qm_fqd_set_oal(&initfq.fqd,
min(sizeof(struct sk_buff) +
@@ -984,9 +985,8 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool td_enable)
/* Initialization common to all ingress queues */
if (dpaa_fq->flags & QMAN_FQ_FLAG_NO_ENQUEUE) {
- initfq.we_mask |= QM_INITFQ_WE_CONTEXTA;
- initfq.fqd.fq_ctrl |=
- QM_FQCTRL_HOLDACTIVE;
+ initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_CONTEXTA);
+ initfq.fqd.fq_ctrl |= cpu_to_be16(QM_FQCTRL_HOLDACTIVE);
initfq.fqd.context_a.stashing.exclusive =
QM_STASHING_EXCL_DATA | QM_STASHING_EXCL_CTX |
QM_STASHING_EXCL_ANNOTATION;
@@ -1350,7 +1350,7 @@ static int dpaa_enable_tx_csum(struct dpaa_priv *priv,
parse_result->l4_off = (u8)skb_transport_offset(skb);
/* Enable L3 (and L4, if TCP or UDP) HW checksum. */
- fd->cmd |= FM_FD_CMD_RPD | FM_FD_CMD_DTC;
+ fd->cmd |= cpu_to_be32(FM_FD_CMD_RPD | FM_FD_CMD_DTC);
/* On P1023 and similar platforms fd->cmd interpretation could
* be disabled by setting CONTEXT_A bit ICMD; currently this bit
@@ -1732,7 +1732,7 @@ static int skb_to_contig_fd(struct dpaa_priv *priv,
/* Fill in the rest of the FD fields */
qm_fd_set_contig(fd, priv->tx_headroom, skb->len);
- fd->cmd |= FM_FD_CMD_FCO;
+ fd->cmd |= cpu_to_be32(FM_FD_CMD_FCO);
/* Map the entire buffer size that may be seen by FMan, but no more */
addr = dma_map_single(dev, skbh,
@@ -1840,7 +1840,7 @@ static int skb_to_sg_fd(struct dpaa_priv *priv,
}
fd->bpid = FSL_DPAA_BPID_INV;
- fd->cmd |= FM_FD_CMD_FCO;
+ fd->cmd |= cpu_to_be32(FM_FD_CMD_FCO);
qm_fd_addr_set64(fd, addr);
return 0;
@@ -1867,7 +1867,7 @@ static inline int dpaa_xmit(struct dpaa_priv *priv,
egress_fq = priv->egress_fqs[queue];
if (fd->bpid == FSL_DPAA_BPID_INV)
- fd->cmd |= qman_fq_fqid(priv->conf_fqs[queue]);
+ fd->cmd |= cpu_to_be32(qman_fq_fqid(priv->conf_fqs[queue]));
/* Trace this Tx fd */
trace_dpaa_tx_fd(priv->net_dev, egress_fq, fd);
@@ -1960,17 +1960,17 @@ static void dpaa_rx_error(struct net_device *net_dev,
{
if (net_ratelimit())
netif_err(priv, hw, net_dev, "Err FD status = 0x%08x\n",
- fd->status & FM_FD_STAT_RX_ERRORS);
+ be32_to_cpu(fd->status) & FM_FD_STAT_RX_ERRORS);
percpu_priv->stats.rx_errors++;
- if (fd->status & FM_FD_ERR_DMA)
+ if (be32_to_cpu(fd->status) & FM_FD_ERR_DMA)
percpu_priv->rx_errors.dme++;
- if (fd->status & FM_FD_ERR_PHYSICAL)
+ if (be32_to_cpu(fd->status) & FM_FD_ERR_PHYSICAL)
percpu_priv->rx_errors.fpe++;
- if (fd->status & FM_FD_ERR_SIZE)
+ if (be32_to_cpu(fd->status) & FM_FD_ERR_SIZE)
percpu_priv->rx_errors.fse++;
- if (fd->status & FM_FD_ERR_PRS_HDR_ERR)
+ if (be32_to_cpu(fd->status) & FM_FD_ERR_PRS_HDR_ERR)
percpu_priv->rx_errors.phe++;
dpaa_fd_release(net_dev, fd);
@@ -1986,7 +1986,7 @@ static void dpaa_tx_error(struct net_device *net_dev,
if (net_ratelimit())
netif_warn(priv, hw, net_dev, "FD status = 0x%08x\n",
- fd->status & FM_FD_STAT_TX_ERRORS);
+ be32_to_cpu(fd->status) & FM_FD_STAT_TX_ERRORS);
percpu_priv->stats.tx_errors++;
@@ -2020,10 +2020,11 @@ static void dpaa_tx_conf(struct net_device *net_dev,
{
struct sk_buff *skb;
- if (unlikely(fd->status & FM_FD_STAT_TX_ERRORS) != 0) {
+ if (unlikely(be32_to_cpu(fd->status) & FM_FD_STAT_TX_ERRORS)) {
if (net_ratelimit())
netif_warn(priv, hw, net_dev, "FD status = 0x%08x\n",
- fd->status & FM_FD_STAT_TX_ERRORS);
+ be32_to_cpu(fd->status) &
+ FM_FD_STAT_TX_ERRORS);
percpu_priv->stats.tx_errors++;
}
@@ -2100,6 +2101,8 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct qman_portal *portal,
struct sk_buff *skb;
int *count_ptr;
+ fd_status = be32_to_cpu(fd->status);
+ fd_format = qm_fd_get_format(fd);
net_dev = ((struct dpaa_fq *)fq)->net_dev;
priv = netdev_priv(net_dev);
dpaa_bp = dpaa_bpid2pool(dq->fd.bpid);
@@ -2417,12 +2420,12 @@ static int dpaa_ingress_cgr_init(struct dpaa_priv *priv)
}
/* Enable CS TD, but disable Congestion State Change Notifications. */
- initcgr.we_mask = QM_CGR_WE_CS_THRES;
+ initcgr.we_mask = cpu_to_be16(QM_CGR_WE_CS_THRES);
initcgr.cgr.cscn_en = QM_CGR_EN;
cs_th = DPAA_INGRESS_CS_THRESHOLD;
qm_cgr_cs_thres_set64(&initcgr.cgr.cs_thres, cs_th, 1);
- initcgr.we_mask |= QM_CGR_WE_CSTD_EN;
+ initcgr.we_mask |= cpu_to_be16(QM_CGR_WE_CSTD_EN);
initcgr.cgr.cstd_en = QM_CGR_EN;
/* This CGR will be associated with the SWP affined to the current CPU.
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/3] dpaa_eth: a couple of fixes
From: Madalin Bucur @ 2016-12-15 13:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
This patch set introduces big endian accessors in the dpaa_eth driver
making sure accesses to the QBMan HW are correct on little endian
platforms. Removing a redundant Kconfig dependency on FSL_SOC.
Adding myself as maintainer of the dpaa_eth driver.
Claudiu Manoil (1):
dpaa_eth: use big endian accessors
Madalin Bucur (2):
dpaa_eth: remove redundant dependency on FSL_SOC
MAINTAINERS: net: add entry for Freescale QorIQ DPAA Ethernet driver
MAINTAINERS | 6 +++
drivers/net/ethernet/freescale/dpaa/Kconfig | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 71 ++++++++++++++------------
3 files changed, 44 insertions(+), 35 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 4/4] fsl/fman: enable compilation on ARM64
From: Madalin Bucur @ 2016-12-15 13:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807497-4724-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig
index 79b7c84..dc0850b 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -1,6 +1,6 @@
config FSL_FMAN
tristate "FMan support"
- depends on FSL_SOC || COMPILE_TEST
+ depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
default n
--
2.1.0
^ permalink raw reply related
* [PATCH net 3/4] fsl/fman: A007273 only applies to PPC SoCs
From: Madalin Bucur @ 2016-12-15 13:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807497-4724-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index f36b4eb..93d6a36 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -1890,6 +1890,7 @@ static int fman_reset(struct fman *fman)
goto _return;
} else {
+#ifdef CONFIG_PPC
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1921,6 +1922,7 @@ static int fman_reset(struct fman *fman)
/* Enable all MACs */
iowrite32be(reg, &guts_regs->devdisr2);
+#endif
/* Perform FMan reset */
iowrite32be(FPM_RSTC_FM_RESET, &fman->fpm_regs->fm_rstc);
@@ -1932,25 +1934,31 @@ static int fman_reset(struct fman *fman)
} while (((ioread32be(&fman->fpm_regs->fm_rstc)) &
FPM_RSTC_FM_RESET) && --count);
if (count == 0) {
+#ifdef CONFIG_PPC
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
err = -EBUSY;
goto _return;
}
+#ifdef CONFIG_PPC
/* Restore devdisr2 value */
iowrite32be(devdisr2, &guts_regs->devdisr2);
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
goto _return;
+#ifdef CONFIG_PPC
guts_regs:
of_node_put(guts_node);
guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
+#endif
}
_return:
return err;
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/4] fsl/fman: arm: call of_platform_populate() for arm64 platfrom
From: Madalin Bucur @ 2016-12-15 13:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807497-4724-1-git-send-email-madalin.bucur@nxp.com>
From: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index dafd9e1..f36b4eb 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2868,6 +2868,16 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
fman->dev = &of_dev->dev;
+#ifdef CONFIG_ARM64
+ /* call of_platform_populate in order to probe sub-nodes on arm64 */
+ err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
+ if (err) {
+ dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
+ __func__);
+ goto fman_free;
+ }
+#endif
+
return fman;
fman_node_put:
--
2.1.0
^ permalink raw reply related
* [PATCH net 1/4] fsl/fman: fix 1G support for QSGMII interfaces
From: Madalin Bucur @ 2016-12-15 13:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <1481807497-4724-1-git-send-email-madalin.bucur@nxp.com>
QSGMII ports were not advertising 1G speed.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 69ca42c..0b31f85 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -594,6 +594,7 @@ static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_RGMII_RXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RGMII_TXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RTBI] = SPEED_1000,
+ [PHY_INTERFACE_MODE_QSGMII] = SPEED_1000,
[PHY_INTERFACE_MODE_XGMII] = SPEED_10000
};
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/4] fsl/fman: fixes for ARM
From: Madalin Bucur @ 2016-12-15 13:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem
The patch set fixes advertised speeds for QSGMII interfaces, disables
A007273 erratum workaround on non-PowerPC platforms where it does not
apply, enables compilation on ARM64 and addresses a probing issue on
ARM64.
Igal Liberman (1):
fsl/fman: arm: call of_platform_populate() for arm64 platfrom
Madalin Bucur (3):
fsl/fman: fix 1G support for QSGMII interfaces
fsl/fman: A007273 only applies to PPC SoCs
fsl/fman: enable compilation on ARM64
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
drivers/net/ethernet/freescale/fman/fman.c | 18 ++++++++++++++++++
drivers/net/ethernet/freescale/fman/mac.c | 1 +
3 files changed, 20 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc/m_tunnel_key: Add dest UDP port to tunnel key action
From: Simon Horman @ 2016-12-15 13:03 UTC (permalink / raw)
To: Hadar Hen Zion
Cc: Stephen Hemminger, netdev, Or Gerlitz, Roi Dayan, Amir Vadai
In-Reply-To: <1481616467-769-3-git-send-email-hadarh@mellanox.com>
On Tue, Dec 13, 2016 at 10:07:47AM +0200, Hadar Hen Zion wrote:
> Enhance tunnel key action parameters by adding destination UDP port.
>
> Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
Hi,
this looks good to me but could you also update tc/m_tunnel_key.c:usage(); ?
With that change:
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* [PATCH iproute2 v2 2/3] ifstat: Add 64 bits based stats to extended statistics
From: Nogah Frankel @ 2016-12-15 13:00 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa, jiri, eladr, yotamg, idosch, ogerlitz,
Nogah Frankel
In-Reply-To: <1481806845-63384-1-git-send-email-nogahf@mellanox.com>
The default stats for ifstat are 32 bits based.
The kernel supports 64 bits based stats. (They are returned in struct
rtnl_link_stats64 which is an exact copy of struct rtnl_link_stats, in
which the "normal" stats are returned, but with fields of u64 instead of
u32). This patch adds them as an extended stats.
It is read with filter type IFLA_STATS_LINK_64 and no sub type.
It is under the name 64bits
(or any shorten of it as "64")
For example:
ifstat -x 64bit
Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
misc/ifstat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/misc/ifstat.c b/misc/ifstat.c
index d17ae21..ac99d04 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -729,7 +729,8 @@ static int verify_forging(int fd)
static void xstat_usage(void)
{
fprintf(stderr,
-"Usage: ifstat supported xstats:\n");
+"Usage: ifstat supported xstats:\n"
+" 64bits default stats, with 64 bits support\n");
}
struct extended_stats_options_t {
@@ -743,6 +744,7 @@ struct extended_stats_options_t {
* Name length must be under 64 chars.
*/
static const struct extended_stats_options_t extended_stats_options[] = {
+ {"64bits", IFLA_STATS_LINK_64, NO_SUB_TYPE},
};
static bool get_filter_type(char *name)
--
2.4.3
^ permalink raw reply related
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