* Re: [Patch net v3] tipc: call start and done ops directly in __tipc_nl_compat_dumpit()
From: Ying Xue @ 2018-09-05 3:19 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: tipc-discussion
In-Reply-To: <20180904215455.3985-1-xiyou.wangcong@gmail.com>
On 09/05/2018 05:54 AM, Cong Wang wrote:
> __tipc_nl_compat_dumpit() uses a netlink_callback on stack,
> so the only way to align it with other ->dumpit() call path
> is calling tipc_dump_start() and tipc_dump_done() directly
> inside it. Otherwise ->dumpit() would always get NULL from
> cb->args[].
>
> But tipc_dump_start() uses sock_net(cb->skb->sk) to retrieve
> net pointer, the cb->skb here doesn't set skb->sk, the net pointer
> is saved in msg->net instead, so introduce a helper function
> __tipc_dump_start() to pass in msg->net.
>
> Ying pointed out cb->args[0...3] are already used by other
> callbacks on this call path, so we can't use cb->args[0] any
> more, use cb->args[4] instead.
It's a common mechanism to save rhashtable iterator pointer in cb->args
after tipc_dump_start() and tipc_dump_done() are introduced. Someday
probably we will involve new dumpit function. In order to lower the risk
that rhashtable iterator pointer saved is overwritten, it's better to
use the last slot, ie, cb->args[5].
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: dsa: b53: Make SRAB driver manage port interrupts
From: Andrew Lunn @ 2018-09-04 22:59 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904221120.13018-3-f.fainelli@gmail.com>
> +static irqreturn_t b53_srab_port_isr(int irq, void *dev_id)
> +{
> + struct b53_srab_port_priv *port = dev_id;
> + struct b53_device *dev = port->dev;
> + struct b53_srab_priv *priv = dev->priv;
> +
> + /* Acknowledge the interrupt */
> + writel(BIT(port->num), priv->regs + B53_SRAB_INTR);
> +
> + schedule_work(&port->irq_work);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int b53_srab_irq_enable(struct b53_device *dev, int port)
> +{
> + struct b53_srab_priv *priv = dev->priv;
> + struct b53_srab_port_priv *p = &priv->port_intrs[port];
> + int ret;
> +
> + ret = request_irq(p->irq, b53_srab_port_isr, 0,
> + dev_name(dev->dev), p);
Hi Florian
Could you use a threaded interrupt? Save you from having to implement
your own work queue. I think you can have a function called in both
interrupt context in order to acknowledged the interrupt, and thread
context to do the remaining work.
Andrew
^ permalink raw reply
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Moritz Fischer @ 2018-09-05 3:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, David S. Miller, Florian Fainelli, Alex Williams,
Linux Kernel Mailing List
In-Reply-To: <20180905010100.GN29121@lunn.ch>
Hi Andrew,
On Tue, Sep 4, 2018 at 6:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> 3) I'm again not sure about the 'select PHYLINK', wouldn't
>> wanna break the build again...
>
> Hi Moritz
>
> I think it is safe. PHYLINK has no stated dependencies on OF. But i
> suspect it currently is pretty useless without OF.
Ok, great. Thanks!
>> @@ -1286,7 +1329,13 @@ static int nixge_probe(struct platform_device *pdev)
>> priv->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
>> priv->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;
>>
>> - err = nixge_mdio_setup(priv, pdev->dev.of_node);
>> + mn = of_get_child_by_name(pdev->dev.of_node, "mdio");
>> + if (!mn) {
>> + dev_warn(&pdev->dev, "No \"mdio\" subnode found, defaulting to legacy\n");
>> + mn = pdev->dev.of_node;
>> + }
>> +
>> + err = nixge_mdio_setup(priv, mn);
>
> I would suggest making this a patch of its own.
Yeah, will do.
> Also, do you need the legacy behaviour? If there are no boards out in
> the wild which this will break, just make the change.
Well all users basically use devicetree overlays that we distribute
with the FPGA images
as part of a filesystem update. So I suppose it wouldn't break anyone,
yet... It would certainly
make the code easier to read.
> Please also update the device tree binding documentation.
Yeah will do.
Thanks for the feedback,
Moritz
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: b53: Add SerDes support
From: Andrew Lunn @ 2018-09-04 23:15 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904221120.13018-6-f.fainelli@gmail.com>
On Tue, Sep 04, 2018 at 03:11:20PM -0700, Florian Fainelli wrote:
> Add support for the Northstar Plus SerDes which is accessed through a
> special page of the switch. Since this is something that most people
> probably will not want to use, make it a configurable option.
>
> The SerDes supports both SGMII and 1000baseX modes, and is internally
> looking like a seemingly standard MII PHY, except for the few bits that
> got repurposed.
Hi Florian
The SERDES in the 6352 also look very similar to a standard MII PHYs.
Maybe at some point, we should look at the SERDES drivers we have
embedded in different MAC drivers, and see if we can pull them out,
maybe put them in drivers/net/phy. Any SERDES driver being used in
combination with phylink probably has the same API.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: b53: Add SerDes support
From: Andrew Lunn @ 2018-09-04 23:32 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904221120.13018-6-f.fainelli@gmail.com>
> +void b53_serdes_phylink_validate(struct b53_device *dev, int port,
> + unsigned long *supported,
> + struct phylink_link_state *state)
> +{
> + u8 lane = b53_serdes_map_lane(dev, port);
> +
> + if (lane == B53_INVALID_LANE)
> + return;
> +
> + switch (lane) {
> + case 0:
> + phylink_set(supported, 2500baseX_Full);
Hi Florian
Could you also use it for 2500BaseT_Full with an appropriate copper
PHY?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: dsa: b53: Make SRAB driver manage port interrupts
From: Florian Fainelli @ 2018-09-04 23:46 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904225955.GH29121@lunn.ch>
On 09/04/2018 03:59 PM, Andrew Lunn wrote:
>> +static irqreturn_t b53_srab_port_isr(int irq, void *dev_id)
>> +{
>> + struct b53_srab_port_priv *port = dev_id;
>> + struct b53_device *dev = port->dev;
>> + struct b53_srab_priv *priv = dev->priv;
>> +
>> + /* Acknowledge the interrupt */
>> + writel(BIT(port->num), priv->regs + B53_SRAB_INTR);
>> +
>> + schedule_work(&port->irq_work);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int b53_srab_irq_enable(struct b53_device *dev, int port)
>> +{
>> + struct b53_srab_priv *priv = dev->priv;
>> + struct b53_srab_port_priv *p = &priv->port_intrs[port];
>> + int ret;
>> +
>> + ret = request_irq(p->irq, b53_srab_port_isr, 0,
>> + dev_name(dev->dev), p);
>
> Hi Florian
>
> Could you use a threaded interrupt? Save you from having to implement
> your own work queue. I think you can have a function called in both
> interrupt context in order to acknowledged the interrupt, and thread
> context to do the remaining work.
Indeed, this works nicely actually, thanks for the suggestion.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: b53: Add SerDes support
From: Florian Fainelli @ 2018-09-04 23:55 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904233222.GJ29121@lunn.ch>
On 09/04/2018 04:32 PM, Andrew Lunn wrote:
>
>
>> +void b53_serdes_phylink_validate(struct b53_device *dev, int port,
>> + unsigned long *supported,
>> + struct phylink_link_state *state)
>> +{
>> + u8 lane = b53_serdes_map_lane(dev, port);
>> +
>> + if (lane == B53_INVALID_LANE)
>> + return;
>> +
>> + switch (lane) {
>> + case 0:
>> + phylink_set(supported, 2500baseX_Full);
>
> Hi Florian
>
> Could you also use it for 2500BaseT_Full with an appropriate copper
> PHY?
My reading of the datasheet (which only mentions 2.5G with no further
mention) make me think that is not possible to do copper at 2.5G and
only 2500baseX since it only talks about fiber and not copper.
Would you recommend a specific SFP that allows that? Like this one:
https://www.flexoptix.net/en/sfp-t-transceiver-2h-gigabit-cat-5e-rj-45-100m-100m-1000m-2500-base-t.html?co8829=85744
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: b53: Add SerDes support
From: Florian Fainelli @ 2018-09-05 0:02 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <20180904231543.GI29121@lunn.ch>
On 09/04/2018 04:15 PM, Andrew Lunn wrote:
> On Tue, Sep 04, 2018 at 03:11:20PM -0700, Florian Fainelli wrote:
>> Add support for the Northstar Plus SerDes which is accessed through a
>> special page of the switch. Since this is something that most people
>> probably will not want to use, make it a configurable option.
>>
>> The SerDes supports both SGMII and 1000baseX modes, and is internally
>> looking like a seemingly standard MII PHY, except for the few bits that
>> got repurposed.
>
> Hi Florian
>
> The SERDES in the 6352 also look very similar to a standard MII PHYs.
>
> Maybe at some point, we should look at the SERDES drivers we have
> embedded in different MAC drivers, and see if we can pull them out,
> maybe put them in drivers/net/phy. Any SERDES driver being used in
> combination with phylink probably has the same API.
Yes, that would sound like a good move forward. The SerDes on the
Northstar Plus does have a bunch of MII standard registers, but not a
whole lot (BMSR, BMCR, MII_PHYSID1/2, AUTONEGADV, AUTONEGLPABIL) and
then, it's all custom.
It would be good to have possibly a third vendor (Mediatek? Qualcomm?)
and see how they did it so we can define an appropriate API.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: b53: Add SerDes support
From: Andrew Lunn @ 2018-09-05 0:06 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, vivien.didelot, davem
In-Reply-To: <57632a74-e3dd-893f-2573-d0450d6b290a@gmail.com>
On Tue, Sep 04, 2018 at 04:55:26PM -0700, Florian Fainelli wrote:
> On 09/04/2018 04:32 PM, Andrew Lunn wrote:
> >
> >
> >> +void b53_serdes_phylink_validate(struct b53_device *dev, int port,
> >> + unsigned long *supported,
> >> + struct phylink_link_state *state)
> >> +{
> >> + u8 lane = b53_serdes_map_lane(dev, port);
> >> +
> >> + if (lane == B53_INVALID_LANE)
> >> + return;
> >> +
> >> + switch (lane) {
> >> + case 0:
> >> + phylink_set(supported, 2500baseX_Full);
> >
> > Hi Florian
> >
> > Could you also use it for 2500BaseT_Full with an appropriate copper
> > PHY?
>
> My reading of the datasheet (which only mentions 2.5G with no further
> mention) make me think that is not possible to do copper at 2.5G and
> only 2500baseX since it only talks about fiber and not copper.
>
> Would you recommend a specific SFP that allows that? Like this one:
>
> https://www.flexoptix.net/en/sfp-t-transceiver-2h-gigabit-cat-5e-rj-45-100m-100m-1000m-2500-base-t.html?co8829=85744
I was actually thinking of a 'plain old' copper PHY with a SERDES
interface which can do 25000Base-T. The Marvell 88x3310 or the
Aquantia 10G PHY, for example.
Russell might be able to make a recommendation. I don't have any
Copper SFP modules.
Andrew
^ permalink raw reply
* Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions.
From: Ttttabcd @ 2018-09-05 0:20 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Netdev
In-Reply-To: <CADVnQy=neWRer8AZBimf2c+iFzn=1iRoBwcsAYgjj=SJXQj7jg@mail.gmail.com>
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 4 September 2018 9:06 PM, Neal Cardwell <ncardwell@google.com> wrote:
> On Tue, Sep 4, 2018 at 1:48 AM Ttttabcd ttttabcd@protonmail.com wrote:
>
> > Hello everyone,recently I am looking at the source code for handling TCP three-way handshake(Linux Kernel version 4.18.5).
> > I found some strange places in the source code for handling syn messages.
> > in the function "tcp_conn_request"
> > This code will be executed when we don't enable the syn cookies.
> >
> > if (!net->ipv4.sysctl_tcp_syncookies &&
> > (net->ipv4.sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) <
> > (net->ipv4.sysctl_max_syn_backlog >> 2)) &&
> > !tcp_peer_is_proven(req, dst)) {
> > /* Without syncookies last quarter of
> > * backlog is filled with destinations,
> > * proven to be alive.
> > * It means that we continue to communicate
> > * to destinations, already remembered
> > * to the moment of synflood.
> > */
> > pr_drop_req(req, ntohs(tcp_hdr(skb)->source),
> > rsk_ops->family);
> > goto drop_and_release;
> > }
> >
> >
> > But why don't we use all the syn queues?
>
> If tcp_peer_is_proven() returns true then we do allow ourselves to use
> the whole queue.
>
> > Why do we need to leave the size of (net->ipv4.sysctl_max_syn_backlog >> 2) in the queue?
> > Even if the system is attacked by a syn flood, there is no need to leave a part. Why do we need to leave a part?
>
> The comment describes the rationale. If syncookies are disabled, then
> the last quarter of the backlog is reserved for filling with
> destinations that were proven to be alive, according to
> tcp_peer_is_proven() (which uses RTTs measured in previous
> connections). The idea is that if there is a SYN flood, we do not want
> to use all of our queue budget on attack traffic but instead want to
> reserve some queue space for SYNs from real remote machines that we
> have actually contacted in the past.
>
> > The value of sysctl_max_syn_backlog is the maximum length of the queue only if syn cookies are enabled.
>
> Even if syncookies are disabled, sysctl_max_syn_backlog is the maximum
> length of the queue.
>
> > This is the first strange place, here is another strange place
> >
> > __u32 isn = TCP_SKB_CB(skb)->tcp_tw_isn;
> >
> > if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
> > inet_csk_reqsk_queue_is_full(sk)) && !isn) {
> >
> > if (!want_cookie && !isn) {
> >
> >
> > The value of "isn" comes from TCP_SKB_CB(skb)->tcp_tw_isn, then it is judged twice whether its value is indeed 0.
> > But "tcp_tw_isn" is initialized in the function "tcp_v4_fill_cb"
> >
> > TCP_SKB_CB(skb)->tcp_tw_isn = 0;
> >
> >
> > So it has always been 0, I used printk to test, and the result is always 0.
>
> That field is also set in tcp_timewait_state_process():
>
> TCP_SKB_CB(skb)->tcp_tw_isn = isn;
>
> So there can be cases where it is not 0.
>
> Hope that helps,
> neal
Thank you very much, I understand
^ permalink raw reply
* [RFC/PATCH] net: nixge: Add PHYLINK support
From: Moritz Fischer @ 2018-09-05 0:15 UTC (permalink / raw)
To: netdev
Cc: davem, f.fainelli, andrew, alex.williams, moritz.fischer,
linux-kernel, Moritz Fischer
Add basic PHYLINK support to driver.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
Hi all,
as Andrew suggested in order to enable SFP as
well as fixed-link support add PHYLINK support.
A couple of questions are still open (hence the RFC):
1) It seems odd to implement PHYLINK callbacks that
are all empty? If so, should we have generic empty
ones in drivers/net/phy/phylink.c like we have for
genphys?
2) If this is ok, then I'll go ahead rework this with
a DT binding update to deprecate the non-'mdio'-subnode
case (since there are no in-tree users we might just
change the binding)?
3) I'm again not sure about the 'select PHYLINK', wouldn't
wanna break the build again...
Thanks again for your time!
Moritz
---
drivers/net/ethernet/ni/Kconfig | 1 +
drivers/net/ethernet/ni/nixge.c | 115 +++++++++++++++++++++++---------
2 files changed, 83 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/ni/Kconfig b/drivers/net/ethernet/ni/Kconfig
index c73978474c4b..80cd72948551 100644
--- a/drivers/net/ethernet/ni/Kconfig
+++ b/drivers/net/ethernet/ni/Kconfig
@@ -21,6 +21,7 @@ config NI_XGE_MANAGEMENT_ENET
depends on HAS_IOMEM && HAS_DMA
select PHYLIB
select OF_MDIO if OF
+ select PHYLINK
help
Simple LAN device for debug or management purposes. Can
support either 10G or 1G PHYs via SFP+ ports.
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 74cf52e3fb09..a0e790d07b1c 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -11,6 +11,7 @@
#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include <linux/of_platform.h>
+#include <linux/phylink.h>
#include <linux/of_irq.h>
#include <linux/skbuff.h>
#include <linux/phy.h>
@@ -165,7 +166,7 @@ struct nixge_priv {
struct device *dev;
/* Connection to PHY device */
- struct device_node *phy_node;
+ struct phylink *phylink;
phy_interface_t phy_mode;
int link;
@@ -416,20 +417,6 @@ static void nixge_device_reset(struct net_device *ndev)
netif_trans_update(ndev);
}
-static void nixge_handle_link_change(struct net_device *ndev)
-{
- struct nixge_priv *priv = netdev_priv(ndev);
- struct phy_device *phydev = ndev->phydev;
-
- if (phydev->link != priv->link || phydev->speed != priv->speed ||
- phydev->duplex != priv->duplex) {
- priv->link = phydev->link;
- priv->speed = phydev->speed;
- priv->duplex = phydev->duplex;
- phy_print_status(phydev);
- }
-}
-
static void nixge_tx_skb_unmap(struct nixge_priv *priv,
struct nixge_tx_skb *tx_skb)
{
@@ -859,17 +846,15 @@ static void nixge_dma_err_handler(unsigned long data)
static int nixge_open(struct net_device *ndev)
{
struct nixge_priv *priv = netdev_priv(ndev);
- struct phy_device *phy;
int ret;
nixge_device_reset(ndev);
- phy = of_phy_connect(ndev, priv->phy_node,
- &nixge_handle_link_change, 0, priv->phy_mode);
- if (!phy)
- return -ENODEV;
+ ret = phylink_of_phy_connect(priv->phylink, priv->dev->of_node, 0);
+ if (ret < 0)
+ return ret;
- phy_start(phy);
+ phylink_start(priv->phylink);
/* Enable tasklets for Axi DMA error handling */
tasklet_init(&priv->dma_err_tasklet, nixge_dma_err_handler,
@@ -893,8 +878,7 @@ static int nixge_open(struct net_device *ndev)
err_rx_irq:
free_irq(priv->tx_irq, ndev);
err_tx_irq:
- phy_stop(phy);
- phy_disconnect(phy);
+ phylink_disconnect_phy(priv->phylink);
tasklet_kill(&priv->dma_err_tasklet);
netdev_err(ndev, "request_irq() failed\n");
return ret;
@@ -908,9 +892,9 @@ static int nixge_stop(struct net_device *ndev)
netif_stop_queue(ndev);
napi_disable(&priv->napi);
- if (ndev->phydev) {
- phy_stop(ndev->phydev);
- phy_disconnect(ndev->phydev);
+ if (priv->phylink) {
+ phylink_stop(priv->phylink);
+ phylink_disconnect_phy(priv->phylink);
}
cr = nixge_dma_read_reg(priv, XAXIDMA_RX_CR_OFFSET);
@@ -1076,13 +1060,31 @@ static int nixge_ethtools_set_phys_id(struct net_device *ndev,
return 0;
}
+static int
+nixge_ethtool_set_link_ksettings(struct net_device *ndev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct nixge_priv *priv = netdev_priv(ndev);
+
+ return phylink_ethtool_ksettings_set(priv->phylink, cmd);
+}
+
+static int
+nixge_ethtool_get_link_ksettings(struct net_device *ndev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct nixge_priv *priv = netdev_priv(ndev);
+
+ return phylink_ethtool_ksettings_get(priv->phylink, cmd);
+}
+
static const struct ethtool_ops nixge_ethtool_ops = {
.get_drvinfo = nixge_ethtools_get_drvinfo,
.get_coalesce = nixge_ethtools_get_coalesce,
.set_coalesce = nixge_ethtools_set_coalesce,
.set_phys_id = nixge_ethtools_set_phys_id,
- .get_link_ksettings = phy_ethtool_get_link_ksettings,
- .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_link_ksettings = nixge_ethtool_get_link_ksettings,
+ .set_link_ksettings = nixge_ethtool_set_link_ksettings,
.get_link = ethtool_op_get_link,
};
@@ -1225,11 +1227,52 @@ static void *nixge_get_nvmem_address(struct device *dev)
return mac;
}
+static void nixge_validate(struct net_device *ndev, unsigned long *supported,
+ struct phylink_link_state *state)
+{
+}
+
+static int nixge_mac_link_state(struct net_device *ndev,
+ struct phylink_link_state *state)
+{
+ return 0;
+}
+
+static void nixge_mac_config(struct net_device *ndev, unsigned int mode,
+ const struct phylink_link_state *state)
+{
+}
+
+static void nixge_mac_an_restart(struct net_device *ndev)
+{
+}
+
+static void nixge_mac_link_down(struct net_device *ndev, unsigned int mode,
+ phy_interface_t interface)
+{
+}
+
+static void nixge_mac_link_up(struct net_device *ndev, unsigned int mode,
+ phy_interface_t interface,
+ struct phy_device *phy)
+{
+}
+
+static const struct phylink_mac_ops nixge_phylink_ops = {
+ .validate = nixge_validate,
+ .mac_link_state = nixge_mac_link_state,
+ .mac_an_restart = nixge_mac_an_restart,
+ .mac_config = nixge_mac_config,
+ .mac_link_down = nixge_mac_link_down,
+ .mac_link_up = nixge_mac_link_up,
+};
+
static int nixge_probe(struct platform_device *pdev)
{
struct nixge_priv *priv;
struct net_device *ndev;
struct resource *dmares;
+ struct device_node *mn;
const u8 *mac_addr;
int err;
@@ -1286,7 +1329,13 @@ static int nixge_probe(struct platform_device *pdev)
priv->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
priv->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;
- err = nixge_mdio_setup(priv, pdev->dev.of_node);
+ mn = of_get_child_by_name(pdev->dev.of_node, "mdio");
+ if (!mn) {
+ dev_warn(&pdev->dev, "No \"mdio\" subnode found, defaulting to legacy\n");
+ mn = pdev->dev.of_node;
+ }
+
+ err = nixge_mdio_setup(priv, mn);
if (err) {
netdev_err(ndev, "error registering mdio bus");
goto free_netdev;
@@ -1299,10 +1348,10 @@ static int nixge_probe(struct platform_device *pdev)
goto unregister_mdio;
}
- priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
- if (!priv->phy_node) {
- netdev_err(ndev, "not find \"phy-handle\" property\n");
- err = -EINVAL;
+ priv->phylink = phylink_create(ndev, pdev->dev.fwnode, priv->phy_mode,
+ &nixge_phylink_ops);
+ if (IS_ERR(priv->phylink)) {
+ err = PTR_ERR(priv->phylink);
goto unregister_mdio;
}
--
2.18.0
^ permalink raw reply related
* I wait for your prompt response.
From: Aziz Dake @ 2018-09-05 0:44 UTC (permalink / raw)
Good day,
I am Mr. Aziz Dake, from Burkina Faso a Minister confide on me to
look for foreign partner who will assist him to invest the sum of
Thirty Million Dollars ($30,000,000) in your country.
He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.
Hence your co -operation is highly needed to actualize this investment project
I wait for your prompt response.
Sincerely yours
Mr Aziz Dake.
^ permalink raw reply
* Planned downtime for ozlabs.org
From: Stephen Rothwell @ 2018-09-05 0:55 UTC (permalink / raw)
To: users
Cc: Stephen Finucane, David Miller, richard.weinberger, rdunlap,
andrew.donnellan, jeffrey.t.kirsher, jk, patchwork, netdev,
miquel.raynal
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Hi all,
There will be a (hopefully) short outage of
{bilbo,patchwork,lists,irc,mail,mx}.ozlabs.org tomorrow (Thu Sep 6) at
around 11am Canberra time (+1000) to (hopefully) fix the problem with
our router port that has been causing some of the recent connectivity
problems.
I may take the opportunity to also reboot the server for useful kernel
updates.
We also currently have no IPv6 connectivity (and no ETA for recovery)
so I have removed the IPv6 addresses from most of our public facing
services. I will put them back when we have our connectivity back.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Andrew Lunn @ 2018-09-05 1:07 UTC (permalink / raw)
To: Moritz Fischer
Cc: netdev, davem, f.fainelli, alex.williams, moritz.fischer,
linux-kernel
In-Reply-To: <20180905001535.19168-1-mdf@kernel.org>
> -static void nixge_handle_link_change(struct net_device *ndev)
> -{
> - struct nixge_priv *priv = netdev_priv(ndev);
> - struct phy_device *phydev = ndev->phydev;
> -
> - if (phydev->link != priv->link || phydev->speed != priv->speed ||
> - phydev->duplex != priv->duplex) {
> - priv->link = phydev->link;
> - priv->speed = phydev->speed;
> - priv->duplex = phydev->duplex;
> - phy_print_status(phydev);
> - }
> -}
I think this is why you are having trouble with the phylink
callbacks. You currently don't have any configuration of the MAC. You
normally need to tell the MAC what speed it should be doing. What
duplex it should be doing, if the link is up or down, if it should do
pause, or asym pause or no pause, etc.
Andrew
^ permalink raw reply
* Re: [PATCH] net: ethernet: i40e: fix build error
From: Wang, Dongsheng @ 2018-09-05 1:32 UTC (permalink / raw)
To: Sergei Shtylyov, jeffrey.t.kirsher@intel.com
Cc: jacob.e.keller@intel.com, davem@davemloft.net,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <84982f95-940e-d278-f6a2-13a9f76823c9@cogentembedded.com>
On 2018/9/4 18:54, Sergei Shtylyov wrote:
> On 9/4/2018 12:48 PM, Wang Dongsheng wrote:
>
>> Remove "inline" from __i40e_add_stat_strings.
>>
>> In file included from
>> drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9:0:
>> drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function
>> ‘__i40e_add_stat_strings’:
>> drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error:
>> function ‘__i40e_add_stat_strings’ can never be inlined because it uses
>> variable argument lists
>> static inline void __i40e_add_stat_strings(u8 **p, const struct
>> i40e_stats stats[],
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
>> ---
>> drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h b/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
>> index bba1cb0..0290ade 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
>> @@ -190,7 +190,7 @@ struct i40e_stats {
>> * Format and copy the strings described by stats into the buffer pointed at
>> * by p.
>> **/
>> -static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
>> +static void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
> You can't have non-inline function in a header file. Please move it,
> leaving only prototype here.
:(. Oops, a stupid mistake...fix an error and bring in another
error...Thanks.
Cheers,
-Dongsheng
>> const unsigned int size, ...)
>> {
>> unsigned int i;
> MBR, Sergei
>
^ permalink raw reply
* Re: [Patch net v3] tipc: call start and done ops directly in __tipc_nl_compat_dumpit()
From: Ying Xue @ 2018-09-05 6:04 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, tipc-discussion
In-Reply-To: <CAM_iQpXvwy1vR9extqOYk2J6zk=xajH+5L8mabwgd1N_JkfPAQ@mail.gmail.com>
On 09/05/2018 01:49 PM, Cong Wang wrote:
> On Tue, Sep 4, 2018 at 8:25 PM Ying Xue <ying.xue@windriver.com> wrote:
>>
>> On 09/05/2018 05:54 AM, Cong Wang wrote:
>>> __tipc_nl_compat_dumpit() uses a netlink_callback on stack,
>>> so the only way to align it with other ->dumpit() call path
>>> is calling tipc_dump_start() and tipc_dump_done() directly
>>> inside it. Otherwise ->dumpit() would always get NULL from
>>> cb->args[].
>>>
>>> But tipc_dump_start() uses sock_net(cb->skb->sk) to retrieve
>>> net pointer, the cb->skb here doesn't set skb->sk, the net pointer
>>> is saved in msg->net instead, so introduce a helper function
>>> __tipc_dump_start() to pass in msg->net.
>>>
>>> Ying pointed out cb->args[0...3] are already used by other
>>> callbacks on this call path, so we can't use cb->args[0] any
>>> more, use cb->args[4] instead.
>>
>> It's a common mechanism to save rhashtable iterator pointer in cb->args
>> after tipc_dump_start() and tipc_dump_done() are introduced. Someday
>> probably we will involve new dumpit function. In order to lower the risk
>> that rhashtable iterator pointer saved is overwritten, it's better to
>> use the last slot, ie, cb->args[5].
>
> I don't understand, currently only cb->args[0..3] are used at most,
> therefore cb->args[4] is pretty safe in current code base, there is
> no reason to be so defensive to use cb->args[5].
>
Yes, at present cb->args[4] is safe.
> If you really worry about future, you probably want to extend cb->args
> from 6 to whatever larger, rather than just skipping cb->args[4].
>
When we have to use the fifth slot of cb->args[] in the future, we need
to skip sb->args[4], which is a bit wried. This is the reason why I
suggested we could use the last one.
> I don't see any reason to do so.
As I said, the current version is safe. If you think it's unnecessary to
change, it's okay to me.
Acked-by: Ying Xue <ying.xue@windriver.com>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH bpf-next v2] libbpf: Remove the duplicate checking of function storage
From: Alexei Starovoitov @ 2018-09-05 6:11 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Taeung Song, Daniel Borkmann, Alexei Starovoitov, netdev,
linux-kernel
In-Reply-To: <20180904110745.3ab4dc3e@cakuba>
On Tue, Sep 04, 2018 at 11:07:45AM +0200, Jakub Kicinski wrote:
> On Mon, 3 Sep 2018 08:30:07 +0900, Taeung Song wrote:
> > After the commit eac7d84519a3 ("tools: libbpf: don't return '.text'
> > as a program for multi-function programs"), bpf_program__next()
> > in bpf_object__for_each_program skips the function storage such as .text,
> > so eliminate the duplicate checking.
> >
> > Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>
> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf-next] bpf/verifier: properly clear union members after a ctx read
From: Alexei Starovoitov @ 2018-09-05 2:23 UTC (permalink / raw)
To: Edward Cree; +Cc: daniel, ast, netdev
In-Reply-To: <0b724ba4-9ddf-e635-0bd5-201658355cf5@solarflare.com>
On Tue, Sep 04, 2018 at 03:19:52PM +0100, Edward Cree wrote:
> In check_mem_access(), for the PTR_TO_CTX case, after check_ctx_access()
> has supplied a reg_type, the other members of the register state are set
> appropriately. Previously reg.range was set to 0, but as it is in a
> union with reg.map_ptr, which is larger, upper bytes of the latter were
> left in place. This then caused the memcmp() in regsafe() to fail,
> preventing some branches from being pruned (and occasionally causing the
> same program to take a varying number of processed insns on repeated
> verifier runs).
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
> Possibly something might need adding to __mark_reg_unknown() as well to
> clear map_ptr/range, I'm not sure (though doing so did not affect the
> processed insn count on the cilium programs).
>
> kernel/bpf/verifier.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index f4ff0c569e54..49e4ea66fdd3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1640,9 +1640,9 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> else
> mark_reg_known_zero(env, regs,
> value_regno);
> - regs[value_regno].id = 0;
> - regs[value_regno].off = 0;
> - regs[value_regno].range = 0;
> + /* Clear id, off, and union(map_ptr, range) */
> + memset(regs + value_regno, 0,
> + offsetof(struct bpf_reg_state, var_off));
> regs[value_regno].type = reg_type;
> }
Awesome! Thanks a bunch for tracking it down.
I vaguely remember thinking about overlapping map_ptr with other fields
and not clearing map_ptr explicitly, because it was unnecessary...
Doing a bit of git-archaeology...
Looks like commit f1174f77b50c ("bpf/verifier: rework value tracking")
removed 'imm' from that union, so that __mark_reg_unknown_value()
that was clearing both 'imm' and 'map_ptr' before was no longer happening.
So old sequence:
mark_reg_unknown_value_and_range(); // which called __mark_reg_unknown_value()
// which cleared 'imm' (and id|off|range)
state->regs[value_regno].type = reg_type;
got replaced with
mark_reg_known_zero();
state->regs[value_regno].id = 0;
state->regs[value_regno].off = 0;
state->regs[value_regno].range = 0;
state->regs[value_regno].type = reg_type;
which made map_ptr contain junk in upper bits.
I bet the comment "note that reg.[id|off|range] == 0" few lines before
that was deleted by that commit probably caused that bug :)
That comment I added as part of commit 969bf05eb3ce ("bpf: direct packet access")
What I was trying to express in that comment that
"mark_reg_unknown_value() that is called right before that comment
also clears id|off|range that are included as part of bigger 'imm' field
that mark_reg_unknown_value() clears, so these three fields don't need
to be cleared separately"
Sorry for confusion that that comment caused and painful debugging.
So would you agree it's fair to add
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
?
Also I think it's better to do this memset() in both
__mark_reg_unknown() and in __mark_reg_known()
instead of open coding it here in check_mem_access().
While at it we would also need to adjust this:
static void __mark_reg_const_zero(struct bpf_reg_state *reg)
{
__mark_reg_known(reg, 0);
reg->off = 0;
reg->type = SCALAR_VALUE;
}
since line reg->off = 0; wouldn't make sense after memset() is added
and few other places.
btw the 4 byte hole:
enum bpf_reg_type type; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
union {
u16 range; /* 2 */
struct bpf_map * map_ptr; /* 8 */
}; /* 8 8 */
doesn't cause instability issues, since we kzalloc verifier reg state.
How about patch like the following:
------------
>From 422fd975ed78645ab67d2eb50ff6e1ff6fb3de32 Mon Sep 17 00:00:00 2001
From: Alexei Starovoitov <ast@kernel.org>
Date: Tue, 4 Sep 2018 19:13:44 -0700
Subject: [PATCH] bpf/verifier: fix verifier instability
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Debugged-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f4ff0c569e54..6ff1bac1795d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -570,7 +570,9 @@ static void __mark_reg_not_init(struct bpf_reg_state *reg);
*/
static void __mark_reg_known(struct bpf_reg_state *reg, u64 imm)
{
- reg->id = 0;
+ /* Clear id, off, and union(map_ptr, range) */
+ memset(((u8 *)reg) + sizeof(reg->type), 0,
+ offsetof(struct bpf_reg_state, var_off) - sizeof(reg->type));
reg->var_off = tnum_const(imm);
reg->smin_value = (s64)imm;
reg->smax_value = (s64)imm;
@@ -589,7 +591,6 @@ static void __mark_reg_known_zero(struct bpf_reg_state *reg)
static void __mark_reg_const_zero(struct bpf_reg_state *reg)
{
__mark_reg_known(reg, 0);
- reg->off = 0;
reg->type = SCALAR_VALUE;
}
@@ -700,9 +701,12 @@ static void __mark_reg_unbounded(struct bpf_reg_state *reg)
/* Mark a register as having a completely unknown (scalar) value. */
static void __mark_reg_unknown(struct bpf_reg_state *reg)
{
+ /*
+ * Clear type, id, off, and union(map_ptr, range) and
+ * padding between 'type' and union
+ */
+ memset(reg, 0, offsetof(struct bpf_reg_state, var_off));
reg->type = SCALAR_VALUE;
- reg->id = 0;
- reg->off = 0;
reg->var_off = tnum_unknown;
reg->frameno = 0;
__mark_reg_unbounded(reg);
@@ -1640,9 +1644,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
else
mark_reg_known_zero(env, regs,
value_regno);
- regs[value_regno].id = 0;
- regs[value_regno].off = 0;
- regs[value_regno].range = 0;
regs[value_regno].type = reg_type;
}
@@ -2495,7 +2496,6 @@ static int check_helper_call(struct bpf_verifier_env *env, int func_id, int insn
regs[BPF_REG_0].type = PTR_TO_MAP_VALUE_OR_NULL;
/* There is no offset yet applied, variable or fixed */
mark_reg_known_zero(env, regs, BPF_REG_0);
- regs[BPF_REG_0].off = 0;
/* remember map_ptr, so that check_map_access()
* can check 'value_size' boundary of memory access
* to map element returned from bpf_map_lookup_elem()
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] net: ethernet: i40evf: fix potential build error
From: Wang Dongsheng @ 2018-09-05 2:27 UTC (permalink / raw)
To: jeffrey.t.kirsher, sergei.shtylyov
Cc: jacob.e.keller, davem, intel-wired-lan, netdev, linux-kernel,
Wang Dongsheng
In-Reply-To: <1536114430-21356-1-git-send-email-dongsheng.wang@hxt-semitech.com>
Can't have non-inline function in a header file.
There is a risk of "Multiple definition" from cross-including.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
.../intel/i40evf/i40e_ethtool_stats.h | 25 ++-----------------
.../ethernet/intel/i40evf/i40evf_ethtool.c | 24 ++++++++++++++++++
2 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_ethtool_stats.h b/drivers/net/ethernet/intel/i40evf/i40e_ethtool_stats.h
index 60b595dd8c39..d70a071f065f 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_ethtool_stats.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_ethtool_stats.h
@@ -181,29 +181,8 @@ i40evf_add_queue_stats(u64 **data, struct i40e_ring *ring)
*data += size;
}
-/**
- * __i40e_add_stat_strings - copy stat strings into ethtool buffer
- * @p: ethtool supplied buffer
- * @stats: stat definitions array
- * @size: size of the stats array
- *
- * Format and copy the strings described by stats into the buffer pointed at
- * by p.
- **/
-static void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
- const unsigned int size, ...)
-{
- unsigned int i;
-
- for (i = 0; i < size; i++) {
- va_list args;
-
- va_start(args, size);
- vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
- *p += ETH_GSTRING_LEN;
- va_end(args);
- }
-}
+void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
+ const unsigned int size, ...);
/**
* 40e_add_stat_strings - copy stat strings into ethtool buffer
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
index 9319971c5c92..c9a54f6de61e 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
@@ -171,6 +171,30 @@ static void i40evf_get_priv_flag_strings(struct net_device *netdev, u8 *data)
}
}
+/**
+ * __i40e_add_stat_strings - copy stat strings into ethtool buffer
+ * @p: ethtool supplied buffer
+ * @stats: stat definitions array
+ * @size: size of the stats array
+ *
+ * Format and copy the strings described by stats into the buffer pointed at
+ * by p.
+ **/
+void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
+ const unsigned int size, ...)
+{
+ unsigned int i;
+
+ for (i = 0; i < size; i++) {
+ va_list args;
+
+ va_start(args, size);
+ vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
+ *p += ETH_GSTRING_LEN;
+ va_end(args);
+ }
+}
+
/**
* i40evf_get_stat_strings - Get stat strings
* @netdev: network interface device structure
--
2.18.0
^ permalink raw reply related
* [PATCH v2 1/2] net: ethernet: i40e: fix build error
From: Wang Dongsheng @ 2018-09-05 2:27 UTC (permalink / raw)
To: jeffrey.t.kirsher, sergei.shtylyov
Cc: jacob.e.keller, davem, intel-wired-lan, netdev, linux-kernel,
Wang Dongsheng
Remove "inline" from __i40e_add_stat_strings.
In file included from
drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9:0:
drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function
‘__i40e_add_stat_strings’:
drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error:
function ‘__i40e_add_stat_strings’ can never be inlined because it uses
variable argument lists
static inline void __i40e_add_stat_strings(u8 **p, const struct
i40e_stats stats[],
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
v2:
1. Move function.
2. Include a new patch at [2/2].
---
.../net/ethernet/intel/i40e/i40e_ethtool.c | 24 ++++++++++++++++++
.../ethernet/intel/i40e/i40e_ethtool_stats.h | 25 ++-----------------
2 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index d7d3974beca2..f4a70d67a80a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1821,6 +1821,30 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
"ethtool stats count mismatch!");
}
+/**
+ * __i40e_add_stat_strings - copy stat strings into ethtool buffer
+ * @p: ethtool supplied buffer
+ * @stats: stat definitions array
+ * @size: size of the stats array
+ *
+ * Format and copy the strings described by stats into the buffer pointed at
+ * by p.
+ **/
+void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
+ const unsigned int size, ...)
+{
+ unsigned int i;
+
+ for (i = 0; i < size; i++) {
+ va_list args;
+
+ va_start(args, size);
+ vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
+ *p += ETH_GSTRING_LEN;
+ va_end(args);
+ }
+}
+
/**
* i40e_get_stat_strings - copy stat strings into supplied buffer
* @netdev: the netdev to collect strings for
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h b/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
index bba1cb0b658f..0874c352136a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h
@@ -181,29 +181,8 @@ i40e_add_queue_stats(u64 **data, struct i40e_ring *ring)
*data += size;
}
-/**
- * __i40e_add_stat_strings - copy stat strings into ethtool buffer
- * @p: ethtool supplied buffer
- * @stats: stat definitions array
- * @size: size of the stats array
- *
- * Format and copy the strings described by stats into the buffer pointed at
- * by p.
- **/
-static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
- const unsigned int size, ...)
-{
- unsigned int i;
-
- for (i = 0; i < size; i++) {
- va_list args;
-
- va_start(args, size);
- vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
- *p += ETH_GSTRING_LEN;
- va_end(args);
- }
-}
+void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
+ const unsigned int size, ...);
/**
* 40e_add_stat_strings - copy stat strings into ethtool buffer
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v7 3/4] gpiolib: Pass array info to get/set array functions
From: kbuild test robot @ 2018-09-05 7:11 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: kbuild-all, Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy
In-Reply-To: <20180902120144.6855-4-jmkrzyszt@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7331 bytes --]
Hi Janusz,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.19-rc2 next-20180905]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Janusz-Krzysztofik/gpiolib-Pass-bitmaps-not-integer-arrays-to-get-set-array/20180903-172834
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-f2-201835 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 'phy_mdm6600_cmd':
drivers/phy/motorola/phy-mapphone-mdm6600.c:166:12: error: passing argument 3 of 'gpiod_set_array_value_cansleep' from incompatible pointer type [-Werror=incompatible-pointer-types]
ddata->cmd_gpios->info, values);
^~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:417:20: note: expected 'int *' but argument is of type 'struct gpio_array *'
static inline void gpiod_set_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:164:2: error: too many arguments to function 'gpiod_set_array_value_cansleep'
gpiod_set_array_value_cansleep(PHY_MDM6600_NR_CMD_LINES,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:417:20: note: declared here
static inline void gpiod_set_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 'phy_mdm6600_status':
drivers/phy/motorola/phy-mapphone-mdm6600.c:185:13: error: passing argument 3 of 'gpiod_get_array_value_cansleep' from incompatible pointer type [-Werror=incompatible-pointer-types]
ddata->status_gpios->info,
^~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:404:19: note: expected 'int *' but argument is of type 'struct gpio_array *'
static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:183:10: error: too many arguments to function 'gpiod_get_array_value_cansleep'
error = gpiod_get_array_value_cansleep(PHY_MDM6600_NR_STATUS_LINES,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:404:19: note: declared here
static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/gpiod_set_array_value_cansleep +164 drivers/phy/motorola/phy-mapphone-mdm6600.c
5d1ebbda0 Tony Lindgren 2018-03-08 151
5d1ebbda0 Tony Lindgren 2018-03-08 152 /**
5d1ebbda0 Tony Lindgren 2018-03-08 153 * phy_mdm6600_cmd() - send a command request to mdm6600
5d1ebbda0 Tony Lindgren 2018-03-08 154 * @ddata: device driver data
5d1ebbda0 Tony Lindgren 2018-03-08 155 *
5d1ebbda0 Tony Lindgren 2018-03-08 156 * Configures the three command request GPIOs to the specified value.
5d1ebbda0 Tony Lindgren 2018-03-08 157 */
5d1ebbda0 Tony Lindgren 2018-03-08 158 static void phy_mdm6600_cmd(struct phy_mdm6600 *ddata, int val)
5d1ebbda0 Tony Lindgren 2018-03-08 159 {
916010a73 Janusz Krzysztofik 2018-09-02 160 DECLARE_BITMAP(values, PHY_MDM6600_NR_CMD_LINES);
5d1ebbda0 Tony Lindgren 2018-03-08 161
916010a73 Janusz Krzysztofik 2018-09-02 162 *values = val;
5d1ebbda0 Tony Lindgren 2018-03-08 163
5d1ebbda0 Tony Lindgren 2018-03-08 @164 gpiod_set_array_value_cansleep(PHY_MDM6600_NR_CMD_LINES,
dea6937cb Janusz Krzysztofik 2018-09-02 165 ddata->cmd_gpios->desc,
dea6937cb Janusz Krzysztofik 2018-09-02 @166 ddata->cmd_gpios->info, values);
5d1ebbda0 Tony Lindgren 2018-03-08 167 }
5d1ebbda0 Tony Lindgren 2018-03-08 168
5d1ebbda0 Tony Lindgren 2018-03-08 169 /**
5d1ebbda0 Tony Lindgren 2018-03-08 170 * phy_mdm6600_status() - read mdm6600 status lines
5d1ebbda0 Tony Lindgren 2018-03-08 171 * @ddata: device driver data
5d1ebbda0 Tony Lindgren 2018-03-08 172 */
5d1ebbda0 Tony Lindgren 2018-03-08 173 static void phy_mdm6600_status(struct work_struct *work)
5d1ebbda0 Tony Lindgren 2018-03-08 174 {
5d1ebbda0 Tony Lindgren 2018-03-08 175 struct phy_mdm6600 *ddata;
5d1ebbda0 Tony Lindgren 2018-03-08 176 struct device *dev;
916010a73 Janusz Krzysztofik 2018-09-02 177 DECLARE_BITMAP(values, PHY_MDM6600_NR_STATUS_LINES);
5d1ebbda0 Tony Lindgren 2018-03-08 178 int error, i, val = 0;
5d1ebbda0 Tony Lindgren 2018-03-08 179
5d1ebbda0 Tony Lindgren 2018-03-08 180 ddata = container_of(work, struct phy_mdm6600, status_work.work);
5d1ebbda0 Tony Lindgren 2018-03-08 181 dev = ddata->dev;
5d1ebbda0 Tony Lindgren 2018-03-08 182
ad5003300 Tony Lindgren 2018-05-31 @183 error = gpiod_get_array_value_cansleep(PHY_MDM6600_NR_STATUS_LINES,
5d1ebbda0 Tony Lindgren 2018-03-08 184 ddata->status_gpios->desc,
dea6937cb Janusz Krzysztofik 2018-09-02 @185 ddata->status_gpios->info,
5d1ebbda0 Tony Lindgren 2018-03-08 186 values);
5d1ebbda0 Tony Lindgren 2018-03-08 187 if (error)
5d1ebbda0 Tony Lindgren 2018-03-08 188 return;
5d1ebbda0 Tony Lindgren 2018-03-08 189
ad5003300 Tony Lindgren 2018-05-31 190 for (i = 0; i < PHY_MDM6600_NR_STATUS_LINES; i++) {
916010a73 Janusz Krzysztofik 2018-09-02 191 val |= test_bit(i, values) << i;
5d1ebbda0 Tony Lindgren 2018-03-08 192 dev_dbg(ddata->dev, "XXX %s: i: %i values[i]: %i val: %i\n",
916010a73 Janusz Krzysztofik 2018-09-02 193 __func__, i, test_bit(i, values), val);
5d1ebbda0 Tony Lindgren 2018-03-08 194 }
5d1ebbda0 Tony Lindgren 2018-03-08 195 ddata->status = val;
5d1ebbda0 Tony Lindgren 2018-03-08 196
5d1ebbda0 Tony Lindgren 2018-03-08 197 dev_info(dev, "modem status: %i %s\n",
5d1ebbda0 Tony Lindgren 2018-03-08 198 ddata->status,
5d1ebbda0 Tony Lindgren 2018-03-08 199 phy_mdm6600_status_name[ddata->status & 7]);
5d1ebbda0 Tony Lindgren 2018-03-08 200 complete(&ddata->ack);
5d1ebbda0 Tony Lindgren 2018-03-08 201 }
5d1ebbda0 Tony Lindgren 2018-03-08 202
:::::: The code at line 164 was first introduced by commit
:::::: 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774 phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4
:::::: TO: Tony Lindgren <tony@atomide.com>
:::::: CC: Kishon Vijay Abraham I <kishon@ti.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30605 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] PCI: sysfs: Export available PCIe bandwidth
From: Stephen Hemminger @ 2018-09-05 7:26 UTC (permalink / raw)
To: Alexandru Gagniuc
Cc: linux-pci, bhelgaas, keith.busch, alex_gagniuc, austin_bolen,
shyam_iyer, Ariel Elior, everest-linux-l2, David S. Miller,
Michael Chan, Ganesh Goudar, Jeff Kirsher, Tariq Toukan,
Saeed Mahameed, Leon Romanovsky, Jakub Kicinski,
Dirk van der Merwe, netdev, linux-kernel, intel-wired-lan,
linux-rdma, oss-drivers
In-Reply-To: <20180903180242.14504-2-mr.nuke.me@gmail.com>
On Mon, 3 Sep 2018 13:02:28 -0500
Alexandru Gagniuc <mr.nuke.me@gmail.com> wrote:
> For certain bandwidth-critical devices (e.g. multi-port network cards)
> it is useful to know the available bandwidth to the root complex. This
> information is only available via the system log, which doesn't
> account for link degradation after probing.
>
> With a sysfs attribute, we can computes the bandwidth on-demand, and
> will detect degraded links.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In other places (like /sys/class/net/eth0/speed) only the raw value is printed
without suffix. The general convention in sysfs is that it should be one value
per file and in more raw format. So why not just print it in bits/sec without
suffix?
^ permalink raw reply
* [PATCH] 9p: readdir: do not trust pdu content for stat item size
From: Dominique Martinet @ 2018-09-05 8:00 UTC (permalink / raw)
To: Dominique Martinet, Eric Van Hensbergen, Latchesar Ionkov
Cc: Gertjan Halkes, v9fs-developer, netdev, linux-kernel,
Dominique Martinet
From: Gertjan Halkes <gertjan@google.com>
v9fs_dir_readdir() could deadloop if a struct was sent with a size set
to -2
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88021
Signed-off-by: Gertjan Halkes <gertjan@google.com>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
---
This patch has been sitting in bugzilla for three years, I'll take it
for the next merge window after some testing.
Thanks Gertjan!
fs/9p/vfs_dir.c | 8 +++-----
net/9p/protocol.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
index 48db9a9f13f9..cb6c4031af55 100644
--- a/fs/9p/vfs_dir.c
+++ b/fs/9p/vfs_dir.c
@@ -105,7 +105,6 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
int err = 0;
struct p9_fid *fid;
int buflen;
- int reclen = 0;
struct p9_rdir *rdir;
struct kvec kvec;
@@ -138,11 +137,10 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
while (rdir->head < rdir->tail) {
err = p9stat_read(fid->clnt, rdir->buf + rdir->head,
rdir->tail - rdir->head, &st);
- if (err) {
+ if (err <= 0) {
p9_debug(P9_DEBUG_VFS, "returned %d\n", err);
return -EIO;
}
- reclen = st.size+2;
over = !dir_emit(ctx, st.name, strlen(st.name),
v9fs_qid2ino(&st.qid), dt_type(&st));
@@ -150,8 +148,8 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
if (over)
return 0;
- rdir->head += reclen;
- ctx->pos += reclen;
+ rdir->head += err;
+ ctx->pos += err;
}
}
}
diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index ee32bbf12675..b4d80c533f89 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -571,9 +571,10 @@ int p9stat_read(struct p9_client *clnt, char *buf, int len, struct p9_wstat *st)
if (ret) {
p9_debug(P9_DEBUG_9P, "<<< p9stat_read failed: %d\n", ret);
trace_9p_protocol_dump(clnt, &fake_pdu);
+ return ret;
}
- return ret;
+ return fake_pdu.offset;
}
EXPORT_SYMBOL(p9stat_read);
--
2.17.1
^ permalink raw reply related
* [PATCH iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Hangbin Liu @ 2018-09-05 3:33 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, David Ahern, Hangbin Liu
The bridge mdb show is broken on current iproute2. e.g.
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp 34: br0 veth0_br 224.1.1.1 temp
After fix:
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp
34: br0 veth0_br 224.1.1.1 temp
Reported-by: Ying Xu <yinxu@redhat.com>
Fixes: c7c1a1ef51aea ("bridge: colorize output and use JSON print library")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
bridge/mdb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/bridge/mdb.c b/bridge/mdb.c
index f38dc67..d89c065 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -107,6 +107,10 @@ static void br_print_router_ports(FILE *f, struct rtattr *attr,
fprintf(f, "%s ", port_ifname);
}
}
+
+ if (!is_json_context() && !show_stats)
+ fprintf(f, "\n");
+
close_json_array(PRINT_JSON, NULL);
}
@@ -164,6 +168,10 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
print_string(PRINT_ANY, "timer", " %s",
format_timer(timer));
}
+
+ if (!is_json_context())
+ fprintf(f, "\n");
+
close_json_object();
}
--
2.5.5
^ permalink raw reply related
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Moritz Fischer @ 2018-09-05 4:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Andrew Lunn, Alex Williams,
Linux Kernel Mailing List
In-Reply-To: <fa4fca9c-5950-8ec1-5746-91e51085cecf@gmail.com>
Hi Florian,
On Tue, Sep 4, 2018 at 5:27 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 09/04/2018 05:15 PM, Moritz Fischer wrote:
>> Add basic PHYLINK support to driver.
>>
>> Suggested-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>> ---
>>
>> Hi all,
>>
>> as Andrew suggested in order to enable SFP as
>> well as fixed-link support add PHYLINK support.
>>
>> A couple of questions are still open (hence the RFC):
>>
>> 1) It seems odd to implement PHYLINK callbacks that
>> are all empty? If so, should we have generic empty
>> ones in drivers/net/phy/phylink.c like we have for
>> genphys?
>
> Yes it is odd, the validate callback most certainly should not be empty,
> neither should the mac_config and mac_link_{up,down}, but, with some
> luck, you can get things to just work, typically with MDIO PHYs, since a
> large amount of what they can do is discoverable.
>
> If you had an existing adjust_link callback from PHYLIB, it's really
> about breaking it down such that the MAC configuration of
> speed/duplex/pause happens in mac_config, and the link setting (if
> necessary), happens in mac_link_{up,down}, and that's pretty much it for
> MLO_AN_PHY cases.
Let me check, it seems there is a register that indicates whether the MAC can
do either 1G or 10G. I might be able to use that for some of the above, but
there is not really much in terms of writable registers there.
It's like a DMA engine with a bit of MDIO on the side. Let me see if I can make
it look less weird with that. If not I'll go with a comment explaining
that there
isn't much to do for the MLO_AN_PHY case and the MLO_FIXED cases?
Cheers and thanks for your feedback,
Moritz
^ 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