* Re: [net-next PATCH RFC 04/26] arch/arm: Add option to skip sync on DMA map and unmap
From: Russell King - ARM Linux @ 2016-10-31 10:20 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, linux-kernel, linux-mm, brouer, davem
In-Reply-To: <20161024120447.16276.50401.stgit@ahduyck-blue-test.jf.intel.com>
On Mon, Oct 24, 2016 at 08:04:47AM -0400, Alexander Duyck wrote:
> The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
> APIs in the arch/arm folder. This change is meant to correct that so that
> we get consistent behavior.
I'm really not convinced that this is anywhere close to correct behaviour.
If we're DMA-ing to a buffer, and we unmap it or sync_for_cpu, then we
will want to access the DMA'd data - especially in the sync_for_cpu case,
it's pointless to call sync_for_cpu if we're not going to access the
data.
So the idea of skipping the CPU copy when DMA_ATTR_SKIP_CPU_SYNC is set
seems to be completely wrong - it means we end up reading the stale data
that was in the buffer, completely ignoring whatever was DMA'd to it.
What's the use case for DMA_ATTR_SKIP_CPU_SYNC ?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Joachim Eastwood @ 2016-10-31 10:20 UTC (permalink / raw)
To: Neil Armstrong
Cc: Rob Herring, peppe.cavallaro, alexandre.torgue-qxv4g6HH51o,
netdev, linux-oxnas-Xt5XgHjqiBU06sgRBLv0+0B+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree
In-Reply-To: <04b8ed79-8efa-cc10-a9a3-fdee10e0723c-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
On 31 October 2016 at 10:55, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> On 10/30/2016 09:41 PM, Rob Herring wrote:
>> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>>
>> It's preferred that bindings are a separate patch.
>
> OK
>
>>
>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>>> 4 files changed, 275 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>>
>>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>>> - Drop init/exit callbacks
>>> - Implement proper remove and PM callback
>>> - Call init from probe
>>> - Disable/Unprepare clock if stmmac probe fails
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> new file mode 100644
>>> index 0000000..5d2696c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> @@ -0,0 +1,44 @@
>>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>>> +
>>> +The device inherits all the properties of the dwmac/stmmac devices
>>> +described in the file stmmac.txt in the current directory with the
>>> +following changes.
>>> +
>>> +Required properties on all platforms:
>>> +
>>> +- compatible: Depending on the platform this should be one of:
>>> + - "oxsemi,ox820-dwmac"
>>> + Additionally "snps,dwmac" and any applicable more
>>> + detailed version number described in net/stmmac.txt
>>> + should be used.
>>
>> You should be explicit what version applies to ox820. "snps,dwmac"
>> should probably be deprecated IMO. There are so many variations of DW
>> h/w.
>
> Well, to be honest I have absolutely no idea ! But I will try to find out...
You can see in the boot log:
>From lpc18xx boot:
[ 3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
[ 3.247653] Ring mode enabled
[ 3.251491] DMA HW capability register supported
[ 3.256336] Enhanced/Alternate descriptors
[ 3.261537] Enabled extended descriptors
[ 3.265968] RX Checksum Offload Engine supported (type 2)
[ 3.272249] TX Checksum insertion supported
[ 3.276874] Wake-Up On Lan supported
[ 3.283743] Enable RX Mitigation via HW Watchdog Timer
[ 3.326701] libphy: stmmac: probed
Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [bnx2] [Regression 4.8] Driver loading fails without firmware
From: Baoquan He @ 2016-10-31 10:09 UTC (permalink / raw)
To: Paul Menzel
Cc: Sony Chacko, Dept-HSGLinuxNICDev, netdev, David S. Miller, dyoung
In-Reply-To: <b0675854-41f9-e7b6-4ad0-85ff59b98977@molgen.mpg.de>
Hi Paul,
On 10/26/16 at 12:31pm, Paul Menzel wrote:
> Baoquan, could you please fix this regression. My suggestion is, that you
> add the old code back, but check if the firmware has been loaded. If it
> hasn’t, load it again.
>
> That way, people can update their Linux kernel, and it continues working
> without changing the initramfs, or anything else.
I checked code and this looks good to me. I can post a patch with this
change to upstream, see what maintainers and other reviewers say.
The thing is I don't understand quite well about your requirement. With
my understanding, you just didn't add bnx2 firmware into initramfs, but
later opening the interface can still request that firmware with "ifup
eth-xxx" command. Is that correct? If yes, requeting firmware twice in
probing path and opening path looks good.
However I am wondering what's your exact steps to do this.
What I tried to do is I execute command "dracut --add-drivers bnx2 -f
/boot/initramfs-4.9.0-rc3+.img 4.9.0-rc3+" to build a new initramfs,
meanwhile make sure bnx2.ko is included, then uncompressed initramfs and
deleted bnx2 folder under lib/firmware/ of uncompressed initramfs. Then
pack them to be /boot/initramfs-4.9.0-rc3+.img and restart. I did saw
below failure message. But later how did you really make the bnx2
network interface up? Could you say it more specifically?
[ 7.364186] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6 (January 29, 2014)
[ 7.371706] ACPI: PCI Interrupt Link [LN44] enabled at IRQ 44
[ 7.378128] bnx2 0000:01:00.0: Direct firmware load for bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
[ 7.387619] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"
[ 7.387888] bnx2: probe of 0000:01:00.0 failed with error -2
[ 7.388990] ACPI: PCI Interrupt Link [LN45] enabled at IRQ 45
[ 7.389370] bnx2 0000:01:00.1: Direct firmware load for bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
[ 7.389371] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"
[ 7.389475] bnx2: probe of 0000:01:00.1 failed with error -2
Thanks
Baoquan
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 9:55 UTC (permalink / raw)
To: Rob Herring
Cc: peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-oxnas-Xt5XgHjqiBU06sgRBLv0+0B+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161030204110.otvjlanmi7dv7fox@rob-hp-laptop>
On 10/30/2016 09:41 PM, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>
> It's preferred that bindings are a separate patch.
OK
>
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>> 4 files changed, 275 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>
>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>> - Drop init/exit callbacks
>> - Implement proper remove and PM callback
>> - Call init from probe
>> - Disable/Unprepare clock if stmmac probe fails
>>
>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> new file mode 100644
>> index 0000000..5d2696c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> @@ -0,0 +1,44 @@
>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>> +
>> +The device inherits all the properties of the dwmac/stmmac devices
>> +described in the file stmmac.txt in the current directory with the
>> +following changes.
>> +
>> +Required properties on all platforms:
>> +
>> +- compatible: Depending on the platform this should be one of:
>> + - "oxsemi,ox820-dwmac"
>> + Additionally "snps,dwmac" and any applicable more
>> + detailed version number described in net/stmmac.txt
>> + should be used.
>
> You should be explicit what version applies to ox820. "snps,dwmac"
> should probably be deprecated IMO. There are so many variations of DW
> h/w.
Well, to be honest I have absolutely no idea ! But I will try to find out...
>
>> +
>> +- reg: The first register range should be the one of the DWMAC
>> + controller.
>
> This is worded like there's a 2nd range?
OK, will rephrase.
>
>> +
>> +- clocks: Should contain phandles to the following clocks
>> +- clock-names: Should contain the following:
>> + - "stmmaceth" - see stmmac.txt
>> + - "gmac" - peripheral gate clock
>> +
>> +- oxsemi,sys-ctrl: a phandle to the system controller syscon node
>> +
>> +Example :
>> +
>> +etha: ethernet@40400000 {
>> + compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
>> + reg = <0x40400000 0x2000>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "macirq", "eth_wake_irq";
>> + mac-address = [000000000000]; /* Filled in by U-Boot */
>> + phy-mode = "rgmii";
>> +
>> + clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
>> + clock-names = "gmac", "stmmaceth";
>> + resets = <&reset RESET_MAC>;
>> +
>> + /* Regmap for sys registers */
>> + oxsemi,sys-ctrl = <&sys>;
>> +
>> + status = "disabled";
>> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Neil Armstrong @ 2016-10-31 9:40 UTC (permalink / raw)
To: Linus Walleij
Cc: Kevin Hilman, Carlo Caione, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
open list:ARM/Amlogic Meson..., linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <CACRpkdZ5VG2NGRh5CmYcYzwCp0LYSsgxHogCFa+6W7BDDBXOYg@mail.gmail.com>
On 10/24/2016 03:03 AM, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>> definition only based on the Amlogic Vendor tree.
>>
>> This definition differs a lot from the GXBB and needs a separate entry.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Looks good to me. Tell me when I may apply it, it looks orthogonal
> to the rest of the patches.
>
> Yours,
> Linus Walleij
>
Hi Linus,
I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
Thanks,
Neil
^ permalink raw reply
* Re: Let's do P4
From: Jiri Pirko @ 2016-10-31 9:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Thomas Graf, John Fastabend, Jakub Kicinski, netdev, davem, jhs,
roopa, simon.horman, ast, daniel, prem, hannes, jbenc, tom,
mattyk, idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera,
Maciej Żenczykowski
In-Reply-To: <20161030223903.GA6658@ast-mbp.hil-sfehihf.abq.wayport.net>
Sun, Oct 30, 2016 at 11:39:05PM CET, alexei.starovoitov@gmail.com wrote:
>On Sun, Oct 30, 2016 at 05:38:36PM +0100, Jiri Pirko wrote:
>> Sun, Oct 30, 2016 at 11:26:49AM CET, tgraf@suug.ch wrote:
>> >On 10/30/16 at 08:44am, Jiri Pirko wrote:
>> >> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastabend@gmail.com wrote:
>> >> >On 16-10-29 07:49 AM, Jakub Kicinski wrote:
>> >> >> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>> >> >>> Hi all.
>> >> >>>
>
>sorry for delay. travelling to KS, so probably missed something in
>this thread and comments can be totally off...
>
>the subject "let's do P4" is imo misleading, since it reads like
>we don't do P4 at the moment, whereas the opposite is true.
>Several p4->bpf compilers is a proof.
We don't do p4 in kernel now, we don't do p4 offloading now. That is
the reason I started this discussion.
>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>> These ASICs are suitable to be programmed by P4.
>
>i think the opposite is the case in case of P4.
>when hw asic has tcam it's still far far away from being usable with P4
>which requires fully programmable protocol parser, arbitrary tables and so on.
>P4 doesn't even define TCAM as a table type. The p4 program can declare
>a desired algorithm of search in the table and compiler has to figure out
>what HW resources to use to satisfy such p4 program.
>
>> 2) network processors - basically a general purpose CPUs
>> These processors are suitable to be programmed by eBPF.
>
>I think this statement is also misleading, since it positions
>p4 and bpf as competitors whereas that's not the case.
>p4 is the language. bpf is an instruction set.
I wanted to say that we are having 2 approaches in silicon, 2 different
paradigms. Sure you can do p4>bpf. But hard to do it the opposite way.
>
>> Exactly. Following drawing shows p4 pipeline setup for SW and Hw:
>>
>> |
>> | +--> ebpf engine
>> | |
>> | |
>> | compilerB
>> | ^
>> | |
>> p4src --> compilerA --> p4ast --TCNL--> cls_p4 --+-> driver -> compilerC -> HW
>> |
>> userspace | kernel
>> |
>
>frankly this diagram smells very much like kernel bypass to me,
what? That is well defined kernel API, in-kernel sw consumer and offload
in driver. Same API for both.
Alex, you have very odd sense about what's bypassing kernel. That kind
of freaks me out...
>since I cannot see how one can put the whole p4 language compiler
>into the driver, so this last step of p4ast->hw, I presume, will be
>done by firmware, which will be running full compiler in an embedded cpu
In case of mlxsw, that compiler would be in driver.
>on the switch. To me that's precisely the kernel bypass, since we won't
>have a clue what HW capabilities actually are and won't be able to fine
>grain control them.
>Please correct me if I'm wrong.
You are wrong. By your definition, everything has to be figured out in
driver and FW does nothing. Otherwise it could do "something else" and
that would be a bypass? Does not make any sense to me whatsoever.
>
>> Plus the thing I cannot imagine in the model you propose is table fillup.
>> For ebpf, you use maps. For p4 you would have to have a separate HW-only
>> API. This is very similar to the original John's Flow-API. And therefore
>> a kernel bypass.
>
>I think John's flow api is a better way to expose mellanox switch capabilities.
We are under impression that p4 suits us nicely. But it is not about
us, it is about finding the common way to do this.
>I also think it's not fair to call it 'bypass'. I see nothing in it
>that justify such 'swear word' ;)
John's Flow-API was a kernel bypass. Why? It was a API specifically
designed to directly work with HW tables, without kernel being involved.
>The goal of flow api was to expose HW features to user space, so that
>user space can program it. For something simple as mellanox switch
>asic it fits perfectly well.
Again, this is not mlx-asic-specific. And again, that is a kernel bypass.
>Unless I misunderstand the bigger goal of this discussion and it's
>about programming ezchip devices.
No. For network processors, I believe that BPF is nicely offloadable, no
need to do the excercise for that.
>
>If the goal is to model hw tcam in the linux kernel then just introduce
>tcam bpf map type. It will be dog slow in user space, but it will
>match exactly what is happnening in the HW and user space can make
>sensible trade-offs.
No, you got me completely wrong. This is not about the TCAM. This is
about differences in the 2 words (p4/bpf).
Again, for "p4-ish" devices, you have to translate BPF. And as you
noted, it's an instruction set. Very hard if not impossible to parse in
order to get back the original semantics.
^ permalink raw reply
* RE: [v15, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-10-31 9:36 UTC (permalink / raw)
To: Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, M.H. Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
Scott Wood, Rob Herring, Santosh Shilimkar, Greg Kroah-Hartman,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, X.B. Xie,
Leo Li, "iommu@l
In-Reply-To: <3386858.dvuMhvkN3m@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> Sent: Friday, October 28, 2016 6:54 PM
> To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Jochen Friedrich; Claudiu Manoil;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Rob Herring; Santosh Shilimkar;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leo Li;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Kumar Gala; linuxppc-
> dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Subject: Re: [v15, 0/7] Fix eSDHC host version register bug
>
> On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first five patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
>
> Looks good overall. With patch 3 dropped (or an explanation why it's
> still needed), everything
>
> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>
[Lu Yangbo-B47093] Thank you very much:) See my explaination in patch 3 email.
> Arnd
^ permalink raw reply
* RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Y.B. Lu @ 2016-10-31 9:35 UTC (permalink / raw)
To: Arnd Bergmann,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, M.H. Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
Scott Wood, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, X.B. Xie
In-Reply-To: <2723366.1bJeJ7SKI6@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> Sent: Friday, October 28, 2016 6:53 PM
> To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Rob Herring; Santosh Shilimkar; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leo Li;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Kumar Gala
> Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
>
> On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> > header file. This SVR numberspace is used on some ARM chips as well
> > as PPC, and even to check for a PPC SVR multi-arch drivers would
> > otherwise need to ifdef the header inclusion and all references to the
> SVR symbols.
> >
> >
>
> I don't see any of the contents of this header referenced by the soc
> driver any more. I think you can just drop this patch.
>
[Lu Yangbo-B47093] This header file was included by guts.c.
The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
This header file was for powerpc arch before. And this patch is to made it as common header file for both ARM and PPC.
Sooner or later this is needed.
> Arnd
^ permalink raw reply
* Re: [PATCH 12/15] ptp: use permission-specific DEVICE_ATTR variants
From: Richard Cochran @ 2016-10-31 9:30 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, netdev, linux-kernel
In-Reply-To: <1477769829-22230-13-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Oct 29, 2016 at 09:37:06PM +0200, Julia Lawall wrote:
> Use DEVICE_ATTR_RO for read only attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* RE: [v15, 6/7] base: soc: introduce soc_device_match() interface
From: Y.B. Lu @ 2016-10-31 9:28 UTC (permalink / raw)
To: Arnd Bergmann,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Geert Uytterhoeven,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, M.H. Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
Scott Wood, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Greg Kroah-Hartman,
"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-mmc
In-Reply-To: <2572890.e6aV4hmMEL@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> Sent: Friday, October 28, 2016 6:48 PM
> To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Rob Herring; Santosh Shilimkar; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leo Li;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Kumar Gala; Geert Uytterhoeven
> Subject: Re: [v15, 6/7] base: soc: introduce soc_device_match() interface
>
> On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> > +
> > +static int soc_device_match_one(struct device *dev, void *arg) {
> > + struct soc_device *soc_dev = container_of(dev, struct
> soc_device, dev);
> > + const struct soc_device_attribute *match = arg;
> > +
> > + if (match->machine &&
> > + !glob_match(match->machine, soc_dev->attr->machine))
> > + return 0;
> > +
> > + if (match->family &&
> > + !glob_match(match->family, soc_dev->attr->family))
> > + return 0;
> > +
> >
>
> Geert found a bug in my code, and submitted a fix at
> https://patchwork.kernel.org/patch/9361395/
>
> I think you should include that one in your series.
>
[Lu Yangbo-B47093] Ok, no problem. Thanks :)
> Arnd
^ permalink raw reply
* Re: [PATCH net-next] ipv4: fib: Replay events when registering FIB notifier
From: Ido Schimmel @ 2016-10-31 9:03 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, netdev, davem, jiri, mlxsw, roopa, nikolay, dsa, andy,
alexander.h.duyck, vivien.didelot, f.fainelli, andrew, kuznet,
jmorris, yoshfuji, kaber, Ido Schimmel
In-Reply-To: <201611010030.QbB5pF6n%fengguang.wu@intel.com>
On Tue, Nov 01, 2016 at 12:54:01AM +0800, kbuild test robot wrote:
> Hi Ido,
>
> [auto build test ERROR on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/idosch-idosch-org/ipv4-fib-Replay-events-when-registering-FIB-notifier/20161031-163334
> config: x86_64-randconfig-x014-201644 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
> net/ipv4/fib_trie.c: In function 'register_fib_notifier':
> >> net/ipv4/fib_trie.c:141:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_rules'
> if (net->ipv4.fib_has_custom_rules)
> ^
> net/ipv4/fib_trie.c: In function 'unregister_fib_notifier':
> net/ipv4/fib_trie.c:178:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_rules'
> if (net->ipv4.fib_has_custom_rules)
> ^
Right, I missed that. Will send a v2.
Thanks!
>
> vim +141 net/ipv4/fib_trie.c
>
> 135 err = blocking_notifier_chain_register(&fib_chain, nb);
> 136 if (err)
> 137 goto unlock;
> 138 for_each_net(net) {
> 139 struct fib_notifier_info info;
> 140
> > 141 if (net->ipv4.fib_has_custom_rules)
> 142 call_fib_notifier(nb, net, FIB_EVENT_RULE_ADD, &info);
> 143 fib_notify(net, nb, FIB_EVENT_ENTRY_ADD);
> 144 }
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* RE: [PATCH net-next V3 0/9] liquidio CN23XX VF support
From: Vatsavayi, Raghu @ 2016-10-31 7:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20161029.143126.1818409172503412109.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
Hi Dave,
Regarding module parameters num_queues_per_{p,v}f, in non-default case if user wants to have multiple queues then because of the way Liquidio HW works we need num_queues_per_pf and num_queues_per_vf module parameters at HW/module init time. This is because in multi-queues per VF scenario, HW has to carve these queues before FW can start communicating with PF/VF host drivers. So we must include these two parameters incase more than queue is needed by VF.
I did not get reply from you when I requested you for confirmation couple of weeks back about the same two module parameters as shown in the mail attachment.
So please confirm if you want us to remove these two parameters num_queues_per_{p,v}f. Then I can remove these module parameters and resubmit the patches.
Thanks and Regards
Raghu.
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Saturday, October 29, 2016 11:31 AM
> To: Vatsavayi, Raghu
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next V3 0/9] liquidio CN23XX VF support
>
> From: Raghu Vatsavayi <rvatsavayi@caviumnetworks.com>
> Date: Tue, 25 Oct 2016 17:57:01 -0700
>
> > 2) As recommended by you removed custom module parameter max_vfs.
>
> I feel the same way about num_queues_per_{p,v}f.
>
> What's really strange is that there is a reference to num_queues_per_pf in
> one of the kernel log messages already.
[-- Attachment #2: Type: message/rfc822, Size: 4686 bytes --]
From: "Vatsavayi, Raghu" <Raghu.Vatsavayi@cavium.com>
To: David Miller <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "Chickles, Derek" <Derek.Chickles@cavium.com>, "Burla, Satananda" <Satananda.Burla@cavium.com>, "Manlunas, Felix" <Felix.Manlunas@cavium.com>
Subject: RE: [PATCH net-next V2 1/9] liquidio CN23XX: HW config for VF support
Date: Thu, 20 Oct 2016 23:08:55 +0000
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, October 20, 2016 1:57 PM
> To: Vatsavayi, Raghu
> Cc: netdev@vger.kernel.org; Chickles, Derek; Burla, Satananda; Manlunas,
> Felix
> Subject: Re: [PATCH net-next V2 1/9] liquidio CN23XX: HW config for VF
> support
>
> From: "Vatsavayi, Raghu" <Raghu.Vatsavayi@cavium.com>
> Date: Thu, 20 Oct 2016 20:01:37 +0000
>
> >
> >
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Thursday, October 20, 2016 11:13 AM
> >> To: Vatsavayi, Raghu
> >> Cc: netdev@vger.kernel.org; Vatsavayi, Raghu; Chickles, Derek; Burla,
> >> Satananda; Manlunas, Felix
> >> Subject: Re: [PATCH net-next V2 1/9] liquidio CN23XX: HW config for
> >> VF support
> >>
> >> From: Raghu Vatsavayi <rvatsavayi@caviumnetworks.com>
> >> Date: Wed, 19 Oct 2016 22:40:38 -0700
> >>
> >> > +/* Default behaviour of Liquidio is to provide one queue per VF.
> >> > +But Liquidio
> >> > + * can also provide multiple queues to each VF. If user wants to
> >> > +change the
> >> > + * default behaviour HW should be provided configuration info at
> >> > +init time,
> >> > + * based on which it will create control queues for communicating
> >> > +with
> >> FW.
> >> > + */
> >> > +static u32 max_vfs[2] = { 0, 0 };
> >> > +module_param_array(max_vfs, int, NULL, 0444);
> >> > +MODULE_PARM_DESC(max_vfs, "Assign two comma-separated
> unsigned
> >> > +integers that specify max number of VFs for PF0 (left of the
> >> > +comma) and PF1 (right of the comma); for 23xx only. By default HW
> >> > +will configure as many VFs as queues after allocating PF queues.To
> >> > +increase queues for VF use this parameter. Use sysfs to create
> >> > +these VFs.");
> >> > +
> >> > +static unsigned int num_queues_per_pf[2] = { 0, 0 };
> >> > +module_param_array(num_queues_per_pf, uint, NULL, 0444);
> >> > +MODULE_PARM_DESC(num_queues_per_pf, "two comma-separated
> >> unsigned
> >> > +integers that specify number of queues per PF0 (left of the comma)
> >> > +and PF1 (right of the comma); for 23xx only");
> >> > +
> >> > static int ptp_enable = 1;
> >>
> >> We cannot continue to allow drivers to add custom module parameters
> >> to control this. It is the worst user experience possible.
> >>
> >> We need a tree-wide generic, consistent, manner in which to configure
> >> and control this kind of thing.
> >
> > Sure Dave, I will remove max_vfs module parameter and will use tree
> > wide generic sysfs interface to enable VFs.
>
> That's not what I meant.
>
> I mean there needs to be a generic mechanism that isn't a per-device knob
> (be it a module parameter or a sysctl, to me these are identical functionality
> and user experience wise).
>
> Something like ethtool or netlink.
Dave, I will remove max_vfs module parameter and will just use the generic mechanism that all drivers do like:
" echo 10 > /sys/devices/pci0000:00/0000:00:03.0/0000:03:00.1/sriov_numvfs"
Regarding other module parameters, in non-default case if user wants to have multiple queues then because of the way Liquidio HW works we need num_queues_per_pf and num_queues_per_vf module parameters at HW/module init time. This is because in multi-queues per VF scenario, HW has to carve these queues before FW can start communicating with PF/VF host drivers, so we must include these two parameters.
Please confirm that having these two module parameters is fine for non-default case. I will soon forward you the patches with these changes that you have recommended.
Thanks Much
Raghu.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: fib: Replay events when registering FIB notifier
From: kbuild test robot @ 2016-10-31 16:54 UTC (permalink / raw)
To: idosch
Cc: kbuild-all, netdev, davem, jiri, mlxsw, roopa, nikolay, dsa, andy,
alexander.h.duyck, vivien.didelot, f.fainelli, andrew, kuznet,
jmorris, yoshfuji, kaber, Ido Schimmel
In-Reply-To: <1477902578-20137-1-git-send-email-idosch@idosch.org>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Hi Ido,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/idosch-idosch-org/ipv4-fib-Replay-events-when-registering-FIB-notifier/20161031-163334
config: x86_64-randconfig-x014-201644 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
net/ipv4/fib_trie.c: In function 'register_fib_notifier':
>> net/ipv4/fib_trie.c:141:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_rules'
if (net->ipv4.fib_has_custom_rules)
^
net/ipv4/fib_trie.c: In function 'unregister_fib_notifier':
net/ipv4/fib_trie.c:178:16: error: 'struct netns_ipv4' has no member named 'fib_has_custom_rules'
if (net->ipv4.fib_has_custom_rules)
^
vim +141 net/ipv4/fib_trie.c
135 err = blocking_notifier_chain_register(&fib_chain, nb);
136 if (err)
137 goto unlock;
138 for_each_net(net) {
139 struct fib_notifier_info info;
140
> 141 if (net->ipv4.fib_has_custom_rules)
142 call_fib_notifier(nb, net, FIB_EVENT_RULE_ADD, &info);
143 fib_notify(net, nb, FIB_EVENT_ENTRY_ADD);
144 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33925 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: Jan Beulich @ 2016-10-31 8:44 UTC (permalink / raw)
To: Dongli Zhang
Cc: david.vrabel, xen-devel, boris.ostrovsky, Juergen Gross,
linux-kernel, netdev
In-Reply-To: <21bd3cd7-68ed-45cd-9728-73c88c79fe65@default>
>>> On 31.10.16 at 09:28, <dongli.zhang@oracle.com> wrote:
>> > ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
>> > - BUG_ON((signed short)ref < 0);
>> > + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
>
>> You really need to cast to plain (or signed) long here - casting to
>> unsigned long will work only in 32-bit configurations, as otherwise
>> you lose the sign of the value.
>
> Seems the sign of value would not be lost since casting to unsigned long will
> use signed extension. Is my understanding wrong or did I miss anything?
ref being of type grant_ref_t, which is a typedef of uint32_t, I can't
see how the conversion to unsigned long would be using sign
extension. Did you look at the generated code? (If ref was of a signed
type, I don't think the original author would have found a need to cast
it to signed short.)
> I have verified this with both sample userspace helloworld program
> and a kernel module.
Are you saying you did see the warning trigger with a 64-bit kernel?
I'd be very surprised, but of course I may be overlooking something.
Jan
^ permalink raw reply
* [PATCH net-next] ipv4: fib: Replay events when registering FIB notifier
From: idosch @ 2016-10-31 8:29 UTC (permalink / raw)
To: netdev
Cc: davem, jiri, mlxsw, roopa, nikolay, dsa, andy, alexander.h.duyck,
vivien.didelot, f.fainelli, andrew, kuznet, jmorris, yoshfuji,
kaber, Ido Schimmel
From: Ido Schimmel <idosch@mellanox.com>
When registering a FIB notifier block we should notify the caller of
already existing FIB entries and rules, as it would otherwise have an
incomplete view of the FIB tables. This is especially important for
switchdev drivers that support FIB offloads. Failing to notify them of
existing entries may lead to packet loss.
Upon registration, walk the leafs of all the routing tables and for each
leaf send notification of existing FIB aliases. Similarly, when
unregistering the notifier synthesize a deletion event, thereby
relieving potential callers from the need to perform cleanup.
The above is consistent with the netdevice notification chain, where
"registration and up events are replayed to the new notifier" upon
registration.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
net/ipv4/fib_trie.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 145 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 31cef36..608f9d4 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -86,15 +86,102 @@
static BLOCKING_NOTIFIER_HEAD(fib_chain);
+static void fib_notify(struct net *net, struct notifier_block *nb,
+ enum fib_event_type event_type);
+
+static int call_fib_notifier(struct notifier_block *nb, struct net *net,
+ enum fib_event_type event_type,
+ struct fib_notifier_info *info)
+{
+ info->net = net;
+ return nb->notifier_call(nb, event_type, info);
+}
+
+static int call_fib_entry_notifier(struct notifier_block *nb, struct net *net,
+ enum fib_event_type event_type, u32 dst,
+ int dst_len, struct fib_info *fi,
+ u8 tos, u8 type, u32 tb_id, u32 nlflags)
+{
+ struct fib_entry_notifier_info info = {
+ .dst = dst,
+ .dst_len = dst_len,
+ .fi = fi,
+ .tos = tos,
+ .type = type,
+ .tb_id = tb_id,
+ .nlflags = nlflags,
+ };
+ return call_fib_notifier(nb, net, event_type, &info.info);
+}
+
+/**
+ * register_fib_notifier - register a fib notifier block
+ * @nb: notifier
+ *
+ * Register a notifier to be called when FIB entries or rules are
+ * added or removed. A negative errno code is returned on failure.
+ *
+ * When registered, all FIB addition events are replayed to the new
+ * notifier to allow the caller to have a complete view of the FIB
+ * tables.
+ */
+
int register_fib_notifier(struct notifier_block *nb)
{
- return blocking_notifier_chain_register(&fib_chain, nb);
+ struct net *net;
+ int err;
+
+ rtnl_lock();
+ err = blocking_notifier_chain_register(&fib_chain, nb);
+ if (err)
+ goto unlock;
+ for_each_net(net) {
+ struct fib_notifier_info info;
+
+ if (net->ipv4.fib_has_custom_rules)
+ call_fib_notifier(nb, net, FIB_EVENT_RULE_ADD, &info);
+ fib_notify(net, nb, FIB_EVENT_ENTRY_ADD);
+ }
+
+unlock:
+ rtnl_unlock();
+ return err;
}
EXPORT_SYMBOL(register_fib_notifier);
+/**
+ * unregister_fib_notifier - unregister a fib notifier block
+ * @nb: notifier
+ *
+ * unregister a notifier previously registered by
+ * register_fib_notifier(). A negative errno code is returned on
+ * failure.
+ *
+ * After unregistering, FIB deletion events are synthesized to the
+ * removed notifier for all present FIB entries. This removes the
+ * need for special case cleanup code.
+ */
+
int unregister_fib_notifier(struct notifier_block *nb)
{
- return blocking_notifier_chain_unregister(&fib_chain, nb);
+ struct net *net;
+ int err;
+
+ rtnl_lock();
+ err = blocking_notifier_chain_unregister(&fib_chain, nb);
+ if (err)
+ goto unlock;
+ for_each_net(net) {
+ struct fib_notifier_info info;
+
+ fib_notify(net, nb, FIB_EVENT_ENTRY_DEL);
+ if (net->ipv4.fib_has_custom_rules)
+ call_fib_notifier(nb, net, FIB_EVENT_RULE_DEL, &info);
+ }
+
+unlock:
+ rtnl_unlock();
+ return err;
}
EXPORT_SYMBOL(unregister_fib_notifier);
@@ -1834,6 +1921,62 @@ int fib_table_flush(struct net *net, struct fib_table *tb)
return found;
}
+static void fib_leaf_notify(struct net *net, struct key_vector *l,
+ struct fib_table *tb, struct notifier_block *nb,
+ enum fib_event_type event_type)
+{
+ struct fib_alias *fa;
+
+ hlist_for_each_entry(fa, &l->leaf, fa_list) {
+ struct fib_info *fi = fa->fa_info;
+
+ if (!fi)
+ continue;
+
+ /* local and main table can share the same trie,
+ * so don't notify twice for the same entry.
+ */
+ if (tb->tb_id != fa->tb_id)
+ continue;
+
+ call_fib_entry_notifier(nb, net, event_type, l->key,
+ KEYLENGTH - fa->fa_slen, fi, fa->fa_tos,
+ fa->fa_type, fa->tb_id, 0);
+ }
+}
+
+static void fib_table_notify(struct net *net, struct fib_table *tb,
+ struct notifier_block *nb,
+ enum fib_event_type event_type)
+{
+ struct trie *t = (struct trie *)tb->tb_data;
+ struct key_vector *l, *tp = t->kv;
+ t_key key = 0;
+
+ while ((l = leaf_walk_rcu(&tp, key)) != NULL) {
+ fib_leaf_notify(net, l, tb, nb, event_type);
+
+ key = l->key + 1;
+ /* stop in case of wrap around */
+ if (key < l->key)
+ break;
+ }
+}
+
+static void fib_notify(struct net *net, struct notifier_block *nb,
+ enum fib_event_type event_type)
+{
+ unsigned int h;
+
+ for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
+ struct hlist_head *head = &net->ipv4.fib_table_hash[h];
+ struct fib_table *tb;
+
+ hlist_for_each_entry(tb, head, tb_hlist)
+ fib_table_notify(net, tb, nb, event_type);
+ }
+}
+
static void __trie_free_rcu(struct rcu_head *head)
{
struct fib_table *tb = container_of(head, struct fib_table, rcu);
--
2.7.4
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: Dongli Zhang @ 2016-10-31 8:28 UTC (permalink / raw)
To: JBeulich
Cc: boris.ostrovsky, netdev, JGross, xen-devel, david.vrabel,
linux-kernel
> > ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
> > - BUG_ON((signed short)ref < 0);
> > + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
> You really need to cast to plain (or signed) long here - casting to
> unsigned long will work only in 32-bit configurations, as otherwise
> you lose the sign of the value.
Seems the sign of value would not be lost since casting to unsigned long will
use signed extension. Is my understanding wrong or did I miss anything? I have
verified this with both sample userspace helloworld program and a kernel
module.
> And then just issuing a warning here is insufficient, I think: Either
> you follow David's line of thought assuming that no failure here is
Keeping this can help debug xen-netfront.
> possible at all (in which case the BUG_ON() can be ditched without
> replacement), or you follow your original one (which matches mine)
> that we can't exclude an error here because of a bug elsewhere,
> in which case this either needs to stay BUG_ON() or should be
> followed by some form of bailing out (so that the bad ref won't get
> stored, preventing its later use from causing further damage).
The reason I use warning instead BUG_ON is that Linus suggested use
WARN_ON_ONCE() in a previous email:
http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html
I would change to BUG_ON() if it is OK to you.
Thank you very much!
Dongli Zhang
----- Original Message -----
From: JBeulich@suse.com
To: dongli.zhang@oracle.com
Cc: david.vrabel@citrix.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, JGross@suse.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Sent: Monday, October 31, 2016 3:48:03 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
>>> On 31.10.16 at 06:38, <dongli.zhang@oracle.com> wrote:
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
> queue->rx_skbs[id] = skb;
>
> ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
> - BUG_ON((signed short)ref < 0);
> + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
You really need to cast to plain (or signed) long here - casting to
unsigned long will work only in 32-bit configurations, as otherwise
you lose the sign of the value.
And then just issuing a warning here is insufficient, I think: Either
you follow David's line of thought assuming that no failure here is
possible at all (in which case the BUG_ON() can be ditched without
replacement), or you follow your original one (which matches mine)
that we can't exclude an error here because of a bug elsewhere,
in which case this either needs to stay BUG_ON() or should be
followed by some form of bailing out (so that the bad ref won't get
stored, preventing its later use from causing further damage).
Jan
^ permalink raw reply
* Re: [PATCH net-next 3/4] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-10-31 8:19 UTC (permalink / raw)
To: Tom Herbert
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann,
Linux Kernel Network Developers, roopa
In-Reply-To: <CALx6S35TOQumWFu1ha9nkNNOEwq2Y2VH6oCOK6F3HZg97omQgw@mail.gmail.com>
On 10/30/16 at 06:28pm, Tom Herbert wrote:
> On Sun, Oct 30, 2016 at 2:47 PM, Thomas Graf <tgraf@suug.ch> wrote:
> > Instead of building complex logic, we can allow the program to return
> > a code to indicate when to perform another route lookup just as we do
> > for the redirect case. Just because the destination address has
> > changed may not require another lookup in all cases. A typical example
> > would be a program rewriting addresses for the default route to other
> > address which are always handled by the default route as well. An
> > unconditional lookup would hurt performance in many cases.
>
> Right, that's why we rely on a dst cache. Any use of LWT that
> encapsulates or tunnels to a fixed destination (ILA, VXLAN, IPIP,
> etc.) would want to use the dst cache optimization to avoid the second
> lookup. The ILA LWT code used to call orig output and that worked as
> long as we could set the default router as the gateway "via". It was
> something we were able to deploy, but not a general solution.
> Integrating properly with routing gives a much better solution IMO.
> Note that David Lebrun's latest LWT Segment Routing patch does the
> second lookup with the dst cache to try to avoid it.
Yes, I saw both ILA and SR dst_cache. I was planning on addressing
the conditional reroute in a second step but it looks fairly simple
actually so I'm fine adding this in a v2 based on a return code. I
will limit lwt-bpf to AF_INET && AF_INET6 though.
^ permalink raw reply
* RE: [PATCH net] r8152: Fix broken RX checksums.
From: Hayes Wang @ 2016-10-31 8:14 UTC (permalink / raw)
To: David Miller, mlord@pobox.com
Cc: nic_swsd, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161030.235342.134481656830778556.davem@davemloft.net>
> >>> The r8152 driver has been broken since (approx) 3.16.xx
> >>> when support was added for hardware RX checksums
> >>> on newer chip versions. Symptoms include random
> >>> segfaults and silent data corruption over NFS.
> >>>
> >>> The hardware checksum logig does not work on the VER_02
> >>> dongles I have here when used with a slow embedded system CPU.
> >>> Google reveals others reporting similar issues on Raspberry Pi.
> >>>
> >>> So, disable hardware RX checksum support for VER_02, and fix
> >>> an obvious coding error for IPV6 checksums in the same function.
> >>>
> >>> Because this bug results in silent data corruption,
> >>> it is a good candidate for back-porting to -stable >= 3.16.xx.
> >>>
> >>> Signed-off-by: Mark Lord <mlord@pobox.com>
> >>
> >> Applied and queued up for -stable, thanks.
> >
> > Thanks. Now that this is taken care of, I do wonder if perhaps
> > RX checksums ought to be enabled at all for ANY versions of this chip?
>
> You should really start a dialogue with the developer who has been
> making the most, if not all, of the major changes to this driver over
> the past few years, Hayes Wang.
Our hw engineer says only VER_01 has the issue about rx checksum.
I need more information for checking it.
Best Regards,
Hayes
^ permalink raw reply
* Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: Jan Beulich @ 2016-10-31 7:47 UTC (permalink / raw)
To: Dongli Zhang
Cc: david.vrabel, xen-devel, boris.ostrovsky, Juergen Gross,
linux-kernel, netdev
In-Reply-To: <1477892309-7150-1-git-send-email-dongli.zhang@oracle.com>
>>> On 31.10.16 at 06:38, <dongli.zhang@oracle.com> wrote:
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
> queue->rx_skbs[id] = skb;
>
> ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
> - BUG_ON((signed short)ref < 0);
> + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
You really need to cast to plain (or signed) long here - casting to
unsigned long will work only in 32-bit configurations, as otherwise
you lose the sign of the value.
And then just issuing a warning here is insufficient, I think: Either
you follow David's line of thought assuming that no failure here is
possible at all (in which case the BUG_ON() can be ditched without
replacement), or you follow your original one (which matches mine)
that we can't exclude an error here because of a bug elsewhere,
in which case this either needs to stay BUG_ON() or should be
followed by some form of bailing out (so that the bad ref won't get
stored, preventing its later use from causing further damage).
Jan
^ permalink raw reply
* Re: Let's do P4
From: Jiri Pirko @ 2016-10-31 7:47 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Alexei Starovoitov, Thomas Graf, John Fastabend, Jakub Kicinski,
Linux NetDev, David Miller, Jamal Hadi Salim, roopa, simon.horman,
ast, daniel, prem, Hannes Frederic Sowa, Jiri Benc, Tom Herbert,
mattyk, idosch, eladr, yotamg, nogahf, ogerlitz, John W. Linville,
Andy Gospodarek, Florian Fainelli, dsa
In-Reply-To: <CAHo-Ooz82uFsf6F=pU-jrR-KOADWuRmkiAfKaB_sQGc=4N7z4g@mail.gmail.com>
Mon, Oct 31, 2016 at 07:03:53AM CET, zenczykowski@gmail.com wrote:
>One thing to consider...
>
>Just because the compiler could be in the kernel, doesn't mean it has to be.
>
>One could envision a hotplug/modprobe like helper program that the
>kernel executes
>when it wants to translate from one encoding (say p4) to another (say [e]bpf).
>
>This keeps complexity (compiler) out of the kernel, while still
>allowing us to have
>the illusion of only one interface to sw/hw. And it has the nice
>benefit of allowing us
>to use existing compiler toolchains...
This idea was repeatedly marked as unacceptable.
^ permalink raw reply
* Re: [bnx2] [Regression 4.8] Driver loading fails without firmware
From: Baoquan He @ 2016-10-31 6:38 UTC (permalink / raw)
To: Paul Menzel
Cc: Sony Chacko, Dept-HSGLinuxNICDev, netdev, David S. Miller, dvteam,
dyoung
In-Reply-To: <20161031035930.GB7138@x1>
On 10/31/16 at 11:59am, Baoquan He wrote:
> Hi Paul,
>
> On 10/30/16 at 12:05pm, Paul Menzel wrote:
> > Dear Baoquan,
> >
> >
> > Am Samstag, den 29.10.2016, 10:55 +0800 schrieb Baoquan He:
> > > On 10/27/16 at 03:21pm, Paul Menzel wrote:
> >
> > > > > > Baoquan, could you please fix this regression. My suggestion is, that you
> > > > > > add the old code back, but check if the firmware has been loaded. If it
> > > > > > hasn’t, load it again.
> > > > > >
> > > > > > That way, people can update their Linux kernel, and it continues working
> > > > > > without changing the initramfs, or anything else.
> > > > >
> > > > > I saw your mail but I am also not familiar with bnx2 driver. As the
> > > > > commit log says I just tried to make bnx2 driver reset itself earlier.
> > > > >
> > > > > So you did a git bisect and found this commit caused the regression,
> > > > > right? If yes, and network developers have no action, I will look into
> > > > > the code and see if I have idea to fix it.
> > > >
> > > > Well, I looked through the commits and found that one, which would explain
> > > > the changed behavior.
> > > >
> > > > To be sure, and to follow your request, I took Linux 4.8.4 and reverted your
> > > > commit (attached). Then I deleted the firmware again from the initramfs, and
> > > > rebooted. The devices showed up just fine as before.
> > > >
> > > > So to summarize, the commit is indeed the culprit.
> >
> > > Sorry for this.
> > >
> > > Could you tell the steps to reproduce? I will find a machine with bnx2
> > > NIC and check if there's other ways.
> >
> > Well, delete the bnx2 firmware files from the initramfs, and start the
> > system.
> >
> > Did you read my proposal, to try to load the firmware twice, that means,
> > basically revert only the deleted lines of your commit, and add an
> > additional check?
>
Please ignore this one, I have reproduced it. Will post a fix after
test.
>
> I got a x86_64 system with bnx2 NIC, and clone Linus's git tree into
> that system. Then building a new kernel 4.9.0-rc3+ with new initramfs.
> But when I uncompressed the new initramfs, didn't find bnx2 related
> firmware, no bnx2 files under lib/firmware of uncompressed initramfs
> folder. While I did see them in /lib/firmware/bnx2/bnx2-xxxxx.fw. Could
> you please say it more specifically how I should do to reproduce the
> failure you encountered? I think your proposal looks good, just need a
> test before post.
>
> Thanks
> Baoquan
^ permalink raw reply
* Re: [PATCH v2 3/6] Documentation: devicetree: net: add NS2 bindings to amac
From: Rob Herring @ 2016-10-31 6:20 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Mark Rutland, Florian Fainelli,
rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477688219-3871-4-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Fri, Oct 28, 2016 at 04:56:56PM -0400, Jon Mason wrote:
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/brcm,amac.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..f2b194e 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,11 +2,12 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> -------------------------------------------------------------
>
> Required properties:
> - - compatible: "brcm,amac" or "brcm,nsp-amac"
> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
One per line is preferred.
> - reg: Address and length of the GMAC registers,
> Address and length of the GMAC IDM registers
> + Address and length of the NIC Port Manager registers (optional)
> - reg-names: Names of the registers. Must have both "amac_base" and
> - "idm_base"
> + "idm_base". "nicpm_base" is optional (required for NS2)
Is nicpm_base optional on some SoCs? If not just say which ones it
applies to. A separate line will make that clearer.
_base is kind of redundant too, but it's already done.
> - interrupts: Interrupt number
>
> Optional properties:
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Let's do P4
From: Maciej Żenczykowski @ 2016-10-31 6:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jiri Pirko, Thomas Graf, John Fastabend, Jakub Kicinski,
Linux NetDev, David Miller, Jamal Hadi Salim, roopa, simon.horman,
ast, daniel, prem, Hannes Frederic Sowa, Jiri Benc, Tom Herbert,
mattyk, idosch, eladr, yotamg, nogahf, ogerlitz, John W. Linville,
Andy Gospodarek, Florian Fainelli, dsa, vivien.d
In-Reply-To: <20161030223903.GA6658@ast-mbp.hil-sfehihf.abq.wayport.net>
One thing to consider...
Just because the compiler could be in the kernel, doesn't mean it has to be.
One could envision a hotplug/modprobe like helper program that the
kernel executes
when it wants to translate from one encoding (say p4) to another (say [e]bpf).
This keeps complexity (compiler) out of the kernel, while still
allowing us to have
the illusion of only one interface to sw/hw. And it has the nice
benefit of allowing us
to use existing compiler toolchains...
^ permalink raw reply
* [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: Dongli Zhang @ 2016-10-31 5:38 UTC (permalink / raw)
To: linux-kernel, xen-devel, netdev; +Cc: boris.ostrovsky, david.vrabel, jgross
While grant reference is of type uint32_t, xen-netfront erroneously casts
it to signed short in BUG_ON().
This would lead to the xen domU panic during boot-up or migration when it
is attached with lots of paravirtual devices.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
drivers/net/xen-netfront.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e17879d..189a28d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
queue->rx_skbs[id] = skb;
ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
- BUG_ON((signed short)ref < 0);
+ WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
queue->grant_rx_ref[id] = ref;
page = skb_frag_page(&skb_shinfo(skb)->frags[0]);
@@ -428,7 +428,7 @@ static void xennet_tx_setup_grant(unsigned long gfn, unsigned int offset,
id = get_id_from_freelist(&queue->tx_skb_freelist, queue->tx_skbs);
tx = RING_GET_REQUEST(&queue->tx, queue->tx.req_prod_pvt++);
ref = gnttab_claim_grant_reference(&queue->gref_tx_head);
- BUG_ON((signed short)ref < 0);
+ WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
gfn, GNTMAP_readonly);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 7/7] qed: Learn resources from management firmware
From: Yuval Mintz @ 2016-10-31 5:14 UTC (permalink / raw)
To: davem, netdev; +Cc: Tomer Tayar, Yuval Mintz
In-Reply-To: <1477890867-3789-1-git-send-email-Yuval.Mintz@cavium.com>
From: Tomer Tayar <Tomer.Tayar@cavium.com>
Currently, each interfaces assumes it receives an equal portion
of HW/FW resources, but this is wasteful - different partitions
[and specifically, parititions exposing different protocol support]
might require different resources.
Implement a new resource learning scheme where the information is
received directly from the management firmware [which has knowledge
of all of the functions and can serve as arbiter].
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 6 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 291 ++++++++++++++++++++++++------
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 46 +++++
drivers/net/ethernet/qlogic/qed/qed_l2.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 42 +++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 15 ++
include/linux/qed/qed_eth_if.h | 2 +-
7 files changed, 341 insertions(+), 63 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index 6d3013f..50b8a01 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -154,7 +154,10 @@ struct qed_qm_iids {
u32 tids;
};
-enum QED_RESOURCES {
+/* HW / FW resources, output of features supported below, most information
+ * is received from MFW.
+ */
+enum qed_resources {
QED_SB,
QED_L2_QUEUE,
QED_VPORT,
@@ -166,6 +169,7 @@ enum QED_RESOURCES {
QED_RDMA_CNQ_RAM,
QED_ILT,
QED_LL2_QUEUE,
+ QED_CMDQS_CQS,
QED_RDMA_STATS_QUEUE,
QED_MAX_RESC,
};
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index d996afe..5be7b8a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1512,47 +1512,240 @@ static void qed_hw_set_feat(struct qed_hwfn *p_hwfn)
RESC_NUM(p_hwfn, QED_SB), num_features);
}
-static int qed_hw_get_resc(struct qed_hwfn *p_hwfn)
+static enum resource_id_enum qed_hw_get_mfw_res_id(enum qed_resources res_id)
+{
+ enum resource_id_enum mfw_res_id = RESOURCE_NUM_INVALID;
+
+ switch (res_id) {
+ case QED_SB:
+ mfw_res_id = RESOURCE_NUM_SB_E;
+ break;
+ case QED_L2_QUEUE:
+ mfw_res_id = RESOURCE_NUM_L2_QUEUE_E;
+ break;
+ case QED_VPORT:
+ mfw_res_id = RESOURCE_NUM_VPORT_E;
+ break;
+ case QED_RSS_ENG:
+ mfw_res_id = RESOURCE_NUM_RSS_ENGINES_E;
+ break;
+ case QED_PQ:
+ mfw_res_id = RESOURCE_NUM_PQ_E;
+ break;
+ case QED_RL:
+ mfw_res_id = RESOURCE_NUM_RL_E;
+ break;
+ case QED_MAC:
+ case QED_VLAN:
+ /* Each VFC resource can accommodate both a MAC and a VLAN */
+ mfw_res_id = RESOURCE_VFC_FILTER_E;
+ break;
+ case QED_ILT:
+ mfw_res_id = RESOURCE_ILT_E;
+ break;
+ case QED_LL2_QUEUE:
+ mfw_res_id = RESOURCE_LL2_QUEUE_E;
+ break;
+ case QED_RDMA_CNQ_RAM:
+ case QED_CMDQS_CQS:
+ /* CNQ/CMDQS are the same resource */
+ mfw_res_id = RESOURCE_CQS_E;
+ break;
+ case QED_RDMA_STATS_QUEUE:
+ mfw_res_id = RESOURCE_RDMA_STATS_QUEUE_E;
+ break;
+ default:
+ break;
+ }
+
+ return mfw_res_id;
+}
+
+static u32 qed_hw_get_dflt_resc_num(struct qed_hwfn *p_hwfn,
+ enum qed_resources res_id)
{
- u8 enabled_func_idx = p_hwfn->enabled_func_idx;
- u32 *resc_start = p_hwfn->hw_info.resc_start;
u8 num_funcs = p_hwfn->num_funcs_on_engine;
- u32 *resc_num = p_hwfn->hw_info.resc_num;
struct qed_sb_cnt_info sb_cnt_info;
- int i, max_vf_vlan_filters;
+ u32 dflt_resc_num = 0;
- memset(&sb_cnt_info, 0, sizeof(sb_cnt_info));
+ switch (res_id) {
+ case QED_SB:
+ memset(&sb_cnt_info, 0, sizeof(sb_cnt_info));
+ qed_int_get_num_sbs(p_hwfn, &sb_cnt_info);
+ dflt_resc_num = sb_cnt_info.sb_cnt;
+ break;
+ case QED_L2_QUEUE:
+ dflt_resc_num = MAX_NUM_L2_QUEUES_BB / num_funcs;
+ break;
+ case QED_VPORT:
+ dflt_resc_num = MAX_NUM_VPORTS_BB / num_funcs;
+ break;
+ case QED_RSS_ENG:
+ dflt_resc_num = ETH_RSS_ENGINE_NUM_BB / num_funcs;
+ break;
+ case QED_PQ:
+ /* The granularity of the PQs is 8 */
+ dflt_resc_num = MAX_QM_TX_QUEUES_BB / num_funcs;
+ dflt_resc_num &= ~0x7;
+ break;
+ case QED_RL:
+ dflt_resc_num = MAX_QM_GLOBAL_RLS / num_funcs;
+ break;
+ case QED_MAC:
+ case QED_VLAN:
+ /* Each VFC resource can accommodate both a MAC and a VLAN */
+ dflt_resc_num = ETH_NUM_MAC_FILTERS / num_funcs;
+ break;
+ case QED_ILT:
+ dflt_resc_num = PXP_NUM_ILT_RECORDS_BB / num_funcs;
+ break;
+ case QED_LL2_QUEUE:
+ dflt_resc_num = MAX_NUM_LL2_RX_QUEUES / num_funcs;
+ break;
+ case QED_RDMA_CNQ_RAM:
+ case QED_CMDQS_CQS:
+ /* CNQ/CMDQS are the same resource */
+ dflt_resc_num = NUM_OF_CMDQS_CQS / num_funcs;
+ break;
+ case QED_RDMA_STATS_QUEUE:
+ dflt_resc_num = RDMA_NUM_STATISTIC_COUNTERS_BB / num_funcs;
+ break;
+ default:
+ break;
+ }
-#ifdef CONFIG_QED_SRIOV
- max_vf_vlan_filters = QED_ETH_MAX_VF_NUM_VLAN_FILTERS;
-#else
- max_vf_vlan_filters = 0;
-#endif
+ return dflt_resc_num;
+}
+
+static const char *qed_hw_get_resc_name(enum qed_resources res_id)
+{
+ switch (res_id) {
+ case QED_SB:
+ return "SB";
+ case QED_L2_QUEUE:
+ return "L2_QUEUE";
+ case QED_VPORT:
+ return "VPORT";
+ case QED_RSS_ENG:
+ return "RSS_ENG";
+ case QED_PQ:
+ return "PQ";
+ case QED_RL:
+ return "RL";
+ case QED_MAC:
+ return "MAC";
+ case QED_VLAN:
+ return "VLAN";
+ case QED_RDMA_CNQ_RAM:
+ return "RDMA_CNQ_RAM";
+ case QED_ILT:
+ return "ILT";
+ case QED_LL2_QUEUE:
+ return "LL2_QUEUE";
+ case QED_CMDQS_CQS:
+ return "CMDQS_CQS";
+ case QED_RDMA_STATS_QUEUE:
+ return "RDMA_STATS_QUEUE";
+ default:
+ return "UNKNOWN_RESOURCE";
+ }
+}
- qed_int_get_num_sbs(p_hwfn, &sb_cnt_info);
+static int qed_hw_set_resc_info(struct qed_hwfn *p_hwfn,
+ enum qed_resources res_id)
+{
+ u32 dflt_resc_num = 0, dflt_resc_start = 0, mcp_resp, mcp_param;
+ u32 *p_resc_num, *p_resc_start;
+ struct resource_info resc_info;
+ int rc;
+
+ p_resc_num = &RESC_NUM(p_hwfn, res_id);
+ p_resc_start = &RESC_START(p_hwfn, res_id);
+
+ /* Default values assumes that each function received equal share */
+ dflt_resc_num = qed_hw_get_dflt_resc_num(p_hwfn, res_id);
+ if (!dflt_resc_num) {
+ DP_ERR(p_hwfn,
+ "Failed to get default amount for resource %d [%s]\n",
+ res_id, qed_hw_get_resc_name(res_id));
+ return -EINVAL;
+ }
+ dflt_resc_start = dflt_resc_num * p_hwfn->enabled_func_idx;
+
+ memset(&resc_info, 0, sizeof(resc_info));
+ resc_info.res_id = qed_hw_get_mfw_res_id(res_id);
+ if (resc_info.res_id == RESOURCE_NUM_INVALID) {
+ DP_ERR(p_hwfn,
+ "Failed to match resource %d [%s] with the MFW resources\n",
+ res_id, qed_hw_get_resc_name(res_id));
+ return -EINVAL;
+ }
+
+ rc = qed_mcp_get_resc_info(p_hwfn, p_hwfn->p_main_ptt, &resc_info,
+ &mcp_resp, &mcp_param);
+ if (rc) {
+ DP_NOTICE(p_hwfn,
+ "MFW response failure for an allocation request for resource %d [%s]\n",
+ res_id, qed_hw_get_resc_name(res_id));
+ return rc;
+ }
+
+ /* Default driver values are applied in the following cases:
+ * - The resource allocation MB command is not supported by the MFW
+ * - There is an internal error in the MFW while processing the request
+ * - The resource ID is unknown to the MFW
+ */
+ if (mcp_resp != FW_MSG_CODE_RESOURCE_ALLOC_OK &&
+ mcp_resp != FW_MSG_CODE_RESOURCE_ALLOC_DEPRECATED) {
+ DP_NOTICE(p_hwfn,
+ "Resource %d [%s]: No allocation info was received [mcp_resp 0x%x]. Applying default values [num %d, start %d].\n",
+ res_id,
+ qed_hw_get_resc_name(res_id),
+ mcp_resp, dflt_resc_num, dflt_resc_start);
+ *p_resc_num = dflt_resc_num;
+ *p_resc_start = dflt_resc_start;
+ goto out;
+ }
+
+ /* Special handling for status blocks; Would be revised in future */
+ if (res_id == QED_SB) {
+ resc_info.size -= 1;
+ resc_info.offset -= p_hwfn->enabled_func_idx;
+ }
+
+ *p_resc_num = resc_info.size;
+ *p_resc_start = resc_info.offset;
+
+out:
+ /* PQs have to divide by 8 [that's the HW granularity].
+ * Reduce number so it would fit.
+ */
+ if ((res_id == QED_PQ) && ((*p_resc_num % 8) || (*p_resc_start % 8))) {
+ DP_INFO(p_hwfn,
+ "PQs need to align by 8; Number %08x --> %08x, Start %08x --> %08x\n",
+ *p_resc_num,
+ (*p_resc_num) & ~0x7,
+ *p_resc_start, (*p_resc_start) & ~0x7);
+ *p_resc_num &= ~0x7;
+ *p_resc_start &= ~0x7;
+ }
- resc_num[QED_SB] = min_t(u32,
- (MAX_SB_PER_PATH_BB / num_funcs),
- sb_cnt_info.sb_cnt);
- resc_num[QED_L2_QUEUE] = MAX_NUM_L2_QUEUES_BB / num_funcs;
- resc_num[QED_VPORT] = MAX_NUM_VPORTS_BB / num_funcs;
- resc_num[QED_RSS_ENG] = ETH_RSS_ENGINE_NUM_BB / num_funcs;
- resc_num[QED_PQ] = MAX_QM_TX_QUEUES_BB / num_funcs;
- resc_num[QED_RL] = min_t(u32, 64, resc_num[QED_VPORT]);
- resc_num[QED_MAC] = ETH_NUM_MAC_FILTERS / num_funcs;
- resc_num[QED_VLAN] = (ETH_NUM_VLAN_FILTERS - 1 /*For vlan0*/) /
- num_funcs;
- resc_num[QED_ILT] = PXP_NUM_ILT_RECORDS_BB / num_funcs;
- resc_num[QED_LL2_QUEUE] = MAX_NUM_LL2_RX_QUEUES / num_funcs;
- resc_num[QED_RDMA_CNQ_RAM] = NUM_OF_CMDQS_CQS / num_funcs;
- resc_num[QED_RDMA_STATS_QUEUE] = RDMA_NUM_STATISTIC_COUNTERS_BB /
- num_funcs;
-
- for (i = 0; i < QED_MAX_RESC; i++)
- resc_start[i] = resc_num[i] * enabled_func_idx;
+ return 0;
+}
+
+static int qed_hw_get_resc(struct qed_hwfn *p_hwfn)
+{
+ u8 res_id;
+ int rc;
+
+ for (res_id = 0; res_id < QED_MAX_RESC; res_id++) {
+ rc = qed_hw_set_resc_info(p_hwfn, res_id);
+ if (rc)
+ return rc;
+ }
/* Sanity for ILT */
- if (RESC_END(p_hwfn, QED_ILT) > PXP_NUM_ILT_RECORDS_BB) {
+ if ((RESC_END(p_hwfn, QED_ILT) > PXP_NUM_ILT_RECORDS_BB)) {
DP_NOTICE(p_hwfn, "Can't assign ILT pages [%08x,...,%08x]\n",
RESC_START(p_hwfn, QED_ILT),
RESC_END(p_hwfn, QED_ILT) - 1);
@@ -1562,34 +1755,12 @@ static int qed_hw_get_resc(struct qed_hwfn *p_hwfn)
qed_hw_set_feat(p_hwfn);
DP_VERBOSE(p_hwfn, NETIF_MSG_PROBE,
- "The numbers for each resource are:\n"
- "SB = %d start = %d\n"
- "L2_QUEUE = %d start = %d\n"
- "VPORT = %d start = %d\n"
- "PQ = %d start = %d\n"
- "RL = %d start = %d\n"
- "MAC = %d start = %d\n"
- "VLAN = %d start = %d\n"
- "ILT = %d start = %d\n"
- "LL2_QUEUE = %d start = %d\n",
- p_hwfn->hw_info.resc_num[QED_SB],
- p_hwfn->hw_info.resc_start[QED_SB],
- p_hwfn->hw_info.resc_num[QED_L2_QUEUE],
- p_hwfn->hw_info.resc_start[QED_L2_QUEUE],
- p_hwfn->hw_info.resc_num[QED_VPORT],
- p_hwfn->hw_info.resc_start[QED_VPORT],
- p_hwfn->hw_info.resc_num[QED_PQ],
- p_hwfn->hw_info.resc_start[QED_PQ],
- p_hwfn->hw_info.resc_num[QED_RL],
- p_hwfn->hw_info.resc_start[QED_RL],
- p_hwfn->hw_info.resc_num[QED_MAC],
- p_hwfn->hw_info.resc_start[QED_MAC],
- p_hwfn->hw_info.resc_num[QED_VLAN],
- p_hwfn->hw_info.resc_start[QED_VLAN],
- p_hwfn->hw_info.resc_num[QED_ILT],
- p_hwfn->hw_info.resc_start[QED_ILT],
- RESC_NUM(p_hwfn, QED_LL2_QUEUE),
- RESC_START(p_hwfn, QED_LL2_QUEUE));
+ "The numbers for each resource are:\n");
+ for (res_id = 0; res_id < QED_MAX_RESC; res_id++)
+ DP_VERBOSE(p_hwfn, NETIF_MSG_PROBE, "%s = %d start = %d\n",
+ qed_hw_get_resc_name(res_id),
+ RESC_NUM(p_hwfn, res_id),
+ RESC_START(p_hwfn, res_id));
return 0;
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 1d113ce..048f9a3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -8529,6 +8529,41 @@ struct mdump_config_stc {
u32 valid_logs;
};
+enum resource_id_enum {
+ RESOURCE_NUM_SB_E = 0,
+ RESOURCE_NUM_L2_QUEUE_E = 1,
+ RESOURCE_NUM_VPORT_E = 2,
+ RESOURCE_NUM_VMQ_E = 3,
+ RESOURCE_FACTOR_NUM_RSS_PF_E = 4,
+ RESOURCE_FACTOR_RSS_PER_VF_E = 5,
+ RESOURCE_NUM_RL_E = 6,
+ RESOURCE_NUM_PQ_E = 7,
+ RESOURCE_NUM_VF_E = 8,
+ RESOURCE_VFC_FILTER_E = 9,
+ RESOURCE_ILT_E = 10,
+ RESOURCE_CQS_E = 11,
+ RESOURCE_GFT_PROFILES_E = 12,
+ RESOURCE_NUM_TC_E = 13,
+ RESOURCE_NUM_RSS_ENGINES_E = 14,
+ RESOURCE_LL2_QUEUE_E = 15,
+ RESOURCE_RDMA_STATS_QUEUE_E = 16,
+ RESOURCE_MAX_NUM,
+ RESOURCE_NUM_INVALID = 0xFFFFFFFF
+};
+
+/* Resource ID is to be filled by the driver in the MB request
+ * Size, offset & flags to be filled by the MFW in the MB response
+ */
+struct resource_info {
+ enum resource_id_enum res_id;
+ u32 size; /* number of allocated resources */
+ u32 offset; /* Offset of the 1st resource */
+ u32 vf_size;
+ u32 vf_offset;
+ u32 flags;
+#define RESOURCE_ELEMENT_STRICT (1 << 0)
+};
+
union drv_union_data {
u32 ver_str[MCP_DRV_VER_STR_SIZE_DWORD];
struct mcp_mac wol_mac;
@@ -8549,6 +8584,7 @@ struct mdump_config_stc {
u64 reserved_stats[11];
struct ocbb_data_stc ocbb_info;
struct temperature_status_stc temp_info;
+ struct resource_info resource;
struct bist_nvm_image_att nvm_image_att;
struct mdump_config_stc mdump_config;
};
@@ -8576,6 +8612,7 @@ struct public_drv_mb {
#define DRV_MSG_CODE_BW_UPDATE_ACK 0x32000000
#define DRV_MSG_CODE_NIG_DRAIN 0x30000000
+#define DRV_MSG_GET_RESOURCE_ALLOC_MSG 0x34000000
#define DRV_MSG_CODE_VF_DISABLED_DONE 0xc0000000
#define DRV_MSG_CODE_CFG_VF_MSIX 0xc0010000
#define DRV_MSG_CODE_NVM_GET_FILE_ATT 0x00030000
@@ -8666,6 +8703,12 @@ struct public_drv_mb {
#define DRV_MB_PARAM_SET_LED_MODE_ON 0x1
#define DRV_MB_PARAM_SET_LED_MODE_OFF 0x2
+ /* Resource Allocation params - Driver version support */
+#define DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MAJOR_MASK 0xFFFF0000
+#define DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MAJOR_SHIFT 16
+#define DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MINOR_MASK 0x0000FFFF
+#define DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MINOR_SHIFT 0
+
#define DRV_MB_PARAM_BIST_REGISTER_TEST 1
#define DRV_MB_PARAM_BIST_CLOCK_TEST 2
#define DRV_MB_PARAM_BIST_NVM_TEST_NUM_IMAGES 3
@@ -8694,6 +8737,9 @@ struct public_drv_mb {
#define FW_MSG_CODE_DRV_UNLOAD_PORT 0x20120000
#define FW_MSG_CODE_DRV_UNLOAD_FUNCTION 0x20130000
#define FW_MSG_CODE_DRV_UNLOAD_DONE 0x21100000
+#define FW_MSG_CODE_RESOURCE_ALLOC_OK 0x34000000
+#define FW_MSG_CODE_RESOURCE_ALLOC_UNKNOWN 0x35000000
+#define FW_MSG_CODE_RESOURCE_ALLOC_DEPRECATED 0x36000000
#define FW_MSG_CODE_DRV_CFG_VF_MSIX_DONE 0xb0010000
#define FW_MSG_CODE_NVM_OK 0x00010000
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 6b0e22d..1e3a16e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1691,7 +1691,7 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
}
qed_vf_get_num_vlan_filters(&cdev->hwfns[0],
- &info->num_vlan_filters);
+ (u8 *)&info->num_vlan_filters);
qed_vf_get_port_mac(&cdev->hwfns[0], info->port_mac);
info->is_legacy = !!cdev->hwfns[0].vf_iov_info->b_pre_fp_hsi;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 0927488..d8e499e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1683,3 +1683,45 @@ int qed_mcp_bist_nvm_test_get_image_att(struct qed_hwfn *p_hwfn,
return rc;
}
+
+#define QED_RESC_ALLOC_VERSION_MAJOR 1
+#define QED_RESC_ALLOC_VERSION_MINOR 0
+#define QED_RESC_ALLOC_VERSION \
+ ((QED_RESC_ALLOC_VERSION_MAJOR << \
+ DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MAJOR_SHIFT) | \
+ (QED_RESC_ALLOC_VERSION_MINOR << \
+ DRV_MB_PARAM_RESOURCE_ALLOC_VERSION_MINOR_SHIFT))
+int qed_mcp_get_resc_info(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct resource_info *p_resc_info,
+ u32 *p_mcp_resp, u32 *p_mcp_param)
+{
+ struct qed_mcp_mb_params mb_params;
+ union drv_union_data *p_union_data;
+ int rc;
+
+ memset(&mb_params, 0, sizeof(mb_params));
+ mb_params.cmd = DRV_MSG_GET_RESOURCE_ALLOC_MSG;
+ mb_params.param = QED_RESC_ALLOC_VERSION;
+ p_union_data = (union drv_union_data *)p_resc_info;
+ mb_params.p_data_src = p_union_data;
+ mb_params.p_data_dst = p_union_data;
+ rc = qed_mcp_cmd_and_union(p_hwfn, p_ptt, &mb_params);
+ if (rc)
+ return rc;
+
+ *p_mcp_resp = mb_params.mcp_resp;
+ *p_mcp_param = mb_params.mcp_param;
+
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_SP,
+ "MFW resource_info: version 0x%x, res_id 0x%x, size 0x%x, offset 0x%x, vf_size 0x%x, vf_offset 0x%x, flags 0x%x\n",
+ *p_mcp_param,
+ p_resc_info->res_id,
+ p_resc_info->size,
+ p_resc_info->offset,
+ p_resc_info->vf_size,
+ p_resc_info->vf_offset, p_resc_info->flags);
+
+ return 0;
+}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
index be8152d..407a2c1 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -689,4 +689,19 @@ int qed_mcp_ov_update_eswitch(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
enum qed_ov_eswitch eswitch);
+/**
+ * @brief - Gets the MFW allocation info for the given resource
+ *
+ * @param p_hwfn
+ * @param p_ptt
+ * @param p_resc_info - descriptor of requested resource
+ * @param p_mcp_resp
+ * @param p_mcp_param
+ *
+ * @return int - 0 - operation was successful.
+ */
+int qed_mcp_get_resc_info(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct resource_info *p_resc_info,
+ u32 *p_mcp_resp, u32 *p_mcp_param);
#endif
diff --git a/include/linux/qed/qed_eth_if.h b/include/linux/qed/qed_eth_if.h
index 1513080..9755a3f 100644
--- a/include/linux/qed/qed_eth_if.h
+++ b/include/linux/qed/qed_eth_if.h
@@ -22,7 +22,7 @@ struct qed_dev_eth_info {
u8 num_tc;
u8 port_mac[ETH_ALEN];
- u8 num_vlan_filters;
+ u16 num_vlan_filters;
u16 num_mac_filters;
/* Legacy VF - this affects the datapath, so qede has to know */
--
1.9.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