* Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-03 15:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, gregory.clement, linux, mw,
stefanc, ymarkman, thomas.petazzoni, miquel.raynal, nadavh,
netdev, linux-kernel
In-Reply-To: <20180103152036.GC3401@lunn.ch>
Hi Andrew,
On Wed, Jan 03, 2018 at 04:20:36PM +0100, Andrew Lunn wrote:
> > @@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
> > case PHY_INTERFACE_MODE_1000BASEX:
> > mode = PHY_MODE_SGMII;
> > break;
> > + case PHY_INTERFACE_MODE_2500BASEX:
> > + mode = PHY_MODE_2500SGMII;
> > + break;
>
> I think this is the source of confusion with linux/phy.h and
> linux/phy/phy.h.
>
> What would PHY_INTERFACE_MODE_2500SGMII use?
>
> Where is this all getting confused? Should the caller to
> mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
> What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
PHY_INTERFACE_MODE_2500BASEX is the PHY mode whereas PHY_MODE_2500SGMII
is the mode used by the common PHY driver (i.e. the one configuring the
serdes lanes).
There's no PHY_INTERFACE_MODE_2500SGMII mode.
> At minimum there needs to be a comment that this is not a typ0,
> otherwise you are going to get patches submitted to 'fix' this.
Sure, I can add a comment to state this function is a translation
between the net PHY mode and the generic PHY mode (it's a n-to-1
translation).
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net] sctp: fix handling of ICMP Frag Needed for too small MTUs
From: Xin Long @ 2018-01-03 15:31 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <20180103133513.GA727@localhost.localdomain>
On Wed, Jan 3, 2018 at 9:35 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Jan 03, 2018 at 03:31:00PM +0800, Xin Long wrote:
>> On Wed, Jan 3, 2018 at 5:44 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > syzbot reported a hang involving SCTP, on which it kept flooding dmesg
>> > with the message:
>> > [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
>> > low, using default minimum of 512
>> >
>> > That happened because whenever SCTP hits an ICMP Frag Needed, it tries
>> > to adjust to the new MTU and triggers an immediate retransmission. But
>> > it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
>> > allowed (512) would not cause the PMTU to change, and issued the
>> > retransmission anyway (thus leading to another ICMP Frag Needed, and so
>> > on).
>> >
>> > The fix is to disable Path MTU discovery for such transport and to skip
>> > the retransmission in such cases. By doing this, SCTP will do the
>> > backoff retransmissions as needed and will likely switch to another
>> > transport if available.
>> >
>> > See-also: https://lkml.org/lkml/2017/12/22/811
>> > Reported-by: syzbot <syzkaller@googlegroups.com>
>> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>> > ---
>> > net/sctp/input.c | 5 ++++-
>> > net/sctp/transport.c | 2 ++
>> > 2 files changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/net/sctp/input.c b/net/sctp/input.c
>> > index 621b5ca3fd1c17c3d7ef7bb1c7677ab98cebbe77..a24658c6f181e03d85f12dbe929c8bb4abaefcbd 100644
>> > --- a/net/sctp/input.c
>> > +++ b/net/sctp/input.c
>> > @@ -412,8 +412,11 @@ void sctp_icmp_frag_needed(struct sock *sk, struct sctp_association *asoc,
>> > * Needed will never be sent, but if a message was sent before
>> > * PMTU discovery was disabled that was larger than the PMTU, it
>> > * would not be fragmented, so it must be re-transmitted fragmented.
>> > + * If the new PMTU is invalid, we will keep getting ICMP Frag
>> > + * Needed. In this case, simply avoid the retransmit.
>> > */
>> > - sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
>> > + if (pmtu >= SCTP_DEFAULT_MINSEGMENT)
>> > + sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
>> > }
>> >
>> > void sctp_icmp_redirect(struct sock *sk, struct sctp_transport *t,
>> > diff --git a/net/sctp/transport.c b/net/sctp/transport.c
>> > index 1e5a22430cf56e40a6f323081beb97836b506384..fbd9fe25764d4d98f93c60a48eccefd9cc6b4165 100644
>> > --- a/net/sctp/transport.c
>> > +++ b/net/sctp/transport.c
>> > @@ -259,6 +259,8 @@ void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
>> > * pmtu discovery on this transport.
>> > */
>> > t->pathmtu = SCTP_DEFAULT_MINSEGMENT;
>> > + t->param_flags = (t->param_flags & ~SPP_PMTUD) |
>> > + SPP_PMTUD_DISABLE;
>> It seems that once it hits here, this transport will have the minimum pmtu
>> forever, even after t->dst has expired. It means this tx path will not come
>> back to normal any more even when it gets a needfrag with reasonable
>> pmtu. is it too harsh to this transport ?
>
> That was the idea. That is what the comment above these lines is
> describing already. Though I missed 06ad391919b2 ("[SCTP] Don't
> disable PMTU discovery when mtu is small") and yes, too harsh.
>
>>
>> Another thing is on sctp_sendmsg, it also checks pmtu_pending that may
>> be set by needfrag, and goes to sctp_assoc_sync_pmtu to trigger this
>> warning again.
>
> That is true but that's not an issue, is it? We are not trying to get
> ride of the warning, instead we want to not cause a flood of
> bogus retransmissions (which led to the flood of warnings).
Right, I guess that the flood of warnings mostly came from that
sctp_retransmit() in sctp_icmp_frag_needed().
Otherwise, that transport should be marked as 'unreachable'
or the asoc should abort after so many times rtx.
>
> By not disabling PMTU discovery (as above) we will have such warning
> every now and then again for the same transport. We may add
> _ratelimited to it, that would help in the case of we have like a
> thousand transports suddenly being affected by such small MTU, but
> won't omit it completely.
If it can't be avoided only with the check 'pmtu >= SCTP_DEFAULT_MINSEGMENT',
yeah, _ratelimited looks good. :-)
>
> I'll spin a v2, thanks.
>
>>
>> > } else {
>> > t->pathmtu = pmtu;
>> > }
>> > --
>> > 2.14.3
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: mv88e6xxx: Get mv88e6352 SERDES statistics
From: Vivien Didelot @ 2018-01-03 15:31 UTC (permalink / raw)
To: Andrew Lunn, David Miller
Cc: Florian Fainelli, netdev, Russell King, Andrew Lunn
In-Reply-To: <1514988562-20079-6-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> +struct mv88e6xxx_port {
> + u64 serdes_stats[2];
> +};
> +
> struct mv88e6xxx_chip {
> const struct mv88e6xxx_info *info;
>
> @@ -207,6 +211,9 @@ struct mv88e6xxx_chip {
> int irq;
> int device_irq;
> int watchdog_irq;
> +
> + /* Array of port structures. */
> + struct mv88e6xxx_port ports[DSA_MAX_PORTS];
> };
We are trying to get rid of these global DSA limitations for ports and
switches and support dynamic values. It wasn't mentioned but I assume
you couldn't use a zero length array here because we allocate before
detecting the switch model. Please define MV88E6XXX_MAX_PORTS to 16
instead, which is indeed a Marvell limitation for SOHO devices.
>
> struct mv88e6xxx_bus_ops {
> diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
> index d32522276fea..3b911b80da33 100644
> --- a/drivers/net/dsa/mv88e6xxx/serdes.c
> +++ b/drivers/net/dsa/mv88e6xxx/serdes.c
> @@ -87,6 +87,90 @@ int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
> return 0;
> }
>
> +struct mv88e6352_serdes_hw_stat {
> + char string[ETH_GSTRING_LEN];
> + int sizeof_stat;
You can simply define size_t size.
> + int reg;
> +};
> +
> +static struct mv88e6352_serdes_hw_stat mv88e6352_serdes_hw_stats[] = {
> + { "serdes_fibre_rx_error", 16, 21 },
> + { "serdes_PRBS_error", 32, 24 },
> +};
<...>
> + BUILD_BUG_ON(ARRAY_SIZE(mv88e6352_serdes_hw_stats) >
> + ARRAY_SIZE(mv88e6xxx_port->serdes_stats));
> +
> + for (i = 0; i < ARRAY_SIZE(mv88e6352_serdes_hw_stats); i++) {
> + stat = &mv88e6352_serdes_hw_stats[i];
> + value = mv88e6352_serdes_get_stat(chip, stat);
extra space
> + mv88e6xxx_port->serdes_stats[i] += value;
> + data[i] = mv88e6xxx_port->serdes_stats[i];
> + }
> +}
^ permalink raw reply
* [PATCH iproute2] devlink, rdma, tipc: properly define TARGETS without HAVE_MNL
From: Matthias Schiffer @ 2018-01-03 15:28 UTC (permalink / raw)
To: stephen; +Cc: netdev
Leaving a variable with a generic name such as TARGETS undefined would lead
to Make picking up its value from the environment. Avoid this by always
defining TARGETS in the Makefiles.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
I also noticed that many Makefiles refer to a variable LIBS, which is
neither defined nor documented to be passed from the outside. Is this
intentional?
devlink/Makefile | 4 +++-
rdma/Makefile | 4 +++-
tipc/Makefile | 4 +++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/devlink/Makefile b/devlink/Makefile
index 3afda65e..ace34c7b 100644
--- a/devlink/Makefile
+++ b/devlink/Makefile
@@ -1,10 +1,12 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
DEVLINKOBJ = devlink.o mnlg.o
-TARGETS=devlink
+TARGETS += devlink
CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
diff --git a/rdma/Makefile b/rdma/Makefile
index c8966bfd..454f25f8 100644
--- a/rdma/Makefile
+++ b/rdma/Makefile
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
RDMA_OBJ = rdma.o utils.o dev.o link.o
-TARGETS=rdma
+TARGETS += rdma
endif
all: $(TARGETS) $(LIBS)
diff --git a/tipc/Makefile b/tipc/Makefile
index abd33ab0..fdb18d39 100644
--- a/tipc/Makefile
+++ b/tipc/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
TIPCOBJ=bearer.o \
@@ -10,7 +12,7 @@ TIPCOBJ=bearer.o \
node.o socket.o \
peer.o tipc.o
-TARGETS=tipc
+TARGETS += tipc
endif
--
2.15.1
^ permalink raw reply related
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: David Miller @ 2018-01-03 15:28 UTC (permalink / raw)
To: nhorman; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103.102606.1453240990448791901.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 03 Jan 2018 10:26:06 -0500 (EST)
> From: Neil Horman <nhorman@redhat.com>
> Date: Wed, 3 Jan 2018 10:13:33 -0500
>
>> Thats exactly what this patch does, instead of creating a second loop to
>> traverse all the emptied ring buffers, now I:
>>
>> 1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
>> 2) Map the skb into the appropriate dma device domain
>> 3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
>> with the old one and recieve the old into the network stack
>> 4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
>> dma address in place, sets the buffer status back to 0 (indicating completion),
>> and write the new ring status back to the hardware
>>
>> This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
>> approach, rather than the leave-a-hole-in-the-ring approach that is there
>> currently, no? Or did I miss something else?
>
> I misread the code sorry, you're absolutely right.
>
> I'll apply this patch, thanks Neil. :)
Hmmm, maybe we need a V3 after all :)
CC [M] drivers/net/ethernet/3com/3c59x.o
drivers/net/ethernet/3com/3c59x.c: In function ‘boomerang_rx’:
drivers/net/ethernet/3com/3c59x.c:2605:13: warning: unused variable ‘dma’ [-Wunused-variable]
dma_addr_t dma;
^~~
^ permalink raw reply
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: David Miller @ 2018-01-03 15:26 UTC (permalink / raw)
To: nhorman; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103151333.GB22129@hmswarspite.think-freely.org>
From: Neil Horman <nhorman@redhat.com>
Date: Wed, 3 Jan 2018 10:13:33 -0500
> Thats exactly what this patch does, instead of creating a second loop to
> traverse all the emptied ring buffers, now I:
>
> 1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
> 2) Map the skb into the appropriate dma device domain
> 3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
> with the old one and recieve the old into the network stack
> 4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
> dma address in place, sets the buffer status back to 0 (indicating completion),
> and write the new ring status back to the hardware
>
> This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
> approach, rather than the leave-a-hole-in-the-ring approach that is there
> currently, no? Or did I miss something else?
I misread the code sorry, you're absolutely right.
I'll apply this patch, thanks Neil. :)
^ permalink raw reply
* Re: [PATCHv1 3/6] ARM: dts: imx6q-bx50v3: Add internal switch
From: Sebastian Reichel @ 2018-01-03 15:24 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam, Ian Ray, Nandor Han, Rob Herring,
David S. Miller, netdev, devicetree, linux-kernel
In-Reply-To: <5c87f610-4927-faca-40a7-3f83e7f00ff7@cogentembedded.com>
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]
Hi,
On Wed, Jan 03, 2018 at 05:48:42PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 01/03/2018 03:26 PM, Sebastian Reichel wrote:
>
> > B850v3, B650v3 and B450v3 all have a GPIO bit banged MDIO bus to
> > communicate with a Marvell switch. On all devices the switch is
> > connected to a PCI based network card, which needs to be referenced
> > by DT, so this also adds the common PCI root node.
> >
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > ---
> > arch/arm/boot/dts/imx6q-bx50v3.dtsi | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > index b915837bbb5f..689981e90e68 100644
> > --- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > @@ -92,6 +92,31 @@
> > mux-int-port = <1>;
> > mux-ext-port = <4>;
> > };
> > +
> > + aliases {
> > + mdio-gpio0 = &mdio0;
> > + };
> > +
> > + mdio0: mdio-gpio {
> > + compatible = "virtual,mdio-gpio";
> > + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>, /* mdc */
> > + <&gpio2 7 GPIO_ACTIVE_HIGH>; /* mdio */
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + switch@0 {
> > + compatible = "marvell,mv88e6240";
>
> Why suddenly 2 extra tabs instead of 1?
will be fixed in PATCHv2.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + switch_ports: ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > + };
> > };
> > &ecspi5 {
> [...]
>
> MBR, Sergei
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 02/39] openrisc: add ioremap_nocache declaration before include asm-generic/io.h and sync ioremap prototype with it.
From: Greentime Hu @ 2018-01-03 15:23 UTC (permalink / raw)
To: Stafford Horne
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH
In-Reply-To: <20180103143803.GI32243@lianli.shorne-pla.net>
Hi, Stafford:
2018-01-03 22:38 GMT+08:00 Stafford Horne <shorne@gmail.com>:
> Hello,
>
> On Tue, Jan 02, 2018 at 04:24:34PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> It will be built failed if commit id: d25ea659 is selected. This patch can fix this
>> build error.
>
> Ideally you would mention the commit description since the id is not yet
> usptream. I found it here (its 1 in this series):
>
> https://github.com/andestech/linux/commit/d25ea659
> asm-generic/io.h: move ioremap_nocache/ioremap_uc/ioremap_wc/ioremap_...
>
>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>> ---
>> arch/openrisc/include/asm/io.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
>> index 7c69139..6709b28 100644
>> --- a/arch/openrisc/include/asm/io.h
>> +++ b/arch/openrisc/include/asm/io.h
>> @@ -29,13 +29,14 @@
>> #define PIO_OFFSET 0
>> #define PIO_MASK 0
>>
>> +#define ioremap_nocache ioremap_nocache
>> #include <asm-generic/io.h>
>
> Ideally we could move <asm-generic/io.h> include down to the bottom of the file
> and not have to do the defines like like this, it seems clumsy to me. In
> 'cris', 'nios2' and other architectures I can see they have the generic include
> at the bottom of the file and not need for #define's.
>
> I tried that but I get a lot of errors. Does your patch to asm-generic/io.h
> cause build issues for those architectures as well?
>
I got this email from kbuild test robot. I personally tried arm64/x86
before I sent the generic asm io.h patch.
I tried openrisc/sparc before I sent these v5 patches.
BUILD REGRESSION
tree/branch: https://github.com/0day-ci/linux
Greentime-Hu/Andes-nds32-Linux-Kernel/20171220-155937
branch HEAD: 9353e22157b9b69be3a3beea3553b5a105a45516 dt-bindings:
timer: Add andestech atcpit100 timer binding doc
Regressions in current branch:
arch/cris/mm/ioremap.c:79:15: note: in expansion of macro 'ioremap_nocache'
arch/openrisc/include/asm/io.h:38:29: error: conflicting types for 'ioremap'
arch/openrisc/include/asm/io.h:44:29: note: in expansion of macro
'ioremap_nocache'
arch/sparc/include/asm/io_32.h:129:15: error: conflicting types for 'ioremap'
arch/sparc/include/asm/io_32.h:130:0: warning: "ioremap_nocache" redefined
arch/sparc/include/asm/io_32.h:131:0: warning: "ioremap_wc" redefined
arch/sparc/include/asm/io_32.h:132:0: warning: "ioremap_wt" redefined
arch/sparc/kernel/ioport.c:124:15: error: conflicting types for 'ioremap'
arch/sparc/kernel/ioport.c:131:1: note: in expansion of macro 'EXPORT_SYMBOL'
drivers/net/ethernet/faraday/ftmac100.c:205:32: sparse: restricted
__le32 degrades to integer
drivers/net/ethernet/faraday/ftmac100.c:221:23: sparse: incorrect type
in assignment (different base types)
drivers/net/ethernet/faraday/ftmac100.c:251:16: sparse: cast to
restricted __le32
drivers/net/ethernet/faraday/ftmac100.c:262:23: sparse: invalid assignment: &=
drivers/net/ethernet/faraday/ftmac100.c:274:23: sparse: incorrect type
in assignment (different base types)
drivers/net/ethernet/faraday/ftmac100.c:288:18: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
drivers/net/ethernet/faraday/ftmac100.c:293:9: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]
drivers/net/ethernet/faraday/ftmac100.c:534:23: sparse: incorrect type
in assignment (different base types)
include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
Error ids grouped by kconfigs:
recent_errors
├── cris-etrax-100lx_v2_defconfig
│ └── arch-cris-mm-ioremap.c:note:in-expansion-of-macro-ioremap_nocache
├── openrisc-or1ksim_defconfig
│ ├── arch-openrisc-include-asm-io.h:error:conflicting-types-for-ioremap
│ └── arch-openrisc-include-asm-io.h:note:in-expansion-of-macro-ioremap_nocache
├── sparc64-allyesconfig
│ ├── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-from-pointer-to-integer-of-different-size
│ └── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-to-pointer-from-integer-of-different-size
├── sparc-defconfig
│ ├── arch-sparc-include-asm-io_32.h:error:conflicting-types-for-ioremap
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_nocache-redefined
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_wc-redefined
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_wt-redefined
│ ├── arch-sparc-kernel-ioport.c:error:conflicting-types-for-ioremap
│ └── arch-sparc-kernel-ioport.c:note:in-expansion-of-macro-EXPORT_SYMBOL
├── x86_64-allmodconfig
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:cast-to-restricted-__le32
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-rxdes0-got-restrunsigned-int-unsigned-rxdes0
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-rxdes2-got-restrunsigned-int-unsigned-rxdes2
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-txdes2-got-restrunsigned-int-unsigned-txdes2
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:invalid-assignment:
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:restricted-__le32-degrades-to-integer
│ ├── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-from-pointer-to-integer-of-different-size
│ └── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-to-pointer-from-integer-of-different-size
└── xtensa-allmodconfig
├── include-asm-generic-io.h:error:conflicting-types-for-ioremap
├── include-asm-generic-io.h:error:conflicting-types-for-ioremap_nocache
└── include-asm-generic-io.h:note:in-expansion-of-macro-ioremap_nocache
elapsed time: 359m
configs tested: 128
i386 tinyconfig
i386 randconfig-x016-201751
i386 randconfig-x011-201751
i386 randconfig-x014-201751
i386 randconfig-x017-201751
i386 randconfig-x019-201751
i386 randconfig-x018-201751
i386 randconfig-x010-201751
i386 randconfig-x013-201751
i386 randconfig-x015-201751
i386 randconfig-x012-201751
i386 randconfig-n0-201751
x86_64 randconfig-x003-201751
x86_64 randconfig-x002-201751
x86_64 randconfig-x006-201751
x86_64 randconfig-x007-201751
x86_64 randconfig-x000-201751
x86_64 randconfig-x005-201751
x86_64 randconfig-x004-201751
x86_64 randconfig-x009-201751
x86_64 randconfig-x008-201751
x86_64 randconfig-x001-201751
ia64 allnoconfig
ia64 defconfig
ia64 alldefconfig
i386 randconfig-i0-12180843
i386 randconfig-i1-12180843
x86_64 randconfig-x012-201751
x86_64 randconfig-x010-201751
x86_64 randconfig-x011-201751
x86_64 randconfig-x015-201751
x86_64 randconfig-x019-201751
x86_64 randconfig-x014-201751
x86_64 randconfig-x013-201751
x86_64 randconfig-x016-201751
x86_64 randconfig-x017-201751
x86_64 randconfig-x018-201751
i386 randconfig-a0-201751
i386 randconfig-a1-201751
c6x evmc6678_defconfig
xtensa common_defconfig
m32r m32104ut_defconfig
score spct6600_defconfig
xtensa iss_defconfig
m32r opsput_defconfig
m32r usrv_defconfig
m32r mappi3.smp_defconfig
nios2 10m50_defconfig
h8300 h8300h-sim_defconfig
cris etrax-100lx_v2_defconfig
blackfin TCM-BF537_defconfig
blackfin BF561-EZKIT-SMP_defconfig
blackfin BF533-EZKIT_defconfig
blackfin BF526-EZBRD_defconfig
i386 allnoconfig
i386 defconfig
i386 alldefconfig
i386 randconfig-s1-201751
i386 randconfig-s0-201751
mn10300 asb2364_defconfig
openrisc or1ksim_defconfig
um x86_64_defconfig
um i386_defconfig
frv defconfig
tile tilegx_defconfig
i386 allmodconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
sh titan_defconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh allnoconfig
i386 randconfig-x007-201751
i386 randconfig-x008-201751
i386 randconfig-x009-201751
i386 randconfig-x004-201751
i386 randconfig-x002-201751
i386 randconfig-x005-201751
i386 randconfig-x001-201751
i386 randconfig-x006-201751
i386 randconfig-x003-201751
i386 randconfig-x000-201751
m68k sun3_defconfig
m68k multi_defconfig
m68k m5475evb_defconfig
mips jz4740
mips malta_kvm_defconfig
mips 64r6el_defconfig
mips 32r2_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips txx9
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
x86_64 allmodconfig
parisc c3000_defconfig
parisc b180_defconfig
parisc defconfig
alpha defconfig
parisc allnoconfig
s390 default_defconfig
arm at91_dt_defconfig
arm allnoconfig
arm efm32_defconfig
arm64 defconfig
arm multi_v5_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm exynos_defconfig
arm shmobile_defconfig
arm multi_v7_defconfig
i386 randconfig-x072-201751
i386 randconfig-x078-201751
i386 randconfig-x071-201751
i386 randconfig-x077-201751
i386 randconfig-x070-201751
i386 randconfig-x074-201751
i386 randconfig-x073-201751
i386 randconfig-x079-201751
i386 randconfig-x076-201751
i386 randconfig-x075-201751
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2
^ permalink raw reply
* Re: [PATCH 0/2] Kill redundant checks in the Renesas Ethernet drivers
From: David Miller @ 2018-01-03 15:21 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20171231184134.684953583@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 31 Dec 2017 21:41:34 +0300
> Here's a set of 2 patches against DaveM's 'net-next.git' repo removing
> redundant checks in the driver probe() methods.
Series applied with the "disassembly" typo fixed.
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support
From: Andrew Lunn @ 2018-01-03 15:20 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, linux, mw, stefanc, ymarkman,
thomas.petazzoni, miquel.raynal, nadavh, netdev, linux-kernel
In-Reply-To: <20180103150750.12974-5-antoine.tenart@free-electrons.com>
> @@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
> case PHY_INTERFACE_MODE_1000BASEX:
> mode = PHY_MODE_SGMII;
> break;
> + case PHY_INTERFACE_MODE_2500BASEX:
> + mode = PHY_MODE_2500SGMII;
> + break;
I think this is the source of confusion with linux/phy.h and
linux/phy/phy.h.
What would PHY_INTERFACE_MODE_2500SGMII use?
Where is this all getting confused? Should the caller to
mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
At minimum there needs to be a comment that this is not a typ0,
otherwise you are going to get patches submitted to 'fix' this.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update my email address.
From: Joe Perches @ 2018-01-03 15:20 UTC (permalink / raw)
To: Pravin B Shelar, davem; +Cc: netdev
In-Reply-To: <1514952882-7040-1-git-send-email-pshelar@ovn.org>
On Tue, 2018-01-02 at 20:14 -0800, Pravin B Shelar wrote:
> Signed-off-by: Pravin Shelar <pshelar@ovn.org>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 753799d..1704ed4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10152,7 +10152,7 @@ F: drivers/irqchip/irq-ompic.c
> F: drivers/irqchip/irq-or1k-*
>
> OPENVSWITCH
> -M: Pravin Shelar <pshelar@nicira.com>
> +M: Pravin B Shelar <pshelar@ovn.org>
If you are going to change the format of your name
by adding a middle initial, you should probably
also add a .mailmap entry.
> L: netdev@vger.kernel.org
> L: dev@openvswitch.org
> W: http://openvswitch.org
^ permalink raw reply
* Re: [PATCH net] ethtool: do not print warning for applications using legacy API
From: Stephen Hemminger @ 2018-01-03 15:19 UTC (permalink / raw)
To: David Miller; +Cc: decot, netdev, linux-kernel
In-Reply-To: <20180102.215002.671661044941618104.davem@davemloft.net>
On Tue, 02 Jan 2018 21:50:02 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Fri, 29 Dec 2017 10:02:52 -0800
>
> > From: Stephen Hemminger <stephen@networkplumber.org>
> >
> > In kernel log ths message appears on every boot:
> > "warning: `NetworkChangeNo' uses legacy ethtool link settings API,
> > link modes are only partially reported"
> >
> > When ethtool link settings API changed, it started complaining about
> > usages of old API. Ironically, the original patch was from google but
> > the application using the legacy API is chrome.
>
> Chrome on my machine doesn't do this, FWIW...
I did report a bug to chrome team as well.
^ permalink raw reply
* Re: [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Marc Kleine-Budde @ 2018-01-03 15:17 UTC (permalink / raw)
To: Faiz Abbas, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <a45431f2-d262-39a1-9152-a2ff75560d21@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 2157 bytes --]
On 01/03/2018 04:06 PM, Faiz Abbas wrote:
> Hi,
>
> On Wednesday 03 January 2018 07:55 PM, Marc Kleine-Budde wrote:
>> On 01/03/2018 01:39 PM, Faiz Abbas wrote:
>>> On Tuesday 02 January 2018 09:37 PM, Marc Kleine-Budde wrote:
>>>> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>>>>> From: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>
>>>>> Add support for PM Runtime which is the new way to handle managing clocks.
>>>>> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
>>>>> management approach in place.
>>>>
>>>> There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
>>>> CONFIG_PM_RUNTIME")
>>>
>>> Ok. Will change the commit message.
>>>
>>>>
>>>> Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :
>>>>
>>>>>> Well, I admit it would be nicer if drivers didn't have to worry about
>>>>>> whether or not CONFIG_PM was enabled. A slightly cleaner approach
>>>>>> from the one outlined above would have the probe routine do this:
>>>>>>
>>>>>> my_power_up(dev);
>>>>>> pm_runtime_set_active(dev);
>>>>>> pm_runtime_get_noresume(dev);
>>>>>> pm_runtime_enable(dev);
>>>
>>> This discussion seems to be about cases in which CONFIG_PM is not
>>> enabled. CONFIG_PM is always selected in the case of omap devices.
>>
>> Yes, but in the commit message you state that you need to support
>> systems that don't have PM_RUNTIME enabled. The only mainline SoCs I see
>> is "arch/arm/boot/dts/sama5d2.dtsi" so far. Please check if they select
>> CONFIG_PM, then we can make the driver much simpler.
>
> Actually the old clock management (for hclk which is the interface
> clock) is still required as mentioned in the cover letter. Will change
> the rather misleading description.
Ok. So you can use the code as discussed on
https://patchwork.kernel.org/patch/9436507/ ?
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
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: Neil Horman @ 2018-01-03 15:13 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103.095849.985156664792555290.davem@davemloft.net>
On Wed, Jan 03, 2018 at 09:58:49AM -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 3 Jan 2018 09:44:15 -0500
>
> > A few spots in 3c59x missed calls to dma_mapping_error checks, casuing
> > WARN_ONS to trigger. Clean those up. While we're at it, refactor the
> > refill code a bit so that if skb allocation or dma mapping fails, we
> > recycle the existing buffer. This prevents holes in the rx ring, and
> > makes for much simpler logic
> >
> > Note: This is compile only tested. Ted, if you could run this and
> > confirm that it continues to work properly, I would appreciate it, as I
> > currently don't have access to this hardware
> >
> > Signed-off-by: Neil Horman <nhorman@redhat.com>
> > CC: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> > CC: "David S. Miller" <davem@davemloft.net>
> > Reported-by: tedheadster@gmail.com
>
> See my other reply.
>
> Your RX handling must become more sophisticated.
>
Yes, I understood your previous reply.
> This is exactly what we tell driver authors to do. If you cannot allocate
> or DMA map a replacement RX buffer, you _MUST_ recycle the existing buffer
> back to the chip rather than pass it up to the stack.
>
Thats exactly what this patch does, instead of creating a second loop to
traverse all the emptied ring buffers, now I:
1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
2) Map the skb into the appropriate dma device domain
3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
with the old one and recieve the old into the network stack
4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
dma address in place, sets the buffer status back to 0 (indicating completion),
and write the new ring status back to the hardware
This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
approach, rather than the leave-a-hole-in-the-ring approach that is there
currently, no? Or did I miss something else?
Neil
^ permalink raw reply
* [PATCH net-next v2 3/4] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-1-antoine.tenart@free-electrons.com>
This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 ++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..257a6b99b4ca 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
{
u32 val;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
- /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ val |= MVPP2_GMAC_PORT_TYPE_MASK;
+ else
+ val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ /* 1000BaseX port cannot negotiate speed nor can it
+ * negotiate duplex: they are always operating with a
+ * fixed speed of 1000Mbps in full duplex, so force
+ * 1000 speed and full duplex here.
+ */
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else
+ val |= MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4733,7 +4755,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
mvpp22_port_mii_set(port);
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4810,7 +4833,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6023,7 +6047,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
link = true;
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH] net: plip: Delete an error message for a failed memory allocation in plip_receive_packet()
From: SF Markus Elfring @ 2018-01-03 15:08 UTC (permalink / raw)
To: netdev, David S. Miller, Gustavo A. R. Silva; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 3 Jan 2018 16:00:23 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/plip/plip.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index feb92ecd1880..22f10d395d9c 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -632,10 +632,9 @@ plip_receive_packet(struct net_device *dev, struct net_local *nl,
}
/* Malloc up new buffer. */
rcv->skb = dev_alloc_skb(rcv->length.h + 2);
- if (rcv->skb == NULL) {
- printk(KERN_ERR "%s: Memory squeeze.\n", dev->name);
+ if (!rcv->skb)
return ERROR;
- }
+
skb_reserve(rcv->skb, 2); /* Align IP on 16 byte boundaries */
skb_put(rcv->skb,rcv->length.h);
rcv->skb->dev = dev;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Andrew Lunn @ 2018-01-03 15:08 UTC (permalink / raw)
To: Antoine Tenart
Cc: Florian Fainelli, thomas.petazzoni, ymarkman, jason, netdev,
linux-kernel, linux, kishon, nadavh, miquel.raynal,
gregory.clement, stefanc, mw, davem, linux-arm-kernel,
sebastian.hesselbarth
In-Reply-To: <20180103143541.GE21727@kwain>
> > >>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > >>> index 4f8423a948d5..70459a28f3a1 100644
> > >>> --- a/include/linux/phy/phy.h
> > >>> +++ b/include/linux/phy/phy.h
> > >>> @@ -28,6 +28,7 @@ enum phy_mode {
> > >>> PHY_MODE_USB_DEVICE,
> > >>> PHY_MODE_USB_OTG,
> > >>> PHY_MODE_SGMII,
> > >>> + PHY_MODE_SGMII_2_5G,
> > >>> PHY_MODE_10GKR,
> > >>> PHY_MODE_UFS_HS_A,
> > >>> PHY_MODE_UFS_HS_B,
> > >>
> > >> There was a discussion maybe last month about adding 2.5G SGMII. I
> > >> would prefer 2500SGMII. Putting the number first makes it uniform with
> > >> the other defines, 1000BASEX, 25000BASEX, 10GKR.
> > >
> > > Good to know. I wasn't completely sure how to name this mode properly,
> > > but I'm fine with PHY_MODE_2500SGMII. I'll update the patches and send a
> > > v2 (without the dt part).
> >
> > And since you are respinning, please make sure you update phy_modes() in
> > the same header file as well as
> > Documentation/devicetree/bindings/net/ethernet.txt with the newly added
> > PHY interface mode.
>
> Actually it's a generic PHY mode I'm adding, not a network PHY mode.
> There's no phy_modes() function for generic PHYs (and this 2500BaseX
> mode already is supported in the network PHY modes).
Hi Antoine
Don't you need it in both include/linux/phy/phy.h and
include/linux/phy.h?
Andrew
^ permalink raw reply
* [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-1-antoine.tenart@free-electrons.com>
This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 40 ++++++++++++++++++++++++++++--------
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 257a6b99b4ca..d5e4bec98b2b 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4638,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
u32 val;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4655,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
}
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,6 +4669,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+ /* Clear all fields we may want to explicitly set below */
+ val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN);
+
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
* negotiate duplex: they are always operating with a
@@ -4668,6 +4682,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
*/
val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
else
val |= MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
@@ -4693,7 +4711,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4756,7 +4775,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4834,7 +4854,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6048,7 +6069,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 2/4] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-1-antoine.tenart@free-electrons.com>
This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..4ef429250d7b 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
};
struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+ else if (mode == PHY_MODE_2500SGMII)
+ val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
return 0;
}
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
{
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+ mvebu_comphy_ethernet_init_reset(lane, mode);
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
switch (lane->mode) {
case PHY_MODE_SGMII:
- ret = mvebu_comphy_set_mode_sgmii(phy);
+ case PHY_MODE_2500SGMII:
+ ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-1-antoine.tenart@free-electrons.com>
This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..5a80e9de3686 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+ PHY_MODE_2500SGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 0/4] net: mvpp2: 1000BaseX and 2000BaseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
Hi all,
This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).
This was tested on a mcbin.
All patches should probably go through net-next as patch 4/4 depends on
patch 1/4 to build and work.
Please note the two mvpp2 patches do not conflict with the ACPI series
v2 Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).
Thanks!
Antoine
Since v1:
- s/PHY_MODE_SGMII_2_5G/PHY_MODE_2500SGMII/
- Fixed a build error in 'net: mvpp2: 1000baseX support' (which was solved in
the 2500baseX support one, but the bisection was broken).
- Removed the dt patches, as the fourth network interface on the mcbin also
needs PHYLINK support in the PPv2 driver to be correctly supported.
Antoine Tenart (4):
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
drivers/net/ethernet/marvell/mvpp2.c | 67 +++++++++++++++++++++++-----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +++++--
include/linux/phy/phy.h | 1 +
3 files changed, 72 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: [PATCHv1 1/6] net: dsa: Support internal phy on 'cpu' port
From: Sebastian Reichel @ 2018-01-03 15:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, Shawn Guo, Sascha Hauer,
Fabio Estevam, Ian Ray, Nandor Han, Rob Herring, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180103132128.GI15036-g2DYL2Zd6BY@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]
Hi Andrew,
On Wed, Jan 03, 2018 at 02:21:28PM +0100, Andrew Lunn wrote:
> On Wed, Jan 03, 2018 at 01:26:04PM +0100, Sebastian Reichel wrote:
> > This adds support for enabling the internal phy for a 'cpu' port.
> > It has been tested on GE B850v3 and B650v3, which have a built-in
> > MV88E6240 switch connected to a PCIe based network card. Without
> > this patch the link does not come up and no traffic can be routed
> > through the switch.
> >
> > Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> > ---
> > net/dsa/port.c | 26 ++++++++++++++++++++++----
> > 1 file changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/dsa/port.c b/net/dsa/port.c
> > index bb4be2679904..f99c1d34416c 100644
> > --- a/net/dsa/port.c
> > +++ b/net/dsa/port.c
> > @@ -282,6 +282,10 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > int mode;
> > int err;
> >
> > + mode = of_get_phy_mode(dn);
> > + if (mode < 0)
> > + mode = PHY_INTERFACE_MODE_NA;
> > +
> > if (of_phy_is_fixed_link(dn)) {
> > err = of_phy_register_fixed_link(dn);
> > if (err) {
> > @@ -292,10 +296,6 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > }
> >
> > phydev = of_phy_find_device(dn);
> > -
> > - mode = of_get_phy_mode(dn);
> > - if (mode < 0)
> > - mode = PHY_INTERFACE_MODE_NA;
> > phydev->interface = mode;
> >
> > genphy_config_init(phydev);
> > @@ -305,6 +305,24 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > ds->ops->adjust_link(ds, port, phydev);
> >
> > put_device(&phydev->mdio.dev);
> > + } else if (mode == PHY_INTERFACE_MODE_INTERNAL ||
> > + mode == PHY_INTERFACE_MODE_NA) {
>
> Hi Sebastian
>
> I understand what you are trying to do, i've got boards which also
> have back-to-back PHYs for the CPU port. These boards however have the
> strapping correct, so nothing needs doing in software.
What I have is a PCIe intel network card with phy, that is wired to a
mv88e6240 switch. The network card is exposed as normal network device,
so phy is enabled when the interface is brought up. The 'cpu' port
for mv88e6240 has an integrated phy, that needs to be enabled.
Your boards must be different, since mv88e6xxx is being reset during
probe(). So even if the 'cpu' phy was enabled before driver probe(),
it would be disabled afterwards.
> But the way you are doing it is wrong. PHY_INTERFACE_MODE_NA means
> something else has already setup the interface mode, leave it alone.
Ok, I assumed, that PHY_INTERFACE_MODE_NA means "no explicit
configuration found, use implicit configuration". E.g. for
mv88e6xxx the downstream ports are not configured in DT, but
their PHY is enabled.
> PHY_INTERFACE_MODE_INTERNAL means there is some other sort of bus
> between the MAC and the PHY than the normal MII.
>
> What you want to say is that there is a PHY on this port, and that you
> want to configure it to a given fixed configuration, probably 1000
> Full, with auto-neg turned off. This is something completely different
> to a fixed phy, which is used when there is no PHY at all.
That's why I put the new code into
if (of_phy_is_fixed_link(...)) {
<<< old code >>>
} else {
<<< new code >>>
}
I agree, that the function name dsa_port_fixed_link_register_of() is
a bit confusing with the added code. I actually added this to
dsa_cpu_dsa_setup() and with the rebase to current master it ended
up there.
> What state is the PHY in, if you don't have this patch? Is it powered
> down?
The phy is part of mv88e6240, which is being reset during probe.
So the phy is powered down and DSA is not functional except for
phy information of downstream ports. The PCIe network interface
does not detect a carrier.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Faiz Abbas @ 2018-01-03 15:06 UTC (permalink / raw)
To: Marc Kleine-Budde, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <7d857263-14a7-6001-8f13-42d80f757573@pengutronix.de>
Hi,
On Wednesday 03 January 2018 07:55 PM, Marc Kleine-Budde wrote:
> On 01/03/2018 01:39 PM, Faiz Abbas wrote:
>> On Tuesday 02 January 2018 09:37 PM, Marc Kleine-Budde wrote:
>>> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>>>> From: Franklin S Cooper Jr <fcooper@ti.com>
>>>>
>>>> Add support for PM Runtime which is the new way to handle managing clocks.
>>>> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
>>>> management approach in place.
>>>
>>> There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
>>> CONFIG_PM_RUNTIME")
>>
>> Ok. Will change the commit message.
>>
>>>
>>> Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :
>>>
>>>>> Well, I admit it would be nicer if drivers didn't have to worry about
>>>>> whether or not CONFIG_PM was enabled. A slightly cleaner approach
>>>>> from the one outlined above would have the probe routine do this:
>>>>>
>>>>> my_power_up(dev);
>>>>> pm_runtime_set_active(dev);
>>>>> pm_runtime_get_noresume(dev);
>>>>> pm_runtime_enable(dev);
>>
>> This discussion seems to be about cases in which CONFIG_PM is not
>> enabled. CONFIG_PM is always selected in the case of omap devices.
>
> Yes, but in the commit message you state that you need to support
> systems that don't have PM_RUNTIME enabled. The only mainline SoCs I see
> is "arch/arm/boot/dts/sama5d2.dtsi" so far. Please check if they select
> CONFIG_PM, then we can make the driver much simpler.
Actually the old clock management (for hclk which is the interface
clock) is still required as mentioned in the cover letter. Will change
the rather misleading description.
Thanks,
Faiz
>
>>>> PM_RUNTIME is required by OMAP based devices to handle clock management.
>>>> Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
>>>> to work with this driver.
>>>
>>> Who will set the SET_RUNTIME_PM_OPS in this case?
>>
>> It is set with a common SET_RUNTIME_PM_OPS in the case of omap at
>> arch/arm/mach-omap2/omap_device.c:632
>>
>> struct dev_pm_domain omap_device_pm_domain = {
>> .ops = {
>> SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
>> NULL)
>> USE_PLATFORM_PM_SLEEP_OPS
>> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(_od_suspend_noirq,
>> _od_resume_noirq)
>> }
>> };
>>
>>
>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>> [nsekhar@ti.com: handle pm_runtime_get_sync() failure, fix some bugs]
>>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>>> ---
>>>> drivers/net/can/m_can/m_can.c | 38 ++++++++++++++++++++++++++++++++++----
>>>> 1 file changed, 34 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>>>> index f72116e..53e764f 100644
>>>> --- a/drivers/net/can/m_can/m_can.c
>>>> +++ b/drivers/net/can/m_can/m_can.c
>>>> @@ -23,6 +23,7 @@
>>>> #include <linux/of.h>
>>>> #include <linux/of_device.h>
>>>> #include <linux/platform_device.h>
>>>> +#include <linux/pm_runtime.h>
>>>> #include <linux/iopoll.h>
>>>> #include <linux/can/dev.h>
>>>>
>>>> @@ -625,19 +626,33 @@ static int m_can_clk_start(struct m_can_priv *priv)
>>>> {
>>>> int err;
>>>>
>>>> + err = pm_runtime_get_sync(priv->device);
>>>> + if (err) {
>>>> + pm_runtime_put_noidle(priv->device);
>>>
>>> Why do you call this in case of an error?
>>
>> pm_runtime_get_sync() increments the usage count of the device before
>> any error is returned. This needs to be decremented using
>> pm_runtime_put_noidle().
>
> Oh, I'm curious how many drivers don't get this right.
>
> Marc
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
From: Lorenzo Bianconi @ 2018-01-03 15:06 UTC (permalink / raw)
To: Guillaume Nault; +Cc: James Chapman, David S. Miller, netdev, Hangbin Liu
In-Reply-To: <20180103141635.GD1402@alphalink.fr>
> On Tue, Jan 02, 2018 at 08:28:03PM +0100, Lorenzo Bianconi wrote:
>> Perhaps I am little bit polarized on UABI issue, but I was rethinking
>> about it and maybe removing offset parameter would lead to an
>> interoperability issue for device running L2TPv3 since offset
>> parameter is there and it is not a nope.
>> Please consider this setup:
>> - 2 endpoint running L2TPv3, the first running net-next and the second
>> running 4.14
>> - both endpoint are configured using iproute2 in this way:
>>
>> - ip l2tp add tunnel local <ip0> remote <ip1> tunnel_id <id0>
>> peer_tunnel_id <id1> udp_sport <p0> udp_dport <p1>
>> - ip l2tp add tunnel local <ip1> remote <ip0> tunnel_id <id1>
>> peer_tunnel_id <id0> udp_sport <p1> udp_dport <p0>
>> - ip l2tp add session name l2tp0 tunnel_id <id0> session_id <s0>
>> peer_session_id <s1> offset 8
>> - ip l2tp add session name l2tp0 tunnel_id <id1> session_id <s1>
>> peer_session_id <s0> offset 8
>>
>> Can we assume offset is never used for L2TPv3?
>>
> That's what I think. You're right worrying about ABI issues. And I
> wouldn't dare proposing such a removal if I had doubts about breaking a
> user setup.
>
> Considering the lack of use cases and the absence of interoperability
> of this feature, I hardly can imagine it being used.
> But it's not only that: the feature has been buggy for years without
> anyone noticing. And this bug wasn't difficult to spot (one just needs
> to look at an L2TPv3 header in a network packet dump).
>
> It's really the combination of these three issues (buggy, no use case
> and not producing valid L2TPv3 frames) that makes me propose a removal.
Hi Guillaume, James,
I agree to remove offset parameter in this case. What about (as
already suggested by James) to take into account possible alignment
issues with previous version of L2TPv3 protocol using 'L2 specific
sublayer'?
I guess, on the kernel side (we will need to patch iproute2 on
userspace side), we need just to properly initialized the 'l2specific'
field to 0 since otherwise we will have the same memleak issue there
if assume we can have l2specific_len != {0,4}.
Moreover does it worth to add some sanity checks in netlink code to
enforce the relation between l2specific_len and l2specific_type? At
the moment there are no guarantee that if l2specific_type is set to
L2TP_L2SPECTYPE_DEFAULT, l2specific_len will be grater or equal than
4.
Regards,
Lorenzo
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: dsa: mv88e6xxx: Hold mutex while doing stats operations
From: Andrew Lunn @ 2018-01-03 15:02 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, Florian Fainelli, netdev, Russell King
In-Reply-To: <878tdfdncl.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Jan 03, 2018 at 09:32:42AM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > -static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
> > +static int _mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
> > {
> > struct mv88e6xxx_chip *chip = ds->priv;
> >
> > @@ -702,6 +706,19 @@ static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
> > return 0;
> > }
>
> We worked to remove the old underscore prefix convention. Please don't
> add it back... Simply rework the return statements of
> mv88e6xxx_get_sset_count to lock/unlock there.
Hi Vivien
That makes mv88e6xxx_get_sset_count quite complex, making it error
prone. Doing the locking in a separate function makes is very clear
the lock is held and then correctly released. So i will just rename
_mv88e6xxx_get_sset_count() to mv88e6xxx_get_sset_count_locked()
Andrew
^ 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