* [PATCH net-next] rxrpc: Remove set but not used variable 'nowj'
From: Wei Yongjun @ 2018-08-02 3:36 UTC (permalink / raw)
To: David Howells; +Cc: Wei Yongjun, linux-afs, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
net/rxrpc/proc.c: In function 'rxrpc_call_seq_show':
net/rxrpc/proc.c:66:29: warning:
variable 'nowj' set but not used [-Wunused-but-set-variable]
unsigned long timeout = 0, nowj;
^
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/rxrpc/proc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rxrpc/proc.c b/net/rxrpc/proc.c
index 163d05d..9805e3b 100644
--- a/net/rxrpc/proc.c
+++ b/net/rxrpc/proc.c
@@ -63,7 +63,7 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
struct rxrpc_peer *peer;
struct rxrpc_call *call;
struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
- unsigned long timeout = 0, nowj;
+ unsigned long timeout = 0;
rxrpc_seq_t tx_hard_ack, rx_hard_ack;
char lbuff[50], rbuff[50];
@@ -97,7 +97,6 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
if (call->state != RXRPC_CALL_SERVER_PREALLOC) {
timeout = READ_ONCE(call->expect_rx_by);
- nowj = jiffies;
timeout -= jiffies;
}
^ permalink raw reply related
* Re: [PATCH] inet/connection_sock: prefer _THIS_IP_ to current_text_addr
From: Nathan Chancellor @ 2018-08-02 5:08 UTC (permalink / raw)
To: David Miller; +Cc: ndesaulniers, netdev, linux-kernel
In-Reply-To: <20180802045825.GA16769@flashbox>
On Wed, Aug 01, 2018 at 09:58:25PM -0700, Nathan Chancellor wrote:
> On Wed, Aug 01, 2018 at 06:42:08PM -0700, David Miller wrote:
> > From: Nick Desaulniers <ndesaulniers@google.com>
> > Date: Wed, 1 Aug 2018 14:57:59 -0700
> >
> > > - sk, what, when, current_text_addr());
> > > + sk, what, when, (void *)_THIS_IP_);
> >
> > Is a fugly macro in all caps really better than a function()?
> >
> > I'm really surprised that _THIS_IP_ is being chosen over
> > current_text_addr(), seriously.
>
> Hi Dave,
Sorry for the second email so quick after the first, needed to clarify
two things.
>
> current_text_addr is only used in five places in the entire kernel and
> this is the only non-architecture specific use.
>
> include/net/inet_connection_sock.h:227: sk, what, when, current_text_addr());
> arch/sh/include/asm/kexec.h:64: newregs->pc = (unsigned long)current_text_addr();
> arch/sh/kernel/dwarf.c:602: pc = (unsigned long)current_text_addr();
> arch/x86/include/asm/kexec.h:135: newregs->ip = (unsigned long)current_text_addr();
> arch/parisc/kernel/unwind.c:442: r.iaoq[0] = (unsigned long) current_text_addr();
>
> We're trying to merge it with _THIS_IP_ before for most architectures,
because for most...
> it is defined nearly identically to _THIS_IP_:
>
> #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
>
> #define current_text_addr() ({ __label__ _l; _l: &&_l; })
>
> * arc
> * arm
> * arm64
> * h8300
> * hexagon
> * m68k
> * mips
> * nds32
> * nios2
> * openrisc
> * powerpc
> * riscv
> * unicore32
> * xtensa
>
> Ultimately, we're trying to turn off a new Clang warning in _THIS_IP_
> which requires some changes to work around what is believed to be a GCC
> bug (see https://lore.kernel.org/patchwork/patch/969101/).
and I should have mentioned that current_text_addr suffers from the
exact same issue so we're trying not to duplicate it 14 times across
the kernel.
> I guess the alternative to this patch is to just define current_text_addr
> as _THIS_IP_ for all of those architectures, I am not sure how that
> filters into Nick's plan (I think the goal of this was to try and avoid
> getting all of the architecture folks involved).
>
> Thanks for your time!
> Nathan
^ permalink raw reply
* Re: [PATCH] inet/connection_sock: prefer _THIS_IP_ to current_text_addr
From: Nathan Chancellor @ 2018-08-02 4:58 UTC (permalink / raw)
To: David Miller; +Cc: ndesaulniers, netdev, linux-kernel
In-Reply-To: <20180801.184208.776886134692058469.davem@davemloft.net>
On Wed, Aug 01, 2018 at 06:42:08PM -0700, David Miller wrote:
> From: Nick Desaulniers <ndesaulniers@google.com>
> Date: Wed, 1 Aug 2018 14:57:59 -0700
>
> > - sk, what, when, current_text_addr());
> > + sk, what, when, (void *)_THIS_IP_);
>
> Is a fugly macro in all caps really better than a function()?
>
> I'm really surprised that _THIS_IP_ is being chosen over
> current_text_addr(), seriously.
Hi Dave,
current_text_addr is only used in five places in the entire kernel and
this is the only non-architecture specific use.
include/net/inet_connection_sock.h:227: sk, what, when, current_text_addr());
arch/sh/include/asm/kexec.h:64: newregs->pc = (unsigned long)current_text_addr();
arch/sh/kernel/dwarf.c:602: pc = (unsigned long)current_text_addr();
arch/x86/include/asm/kexec.h:135: newregs->ip = (unsigned long)current_text_addr();
arch/parisc/kernel/unwind.c:442: r.iaoq[0] = (unsigned long) current_text_addr();
We're trying to merge it with _THIS_IP_ before for most architectures,
it is defined nearly identically to _THIS_IP_:
#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
#define current_text_addr() ({ __label__ _l; _l: &&_l; })
* arc
* arm
* arm64
* h8300
* hexagon
* m68k
* mips
* nds32
* nios2
* openrisc
* powerpc
* riscv
* unicore32
* xtensa
Ultimately, we're trying to turn off a new Clang warning in _THIS_IP_
which requires some changes to work around what is believed to be a GCC
bug (see https://lore.kernel.org/patchwork/patch/969101/).
I guess the alternative to this patch is to just define current_text_addr
as _THIS_IP_ for all of those architectures, I am not sure how that
filters into Nick's plan (I think the goal of this was to try and avoid
getting all of the architecture folks involved).
Thanks for your time!
Nathan
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-08-02 4:37 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Fixes keep trickling in:
1) Various IP fragmentation memory limit hardening changes from
Eric Dumazet.
2) Revert ipv6 metrics leak change, it causes more problems than it fixes
for now.
3) Fix WoL regression in stmmac driver, from Jose Abreu.
4) Netlink socket spectre v1 gadget fix, from Jeremy Cline.
Please pull, thanks a lot!
The following changes since commit c1d61e7fe3760851319138550efb732273ab2e57:
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2018-07-31 09:46:36 -0700)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to e6aed040eafb4ce1881bbc59a225f6b27d250396:
Revert "net/ipv6: fix metrics leak" (2018-08-01 21:32:30 -0700)
----------------------------------------------------------------
Adi Nissim (1):
net/mlx5e: Fix null pointer access when setting MTU of vport representor
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix SERDES support on 88E6141/6341
David S. Miller (3):
Merge tag 'wireless-drivers-for-davem-2018-07-31' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge tag 'mlx5-fixes-2018-07-31' of git://git.kernel.org/.../saeed/linux
Revert "net/ipv6: fix metrics leak"
Eli Cohen (1):
net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager
Emmanuel Grumbach (1):
iwlwifi: add more card IDs for 9000 series
Eric Dumazet (3):
inet: frag: enforce memory limits earlier
ipv4: frags: handle possible skb truesize change
bonding: avoid lockdep confusion in bond_get_stats()
Feras Daoud (1):
net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow
Florian Fainelli (1):
net: dsa: Do not suspend/resume closed slave_dev
Govindarajulu Varadarajan (1):
enic: do not call enic_change_mtu in enic_probe
Ioana Ciornei (1):
Documentation: dpaa2: Use correct heading adornment
Jeremy Cline (1):
netlink: Fix spectre v1 gadget in netlink_create()
Jose Abreu (1):
net: stmmac: Fix WoL for PCI-based setups
Or Gerlitz (1):
net/mlx5e: Set port trust mode to PCP as default
Rafał Miłecki (1):
brcmfmac: fix regression in parsing NVRAM for multiple devices
YueHaibing (1):
rxrpc: Fix user call ID check in rxrpc_service_prealloc_one
Documentation/networking/dpaa2/overview.rst | 1 +
drivers/net/bonding/bond_main.c | 14 ++++++++++++--
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
drivers/net/ethernet/cisco/enic/enic_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 4 ++++
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 40 +++++++++++++++++++++++++++++++++++++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 +++++
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 22 ++++++++++++++++++++++
net/dsa/slave.c | 6 ++++++
net/ipv4/inet_fragment.c | 6 +++---
net/ipv4/ip_fragment.c | 5 +++++
net/ipv6/ip6_fib.c | 18 ++++--------------
net/netlink/af_netlink.c | 2 ++
net/rxrpc/call_accept.c | 4 ++--
19 files changed, 184 insertions(+), 30 deletions(-)
^ permalink raw reply
* Spende von $ 4,800,000.00!
From: Gloria Adelaida Elias Mejia @ 2018-08-02 2:15 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
Hallo, Sie haben eine Spende von $ 4,800,000.00, ich habe die America Lotterie im Wert von $ 40 Millionen gewonnen und ich gebe einen Teil davon an fünf glückliche Menschen und Wohltätigkeitseinrichtungen zum Gedenken an meine verstorbene Frau, die an Krebs starb.
Spendenreferenznummer: BBIB / AVL017 / 28392
Kontaktieren Sie mich für weitere Informationen: tomcrist895@gmail.com
Prost
Tom Crist
[-- Attachment #2: Type: text/html, Size: 2309 bytes --]
^ permalink raw reply
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: David Miller @ 2018-08-02 1:40 UTC (permalink / raw)
To: jakub.kicinski; +Cc: saeedm, netdev, jiri, alexander.duyck, helgaas
In-Reply-To: <20180801170047.687ce65c@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 1 Aug 2018 17:00:47 -0700
> On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
>> - According to the discussion outcome, we are keeping the congestion control
>> setting as mlx5 device specific for the current HW generation.
>
> I still see queuing and marking based on queue level. You want to add
> a Qdisc that will mirror your HW's behaviour to offload, if you really
> believe this is not a subset of RED, why not... But devlink params?
I totally agree, devlink seems like absolutely to wrong level and set
of interfaces to be doing this stuff.
I will not pull these changes in and I probably should have not
accepted the DCB changes from the other day and they were sneakily
leading up to this crap.
Sorry, please follow Jakub's lead as I think his approach makes much
more technical sense than using devlink for this.
Thanks.
^ permalink raw reply
* Re: [Patch net-next] net: hns3: fix return value error while hclge_cmd_csq_clean failed
From: tanhuazhong @ 2018-08-02 0:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxarm
In-Reply-To: <20180801.100332.1084702659051147259.davem@davemloft.net>
On 2018/8/2 1:03, David Miller wrote:
> From: Huazhong Tan <tanhuazhong@huawei.com>
> Date: Wed, 1 Aug 2018 17:53:28 +0800
>
>> From: fredalu <fredalu@yeah.net>
>>
>> While cleaning the command queue, the value of the HEAD register is not
>> in the range of next_to_clean and next_to_use, meaning that this value
>> is invalid. This also means that there is a hardware error and the
>> hardware will trigger a reset soon. At this time we should return an
>> error code instead of 0, and HCLGE_STATE_CMD_DISABLE needs to be set to
>> prevent sending command again.
>>
>> Fixes: 3ff504908f95 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean")
>> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>wq
> ---> ^^^
>
> I think I know what text editor you use... :-)
>
> Applied with 'wq' removed from your signoff... Thanks.
>
> .
>
Sorry about this, I have sent V2 to fix it.
Thanks.:)
^ permalink raw reply
* [PATCH v4 4/8] net: phy: Disable external master access in bcm mdio mux driver
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Configure the scan control register in the Broadcom iProc
mdio mux driver to disable access to external master.
In some SoC's, the scan control register defaults to an incorrect
value.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index 48bb74a..c36ce4b 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -22,6 +22,9 @@
#include <linux/mdio-mux.h>
#include <linux/delay.h>
+#define MDIO_SCAN_CTRL_OFFSET 0x008
+#define MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR 28
+
#define MDIO_PARAM_OFFSET 0x23c
#define MDIO_PARAM_MIIM_CYCLE 29
#define MDIO_PARAM_INTERNAL_SEL 25
@@ -53,6 +56,16 @@ struct iproc_mdiomux_desc {
struct mii_bus *mii_bus;
};
+static void mdio_mux_iproc_config(struct iproc_mdiomux_desc *md)
+{
+ u32 val;
+
+ /* Disable external mdio master access */
+ val = readl(md->base + MDIO_SCAN_CTRL_OFFSET);
+ val |= BIT(MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR);
+ writel(val, md->base + MDIO_SCAN_CTRL_OFFSET);
+}
+
static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
{
unsigned int timeout = 1000; /* loop for 1s */
@@ -216,6 +229,8 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
goto out_register;
}
+ mdio_mux_iproc_config(md);
+
dev_info(md->dev, "iProc mdiomux registered\n");
return 0;
--
1.9.1
^ permalink raw reply related
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: Alexander Duyck @ 2018-08-02 0:36 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, David S. Miller, Netdev, Jiri Pirko,
Jakub Kicinski, Bjorn Helgaas
In-Reply-To: <CALzJLG-TRPE+4NpHDjkSBBPVMm-MetJnBqnRGqLbSxr7ur0ZrA@mail.gmail.com>
On Wed, Aug 1, 2018 at 4:13 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Wed, Aug 1, 2018 at 3:34 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, Aug 1, 2018 at 2:52 PM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>>> Hi Dave,
>>>
>>> This series provides devlink parameters updates to both devlink API and
>>> mlx5 driver, it is a 2nd iteration of the dropped patches sent in a previous
>>> mlx5 submission "net/mlx5: Support PCIe buffer congestion handling via
>>> Devlink" to address review comments [1].
>>>
>>> Changes from the original series:
>>> - According to the discussion outcome, we are keeping the congestion control
>>> setting as mlx5 device specific for the current HW generation.
>>> - Changed the congestion_mode and congestion action param type to string
>>> - Added patches to fix devlink handling of param type string
>>> - Added a patch which adds extack messages support for param set.
>>> - At the end of this series, I've added yet another mlx5 devlink related
>>> feature, firmware snapshot support.
>>>
>>> For more information please see tag log below.
>>>
>>> Please pull and let me know if there's any problem.
>>>
>>> [1] https://patchwork.ozlabs.org/patch/945996/
>>>
>>> Thanks,
>>> Saeed.
>>>
>>> ---
>>>
>>> The following changes since commit e6476c21447c4b17c47e476aade6facf050f31e8:
>>>
>>> net: remove bogus RCU annotations on socket.wq (2018-07-31 12:40:22 -0700)
>>>
>>> are available in the Git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2018-08-01
>>>
>>> for you to fetch changes up to 2ac6108c65ffcb1e5eab1fba1fd59272604d1c32:
>>>
>>> net/mlx5: Use devlink region_snapshot parameter (2018-08-01 14:49:09 -0700)
>>>
>>> ----------------------------------------------------------------
>>> mlx5-updates-2018-08-01
>>>
>>> This series provides devlink parameters updates to both devlink API and
>>> mlx5 driver,
>>>
>>> 1) Devlink changes: (Moshe Shemesh)
>>> The first two patches fix devlink param infrastructure for string type
>>> params.
>>> The third patch adds a devlink helper function to safely copy string from
>>> driver to devlink.
>>> The forth patch adds extack support for param set.
>>>
>>> 2) mlx5 specific congestion parameters: (Eran Ben Elisha)
>>> Next three patches add new devlink driver specific params for controlling
>>> congestion action and mode, using string type params and extack messages support.
>>>
>>> This congestion mode enables hw workaround in specific devices which is
>>> controlled by devlink driver-specific params. The workaround is device
>>> specific for this NIC generation, the next NIC will not need it.
>>>
>>> Congestion parameters:
>>> - Congestion action
>>> HW W/A mechanism in the PCIe buffer which monitors the amount of
>>> consumed PCIe buffer per host. This mechanism supports the
>>> following actions in case of threshold overflow:
>>> - Disabled - NOP (Default)
>>> - Drop
>>> - Mark - Mark CE bit in the CQE of received packet
>>> - Congestion mode
>>> - Aggressive - Aggressive static trigger threshold (Default)
>>> - Dynamic - Dynamically change the trigger threshold
>>>
>>> 3) mlx5 firmware snapshot support via devlink: (Alex Vesker)
>>> Last three patches, add the support for capturing region snapshot of the
>>> firmware crspace during critical errors, using devlink region_snapshot
>>> parameter.
>>>
>>> -Saeed.
>>>
>>> ----------------------------------------------------------------
>>> Alex Vesker (3):
>>> net/mlx5: Add Vendor Specific Capability access gateway
>>> net/mlx5: Add Crdump FW snapshot support
>>> net/mlx5: Use devlink region_snapshot parameter
>>>
>>> Eran Ben Elisha (3):
>>> net/mlx5: Move all devlink related functions calls to devlink.c
>>> net/mlx5: Add MPEGC register configuration functionality
>>> net/mlx5: Enable PCIe buffer congestion handling workaround via devlink
>>>
>>> Moshe Shemesh (4):
>>> devlink: Fix param set handling for string type
>>> devlink: Fix param cmode driverinit for string type
>>> devlink: Add helper function for safely copy string param
>>> devlink: Add extack messages support to param set
>>>
>>> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 3 +-
>>> drivers/net/ethernet/mellanox/mlx4/main.c | 6 +-
>>> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 3 +-
>>> drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 388 +++++++++++++++++++++
>>> drivers/net/ethernet/mellanox/mlx5/core/devlink.h | 13 +
>>> .../net/ethernet/mellanox/mlx5/core/diag/crdump.c | 223 ++++++++++++
>>> drivers/net/ethernet/mellanox/mlx5/core/health.c | 3 +
>>> drivers/net/ethernet/mellanox/mlx5/core/lib/mlx5.h | 4 +
>>> .../net/ethernet/mellanox/mlx5/core/lib/pci_vsc.c | 320 +++++++++++++++++
>>> .../net/ethernet/mellanox/mlx5/core/lib/pci_vsc.h | 56 +++
>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 10 +-
>>> include/linux/mlx5/driver.h | 5 +
>>> include/net/devlink.h | 15 +-
>>> net/core/devlink.c | 44 ++-
>>> 14 files changed, 1076 insertions(+), 17 deletions(-)
>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.c
>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.h
>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/diag/crdump.c
>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/pci_vsc.c
>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/pci_vsc.h
>>
>> So after looking over the patch set the one thing I would ask for in
>> this is some sort of documentation at a minimum. As a user I don't see
>> how you can expect someone to be able to use this when the naming of
>> things are pretty cryptic and there is no real explanation anywhere if
>> you don't go through and read the patch description itself. When you
>> start adding driver specific interfaces, you should at least start
>> adding vendor specific documentation.
>>
>
> Sure, sounds like a great idea, something like:
> Documentation/networking/mlx5.txt and have a devlink section ?
> or have a generic devlink doc and a mlx5 section in it ?
Either would work for me.
>> Also I don't see how using a vendor specific configuration space
>> section can be done without adding some tie-ins to the PCI core files
>> because it should be possible to race with someone poking at the
>> register space via something like setpci/lspci. Also one of the things
>> that came up was that drivers are not supposed to be banging on the
>> PCI configuration space at will, and it seems like this patch set is
>> doing exactly that through the VSC block.
>>
>
> this is a whole different feature than the device specific parameters.
> The whole vendor specific configuration space access is needed only
> for diagnostic/dump
> purposes when something really bad happens and the command interface
> with FW is down,
> and when the FW is un-responsive, we want to dump the crspace into the
> already existing devlink
> crdump buffer, how do you expect us to read it if we are not allowed
> to access it ?
>
> What do you mean by tie-ins to the PCI core files ? can you please elaborate ?
You have added a vendor specific config section and you are using it
to access several of the pieces of metadata. The setup isn't too
different than the VPD setup and approach. However I don't see many of
the protections that exist for VPD in place for this vendor specific
configuration. As such I have concerns. For example what is to keep
requests to the various devlink interfaces from racing with each other
when they both end up operating through the VCS?
- Alex
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the rdma tree
From: Stephen Rothwell @ 2018-08-02 2:05 UTC (permalink / raw)
To: David Miller, Networking, Doug Ledford, Jason Gunthorpe
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, YueHaibing,
Bart Van Assche
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/rds/ib_send.c
between commit:
d34ac5cd3a73 ("RDMA, core and ULPs: Declare ib_post_send() and ib_post_recv() arguments const")
from the rdma tree and commit:
87f70132b08e ("rds: remove redundant variable 'rds_ibdev'")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/rds/ib_send.c
index 8ac80c1b051e,c8dd3125d398..000000000000
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@@ -758,8 -758,7 +758,7 @@@ int rds_ib_xmit_atomic(struct rds_conne
{
struct rds_ib_connection *ic = conn->c_transport_data;
struct rds_ib_send_work *send = NULL;
- struct ib_send_wr *failed_wr;
+ const struct ib_send_wr *failed_wr;
- struct rds_ib_device *rds_ibdev;
u32 pos;
u32 work_alloc;
int ret;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next, v6, 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue
From: Andrei Vagin @ 2018-08-02 0:11 UTC (permalink / raw)
To: Nambiar, Amritha
Cc: netdev, davem, alexander.h.duyck, willemdebruijn.kernel,
sridhar.samudrala, alexander.duyck, edumazet, hannes, tom, tom,
jasowang, gaowanlong, Michael S. Tsirkin, virtualization
In-Reply-To: <4b7f5d42-1b81-f095-f313-f43e41cf8601@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote:
> With this patch series, I introduced static_key for XPS maps
> (xps_needed), so static_key_slow_inc() is used to switch branches. The
> definition of static_key_slow_inc() has cpus_read_lock in place. In the
> virtio_net driver, XPS queues are initialized after setting the
> queue:cpu affinity in virtnet_set_affinity() which is already protected
> within cpus_read_lock. Hence, the warning here trying to acquire
> cpus_read_lock when it is already held.
>
> A quick fix for this would be to just extract netif_set_xps_queue() out
> of the lock by simply wrapping it with another put/get_online_cpus
> (unlock right before and hold lock right after).
virtnet_set_affinity() is called from virtnet_cpu_online(), which is
called under cpus_read_lock too.
It looks like now we can't call netif_set_xps_queue() from cpu hotplug
callbacks.
I can suggest a very straightforward fix for this problem. The patch is
attached.
> But this may not a
> clean solution. It'd help if I can get suggestions on what would be a
> clean option to fix this without extensively changing the code in
> virtio_net. Is it mandatory to protect the affinitization with
> read_lock? I don't see similar lock in other drivers while setting the
> affinity. I understand this warning should go away, but isn't it safe to
> have multiple readers.
>
> > On Fri, Jun 29, 2018 at 09:27:07PM -0700, Amritha Nambiar wrote:
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 4258 bytes --]
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 1880c86e84b4..ebb5470090e5 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1941,7 +1941,7 @@ static void virtnet_set_affinity(struct virtnet_info *vi)
for_each_online_cpu(cpu) {
virtqueue_set_affinity(vi->rq[i].vq, cpu);
virtqueue_set_affinity(vi->sq[i].vq, cpu);
- netif_set_xps_queue(vi->dev, cpumask_of(cpu), i);
+ __netif_set_xps_queue(vi->dev, cpumask_bits(cpumask_of(cpu)), i, false, true);
i++;
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9c917467a2c7..37c88e566806 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3320,7 +3320,7 @@ static inline void netif_wake_subqueue(struct net_device *dev, u16 queue_index)
int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
u16 index);
int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
- u16 index, bool is_rxqs_map);
+ u16 index, bool is_rxqs_map, bool cpuslocked);
/**
* netif_attr_test_mask - Test a CPU or Rx queue set in a mask
diff --git a/net/core/dev.c b/net/core/dev.c
index 38b0c414d780..96ade614a23e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2176,6 +2176,7 @@ static void netif_reset_xps_queues(struct net_device *dev, u16 offset,
if (!static_key_false(&xps_needed))
return;
+ cpus_read_lock();
mutex_lock(&xps_map_mutex);
if (static_key_false(&xps_rxqs_needed)) {
@@ -2199,10 +2200,11 @@ static void netif_reset_xps_queues(struct net_device *dev, u16 offset,
out_no_maps:
if (static_key_enabled(&xps_rxqs_needed))
- static_key_slow_dec(&xps_rxqs_needed);
+ static_key_slow_dec_cpuslocked(&xps_rxqs_needed);
- static_key_slow_dec(&xps_needed);
+ static_key_slow_dec_cpuslocked(&xps_needed);
mutex_unlock(&xps_map_mutex);
+ cpus_read_unlock();
}
static void netif_reset_xps_queues_gt(struct net_device *dev, u16 index)
@@ -2251,7 +2253,7 @@ static struct xps_map *expand_xps_map(struct xps_map *map, int attr_index,
}
int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
- u16 index, bool is_rxqs_map)
+ u16 index, bool is_rxqs_map, bool cpuslocked)
{
const unsigned long *online_mask = NULL, *possible_mask = NULL;
struct xps_dev_maps *dev_maps, *new_dev_maps = NULL;
@@ -2275,6 +2277,9 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
return -EINVAL;
}
+ if (!cpuslocked)
+ cpus_read_lock();
+
mutex_lock(&xps_map_mutex);
if (is_rxqs_map) {
maps_sz = XPS_RXQ_DEV_MAPS_SIZE(num_tc, dev->num_rx_queues);
@@ -2317,9 +2322,9 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
if (!new_dev_maps)
goto out_no_new_maps;
- static_key_slow_inc(&xps_needed);
+ static_key_slow_inc_cpuslocked(&xps_needed);
if (is_rxqs_map)
- static_key_slow_inc(&xps_rxqs_needed);
+ static_key_slow_inc_cpuslocked(&xps_rxqs_needed);
for (j = -1; j = netif_attrmask_next(j, possible_mask, nr_ids),
j < nr_ids;) {
@@ -2427,6 +2432,8 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
out_no_maps:
mutex_unlock(&xps_map_mutex);
+ if (!cpuslocked)
+ cpus_read_unlock();
return 0;
error:
@@ -2444,15 +2451,18 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
}
mutex_unlock(&xps_map_mutex);
+ if (!cpuslocked)
+ cpus_read_unlock();
kfree(new_dev_maps);
return -ENOMEM;
}
+EXPORT_SYMBOL_GPL(__netif_set_xps_queue);
int netif_set_xps_queue(struct net_device *dev, const struct cpumask *mask,
u16 index)
{
- return __netif_set_xps_queue(dev, cpumask_bits(mask), index, false);
+ return __netif_set_xps_queue(dev, cpumask_bits(mask), index, false, false);
}
EXPORT_SYMBOL(netif_set_xps_queue);
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 0a95bcf64cdc..06a141445d80 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1400,7 +1400,7 @@ static ssize_t xps_rxqs_store(struct netdev_queue *queue, const char *buf,
return err;
}
- err = __netif_set_xps_queue(dev, mask, index, true);
+ err = __netif_set_xps_queue(dev, mask, index, true, false);
kfree(mask);
return err ? : len;
}
^ permalink raw reply related
* RE: [PATCH] net: fec: check DMA addressing limitations
From: Andy Duan @ 2018-08-02 2:00 UTC (permalink / raw)
To: Stefan Agner, davem@davemloft.net
Cc: krzk@kernel.org, robin.murphy@arm.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180801114449.21208-1-stefan@agner.ch>
From: Stefan Agner <stefan@agner.ch> Sent: 2018年8月1日 19:45
> Check DMA addressing limitations as suggested by the DMA API how-to.
> This does not fix a particular issue seen but is considered good style.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index c729665107f5..af0fb200e936 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -3146,6 +3146,12 @@ static int fec_enet_init(struct net_device
> *ndev)
> fep->tx_align = 0x3;
> #endif
>
> + /* Check mask of the streaming and coherent API */
> + if (dma_set_mask_and_coherent(&fep->pdev->dev,
> DMA_BIT_MASK(32))) {
> + dev_warn(&fep->pdev->dev, "No suitable DMA available\n");
> + return -ENODEV;
It is better:
ret = dma_set_mask_and_coherent(&fep->pdev->dev, DMA_BIT_MASK(32));
if (ret < 0) {
dev_warn(&fep->pdev->dev, "No suitable DMA available\n");
return ret;
}
If the patch aim to "OF: Don't set default coherent DMA mask", I think not only this driver need to add the DMA mask limitations, many other drivers also need.
> + }
> +
> fec_enet_alloc_queue(ndev);
>
> bd_size = (fep->total_tx_ring_size + fep->total_rx_ring_size) * dsize;
> --
> 2.18.0
^ permalink raw reply
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: Jakub Kicinski @ 2018-08-02 0:00 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David S. Miller, netdev, Jiri Pirko, Alexander Duyck,
Bjorn Helgaas
In-Reply-To: <20180801215255.6642-1-saeedm@mellanox.com>
On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote:
> - According to the discussion outcome, we are keeping the congestion control
> setting as mlx5 device specific for the current HW generation.
I still see queuing and marking based on queue level. You want to add
a Qdisc that will mirror your HW's behaviour to offload, if you really
believe this is not a subset of RED, why not... But devlink params?
^ permalink raw reply
* Re: [PATCH] inet/connection_sock: prefer _THIS_IP_ to current_text_addr
From: David Miller @ 2018-08-02 1:42 UTC (permalink / raw)
To: ndesaulniers; +Cc: natechancellor, netdev, linux-kernel
In-Reply-To: <20180801215759.103758-1-ndesaulniers@google.com>
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Wed, 1 Aug 2018 14:57:59 -0700
> - sk, what, when, current_text_addr());
> + sk, what, when, (void *)_THIS_IP_);
Is a fugly macro in all caps really better than a function()?
I'm really surprised that _THIS_IP_ is being chosen over
current_text_addr(), seriously.
^ permalink raw reply
* Re: [PATCH v4 0/8] Add clock config and pm support to bcm iProc mdio mux
From: Florian Fainelli @ 2018-08-02 1:40 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
On 08/01/2018 05:53 PM, Arun Parameswaran wrote:
> Hi,
> The patchset is based on David Miller's "net-next" repo.
>
> The patchset extends the Broadcom iProc mdio mux to add support for
> suspend/resume and the ability to configure the internal clock
> divider. The patchset also sets the scan control register to
> disable external master access.
>
> The base address of the mdio-mux-bcm-iproc is modified to point to the
> start of the mdio block's address space, to be able to access all the
> mdio's registers. The missing registers are required to configure the
> internal clock divider registers in some of the Broadcom SoC's.
Looks ready to me now, thanks for your persistence addressing feedback.
>
> Changes from v3:
> - Removed 'platform_set_drvdata(pdev, NULL)' call (in patch 5/8)
> - Fixed the return code handling for the devm_clk_get() call (in patch
> 7/8)
> - Added Reviewed-by tag to Patch 8/8
>
> Changes from v2:
> - Addressed Andrew's comments:
> - Moved to using devm_mdiobus_alloc. Added this as a separate patch.
> - Changed to reverse christmas tree order for variable declaration in
> the clock patch
> - Addressed Florian's comments:
> - Removed null checks for the clock before calling unprepare in
> both clock and pm patches.
> - Added check for EPROBE_DEFER when fetching the clock in the clock
> patch.
> - The patch to use the devm API has been added before the clock & pm
> patches. This patch is now patch '5' in the series.
> - Added reviewed-by tags to commit messages of patches which remain
> unmodified from v2.
> - Modified PM patch to use platform_get_drvdata() in suspend/resume
> API's, similar to the recent fix that went in for the remove()
> api.
>
> Changes from v1:
> - Addressed Andrew's comments.
> - Reworked the patches to be based on 'net-next'
> - Removed 'fixes' from the commit messages, the changes are related
> to the new features being added.
> - Maintained backward compatibility to older dt-blob's specifying
> base addresse with an offset. The correction is applied in the
> driver and a message is printed to update the dt-blob.
> - Re-worked and re-ordered the last four patches (4-7).
> - Added setting of the scan control register as a new patch
> - Added a call to 'clk_prepare_enable()' in the patch that adds
> the clock config support, removed the debug message when clock
> is not passed.
> - Simplified the pm support patch (removed the array used for the
> save/restore logic).
>
> Thanks
>
> Arun Parameswaran (8):
> dt-bindings: net: Fix Broadcom iProc mdio mux driver base address
> net: phy: Fix the register offsets in Broadcom iProc mdio mux driver
> arm64: dts: Fix the base address of the Broadcom iProc mdio mux
> net: phy: Disable external master access in bcm mdio mux driver
> net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
> dt-bindings: net: Add clock handle to Broadcom iProc mdio mux
> net: phy: Add support to configure clock in Broadcom iProc mdio mux
> net: phy: Add pm support to Broadcom iProc mdio mux driver
>
> .../bindings/net/brcm,mdio-mux-iproc.txt | 7 +-
> arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 +-
> .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 +-
> drivers/net/phy/mdio-mux-bcm-iproc.c | 108 ++++++++++++++++++---
> 4 files changed, 106 insertions(+), 17 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH v4 7/8] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Florian Fainelli @ 2018-08-02 1:40 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1533171233-14557-8-git-send-email-arun.parameswaran@broadcom.com>
On 08/01/2018 05:53 PM, Arun Parameswaran wrote:
> Add support to configure the internal rate adjust register based on the
> core clock supplied through device tree in the Broadcom iProc mdio mux.
>
> The operating frequency of the mdio mux block is 11MHz. This is derrived
> by dividing the clock to the mdio mux with the rate adjust register.
>
> In some SoC's the default values of the rate adjust register do not yield
> 11MHz. These SoC's are required to specify the clock via the device tree
> for proper operation.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v4 5/8] net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
From: Florian Fainelli @ 2018-08-02 1:39 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1533171233-14557-6-git-send-email-arun.parameswaran@broadcom.com>
On 08/01/2018 05:53 PM, Arun Parameswaran wrote:
> Use devm_mdiobus_alloc() instead of mdiobus_alloc() in the Broadcom
> iProc mdio mux driver.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-08-01 23:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, caleb.raitto, Jason Wang, Network Development,
Caleb Raitto
In-Reply-To: <20180802014755-mutt-send-email-mst@kernel.org>
On Wed, Aug 1, 2018 at 6:48 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Aug 01, 2018 at 06:43:53PM -0400, Willem de Bruijn wrote:
> > > > So e.g. we could set an affinity hint to a group of CPUs that
> > > > > might transmit to this queue.
> > > >
> > > > We also want to set the xps mask for all cpus in the group to this queue.
> > > >
> > > > Is there a benefit over explicitly choosing one cpu from the set, btw?
> > >
> > > If only one CPU actually transmits on this queue then probably yes.
> > > And virtio doesn't know whether that's the case.
> >
> > Oh, yes, good example.
> >
> > To plumb that through, vp_set_vq_affinity would have to take a cpu
> > mask like irq_set_affinity_hint, instead of a single value.
> >
> > Though I don't suggest doing that as part of the core
> > virtnet_set_affinity changes.
>
> Why not? It seems a reasonable thing to do.
Well, at least let's split it into separate patches.
^ permalink raw reply
* Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31
From: Saeed Mahameed @ 2018-08-01 23:13 UTC (permalink / raw)
To: Alexander Duyck
Cc: Saeed Mahameed, David S. Miller, Netdev, Jiri Pirko,
Jakub Kicinski, Bjorn Helgaas
In-Reply-To: <CAKgT0UdsCfr61K=+oBu6WkKm5A7a5MBC6UBrYa0cbXz=tBwGkw@mail.gmail.com>
On Wed, Aug 1, 2018 at 3:34 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, Aug 1, 2018 at 2:52 PM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>> Hi Dave,
>>
>> This series provides devlink parameters updates to both devlink API and
>> mlx5 driver, it is a 2nd iteration of the dropped patches sent in a previous
>> mlx5 submission "net/mlx5: Support PCIe buffer congestion handling via
>> Devlink" to address review comments [1].
>>
>> Changes from the original series:
>> - According to the discussion outcome, we are keeping the congestion control
>> setting as mlx5 device specific for the current HW generation.
>> - Changed the congestion_mode and congestion action param type to string
>> - Added patches to fix devlink handling of param type string
>> - Added a patch which adds extack messages support for param set.
>> - At the end of this series, I've added yet another mlx5 devlink related
>> feature, firmware snapshot support.
>>
>> For more information please see tag log below.
>>
>> Please pull and let me know if there's any problem.
>>
>> [1] https://patchwork.ozlabs.org/patch/945996/
>>
>> Thanks,
>> Saeed.
>>
>> ---
>>
>> The following changes since commit e6476c21447c4b17c47e476aade6facf050f31e8:
>>
>> net: remove bogus RCU annotations on socket.wq (2018-07-31 12:40:22 -0700)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2018-08-01
>>
>> for you to fetch changes up to 2ac6108c65ffcb1e5eab1fba1fd59272604d1c32:
>>
>> net/mlx5: Use devlink region_snapshot parameter (2018-08-01 14:49:09 -0700)
>>
>> ----------------------------------------------------------------
>> mlx5-updates-2018-08-01
>>
>> This series provides devlink parameters updates to both devlink API and
>> mlx5 driver,
>>
>> 1) Devlink changes: (Moshe Shemesh)
>> The first two patches fix devlink param infrastructure for string type
>> params.
>> The third patch adds a devlink helper function to safely copy string from
>> driver to devlink.
>> The forth patch adds extack support for param set.
>>
>> 2) mlx5 specific congestion parameters: (Eran Ben Elisha)
>> Next three patches add new devlink driver specific params for controlling
>> congestion action and mode, using string type params and extack messages support.
>>
>> This congestion mode enables hw workaround in specific devices which is
>> controlled by devlink driver-specific params. The workaround is device
>> specific for this NIC generation, the next NIC will not need it.
>>
>> Congestion parameters:
>> - Congestion action
>> HW W/A mechanism in the PCIe buffer which monitors the amount of
>> consumed PCIe buffer per host. This mechanism supports the
>> following actions in case of threshold overflow:
>> - Disabled - NOP (Default)
>> - Drop
>> - Mark - Mark CE bit in the CQE of received packet
>> - Congestion mode
>> - Aggressive - Aggressive static trigger threshold (Default)
>> - Dynamic - Dynamically change the trigger threshold
>>
>> 3) mlx5 firmware snapshot support via devlink: (Alex Vesker)
>> Last three patches, add the support for capturing region snapshot of the
>> firmware crspace during critical errors, using devlink region_snapshot
>> parameter.
>>
>> -Saeed.
>>
>> ----------------------------------------------------------------
>> Alex Vesker (3):
>> net/mlx5: Add Vendor Specific Capability access gateway
>> net/mlx5: Add Crdump FW snapshot support
>> net/mlx5: Use devlink region_snapshot parameter
>>
>> Eran Ben Elisha (3):
>> net/mlx5: Move all devlink related functions calls to devlink.c
>> net/mlx5: Add MPEGC register configuration functionality
>> net/mlx5: Enable PCIe buffer congestion handling workaround via devlink
>>
>> Moshe Shemesh (4):
>> devlink: Fix param set handling for string type
>> devlink: Fix param cmode driverinit for string type
>> devlink: Add helper function for safely copy string param
>> devlink: Add extack messages support to param set
>>
>> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 3 +-
>> drivers/net/ethernet/mellanox/mlx4/main.c | 6 +-
>> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 3 +-
>> drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 388 +++++++++++++++++++++
>> drivers/net/ethernet/mellanox/mlx5/core/devlink.h | 13 +
>> .../net/ethernet/mellanox/mlx5/core/diag/crdump.c | 223 ++++++++++++
>> drivers/net/ethernet/mellanox/mlx5/core/health.c | 3 +
>> drivers/net/ethernet/mellanox/mlx5/core/lib/mlx5.h | 4 +
>> .../net/ethernet/mellanox/mlx5/core/lib/pci_vsc.c | 320 +++++++++++++++++
>> .../net/ethernet/mellanox/mlx5/core/lib/pci_vsc.h | 56 +++
>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 10 +-
>> include/linux/mlx5/driver.h | 5 +
>> include/net/devlink.h | 15 +-
>> net/core/devlink.c | 44 ++-
>> 14 files changed, 1076 insertions(+), 17 deletions(-)
>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.c
>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.h
>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/diag/crdump.c
>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/pci_vsc.c
>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/pci_vsc.h
>
> So after looking over the patch set the one thing I would ask for in
> this is some sort of documentation at a minimum. As a user I don't see
> how you can expect someone to be able to use this when the naming of
> things are pretty cryptic and there is no real explanation anywhere if
> you don't go through and read the patch description itself. When you
> start adding driver specific interfaces, you should at least start
> adding vendor specific documentation.
>
Sure, sounds like a great idea, something like:
Documentation/networking/mlx5.txt and have a devlink section ?
or have a generic devlink doc and a mlx5 section in it ?
> Also I don't see how using a vendor specific configuration space
> section can be done without adding some tie-ins to the PCI core files
> because it should be possible to race with someone poking at the
> register space via something like setpci/lspci. Also one of the things
> that came up was that drivers are not supposed to be banging on the
> PCI configuration space at will, and it seems like this patch set is
> doing exactly that through the VSC block.
>
this is a whole different feature than the device specific parameters.
The whole vendor specific configuration space access is needed only
for diagnostic/dump
purposes when something really bad happens and the command interface
with FW is down,
and when the FW is un-responsive, we want to dump the crspace into the
already existing devlink
crdump buffer, how do you expect us to read it if we are not allowed
to access it ?
What do you mean by tie-ins to the PCI core files ? can you please elaborate ?
> - Alex
^ permalink raw reply
* [PATCH v4 8/8] net: phy: Add pm support to Broadcom iProc mdio mux driver
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Add support for suspend and resume to the Broadcom iProc mdio
mux driver.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index c608e3c4..518f4c7 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -286,6 +286,32 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mdio_mux_iproc_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(md->core_clk);
+
+ return 0;
+}
+
+static int mdio_mux_iproc_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+
+ clk_prepare_enable(md->core_clk);
+ mdio_mux_iproc_config(md);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(mdio_mux_iproc_pm_ops,
+ mdio_mux_iproc_suspend, mdio_mux_iproc_resume);
+
static const struct of_device_id mdio_mux_iproc_match[] = {
{
.compatible = "brcm,mdio-mux-iproc",
@@ -298,6 +324,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
.driver = {
.name = "mdio-mux-iproc",
.of_match_table = mdio_mux_iproc_match,
+ .pm = &mdio_mux_iproc_pm_ops,
},
.probe = mdio_mux_iproc_probe,
.remove = mdio_mux_iproc_remove,
--
1.9.1
^ permalink raw reply related
* [PATCH v4 7/8] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Add support to configure the internal rate adjust register based on the
core clock supplied through device tree in the Broadcom iProc mdio mux.
The operating frequency of the mdio mux block is 11MHz. This is derrived
by dividing the clock to the mdio mux with the rate adjust register.
In some SoC's the default values of the rate adjust register do not yield
11MHz. These SoC's are required to specify the clock via the device tree
for proper operation.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 41 ++++++++++++++++++++++++++++++++++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index 3ba9616..c608e3c4 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -13,7 +13,7 @@
* You should have received a copy of the GNU General Public License
* version 2 (GPLv2) along with this source code.
*/
-
+#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/device.h>
#include <linux/of_mdio.h>
@@ -22,6 +22,10 @@
#include <linux/mdio-mux.h>
#include <linux/delay.h>
+#define MDIO_RATE_ADJ_EXT_OFFSET 0x000
+#define MDIO_RATE_ADJ_INT_OFFSET 0x004
+#define MDIO_RATE_ADJ_DIVIDENT_SHIFT 16
+
#define MDIO_SCAN_CTRL_OFFSET 0x008
#define MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR 28
@@ -49,21 +53,38 @@
#define MDIO_REG_ADDR_SPACE_SIZE 0x250
+#define MDIO_OPERATING_FREQUENCY 11000000
+#define MDIO_RATE_ADJ_DIVIDENT 1
+
struct iproc_mdiomux_desc {
void *mux_handle;
void __iomem *base;
struct device *dev;
struct mii_bus *mii_bus;
+ struct clk *core_clk;
};
static void mdio_mux_iproc_config(struct iproc_mdiomux_desc *md)
{
+ u32 divisor;
u32 val;
/* Disable external mdio master access */
val = readl(md->base + MDIO_SCAN_CTRL_OFFSET);
val |= BIT(MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR);
writel(val, md->base + MDIO_SCAN_CTRL_OFFSET);
+
+ if (md->core_clk) {
+ /* use rate adjust regs to derrive the mdio's operating
+ * frequency from the specified core clock
+ */
+ divisor = clk_get_rate(md->core_clk) / MDIO_OPERATING_FREQUENCY;
+ divisor = divisor / (MDIO_RATE_ADJ_DIVIDENT + 1);
+ val = divisor;
+ val |= MDIO_RATE_ADJ_DIVIDENT << MDIO_RATE_ADJ_DIVIDENT_SHIFT;
+ writel(val, md->base + MDIO_RATE_ADJ_EXT_OFFSET);
+ writel(val, md->base + MDIO_RATE_ADJ_INT_OFFSET);
+ }
}
static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
@@ -204,6 +225,19 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ md->core_clk = devm_clk_get(&pdev->dev, NULL);
+ if (md->core_clk == ERR_PTR(-ENOENT) ||
+ md->core_clk == ERR_PTR(-EINVAL))
+ md->core_clk = NULL;
+ else if (IS_ERR(md->core_clk))
+ return PTR_ERR(md->core_clk);
+
+ rc = clk_prepare_enable(md->core_clk);
+ if (rc) {
+ dev_err(&pdev->dev, "failed to enable core clk\n");
+ return rc;
+ }
+
bus = md->mii_bus;
bus->priv = md;
bus->name = "iProc MDIO mux bus";
@@ -217,7 +251,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
rc = mdiobus_register(bus);
if (rc) {
dev_err(&pdev->dev, "mdiomux registration failed\n");
- return rc;
+ goto out_clk;
}
platform_set_drvdata(pdev, md);
@@ -236,6 +270,8 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
out_register:
mdiobus_unregister(bus);
+out_clk:
+ clk_disable_unprepare(md->core_clk);
return rc;
}
@@ -245,6 +281,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
mdio_mux_uninit(md->mux_handle);
mdiobus_unregister(md->mii_bus);
+ clk_disable_unprepare(md->core_clk);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v4 6/8] dt-bindings: net: Add clock handle to Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Add clock phandle, of the core clock driving the mdio block, as an
optional property to the Broadcom iProc mdio mux.
The clock, when specified, will be used to setup the rate adjust registers
in the mdio to derrive the mdio's operating frequency.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
index dc8aa68..b58843f 100644
--- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
+++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
@@ -13,6 +13,9 @@ MDIO multiplexer node:
Every non-ethernet PHY requires a compatible so that it could be probed based
on this compatible string.
+Optional properties:
+- clocks: phandle of the core clock which drives the mdio block.
+
Additional information regarding generic multiplexer properties can be found
at- Documentation/devicetree/bindings/net/mdio-mux.txt
--
1.9.1
^ permalink raw reply related
* [PATCH v4 5/8] net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Use devm_mdiobus_alloc() instead of mdiobus_alloc() in the Broadcom
iProc mdio mux driver.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index c36ce4b..3ba9616 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -198,7 +198,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
return PTR_ERR(md->base);
}
- md->mii_bus = mdiobus_alloc();
+ md->mii_bus = devm_mdiobus_alloc(&pdev->dev);
if (!md->mii_bus) {
dev_err(&pdev->dev, "mdiomux bus alloc failed\n");
return -ENOMEM;
@@ -217,7 +217,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
rc = mdiobus_register(bus);
if (rc) {
dev_err(&pdev->dev, "mdiomux registration failed\n");
- goto out;
+ return rc;
}
platform_set_drvdata(pdev, md);
@@ -236,8 +236,6 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
out_register:
mdiobus_unregister(bus);
-out:
- mdiobus_free(bus);
return rc;
}
@@ -247,7 +245,6 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
mdio_mux_uninit(md->mux_handle);
mdiobus_unregister(md->mii_bus);
- mdiobus_free(md->mii_bus);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/8] arm64: dts: Fix the base address of the Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Modify the base address of the mdio mux driver to point to the
start of the mdio mux block's register address space.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4057197..1a406a7 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -482,9 +482,9 @@
status = "disabled";
};
- mdio_mux_iproc: mdio-mux@6602023c {
+ mdio_mux_iproc: mdio-mux@66020000 {
compatible = "brcm,mdio-mux-iproc";
- reg = <0x6602023c 0x14>;
+ reg = <0x66020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index b203152..a70e8dd 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -278,9 +278,9 @@
#include "stingray-pinctrl.dtsi"
- mdio_mux_iproc: mdio-mux@2023c {
+ mdio_mux_iproc: mdio-mux@20000 {
compatible = "brcm,mdio-mux-iproc";
- reg = <0x0002023c 0x14>;
+ reg = <0x00020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/8] net: phy: Fix the register offsets in Broadcom iProc mdio mux driver
From: Arun Parameswaran @ 2018-08-02 0:53 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533171233-14557-1-git-send-email-arun.parameswaran@broadcom.com>
Modify the register offsets in the Broadcom iProc mdio mux to start
from the top of the register address space.
Earlier, the base address pointed to the end of the block's register
space. The base address will now point to the start of the mdio's
address space. The offsets have been fixed to match this.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index 0831b71..48bb74a 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -22,7 +22,7 @@
#include <linux/mdio-mux.h>
#include <linux/delay.h>
-#define MDIO_PARAM_OFFSET 0x00
+#define MDIO_PARAM_OFFSET 0x23c
#define MDIO_PARAM_MIIM_CYCLE 29
#define MDIO_PARAM_INTERNAL_SEL 25
#define MDIO_PARAM_BUS_ID 22
@@ -30,20 +30,22 @@
#define MDIO_PARAM_PHY_ID 16
#define MDIO_PARAM_PHY_DATA 0
-#define MDIO_READ_OFFSET 0x04
+#define MDIO_READ_OFFSET 0x240
#define MDIO_READ_DATA_MASK 0xffff
-#define MDIO_ADDR_OFFSET 0x08
+#define MDIO_ADDR_OFFSET 0x244
-#define MDIO_CTRL_OFFSET 0x0C
+#define MDIO_CTRL_OFFSET 0x248
#define MDIO_CTRL_WRITE_OP 0x1
#define MDIO_CTRL_READ_OP 0x2
-#define MDIO_STAT_OFFSET 0x10
+#define MDIO_STAT_OFFSET 0x24c
#define MDIO_STAT_DONE 1
#define BUS_MAX_ADDR 32
#define EXT_BUS_START_ADDR 16
+#define MDIO_REG_ADDR_SPACE_SIZE 0x250
+
struct iproc_mdiomux_desc {
void *mux_handle;
void __iomem *base;
@@ -169,6 +171,14 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
md->dev = &pdev->dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res->start & 0xfff) {
+ /* For backward compatibility in case the
+ * base address is specified with an offset.
+ */
+ dev_info(&pdev->dev, "fix base address in dt-blob\n");
+ res->start &= ~0xfff;
+ res->end = res->start + MDIO_REG_ADDR_SPACE_SIZE - 1;
+ }
md->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(md->base)) {
dev_err(&pdev->dev, "failed to ioremap register\n");
--
1.9.1
^ 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