* Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
From: Robert P. J. Day @ 2018-08-27 6:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux kernel netdev mailing list
In-Reply-To: <20180826135006.157d1bc2@xeon-e3>
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
> On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
> "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
> > apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-based linux box with multiple ports, where the current symptom is
> > that there is no userspace notification when someone simply unplugs
> > one of the ports ("ifconfig" shows that interface still RUNNING).
> >
> > as i read it, an active ethernet interface should be both UP (the
> > administrative state) and RUNNING (the RFC 2863-defined operational
> > state). if i unplug, i've verified on a standard net port on my laptop
> > that the interface is still UP, but no longer RUNNING, which makes
> > perfect sense. i plug back in, interface starts RUNNING again. so
> > where's the problem?
> >
> > i can see that whether ifconfig shows an interface RUNNING is
> > defined in net/core/dev.c:
> >
> > unsigned int dev_get_flags(const struct net_device *dev)
> > {
> > unsigned int flags;
> >
> > flags = (dev->flags & ~(IFF_PROMISC |
> > IFF_ALLMULTI |
> > IFF_RUNNING |
> > IFF_LOWER_UP |
> > IFF_DORMANT)) |
> > (dev->gflags & (IFF_PROMISC |
> > IFF_ALLMULTI));
> >
> > if (netif_running(dev)) {
> > if (netif_oper_up(dev))
> > flags |= IFF_RUNNING; <---- THERE
> > if (netif_carrier_ok(dev))
> > flags |= IFF_LOWER_UP;
> > if (netif_dormant(dev))
> > flags |= IFF_DORMANT;
> > }
> >
> > return flags;
> > }
> >
> > where netif_oper_up() is defined as:
> >
> > static inline bool netif_oper_up(const struct net_device *dev)
> > {
> > return (dev->operstate == IF_OPER_UP ||
> > dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
> > }
> >
> > so i am simply assuming that the underlying problem is that,
> > somewhere down below, the unplugging of a port is somehow not setting
> > dev->operstate to its proper value of IF_OPER_DOWN.
> >
> > that would clearly explain everything, and i'm about to dig even
> > further to see where the event of unplugging a port *should* be
> > recognized, but does this sound like a reasonable diagnosis? there
> > have been other problems with the programming of the FPGA, so it would
> > surprise absolutely no one to learn that this aspect was
> > misprogrammed.
> >
> > rday
> >
>
> There is no reason drivers should ever muck with flags directly.
> You probably are looking for netif_detach
i assume you mean netif_device_detach; i'll check into that.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH] r8169: don't use MSI-X on RTL8106e
From: Jian-Hong Pan @ 2018-08-27 10:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Heiner Kallweit, Thomas Gleixner, David Miller,
Realtek linux nic maintainers, netdev, Linux Kernel,
Linux Upstreaming Team, linux-pci, marc.zyngier, hch
In-Reply-To: <20180823133805.GE154536@bhelgaas-glaptop.roam.corp.google.com>
2018-08-23 21:38 GMT+08:00 Bjorn Helgaas <helgaas@kernel.org>:
> On Thu, Aug 23, 2018 at 06:46:28PM +0800, Jian-Hong Pan wrote:
>> > On 22.08.2018 13:44, Thomas Gleixner wrote:
>> >> Can you please do the following:
>>
>> Tested on ASUS X441AUR equipped with RTL8106e.
>> This is the laptop whose ethernet does not come back after resume, if
>> it does not fallback to MSI.
>> ...
>
>> dev@endless:~$ sudo lspci -xnnvvs 02:00.0
>> ...
>> 00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
>> 10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
>> 20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
>>
>> After comparing, there is no difference between before suspend and
>> after resume.
>
> It'd be better to compare the hex data directly and ignore the lspci
> decoding, since lspci doesn't decode everything. You only dumped the
> first 0x40 bytes of config space, and all capabilities, including the
> MSI and MSI-X capabilities, are past that:
>
>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
>> Vector table: BAR=4 offset=00000000
>> PBA: BAR=4 offset=00000800
>
> In addition, some of the MSI-X information for this device is in BAR
> 4. "lspci -xxx" will dump all config space, and you can use a tool
> like http://cmp.felk.cvut.cz/~pisa/linux/rdwrmem.c or
> https://github.com/billfarrow/pcimem to dump the BAR contents.
Tested on ASUS X441AUR equipped with RTL8106e without fallbacking to MSI again.
Use lspci and https://github.com/billfarrow/pcimem
Here is the status before suspend:
dev@endless:~$ sudo lspci -xxxs 02:00.0
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)
00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 01 50 c3 ff 08 00 00 00 00 00 00 00 00 00 00 00
50: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 b0 02 02 c0 8d 90 05 10 20 10 00 11 7c 47 00
80: 42 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 1f 08 0c 00 00 04 00 00 02 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 11 d0 03 80 04 00 00 00 04 08 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
dev@endless:~$ sudo ~/pcimem/pcimem
/sys/devices/pci0000\:00/0000\:00\:1c.4/0000\:02\:00.0/resource4 0
b*16384
[sudo] password for dev:
/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/resource4 opened.
Target offset is 0x0, page size is 4096
mmap(0, 16384, 0x3, 0x1, 3, 0x0)
PCI Memory mapped to address 0x7f15186d1000.
0x0000: 0x38
0x0001: 0x03
0x0002: 0xE0
0x0003: 0xFE
0x0004: 0x00
...
0x0010: 0x41
0x0011: 0x72
.
.
.
0x003C: 0x01
0x003D: 0x00
...
0x1000: 0x38
0x1001: 0x03
.
.
.
After resume:
dev@endless:~$ sudo lspci -xxxs 02:00.0
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)
00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 01 50 c3 ff 08 00 00 00 00 00 00 00 00 00 00 00
50: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 b0 02 02 c0 8d 90 05 10 20 10 00 11 7c 47 00
80: 42 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 1f 08 0c 00 00 04 00 00 02 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 11 d0 03 80 04 00 00 00 04 08 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
dev@endless:~$ sudo ~/pcimem/pcimem
/sys/devices/pci0000\:00/0000\:00\:1c.4/0000\:02\:00.0/resource4 0
b*16384
/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/resource4 opened.
Target offset is 0x0, page size is 4096
mmap(0, 16384, 0x3, 0x1, 3, 0x0)
PCI Memory mapped to address 0x7f8d68dd5000.
0x0000: 0xFF
...
The config is the same, but values in BAR=4 is weird after resume.
They all become 0xFF.
Regards,
Jian-Hong Pan
^ permalink raw reply
* Re: confusing comment, explanation of @IFF_RUNNING in if.h
From: Oliver Hartkopp @ 2018-08-27 7:11 UTC (permalink / raw)
To: Robert P. J. Day, Stephen Hemminger
Cc: Andrew Lunn, Linux kernel netdev mailing list
In-Reply-To: <alpine.LFD.2.21.1808270220020.11581@localhost.localdomain>
On 08/27/2018 08:20 AM, Robert P. J. Day wrote:
> On Sun, 26 Aug 2018, Stephen Hemminger wrote:
>
>> On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
>> "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>>
>>> On Sun, 26 Aug 2018, Andrew Lunn wrote:
>>>
>>>>> i ask since, in my testing, when the interface should have been
>>>>> up, the attribute file "operstate" for that interface showed
>>>>> "unknown", and i wondered how worried i should be about that.
>>>>
>>>> Hi Robert
>>>>
>>>> You should probably post the driver for review. A well written
>>>> driver should not even need to care about any of this. phylib and
>>>> the netdev driver code does all the work. It only gets interesting
>>>> when you don't have a PHY, e.g. a stacked device, like bonding, or a
>>>> virtual device like tun/tap.
>>>
>>> i wish, but i'm on contract, and proprietary, and NDA and all that.
>>> so i am reduced to crawling through the code, trying to figure out
>>> what is misconfigured that is causing all this grief.
>>>
>>> rday
>>>
>>
>> So you expect FOSS developers to help you with proprietary licensed
>> driver. Good Luck with that.
>
> sorry, i'm sure this will all be released upon production, just not
> while it's in the midst of development.
"released upon production" means usually:
Oh, we put that driver in a tar-ball on a CD that's shipped with the
product and which will get no further visibility nor (security) maintenance.
Robert, please tell your manager that creating a driver is no rocket
science and also brings no "costumer differentiation" which needs to be
covered under NDA.
Posting drivers and bring it into mainline Linux heavily increases the
quality due to the review process and all the people that are willing to
help you to get better. At the end your driver gets long-term
maintenance and other people can benefit from it - as your boss is
getting benefit from using Linux right now.
When something is "released upon production" it will not be in a quality
that it could go into the kernel - and no one will have the
time/money/ambition to spend effort on it then. You have just produced
one of the numerous dead out-of-tree drivers. That would be just sad.
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH v2 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-08-27 11:13 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, Jason A. Donenfeld,
Greg KH
In-Reply-To: <20180824213849.23647-18-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc1 next-20180827]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180827-073051
config: arm-raumfeld_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from <command-line>:0:0:
lib/zinc/chacha20/chacha20-arm-glue.h: In function 'chacha20_arch':
>> lib/zinc/chacha20/chacha20-arm-glue.h:36:3: error: implicit declaration of function 'chacha20_neon'; did you mean 'chacha20_arch'? [-Werror=implicit-function-declaration]
chacha20_neon(dst, src, len, key, counter);
^~~~~~~~~~~~~
chacha20_arch
cc1: some warnings being treated as errors
vim +36 lib/zinc/chacha20/chacha20-arm-glue.h
959d9378 Jason A. Donenfeld 2018-08-24 26
959d9378 Jason A. Donenfeld 2018-08-24 27 static inline bool chacha20_arch(u8 *dst, const u8 *src, const size_t len, const u32 key[8], const u32 counter[4], simd_context_t simd_context)
959d9378 Jason A. Donenfeld 2018-08-24 28 {
959d9378 Jason A. Donenfeld 2018-08-24 29 if (simd_context != HAVE_FULL_SIMD
959d9378 Jason A. Donenfeld 2018-08-24 30 #if defined(ARM_USE_NEON)
959d9378 Jason A. Donenfeld 2018-08-24 31 || !chacha20_use_neon
959d9378 Jason A. Donenfeld 2018-08-24 32 #endif
959d9378 Jason A. Donenfeld 2018-08-24 33 )
959d9378 Jason A. Donenfeld 2018-08-24 34 chacha20_arm(dst, src, len, key, counter);
959d9378 Jason A. Donenfeld 2018-08-24 35 else
959d9378 Jason A. Donenfeld 2018-08-24 @36 chacha20_neon(dst, src, len, key, counter);
959d9378 Jason A. Donenfeld 2018-08-24 37 return true;
959d9378 Jason A. Donenfeld 2018-08-24 38 }
959d9378 Jason A. Donenfeld 2018-08-24 39
:::::: The code at line 36 was first introduced by commit
:::::: 959d93782f7ebf927cceeeb5ba86331211abfcd8 zinc: ChaCha20 ARM and ARM64 implementations
:::::: TO: Jason A. Donenfeld <Jason@zx2c4.com>
:::::: CC: 0day robot <lkp@intel.com>
---
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: 21645 bytes --]
^ permalink raw reply
* Re: confusing comment, explanation of @IFF_RUNNING in if.h
From: Robert P. J. Day @ 2018-08-27 8:04 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Stephen Hemminger, Andrew Lunn, Linux kernel netdev mailing list
In-Reply-To: <5c3004dc-e877-c142-60ac-91f4623e5153@hartkopp.net>
On Mon, 27 Aug 2018, Oliver Hartkopp wrote:
> "released upon production" means usually: Oh, we put that driver in
> a tar-ball on a CD that's shipped with the product and which will
> get no further visibility nor (security) maintenance.
>
> Robert, please tell your manager that creating a driver is no rocket
> science and also brings no "costumer differentiation" which needs to
> be covered under NDA.
>
> Posting drivers and bring it into mainline Linux heavily increases
> the quality due to the review process and all the people that are
> willing to help you to get better. At the end your driver gets
> long-term maintenance and other people can benefit from it - as your
> boss is getting benefit from using Linux right now.
>
> When something is "released upon production" it will not be in a
> quality that it could go into the kernel - and no one will have the
> time/money/ambition to spend effort on it then. You have just
> produced one of the numerous dead out-of-tree drivers. That would be
> just sad.
i make these arguments on a regular basis with all of my clients
but, as a contractor, i have little influence. but i will continue to
make them.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Jamal Hadi Salim @ 2018-08-27 11:57 UTC (permalink / raw)
To: Al Viro, Kees Cook
Cc: LKML, Cong Wang, Jiri Pirko, David S. Miller, Network Development
In-Reply-To: <20180826225749.GY6515@ZenIV.linux.org.uk>
On 2018-08-26 6:57 p.m., Al Viro wrote:
> On Sun, Aug 26, 2018 at 06:32:37PM +0100, Al Viro wrote:
>
>> As far as I can tell, the solution is
> [snip long and painful reasoning]
>> pointers, and not in provably opaque fashion. Theoretically, the three tcf_...
>> inlines above need another look; fortunately, they don't use ->next at all, not to
>> mention not being used anywhere outside of net/sched/*.c
>>
>> The 80 lines above prove that we only need to grep net/sched/*.c for
>> tcf_proto_ops method calls. And only because we don't have (thank $DEITY)
>> anything that could deconstruct types - as soon as some bastard grows means
>> to say "type of the second argument of the function pointed to by p", this
>> kind of analysis, painful as it is, goes out of window. Even as it is,
>> do you really like the idea of newbies trying to get through the exercises
>> like the one above?
>
> BTW, would there be any problem if we took the definitions of tcf_proto and
> tcf_proto_ops to e.g. net/sched/tcf_proto.h (along with the three inlines in
> in pkt_cls.h), left forwards in sch_generic.h and added includes of "tcf_proto.h"
> where needed in net/sched/*.c?
>
I cant think of any challenges. Cong/Jiri? Would it require development
time classifiers/actions/qdiscs to sit in that directory (I suspect you
dont want them in include/net).
BTW, the idea of improving grep-ability of the code by prefixing the
ops appropriately makes sense. i.e we should have ops->cls_init,
ops->act_init etc.
cheers,
jamal
> That would make tcf_proto/tcf_proto_ops opaque outside of net/sched, reducing
> the exposure of internals. Something like a diff below (against net/master,
> builds clean, ought to result in identical binary):
>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Geert Uytterhoeven @ 2018-08-27 12:40 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
Sergei Shtylyov, David S. Miller, linux-can, netdev,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Simon Horman, Geert Uytterhoeven, Chris Paterson, Biju Das,
Linux-Renesas, Linux Kernel Mailing List
In-Reply-To: <1535029653-7418-4-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Thu, Aug 23, 2018 at 3:08 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:>
> Document RZ/G2M (r8a774a1) SoC specific bindings and RZ/G2
> generic bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings
> Required properties:
> - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC.
Looks good to me.
> "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> @@ -17,6 +18,7 @@ Required properties:
> "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> + "renesas,rzg-gen2-can" for a generic RZ/G2 compatible device.
AFAIK, the actual CAN module in RZ/G2M is fully compatible with the CAN
module in R-Car Gen3 SoCs. The lack of clkp2 is merely an integration
difference: as RZ/G2 SoCs do not have the CANFD module, and their CPG block
doesn't provide the CANFD clock (so the CAN device node in DT cannot refer
to that clock anyway).
Hence I don't think there's a need to introduce a "renesas,rzg-gen2-can"
compatible value.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> followed by the generic version.
> @@ -24,7 +26,9 @@ Required properties:
> - reg: physical base address and size of the R-Car CAN register map.
> - interrupts: interrupt specifier for the sole interrupt.
> - clocks: phandles and clock specifiers for 3 CAN clock inputs.
You still have "3" here. Perhaps
"Must contain a phandle and clock-specifier pair for each entry in
clock-names."?
> -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk".
> +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk".
> + 3 clock input name strings for every other SoC: "clkp1", "clkp2",
> + "can_clk".
OK.
> @@ -41,8 +45,9 @@ using the below properties:
> Optional properties:
> - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
> <0x0> (default) : Peripheral clock (clkp1)
> - <0x1> : Peripheral clock (clkp2)
> - <0x3> : Externally input clock
> + <0x1> : Peripheral clock (clkp2) (not supported by
> + RZ/G2 devices)
> + <0x3> : External input clock
I already expressed my feelings about this property in my reply to the first
patch ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* any reason for "!!netif_carrier_ok" and "!!netif_dormant" in net-sysfs.c?
From: Robert P. J. Day @ 2018-08-27 8:55 UTC (permalink / raw)
To: Linux kernel netdev mailing list
another pedantic oddity -- is there a reason for these two double
negations in net/core/net-sysfs.c?
static ssize_t carrier_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev));
...
static ssize_t dormant_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
return sprintf(buf, fmt_dec, !!netif_dormant(netdev));
i understand the normal rationale for !! in assuring a final boolean
value of precisely either 0 or 1 (here for the sake of printing), but
given that those two routines are declared with a return value of
"bool" in netdevice.h, i don't see any way that they can return
anything *other* than 0 or 1. i realize it can't possibly hurt, but
whenever i see this construct, i normally assume there's a *reason*
for it, but i can't see what it's doing in those two places.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH v2 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-08-27 12:52 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, Jason A. Donenfeld,
Greg KH
In-Reply-To: <20180824213849.23647-18-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 42510 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc1 next-20180827]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180827-073051
config: um-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um
All error/warnings (new ones prefixed by >>):
In file included from lib/zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/chacha20/chacha20-x86_64-glue.h:27:13: warning: 'chacha20_use_avx512vl' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512vl __ro_after_init;
^~~~~~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:26:13: warning: 'chacha20_use_avx512' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:25:13: warning: 'chacha20_use_avx2' defined but not used [-Wunused-variable]
static bool chacha20_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:24:13: warning: 'chacha20_use_ssse3' defined but not used [-Wunused-variable]
static bool chacha20_use_ssse3 __ro_after_init;
^~~~~~~~~~~~~~~~~~
--
In file included from lib/zinc/poly1305/poly1305-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/poly1305/poly1305-x86_64-glue.h:28:13: warning: 'poly1305_use_avx512' defined but not used [-Wunused-variable]
static bool poly1305_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib/zinc/poly1305/poly1305-x86_64-glue.h:27:13: warning: 'poly1305_use_avx2' defined but not used [-Wunused-variable]
static bool poly1305_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib/zinc/poly1305/poly1305-x86_64-glue.h:26:13: warning: 'poly1305_use_avx' defined but not used [-Wunused-variable]
static bool poly1305_use_avx __ro_after_init;
^~~~~~~~~~~~~~~~
--
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:49:41: error: 'NBUGINTS' undeclared here (not in a function)
extern const char * const x86_bug_flags[NBUGINTS*32];
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:196:24: error: 'X86_FEATURE_ALWAYS' undeclared (first use in this function)
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
arch/x86/include/asm/cpufeature.h:196:24: note: each undeclared identifier is reported only once for each function it appears in
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h: In function 'inv_eltfp25519_1w_adx':
>> lib/zinc/curve25519/curve25519-x86_64.h:1543:2: error: implicit declaration of function 'memzero_explicit' [-Werror=implicit-function-declaration]
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h: In function 'curve25519_adx':
>> lib/zinc/curve25519/curve25519-x86_64.h:1706:2: error: implicit declaration of function 'memcpy'; did you mean 'pte_copy'? [-Werror=implicit-function-declaration]
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
pte_copy
In file included from <command-line>:0:0:
lib/zinc/curve25519/curve25519-x86_64-glue.h: At top level:
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:12:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_bmi2 __ro_after_init;
^~~~~~~~~~~~~~~
lib/zinc/curve25519/curve25519-x86_64-glue.h:13:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_adx __ro_after_init;
^~~~~~~~~~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:15:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'curve25519_fpu_init'
void __init curve25519_fpu_init(void)
^~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
lib/zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_arch':
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:23:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:26:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
lib/zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_base_arch':
lib/zinc/curve25519/curve25519-x86_64-glue.h:35:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib/zinc/curve25519/curve25519-x86_64-glue.h:38:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
In file included from arch/x86/include/asm/string.h:5:0,
from include/linux/string.h:20,
from lib/zinc/curve25519/curve25519.c:9:
arch/x86/include/asm/string_64.h: At top level:
>> arch/x86/include/asm/string_64.h:32:14: error: conflicting types for 'memcpy'
extern void *memcpy(void *to, const void *from, size_t len);
^~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h:1706:2: note: previous implicit declaration of 'memcpy' was here
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
In file included from lib/zinc/curve25519/curve25519.c:9:0:
>> include/linux/string.h:216:6: warning: conflicting types for 'memzero_explicit'
void memzero_explicit(void *s, size_t count);
^~~~~~~~~~~~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h:1543:2: note: previous implicit declaration of 'memzero_explicit' was here
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from lib/zinc/blake2s/blake2s-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/blake2s/blake2s-x86_64-glue.h:20:13: warning: 'blake2s_use_avx512' defined but not used [-Wunused-variable]
static bool blake2s_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~
lib/zinc/blake2s/blake2s-x86_64-glue.h:19:13: warning: 'blake2s_use_avx' defined but not used [-Wunused-variable]
static bool blake2s_use_avx __ro_after_init;
^~~~~~~~~~~~~~~
--
In file included from lib//zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib//zinc/chacha20/chacha20-x86_64-glue.h:27:13: warning: 'chacha20_use_avx512vl' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512vl __ro_after_init;
^~~~~~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:26:13: warning: 'chacha20_use_avx512' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:25:13: warning: 'chacha20_use_avx2' defined but not used [-Wunused-variable]
static bool chacha20_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:24:13: warning: 'chacha20_use_ssse3' defined but not used [-Wunused-variable]
static bool chacha20_use_ssse3 __ro_after_init;
^~~~~~~~~~~~~~~~~~
--
In file included from lib//zinc/poly1305/poly1305-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib//zinc/poly1305/poly1305-x86_64-glue.h:28:13: warning: 'poly1305_use_avx512' defined but not used [-Wunused-variable]
static bool poly1305_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib//zinc/poly1305/poly1305-x86_64-glue.h:27:13: warning: 'poly1305_use_avx2' defined but not used [-Wunused-variable]
static bool poly1305_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib//zinc/poly1305/poly1305-x86_64-glue.h:26:13: warning: 'poly1305_use_avx' defined but not used [-Wunused-variable]
static bool poly1305_use_avx __ro_after_init;
^~~~~~~~~~~~~~~~
--
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:49:41: error: 'NBUGINTS' undeclared here (not in a function)
extern const char * const x86_bug_flags[NBUGINTS*32];
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:196:24: error: 'X86_FEATURE_ALWAYS' undeclared (first use in this function)
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
arch/x86/include/asm/cpufeature.h:196:24: note: each undeclared identifier is reported only once for each function it appears in
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h: In function 'inv_eltfp25519_1w_adx':
lib//zinc/curve25519/curve25519-x86_64.h:1543:2: error: implicit declaration of function 'memzero_explicit' [-Werror=implicit-function-declaration]
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h: In function 'curve25519_adx':
lib//zinc/curve25519/curve25519-x86_64.h:1706:2: error: implicit declaration of function 'memcpy'; did you mean 'pte_copy'? [-Werror=implicit-function-declaration]
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
pte_copy
In file included from <command-line>:0:0:
lib//zinc/curve25519/curve25519-x86_64-glue.h: At top level:
lib//zinc/curve25519/curve25519-x86_64-glue.h:12:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_bmi2 __ro_after_init;
^~~~~~~~~~~~~~~
lib//zinc/curve25519/curve25519-x86_64-glue.h:13:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_adx __ro_after_init;
^~~~~~~~~~~~~~~
lib//zinc/curve25519/curve25519-x86_64-glue.h:15:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'curve25519_fpu_init'
void __init curve25519_fpu_init(void)
^~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
lib//zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_arch':
lib//zinc/curve25519/curve25519-x86_64-glue.h:23:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h:26:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_base_arch':
lib//zinc/curve25519/curve25519-x86_64-glue.h:35:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h:38:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
In file included from arch/x86/include/asm/string.h:5:0,
from include/linux/string.h:20,
from lib//zinc/curve25519/curve25519.c:9:
arch/x86/include/asm/string_64.h: At top level:
>> arch/x86/include/asm/string_64.h:32:14: error: conflicting types for 'memcpy'
extern void *memcpy(void *to, const void *from, size_t len);
^~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h:1706:2: note: previous implicit declaration of 'memcpy' was here
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
In file included from lib//zinc/curve25519/curve25519.c:9:0:
>> include/linux/string.h:216:6: warning: conflicting types for 'memzero_explicit'
void memzero_explicit(void *s, size_t count);
^~~~~~~~~~~~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h:1543:2: note: previous implicit declaration of 'memzero_explicit' was here
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
..
vim +/memzero_explicit +1543 lib/zinc/curve25519/curve25519-x86_64.h
468c57c7 Jason A. Donenfeld 2018-08-24 1498
468c57c7 Jason A. Donenfeld 2018-08-24 1499 static void inv_eltfp25519_1w_adx(u64 *const c, const u64 *const a)
468c57c7 Jason A. Donenfeld 2018-08-24 1500 {
468c57c7 Jason A. Donenfeld 2018-08-24 1501 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1502 eltfp25519_1w_buffer buffer;
468c57c7 Jason A. Donenfeld 2018-08-24 1503 eltfp25519_1w x0, x1, x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1504 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1505 u64 *T[4];
468c57c7 Jason A. Donenfeld 2018-08-24 1506
468c57c7 Jason A. Donenfeld 2018-08-24 1507 T[0] = m.x0;
468c57c7 Jason A. Donenfeld 2018-08-24 1508 T[1] = c; /* x^(-1) */
468c57c7 Jason A. Donenfeld 2018-08-24 1509 T[2] = m.x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1510 T[3] = m.x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1511
468c57c7 Jason A. Donenfeld 2018-08-24 1512 copy_eltfp25519_1w(T[1], a);
468c57c7 Jason A. Donenfeld 2018-08-24 1513 sqrn_eltfp25519_1w_adx(T[1], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1514 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1515 sqrn_eltfp25519_1w_adx(T[2], 2);
468c57c7 Jason A. Donenfeld 2018-08-24 1516 mul_eltfp25519_1w_adx(T[0], a, T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1517 mul_eltfp25519_1w_adx(T[1], T[1], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1518 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1519 sqrn_eltfp25519_1w_adx(T[2], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1520 mul_eltfp25519_1w_adx(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1521 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1522 sqrn_eltfp25519_1w_adx(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1523 mul_eltfp25519_1w_adx(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1524 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1525 sqrn_eltfp25519_1w_adx(T[2], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1526 mul_eltfp25519_1w_adx(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1527 copy_eltfp25519_1w(T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1528 sqrn_eltfp25519_1w_adx(T[3], 20);
468c57c7 Jason A. Donenfeld 2018-08-24 1529 mul_eltfp25519_1w_adx(T[3], T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1530 sqrn_eltfp25519_1w_adx(T[3], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1531 mul_eltfp25519_1w_adx(T[3], T[3], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1532 copy_eltfp25519_1w(T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1533 sqrn_eltfp25519_1w_adx(T[0], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1534 mul_eltfp25519_1w_adx(T[0], T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1535 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1536 sqrn_eltfp25519_1w_adx(T[2], 100);
468c57c7 Jason A. Donenfeld 2018-08-24 1537 mul_eltfp25519_1w_adx(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1538 sqrn_eltfp25519_1w_adx(T[2], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1539 mul_eltfp25519_1w_adx(T[2], T[2], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1540 sqrn_eltfp25519_1w_adx(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1541 mul_eltfp25519_1w_adx(T[1], T[1], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1542
468c57c7 Jason A. Donenfeld 2018-08-24 @1543 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1544 }
468c57c7 Jason A. Donenfeld 2018-08-24 1545
468c57c7 Jason A. Donenfeld 2018-08-24 1546 static void inv_eltfp25519_1w_bmi2(u64 *const c, const u64 *const a)
468c57c7 Jason A. Donenfeld 2018-08-24 1547 {
468c57c7 Jason A. Donenfeld 2018-08-24 1548 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1549 eltfp25519_1w_buffer buffer;
468c57c7 Jason A. Donenfeld 2018-08-24 1550 eltfp25519_1w x0, x1, x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1551 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1552 u64 *T[5];
468c57c7 Jason A. Donenfeld 2018-08-24 1553
468c57c7 Jason A. Donenfeld 2018-08-24 1554 T[0] = m.x0;
468c57c7 Jason A. Donenfeld 2018-08-24 1555 T[1] = c; /* x^(-1) */
468c57c7 Jason A. Donenfeld 2018-08-24 1556 T[2] = m.x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1557 T[3] = m.x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1558
468c57c7 Jason A. Donenfeld 2018-08-24 1559 copy_eltfp25519_1w(T[1], a);
468c57c7 Jason A. Donenfeld 2018-08-24 1560 sqrn_eltfp25519_1w_bmi2(T[1], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1561 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1562 sqrn_eltfp25519_1w_bmi2(T[2], 2);
468c57c7 Jason A. Donenfeld 2018-08-24 1563 mul_eltfp25519_1w_bmi2(T[0], a, T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1564 mul_eltfp25519_1w_bmi2(T[1], T[1], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1565 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1566 sqrn_eltfp25519_1w_bmi2(T[2], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1567 mul_eltfp25519_1w_bmi2(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1568 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1569 sqrn_eltfp25519_1w_bmi2(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1570 mul_eltfp25519_1w_bmi2(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1571 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1572 sqrn_eltfp25519_1w_bmi2(T[2], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1573 mul_eltfp25519_1w_bmi2(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1574 copy_eltfp25519_1w(T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1575 sqrn_eltfp25519_1w_bmi2(T[3], 20);
468c57c7 Jason A. Donenfeld 2018-08-24 1576 mul_eltfp25519_1w_bmi2(T[3], T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1577 sqrn_eltfp25519_1w_bmi2(T[3], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1578 mul_eltfp25519_1w_bmi2(T[3], T[3], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1579 copy_eltfp25519_1w(T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1580 sqrn_eltfp25519_1w_bmi2(T[0], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1581 mul_eltfp25519_1w_bmi2(T[0], T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1582 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1583 sqrn_eltfp25519_1w_bmi2(T[2], 100);
468c57c7 Jason A. Donenfeld 2018-08-24 1584 mul_eltfp25519_1w_bmi2(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1585 sqrn_eltfp25519_1w_bmi2(T[2], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1586 mul_eltfp25519_1w_bmi2(T[2], T[2], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1587 sqrn_eltfp25519_1w_bmi2(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1588 mul_eltfp25519_1w_bmi2(T[1], T[1], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1589
468c57c7 Jason A. Donenfeld 2018-08-24 1590 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1591 }
468c57c7 Jason A. Donenfeld 2018-08-24 1592
468c57c7 Jason A. Donenfeld 2018-08-24 1593 /* Given c, a 256-bit number, fred_eltfp25519_1w updates c
468c57c7 Jason A. Donenfeld 2018-08-24 1594 * with a number such that 0 <= C < 2**255-19.
468c57c7 Jason A. Donenfeld 2018-08-24 1595 */
468c57c7 Jason A. Donenfeld 2018-08-24 1596 static __always_inline void fred_eltfp25519_1w(u64 *const c)
468c57c7 Jason A. Donenfeld 2018-08-24 1597 {
468c57c7 Jason A. Donenfeld 2018-08-24 1598 u64 tmp0 = 38, tmp1 = 19;
468c57c7 Jason A. Donenfeld 2018-08-24 1599 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1600 "btrq $63, %3 ;" /* Put bit 255 in carry flag and clear */
468c57c7 Jason A. Donenfeld 2018-08-24 1601 "cmovncl %k5, %k4 ;" /* c[255] ? 38 : 19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1602
468c57c7 Jason A. Donenfeld 2018-08-24 1603 /* Add either 19 or 38 to c */
468c57c7 Jason A. Donenfeld 2018-08-24 1604 "addq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1605 "adcq $0, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1606 "adcq $0, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1607 "adcq $0, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1608
468c57c7 Jason A. Donenfeld 2018-08-24 1609 /* Test for bit 255 again; only triggered on overflow modulo 2^255-19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1610 "movl $0, %k4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1611 "cmovnsl %k5, %k4 ;" /* c[255] ? 0 : 19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1612 "btrq $63, %3 ;" /* Clear bit 255 */
468c57c7 Jason A. Donenfeld 2018-08-24 1613
468c57c7 Jason A. Donenfeld 2018-08-24 1614 /* Subtract 19 if necessary */
468c57c7 Jason A. Donenfeld 2018-08-24 1615 "subq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1616 "sbbq $0, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1617 "sbbq $0, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1618 "sbbq $0, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1619
468c57c7 Jason A. Donenfeld 2018-08-24 1620 : "+r"(c[0]), "+r"(c[1]), "+r"(c[2]), "+r"(c[3]), "+r"(tmp0), "+r"(tmp1)
468c57c7 Jason A. Donenfeld 2018-08-24 1621 :
468c57c7 Jason A. Donenfeld 2018-08-24 1622 : "memory", "cc");
468c57c7 Jason A. Donenfeld 2018-08-24 1623 }
468c57c7 Jason A. Donenfeld 2018-08-24 1624
468c57c7 Jason A. Donenfeld 2018-08-24 1625 static __always_inline void cswap(u8 bit, u64 *const px, u64 *const py)
468c57c7 Jason A. Donenfeld 2018-08-24 1626 {
468c57c7 Jason A. Donenfeld 2018-08-24 1627 u64 temp;
468c57c7 Jason A. Donenfeld 2018-08-24 1628 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1629 "test %9, %9 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1630 "movq %0, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1631 "cmovnzq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1632 "cmovnzq %8, %4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1633 "movq %1, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1634 "cmovnzq %5, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1635 "cmovnzq %8, %5 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1636 "movq %2, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1637 "cmovnzq %6, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1638 "cmovnzq %8, %6 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1639 "movq %3, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1640 "cmovnzq %7, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1641 "cmovnzq %8, %7 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1642 : "+r"(px[0]), "+r"(px[1]), "+r"(px[2]), "+r"(px[3]),
468c57c7 Jason A. Donenfeld 2018-08-24 1643 "+r"(py[0]), "+r"(py[1]), "+r"(py[2]), "+r"(py[3]),
468c57c7 Jason A. Donenfeld 2018-08-24 1644 "=r"(temp)
468c57c7 Jason A. Donenfeld 2018-08-24 1645 : "r"(bit)
468c57c7 Jason A. Donenfeld 2018-08-24 1646 : "cc"
468c57c7 Jason A. Donenfeld 2018-08-24 1647 );
468c57c7 Jason A. Donenfeld 2018-08-24 1648 }
468c57c7 Jason A. Donenfeld 2018-08-24 1649
468c57c7 Jason A. Donenfeld 2018-08-24 1650 static __always_inline void cselect(u8 bit, u64 *const px, const u64 *const py)
468c57c7 Jason A. Donenfeld 2018-08-24 1651 {
468c57c7 Jason A. Donenfeld 2018-08-24 1652 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1653 "test %4, %4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1654 "cmovnzq %5, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1655 "cmovnzq %6, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1656 "cmovnzq %7, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1657 "cmovnzq %8, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1658 : "+r"(px[0]), "+r"(px[1]), "+r"(px[2]), "+r"(px[3])
468c57c7 Jason A. Donenfeld 2018-08-24 1659 : "r"(bit), "rm"(py[0]), "rm"(py[1]), "rm"(py[2]), "rm"(py[3])
468c57c7 Jason A. Donenfeld 2018-08-24 1660 : "cc"
468c57c7 Jason A. Donenfeld 2018-08-24 1661 );
468c57c7 Jason A. Donenfeld 2018-08-24 1662 }
468c57c7 Jason A. Donenfeld 2018-08-24 1663
468c57c7 Jason A. Donenfeld 2018-08-24 1664 static __always_inline void clamp_secret(u8 secret[CURVE25519_POINT_SIZE])
468c57c7 Jason A. Donenfeld 2018-08-24 1665 {
468c57c7 Jason A. Donenfeld 2018-08-24 1666 secret[0] &= 248;
468c57c7 Jason A. Donenfeld 2018-08-24 1667 secret[31] &= 127;
468c57c7 Jason A. Donenfeld 2018-08-24 1668 secret[31] |= 64;
468c57c7 Jason A. Donenfeld 2018-08-24 1669 }
468c57c7 Jason A. Donenfeld 2018-08-24 1670
468c57c7 Jason A. Donenfeld 2018-08-24 1671 static void curve25519_adx(u8 shared[CURVE25519_POINT_SIZE], const u8 private_key[CURVE25519_POINT_SIZE], const u8 session_key[CURVE25519_POINT_SIZE])
468c57c7 Jason A. Donenfeld 2018-08-24 1672 {
468c57c7 Jason A. Donenfeld 2018-08-24 1673 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1674 u64 buffer[4 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1675 u64 coordinates[4 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1676 u64 workspace[6 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1677 u8 session[CURVE25519_POINT_SIZE];
468c57c7 Jason A. Donenfeld 2018-08-24 1678 u8 private[CURVE25519_POINT_SIZE];
468c57c7 Jason A. Donenfeld 2018-08-24 1679 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1680
468c57c7 Jason A. Donenfeld 2018-08-24 1681 int i = 0, j = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1682 u64 prev = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1683 u64 *const X1 = (u64 *)m.session;
468c57c7 Jason A. Donenfeld 2018-08-24 1684 u64 *const key = (u64 *)m.private;
468c57c7 Jason A. Donenfeld 2018-08-24 1685 u64 *const Px = m.coordinates + 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1686 u64 *const Pz = m.coordinates + 4;
468c57c7 Jason A. Donenfeld 2018-08-24 1687 u64 *const Qx = m.coordinates + 8;
468c57c7 Jason A. Donenfeld 2018-08-24 1688 u64 *const Qz = m.coordinates + 12;
468c57c7 Jason A. Donenfeld 2018-08-24 1689 u64 *const X2 = Qx;
468c57c7 Jason A. Donenfeld 2018-08-24 1690 u64 *const Z2 = Qz;
468c57c7 Jason A. Donenfeld 2018-08-24 1691 u64 *const X3 = Px;
468c57c7 Jason A. Donenfeld 2018-08-24 1692 u64 *const Z3 = Pz;
468c57c7 Jason A. Donenfeld 2018-08-24 1693 u64 *const X2Z2 = Qx;
468c57c7 Jason A. Donenfeld 2018-08-24 1694 u64 *const X3Z3 = Px;
468c57c7 Jason A. Donenfeld 2018-08-24 1695
468c57c7 Jason A. Donenfeld 2018-08-24 1696 u64 *const A = m.workspace + 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1697 u64 *const B = m.workspace + 4;
468c57c7 Jason A. Donenfeld 2018-08-24 1698 u64 *const D = m.workspace + 8;
468c57c7 Jason A. Donenfeld 2018-08-24 1699 u64 *const C = m.workspace + 12;
468c57c7 Jason A. Donenfeld 2018-08-24 1700 u64 *const DA = m.workspace + 16;
468c57c7 Jason A. Donenfeld 2018-08-24 1701 u64 *const CB = m.workspace + 20;
468c57c7 Jason A. Donenfeld 2018-08-24 1702 u64 *const AB = A;
468c57c7 Jason A. Donenfeld 2018-08-24 1703 u64 *const DC = D;
468c57c7 Jason A. Donenfeld 2018-08-24 1704 u64 *const DACB = DA;
468c57c7 Jason A. Donenfeld 2018-08-24 1705
468c57c7 Jason A. Donenfeld 2018-08-24 @1706 memcpy(m.private, private_key, sizeof(m.private));
468c57c7 Jason A. Donenfeld 2018-08-24 1707 memcpy(m.session, session_key, sizeof(m.session));
468c57c7 Jason A. Donenfeld 2018-08-24 1708
468c57c7 Jason A. Donenfeld 2018-08-24 1709 clamp_secret(m.private);
468c57c7 Jason A. Donenfeld 2018-08-24 1710
468c57c7 Jason A. Donenfeld 2018-08-24 1711 /* As in the draft:
468c57c7 Jason A. Donenfeld 2018-08-24 1712 * When receiving such an array, implementations of curve25519
468c57c7 Jason A. Donenfeld 2018-08-24 1713 * MUST mask the most-significant bit in the final byte. This
468c57c7 Jason A. Donenfeld 2018-08-24 1714 * is done to preserve compatibility with point formats which
468c57c7 Jason A. Donenfeld 2018-08-24 1715 * reserve the sign bit for use in other protocols and to
468c57c7 Jason A. Donenfeld 2018-08-24 1716 * increase resistance to implementation fingerprinting
468c57c7 Jason A. Donenfeld 2018-08-24 1717 */
468c57c7 Jason A. Donenfeld 2018-08-24 1718 m.session[CURVE25519_POINT_SIZE - 1] &= (1 << (255 % 8)) - 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1719
468c57c7 Jason A. Donenfeld 2018-08-24 1720 copy_eltfp25519_1w(Px, X1);
468c57c7 Jason A. Donenfeld 2018-08-24 1721 setzero_eltfp25519_1w(Pz);
468c57c7 Jason A. Donenfeld 2018-08-24 1722 setzero_eltfp25519_1w(Qx);
468c57c7 Jason A. Donenfeld 2018-08-24 1723 setzero_eltfp25519_1w(Qz);
468c57c7 Jason A. Donenfeld 2018-08-24 1724
468c57c7 Jason A. Donenfeld 2018-08-24 1725 Pz[0] = 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1726 Qx[0] = 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1727
468c57c7 Jason A. Donenfeld 2018-08-24 1728 /* main-loop */
468c57c7 Jason A. Donenfeld 2018-08-24 1729 prev = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1730 j = 62;
468c57c7 Jason A. Donenfeld 2018-08-24 1731 for (i = 3; i >= 0; --i) {
468c57c7 Jason A. Donenfeld 2018-08-24 1732 while (j >= 0) {
468c57c7 Jason A. Donenfeld 2018-08-24 1733 u64 bit = (key[i] >> j) & 0x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1734 u64 swap = bit ^ prev;
468c57c7 Jason A. Donenfeld 2018-08-24 1735 prev = bit;
468c57c7 Jason A. Donenfeld 2018-08-24 1736
468c57c7 Jason A. Donenfeld 2018-08-24 1737 add_eltfp25519_1w_adx(A, X2, Z2); /* A = (X2+Z2) */
468c57c7 Jason A. Donenfeld 2018-08-24 1738 sub_eltfp25519_1w(B, X2, Z2); /* B = (X2-Z2) */
468c57c7 Jason A. Donenfeld 2018-08-24 1739 add_eltfp25519_1w_adx(C, X3, Z3); /* C = (X3+Z3) */
468c57c7 Jason A. Donenfeld 2018-08-24 1740 sub_eltfp25519_1w(D, X3, Z3); /* D = (X3-Z3) */
468c57c7 Jason A. Donenfeld 2018-08-24 1741 mul_eltfp25519_2w_adx(DACB, AB, DC); /* [DA|CB] = [A|B]*[D|C] */
468c57c7 Jason A. Donenfeld 2018-08-24 1742
468c57c7 Jason A. Donenfeld 2018-08-24 1743 cselect(swap, A, C);
468c57c7 Jason A. Donenfeld 2018-08-24 1744 cselect(swap, B, D);
468c57c7 Jason A. Donenfeld 2018-08-24 1745
468c57c7 Jason A. Donenfeld 2018-08-24 1746 sqr_eltfp25519_2w_adx(AB); /* [AA|BB] = [A^2|B^2] */
468c57c7 Jason A. Donenfeld 2018-08-24 1747 add_eltfp25519_1w_adx(X3, DA, CB); /* X3 = (DA+CB) */
468c57c7 Jason A. Donenfeld 2018-08-24 1748 sub_eltfp25519_1w(Z3, DA, CB); /* Z3 = (DA-CB) */
468c57c7 Jason A. Donenfeld 2018-08-24 1749 sqr_eltfp25519_2w_adx(X3Z3); /* [X3|Z3] = [(DA+CB)|(DA+CB)]^2 */
468c57c7 Jason A. Donenfeld 2018-08-24 1750
468c57c7 Jason A. Donenfeld 2018-08-24 1751 copy_eltfp25519_1w(X2, B); /* X2 = B^2 */
468c57c7 Jason A. Donenfeld 2018-08-24 1752 sub_eltfp25519_1w(Z2, A, B); /* Z2 = E = AA-BB */
468c57c7 Jason A. Donenfeld 2018-08-24 1753
468c57c7 Jason A. Donenfeld 2018-08-24 1754 mul_a24_eltfp25519_1w(B, Z2); /* B = a24*E */
468c57c7 Jason A. Donenfeld 2018-08-24 1755 add_eltfp25519_1w_adx(B, B, X2); /* B = a24*E+B */
468c57c7 Jason A. Donenfeld 2018-08-24 1756 mul_eltfp25519_2w_adx(X2Z2, X2Z2, AB); /* [X2|Z2] = [B|E]*[A|a24*E+B] */
468c57c7 Jason A. Donenfeld 2018-08-24 1757 mul_eltfp25519_1w_adx(Z3, Z3, X1); /* Z3 = Z3*X1 */
468c57c7 Jason A. Donenfeld 2018-08-24 1758 --j;
468c57c7 Jason A. Donenfeld 2018-08-24 1759 }
468c57c7 Jason A. Donenfeld 2018-08-24 1760 j = 63;
468c57c7 Jason A. Donenfeld 2018-08-24 1761 }
468c57c7 Jason A. Donenfeld 2018-08-24 1762
468c57c7 Jason A. Donenfeld 2018-08-24 1763 inv_eltfp25519_1w_adx(A, Qz);
468c57c7 Jason A. Donenfeld 2018-08-24 1764 mul_eltfp25519_1w_adx((u64 *)shared, Qx, A);
468c57c7 Jason A. Donenfeld 2018-08-24 1765 fred_eltfp25519_1w((u64 *)shared);
468c57c7 Jason A. Donenfeld 2018-08-24 1766
468c57c7 Jason A. Donenfeld 2018-08-24 1767 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1768 }
468c57c7 Jason A. Donenfeld 2018-08-24 1769
:::::: The code at line 1543 was first introduced by commit
:::::: 468c57c74ac7091c9c04ab2acccf68fe300cd9bc zinc: Curve25519 x86_64 implementation
:::::: TO: Jason A. Donenfeld <Jason@zx2c4.com>
:::::: CC: 0day robot <lkp@intel.com>
---
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: 20207 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-08-27 12:55 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Chris Paterson, Wolfgang Grandegger, Marc Kleine-Budde,
Rob Herring, Mark Rutland, David S. Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Biju Das,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <TY1PR01MB177055864EEAD487C2917860C0360@TY1PR01MB1770.jpnprd01.prod.outlook.com>
On Fri, Aug 24, 2018 at 08:31:42AM +0000, Fabrizio Castro wrote:
> Hello Simon,
>
> Thank you for the feedback!
>
> > >
> > > In theory CAN could be broken if renesas,can-clock-select is set to 0x1
> > > (clkp2) in the DT, as this value will be written to the CAN Clock Select
> > > Register. However if the documentation is followed there will be no
> > > problems.
> > >
> > > We should probably update the driver to fix this though, which will be a
> > > change specific to all RZ/G2 devices, so perhaps we should also be adding
> > > a "renesas,rzg-gen2-can" family compatible string as well? (to driver and
> > > documentation)
> >
> > Yes, I think that sounds reasonable.
> >
> > But in that case we should pre-emptively not use renesas,rcar-gen3-can for
> > RZ/G2.
>
> What do you think about the following:
> https://patchwork.kernel.org/patch/10573795/
> https://patchwork.kernel.org/patch/10573791/
> https://patchwork.kernel.org/patch/10573805/
I think that is the right approach.
^ permalink raw reply
* Re: [PATCH v2 01/29] nvmem: add support for cell lookups
From: Bartosz Golaszewski @ 2018-08-27 13:37 UTC (permalink / raw)
To: Boris Brezillon
Cc: Andrew Lunn, linux-doc, Sekhar Nori, Bartosz Golaszewski,
Srinivas Kandagatla, linux-i2c, Mauro Carvalho Chehab,
Rob Herring, Florian Fainelli, Kevin Hilman, Richard Weinberger,
Russell King, Marek Vasut, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, "ope
In-Reply-To: <20180827110055.122988d0@bbrezillon>
2018-08-27 11:00 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> On Mon, 27 Aug 2018 10:56:29 +0200
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
>> 2018-08-25 8:27 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
>> > On Fri, 24 Aug 2018 17:27:40 +0200
>> > Andrew Lunn <andrew@lunn.ch> wrote:
>> >
>> >> On Fri, Aug 24, 2018 at 05:08:48PM +0200, Boris Brezillon wrote:
>> >> > Hi Bartosz,
>> >> >
>> >> > On Fri, 10 Aug 2018 10:04:58 +0200
>> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> >> >
>> >> > > +struct nvmem_cell_lookup {
>> >> > > + struct nvmem_cell_info info;
>> >> > > + struct list_head list;
>> >> > > + const char *nvmem_name;
>> >> > > +};
>> >> >
>> >> > Hm, maybe I don't get it right, but this looks suspicious. Usually the
>> >> > consumer lookup table is here to attach device specific names to
>> >> > external resources.
>> >> >
>> >> > So what I'd expect here is:
>> >> >
>> >> > struct nvmem_cell_lookup {
>> >> > /* The nvmem device name. */
>> >> > const char *nvmem_name;
>> >> >
>> >> > /* The nvmem cell name */
>> >> > const char *nvmem_cell_name;
>> >> >
>> >> > /*
>> >> > * The local resource name. Basically what you have in the
>> >> > * nvmem-cell-names prop.
>> >> > */
>> >> > const char *conid;
>> >> > };
>> >> >
>> >> > struct nvmem_cell_lookup_table {
>> >> > struct list_head list;
>> >> >
>> >> > /* ID of the consumer device. */
>> >> > const char *devid;
>> >> >
>> >> > /* Array of cell lookup entries. */
>> >> > unsigned int ncells;
>> >> > const struct nvmem_cell_lookup *cells;
>> >> > };
>> >> >
>> >> > Looks like your nvmem_cell_lookup is more something used to attach cells
>> >> > to an nvmem device, which is NVMEM provider's responsibility not the
>> >> > consumer one.
>> >>
>> >> Hi Boris
>> >>
>> >> There are cases where there is not a clear providier/consumer split. I
>> >> have an x86 platform, with a few at24 EEPROMs on it. It uses an off
>> >> the shelf Komtron module, placed on a custom carrier board. One of the
>> >> EEPROMs contains the hardware variant information. Once i know the
>> >> variant, i need to instantiate other I2C, SPI, MDIO devices, all using
>> >> platform devices, since this is x86, no DT available.
>> >>
>> >> So the first thing my x86 platform device does is instantiate the
>> >> first i2c device for the AT24. Once the EEPROM pops into existence, i
>> >> need to add nvmem cells onto it. So at that point, the x86 platform
>> >> driver is playing the provider role. Once the cells are added, i can
>> >> then use nvmem consumer interfaces to get the contents of the cell,
>> >> run a checksum, and instantiate the other devices.
>> >>
>> >> I wish the embedded world was all DT, but the reality is that it is
>> >> not :-(
>> >
>> > Actually, I'm not questioning the need for this feature (being able to
>> > attach NVMEM cells to an NVMEM device on a platform that does not use
>> > DT). What I'm saying is that this functionality is provider related,
>> > not consumer related. Also, I wonder if defining such NVMEM cells
>> > shouldn't go through the provider driver instead of being passed
>> > directly to the NVMEM layer, because nvmem_config already have a fields
>> > to pass cells at registration time, plus, the name of the NVMEM cell
>> > device is sometimes created dynamically and can be hard to guess at
>> > platform_device registration time.
>> >
>>
>> In my use case the provider is at24 EEPROM driver. This is where the
>> nvmem_config lives but I can't image a correct and clean way of
>> passing this cell config to the driver from board files without using
>> new ugly fields in platform_data which this very series is trying to
>> remove. This is why this cell config should live in machine code.
>
> Okay.
>
>>
>> > I also think non-DT consumers will need a way to reference exiting
>> > NVMEM cells, but this consumer-oriented nvmem cell lookup table should
>> > look like the gpio or pwm lookup table (basically what I proposed in my
>> > previous email).
>>
>> How about introducing two new interfaces to nvmem: one for defining
>> nvmem cells from machine code and the second for connecting these
>> cells with devices?
>
> Yes, that's basically what I was suggesting: move what you've done in
> nvmem-provider.h (maybe rename some of the structs to make it clear
> that this is about defining cells not referencing existing ones), and
> add a new consumer interface (based on what other subsystems do) in
> nvmem-consumer.h.
>
> This way you have both things clearly separated, and if a driver is
> both a consumer and a provider you'll just have to include both headers.
>
> Regards,
>
> Boris
I didn't notice it before but there's a global list of nvmem cells
with each cell referencing its owner nvmem device. I'm wondering if
this isn't some kind of inversion of ownership. Shouldn't each nvmem
device have a separate list of nvmem cells owned by it? What happens
if we have two nvmem providers with the same names for cells? I'm
asking because dev_id based lookup doesn't make sense if internally
nvmem_cell_get_from_list() doesn't care about any device names (takes
only the cell_id as argument).
This doesn't cause any trouble now since there are no users defining
cells in nvmem_config - there are only DT users - but this must be
clarified before I can advance with correctly implementing nvmem
lookups.
BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
instance even if the cell for this node was already added to the nvmem
device.
Bart
^ permalink raw reply
* Re: [PATCH] net: mvpp2: avoid bouncing buffers
From: Brian Brooks @ 2018-08-27 13:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Miller, antoine.tenart, maxime.chevallier, ymarkman,
stefanc, netdev, linux-kernel, bjorn.topel, brian.brooks
In-Reply-To: <20180820062326.GA22222@infradead.org>
On 08/19 23:23:26, Christoph Hellwig wrote:
> On Sun, Aug 19, 2018 at 07:55:05PM -0700, David Miller wrote:
> > From: Brian Brooks <brian.brooks@linaro.org>
> > Date: Sun, 19 Aug 2018 21:47:30 -0500
> >
> > > @@ -5126,6 +5126,12 @@ static int mvpp2_probe(struct platform_device *pdev)
> > > }
> > >
> > > if (priv->hw_version == MVPP22) {
> > > + /* Platform code may have set dev->dma_mask to point
> > > + * to dev->coherent_dma_mask, but we want to ensure
> > > + * they take different values due to comment below.
> > > + */
> > > + pdev->dev.dma_mask = &priv->dma_mask;
> >
> > The platform code might be doing this exactly because it cannot support
> > different coherent and streaming DMA masks.
> >
> > Well, in any case, the platform code is doing it for a reason and
> > overriding this in a "driver" of all places seems totally
> > inappropriate and at best a layering violation.
> >
> > I would rather you fix this in a way that involves well defined APIs
> > that set the DMA masks or whatever to the values that you need, rather
> > than going behind the platform code's back and changing the DMA mask
> > pointer like this.
>
> Agreed. What platform do you see this issue on?
This is Armada 8040 SoC with PPv2 net device on chip. MACCHIATObin board.
Both DT and ACPI have the following snippet:
/*
* Set default coherent_dma_mask to 32 bit. Drivers are expected to
* setup the correct supported mask.
*/
if (!dev->coherent_dma_mask)
dev->coherent_dma_mask = DMA_BIT_MASK(32);
/*
* Set it to coherent_dma_mask by default if the architecture
* code has not set it.
*/
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
Some architectures code setup DMA masks, but it does not seem appropriate
to add mvpp2 specific code in arch/arm64. The mvpp2 driver appeared to be
the least invasive place to resolve the limitation of this net device.
Another DMA API could be added to allocate storage for the streaming
mask to ensure masks can take on separate values when the existing DMA
APIs are used by the driver to set those values. But, this would be the
only driver using such API. Would that be how to handle this?
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: Michael S. Tsirkin @ 2018-08-27 14:00 UTC (permalink / raw)
To: Tiwei Bie
Cc: jasowang, virtualization, linux-kernel, netdev, virtio-dev, wexu,
jfreimann
In-Reply-To: <20180711022711.7090-1-tiwei.bie@intel.com>
Are there still plans to test the performance with vost pmd?
vhost doesn't seem to show a performance gain ...
On Wed, Jul 11, 2018 at 10:27:06AM +0800, Tiwei Bie wrote:
> Hello everyone,
>
> This patch set implements packed ring support in virtio driver.
>
> Some functional tests have been done with Jason's
> packed ring implementation in vhost:
>
> https://lkml.org/lkml/2018/7/3/33
>
> Both of ping and netperf worked as expected.
>
> v1 -> v2:
> - Use READ_ONCE() to read event off_wrap and flags together (Jason);
> - Add comments related to ccw (Jason);
>
> RFC (v6) -> v1:
> - Avoid extra virtio_wmb() in virtqueue_enable_cb_delayed_packed()
> when event idx is off (Jason);
> - Fix bufs calculation in virtqueue_enable_cb_delayed_packed() (Jason);
> - Test the state of the desc at used_idx instead of last_used_idx
> in virtqueue_enable_cb_delayed_packed() (Jason);
> - Save wrap counter (as part of queue state) in the return value
> of virtqueue_enable_cb_prepare_packed();
> - Refine the packed ring definitions in uapi;
> - Rebase on the net-next tree;
>
> RFC v5 -> RFC v6:
> - Avoid tracking addr/len/flags when DMA API isn't used (MST/Jason);
> - Define wrap counter as bool (Jason);
> - Use ALIGN() in vring_init_packed() (Jason);
> - Avoid using pointer to track `next` in detach_buf_packed() (Jason);
> - Add comments for barriers (Jason);
> - Don't enable RING_PACKED on ccw for now (noticed by Jason);
> - Refine the memory barrier in virtqueue_poll();
> - Add a missing memory barrier in virtqueue_enable_cb_delayed_packed();
> - Remove the hacks in virtqueue_enable_cb_prepare_packed();
>
> RFC v4 -> RFC v5:
> - Save DMA addr, etc in desc state (Jason);
> - Track used wrap counter;
>
> RFC v3 -> RFC v4:
> - Make ID allocation support out-of-order (Jason);
> - Various fixes for EVENT_IDX support;
>
> RFC v2 -> RFC v3:
> - Split into small patches (Jason);
> - Add helper virtqueue_use_indirect() (Jason);
> - Just set id for the last descriptor of a list (Jason);
> - Calculate the prev in virtqueue_add_packed() (Jason);
> - Fix/improve desc suppression code (Jason/MST);
> - Refine the code layout for XXX_split/packed and wrappers (MST);
> - Fix the comments and API in uapi (MST);
> - Remove the BUG_ON() for indirect (Jason);
> - Some other refinements and bug fixes;
>
> RFC v1 -> RFC v2:
> - Add indirect descriptor support - compile test only;
> - Add event suppression supprt - compile test only;
> - Move vring_packed_init() out of uapi (Jason, MST);
> - Merge two loops into one in virtqueue_add_packed() (Jason);
> - Split vring_unmap_one() for packed ring and split ring (Jason);
> - Avoid using '%' operator (Jason);
> - Rename free_head -> next_avail_idx (Jason);
> - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
> - Some other refinements and bug fixes;
>
> Thanks!
>
> Tiwei Bie (5):
> virtio: add packed ring definitions
> virtio_ring: support creating packed ring
> virtio_ring: add packed ring support
> virtio_ring: add event idx support in packed ring
> virtio_ring: enable packed ring
>
> drivers/s390/virtio/virtio_ccw.c | 14 +
> drivers/virtio/virtio_ring.c | 1365 ++++++++++++++++++++++------
> include/linux/virtio_ring.h | 8 +-
> include/uapi/linux/virtio_config.h | 3 +
> include/uapi/linux/virtio_ring.h | 43 +
> 5 files changed, 1157 insertions(+), 276 deletions(-)
>
> --
> 2.18.0
^ permalink raw reply
* Re: [PATCH v2 01/29] nvmem: add support for cell lookups
From: Boris Brezillon @ 2018-08-27 14:01 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andrew Lunn, linux-doc, Sekhar Nori, Bartosz Golaszewski,
Srinivas Kandagatla, linux-i2c, Mauro Carvalho Chehab,
Rob Herring, Florian Fainelli, Kevin Hilman, Richard Weinberger,
Russell King, Marek Vasut, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, "ope
In-Reply-To: <CAMRc=MfpZJUEAhM4OoLbmJcnX3rTJk8fvdiL6=9BjNkVcsf=SA@mail.gmail.com>
On Mon, 27 Aug 2018 15:37:23 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2018-08-27 11:00 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> > On Mon, 27 Aug 2018 10:56:29 +0200
> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> >> 2018-08-25 8:27 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> >> > On Fri, 24 Aug 2018 17:27:40 +0200
> >> > Andrew Lunn <andrew@lunn.ch> wrote:
> >> >
> >> >> On Fri, Aug 24, 2018 at 05:08:48PM +0200, Boris Brezillon wrote:
> >> >> > Hi Bartosz,
> >> >> >
> >> >> > On Fri, 10 Aug 2018 10:04:58 +0200
> >> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >> >> >
> >> >> > > +struct nvmem_cell_lookup {
> >> >> > > + struct nvmem_cell_info info;
> >> >> > > + struct list_head list;
> >> >> > > + const char *nvmem_name;
> >> >> > > +};
> >> >> >
> >> >> > Hm, maybe I don't get it right, but this looks suspicious. Usually the
> >> >> > consumer lookup table is here to attach device specific names to
> >> >> > external resources.
> >> >> >
> >> >> > So what I'd expect here is:
> >> >> >
> >> >> > struct nvmem_cell_lookup {
> >> >> > /* The nvmem device name. */
> >> >> > const char *nvmem_name;
> >> >> >
> >> >> > /* The nvmem cell name */
> >> >> > const char *nvmem_cell_name;
> >> >> >
> >> >> > /*
> >> >> > * The local resource name. Basically what you have in the
> >> >> > * nvmem-cell-names prop.
> >> >> > */
> >> >> > const char *conid;
> >> >> > };
> >> >> >
> >> >> > struct nvmem_cell_lookup_table {
> >> >> > struct list_head list;
> >> >> >
> >> >> > /* ID of the consumer device. */
> >> >> > const char *devid;
> >> >> >
> >> >> > /* Array of cell lookup entries. */
> >> >> > unsigned int ncells;
> >> >> > const struct nvmem_cell_lookup *cells;
> >> >> > };
> >> >> >
> >> >> > Looks like your nvmem_cell_lookup is more something used to attach cells
> >> >> > to an nvmem device, which is NVMEM provider's responsibility not the
> >> >> > consumer one.
> >> >>
> >> >> Hi Boris
> >> >>
> >> >> There are cases where there is not a clear providier/consumer split. I
> >> >> have an x86 platform, with a few at24 EEPROMs on it. It uses an off
> >> >> the shelf Komtron module, placed on a custom carrier board. One of the
> >> >> EEPROMs contains the hardware variant information. Once i know the
> >> >> variant, i need to instantiate other I2C, SPI, MDIO devices, all using
> >> >> platform devices, since this is x86, no DT available.
> >> >>
> >> >> So the first thing my x86 platform device does is instantiate the
> >> >> first i2c device for the AT24. Once the EEPROM pops into existence, i
> >> >> need to add nvmem cells onto it. So at that point, the x86 platform
> >> >> driver is playing the provider role. Once the cells are added, i can
> >> >> then use nvmem consumer interfaces to get the contents of the cell,
> >> >> run a checksum, and instantiate the other devices.
> >> >>
> >> >> I wish the embedded world was all DT, but the reality is that it is
> >> >> not :-(
> >> >
> >> > Actually, I'm not questioning the need for this feature (being able to
> >> > attach NVMEM cells to an NVMEM device on a platform that does not use
> >> > DT). What I'm saying is that this functionality is provider related,
> >> > not consumer related. Also, I wonder if defining such NVMEM cells
> >> > shouldn't go through the provider driver instead of being passed
> >> > directly to the NVMEM layer, because nvmem_config already have a fields
> >> > to pass cells at registration time, plus, the name of the NVMEM cell
> >> > device is sometimes created dynamically and can be hard to guess at
> >> > platform_device registration time.
> >> >
> >>
> >> In my use case the provider is at24 EEPROM driver. This is where the
> >> nvmem_config lives but I can't image a correct and clean way of
> >> passing this cell config to the driver from board files without using
> >> new ugly fields in platform_data which this very series is trying to
> >> remove. This is why this cell config should live in machine code.
> >
> > Okay.
> >
> >>
> >> > I also think non-DT consumers will need a way to reference exiting
> >> > NVMEM cells, but this consumer-oriented nvmem cell lookup table should
> >> > look like the gpio or pwm lookup table (basically what I proposed in my
> >> > previous email).
> >>
> >> How about introducing two new interfaces to nvmem: one for defining
> >> nvmem cells from machine code and the second for connecting these
> >> cells with devices?
> >
> > Yes, that's basically what I was suggesting: move what you've done in
> > nvmem-provider.h (maybe rename some of the structs to make it clear
> > that this is about defining cells not referencing existing ones), and
> > add a new consumer interface (based on what other subsystems do) in
> > nvmem-consumer.h.
> >
> > This way you have both things clearly separated, and if a driver is
> > both a consumer and a provider you'll just have to include both headers.
> >
> > Regards,
> >
> > Boris
>
> I didn't notice it before but there's a global list of nvmem cells
> with each cell referencing its owner nvmem device. I'm wondering if
> this isn't some kind of inversion of ownership. Shouldn't each nvmem
> device have a separate list of nvmem cells owned by it? What happens
> if we have two nvmem providers with the same names for cells? I'm
> asking because dev_id based lookup doesn't make sense if internally
> nvmem_cell_get_from_list() doesn't care about any device names (takes
> only the cell_id as argument).
>
> This doesn't cause any trouble now since there are no users defining
> cells in nvmem_config - there are only DT users - but this must be
> clarified before I can advance with correctly implementing nvmem
> lookups.
>
> BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
> instance even if the cell for this node was already added to the nvmem
> device.
Yep, don't know if it's done on purpose or not, but it's weird. I'd
expect cells to be instantiated at NVMEM registration time (and stored
in a list attached to the device) and then, anytime someone calls
nvmem_cell_get(), you would search in this list for a match.
^ permalink raw reply
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Kees Cook @ 2018-08-27 14:08 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Al Viro, LKML, Cong Wang, Jiri Pirko, David S. Miller,
Network Development
In-Reply-To: <d68f13e6-339a-2a40-9c0d-7549cd9aabb3@mojatatu.com>
On Mon, Aug 27, 2018 at 4:46 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 2018-08-26 5:56 p.m., Kees Cook wrote:
>>
>> On Sun, Aug 26, 2018 at 10:30 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>>
>>> We should add an nla_policy later.
>>
>>
>> What's the right way to do that for cases like this?
>
>
> Meant something like attached which you alluded-to in your comments
> would give an upper bound (Max allowed keys is 128).
The problem is that policy doesn't parse the contents: "nkeys"
determines the size, so we have to both validate minimum size (to be
sure the location of "nkeys" is valid) and check that the size is at
least nkeys * struct long. I don't think there is a way to do this
with the existing policy language.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH net] sctp: hold transport before accessing its asoc in sctp_transport_get_next
From: Xin Long @ 2018-08-27 10:38 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
As Marcelo noticed, in sctp_transport_get_next, it is iterating over
transports but then also accessing the association directly, without
checking any refcnts before that, which can cause an use-after-free
Read.
So fix it by holding transport before accessing the association. With
that, sctp_transport_hold calls can be removed in the later places.
Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/proc.c | 4 ----
net/sctp/socket.c | 22 +++++++++++++++-------
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index ef5c9a8..4d6f1c8 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -264,8 +264,6 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
}
transport = (struct sctp_transport *)v;
- if (!sctp_transport_hold(transport))
- return 0;
assoc = transport->asoc;
epb = &assoc->base;
sk = epb->sk;
@@ -322,8 +320,6 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
}
transport = (struct sctp_transport *)v;
- if (!sctp_transport_hold(transport))
- return 0;
assoc = transport->asoc;
list_for_each_entry_rcu(tsp, &assoc->peer.transport_addr_list,
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index e96b15a..aa76586 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5005,9 +5005,14 @@ struct sctp_transport *sctp_transport_get_next(struct net *net,
break;
}
+ if (!sctp_transport_hold(t))
+ continue;
+
if (net_eq(sock_net(t->asoc->base.sk), net) &&
t->asoc->peer.primary_path == t)
break;
+
+ sctp_transport_put(t);
}
return t;
@@ -5017,13 +5022,18 @@ struct sctp_transport *sctp_transport_get_idx(struct net *net,
struct rhashtable_iter *iter,
int pos)
{
- void *obj = SEQ_START_TOKEN;
+ struct sctp_transport *t;
- while (pos && (obj = sctp_transport_get_next(net, iter)) &&
- !IS_ERR(obj))
- pos--;
+ if (!pos)
+ return SEQ_START_TOKEN;
- return obj;
+ while ((t = sctp_transport_get_next(net, iter)) && !IS_ERR(t)) {
+ if (!--pos)
+ break;
+ sctp_transport_put(t);
+ }
+
+ return t;
}
int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
@@ -5082,8 +5092,6 @@ int sctp_for_each_transport(int (*cb)(struct sctp_transport *, void *),
tsp = sctp_transport_get_idx(net, &hti, *pos + 1);
for (; !IS_ERR_OR_NULL(tsp); tsp = sctp_transport_get_next(net, &hti)) {
- if (!sctp_transport_hold(tsp))
- continue;
ret = cb(tsp, p);
if (ret)
break;
--
2.1.0
^ permalink raw reply related
* [PATCH net] sctp: remove useless start_fail from sctp_ht_iter in proc
From: Xin Long @ 2018-08-27 10:40 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
After changing rhashtable_walk_start to return void, start_fail would
never be set other value than 0, and the checking for start_fail is
pointless, so remove it.
Fixes: 97a6ec4ac021 ("rhashtable: Change rhashtable_walk_start to return void")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/proc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 4d6f1c8..a644292 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -215,7 +215,6 @@ static const struct seq_operations sctp_eps_ops = {
struct sctp_ht_iter {
struct seq_net_private p;
struct rhashtable_iter hti;
- int start_fail;
};
static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
@@ -224,7 +223,6 @@ static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
sctp_transport_walk_start(&iter->hti);
- iter->start_fail = 0;
return sctp_transport_get_idx(seq_file_net(seq), &iter->hti, *pos);
}
@@ -232,8 +230,6 @@ static void sctp_transport_seq_stop(struct seq_file *seq, void *v)
{
struct sctp_ht_iter *iter = seq->private;
- if (iter->start_fail)
- return;
sctp_transport_walk_stop(&iter->hti);
}
--
2.1.0
^ permalink raw reply related
* [PATCH net] erspan: set erspan_ver to 1 by default when adding an erspan dev
From: Xin Long @ 2018-08-27 10:41 UTC (permalink / raw)
To: network dev; +Cc: davem, William Tu
After erspan_ver is introudced, if erspan_ver is not set in iproute, its
value will be left 0 by default. Since Commit 02f99df1875c ("erspan: fix
invalid erspan version."), it has broken the traffic due to the version
check in erspan_xmit if users are not aware of 'erspan_ver' param, like
using an old version of iproute.
To fix this compatibility problem, it sets erspan_ver to 1 by default
when adding an erspan dev in erspan_setup. Note that we can't do it in
ipgre_netlink_parms, as this function is also used by ipgre_changelink.
Fixes: 02f99df1875c ("erspan: fix invalid erspan version.")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv4/ip_gre.c | 3 +++
net/ipv6/ip6_gre.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 51a5d06..ae714ae 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1508,11 +1508,14 @@ static int ipgre_fill_info(struct sk_buff *skb, const struct net_device *dev)
static void erspan_setup(struct net_device *dev)
{
+ struct ip_tunnel *t = netdev_priv(dev);
+
ether_setup(dev);
dev->netdev_ops = &erspan_netdev_ops;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
ip_tunnel_setup(dev, erspan_net_id);
+ t->erspan_ver = 1;
}
static const struct nla_policy ipgre_policy[IFLA_GRE_MAX + 1] = {
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 18a3794..e493b04 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1778,6 +1778,7 @@ static void ip6gre_netlink_parms(struct nlattr *data[],
if (data[IFLA_GRE_COLLECT_METADATA])
parms->collect_md = true;
+ parms->erspan_ver = 1;
if (data[IFLA_GRE_ERSPAN_VER])
parms->erspan_ver = nla_get_u8(data[IFLA_GRE_ERSPAN_VER]);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Jamal Hadi Salim @ 2018-08-27 11:46 UTC (permalink / raw)
To: Kees Cook
Cc: Al Viro, LKML, Cong Wang, Jiri Pirko, David S. Miller,
Network Development
In-Reply-To: <CAGXu5jJZ-BfJPA+m1BOuVVQxPb8SXpSRo+F2cVTF62C9JTyRXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On 2018-08-26 5:56 p.m., Kees Cook wrote:
> On Sun, Aug 26, 2018 at 10:30 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> We should add an nla_policy later.
>
> What's the right way to do that for cases like this?
Meant something like attached which you alluded-to in your comments
would give an upper bound (Max allowed keys is 128).
cheers,
jamal
[-- Attachment #2: patchlet --]
[-- Type: text/plain, Size: 706 bytes --]
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index d5d2a6dc3921..cb7a3fa0e728 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -761,7 +761,9 @@ static const struct nla_policy u32_policy[TCA_U32_MAX + 1] = {
[TCA_U32_HASH] = { .type = NLA_U32 },
[TCA_U32_LINK] = { .type = NLA_U32 },
[TCA_U32_DIVISOR] = { .type = NLA_U32 },
- [TCA_U32_SEL] = { .len = sizeof(struct tc_u32_sel) },
+ [TCA_U32_SEL] = { .type = NLA_BINARY,
+ .len = (sizeof(struct tc_u32_sel) +
+ (128*sizeof(struct tc_u32_key)) },
[TCA_U32_INDEV] = { .type = NLA_STRING, .len = IFNAMSIZ },
[TCA_U32_MARK] = { .len = sizeof(struct tc_u32_mark) },
[TCA_U32_FLAGS] = { .type = NLA_U32 },
^ permalink raw reply related
* [PATCH] net: mvpp2: initialize port of_node pointer
From: Baruch Siach @ 2018-08-27 12:12 UTC (permalink / raw)
To: Maxime Chevallier, Antoine Tenart
Cc: netdev, Russell King, Ori Shem-Tov, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Baruch Siach
Without a valid of_node in struct device we can't find the mvpp2 port
device by its DT node. Specifically, this breaks
of_find_net_device_by_node().
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 32d785b616e1..28500417843e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4803,6 +4803,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
dev->min_mtu = ETH_MIN_MTU;
/* 9704 == 9728 - 20 and rounding to 8 */
dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
+ dev->dev.of_node = port_node;
/* Phylink isn't used w/ ACPI as of now */
if (port_node) {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Geert Uytterhoeven @ 2018-08-27 12:28 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux-Renesas
In-Reply-To: <1535029653-7418-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Thu, Aug 23, 2018 at 3:08 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch fixes this problem and also allows for architectures
> missing some of the clocks (e.g. RZ/G2) to behave as expected.
I think the fix for the second issue is not needed (see my reply to the other
patch).
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> ---
>
> This patch applies on linux-can-next-for-4.19-20180727
>
> drivers/net/can/rcar/rcar_can.c | 43 +++++++++++++++++++++++++++++++++--------
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
> index 11662f4..fbd9284 100644
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -21,9 +21,13 @@
> #include <linux/clk.h>
> #include <linux/can/platform/rcar_can.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
>
> #define RCAR_CAN_DRV_NAME "rcar_can"
>
> +#define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> + BIT(CLKR_CLKEXT))
> +
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> * mailbox 56 - 59 - Tx FIFO mailboxes
> @@ -745,10 +749,12 @@ static int rcar_can_probe(struct platform_device *pdev)
> u32 clock_select = CLKR_CLKP1;
> int err = -ENODEV;
> int irq;
> + uintptr_t allowed_clks = RCAR_SUPPORTED_CLOCKS;
>
> if (pdev->dev.of_node) {
> of_property_read_u32(pdev->dev.of_node,
> "renesas,can-clock-select", &clock_select);
> + allowed_clks = (uintptr_t)of_device_get_match_data(&pdev->dev);
> } else {
> pdata = dev_get_platdata(&pdev->dev);
> if (!pdata) {
> @@ -789,7 +795,7 @@ static int rcar_can_probe(struct platform_device *pdev)
> goto fail_clk;
> }
>
> - if (clock_select >= ARRAY_SIZE(clock_names)) {
> + if (!(BIT(clock_select) & allowed_clks)) {
Hence you can just use RCAR_SUPPORTED_CLOCKS directly,
or better, just check clock_names[clock_select] != NULL, ...
> err = -EINVAL;
> dev_err(&pdev->dev, "invalid CAN clock selected\n");
> goto fail_clk;
> @@ -899,13 +905,34 @@ static int __maybe_unused rcar_can_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(rcar_can_pm_ops, rcar_can_suspend, rcar_can_resume);
>
> static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
> - { .compatible = "renesas,can-r8a7778" },
> - { .compatible = "renesas,can-r8a7779" },
> - { .compatible = "renesas,can-r8a7790" },
> - { .compatible = "renesas,can-r8a7791" },
> - { .compatible = "renesas,rcar-gen1-can" },
> - { .compatible = "renesas,rcar-gen2-can" },
> - { .compatible = "renesas,rcar-gen3-can" },
> + {
> + .compatible = "renesas,can-r8a7778",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7779",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7790",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7791",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen1-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen2-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen3-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> { }
... and all of the above can dropped.
> };
> MODULE_DEVICE_TABLE(of, rcar_can_of_table);
BTW, why does the custom "renesas,can-clock-select" exist?
If guess the standard "assigned-clock-parents" wasn't suitable because there's
no actual defined clock for which you can change the parent?
Why do you need manual selection? Can't the driver just pick the most suitable
available clock, like other drivers (e.g. sh-sci) do?
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH 2/3][can-next] can: rcar_can: Add RZ/G2 support
From: Geert Uytterhoeven @ 2018-08-27 12:30 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux-Renesas
In-Reply-To: <1535029653-7418-3-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
(Usually the DT patch goes before the driver patch)
On Thu, Aug 23, 2018 at 3:08 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> RZ/G2 devices don't have clkp2, therefore this commit adds a
> generic compatible string for them to allow for proper checking
> during probe.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Thanks for your patch!
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -27,6 +27,7 @@
>
> #define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> BIT(CLKR_CLKEXT))
> +#define RZG2_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKEXT))
>
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> @@ -933,6 +934,10 @@ static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
> .compatible = "renesas,rcar-gen3-can",
> .data = (void *)RCAR_SUPPORTED_CLOCKS,
> },
> + {
> + .compatible = "renesas,rzg-gen2-can",
> + .data = (void *)RZG2_SUPPORTED_CLOCKS,
> + },
> { }
I think this patch is not needed, cfr. my reply to the
first^H^H^H^H^Hthird patch
in your series.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
From: Marc Kleine-Budde @ 2018-08-27 10:08 UTC (permalink / raw)
To: Eugeniu Rosca, Simon Horman, Kieran Bingham, Sergei Shtylyov,
Wolfgang Grandegger, David S . Miller, Rob Herring, Mark Rutland,
linux-can, netdev, devicetree, Magnus Damm, linux-renesas-soc
Cc: Eugeniu Rosca
In-Reply-To: <20180820144910.13210-1-erosca@de.adit-jv.com>
[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]
On 08/20/2018 04:49 PM, Eugeniu Rosca wrote:
> From: Eugeniu Rosca <rosca.eugeniu@gmail.com>
>
> Document the support for rcar_can on R8A77965 SoC devices.
> Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
> "assigned-clock-rates" properties (thanks, Sergei).
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Added to linux-can.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 1/2] net/ibm/emac: wrong emac_calc_base call was used by typo
From: Ivan Mikhaylov @ 2018-08-27 16:43 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Christian Lamparter, linux-kernel
__emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
by copy-paste mistake for emac4syn.
Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192 rx/tx fifo size")
Signed-off-by: Ivan Mikhaylov <ivan@de.ibm.com>
---
drivers/net/ethernet/ibm/emac/core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 354c098..3726646 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -494,9 +494,6 @@ static u32 __emac_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_s
case 16384:
ret |= EMAC_MR1_RFS_16K;
break;
- case 8192:
- ret |= EMAC4_MR1_RFS_8K;
- break;
case 4096:
ret |= EMAC_MR1_RFS_4K;
break;
@@ -537,6 +534,9 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
case 16384:
ret |= EMAC4_MR1_RFS_16K;
break;
+ case 8192:
+ ret |= EMAC4_MR1_RFS_8K;
+ break;
case 4096:
ret |= EMAC4_MR1_RFS_4K;
break;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Russell King - ARM Linux @ 2018-08-27 16:50 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180517082939.14598-3-antoine.tenart@bootlin.com>
On Thu, May 17, 2018 at 10:29:31AM +0200, Antoine Tenart wrote:
> +static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> + struct mvpp2_port *port = netdev_priv(dev);
> +
> + /* Check for invalid configuration */
> + if (state->interface == PHY_INTERFACE_MODE_10GKR && port->gop_id != 0) {
> + netdev_err(dev, "Invalid mode on %s\n", dev->name);
> + return;
> + }
> +
> + netif_tx_stop_all_queues(port->dev);
> + if (!port->has_phy)
> + netif_carrier_off(port->dev);
...
> + /* If the port already was up, make sure it's still in the same state */
> + if (state->link || !port->has_phy) {
> + mvpp2_port_enable(port);
> +
> + mvpp2_egress_enable(port);
> + mvpp2_ingress_enable(port);
> + if (!port->has_phy)
> + netif_carrier_on(dev);
> + netif_tx_wake_all_queues(dev);
> + }
I'm guessing that the above is what is classed as "small fixes"
in the cover letter for this series - as such I didn't look closely
at this patch, but I should have, because this is not a "small fix".
I don't find the above code in previous patches, and I don't find
any description about why this has changed.
I'm on record for having said (many times) that drivers that are
converted to phylink should _not_ mess with the net device carrier
state themselves, but should leave it to phylink to manage.
The above appears to cause a problem when testing on a singleshot
mcbin board - as a direct result of the above, I find that _all_
the network devices apparently have link, including those which
have no SFP inserted into the cage. This results in debian jessie
hanging at boot for over 1 minute while systemd tries to bring up
all network devices.
The same should be true of the doubleshot board's 1G cage - which
is the same as the singleshot in every respect, and the singleshot
exhibits this problem there as well. I haven't actually tested
this on the doubleshot though.
Have you identified a case where mac_config() is called with the
link up for which a major reconfiguration is required? mac_config()
will get called for small reconfigurations such as changing the
pause parameters (which should _not_ require the queues to be
restarted) but the link should always be down for major
reconfigurations such sa changing the PHY interface mode.
mac_config() can also be called when nothing has changed - if we've
decided to re-run the link state resolve, it can be called with the
same parameters as previously, especially now that we have polling
of a GPIO for link state monitoring. With your code above, this will
cause mvpp2 to down/up the carrier state every second.
Note that state->link here is the _future_ state of the link, which
may change state before the mac_link_up()/down() functions have been
called - turning the carrier on/off like this will prevent these
callbacks being made, and the link state being printed by phylink.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox