* Re: [RFC PATCH] dt-binding: net: sfp binding documentation
From: Russell King - ARM Linux @ 2017-08-23 13:56 UTC (permalink / raw)
To: Rob Herring
Cc: Baruch Siach, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S . Miller, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqL_7gG8FSEJDXu=37DFpHjfLhQuUhPFRKcScYTzM4cNyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 21, 2017 at 02:10:33PM -0500, Rob Herring wrote:
> On Sun, Aug 20, 2017 at 5:28 AM, Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > Add device-tree binding documentation SFP transceivers. Support for SFP
> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> >
> > Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > ---
> >
> > The SFP driver is on net-next.
> >
> > Not sure about the rate-select-gpio property name. The SFP+ standard
> > (not supported yet) uses two signals, RS0 and RS1. RS0 is compatible
> > with the SFP rate select signal, while RS1 controls the Tx rate.
> > ---
> > Documentation/devicetree/bindings/net/sff-sfp.txt | 24 +++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/sff-sfp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/sff-sfp.txt b/Documentation/devicetree/bindings/net/sff-sfp.txt
> > new file mode 100644
> > index 000000000000..f0c27bc3925e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/sff-sfp.txt
> > @@ -0,0 +1,24 @@
> > +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> > +Transceiver
> > +
> > +Required properties:
> > +
> > +- compatible : must be "sff,sfp"
>
> Need to document "sff" vendor prefix.
>
> Kind of a short name, but I guess it is sufficient. Are there
> revisions of the standard (not SFP+) or more than one form factor (I
> don't recall any)?
The standards get revised and reorganised, so you can't really name any
particular standard. SFP+ is a supplement to SFP, and I suspect that's
going to continue into the future.
> > +
> > +Optional Properties:
> > +
> > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > + interface
>
> Why not a child of the i2c bus it is on? IOW, what should this be a child of?
What reg= value would you use to identify it? There's no particular
I2C bus address. There's an EEPROM on the actual module, and there
may be a PHY on the I2C bus (some PHYs include I2C as an alternative
way to speak to them other than MDIO.)
I2C couldn't probe these as they are effectively hotplugged.
However, there's also the question about why it should be a child of
the I2C bus - the I2C bus is just a means of communicating with and
identifying the module. You could equally argue that it should be
a child of the GPIO controller, because that's how it's controlled.
You could also argue that it should be a child of the ethernet
interface, since that's the main data path.
> > +
> > +- moddef0-gpio : phandle of the MOD-DEF0 (AKA Mod_ABS) module presence input
> > + gpio signal
>
> mod-def0-gpios?
It all depends on the standard you read. Some call it MOD_DEF0, Mod-DEF0,
Mod_ABS, and some call it MOD-DEF0. And confusingly, some standards call
the binary combination of the three MOD-DEF signals "MOD-DEF 0"...
"MOD-DEF 7". These signals come from the GBIC module era. It's something
of a mess.
> > +
> > +- los-gpio : phandle of the Receiver Loss of Signal Indication input gpio
> > + signal
> > +
> > +- tx-fault-gpio : phandle of the Module Transmitter Fault input gpio signal
> > +
> > +- tx-disable-gpio : phandle of the Transmitter Disable output gpio signal
> > +
> > +- rate-select-gpio : phandle of the Rx Signaling Rate Select (AKA RS0) output
> > + gpio
>
> -gpios is the preferred form for all of these.
Even if there's only _one_ - using the plural leads one to think that
you can list many GPIOs, which is not correct here.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Something hitting my total number of connections to the server
From: Neal Cardwell @ 2017-08-23 13:35 UTC (permalink / raw)
To: Akshat Kakkar; +Cc: Eric Dumazet, David Laight, netdev
In-Reply-To: <CAA5aLPgA+YzavA8tw6uqfR8d6r058OymJOE+jevVmDA2Ar21rg@mail.gmail.com>
On Wed, Aug 23, 2017 at 1:08 AM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
>
> On Tue, Aug 22, 2017 at 5:58 PM, Neal Cardwell <ncardwell@google.com> wrote:
> > On Tue, Aug 22, 2017 at 1:42 AM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> >> There are multiple hosts/clients. All are mainly windows based.
> >>
> >> Timestamp is not used as my clients mainly are windows based and in
> >> that it tcp timestamp is by defauly disabled.
> > ...
> >> net.ipv4.tcp_tw_reuse=1
> >> net.ipv4.tcp_tw_recycle=1
> >
> > I suspect the problem is there. The net.ipv4.tcp_tw_recycle setting
> > should be 0. Running with the value 1 is known to cause buggy behavior
> > related to TCP timestamps, and that feature has been removed in kernel
> > v4.12.
> >
> > Can you please re-run your tests with net.ipv4.tcp_tw_recycle=0 or a
> > newer kernel?
> >
> > neal
>
> Thanks for your reply.
>
> I understand that.
>
> But my point is, though tcp timestamp is enabled on the server, but as
> client is not using it ... so how come this _bug_ (if any) is
> triggered in first place.
You mention "clients mainly are windows based". if they are only
"mainly" Windows-based, and some are of other OSes that do use TCP
timestamps, and the remote address is the same for TCP-timestamp-using
and non-TCP-timestamp-using clients, then running with timestamps
enabled on the server could tickle the bugs in pre-4.12 kernels that
save info from TCP-timestamp-using connections and erroneously try to
use that info to validate non-TCP-timestamp-using connections.
But the main point is that the configuration you cited
(net.ipv4.tcp_tw_recycle=1) is an unsupported configuration with known
bugs. The best resolution would be to just run with
net.ipv4.tcp_tw_recycle=0. It's not worth digging any further unless
you run with net.ipv4.tcp_tw_recycle=0 or a kernel that is v4.12 or
later and still have problems.
Hope that helps,
neal
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address when connecting to the PHY
From: Andrew Lunn @ 2017-08-23 13:34 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, davem@davemloft.net, jason@lakedaemon.net,
gregory.clement@free-electrons.com,
sebastian.hesselbarth@gmail.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, mw@semihalf.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <7dc117f56c284081b791bceb588a8aa1@IL-EXCH01.marvell.com>
> This feature work only for Out-of-Band Auto-Negotiation in SGMII Mode.
> Current GoP(MAC) code configure SGMII In-band Auto-Negotiation performed by the PCS layer
> without PHY polling.
Hi Stefan
So there is no need to configure the address then, leave PHY polling
turned off and we avoid all the issues.
Andrew
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address when connecting to the PHY
From: Stefan Chulski @ 2017-08-23 13:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem@davemloft.net, jason@lakedaemon.net,
gregory.clement@free-electrons.com,
sebastian.hesselbarth@gmail.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, mw@semihalf.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170823123424.GA28612@lunn.ch>
> In order to safely read/write the PHY, you need to hold the PHY mutex.
> Unless the hardware is very smart, please don't enable this. Let the phylib and
> the appropriate PHY driver do the work.
>
> Andrew
Hi Andrew,
This feature work only for Out-of-Band Auto-Negotiation in SGMII Mode.
Current GoP(MAC) code configure SGMII In-band Auto-Negotiation performed by the PCS layer
without PHY polling.
Regards,
Stefan.
^ permalink raw reply
* Re: [RFC PATCH] dt-binding: net: sfp binding documentation
From: Andrew Lunn @ 2017-08-23 13:10 UTC (permalink / raw)
To: Baruch Siach
Cc: Rob Herring, Mark Rutland, Florian Fainelli, David S . Miller,
Russell King, netdev, devicetree@vger.kernel.org
In-Reply-To: <20170823121653.xha2obe4ewlhwyvh@sapphire.tkos.co.il>
On Wed, Aug 23, 2017 at 03:16:53PM +0300, Baruch Siach wrote:
> Hi Rob,
>
> On Mon, Aug 21, 2017 at 02:10:33PM -0500, Rob Herring wrote:
> > On Sun, Aug 20, 2017 at 5:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > Add device-tree binding documentation SFP transceivers. Support for SFP
> > > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > ---
> > >
> > > The SFP driver is on net-next.
>
> [...]
>
> > > +Optional Properties:
> > > +
> > > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > > + interface
> >
> > Why not a child of the i2c bus it is on? IOW, what should this be a child of?
>
> As I understand form the code the ID of the SFP i2c slave is derived from the
> Ethernet PHY 'reg' property. The PHY node's 'sfp' property points to a phandle
> of the sff,sfp node.
Hi Rob
The SFP module uses multiple addresses on the i2c bus. 0x50 is
something like an EEPROM, but some of the content is
dynamic. Depending of the version of the standard, it can also use
0x51 for additional information. If the SPF module contains a copper
PHY, it also uses another address on the i2c bus for the standard
copper PHY registers.
An SFP module does not fit the usual I2C client model, since it is a
collection of interconnected i2c clients in one package.
Andrew
^ permalink raw reply
* Re: [PATCH net] net/sock: allow the user to set negative peek offset
From: Willem de Bruijn @ 2017-08-23 13:01 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, David S. Miller, Matthew Dawson, Sam Kumar
In-Reply-To: <64e676e59d203f13cd326c3b0cf6b05287b69e1b.1503481941.git.pabeni@redhat.com>
On Wed, Aug 23, 2017 at 5:57 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> This is necessary to allow the user to disable peeking with
> offset once it's enabled.
> Unix sockets already allow the above, with this patch we
> permit it for udp[6] sockets, too.
>
> Fixes: 627d2d6b5500 ("udp: enable MSG_PEEK at non-zero offset")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Willem de Bruijn <willemb@google.com>
I don't think that the existing behavior is buggy, per se. So this
could also go to net-next.
^ permalink raw reply
* [PATCH] ss: fix help/man TCP-STATE description for listening
From: Andreas Henriksson @ 2017-08-23 12:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Andreas Henriksson
There's some misleading information in --help and ss(8) manpage about
TCP-STATE named 'listen'.
ss doesn't know such a state, but it knows 'listening' state.
$ ss -tua state listen
ss: wrong state name: listen
$ ss -tua state listening
[...]
Addresses: https://bugs.debian.org/872990
Reported-by: Pavel Lyulchenko <p.lyulchenko@gmail.com>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
man/man8/ss.8 | 4 ++--
misc/ss.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 81de69de..3bec97f0 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -153,14 +153,14 @@ Available identifiers are:
All standard TCP states:
.BR established ", " syn-sent ", " syn-recv ", " fin-wait-1 ", " fin-wait-2 ", " time-wait ", " closed ", " close-wait ", " last-ack ", "
-.BR listen " and " closing.
+.BR listening " and " closing.
.B all
- for all the states
.B connected
- all the states except for
-.BR listen " and " closed
+.BR listening " and " closed
.B synchronized
- all the
diff --git a/misc/ss.c b/misc/ss.c
index 34c6da54..c197e075 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -3922,11 +3922,11 @@ static void _usage(FILE *dest)
" -F, --filter=FILE read filter information from FILE\n"
" FILTER := [ state STATE-FILTER ] [ EXPRESSION ]\n"
" STATE-FILTER := {all|connected|synchronized|bucket|big|TCP-STATES}\n"
-" TCP-STATES := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|closed|close-wait|last-ack|listen|closing}\n"
+" TCP-STATES := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|closed|close-wait|last-ack|listening|closing}\n"
" connected := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}\n"
" synchronized := {established|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}\n"
" bucket := {syn-recv|time-wait}\n"
-" big := {established|syn-sent|fin-wait-{1,2}|closed|close-wait|last-ack|listen|closing}\n"
+" big := {established|syn-sent|fin-wait-{1,2}|closed|close-wait|last-ack|listening|closing}\n"
);
}
--
2.11.0
^ permalink raw reply related
* [PATCH] net/mlx5e: make mlx5e_profile const
From: Bhumika Goyal @ 2017-08-23 12:52 UTC (permalink / raw)
To: julia.lawall, saeedm, matanb, leonro, netdev, linux-rdma,
linux-kernel
Cc: Bhumika Goyal
Make this const as it is only passed as an argument to the function
mlx5e_create_netdev and the corresponding argument is of type const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 45c088c..45e03c4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -924,7 +924,7 @@ static int mlx5e_get_rep_max_num_channels(struct mlx5_core_dev *mdev)
return MLX5E_PORT_REPRESENTOR_NCH;
}
-static struct mlx5e_profile mlx5e_rep_profile = {
+static const struct mlx5e_profile mlx5e_rep_profile = {
.init = mlx5e_init_rep,
.init_rx = mlx5e_init_rep_rx,
.cleanup_rx = mlx5e_cleanup_rep_rx,
--
1.9.1
^ permalink raw reply related
* [PATCH] net/mlx4_core: make mlx4_profile const
From: Bhumika Goyal @ 2017-08-23 12:47 UTC (permalink / raw)
To: julia.lawall, tariqt, netdev, linux-rdma, linux-kernel; +Cc: Bhumika Goyal
Make these const as they are only used in a copy operation.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 541ce9e..43fb2eb 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -121,7 +121,7 @@
DRV_NAME ": Mellanox ConnectX core driver v"
DRV_VERSION "\n";
-static struct mlx4_profile default_profile = {
+static const struct mlx4_profile default_profile = {
.num_qp = 1 << 18,
.num_srq = 1 << 16,
.rdmarc_per_qp = 1 << 4,
@@ -131,7 +131,7 @@
.num_mtt = 1 << 20, /* It is really num mtt segements */
};
-static struct mlx4_profile low_mem_profile = {
+static const struct mlx4_profile low_mem_profile = {
.num_qp = 1 << 17,
.num_srq = 1 << 6,
.rdmarc_per_qp = 1 << 4,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/3] constify dsa_switch_ops
From: Andrew Lunn @ 2017-08-23 12:45 UTC (permalink / raw)
To: Arvind Yadav; +Cc: vivien.didelot, f.fainelli, linux-kernel, netdev
In-Reply-To: <1503483419-21780-1-git-send-email-arvind.yadav.cs@gmail.com>
On Wed, Aug 23, 2017 at 03:46:56PM +0530, Arvind Yadav wrote:
> dsa_switch_ops are not supposed to change at runtime. All functions
> working with dsa_switch_ops provided by <net/dsa.h> work with
> const dsa_switch_ops. So mark the non-const structs as const.
>
> Arvind Yadav (3):
> [PATCH 1/3] net: dsa: loop: constify dsa_switch_ops
> [PATCH 2/3] net: dsa: lan9303: constify dsa_switch_ops
> [PATCH 3/3] net: dsa: mt7530: constify dsa_switch_ops
For the whole series:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-08-23 12:42 UTC (permalink / raw)
To: Pavel Machek
Cc: Woojung.Huh, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, Tristram.Ha
In-Reply-To: <20170823090941.GA27570@amd>
> Any ideas how to do the work in a way to minimize code duplication are
> welcome...
A lot depends on how much duplication there is. mv88e6xxx uses a set
of function points per chip variant. Another option is to put the
common code into a library, and have two drivers. Or if it is the same
registers, but at different locations, you can add a translation
function, which is what i think the b53 driver does.
Andrew
^ permalink raw reply
* [PATCH] wireless: ipw2x00: make iw_handler_def const
From: Bhumika Goyal @ 2017-08-23 12:36 UTC (permalink / raw)
To: julia.lawall, stas.yakovlev, kvalo, linux-wireless, netdev,
linux-kernel
Cc: Bhumika Goyal
Make these const as they are only stored in the const field of a
net_device structure.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 4 ++--
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 77f3f92..19c442c 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -340,7 +340,7 @@ static int ipw2100_ucode_download(struct ipw2100_priv *priv,
struct ipw2100_fw *fw);
static void ipw2100_wx_event_work(struct work_struct *work);
static struct iw_statistics *ipw2100_wx_wireless_stats(struct net_device *dev);
-static struct iw_handler_def ipw2100_wx_handler_def;
+static const struct iw_handler_def ipw2100_wx_handler_def;
static inline void read_register(struct net_device *dev, u32 reg, u32 * val)
{
@@ -8273,7 +8273,7 @@ static struct iw_statistics *ipw2100_wx_wireless_stats(struct net_device *dev)
return (struct iw_statistics *)NULL;
}
-static struct iw_handler_def ipw2100_wx_handler_def = {
+static const struct iw_handler_def ipw2100_wx_handler_def = {
.standard = ipw2100_wx_handlers,
.num_standard = ARRAY_SIZE(ipw2100_wx_handlers),
.num_private = ARRAY_SIZE(ipw2100_private_handler),
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index c311b1a..7194a18 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -10008,7 +10008,7 @@ enum {
#endif
};
-static struct iw_handler_def ipw_wx_handler_def = {
+static const struct iw_handler_def ipw_wx_handler_def = {
.standard = ipw_wx_handlers,
.num_standard = ARRAY_SIZE(ipw_wx_handlers),
.num_private = ARRAY_SIZE(ipw_priv_handler),
--
1.9.1
^ permalink raw reply related
* Re: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address when connecting to the PHY
From: Andrew Lunn @ 2017-08-23 12:34 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, davem@davemloft.net, jason@lakedaemon.net,
gregory.clement@free-electrons.com,
sebastian.hesselbarth@gmail.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, mw@semihalf.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <f6d8907b057241c7a72da0a0255cfd23@IL-EXCH01.marvell.com>
> 2. Auto-Negotiation with PHY devices connected to the GMAC ports.
> The device uses a standard master Serial Management Interface for reading from/writing to the PHY
> registers. In addition, the PHY polling unit performs Auto-Negotiation status update with PHY devices attached
> to the Network ports via the Master SMI Interface.
> The device polls the Status register of each PHY in a round-robin manner.
> If the device detects a change in the link from down to up on 1 of the ports, it performs a series of
> register reads from the PHY and updates the Auto-Negotiation results in the device's registers. The
> Port MAC Status register is updated with these results only if Auto-Negotiation is enabled.
Hi Stefan
That is what i was afraid off.
How clever is this phy polling hardware? e.g. Say somebody reads the
PHY temperature sensor:
commit 0b04680fdae464ee51409b8cb36005f6ef8bd689
Author: Andrew Lunn <andrew@lunn.ch>
Date: Fri Jan 20 01:37:49 2017 +0100
phy: marvell: Add support for temperature sensor
Some Marvell PHYs have an inbuilt temperature sensor. Add hwmon
support for this sensor.
There are two different variants. The simpler, older chips have a 5
degree accuracy. The newer devices have 1 degree accuracy.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This requires changing the PHY page to 0x1a. Any reads the polling
unit does at that time are going to get registers from page 0x1a, not
0x0.
And there are other examples where the page may change,
e.g. configuring WOL, LEDs. Cable test is not yet supported, but it is
on my todo list.
In order to safely read/write the PHY, you need to hold the PHY mutex.
Unless the hardware is very smart, please don't enable this. Let the
phylib and the appropriate PHY driver do the work.
Andrew
^ permalink raw reply
* Re: [PATCH][V2][netdev-next] gre: remove duplicated assignment of iph
From: Nikolay Aleksandrov @ 2017-08-23 12:26 UTC (permalink / raw)
To: Colin King, William Tu, David S . Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netdev
Cc: linux-kernel
In-Reply-To: <20170823115948.19884-1-colin.king@canonical.com>
On 23/08/17 14:59, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> iph is being assigned the same value twice; remove the redundant
> first assignment. (Thanks to Nikolay Aleksandrov for pointing out
> that the first asssignment should be removed and not the second)
>
> Fixes warning:
> net/ipv4/ip_gre.c:265:2: warning: Value stored to 'iph' is never read
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/ipv4/ip_gre.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 6e8a62289e03..161326f7f10b 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -262,7 +262,6 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> int len;
>
> itn = net_generic(net, erspan_net_id);
> - iph = ip_hdr(skb);
> len = gre_hdr_len + sizeof(*ershdr);
>
> if (unlikely(!pskb_may_pull(skb, len)))
>
LGTM,
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [RFC PATCH] dt-binding: net: sfp binding documentation
From: Baruch Siach @ 2017-08-23 12:16 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, David S . Miller,
Russell King, netdev, devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqL_7gG8FSEJDXu=37DFpHjfLhQuUhPFRKcScYTzM4cNyg@mail.gmail.com>
Hi Rob,
On Mon, Aug 21, 2017 at 02:10:33PM -0500, Rob Herring wrote:
> On Sun, Aug 20, 2017 at 5:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > Add device-tree binding documentation SFP transceivers. Support for SFP
> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> >
> > The SFP driver is on net-next.
[...]
> > +Optional Properties:
> > +
> > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > + interface
>
> Why not a child of the i2c bus it is on? IOW, what should this be a child of?
As I understand form the code the ID of the SFP i2c slave is derived from the
Ethernet PHY 'reg' property. The PHY node's 'sfp' property points to a phandle
of the sff,sfp node.
It is also possible for the 'sfp' property to appear directly in the Ethernet
device node.
Quoting RMK from merge commit 234709336b8 (net-next):
To add to the complexity, SFP modules can be connected in at least
two places:
1. Directly to the serdes output of a MAC with no intervening PHY.
For example:
mvneta ----> SFP socket
2. To a PHY, for example:
mvpp2 ---> PHY ---> copper
|
`-----> SFP socket
This code supports both setups, although it's not fully implemented
with scenario (2).
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH][V2][netdev-next] gre: remove duplicated assignment of iph
From: Colin King @ 2017-08-23 11:59 UTC (permalink / raw)
To: William Tu, David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
iph is being assigned the same value twice; remove the redundant
first assignment. (Thanks to Nikolay Aleksandrov for pointing out
that the first asssignment should be removed and not the second)
Fixes warning:
net/ipv4/ip_gre.c:265:2: warning: Value stored to 'iph' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/ipv4/ip_gre.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 6e8a62289e03..161326f7f10b 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -262,7 +262,6 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
int len;
itn = net_generic(net, erspan_net_id);
- iph = ip_hdr(skb);
len = gre_hdr_len + sizeof(*ershdr);
if (unlikely(!pskb_may_pull(skb, len)))
--
2.14.1
^ permalink raw reply related
* Re: [PATCH][netdev-next] gre: remove duplicated assignment of iph
From: Nikolay Aleksandrov @ 2017-08-23 11:52 UTC (permalink / raw)
To: Colin King, David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netdev
Cc: kernel-janitors, linux-kernel, William Tu
In-Reply-To: <20170823111305.19185-1-colin.king@canonical.com>
On 23/08/17 14:13, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> iph is being assigned the same value twice; remove the redundant
> second assignment.
>
> Fixes warning:
> net/ipv4/ip_gre.c:265:2: warning: Value stored to 'iph' is never read
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/ipv4/ip_gre.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 6e8a62289e03..6b3e7c99a3b6 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -268,7 +268,6 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> if (unlikely(!pskb_may_pull(skb, len)))
> return -ENOMEM;
>
> - iph = ip_hdr(skb);
> ershdr = (struct erspanhdr *)(skb->data + gre_hdr_len);
>
> /* The original GRE header does not have key field,
>
This one looks like a correct assignment, I'd remove the previous one because
pskb_may_pull may change the header pointers and the previously assigned iph might
become wrong.
Also add the author of the code to the CC list.
^ permalink raw reply
* Re: [PATCH 0/2] net: Fix crashes due to activity during suspend
From: Geert Uytterhoeven @ 2017-08-23 11:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Geert Uytterhoeven, David S . Miller, Steve Glendinning,
Andrew Lunn, Lukas Wunner, Rafael J . Wysocki,
netdev@vger.kernel.org, Linux PM list, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <757f672b-d3cf-9189-0533-cb45e325c6b8@gmail.com>
Hi Florian,
On Tue, Aug 22, 2017 at 8:49 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 08/22/2017 11:37 AM, Geert Uytterhoeven wrote:
>> If an Ethernet device is used while the device is suspended, the system may
>> crash.
>>
>> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
>> driven by a PM controlled clock. If the Ethernet registers are accessed
>> while the clock is not running, the system will crash with an imprecise
>> external abort.
>>
>> This patch series fixes two of such crashes:
>> 1. The first patch prevents the PHY polling state machine from accessing
>> PHY registers while a device is suspended,
>> 2. The second patch prevents the net core from trying to transmit packets
>> when an smsc911x device is suspended.
>>
>> Both crashes can be reproduced on sh73a0/kzm9g and r8a73a4/ape6evm during
>> s2ram (rarely), or by using pm_test (more likely to trigger):
>>
>> # echo 0 > /sys/module/printk/parameters/console_suspend
>> # echo platform > /sys/power/pm_test
>> # echo mem > /sys/power/state
>>
>> With this series applied, my test systems survive a loop of 100 test
>> suspends.
>
> It seems to me like part, if not the entire problem is that smsc91xx's
> suspend and resume functions are way too simplistic and absolutely do
> not manage the PHY during suspend/resume, the PHY state machine is not
> even stopped, so of course, this will cause bus errors if you access
> those registers.
>
> You are addressing this as part of patch 2, but this seems to me like
> this is still a bit incomplete and you'd need at least phy_stop() and/or
> phy_suspend() (does a power down of the PHY) and phy_start() and/or
> phy_resume() calls to complete the PHY state machine shutdown during
> suspend.
>
> Have you tried that?
Unfortunately that doesn't help.
In state PHY_HALTED, the PHY state machine still calls the .adjust_link()
callback while the device is suspended.
Do you have a clue? This is too far beyond my phy-foo...
Thanks!
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
* [PATCH net] sctp: Avoid out-of-bounds reads from address storage
From: Stefano Brivio @ 2017-08-23 11:27 UTC (permalink / raw)
To: David S . Miller, netdev, linux-kernel, stable
Cc: Xin Long, Vlad Yasevich, Neil Horman, linux-sctp
inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy
sizeof(sockaddr_storage) bytes to fill in sockaddr structs used
to export diagnostic information to userspace.
However, the memory allocated to store sockaddr information is
smaller than that and depends on the address family, so we leak
up to 100 uninitialized bytes to userspace. Just use the size of
the source structs instead, in all the three cases this is what
userspace expects. Zero out the remaining memory.
Unused bytes (i.e. when IPv4 addresses are used) in source
structs sctp_sockaddr_entry and sctp_transport are already
cleared by sctp_add_bind_addr() and sctp_transport_new(),
respectively.
Noticed while testing KASAN-enabled kernel with 'ss':
[ 2326.885243] BUG: KASAN: slab-out-of-bounds in inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag] at addr ffff881be8779800
[ 2326.896800] Read of size 128 by task ss/9527
[ 2326.901564] CPU: 0 PID: 9527 Comm: ss Not tainted 4.11.0-22.el7a.x86_64 #1
[ 2326.909236] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
[ 2326.917585] Call Trace:
[ 2326.920312] dump_stack+0x63/0x8d
[ 2326.924014] kasan_object_err+0x21/0x70
[ 2326.928295] kasan_report+0x288/0x540
[ 2326.932380] ? inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag]
[ 2326.938500] ? skb_put+0x8b/0xd0
[ 2326.942098] ? memset+0x31/0x40
[ 2326.945599] check_memory_region+0x13c/0x1a0
[ 2326.950362] memcpy+0x23/0x50
[ 2326.953669] inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag]
[ 2326.959596] ? inet_diag_msg_sctpasoc_fill+0x460/0x460 [sctp_diag]
[ 2326.966495] ? __lock_sock+0x102/0x150
[ 2326.970671] ? sock_def_wakeup+0x60/0x60
[ 2326.975048] ? remove_wait_queue+0xc0/0xc0
[ 2326.979619] sctp_diag_dump+0x44a/0x760 [sctp_diag]
[ 2326.985063] ? sctp_ep_dump+0x280/0x280 [sctp_diag]
[ 2326.990504] ? memset+0x31/0x40
[ 2326.994007] ? mutex_lock+0x12/0x40
[ 2326.997900] __inet_diag_dump+0x57/0xb0 [inet_diag]
[ 2327.003340] ? __sys_sendmsg+0x150/0x150
[ 2327.007715] inet_diag_dump+0x4d/0x80 [inet_diag]
[ 2327.012979] netlink_dump+0x1e6/0x490
[ 2327.017064] __netlink_dump_start+0x28e/0x2c0
[ 2327.021924] inet_diag_handler_cmd+0x189/0x1a0 [inet_diag]
[ 2327.028045] ? inet_diag_rcv_msg_compat+0x1b0/0x1b0 [inet_diag]
[ 2327.034651] ? inet_diag_dump_compat+0x190/0x190 [inet_diag]
[ 2327.040965] ? __netlink_lookup+0x1b9/0x260
[ 2327.045631] sock_diag_rcv_msg+0x18b/0x1e0
[ 2327.050199] netlink_rcv_skb+0x14b/0x180
[ 2327.054574] ? sock_diag_bind+0x60/0x60
[ 2327.058850] sock_diag_rcv+0x28/0x40
[ 2327.062837] netlink_unicast+0x2e7/0x3b0
[ 2327.067212] ? netlink_attachskb+0x330/0x330
[ 2327.071975] ? kasan_check_write+0x14/0x20
[ 2327.076544] netlink_sendmsg+0x5be/0x730
[ 2327.080918] ? netlink_unicast+0x3b0/0x3b0
[ 2327.085486] ? kasan_check_write+0x14/0x20
[ 2327.090057] ? selinux_socket_sendmsg+0x24/0x30
[ 2327.095109] ? netlink_unicast+0x3b0/0x3b0
[ 2327.099678] sock_sendmsg+0x74/0x80
[ 2327.103567] ___sys_sendmsg+0x520/0x530
[ 2327.107844] ? __get_locked_pte+0x178/0x200
[ 2327.112510] ? copy_msghdr_from_user+0x270/0x270
[ 2327.117660] ? vm_insert_page+0x360/0x360
[ 2327.122133] ? vm_insert_pfn_prot+0xb4/0x150
[ 2327.126895] ? vm_insert_pfn+0x32/0x40
[ 2327.131077] ? vvar_fault+0x71/0xd0
[ 2327.134968] ? special_mapping_fault+0x69/0x110
[ 2327.140022] ? __do_fault+0x42/0x120
[ 2327.144008] ? __handle_mm_fault+0x1062/0x17a0
[ 2327.148965] ? __fget_light+0xa7/0xc0
[ 2327.153049] __sys_sendmsg+0xcb/0x150
[ 2327.157133] ? __sys_sendmsg+0xcb/0x150
[ 2327.161409] ? SyS_shutdown+0x140/0x140
[ 2327.165688] ? exit_to_usermode_loop+0xd0/0xd0
[ 2327.170646] ? __do_page_fault+0x55d/0x620
[ 2327.175216] ? __sys_sendmsg+0x150/0x150
[ 2327.179591] SyS_sendmsg+0x12/0x20
[ 2327.183384] do_syscall_64+0xe3/0x230
[ 2327.187471] entry_SYSCALL64_slow_path+0x25/0x25
[ 2327.192622] RIP: 0033:0x7f41d18fa3b0
[ 2327.196608] RSP: 002b:00007ffc3b731218 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 2327.205055] RAX: ffffffffffffffda RBX: 00007ffc3b731380 RCX: 00007f41d18fa3b0
[ 2327.213017] RDX: 0000000000000000 RSI: 00007ffc3b731340 RDI: 0000000000000003
[ 2327.220978] RBP: 0000000000000002 R08: 0000000000000004 R09: 0000000000000040
[ 2327.228939] R10: 00007ffc3b730f30 R11: 0000000000000246 R12: 0000000000000003
[ 2327.236901] R13: 00007ffc3b731340 R14: 00007ffc3b7313d0 R15: 0000000000000084
[ 2327.244865] Object at ffff881be87797e0, in cache kmalloc-64 size: 64
[ 2327.251953] Allocated:
[ 2327.254581] PID = 9484
[ 2327.257215] save_stack_trace+0x1b/0x20
[ 2327.261485] save_stack+0x46/0xd0
[ 2327.265179] kasan_kmalloc+0xad/0xe0
[ 2327.269165] kmem_cache_alloc_trace+0xe6/0x1d0
[ 2327.274138] sctp_add_bind_addr+0x58/0x180 [sctp]
[ 2327.279400] sctp_do_bind+0x208/0x310 [sctp]
[ 2327.284176] sctp_bind+0x61/0xa0 [sctp]
[ 2327.288455] inet_bind+0x5f/0x3a0
[ 2327.292151] SYSC_bind+0x1a4/0x1e0
[ 2327.295944] SyS_bind+0xe/0x10
[ 2327.299349] do_syscall_64+0xe3/0x230
[ 2327.303433] return_from_SYSCALL_64+0x0/0x6a
[ 2327.308194] Freed:
[ 2327.310434] PID = 4131
[ 2327.313065] save_stack_trace+0x1b/0x20
[ 2327.317344] save_stack+0x46/0xd0
[ 2327.321040] kasan_slab_free+0x73/0xc0
[ 2327.325220] kfree+0x96/0x1a0
[ 2327.328530] dynamic_kobj_release+0x15/0x40
[ 2327.333195] kobject_release+0x99/0x1e0
[ 2327.337472] kobject_put+0x38/0x70
[ 2327.341266] free_notes_attrs+0x66/0x80
[ 2327.345545] mod_sysfs_teardown+0x1a5/0x270
[ 2327.350211] free_module+0x20/0x2a0
[ 2327.354099] SyS_delete_module+0x2cb/0x2f0
[ 2327.358667] do_syscall_64+0xe3/0x230
[ 2327.362750] return_from_SYSCALL_64+0x0/0x6a
[ 2327.367510] Memory state around the buggy address:
[ 2327.372855] ffff881be8779700: fc fc fc fc 00 00 00 00 00 00 00 00 fc fc fc fc
[ 2327.380914] ffff881be8779780: fb fb fb fb fb fb fb fb fc fc fc fc 00 00 00 00
[ 2327.388972] >ffff881be8779800: 00 00 00 00 fc fc fc fc fb fb fb fb fb fb fb fb
[ 2327.397031] ^
[ 2327.401792] ffff881be8779880: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[ 2327.409850] ffff881be8779900: 00 00 00 00 00 04 fc fc fc fc fc fc 00 00 00 00
[ 2327.417907] ==================================================================
This fixes CVE-2017-7558.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1480266
Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
Cc: <stable@vger.kernel.org> # 4.7+
Cc: Xin Long <lucien.xin@gmail.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
net/sctp/sctp_diag.c | 7 +++++--
net/sctp/socket.c | 3 +--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index 9a647214a91e..e99518e79b52 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -70,7 +70,8 @@ static int inet_diag_msg_sctpladdrs_fill(struct sk_buff *skb,
info = nla_data(attr);
list_for_each_entry_rcu(laddr, address_list, list) {
- memcpy(info, &laddr->a, addrlen);
+ memcpy(info, &laddr->a, sizeof(laddr->a));
+ memset(info + sizeof(laddr->a), 0, addrlen - sizeof(laddr->a));
info += addrlen;
}
@@ -93,7 +94,9 @@ static int inet_diag_msg_sctpaddrs_fill(struct sk_buff *skb,
info = nla_data(attr);
list_for_each_entry(from, &asoc->peer.transport_addr_list,
transports) {
- memcpy(info, &from->ipaddr, addrlen);
+ memcpy(info, &from->ipaddr, sizeof(from->ipaddr));
+ memset(info + sizeof(from->ipaddr), 0,
+ addrlen - sizeof(from->ipaddr));
info += addrlen;
}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 1db478e34520..8d760863bc41 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4538,8 +4538,7 @@ int sctp_get_sctp_info(struct sock *sk, struct sctp_association *asoc,
info->sctpi_ictrlchunks = asoc->stats.ictrlchunks;
prim = asoc->peer.primary_path;
- memcpy(&info->sctpi_p_address, &prim->ipaddr,
- sizeof(struct sockaddr_storage));
+ memcpy(&info->sctpi_p_address, &prim->ipaddr, sizeof(prim->ipaddr));
info->sctpi_p_state = prim->state;
info->sctpi_p_cwnd = prim->cwnd;
info->sctpi_p_srtt = prim->srtt;
--
2.9.4
^ permalink raw reply related
* Re: [V2 PATCH net-next 0/5] xdp: more work on xdp tracepoints
From: Jesper Dangaard Brouer @ 2017-08-23 11:16 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Daniel Borkmann, brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
On Wed, 23 Aug 2017 12:15:14 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> More work on streamlining the tracepoints for XDP.
>
> V2: Change trace_xdp_redirect() to align with args of trace_xdp_exception()
Heads-up DaveM, just rebased my tree and noticed a merge conflict on
net-next... I'll send a V3
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH][netdev-next] gre: remove duplicated assignment of iph
From: Colin King @ 2017-08-23 11:13 UTC (permalink / raw)
To: David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
iph is being assigned the same value twice; remove the redundant
second assignment.
Fixes warning:
net/ipv4/ip_gre.c:265:2: warning: Value stored to 'iph' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/ipv4/ip_gre.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 6e8a62289e03..6b3e7c99a3b6 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -268,7 +268,6 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
if (unlikely(!pskb_may_pull(skb, len)))
return -ENOMEM;
- iph = ip_hdr(skb);
ershdr = (struct erspanhdr *)(skb->data + gre_hdr_len);
/* The original GRE header does not have key field,
--
2.14.1
^ permalink raw reply related
* Re: [V2 PATCH net-next 5/5] xdp: get tracepoints xdp_exception and xdp_redirect in sync
From: Daniel Borkmann @ 2017-08-23 10:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: Daniel Borkmann, John Fastabend
In-Reply-To: <150348334039.23476.16866879022276856834.stgit@firesoul>
On 08/23/2017 12:15 PM, Jesper Dangaard Brouer wrote:
> Remove the net_device string name from the xdp_exception tracepoint,
> like the xdp_redirect tracepoint.
>
> Align the TP_STRUCT to have common entries between these two
> tracepoint.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [V2 PATCH net-next 4/5] xdp: remove net_device names from xdp_redirect tracepoint
From: Daniel Borkmann @ 2017-08-23 10:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: Daniel Borkmann, John Fastabend
In-Reply-To: <150348333529.23476.10681237706586293307.stgit@firesoul>
On 08/23/2017 12:15 PM, Jesper Dangaard Brouer wrote:
> There is too much overhead in the current trace_xdp_redirect
> tracepoint as it does strcpy and strlen on the net_device names.
>
> Besides, exposing the ifindex/index is actually the information that
> is needed in the tracepoint to diagnose issues. When a lookup fails
> (either ifindex or devmap index) then there is a need for saying which
> to_index that have issues.
>
> V2: Adjust args to be aligned with trace_xdp_exception.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* [PATCH 3/3 v3] net: tipc: constify genl_ops
From: Arvind Yadav @ 2017-08-23 10:52 UTC (permalink / raw)
To: davem, Larry.Finger, chaoming_li, kvalo, jon.maloy, ying.xue
Cc: linux-kernel, linux-wireless, netdev
genl_ops are not supposed to change at runtime. All functions
working with genl_ops provided by <net/genetlink.h> work with
const genl_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
Changes in v2:
Patch Subject was wrong.
changes in v3 :
Updated patch subject as per comment.
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index 750949d..e48f0b2 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -1217,7 +1217,7 @@ static int tipc_nl_compat_recv(struct sk_buff *skb, struct genl_info *info)
return err;
}
-static struct genl_ops tipc_genl_compat_ops[] = {
+static const struct genl_ops tipc_genl_compat_ops[] = {
{
.cmd = TIPC_GENL_CMD,
.doit = tipc_nl_compat_recv,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V8 net-next 00/22] Huawei HiNIC Ethernet Driver
From: Aviad Krawczyk @ 2017-08-23 10:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Miller, Linux Kernel Mailing List, Networking, bc.y,
victor.gissin, zhaochen6, tony.qu
In-Reply-To: <CAK8P3a0St2mZ7q33zccHZ1uPyv0FKf2A+q+cMk+LN_L_qjxfkg@mail.gmail.com>
Hi,
> It's clear that ...
Sorry, but there are wrong assumptions here.
Thanks,
Aviad
On 8/23/2017 1:37 PM, Arnd Bergmann wrote:
> On Wed, Aug 23, 2017 at 11:31 AM, Aviad Krawczyk
> <aviad.krawczyk@huawei.com> wrote:
>> Hi Arnd,
>>
>> This is Huawei's PCIE HiNIC card.
>>
>> I am not familiar with the HiSilicon product and I don't see how
>> Huawei's PCIE HiNIC card is connected to the HiSilicon drivers on Linux Tree.
>>
>> I don't see how it can be shared: different product and different code.
>
> Sharing code was just a wild thought of mine, as I said I had not looked at
> whether there is anything that can be shared.
>
> However, simply moving drivers/net/ethernet/huawei/hinic to
> drivers/net/ethernet/hisilicon/hinic/ still seems to be the right thing and
> is a trivial patch.
>
> It's clear that hinic is made by HiSilicon and that hns/hns3 are used
> exclusively in Huawei, and maintained by Huawei developers, so it's
> probably just a matter of time before the IP block from the SoC makes
> it into a future PCI device or vice versa. Merging the two directories
> now makes this easier to handle in the future and (slightly) reduces
> the clutter in the top-level drivers/net/ethernet/Kconfig file.
>
> Arnd
>
> .
>
^ 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