* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Knut Omang @ 2017-12-18 13:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Stephen Hemminger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mauro Carvalho Chehab, Nicolas Palix, Jonathan Corbet,
Santosh Shilimkar, Matthew Wilcox, cocci-/FJkirnvOdkvYVN+rsErww,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Doug Ledford,
Mickaël Salaün, Shuah Khan,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA, Michal Marek, Julia Lawall,
John Haxby, Åsmund Østvold, Masahiro Yamada
In-Reply-To: <20171218050043.GA1307-uk2M96/98Pc@public.gmane.org>
On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
>
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all subsystems should be treated equally.
> >
> > This is a tool to enable automated testing for as many checks as
> > possible, as soon as possible. Like any tool, it can be misused, but
> > that's IMHO an orthogonal problem that I think the maintainers will
> > be more than capable of preventing.
> >
> > Think of this as a tightening screw: We eliminate errors class by
> > class or file by file, and in the same commit narrows in the list of
> > exceptions. That way we can fix issues piece by piece while avoiding
> > a lot of regressions in already clean parts.
>
> Since you used drivers/infiniband as an example for this script..
>
> I will say I agree with this idea.
> It is not that we *want* infiniband to be different from the rest of
> the kernel, it is that we have this historical situation where we
> don't have a code base that already passes the various static checker
> things.
I poked around trying make M= in different parts of the kernel to get some
"mileage" and to get as much examples as possible, and it appears most of
the kernel has issues of sorts. Also Joe and others keep adding more checks
as well, and we'd want that process to coexist with the need for automatic
regression testing in this area.
> I would like it very much if I could run 'make static checker' and see
> no warnings.
which is just what is the result with 'make C=2 M=drivers/infiniband/core'
and the patches #1 and #5 in this set in case not everyone got the point,
> This helps me know that I when I accept patches I am not
> introducing new problems to code that has already been cleaned up.
>
> Today when we run checkers we get so many warnings it is too hard to
> make any sense of it.
>
> Being able to say File X is now clean for check XYZ seems very useful
> and may motivate people to clean up the files they actualy care
> about...
>
> > > There was discussion at Kernel Summit about how the different
> > > subsystems already have different rules. This appears to be a way
> > > to make that worse.
> >
> > IMHO this is a tool that should help maintainers implement the
> > policies they desire. But the tool itself does not dictate any
> > such.
>
> Yes, again, in infiniband we like to see checkpatch be good for new
> submission, even if that clashes with surrounding code. For instance
> we have a mixture of sizeof foo and sizeof(foo) styles in the same
> file/function now.
That's one of the fixes that the excellent --fix-inplace handles so
one of my patches here
https://github.com/torvalds/linux/compare/master...knuto:runchecks
fixes those in drivers/infiniband/core.
> I certainly don't want to tell people they need to follow some
> different style from 10 years ago when they send patches.
>
Thanks,
Knut
> Jason
--
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
* [PATCH] wil6210: fix build warnings without CONFIG_PM
From: Arnd Bergmann @ 2017-12-18 13:45 UTC (permalink / raw)
To: Maya Erez, Kalle Valo
Cc: Arnd Bergmann, Lazar Alexei, Dedy Lansky, Hamad Kadmany,
Lior David, Gidon Studinski, linux-wireless, wil6210, netdev,
linux-kernel
The #ifdef checks are hard to get right, in this case some functions
should have been left inside a CONFIG_PM_SLEEP check as seen by this
message:
drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
Using an __maybe_unused is easier here, so I'm replacing all the
other #ifdef in this file as well for consistency.
Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 25 ++++++++-----------------
drivers/net/wireless/ath/wil6210/wil6210.h | 2 --
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 42a5480c764d..9e622ddcc0bb 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -31,10 +31,8 @@ static bool ftm_mode;
module_param(ftm_mode, bool, 0444);
MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false");
-#ifdef CONFIG_PM
static int wil6210_pm_notify(struct notifier_block *notify_block,
unsigned long mode, void *unused);
-#endif /* CONFIG_PM */
static
void wil_set_capabilities(struct wil6210_priv *wil)
@@ -307,15 +305,15 @@ static int wil_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto bus_disable;
}
-#ifdef CONFIG_PM
- wil->pm_notify.notifier_call = wil6210_pm_notify;
+ if (IS_ENABLED(CONFIG_PM))
+ wil->pm_notify.notifier_call = wil6210_pm_notify;
+
rc = register_pm_notifier(&wil->pm_notify);
if (rc)
/* Do not fail the driver initialization, as suspend can
* be prevented in a later phase if needed
*/
wil_err(wil, "register_pm_notifier failed: %d\n", rc);
-#endif /* CONFIG_PM */
wil6210_debugfs_init(wil);
@@ -346,9 +344,7 @@ static void wil_pcie_remove(struct pci_dev *pdev)
wil_dbg_misc(wil, "pcie_remove\n");
-#ifdef CONFIG_PM
unregister_pm_notifier(&wil->pm_notify);
-#endif /* CONFIG_PM */
wil_pm_runtime_forbid(wil);
@@ -372,8 +368,6 @@ static const struct pci_device_id wil6210_pcie_ids[] = {
};
MODULE_DEVICE_TABLE(pci, wil6210_pcie_ids);
-#ifdef CONFIG_PM
-
static int wil6210_suspend(struct device *dev, bool is_runtime)
{
int rc = 0;
@@ -481,17 +475,17 @@ static int wil6210_pm_notify(struct notifier_block *notify_block,
return rc;
}
-static int wil6210_pm_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_suspend(struct device *dev)
{
return wil6210_suspend(dev, false);
}
-static int wil6210_pm_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_resume(struct device *dev)
{
return wil6210_resume(dev, false);
}
-static int wil6210_pm_runtime_idle(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -501,12 +495,12 @@ static int wil6210_pm_runtime_idle(struct device *dev)
return wil_can_suspend(wil, true);
}
-static int wil6210_pm_runtime_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_resume(struct device *dev)
{
return wil6210_resume(dev, true);
}
-static int wil6210_pm_runtime_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -518,15 +512,12 @@ static int wil6210_pm_runtime_suspend(struct device *dev)
return wil6210_suspend(dev, true);
}
-#endif /* CONFIG_PM */
static const struct dev_pm_ops wil6210_pm_ops = {
-#ifdef CONFIG_PM
SET_SYSTEM_SLEEP_PM_OPS(wil6210_pm_suspend, wil6210_pm_resume)
SET_RUNTIME_PM_OPS(wil6210_pm_runtime_suspend,
wil6210_pm_runtime_resume,
wil6210_pm_runtime_idle)
-#endif /* CONFIG_PM */
};
static struct pci_driver wil6210_driver = {
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index cf27d9711dde..366a6ef222dc 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -742,9 +742,7 @@ struct wil6210_priv {
int fw_calib_result;
-#ifdef CONFIG_PM
struct notifier_block pm_notify;
-#endif /* CONFIG_PM */
bool suspend_resp_rcvd;
bool suspend_resp_comp;
--
2.9.0
^ permalink raw reply related
* Re: Wifi RTL8723bu driver test: failed to scan
From: Mylene JOSSERAND @ 2017-12-18 13:47 UTC (permalink / raw)
To: Jes Sorensen
Cc: kvalo, linux-wireless, netdev, Thomas Petazzoni, Maxime Ripard
In-Reply-To: <75669dd0-1f25-fc7e-4a4d-a5549aeeb2cf@gmail.com>
Hello Jes,
Le Tue, 28 Nov 2017 11:14:10 -0500,
Jes Sorensen <jes.sorensen@gmail.com> a écrit :
> On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> > Hello Jes Sorensen,
> >
> > I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> > SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> > driver RTL8723BU for this USB dongle.
> >
> > Currently, I am only testing the Wifi and the mainline driver (kernel
> > 4.14-rc7) does not seem to work. At least, the scanning does not output
> > anything.
> >
> > I tested the driver recommended by LM Technologies [3] and it works
> > fine (scan, connect and ping are ok). Before investigating on the
> > differences between these two drivers, do you have any idea about this
> > issue?
> >
> > Here are the commands and output I got with mainline's driver:
>
> I have not looked at the driver these LM Technologies people are
> referring to, but I am guessing it's the vendor code.
>
> 8723bu is a little dicey because it has BT in the chip and if you enable
> that the two drivers need to interact, which rtl8xxxu currently doesn't
> know about. Check your dmesg output to make sure you don't have some BT
> thing loaded hijacking the chip.
I finally tested it again without any BT stuff enabled and I am still
not having any output on scanning.
I added DEBUG support to have all dev_dbg outputs for rtl8xxxu (core
and 8723b). Here is the log of boot and different iw commands:
http://code.bulix.org/56345t-242970?raw
Do you have any idea/hint to give me?
I checked the firmware: I am using the last one from linux-firmware's
repository. Have you already tried this chip? With which firmware?
Thank you very much for any help.
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit
From: Sowmini Varadhan @ 2017-12-18 13:55 UTC (permalink / raw)
To: syzbot; +Cc: netdev, rds-devel, syzkaller-bugs
In-Reply-To: <001a1145ac5480242305609956b3@google.com>
On (12/18/17 00:43), syzbot wrote:
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> program syz-executor6 is using a deprecated SCSI ioctl, please convert it to
> SG_IO
> IP: rds_send_xmit+0x80/0x930 net/rds/send.c:186
conn->c_trans is at offset 0x28.
Both this and https://marc.info/?l=linux-netdev&m=151360062922798&w=2
are manifestations of the same bug: somehow the cp_send_w is still
getting queued incorrectly after the conn destroy is initiated (commit
681648e67d fixes one such window, maybe there are others).
Let me look at how this slipped through the cracks.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Linus Walleij @ 2017-12-18 13:57 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, Linux ARM, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij, Tobias Waldvogel
In-Reply-To: <20171216193911.6938-2-linus.walleij@linaro.org>
On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The Gemini ethernet has been around for years as an out-of-tree
> patch used with the NAS boxen and routers built on StorLink
> SL3512 and SL3516, later Storm Semiconductor, later Cortina
> Systems. These ASICs are still being deployed and brand new
> off-the-shelf systems using it can easily be acquired.
>
> The full name of the IP block is "Net Engine and Gigabit
> Ethernet MAC" commonly just called "GMAC".
>
> The hardware block contains a common TCP Offload Enginer (TOE)
> that can be used by both MACs. The current driver does not use
> it.
>
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes from v8:
> - Remove dependency guards in Kconfig to get a wider compile
> coverage for the driver to detect broken APIs etc.
I guess we need to hold this off for a while, the code does
some weird stuff using the ARM-internal page DMA mapping
API.
I *think* what happens is that the driver allocates a global queue
used for RX and TX on both interfaces, then initializes that with
page pointers and gives that to the hardware to play with.
When an RX packet comes in, the RX routine needs to figure
out from the DMA (physical) address which remapped
page/address this random physical address pointer
corresponds to.
The Linux DMA API assumption is that the driver keeps track
of this mapping, not the hardware. So we need to figure out
a way to reverse-map this. Preferably quickly, and without
using any ARM-internal mapping APIs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH][next] bpf: fix spelling mistake: "funcation"-> "function"
From: Colin King @ 2017-12-18 14:03 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in error message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 6d8e432453b8..2f6f09cd1925 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -772,7 +772,7 @@ static int check_subprogs(struct bpf_verifier_env *env)
return -EPERM;
}
if (bpf_prog_is_dev_bound(env->prog->aux)) {
- verbose(env, "funcation calls in offloaded programs are not supported yet\n");
+ verbose(env, "function calls in offloaded programs are not supported yet\n");
return -EINVAL;
}
ret = add_subprog(env, i + insn[i].imm + 1);
--
2.14.1
^ permalink raw reply related
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Rafael J. Wysocki @ 2017-12-18 14:09 UTC (permalink / raw)
To: Marcin Wojtas, linux-kernel, linux-arm-kernel, netdev
Cc: davem, linux, andrew, f.fainelli, antoine.tenart,
thomas.petazzoni, gregory.clement, ezequiel.garcia, nadavh, neta,
ard.biesheuvel, jaz, tn
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
On 12/18/2017 10:17 AM, Marcin Wojtas wrote:
> Hi,
>
> This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> First three patches introduce fwnode helpers for obtaining PHY
> information from nodes and also MDIO fwnode API for registering
> the bus with its PHY/devices.
>
> Following patches update code of the mvmdio and mvpp2 drivers
> to support ACPI tables handling. The latter is done in 4 steps,
> as can be seen in the commits. For the details, please
> refer to the commit messages.
>
> Drivers operation was tested on top of the net-next branch
> with both DT and ACPI. Although for compatibility reasons
> with older platforms, the mvmdio driver keeps using
> of_ MDIO registering, new fwnode_ one proved to fully work
> with DT as well (tested on MacchiatoBin board).
>
> mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> on a public branch:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> It was compiled together with the most recent Tianocore EDK2 revision.
> Please refer to the firmware build instruction on MacchiatoBin board:
> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>
> Above support configures 1G to use its PHY normally. 10G can work now
> only with the link interrupt mode. Somehow reading of the
> string property in fwnode_mdiobus_child_is_phy works only with
> DT and cannot cope with 10G PHY nodes as in:
> https://pastebin.com/3JnYpU0A
>
> Above root cause will be further checked. In the meantime I will
> appreciate any comments or remarks for the kernel patches.
>
> Best regards,
> Marcin
>
> Marcin Wojtas (8):
> device property: Introduce fwnode_get_mac_address()
> device property: Introduce fwnode_get_phy_mode()
> mdio_bus: Introduce fwnode MDIO helpers
> net: mvmdio: add ACPI support
> net: mvpp2: simplify maintaining enabled ports' list
> net: mvpp2: use device_*/fwnode_* APIs instead of of_*
> net: mvpp2: handle PHY with its fwnode
> net: mvpp2: enable ACPI support in the driver
>
> drivers/base/property.c | 52 +++--
> drivers/net/ethernet/marvell/mvmdio.c | 42 +++-
> drivers/net/ethernet/marvell/mvpp2.c | 246 ++++++++++++--------
> drivers/net/phy/mdio_bus.c | 218 +++++++++++++++++
> include/linux/mdio.h | 3 +
> include/linux/property.h | 3 +
> 6 files changed, 454 insertions(+), 110 deletions(-)
>
Please CC linux-acpi on all submissions of patches touching ACPI,
property.c or property.h.
Thanks!
^ permalink raw reply
* RE: [PATCH 25/27] qede: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-26-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 25/27] qede: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update qede_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <Ariel.Elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.c b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
index 0d054dc..c2de311 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
@@ -129,9 +129,9 @@ static int qede_ptp_settime(struct ptp_clock_info *info,
DP_VERBOSE(edev, QED_MSG_DEBUG, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
+ /* Reset the timecounter */
spin_lock_bh(&ptp->lock);
- timecounter_init(&ptp->tc, ns);
+ timecounter_reset(&ptp->tc, ns);
spin_unlock_bh(&ptp->lock);
return 0;
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 18/27] bnx2x: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-19-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 18/27] bnx2x: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update bnx2x_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <ariel.elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1e10a81..e30e736 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13849,8 +13849,8 @@ static int bnx2x_ptp_settime(struct ptp_clock_info *ptp,
DP(BNX2X_MSG_PTP, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
- timecounter_init(&bp->timecounter, ns);
+ /* Reset the timecounter */
+ timecounter_reset(&bp->timecounter, ns);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] cxgb4: Report tid start range correctly for T6
From: Ganesh Goudar @ 2017-12-18 14:15 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Arjun Vynipadath
For T6, tid start range should be read from
LE_DB_ACTIVE_TABLE_START_INDEX_A register.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 4956e42..d8efcd9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2668,10 +2668,14 @@ static const struct file_operations mem_debugfs_fops = {
static int tid_info_show(struct seq_file *seq, void *v)
{
+ unsigned int tid_start = 0;
struct adapter *adap = seq->private;
const struct tid_info *t = &adap->tids;
enum chip_type chip = CHELSIO_CHIP_VERSION(adap->params.chip);
+ if (chip > CHELSIO_T5)
+ tid_start = t4_read_reg(adap, LE_DB_ACTIVE_TABLE_START_INDEX_A);
+
if (t4_read_reg(adap, LE_DB_CONFIG_A) & HASHEN_F) {
unsigned int sb;
seq_printf(seq, "Connections in use: %u\n",
@@ -2683,8 +2687,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
sb = t4_read_reg(adap, LE_DB_SRVR_START_INDEX_A);
if (sb) {
- seq_printf(seq, "TID range: 0..%u/%u..%u", sb - 1,
- adap->tids.hash_base,
+ seq_printf(seq, "TID range: %u..%u/%u..%u", tid_start,
+ sb - 1, adap->tids.hash_base,
t->ntids - 1);
seq_printf(seq, ", in use: %u/%u\n",
atomic_read(&t->tids_in_use),
@@ -2709,7 +2713,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
seq_printf(seq, "Connections in use: %u\n",
atomic_read(&t->conns_in_use));
- seq_printf(seq, "TID range: 0..%u", t->ntids - 1);
+ seq_printf(seq, "TID range: %u..%u", tid_start,
+ tid_start + t->ntids - 1);
seq_printf(seq, ", in use: %u\n",
atomic_read(&t->tids_in_use));
}
--
2.1.0
^ permalink raw reply related
* pull-request: wireless-drivers-next 2017-12-18
From: Kalle Valo @ 2017-12-18 14:17 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
luciano.coelho-ral2JQCrhuEAvxtiuMwx3w
Hi Dave,
a pull request for 4.16 to net-next tree. This is a big one, but on the
other hand most of the stuff here has been some time on linux-next so
hopefully there are no nasty surprises. Even though Arnd just send a
patch[1] five minutes ago about fixing a wcn36xx build warning, but I
don't think that's critical enough to hold up this, so I'll send it to
you in the next pull request.
But this time we actually have a merge conflict due to a000 hardware
rename in iwlwifi:
CONFLICT (content): Merge conflict in drivers/net/wireless/intel/iwlwifi/pcie/drv.c
The fix is quite straightforward, take the 22000 versions and manually
add an entry for 0xA0F0 device:
{IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
I put the 'git diff' output of my test resolution below, hopefully it
helps. I'll also Cc Luca so he can correct any mistakes I did :)
Please let me know if you have any problems.
[1] https://patchwork.kernel.org/patch/10119565/
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -652,20 -651,19 +652,20 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)},
- /* a000 Series */
- {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x34F0, 0x0310, iwla000_2ac_cfg_jf)},
- {IWL_PCI_DEVICE(0x2720, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0090, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0310, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x40C0, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwla000_2ax_cfg_hr)},
+ /* 22000 Series */
+ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0310, iwl22000_2ac_cfg_jf)},
+ {IWL_PCI_DEVICE(0x2720, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0070, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0078, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0070, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0030, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x1080, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0090, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0310, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwl22000_2ax_cfg_hr)},
++ {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
#endif /* CONFIG_IWLMVM */
The following changes since commit 0fc66ddfaf8bb8f73c965f24928f8815b470304e:
Documentation: net: dsa: Cut set_addr() documentation (2017-11-30 10:10:16 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-12-18
for you to fetch changes up to 1dde35d0b8e3a9fbf24e13d16dc583f1cc5d027b:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-12-14 18:38:48 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.16
A bigger pull request this time, the most visible change being the new
driver mt76. But there's also Kconfig refactoring in ath9k and ath10k,
work beginning in iwlwifi to have rate scaling in firmware/hardware,
wcn3990 support getting closer in ath10k and lots of smaller changes.
mt76
* a new driver for MT76x2e, a 2x2 PCIe 802.11ac chipset by MediaTek
ath10k
* enable multiqueue support for all hw using mac80211 wake_tx_queue op
* new Kconfig option ATH10K_SPECTRAL to save RAM
* show tx stats on QCA9880
* new qcom,ath10k-calibration-variant DT entry
* WMI layer support for wcn3990
ath9k
* new Kconfig option ATH9K_COMMON_SPECTRAL to save RAM
wcn36xx
* hardware scan offload support
wil6210
* run-time PM support when interface is down
iwlwifi
* initial work for rate-scaling offload
* Support for new FW API version 36
* Rename the temporary hw name A000 to 22000
ssb
* make SSB a menuconfig to ease disabling it all
mwl8k
* enable non-DFS 5G channels 149-165
----------------------------------------------------------------
Anilkumar Kolli (3):
ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics
ath10k: move pktlog_filter out of ath10k_debug
ath10k: add per peer tx stats support for 10.2.4
Arnd Bergmann (3):
wlcore: use boottime for fw time sync
ath10k: use 64-bit crash dump timestamps
wlcore: fix unused function warning
Ashish Kalra (1):
bcma: Adjust block comment
Avraham Stern (1):
iwlwifi: mvm: add WFA vendor specific TPC report IE to probe request
Balaji Pothunoori (1):
ath10k: handling qos at STA side based on AP WMM enable/disable
Ben Greear (1):
ath10k: fix invalid STS_CAP_OFFSET_MASK
Bjorn Andersson (1):
wcn36xx: Reduce spinlock in indication handler
Colin Ian King (3):
rtlwifi: rtl818x: remove redundant check for cck_power > 15
wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove error on -ENOMEM
brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events
Dan Carpenter (1):
ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
Dedy Lansky (1):
wil6210: print human readable names of WMI commands and events
Emmanuel Grumbach (5):
iwlwifi: mvm: rs: don't override the rate history in the search cycle
iwlwifi: mvm: revert support new Coex firmware API
iwlwifi: print the version number of the firmware in hex
iwlwifi: fix the ALIVE notification layout
iwlwifi: mvm: remove set but unused variable in iwl_mvm_roc_done_wk
Eyal Ilsar (1):
wcn36xx: set default BTLE coexistence config
Felix Fietkau (3):
dt-bindings: net: add mt76 wireless device binding
mt76: add common code shared between multiple chipsets
mt76: add driver code for MT76x2e
Gregory Greenman (7):
iwlwifi: mvm: rs: introduce new API for rate scaling
iwlwifi: mvm: rs: add ops for the new rate scaling in the FW
iwlwifi: mvm: rs: add basic implementation of the new RS API handlers
iwlwifi: mvm: rs: new rate scale API - add FW notifications
iwlwifi: mvm: rs: new rate scale API - add debugfs hooks
iwlwifi: mvm: rs: add size checks when printing to a buffer
iwlwifi: mvm: rs: add sanity check when sending LQ command
Gustavo A. R. Silva (1):
ath9k: dfs: use swap macro in ath9k_check_chirping
Hamad Kadmany (1):
wil6210: abort properly in cfg suspend
Ian Molton (20):
brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
brcmfmac: Register sizes on hardware are not dependent on compiler types
brcmfmac: Split brcmf_sdiod_regrw_helper() up.
brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
brcmfmac: Remove dead IO code
brcmfmac: Remove bandaid for SleepCSR
brcmfmac: Remove brcmf_sdiod_request_data()
brcmfmac: Fix asymmetric IO functions.
brcmfmac: Remove noisy debugging.
brcmfmac: Rename bcmerror to err
brcmfmac: Split brcmf_sdiod_buffrw function up.
brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
brcmfmac: Clarify if using braces.
brcmfmac: Rename / replace old IO functions with simpler ones.
brcmfmac: Tidy register definitions a little
brcmfmac: Remove brcmf_sdiod_addrprep()
brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()
brcmfmac: Cleanup offsetof()
brcmfmac: Remove unused macro.
brcmfmac: Remove repeated calls to brcmf_chip_get_core()
Johannes Berg (3):
iwlwifi: mvm: remove TCP wakeup support
iwlwifi: mvm: remove superfluous flush_work()
iwlwifi: mvm: request statistics when reading debugfs
Jérémy Lefaure (1):
wireless: use ARRAY_SIZE
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2017-11-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2017-12-05' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Kenneth Lu (2):
ath6kl: remove redundant variable ies_len
ath6kl: improve endianness handling
Larry Finger (1):
rtlwifi: Convert individual interrupt results to struct
Lazar Alexei (5):
wil6210: run-time PM when interface down
wil6210: get suspend reject reason and resume triggers from FW
wil6210: fix PCIe bus mastering in case of interface down
wil6210: remove suspend time statistics
wil6210: update statistics for suspend
Liad Kaufman (3):
iwlwifi: mvm: support MGMT frames in compressed BA
iwlwifi: dbg: allow wrt collection before ALIVE
iwlwifi: mvm: make init_dbg effective only on failure
Limin Zhu (1):
mwifiex: cfg80211: do not change virtual interface during scan processing
Lior David (5):
wil6210: refresh FW capabilities during interface up
wil6210: fix length check in __wmi_send
wil6210: add block size checks during FW load
wil6210: missing length check in wmi_set_ie
wil6210: missing length check in wil_cfg80211_mgmt_tx
Loic Poulain (1):
wcn36xx: Add hardware scan offload support
Luca Coelho (3):
iwlwifi: rename the temporary name of A000 to the official 22000
iwlwifi: bump FW API to 36 for 8000 and up
iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports
Manikanta Pubbisetty (2):
ath10k: update tdls teardown state to target
ath10k: handle tdls peer events
Matthias Schiffer (2):
ath9k: move spectral scan support under a separate config symbol
ath10k: move spectral scan support under a separate config symbol
Nicolas Iooss (1):
rtlwifi: always initialize variables given to RT_TRACE()
Ping-Ke Shih (4):
rtlwifi: Reduce IO in RX interrupt to boost throughput
rtlwifi: fix the wrong size to calculate fifo space
rtlwifi: cleanup the code that check whether TX ring is available
rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet to HIQ
Rajkumar Manoharan (1):
ath10k: unify rx processing in napi_poll
Rakesh Pillai (4):
ath10k: wmi: modify svc bitmap parsing for wcn3990
ath10k: wmi: add management tx by reference support over wmi
ath10k: wmi: get wmi init parameter values from hw params
ath10k: wmi: add hw params entry for wcn3990
Reizer, Eyal (1):
wlcore: allow elp during wowlan suspend
Sara Sharon (2):
iwlwifi: mvm: check for short GI only for OFDM
iwlwifi: mvm: avoid dumping assert log when device is stopped
Sven Eckelmann (2):
dt: bindings: add new dt entry for ath10k calibration variant
ath10k: search DT for qcom,ath10k-calibration-variant
Toke Høiland-Jørgensen (1):
ath10k: re-enable TXQs for all devices
Tsang-Shian Lin (1):
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
Vincent Legoll (1):
ssb: make SSB a menuconfig to ease disabling it all
Weixiao Zhang (1):
mwl8k: Expand non-DFS 5G channels
Wright Feng (1):
brcmfmac: enlarge buffer size of caps to 512 bytes
Xinming Hu (1):
mwifiex: do not support change AP interface to station mode
.../bindings/net/wireless/mediatek,mt76.txt | 32 +
.../bindings/net/wireless/qcom,ath10k.txt | 3 +
drivers/bcma/driver_pcie2.c | 3 +-
drivers/net/wireless/ath/ath10k/Kconfig | 9 +-
drivers/net/wireless/ath/ath10k/Makefile | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 95 ++-
drivers/net/wireless/ath/ath10k/core.h | 10 +-
drivers/net/wireless/ath/ath10k/debug.c | 18 +-
drivers/net/wireless/ath/ath10k/debug.h | 21 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 27 -
drivers/net/wireless/ath/ath10k/htt.h | 19 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 181 +++--
drivers/net/wireless/ath/ath10k/hw.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 14 +
drivers/net/wireless/ath/ath10k/mac.c | 65 +-
drivers/net/wireless/ath/ath10k/spectral.h | 4 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 9 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 146 +++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 113 +++
drivers/net/wireless/ath/ath10k/wmi.c | 72 ++
drivers/net/wireless/ath/ath10k/wmi.h | 5 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 -
drivers/net/wireless/ath/ath6kl/txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 14 +-
drivers/net/wireless/ath/ath9k/Makefile | 4 +-
drivers/net/wireless/ath/ath9k/common-spectral.h | 4 +-
drivers/net/wireless/ath/ath9k/dfs.c | 8 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/wcn36xx/hal.h | 107 ++-
drivers/net/wireless/ath/wcn36xx/main.c | 16 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 126 +++-
drivers/net/wireless/ath/wcn36xx/smd.h | 3 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 17 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 150 +++-
drivers/net/wireless/ath/wil6210/ethtool.c | 15 +
drivers/net/wireless/ath/wil6210/fw_inc.c | 79 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 22 +-
drivers/net/wireless/ath/wil6210/main.c | 26 +-
drivers/net/wireless/ath/wil6210/netdev.c | 18 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 97 ++-
drivers/net/wireless/ath/wil6210/pm.c | 104 ++-
drivers/net/wireless/ath/wil6210/wil6210.h | 40 +-
drivers/net/wireless/ath/wil6210/wmi.c | 304 +++++++-
drivers/net/wireless/ath/wil6210/wmi.h | 17 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 377 +++------
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 12 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 248 +++---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 52 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 462 +++---------
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 216 ++++++
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 216 ------
drivers/net/wireless/intel/iwlwifi/fw/api/alive.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 30 -
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 2 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 262 ++++++-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 15 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 5 +-
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 20 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 33 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 232 +-----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 91 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 14 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 43 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 314 ++++++++
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 234 +++---
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 48 ++
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 35 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 7 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 36 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 +-
drivers/net/wireless/marvell/mwl8k.c | 7 +-
drivers/net/wireless/mediatek/Kconfig | 1 +
drivers/net/wireless/mediatek/Makefile | 1 +
drivers/net/wireless/mediatek/mt76/Kconfig | 10 +
drivers/net/wireless/mediatek/mt76/Makefile | 15 +
drivers/net/wireless/mediatek/mt76/debugfs.c | 77 ++
drivers/net/wireless/mediatek/mt76/dma.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/dma.h | 38 +
drivers/net/wireless/mediatek/mt76/eeprom.c | 112 +++
drivers/net/wireless/mediatek/mt76/mac80211.c | 393 ++++++++++
drivers/net/wireless/mediatek/mt76/mmio.c | 61 ++
drivers/net/wireless/mediatek/mt76/mt76.h | 360 +++++++++
drivers/net/wireless/mediatek/mt76/mt76x2.h | 227 ++++++
drivers/net/wireless/mediatek/mt76/mt76x2_core.c | 88 +++
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 133 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 493 ++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 80 ++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.c | 183 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.h | 68 ++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c | 647 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h | 182 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 839 +++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 755 ++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.h | 190 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 545 +++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h | 155 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_pci.c | 110 +++
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 758 +++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_regs.h | 587 ++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_trace.c | 23 +
drivers/net/wireless/mediatek/mt76/mt76x2_trace.h | 144 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 258 +++++++
drivers/net/wireless/mediatek/mt76/trace.c | 23 +
drivers/net/wireless/mediatek/mt76/trace.h | 71 ++
drivers/net/wireless/mediatek/mt76/tx.c | 511 +++++++++++++
drivers/net/wireless/mediatek/mt76/util.c | 78 ++
drivers/net/wireless/mediatek/mt76/util.h | 44 ++
.../net/wireless/realtek/rtl818x/rtl8187/rtl8225.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 75 +-
drivers/net/wireless/realtek/rtlwifi/pci.h | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 57 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 22 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/table.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/table.c | 34 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 11 +-
drivers/net/wireless/ti/wl1251/init.c | 4 +-
drivers/net/wireless/ti/wlcore/acx.c | 2 +-
drivers/net/wireless/ti/wlcore/acx.h | 2 -
drivers/net/wireless/ti/wlcore/main.c | 41 +-
drivers/net/wireless/ti/wlcore/tx.c | 4 +-
drivers/ssb/Kconfig | 9 +-
159 files changed, 12700 insertions(+), 2097 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
create mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/22000.c
delete mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/a000.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
create mode 100644 drivers/net/wireless/mediatek/mt76/Kconfig
create mode 100644 drivers/net/wireless/mediatek/mt76/Makefile
create mode 100644 drivers/net/wireless/mediatek/mt76/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mac80211.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mmio.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_pci.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_regs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.h
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:22 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: roopa, davem, stephen, avagin, bridge
In-Reply-To: <0d66d7ab-2837-afcb-430f-32f6e4a5d675@lab.ntt.co.jp>
On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
[snip]
> ...
>> err = br_changelink(dev, tb, data, extack);
>> - if (err)
>> + if (err) {
>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>
> Don't we need to call br_dev_delete (br_link_ops.dellink) after
> successful register instead of br_fdb_delete?
> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>
Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
Good catch, that is another leak - the bridge sysfs entries are registered when
NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
on error there. This has also been present since the introduction of changelink
during newlink, commit:
b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
With kobject debug enabled and that I can see "brif" and the rest of the sysfs
files getting freed properly, while before they weren't.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:23 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: bridge, roopa, avagin, davem
In-Reply-To: <4b07ce51-177d-df6f-f5ac-321f85402b6c@cumulusnetworks.com>
On 12/18/2017 04:22 PM, Nikolay Aleksandrov wrote:
> On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
>> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
> [snip]
>> ...
>>> err = br_changelink(dev, tb, data, extack);
>>> - if (err)
>>> + if (err) {
>>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>>
>> Don't we need to call br_dev_delete (br_link_ops.dellink) after
>> successful register instead of br_fdb_delete?
>> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>>
>
> Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
>
> Good catch, that is another leak - the bridge sysfs entries are registered when
> NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
> on error there. This has also been present since the introduction of changelink
> during newlink, commit:
> b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
err, since the changelink was fixed to be after device registration in commit:
5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
>
> I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
> With kobject debug enabled and that I can see "brif" and the rest of the sysfs
> files getting freed properly, while before they weren't.
>
> Thanks,
> Nik
>
^ permalink raw reply
* Re: [PATCH net] sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
From: Neil Horman @ 2017-12-18 14:33 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <047a7d68a197ff748b48eb8cda4b08fd5b9623fe.1513577245.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:07:25PM +0800, Xin Long wrote:
> Now when reneging events in sctp_ulpq_renege(), the variable freed
> could be increased by a __u16 value twice while freed is of __u16
> type. It means freed may overflow at the second addition.
>
> This patch is to fix it by using __u32 type for 'freed', while at
> it, also to remove 'if (chunk)' check, as all renege commands are
> generated in sctp_eat_data and it can't be NULL.
>
> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/ulpqueue.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index a71be33..e36ec5d 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -1084,29 +1084,21 @@ void sctp_ulpq_partial_delivery(struct sctp_ulpq *ulpq,
> void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
> gfp_t gfp)
> {
> - struct sctp_association *asoc;
> - __u16 needed, freed;
> -
> - asoc = ulpq->asoc;
> + struct sctp_association *asoc = ulpq->asoc;
> + __u32 freed = 0;
> + __u16 needed;
>
> - if (chunk) {
> - needed = ntohs(chunk->chunk_hdr->length);
> - needed -= sizeof(struct sctp_data_chunk);
> - } else
> - needed = SCTP_DEFAULT_MAXWINDOW;
> -
> - freed = 0;
> + needed = ntohs(chunk->chunk_hdr->length) -
> + sizeof(struct sctp_data_chunk);
>
> if (skb_queue_empty(&asoc->base.sk->sk_receive_queue)) {
> freed = sctp_ulpq_renege_order(ulpq, needed);
> - if (freed < needed) {
> + if (freed < needed)
> freed += sctp_ulpq_renege_frags(ulpq, needed - freed);
> - }
> }
> /* If able to free enough room, accept this chunk. */
> - if (chunk && (freed >= needed)) {
> - int retval;
> - retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> + if (freed >= needed) {
> + int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> /*
> * Enter partial delivery if chunk has not been
> * delivered; otherwise, drain the reassembly queue.
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] wil6210: fix build warnings without CONFIG_PM
From: Kalle Valo @ 2017-12-18 14:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: qca_merez, QCA_ailizaro, qca_dlansky, QCA_hkadmany, qca_liord,
QCA_gidons, linux-wireless@vger.kernel.org, wil6210,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20171218134604.3087909-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The #ifdef checks are hard to get right, in this case some functions
> should have been left inside a CONFIG_PM_SLEEP check as seen by this
> message:
>
> drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
> drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
>
> Using an __maybe_unused is easier here, so I'm replacing all the
> other #ifdef in this file as well for consistency.
>
> Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A note to myself (unfortunately patchwork doesn't have any way to add
notes to patches): 94162666cd51 is in wireless-drivers-next so this
patch should also go to -next.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net] sctp: add SCTP_CID_RECONF conversion in sctp_cname
From: Neil Horman @ 2017-12-18 14:37 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <ae9172b7dc432d6092ab2bc061a0cf322a3939b5.1513577597.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:13:17PM +0800, Xin Long wrote:
> Whenever a new type of chunk is added, the corresp conversion in
> sctp_cname should be added. Otherwise, in some places, pr_debug
> will print it as "unknown chunk".
>
> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/debug.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 3f619fd..291c97b 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -78,6 +78,9 @@ const char *sctp_cname(const union sctp_subtype cid)
> case SCTP_CID_AUTH:
> return "AUTH";
>
> + case SCTP_CID_RECONF:
> + return "RECONF";
> +
> default:
> break;
> }
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next] udp: handle gro_receive only when necessary
From: Paolo Abeni @ 2017-12-18 14:45 UTC (permalink / raw)
To: zhangliping; +Cc: davem, netdev, zhangliping
In-Reply-To: <1f4bfef5.b4c7.16069879c26.Coremail.zhanglkk1990@163.com>
On Mon, 2017-12-18 at 20:09 +0800, zhangliping wrote:
> My test case is very simple, two VMs were connected via ovs + dpdk.
> Inside VM, rps is enabled. Then one VM runs "iperf -s -u &", another
> VM runs "iperf -c 1.1.1.2 -P 12 -u -b 10Gbps -l 40 -t 36000".
Understood, thanks. Still the time spent in 'udp4_lib_lookup2' looks
quite different/higher than what I observe in my tests. Are you using
x86_64? if not, do you see many cache misses in udp4_lib_lookup2?
Thanks,
Paolo
^ permalink raw reply
* [PATCH RESEND] Bluetooth: Prevent stack info leak from the EFS element.
From: Greg Kroah-Hartman @ 2017-12-18 14:47 UTC (permalink / raw)
To: netdev
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Ben Seri,
linux-kernel
From: Ben Seri <ben@armis.com>
In the function l2cap_parse_conf_rsp and in the function
l2cap_parse_conf_req the following variable is declared without
initialization:
struct l2cap_conf_efs efs;
In addition, when parsing input configuration parameters in both of
these functions, the switch case for handling EFS elements may skip the
memcpy call that will write to the efs variable:
...
case L2CAP_CONF_EFS:
if (olen == sizeof(efs))
memcpy(&efs, (void *)val, olen);
...
The olen in the above if is attacker controlled, and regardless of that
if, in both of these functions the efs variable would eventually be
added to the outgoing configuration request that is being built:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs);
So by sending a configuration request, or response, that contains an
L2CAP_CONF_EFS element, but with an element length that is not
sizeof(efs) - the memcpy to the uninitialized efs variable can be
avoided, and the uninitialized variable would be returned to the
attacker (16 bytes).
This issue has been assigned CVE-2017-1000410
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/l2cap_core.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
David, can you take this through your tree? It fixes a reported issue
and the bluetooth developers seem to be totally ignoring it for weeks
for some unknown reason :(
Or, I can take it through one of mine if you don't want to touch it.
thanks,
greg k-h
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 43ba91c440bc..fc6615d59165 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3363,9 +3363,10 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
break;
case L2CAP_CONF_EFS:
- remote_efs = 1;
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
+ remote_efs = 1;
memcpy(&efs, (void *) val, olen);
+ }
break;
case L2CAP_CONF_EWS:
@@ -3584,16 +3585,17 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
break;
case L2CAP_CONF_EFS:
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
memcpy(&efs, (void *)val, olen);
- if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != chan->local_stype)
- return -ECONNREFUSED;
+ if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != chan->local_stype)
+ return -ECONNREFUSED;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs, endptr - ptr);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
+ (unsigned long) &efs, endptr - ptr);
+ }
break;
case L2CAP_CONF_FCS:
^ permalink raw reply related
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Michał Mirosław @ 2017-12-18 14:48 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Janos Laube, Paulius Zaleckas,
Linux ARM, Hans Ulli Kroll, Florian Fainelli, Tobias Waldvogel
In-Reply-To: <CACRpkdZ3t9ZDB-GOoriq0Jm=-GtYzUX-qc36o_XbWO9NQzMUmA@mail.gmail.com>
On Mon, Dec 18, 2017 at 02:57:37PM +0100, Linus Walleij wrote:
> On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > The Gemini ethernet has been around for years as an out-of-tree
> > patch used with the NAS boxen and routers built on StorLink
> > SL3512 and SL3516, later Storm Semiconductor, later Cortina
> > Systems. These ASICs are still being deployed and brand new
> > off-the-shelf systems using it can easily be acquired.
[...]
> > ---
> > Changes from v8:
> > - Remove dependency guards in Kconfig to get a wider compile
> > coverage for the driver to detect broken APIs etc.
>
> I guess we need to hold this off for a while, the code does
> some weird stuff using the ARM-internal page DMA mapping
> API.
>
> I *think* what happens is that the driver allocates a global queue
> used for RX and TX on both interfaces, then initializes that with
> page pointers and gives that to the hardware to play with.
>
> When an RX packet comes in, the RX routine needs to figure
> out from the DMA (physical) address which remapped
> page/address this random physical address pointer
> corresponds to.
>
> The Linux DMA API assumption is that the driver keeps track
> of this mapping, not the hardware. So we need to figure out
> a way to reverse-map this. Preferably quickly, and without
> using any ARM-internal mapping APIs.
IIRC, the hardware copies descriptors from free queue (FREEQ)
to RX queues. FREEQ is shared among the two ethernet ports.
This platform is CPU bound, so every additional lookup will
hit performance here. In my version I had an #ifdef for
COMPILE_TEST that replaced ARM-specific calls with stubs.
Since the driver is not expected to work on other platforms,
this seemed like the best workaround to make it compile
on other arches.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Russell King - ARM Linux @ 2017-12-18 14:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Linus Walleij, Tobias Waldvogel, Florian Fainelli,
Paulius Zaleckas, netdev, Hans Ulli Kroll, Janos Laube,
David S . Miller, Linux ARM
In-Reply-To: <20171218144817.GA25352@qmqm.qmqm.pl>
On Mon, Dec 18, 2017 at 03:48:17PM +0100, Michał Mirosław wrote:
> On Mon, Dec 18, 2017 at 02:57:37PM +0100, Linus Walleij wrote:
> > On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > The Gemini ethernet has been around for years as an out-of-tree
> > > patch used with the NAS boxen and routers built on StorLink
> > > SL3512 and SL3516, later Storm Semiconductor, later Cortina
> > > Systems. These ASICs are still being deployed and brand new
> > > off-the-shelf systems using it can easily be acquired.
> [...]
> > > ---
> > > Changes from v8:
> > > - Remove dependency guards in Kconfig to get a wider compile
> > > coverage for the driver to detect broken APIs etc.
> >
> > I guess we need to hold this off for a while, the code does
> > some weird stuff using the ARM-internal page DMA mapping
> > API.
> >
> > I *think* what happens is that the driver allocates a global queue
> > used for RX and TX on both interfaces, then initializes that with
> > page pointers and gives that to the hardware to play with.
> >
> > When an RX packet comes in, the RX routine needs to figure
> > out from the DMA (physical) address which remapped
> > page/address this random physical address pointer
> > corresponds to.
> >
> > The Linux DMA API assumption is that the driver keeps track
> > of this mapping, not the hardware. So we need to figure out
> > a way to reverse-map this. Preferably quickly, and without
> > using any ARM-internal mapping APIs.
>
> IIRC, the hardware copies descriptors from free queue (FREEQ)
> to RX queues. FREEQ is shared among the two ethernet ports.
>
> This platform is CPU bound, so every additional lookup will
> hit performance here. In my version I had an #ifdef for
> COMPILE_TEST that replaced ARM-specific calls with stubs.
> Since the driver is not expected to work on other platforms,
> this seemed like the best workaround to make it compile
> on other arches.
Really. No. Stop going beneath the covers and using ARM private
implementation APIs in drivers.
Take that as a big NAK to that.
(I don't seem have the patch in question here to look at though.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH][next] ath10k: wmi: remove redundant integer fc
From: Colin King @ 2017-12-18 15:02 UTC (permalink / raw)
To: Kalle Valo, ath10k, linux-wireless, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable fc is being assigned but never used, so remove it. Cleans
up the clang warning:
warning: Value stored to 'fc' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 8d53063bd503..06fde53aa679 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2494,7 +2494,6 @@ ath10k_wmi_tlv_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
void *ptr;
int len;
u32 buf_len = msdu->len;
- u16 fc;
struct ath10k_vif *arvif;
dma_addr_t mgmt_frame_dma;
u32 vdev_id;
@@ -2503,7 +2502,6 @@ ath10k_wmi_tlv_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
return ERR_PTR(-EINVAL);
hdr = (struct ieee80211_hdr *)msdu->data;
- fc = le16_to_cpu(hdr->frame_control);
arvif = (void *)cb->vif->drv_priv;
vdev_id = arvif->vdev_id;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v10 3/5] bpf: add a bpf_override_function helper
From: Daniel Borkmann @ 2017-12-18 15:09 UTC (permalink / raw)
To: Masami Hiramatsu, Josef Bacik
Cc: rostedt, mingo, davem, netdev, linux-kernel, ast, kernel-team,
linux-btrfs, darrick.wong, Josef Bacik
In-Reply-To: <20171218185100.4a8174488dfebf93d28899c3@kernel.org>
On 12/18/2017 10:51 AM, Masami Hiramatsu wrote:
> On Fri, 15 Dec 2017 14:12:54 -0500
> Josef Bacik <josef@toxicpanda.com> wrote:
>> From: Josef Bacik <jbacik@fb.com>
>>
>> Error injection is sloppy and very ad-hoc. BPF could fill this niche
>> perfectly with it's kprobe functionality. We could make sure errors are
>> only triggered in specific call chains that we care about with very
>> specific situations. Accomplish this with the bpf_override_funciton
>> helper. This will modify the probe'd callers return value to the
>> specified value and set the PC to an override function that simply
>> returns, bypassing the originally probed function. This gives us a nice
>> clean way to implement systematic error injection for all of our code
>> paths.
>
> OK, got it. I think the error_injectable function list should be defined
> in kernel/trace/bpf_trace.c because only bpf calls it and needs to care
> the "safeness".
>
> [...]
>> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
>> index 8dc0161cec8f..1ea748d682fd 100644
>> --- a/arch/x86/kernel/kprobes/ftrace.c
>> +++ b/arch/x86/kernel/kprobes/ftrace.c
>> @@ -97,3 +97,17 @@ int arch_prepare_kprobe_ftrace(struct kprobe *p)
>> p->ainsn.boostable = false;
>> return 0;
>> }
>> +
>> +asmlinkage void override_func(void);
>> +asm(
>> + ".type override_func, @function\n"
>> + "override_func:\n"
>> + " ret\n"
>> + ".size override_func, .-override_func\n"
>> +);
>> +
>> +void arch_ftrace_kprobe_override_function(struct pt_regs *regs)
>> +{
>> + regs->ip = (unsigned long)&override_func;
>> +}
>> +NOKPROBE_SYMBOL(arch_ftrace_kprobe_override_function);
>
> Calling this as "override_function" is meaningless. This is a function
> which just return. So I think combination of just_return_func() and
> arch_bpf_override_func_just_return() will be better.
>
> Moreover, this arch/x86/kernel/kprobes/ftrace.c is an archtecture
> dependent implementation of kprobes, not bpf.
Josef, please work out any necessary cleanups that would still need
to be addressed based on Masami's feedback and send them as follow-up
patches, thanks.
> Hmm, arch/x86/net/bpf_jit_comp.c will be better place?
(No, it's JIT only and I'd really prefer to keep it that way, mixing
this would result in a huge mess.)
^ permalink raw reply
* Re: [PATCH bpf-next 12/13] bpf: arm64: add JIT support for multi-function programs
From: Arnd Bergmann @ 2017-12-18 15:29 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, John Fastabend, Edward Cree,
Jakub Kicinski, Networking, kernel-team
In-Reply-To: <20171215015517.409513-13-ast@kernel.org>
On Fri, Dec 15, 2017 at 2:55 AM, Alexei Starovoitov <ast@kernel.org> wrote:
> + if (jit_data->ctx.offset) {
> + ctx = jit_data->ctx;
> + image_ptr = jit_data->image;
> + header = jit_data->header;
> + extra_pass = true;
> + goto skip_init_ctx;
> + }
> memset(&ctx, 0, sizeof(ctx));
> ctx.prog = prog;
The 'goto' jumps over the 'image_size' initialization
> prog->bpf_func = (void *)ctx.image;
> prog->jited = 1;
> prog->jited_len = image_size;
so we now get a warning here, starting with linux-next-20171218:
arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
I could not figure out what the code should be doing instead, or if it is
indeed safe and the warning is a false-positive.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Joe Perches @ 2017-12-18 15:30 UTC (permalink / raw)
To: Knut Omang, Jason Gunthorpe
Cc: Stephen Hemminger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mauro Carvalho Chehab, Nicolas Palix, Jonathan Corbet,
Santosh Shilimkar, Matthew Wilcox, cocci-/FJkirnvOdkvYVN+rsErww,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Doug Ledford,
Mickaël Salaün, Shuah Khan,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA, Michal Marek, Julia Lawall,
John Haxby, Åsmund Østvold, Masahiro Yamada
In-Reply-To: <1513602315.22938.49.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote:
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > $(git ls-files drivers/infiniband/)
>
> Yes, and I already did that work piece by piece for individual types,
> just to test the runchecks tool, and want to post that set once the
> runchecks script and Makefile changes itself are in,
I think those are independent of any runcheck tool changes and
could be posted now. In general, don't keep patches in a local
tree waiting on some other unrelated patch.
Just fyi:
There is a script that helps automate checkpatch "by-type" conversions
with compilation, .o difference checking, and git commit editing.
https://lkml.org/lkml/2014/7/11/794
--
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
* [PATCH net v2] net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks
From: Nikolay Aleksandrov @ 2017-12-18 15:35 UTC (permalink / raw)
To: netdev
Cc: makita.toshiaki, roopa, davem, stephen, avagin, bridge, idosch,
Nikolay Aleksandrov
In-Reply-To: <e4948ab7-0f3b-a4f5-52ea-853a987f1abb@cumulusnetworks.com>
The early call to br_stp_change_bridge_id in bridge's newlink can cause
a memory leak if an error occurs during the newlink because the fdb
entries are not cleaned up if a different lladdr was specified, also
another minor issue is that it generates fdb notifications with
ifindex = 0. Another unrelated memory leak is the bridge sysfs entries
which get added on NETDEV_REGISTER event, but are not cleaned up in the
newlink error path. To remove this special case the call to
br_stp_change_bridge_id is done after netdev register and we cleanup the
bridge on changelink error via br_dev_delete to plug all leaks.
This patch makes netlink bridge destruction on newlink error the same as
dellink and ioctl del which is necessary since at that point we have a
fully initialized bridge device.
To reproduce the issue:
$ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1
RTNETLINK answers: Invalid argument
$ rmmod bridge
[ 1822.142525] =============================================================================
[ 1822.143640] BUG bridge_fdb_cache (Tainted: G O ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown()
[ 1822.144821] -----------------------------------------------------------------------------
[ 1822.145990] Disabling lock debugging due to kernel taint
[ 1822.146732] INFO: Slab 0x0000000092a844b2 objects=32 used=2 fp=0x00000000fef011b0 flags=0x1ffff8000000100
[ 1822.147700] CPU: 2 PID: 13584 Comm: rmmod Tainted: G B O 4.15.0-rc2+ #87
[ 1822.148578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 1822.150008] Call Trace:
[ 1822.150510] dump_stack+0x78/0xa9
[ 1822.151156] slab_err+0xb1/0xd3
[ 1822.151834] ? __kmalloc+0x1bb/0x1ce
[ 1822.152546] __kmem_cache_shutdown+0x151/0x28b
[ 1822.153395] shutdown_cache+0x13/0x144
[ 1822.154126] kmem_cache_destroy+0x1c0/0x1fb
[ 1822.154669] SyS_delete_module+0x194/0x244
[ 1822.155199] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 1822.155773] entry_SYSCALL_64_fastpath+0x23/0x9a
[ 1822.156343] RIP: 0033:0x7f929bd38b17
[ 1822.156859] RSP: 002b:00007ffd160e9a98 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0
[ 1822.157728] RAX: ffffffffffffffda RBX: 00005578316ba090 RCX: 00007f929bd38b17
[ 1822.158422] RDX: 00007f929bd9ec60 RSI: 0000000000000800 RDI: 00005578316ba0f0
[ 1822.159114] RBP: 0000000000000003 R08: 00007f929bff5f20 R09: 00007ffd160e8a11
[ 1822.159808] R10: 00007ffd160e9860 R11: 0000000000000202 R12: 00007ffd160e8a80
[ 1822.160513] R13: 0000000000000000 R14: 0000000000000000 R15: 00005578316ba090
[ 1822.161278] INFO: Object 0x000000007645de29 @offset=0
[ 1822.161666] INFO: Object 0x00000000d5df2ab5 @offset=128
Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device")
Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v2: it's better to use br_dev_delete to clean up because the sysfs entries
were leaked as well, basically we use it for the bridge fdb flush and sysfs
entries delete
Consequently this also would fix the null ptr deref due to the rhashtable
not being initialized in net-next when br_stp_change_bridge_id is called.
net/bridge/br_netlink.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index d0ef0a8e8831..015f465c514b 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1262,19 +1262,20 @@ static int br_dev_newlink(struct net *src_net, struct net_device *dev,
struct net_bridge *br = netdev_priv(dev);
int err;
+ err = register_netdevice(dev);
+ if (err)
+ return err;
+
if (tb[IFLA_ADDRESS]) {
spin_lock_bh(&br->lock);
br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
spin_unlock_bh(&br->lock);
}
- err = register_netdevice(dev);
- if (err)
- return err;
-
err = br_changelink(dev, tb, data, extack);
if (err)
- unregister_netdevice(dev);
+ br_dev_delete(dev, NULL);
+
return err;
}
--
2.14.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